Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Языкового агента можно заставить стабильнее выдавать уже найденное решение, не меняя модель и пользовательский запрос. В работе Failproof AI точечные правила подняли долю успешных запусков на подходящих задачах с 39% до 61%, хотя препринт не рецензирован и все числа получили сами авторы. Для команд это повод сначала исправить повторяемые ошибки в управляющей оболочке, а не сразу переходить на более дорогую модель.
Правило срабатывает там, где решение обычно теряется
Авторы называют подход FIRE. Он рассчитан не на случаи, когда модели не хватает знаний или она не может построить алгоритм, а на процедурные сбои после основной работы.
Например, агент пишет и проверяет сервер, но запускает его внутри своей командной сессии. После завершения сессии процесс исчезает, поэтому внешняя проверка не находит работающий сервис. В другом случае агент правильно заменяет нужные фрагменты файла, а затем запускает форматирование и портит байты, которые требовалось сохранить.
FIRE превращает такой сбой в правило управляющей оболочки. Правило сначала определяет, относится ли к нему задача, затем следит за действиями агента и вмешивается только перед известным опасным шагом.
Вмешательство принимает одну из двух форм. Оболочка либо добавляет короткую инструкцию в контекст и заставляет агента продолжить работу, либо запрещает действие: например, не разрешает открывать повреждённую базу на запись до создания копии вместе с журналом.
Практический процесс выглядит так:
- Собрать неудачные траектории, где агент уже создавал рабочий результат или успешно решал ту же задачу в другом запуске.
- Найти наблюдаемое состояние перед сбоем: попытку завершить работу, опасную команду или отсутствие отдельной проверки.
- Описать область действия по тексту задачи и точный момент срабатывания по истории команд.
- Зафиксировать ожидаемое исправление, условие отключения правила и предел повторных подсказок.
- Проверить соседние задачи, чтобы правило не вмешивалось там, где агент и без него работает правильно.
Такое разделение важно: слишком широкое правило расходует токены и отвлекает модель, а позднее уже не может отменить необратимую команду. Правило также не должно содержать ответ на конкретную задачу, путь к тестовому файлу или другое скрытое знание.
Точный приказ сработал, общая перепроверка — нет
Авторы отделили содержание правила от самого факта вмешательства. В контрольном варианте оболочка останавливала агента в тот же момент, но давала общую просьбу проверить работу. Ещё два варианта просили всегда проводить проверку или пересмотреть решение.
Только конкретные инструкции заметно повысили успех. Значит, агенту помогла не дополнительная пауза и не абстрактный призыв подумать ещё раз, а описание нужного действия: отделить процесс от сессии, проверить порт отдельной командой или не менять исходные данные до копирования.
На полном наборе доля задач, которые старший вариант GPT-5.6 решил в обоих запусках, выросла с 64,4% до 73,6%. При этом доля задач хотя бы с одним успехом прибавила лишь 1,2 процентного пункта. Правила почти не расширили набор доступных модели решений, зато сделали их повторяемыми.
На покрытых правилами задачах средний вариант Terra достиг 71,4% успешных попыток против 64,3% у более дорогого Sol без правил. Terra обошлась примерно вдвое дешевле, но этот результат относится только к заранее выбранным типам сбоев и не доказывает общего превосходства над Sol.
Когда управляющая оболочка меняет план разработки
Работа поддерживает архитектуру, в которой модель отвечает за поиск решения, а оболочка — за его сохранение и доставку. Если журналы показывают несколько повторяющихся процедурных сбоев с наблюдаемым моментом перед ошибкой, отдельный слой правил может оказаться дешевле смены модели.
Для этого агентская платформа должна записывать команды, результаты инструментов, попытки завершить работу и собственное состояние правил. Без таких журналов команда не сможет отличить нехватку возможностей модели от ситуации, когда готовый результат потерялся на последнем шаге.
При испытаниях стоит отдельно считать достижимость и повторяемость. Первый показатель отвечает, решила ли модель задачу хотя бы однажды, второй — прошла ли она проверку во всех одинаковых запусках. Рост только второго показателя означает, что оболочка удерживает существующую возможность, а не добавляет новую.
Замеры охватывают полный набор из 87 англоязычных задач Terminal-Bench 2.1, по две попытки на условие, Codex CLI и одну семью моделей при одинаковом уровне рассуждения. Наборы правил различались между вариантами модели, поэтому переносить их без повторной проверки нельзя. Авторы также являются сооснователями Failproof AI, которая разрабатывает использованную инфраструктуру.
FIRE не заменяет обновление модели, если агент не знает нужного метода или не может получить рабочий промежуточный результат. Но при устойчивых ошибках доставки порядок работ меняется: сначала воспроизвести сбой, поставить узкое правило в оболочку и проверить побочные эффекты, а уже затем оценивать, окупает ли себя более дорогая модель.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
