Агенты с самопроверкой против агентов без верификации

Разработчик собирает агента, который по запросу пользователя бронирует переговорку, пишет письмо и создаёт задачу в трекере. В первой версии агент просто выполняет шаги подряд. Во второй — после каждого действия останавливается и проверяет: получилось ли, правильные ли параметры, не противоречит ли результат исходной задаче. Первая версия быстрее и дешевле в 2–4 раза по токенам. Вторая реже ломает прод и реже отправляет письмо не тому адресату. Выбор между этими двумя архитектурами — не про моду, а про то, что дороже: лишние токены или разбор последствий ошибки.

Что такое самопроверка агента

Под самопроверкой (self-verification) понимают шаг, на котором агент оценивает собственный промежуточный или финальный результат перед тем, как двигаться дальше или отдать ответ. Технически это может быть отдельный вызов модели с промптом вида «проверь, соответствует ли этот результат задаче», сравнение с формальным критерием (тест прошёл или нет, JSON валиден или нет), либо второй агент-критик, который смотрит на работу первого.

Агент без верификации работает по циклу «подумал — сделал — сделал следующий шаг». Ошибка на раннем шаге тащится дальше и обрастает новыми ошибками. Агент с верификацией добавляет в цикл ещё одно звено — «сделал — проверил — при провале переделал».

Три уровня проверки

На практике встречаются три разных подхода, и их часто путают под одним словом «самопроверка»:

• Детерминированная проверка. Результат сверяется с машинным критерием: компилятор, линтер, схема JSON, юнит-тест, ответ внешнего API. Дешёвая и надёжная, но применима только там, где критерий формализуем.
• Проверка самой моделью (self-critique). Тот же LLM получает свой вывод и промпт «найди ошибки». Работает без внешней инфраструктуры, но модель склонна одобрять собственные ответы и пропускать те же ошибки, что и совершила.
• Отдельный агент-критик. Второй экземпляр модели, часто с другим промптом или другой моделью, оценивает работу первого. Дороже по токенам, но ломает эффект «сам себе судья».

Где верификация окупается, а где нет

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

Верификация нужна не там, где модель ошибается чаще, а там, где ошибку дороже всего исправить постфактум.

Второй фактор — есть ли дешёвый машинный критерий. Для кода он почти всегда есть: запустить тесты, прогнать линтер, проверить, что код компилируется. Здесь детерминированная проверка почти бесплатна по сравнению с лишним вызовом модели и резко снижает долю нерабочих ответов. Для задач вроде «напиши убедительное письмо» формального критерия нет, и остаётся либо self-critique с его слабостями, либо человек.

Сравнение подходов

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

Скрытая цена самопроверки

У верификации есть цена, о которой забывают на этапе прототипа:

1. Токены и деньги. Каждый шаг проверки — это дополнительный вызов модели с полным или частичным контекстом. На длинных цепочках расход растёт кратно.
2. Задержка. Проверка после каждого шага удваивает число последовательных обращений к модели. Для интерактивного агента это ощутимая пауза для пользователя.
3. Ложная уверенность. Self-critique создаёт иллюзию контроля: агент «проверил себя» и одобрил, но пропустил ту же ошибку. Проверка без независимого критерия иногда хуже её отсутствия, потому что усыпляет.
4. Зацикливание. Агент проваливает проверку, переделывает, снова проваливает и уходит в цикл, пока не упрётся в лимит итераций или бюджета. Без жёсткого потолка на число попыток это прямой путь к неконтролируемому счёту.

Как выбрать под свою задачу

Практический порядок решений выглядит так:

• Оцените цену одной ошибки, дошедшей до конца. Если она близка к нулю (черновик, который правит человек) — начните без верификации.
• Проверьте, есть ли машинный критерий. Есть тест, схема, валидатор — ставьте детерминированную проверку, она почти бесплатна и надёжна.
• Нет критерия, но ошибка дорогая — добавляйте отдельного критика, а не self-critique того же промпта.
• В любом случае поставьте потолок на число итераций и на бюджет токенов, чтобы цикл проверок не съел деньги молча.

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

Ни один из подходов не универсален. Агент без верификации выигрывает в скорости и цене на дешёвых ошибках. Агент с проверкой выигрывает там, где разбор последствий стоит дороже лишних токенов. Начинать разумнее с замера цены ошибки, а не с выбора модной архитектуры.