Бюджет шагов: почему агент должен уметь сдаваться

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

И вторая половина, которую обычно упускают: потолок в шагах — не тот потолок, который стоит денег.

Шаги умножаются

В контуре управления интерфейсом, который я разбирал раньше, ограничение выглядит так: не больше 24 шагов, и на каждом шаге до 3 попыток, если модель вернула невалидное действие.

Верхняя граница одного запуска — не 24 обращения к модели, а 72.

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

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

Из чего должен состоять потолок

Один лимит недостаточен, потому что исчерпываются разные вещи.

Шаги. Грубая защита от зацикливания. Ставится по здравому смыслу: сколько шагов нужно человеку на такую задачу, умножить на два.

Попытки внутри шага. Три — разумное значение: первая может не удаться случайно, вторая с подсказкой об ошибке обычно проходит, третья почти никогда не приносит нового.

Деньги или токены. Единственный лимит, который переживает смену задачи. Шаги на разных задачах стоят по-разному: шаг со снимком экрана дороже текстового в разы, картинки — это тоже токены.

Время. Защита не от цикла, а от зависшего инструмента.

Отсутствие прогресса. Самый полезный и самый трудный: если состояние не меняется несколько шагов подряд, дальше идти незачем.

Что делать при исчерпании

Здесь чаще всего ошибаются: считают, что достижение лимита — это провал, и просто бросают запуск.

Правильнее относиться к лимиту как к точке передачи. Агент должен завершиться отчётом: что было целью, что успел сделать, где встал, что пробовал. Тогда человек продолжает с этого места, а не начинает заново.

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

Условие несогласия

Для агента, который читает и ничего не меняет, жёсткий потолок шагов менее критичен: цена лишнего круга — только токены, и лимита по деньгам достаточно.

Как только у агента появляется право менять состояние — файлы, письма, записи в базе, — потолок становится обязательным. Зацикливание с записью не просто расходует бюджет, оно оставляет след, который потом разбирать.

Чего я делать не стал бы

Не стал бы делать лимит настраиваемым «на глаз» без журнала. Без записи о том, на каком шаге запуски обычно заканчиваются, любое число — догадка.

Не стал бы позволять агенту самому поднимать себе лимит. Это выглядит удобно ровно до случая, когда он поднимает его в цикле.

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

Открытый вопрос

Лимит в шагах — это признание, что критерия «задача невыполнима» у нас нет. Мы не умеем отличить «ещё немного, и получится» от «не получится никогда», и заменяем это счётчиком.

Счётчик работает, но платится дважды: обрывает задачи, которым не хватило одного шага, и позволяет двадцати шагам уйти в никуда. Настоящее решение требует, чтобы агент мог оценить достижимость цели из текущего состояния, а этого он не умеет — и, судя по устройству, не научится, пока оценка достижимости остаётся тем же порождением правдоподобного текста.