Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Замечания к работе агента для программирования помогают чаще доводить длинные задачи до решения, если проверять не только реакцию агента, но и устранение исходной ошибки. Kai Mei и соавторы в системе Opera повысили долю решённых задач на SWE-Bench Pro на 15 процентных пунктов; препринт не рецензирован, а все числа получили сами авторы. Такой критик становится отдельным контуром управления агентом, а не ещё одним запросом с советом.
Замечание остаётся открытым до проверки исправления
Обычный критик читает историю действий, указывает на ошибку и исчезает из процесса. Агент может формально выполнить совет, но оставить исходную проблему: добавить проверку, после которой тест всё равно падает, или изменить соседний файл вместо нужного.
Opera хранит только одну открытую заметку. В ней записаны проблема, видимые доказательства, направление исправления и неизменный критерий закрытия. Следующий разбор получает эту заметку вместе с новой историей действий, поэтому критик проверяет продолжение той же работы, а не начинает рассуждение заново.
Проверки запускаются по расписанию и после событий, которые часто указывают на сбой: агент бездействует, повторяет действие, получает ошибку, объявляет задачу выполненной или отправляет итоговые изменения. Сам запуск не требует вмешательства — критик может разрешить продолжить работу без замечания.
Вместо свободного комментария Opera выбирает тип проблемы по этапу ремонта: поиск нужного места, чтение кода, правка, тестирование или сдача результата. Затем она указывает конкретное место, текущее поведение, требуемое изменение и способ его проверить. За один раз агент получает одну проблему, чтобы инструкции не конкурировали между собой.
Перед отправкой замечание проходит проверку: подтверждают ли наблюдаемые действия диагноз, нужна ли правка для задачи и позволит ли предложенный тест установить результат. Другая проверка закрывает заметку только после появления подходящего доказательства. Эти фильтры оказались существенной частью метода: на Terminal-Bench 2.1 без них прирост сократился с 7,9 до 2,6 процентного пункта.
Opera отдельно отмечает соблюдение совета и устранение проблемы. Первое означает, что агент попытался выполнить инструкцию. Второе — что выполнен исходный критерий, например нужный тест проходит или в изменениях появился требуемый контракт. Это различие и превращает разовый комментарий в управляемое состояние процесса.
Критик помогает только агенту, способному применить совет
Метод проверяли на трёх наборах задач — Terminal-Bench 2.1, подмножестве SWE-Bench Pro и DeepSWE v1.1 — с четырьмя моделями агента и разными средами запуска. В основной конфигурации роль критика выполняла GPT-5.6-Sol, а Opera сравнивали с агентом без критика и четырьмя подходами, которые оценивают ход работы или итоговый патч.
На Terminal-Bench 2.1 максимальный прирост составил 12,4 процентного пункта, на DeepSWE v1.1 — 8,9. С Qwen3.8-27B система показала лучшую среднюю долю решённых задач среди сравнённых критиков на всех наборах, хотя на SWE-Bench Pro преимущество перед ближайшим вариантом было небольшим.
Результат зависит не только от силы критика. Слабая модель получает пользу, пока умеет построить рабочее решение после подсказки. Если необходимой способности нет, замечания не заменяют её. У сильных моделей возникает другая проблема: они охотнее следуют совету, поэтому удачная подсказка чаще спасает задачу, а ошибочная — чаще ломает ход работы, который и без неё завершился бы успешно.
Модель может критиковать саму себя. Такая схема помогала там, где агент уже владел нужными знаниями, но не применял их вовремя. Для слабых агентов внешний более сильный критик давал больший эффект, поскольку самокритика наследовала те же слепые зоны.
Планы меняет контур контроля, а не выбор основной модели
Opera подключается через историю действий и текстовые сообщения, не меняя веса агента. Поэтому существующую систему можно испытать без переобучения: добавить события для запуска проверки, хранить открытую заметку, пропускать советы через фильтр и собирать доказательства закрытия. Особенно хорошо схема соответствует задачам, где агент долго исследует репозиторий, повторяет команды или преждевременно объявляет работу законченной.
Закладывать критика как обязательную часть архитектуры стоит после проверки на собственных задачах. Он добавляет запросы к модели и задержку, а в опытах с самокритикой вычислительные затраты разных вариантов не уравнивали. Практический показатель здесь — не количество выданных советов, а доля заметок, после которых исходная проблема действительно исчезла, с отдельным учётом задач, испорченных лишним вмешательством.
Тот же контур можно использовать при обучении. Авторы дообучили Qwen3.5-9B на её собственных действиях под руководством более сильного критика и получили прирост 10,2 процентного пункта на отложенных репозиториях без Opera во время запуска. Обучение на траекториях сильной модели дало близкий результат на целевом наборе, но заметно ухудшило перенос в другую среду; траектории самой слабой модели сохранили его лучше.
Для команды это разделяет два решения. Если агент способен исправлять диагностированные ошибки, сначала имеет смысл испытать постоянные заметки и аудит вмешательств. Если агент не находит жизнеспособного решения даже с точной подсказкой, Opera не отменяет переход на более подходящую основную модель.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
