Как проверить, что AI-агент действительно выполнил задачу

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

Содержание
Как проверить, что AI-агент действительно выполнил задачу

Вы поручили Claude Code, Codex или другому агенту переименовать файлы, обновить таблицу или создать записи в рабочей системе. Агент ответил «готово», а явной ошибки нет. Это означает лишь, что сеанс завершился без заметного сбоя; бизнес-результат всё ещё нужно принять отдельно.

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

Почему успешный вызов инструмента ещё не означает выполнение задачи

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

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

Публичный ThinkingBox-Bench v1.0 от Microsoft — синтетический исследовательский бенчмарк, а не статистика производственных инцидентов. В нём 507 исполняемых задач из пяти бизнес-доменов; попытка засчитывается только после проверок конечного состояния, побочных эффектов и заданных свойств диалога. В документации фиксированной версии указано, что частичного зачёта нет. Ниже «частично выполнено» и «не подтверждено» — это ваши операционные статусы приёмки, а не метрики бенчмарка.

До запуска составьте контракт приёмки

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

ЧтоЧто зафиксироватьПример
Обязательное состояниеОбъекты, поля, количество и связи120 файлов переименованы; в таблице 120 уникальных ID
Запрещённое состояниеИзменения, которых быть не должноИсходники не удалены; второе письмо не отправлено; другие листы не изменены
Источник истиныСистема, по данным которой принимается результатЦелевая папка, ячейки таблицы, CRM, статус заявки
Идентификатор повтораКлюч именно этой бизнес-операцииoperation_id или номер заказа в границах текущей задачи; ID клиента, имя файла, ID объекта и хэш манифеста обозначают объекты запроса и сами по себе не подтверждают эту операцию

Описывайте результат, а не действие агента. «Вызван инструмент обновления таблицы» — не конечное состояние. «На целевом листе 120 строк, ID уникальны, суммы совпадают с исходным манифестом» — конечное состояние.

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

Сохраните минимум доказательств выполнения

Чтобы связать один запуск с реальными изменениями, сохраните:

  • исходное задание, разрешённую область и ожидаемый результат;
  • время начала и окончания, рабочую папку и список целей;
  • ID сеанса агента и job ID, если инструмент его вернул;
  • operation_id или другой уникальный бизнес-ключ;
  • количество объектов, версии, важные поля или хэши до запуска;
  • явные ошибки, тайм-ауты, запреты доступа и пропущенные шаги.

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

Ждите конечного состояния системы, а не последней фразы агента

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

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

Перечитайте результат по шести уровням

1. Убедитесь, что объект существует и относится к этому запуску

Проверьте путь, имя, ID, время изменения и версию. Старый файл с тем же именем не доказывает успех. Новая запись, привязанная не к тому клиенту, тоже не подходит.

2. Проверьте содержимое и бизнес-инварианты

Сверьте количество, уникальность, суммы, обязательные поля, связи и формат. Для таблицы это ID, строки и итоги; для файлов — манифест, размеры, хэши или выборочная проверка; для записи — статус, сумма, владелец и временной диапазон.

3. Используйте авторитетную систему

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

4. Подтвердите все обязательные эффекты

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

5. Найдите то, чего быть не должно

Ищите дубли строк и записей, лишние письма, удалённые файлы, изменения вне области и запись не в тот объект. Неожиданный эффект нужно выделить отдельно: повтор может усилить ущерб.

6. Сверьте системы между собой

Для файлов, таблиц и бизнес-приложений сначала ограничьте запрос текущим operation_id или границами задачи, затем сверяйте ID клиента и объекта, требуемый статус или версию и манифест. Совпадение идентификатора объекта не доказывает, что выполнена именно эта операция. Сравните списки ID и выпишите отсутствующие и лишние элементы.

Используйте четыре операционных статуса

СтатусКогда ставитьЧто делать
ВыполненоВсе обязательные условия подтверждены, недопустимых лишних эффектов нетСохранить доказательства и закрыть задачу
Частично выполненоЧасть результата подтверждена, но есть конкретные пропускиИсправить только недостающее
Не подтвержденоСистема недоступна, результат ещё распространяется или доказательств недостаточноЗапросить данные или подождать; не повторять вслепую
Неожиданный эффектЕсть дубль, удаление, изменение вне области или запись не в тот объектОстановить автоматизацию и передать на проверку

«Не подтверждено» не равно «ошибка». Это означает, что вы пока не знаете результат.

Решайте вопрос повтора в правильном порядке

  1. Сначала найдите именно эту операцию. Ограничьте запрос в источнике истины operation_id или номером заказа, затем добавьте имя файла, ID клиента или объекта и требуемый статус либо версию. Само наличие объекта не подтверждает эту запись.
  2. Определите границу успеха. Составьте список уже созданных и отсутствующих объектов.
  3. Дополняйте идемпотентно. Если один ключ гарантированно не создаёт второй результат, отправляйте только пропуски. Если это неизвестно, не повторяйте необратимое действие автоматически.
  4. Отделяйте записи от уведомлений и транзакций. Если запись есть, а письмо не ушло, повторите только письмо. Если письмо ушло, а запись неясна, сначала запросите запись.
  5. Остановитесь при лишних эффектах. Сначала исправьте неверные объекты, затем человек решит, можно ли продолжать.

Короткое правило: повторяйте только после подтверждённого отсутствия записи; при частичной записи дополняйте пропуски; при неизвестном результате сначала спрашивайте; при неверной записи останавливайтесь.

Пример: файлы, таблица и CRM

Это условный сценарий, не реальный клиентский инцидент и не воспроизведённый производственный лог.

Агент должен переименовать 120 файлов, добавить 120 строк в таблицу, создать 12 сводных записей в CRM и отправить одно письмо. Проверка показывает: файлы и строки верны, в CRM только 9 записей, письмо уже отправлено.

Статус — «частично выполнено». Безопасное восстановление:

  • запросить CRM по operation_id и 12 ожидаемым бизнес-ключам;
  • определить 9 существующих записей и создать только 3 отсутствующие с ключами дедупликации;
  • сверить итоговые 12 CRM ID с файлами и таблицей;
  • не переименовывать файлы снова, не переписывать 120 строк и не отправлять второе письмо.

Если CRM нельзя запросить, статус остаётся «не подтверждено». Полный повтор в этот момент может создать дубли и второе уведомление.

Шаблон журнала приёмки

ПолеЧто записывать
Задача и областьЧто сделать, где можно менять и где нельзя
Ожидаемый результатОбъекты, поля, количество, связи и конечные статусы
ИдентификаторыID сеанса, job ID, operation_id, бизнес-ключи
Авторитетные данныеЦелевые объекты, время запроса, ID и ссылки
ПропускиОбязательные объекты или действия, которых нет
Лишние эффектыДубли, удаления, изменения вне области, лишние уведомления
Статус приёмкиВыполнено, частично, не подтверждено или неожиданный эффект
Следующий шагЗакрыть, ждать, дополнить, повторить, откатить или передать человеку

Приложите списки ID, разницу и время запроса. Формулировки «проверено» без данных недостаточно.

BetterToken даёт подключение модели, но не принимает бизнес-результат

Для подключения Claude Code через BetterToken используйте актуальную инструкцию по настройке и проверке соединения. Обычный ответ без ошибок соединения или модели подтверждает конфигурацию, но не доказывает, что файл, таблица или запись во внешней системе достигли нужного состояния.

Идентификаторы сеанса помогают найти конкретный запуск, однако приёмку проводите по целевым данным. Доступность модели, успешный ответ или расход токенов не являются доказательством бизнес-завершения.

Закройте задачу только после трёх вопросов

  1. Вижу ли я ожидаемое состояние в авторитетной системе, а не только в сообщении агента?
  2. Проверил ли я пропуски, дубли и другие неожиданные эффекты?
  3. Если результат неизвестен, могу ли я сначала запросить его по уникальному ключу?

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

Готовы оптимизировать LLM workflow?

Подключите единый API, управляйте ключами и контролируйте расходы на AI-модели в BetterToken.

Начать бесплатно