Журнал · Rit.work

Почему ветвящийся поиск не помог терминальным агентам

Probe-and-Resume откладывает проверку терминального агента до сигнала о готовности и позволяет критику испытывать результат в изолированной копии среды.

Rit.work
Студия разработки
16 октября 2026 г.3 мин чтения

Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.

Проверять работу терминального ИИ-агента полезнее после того, как он объявил задачу выполненной, а не на каждом промежуточном шаге. В нерецензированном препринте Columbia University числа получили сами авторы: схема Probe-and-Resume подняла долю успешных задач на 8,4 процентного пункта относительно поиска по дереву Монте-Карло (MCTS) с обычным критиком. Для продуктовой команды это смещает инвестиции с перебора промежуточных ветвей на изолированную проверку готового состояния и цикл исправлений.

Почему промежуточный шаг трудно оценить

Терминальный агент меняет не только текст, который видит модель. Он создаёт файлы, запускает процессы, устанавливает пакеты, правит базы данных и конфигурацию сервисов. История команд показывает лишь часть состояния компьютера, поэтому критик может пропустить важный побочный эффект или принять перспективный промежуточный результат за тупик.

Эксперимент охватил все 89 задач Terminal-Bench 2.1. В роли агента и критика работала GPT-5.6 Luna, Terminus-2 управлял диалогом с терминалом, а Waypoint сохранял и восстанавливал состояние контейнера. Проверяли одну конкретную конфигурацию поиска, поэтому результат не доказывает, что любой MCTS бесполезен для компьютерных агентов.

Критиков вызывали в разных точках траектории. Один видел только историю действий, второй мог читать состояние среды, третий получал право выполнять команды и менять изолированную копию. На ранних этапах все варианты ранжировали продолжения лишь немногим лучше случайного выбора; ближе к завершению оценки становились полезнее.

Доступ к среде мало помогал предсказывать будущее промежуточной ветви. Зато после заявления агента о готовности критик с правом выполнять команды снизил долю ошибочных решений до 22%. Простого чтения файлов оказалось недостаточно: чтобы проверить программу, сервис или восстановленные данные, часто нужно собрать собственный тест и запустить его.

Как Probe-and-Resume проверяет почти готовое состояние

Probe-and-Resume не строит дерево после каждого фрагмента работы. Агент сначала выполняет задачу обычным способом. Когда он считает результат готовым, система сохраняет состояние и создаёт его изолированную копию для критика.

Критик может читать и изменять файлы, запускать программы, устанавливать зависимости и проводить разрушительные проверки. Его изменения не попадают в рабочее состояние агента: после проверки копию выбрасывают. Это позволяет, например, остановить сервис, повредить временный файл или переписать конфигурацию ради теста, не разрушая результат, который ещё предстоит исправлять.

Критику также дают копию исходной среды. Она нужна для требований вроде «сохранить прежнее поведение», «не менять входной файл» или «восстановить удалённые данные». Без исходной точки даже полный доступ к готовому состоянию не показывает, что именно агент должен был оставить неизменным.

Если критик принимает результат, его отправляют внешнему проверяющему механизму. Если отклоняет, агент получает найденные проблемы и продолжает работу с сохранённого состояния, а не начинает задачу заново. Критик здесь решает более узкую задачу, чем при поиске: он не угадывает, какая ветвь когда-нибудь приведёт к успеху, а проверяет конкретное заявление о готовности.

Что меняется в архитектуре агента

Одних снимков среды недостаточно. Когда агенту просто добавили команды сохранения и восстановления, он воспользовался ими лишь в 3 из 445 запусков. Значит, инфраструктура ветвления сама по себе не превращается в стратегию: нужно заранее определить, кто создаёт копию, когда запускается проверка и как замечания возвращаются агенту.

Обычный MCTS почти не изменил долю успешных задач, поскольку опирался на слабые оценки промежуточных состояний. Probe-and-Resume довёл успешность до 72,4%, приблизился к Codex CLI на той же базовой модели и потребовал менее половины его стоимости на модельные токены.

Работа меняет планы команд, чьи агенты управляют живой средой, а точный проверяющий механизм недоступен во время выполнения. Вместо критика после каждого шага им стоит рассмотреть контрольную точку перед сдачей результата, одноразовую копию среды, права на выполнение проверок и возврат к сохранённому состоянию после отказа.

Для задач с надёжным встроенным тестом модель-критик не заменяет этот тест. Probe-and-Resume предназначен для случаев, где требования приходится восстанавливать по инструкции, состоянию компьютера и собственным пробам. Работа также не устанавливает, что сигнал о готовности всегда служит лучшим моментом проверки: она показывает, что в исследованной конфигурации этот момент полезнее регулярной оценки частично выполненной работы.

Источники

Пауза в чтении

Похоже на вашу задачу?

Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.

Rit.work

Студия разработки

Собираем мобильные приложения и помогаем командам получать от AI реальную пользу. Основатель и команда, работаем удалённо — с клиентами в России и за рубежом.

← Ко всем материалам
Понравилось? Обсудим вашу задачу