Автор Habr предлагает приёмку для AI-агентов: «готово» требует доказательств

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

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

Почему «готово» ничего не доказывает

Ассистент выдаёт текст, человек его читает и решает, что с ним делать. Контрольная точка встроена в процесс. Агент действует сам: пишет в CRM, правит таблицы, запускает скрипты, отправляет письма. Его отчёт «задача выполнена» остаётся таким же сгенерированным текстом, как и любой другой ответ модели. Он может совпадать с состоянием системы, а может нет.

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

Приёмка вместо доверия

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

В инженерной практике обычно выделяют три уровня такой проверки:

• результат: целевое состояние достигнуто, и это видно в самой системе;
• границы: сравнение состояния до и после показывает только запланированные изменения;
• след: журнал действий агента позволяет восстановить, что именно он делал и в каком порядке.

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

Какие метрики стоит считать

Пока приёмка не измеряется, обсуждение остаётся на уровне ощущений. Минимальный набор показателей для команды, которая запускает агента в рабочий процесс:

• доля ложных «готово»: задачи, объявленные закрытыми, но не прошедшие проверку;
• доля задач, принятых без правок человека;
• время человека на проверку одной задачи;
• доля задач, для которых проверка автоматизирована;
• число откатов изменений за период.

Важно смотреть на связку этих цифр. Если агент закрывает много задач, но время на ручную перепроверку растёт, экономия фиктивна.

С чего начать на практике

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

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

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

Идея автора Habr сводится к простому правилу: агент получает право говорить «готово» только вместе с доказательством. Для рынка, где агентов массово пускают в рабочие процессы, это здравый и недорогой стандарт.