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

Вы поручили 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 и выпишите отсутствующие и лишние элементы.
Используйте четыре операционных статуса
| Статус | Когда ставить | Что делать |
|---|---|---|
| Выполнено | Все обязательные условия подтверждены, недопустимых лишних эффектов нет | Сохранить доказательства и закрыть задачу |
| Частично выполнено | Часть результата подтверждена, но есть конкретные пропуски | Исправить только недостающее |
| Не подтверждено | Система недоступна, результат ещё распространяется или доказательств недостаточно | Запросить данные или подождать; не повторять вслепую |
| Неожиданный эффект | Есть дубль, удаление, изменение вне области или запись не в тот объект | Остановить автоматизацию и передать на проверку |
«Не подтверждено» не равно «ошибка». Это означает, что вы пока не знаете результат.
Решайте вопрос повтора в правильном порядке
- Сначала найдите именно эту операцию. Ограничьте запрос в источнике истины
operation_idили номером заказа, затем добавьте имя файла, ID клиента или объекта и требуемый статус либо версию. Само наличие объекта не подтверждает эту запись. - Определите границу успеха. Составьте список уже созданных и отсутствующих объектов.
- Дополняйте идемпотентно. Если один ключ гарантированно не создаёт второй результат, отправляйте только пропуски. Если это неизвестно, не повторяйте необратимое действие автоматически.
- Отделяйте записи от уведомлений и транзакций. Если запись есть, а письмо не ушло, повторите только письмо. Если письмо ушло, а запись неясна, сначала запросите запись.
- Остановитесь при лишних эффектах. Сначала исправьте неверные объекты, затем человек решит, можно ли продолжать.
Короткое правило: повторяйте только после подтверждённого отсутствия записи; при частичной записи дополняйте пропуски; при неизвестном результате сначала спрашивайте; при неверной записи останавливайтесь.
Пример: файлы, таблица и 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 используйте актуальную инструкцию по настройке и проверке соединения. Обычный ответ без ошибок соединения или модели подтверждает конфигурацию, но не доказывает, что файл, таблица или запись во внешней системе достигли нужного состояния.
Идентификаторы сеанса помогают найти конкретный запуск, однако приёмку проводите по целевым данным. Доступность модели, успешный ответ или расход токенов не являются доказательством бизнес-завершения.
Закройте задачу только после трёх вопросов
- Вижу ли я ожидаемое состояние в авторитетной системе, а не только в сообщении агента?
- Проверил ли я пропуски, дубли и другие неожиданные эффекты?
- Если результат неизвестен, могу ли я сначала запросить его по уникальному ключу?
Закрывайте задачу, когда все ответы ясны. Перед следующим важным запуском скопируйте шаблон выше и заполните конечное состояние, запреты и ключ повтора. Это обычно дешевле, чем разбирать дублированную операцию постфактум.