Верификация ИИ-агентов: почему фраза «готово» не заменяет проверку состояния системы

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

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

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

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

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

Для начала агенту стоит оставить подготовку черновика и проверку его структуры. Следующим шагом может стать разрешение на конкретное изменение после подтверждения человеком. Более широкие действия следует обсуждать по наблюдаемым результатам узкого процесса. Как отмечают в Anthropic в документе Building Effective Agents, начинать нужно с простых решений, добавляя сложность по необходимости. В некоторых случаях часть операций может оказаться обычным скриптом, и наличие LLM не обязывает доверять ей каждое сложение. Перед выдачей расширенных доступов важно видеть не убедительное «готово», а скучное совпадение обещанного результата с фактическим состоянием системы.