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