Агент закончил задачу. Почему completion ещё не доказывает результат

У AI-агента есть несколько разных способов «закончить работу». Он может вернуть ответ без тайм-аута, записать данные и пройти проверку схемы. Но ни один из этих сигналов сам по себе не означает, что пользователь получил нужный результат.

В агентной разработке полезно разделять как минимум три состояния:

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

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

Сначала проверяется завершённость

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

source_map: output/source_map.md system_context: output/system_context.md findings: output/findings.md task_pack: output/task_pack.md

Объект разбирается, названия полей правильные. Но файлов по этим путям может не существовать. Или вместо документа внутри поля будет фраза «материал будет добавлен позже». Формат соблюдён, а рабочего результата нет.

Поэтому до оценки качества нужен completion gate. Он отвечает на более простой вопрос: есть ли полный артефакт, который вообще можно оценивать?

Практическая последовательность выглядит так:

1. Запрос завершился без тайм-аута и падения процесса.
2. В ответе есть содержимое.
3. Структуру можно разобрать.
4. Обязательные поля соответствуют контракту.
5. Все обещанные документы действительно присутствуют.
6. Документы не состоят из путей, заглушек и пустых разделов.

Только после этого имеет смысл обсуждать качество требований или архитектуры.

Green проверяет не всё

Зелёный тест обычно означает соответствие заранее заданному сценарию. Это полезный сигнал, но он не отвечает на два других вопроса.

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

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

В TDPD эта граница выражается цепочкой:

источник или решение → правило → пользовательский сценарий → тест или ручная проверка → доказательство реализации → UAT.

Изменился источник или принятое решение — downstream-артефакты нужно пометить устаревшими. Старый Green нельзя автоматически переносить на новую постановку.

Не количество агентов, а покрытие свидетельств

Несколько агентов, которые по очереди пересказывают один и тот же контекст, не создают независимую проверку. Это может быть просто дорогой echo chamber.

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

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

Текстовый пересказ не заменяет исходный артефакт

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

Для проверяемого результата нужно сохранить:

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

Если требование звучит как «пользователь видит подтверждение сохранения», одного теста API недостаточно. Нужно проверить наблюдаемое состояние интерфейса. Если требование извлечено из видео, итоговая проверка должна уметь вернуться к исходному фрагменту, а не только к пересказу.

Автор результата не должен быть единственным судьёй

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

Перед UAT человек проверяет:

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

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

Как читать отчёт о запуске

Вместо одного процента полезно хранить отдельные причины:

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

Тогда понятно, что исправлять: среду, контракт, модель, проверку или саму постановку.

Completion gate не делает модель умнее. Он не даёт перепутать отсутствие результата с плохим результатом и формально правильный объект с завершённой работой.

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