Как проверить реальную работу ИИ-агента

Проблема рабочих AI-агентов не в странных ответах, а в убедительном «готово», после которого сотрудникам приходится перепроверять и переделывать работу. Ассистенту, предлагающему формулировки, можно простить неудачный абзац, но агенту, который изменяет рабочие данные, этого недостаточно. Автор материала на Хабре предлагает обсудить приёмку результатов: что именно должно произойти, чтобы задачу можно было считать закрытой.

В качестве примера рассматривается вымышленный сценарий: после встречи агент получает поручение обновить еженедельный отчёт по заявкам. Формулировка «обнови отчёт за неделю» подходит для созвона, но не для теста, поскольку остаётся множество неясностей: какая неделя, часовой пояс, файл, можно ли менять оригинал, какие заявки учитывать и кто принимает результат. Автор подчёркивает, что это учебный пример, а не описание внутренней системы Яндекса.

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

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

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

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

Для сравнения версий необходимо сохранять настройки модели и инструментов, входные данные и условия окружения, иначе после смены промпта легко сравнить две разные задачи и объявить прогресс. Повторять сценарии тоже полезно: один удачный прогон не показывает устойчивость. Число повторов выбирается под цену ошибки и бюджет. Например, если агент аккуратно оформил девять черновиков и один раз отправил документ не тому адресату, средняя успешность может выглядеть прилично, но решение о расширении доступа — уже нет.

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

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