Это вторая заметка в серии о проектировании агентов для длительных задач, появившаяся после внимательного чтения BEACON (Чжэцзянский университет, arXiv:2605.06078).
В первой заметке мы утверждали, что обнаружение циклов не выявляет застрявшего агента, поскольку повторение — сигнал на стороне входа, а прогресс — на стороне выхода. Этот аргумент работает, только если есть то, относительно чего измерять прогресс. Эта заметка — именно об этом.
Правильно поставьте вопрос
Вопрос не в том, «как агент узнаёт, что закончил шаг». Вопрос в том, «как система узнаёт, что он действительно закончил, а не просто объявил об этом».
Разница в один слой, а достоверность несопоставима.
Обе половины уже были, но мы их не соединили
При чтении собственной реализации именно это удивило нас больше всего.
Первая половина. Контрольные этапы уже есть в продукте. Инструмент поддерживает сохраняемый план задачи: на что разбивается длительная задача и в каком состоянии каждый шаг — ожидает, выполняется, завершён, заблокирован. Его заявленная цель — дать длительной задаче устойчивую опору для оценки прогресса. Но как шаг становится «завершённым»? Об этом объявляет модель.
Вторая половина. После каждого вызова инструмента хост записывает набор детерминированных фактов: действительно ли изменился хеш содержимого файла, каким был код завершения команды, истекло ли время ожидания. Они записываются на стороне хоста и никогда не попадают в контекст модели — именно поэтому модель не может их выдумать.
Вот где разрыв. Одна запись говорит: я закончил. Другая говорит: хеш файла изменился с A на B. Никто никогда не сопоставлял их.
Не хватает не структуры данных и не наблюдаемости. Не хватает моста между ними.
Самое полезное в статье — не формула
BEACON прежде всего известен преимуществом на двух масштабах, но перенять стоит роль детектора Φ.
Φ не требует обученной модели или ручной разметки. Он читает только изменения состояния, наблюдаемые в обратной связи среды: переходы состояния объектов в ALFWorld (предмет успешно взят, нагрев завершён), переходы страниц в WebShop, а в ScienceWorld просто получает сигнал подцели, который среда уже выдаёт.
Никакой дополнительной модели и никаких дополнительных затрат на выборку. Сравните альтернативы: модель вознаграждения за процесс требует дорогой разметки и допускает манипуляции, а оценка ценности методом Монте-Карло требует дополнительных прогонов в каждой точке решения. Именно этих затрат избегает Φ.
У создателей агентных продуктов есть преимущество, которого нет в условиях статьи: вызовы инструментов изначально структурированы и явно показывают успех и неудачу. Авторам пришлось извлекать сигналы из среды. У нас они уже есть.
Три слоя возможной реализации
Первый слой: собрать детерминированные доказательства в один поток. Никаких смысловых суждений, только механическая запись необратимых проверяемых изменений. Изменился хеш содержимого файла. Команда завершилась с кодом ноль. Внешний вызов API вернул успех. Строка зафиксирована. Всё это существует уже сейчас, но разбросано и никогда не собирается в единую запись установленных к этому моменту фактов.
Второй слой: соединить две половины. Самый ценный шаг. Когда модель объявляет шаг завершённым, перестаньте принимать это на веру и поищите доказательства первого слоя в соответствующем временном окне. Есть доказательства — отметьте завершение подтверждено. Нет доказательств — отметьте завершение заявлено. Это не запрещает модели ничего заявлять, а лишь отделяет подтверждённое от неподтверждённого.
Третий слой: определить Φ для каждого типа возможностей. Авторы признают, что Φ требует предметных знаний и плохо обобщается, поэтому универсального детектора ждать не стоит. Задачи программирования следят за кодами завершения тестов. Задачи анализа данных — за появлением выходного файла. Задачи отправки сообщений — за ответом API. Этот слой наращивается постепенно, по одной возможности за раз.
Один добавленный нами критерий: необратимость, а не важность
Этого в статье нет.
Контрольные этапы BEACON работают, потому что отмечают переходы состояния, которые нельзя обратить. Когда ключ у вас, мир уже изменился. Поэтому критерием должно быть произвело ли это действие необратимый внешний эффект, а не был ли этот шаг важным.
Необратимое: запись файла, фиксация кода, отправка сообщения, вызов платного API, фиксация в базе данных. Обратимое: чтение файла, поиск, получение страницы, размышление.
Отсюда два следствия. Это можно определить механически по типу действия — без понимания смысла и субъективности вроде «модель сочла шаг важным». И это совпадает с точками восстановления: только возобновление с необратимой границы имеет смысл, поскольку обратимые действия можно просто повторить.
Два числа: одно для уверенности, другое для осторожности
Уверенность придаёт эксперимент с ухудшением. Случайно уберите половину контрольных этапов, и оценка всё ещё будет 82,8 против базовых 72,8 — на десять пунктов выше. Ухудшение плавное, без обвала. Для тех, кто выпускает такую систему, это главное: не нужно доводить Φ до совершенства, прежде чем решиться его включить. Уже половинное покрытие приносит пользу.
Осторожности учит сравнение разбиений.
| Разбиение | Оценка | К базовому уровню (72,8) |
|---|---|---|
| Случайное разбиение на 5 частей | 74,2 | +1,4 |
| Реальные контрольные этапы | 91,4 | +17,2 |
В первой заметке эти числа тоже приводились, но здесь вывод прямее. Если этапы заданы интуитивно, это примерно случайное разбиение и работа потрачена впустую. Этапы ценны именно тогда, когда совпадают с реальной структурой задачи.
Где нужны оговорки
В приложении к самой статье автоматическое выявление этапов названо открытой проблемой. Все три теста получают этапы из правил: сопоставления шаблонов ответов среды, переходов страниц или сигнала, который среда выдаёт напрямую. В действительно открытых задачах — работе в браузере, рефакторинге кодовой базы, глубоком исследовании — нет таких готовых проверяемых переходов.
Поэтому это подход, проверенный внутри структурированных сред, а не решение, которое можно перенести целиком. Применимым в агентном продукте его делает структурированная граница вызова инструмента, а не уже готовый ответ из статьи.
Другая ловушка — детализация. Слишком редкие этапы ничего не дают; слишком частые превращают сигнал уровня сегмента в шум. В продукте это уровень разбиения задачи, и здесь есть удобство, которого нет в условиях статьи. Шаги плана изначально видны пользователю, поэтому детализацию можно привязать к понятности шага человеку, а не настраивать только алгоритмически.
Если делать только одно
Сделайте второй слой.
Он дешёвый, поскольку данные первого слоя уже есть, а второй лишь сопоставляет их с заявлениями модели. Он независимо проверяем, потому что отношение подтверждённого к заявленному само по себе заслуживает наблюдения. И это необходимое условие всего остального: без понятия проверенного этапа ни обнаружению остановки прогресса из первой заметки, ни границе сжатия контекста из следующей не на что опереться.
У него есть и удобное свойство. Внедрение не меняет поведение: модель объявляет шаги как прежде, просто появляется дополнительная отметка. Когда накопятся данные, можно решить, вмешиваться ли в заявления без доказательств.
Следующая заметка посвящена сжатию контекста: почему обрезка по порогу токенов мало связана с тем, что безопасно забыть, и как поправить самое естественное продолжение этой заметки — предположение, что после проверки этапа всё предшествующее можно свернуть.