Кто принимает результат в многошаговом агенте: агент, проверяющий или код

Вопрос: «кто принимает результат — отдельный проверяющий шаг или сам агент?» Это вопрос про архитектуру доверия в многошаговом агенте. И ответ на него — не «то или это», а «и то, и другое, но в разных ролях».

Почему «сам агент» — плохая идея

Самый простой вариант: агент сделал задачу → агент говорит «готово». Для болтовни это работает. Для задач — ломается.

Причина простая: агент не видит факт, он видит своё представление о факте. Он открыл страницу, кликнул «Отправить», увидел тост «письмо отправлено» — и говорит «готово». А через минуту выясняется, что тост был про черновик, а письмо не ушло. Или ушло не на тот адрес. Или ушло, но без вложения.

Агент не врёт. Он не знает, что произошло на самом деле. Он видит то, что ему показали. И если показали не то — он скажет «готово» с чистой совестью.

Это не проблема конкретной модели. Это фундаментальное свойство любого агента, который работает через интерфейсы: он видит интерфейс, а не реальность. Кнопка «Отправить» может быть неактивной, но выглядеть активной. Тост может быть про «сохранено», а не «отправлено». Страница может показать «успех», а на бэкенде при этом — ошибка.

Поэтому «сам агент принимает результат» — это не проверка, это декларация. Агент декларирует успех, но не проверяет его.

Почему «отдельный проверяющий шаг» — тоже не панацея

Второй вариант: после агента запускается отдельный проверяющий (другой агент, LLM-judge или человек), и уже он говорит «принято» / «не принято».

Это лучше, чем «сам агент», но у подхода три проблемы.

Первая: проверяющий видит то же, что и агент. Если агент смотрел на тост «успех», а проверяющий смотрит на тот же тост — он скажет «успех». Проверяющий не видит реальность, он видит интерфейс, через который смотрел агент. Значит, проверка — это второе мнение о том же представлении, а не проверка факта.

Вторая: проверяющий — это ещё один LLM-вызов. Он стоит денег и времени. И он тоже может ошибаться. LLM-judge, который смотрит на trace и говорит «выглядит правдоподобно» — это не проверка, это ещё одно мнение. Иногда полезное (ловит грубые ошибки), но не заменяет факт.

Третья: проверяющий не знает контекста. Он видит «агент сказал готово, trace выглядит ок» — но не знает, что оператор просил «отправить на boss@example.com», а агент отправил на boss@example.co (опечатка). Проверяющий не сверяет с задачей, он сверяет с trace.

Значит, «отдельный проверяющий шаг» — это лучше, чем ничего, но не заменяет проверку факта.

Что работает: три уровня приёмки

В моём опыте работает трёхуровневая схема. Не «или-или», а «и-и-и», где каждый уровень ловит свой класс ошибок.

Уровень 1: внешний сенсор (оракул). Это код, который проверяет факт, а не мнение. Для публикации поста — открывает страницу и проверяет: slug в URL, теги в meta, ключевые слова в тексте. Для письма — открывает «Отправленные» и проверяет: получатель, вложение, время. Для PDF — открывает PDF и проверяет: текст читается, нет сырого markdown, картинки встроены.

Оракул не спрашивает агента. Он смотрит в реальность (DOM, файл, URL) и говорит PASS или FAIL. Если FAIL — агент получает конкретное поле («slug старый», «теги не те») и чинит. Пока оракул не скажет PASS — задача не закрыта.

Это самый важный уровень: он ловит фактические ошибки: «сделал, но не то», «сделал, но не там», «сделал, но не так».

Уровень 2: структурная эвристика (аудит). Это код, который проверяет полноту, а не факт. Например: «оператор просил три вещи (пост, PDF, письмо) — агент сделал все три?» или «в ответе есть слово “не удалось” — значит, это не финальный успех». Эвристика не смотрит в DOM, она смотрит в trace и в ответ агента.

Этот уровень ловит логические ошибки: «сделал две вещи из трёх», «сказал готово, но в ответе есть “не удалось”», «не предложил следующий шаг, хотя просили».

Уровень 3: человек (оператор). Это последний рубеж, для случаев, где автоматика не может решить. Не «на каждом шаге», а только там, где повтор опасен и сверка ненадёжна: письмо ушло или нет, платёж прошёл или нет, вход выполнен или нет.

Оператор смотрит в Live View или во внешнюю систему и говорит: «сделано» / «не сделано». После этого — либо complete, либо retry.

Он ловит неопределённость: «мы не знаем, что произошло, и автоматика не может узнать».

Почему три уровня, а не один

Потому что разные ошибки ловятся разными способами.

- Оракул ловит «сделал не то». Он не ловит «сделал не всё» (потому что не знает, что просили) и не ловит «не знаю, что произошло» (потому что не видит реальность за пределами DOM). - Аудит ловит «сделал не всё». Он не ловит «сделал не то» (потому что не видит DOM) и не ловит «не знаю, что произошло» (потому что не видит внешнюю систему). - Оператор ловит «не знаю, что произошло». Он не ловит «сделал не то» (потому что не видит DOM так же быстро, как код) и не ловит «сделал не всё» (потому что не помнит, что просили пять шагов назад).

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

Кто «принимает результат»

Формально — оракул. Он говорит PASS или FAIL, и это объективный критерий. Агент не может сказать «готово», если оракул говорит FAIL. Ключевое здесь: агент не принимает результат, агент его производит. Принимает — код.

Аудит — это второй фильтр, который ловит полноту. Он не «принимает», он «сигнализирует»: «эй, кажется, что-то не сделано». Если аудит говорит «есть дыра» — агент идёт чинить. Если починить не получается — сообщает оператору «вот дыра, вот что нужно».

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

Как это выглядит в жизни

Представим агента, который готовит пост, PDF и письмо. Шаги:

1. Сгенерировать пост → оракул: «slug обновлён, теги обновлены, текст на месте». FAIL → чинит. 2. Сгенерировать PDF → оракул: «текст читается, нет сырого markdown». FAIL → чинит. 3. Отправить письмо → оракул: «в Отправленных есть письмо с нужным получателем». FAIL (нет письма) → чинит. FAIL (письмо есть, но без вложения) → чинит.

Аудит после шага 3: «оператор просил три вещи, все три сделаны?» Если нет — «ты забыл вложение». Агент чинит.

Оператор — только если письмо «ушло, но мы не уверены» (Live View: «я вижу, что ушло» / «я вижу, что не ушло»).

В итоге агент не говорит «готово», пока оракул не скажет PASS. И не говорит «готово», если аудит нашёл дыру. И не говорит «готово», пока оператор не разрешил неопределённость. Только когда все три уровня сказали «ок» — задача закрыта.

Что не работает

Четыре подхода, которые выглядят разумно, но ломаются на практике.

Первый: «LLM-judge решает». LLM-judge — это мнение, а не факт. Он может сказать «выглядит хорошо», а факт — плохо. LLM-judge полезен как дополнительный фильтр (ловит грубые ошибки), но не заменяет оракул.

Второй: «агент сам решает, что готово». Это декларация, а не проверка. Агент видит интерфейс, а не реальность.

Третий: «оператор проверяет каждый шаг». Оператор не бесплатный. Если каждая задача требует подтверждения — агент не работает.

Четвёртый: «оракул проверяет всё». Оракул видит факт в DOM, но не видит полноту (что просили) и неопределённость (что произошло за пределами DOM). Оракул — один из уровней, а не замена всем остальным.

Итог

Кто принимает результат? Код, а не агент. Агент производит, код проверяет. Причём проверяет на трёх уровнях:

- оракул — факт (slug, теги, письмо в Отправленных, текст в PDF); - аудит — полноту (всё ли, что просили, сделано); - оператор — неопределённость (что произошло, когда автоматика не может узнать).

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

Агент, который принимает результат сам, — это агент, который врёт с чистой совестью. Агент, который производит результат и отдаёт его на проверку коду и человеку, — это агент, которому можно доверять.

#ЭлисAI #ИИагенты #архитектура