В этом разборе
Сигнал завершения сервиса и принятый артефакт отвечают на разные вопросы и должны проверяться отдельно.
Управляемый агент может закончить выполнение, когда запрошенный результат ещё непригоден для использования. Бета Agents API сделала границу важнее: прогресс исполнения и оценка задачи теперь проходят через API. Приложению нужен объект проверки, существующий независимо от итогового сообщения агента и его собственного описания сделанной работы.
У запуска была история артефактов
Анонс Codex от 16 мая 2025 года связывал облачную работу с проверяемыми изменениями программ. Примитивы от 11 февраля 2026 года поддерживали выполнение и создаваемые результаты. Бета Agents API от 10 сентября 2026 года упаковала управляемый harness для разработчиков. Последовательность объясняет, почему исход сервиса и принятый прикладной артефакт должны оставаться отдельными объектами.
Что именно получает адресат
Представим иллюстративную инвентаризацию конфигурационных файлов репозитория. Заказчику нужна таблица связи каждого сервиса с действующей конфигурацией и открытыми исключениями. Убедительный абзац о просмотре репозитория не является этим результатом, даже если звучит полно и перечисляет выполненные действия.
Артефакт приёмки должен сохранять идентичность источника, охваченный объём и конкретный вывод. Для этого не обязателен большой отчёт. Компактная таблица достаточна, если другой проверяющий видит пропуски и способен связать спорную строку с изученным файлом. Размер документа не заменяет возможность восстановить основание каждого значимого заключения.
Сигнал завершения отвечает на узкий вопрос
Завершение на уровне сервиса может означать, что выполнение достигло некоторого исхода. Оно не устанавливает полноту частной инвентаризации приложения и правильность каждого выведенного отношения. Эти свойства зависят от доказательств конкретной задачи, которые сервис не способен определить только по факту окончания работы.
Состояние сервиса нужно сохранить как вход для приёмки. Его нельзя отбрасывать, но оно не заменяет проверки содержания. Частичный список полезен при явных пропусках; список, выглядящий полным и скрывающий пробелы, представляет другой продуктовый исход. Эти варианты должны различаться до передачи результата следующему участнику процесса.
Сценарий с намеренным исключением
Подготовим маленький репозиторий со стандартной конфигурацией и необычной генерируемой конфигурацией. Определим ожидаемое покрытие до запуска. Попросим агента создать инвентаризацию, затем проверим наличие особого пути либо явного указания на нерешённость. Исключение не должно незаметно исчезать из предполагаемой области исследования.
Свяжем выбранные строки с исходными файлами. Проверим, ведёт ли итоговое сообщение к действительному артефакту, а не пересказывает ранний черновик. Сценарий проверяет покрытие и происхождение, отделяя отсутствующий файл от неправильной интерпретации доступного. Такая разница помогает исправить нужную стадию, а не повторять весь запуск без понимания причины.
Приёмка вне самоописания
Объяснение агента помогает найти доказательства, но не может независимо заверить собственную работу. Нужно сохранить критерии и набор источников, чтобы последующие обновления модели или harness проверялись относительно прежнего требования. Иначе новая убедительная сводка способна незаметно изменить само определение полноты задачи.
Ретроспективный урок состоит в том, что управляемое выполнение повышает ценность конкретной передачи результата. Принятый артефакт связывает активность сервиса с намерением пользователя, не приписывая завершённому запуску гарантию полезной работы. При этом история выполнения остаётся доступной для диагностики, а содержательная приёмка сохраняет собственное независимое основание.