Как вручную перехватывать автоматического исследовательского стажёра OpenAI? Руководство по развёртыванию 2026

Симптом → самое быстрое решение

Agent может непрерывно работать несколько часов, но успешное выполнение сложного исследования всё равно может потребовать ручного вмешательства. Для ручного перехвата автоматического исследовательского стажёра OpenAI не нужно следить за каждой строкой работы и нельзя отправлять все действия в одну общую очередь approvals: разделите операции на чтение, обратимые изменения и опасные внешние действия, ставьте паузу перед критическими вызовами, сохраняйте состояние в постоянном хранилище и продолжайте выполнение только внутри изолированной рабочей области.

Этот материал подходит вам, если вы:

• запускаете Codex для длительных экспериментов, анализа данных или изменения кода;
• строите платформу Agent-задач и хотите сделать согласование передаваемым и восстанавливаемым;
• подключаете macOS, Xcode, настольные инструменты или удалённый Mac к исследовательскому контуру.

Последнее обновление — 8 сентября 2026 года. Дата и формулировки о ручном сопровождении проверены по исследовательскому материалу OpenAI от 6 сентября 2026 года, а поведение SDK — по актуальной документации OpenAI Agents SDK для human-in-the-loop.

До запуска: разделите полномочия, а не людей

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

Разложите каждую исследовательскую задачу на пять независимых типов действий:

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

Затем присвойте каждому инструменту один из трёх уровней:

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

Это важное различие между модельным выводом и фактическим действием Agent. Хороший текстовый план не доказывает, что вызов безопасен; именно инструментальный вызов должен попасть под контроль.

Первый этап: сделайте остановку постоянной

Для реализации паузы можно использовать OpenAI Agents SDK: его документация описывает human-in-the-loop, прерывание выполнения и сериализацию состояния через RunState. Это инженерная основа, а не официальная универсальная архитектура «автоматического исследовательского стажёра» для всех организаций. Описание interruption и approvals в SDK проверяйте вместе с документацией RunState, поскольку имена полей и примеры могут меняться.

В состояние задачи включите:

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

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

Сохраняйте это состояние в базе приложения или постоянной очереди. Терминал исследователя и история чата не подходят: закрытие ноутбука, перезапуск процесса или передача задачи другому оператору не должны уничтожать очередь согласований. API-ключи, токены репозитория, пароли и временные полномочия не помещайте в RunState. Перед сохранением заменяйте их ссылками на секретное хранилище, а при восстановлении выдавайте минимально необходимые права заново.

Официальные материалы SDK отдельно описывают контекст выполнения и результаты запуска — полезно не смешивать их с долговременным состоянием задачи: контекст Agent и результаты выполнения.

Пилот: проверяйте три исхода одной и той же паузы

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

Проведите проверку в таком порядке:

1. Запустите Agent с инструментом, который требует согласования, и убедитесь, что побочный вызов не произошёл до решения.
2. Разрешите операцию, зафиксируйте имя инструмента, хэш или версию рабочей области и фактический результат.
3. Повторите запуск и отклоните тот же вызов.
4. Убедитесь, что задача завершается безопасно либо строит новый план без повторной отправки запрещённой операции.
5. Оставьте запрос без ответа, перезапустите процесс и проверьте, что он остаётся в очереди.
6. Передайте задачу другому уполномоченному оператору и сравните восстановленный контекст с исходным.

Отклонение нельзя трактовать как обычную сетевую ошибку. Если код автоматически повторяет вызов после отказа, Agent способен превратить одно решение человека в бесконечный цикл попыток. После отказа выбирайте одну из двух ветвей: безопасное завершение с объяснимым статусом или новая генерация плана с явно изменённым набором разрешённых действий.

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

Первый день: свяжите очередь с рабочей областью

Человек должен одобрять не абстрактное сообщение «Agent хочет продолжить исследование», а конкретную операцию в конкретной среде. В карточке запроса покажите:

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

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

Для обычного анализа подойдёт одноразовая изолированная рабочая область. Задания, которым нужны macOS, Xcode или настольный интерфейс, помещайте в отдельный пул удалённых Mac. Это не означает, что каждый вызов должен требовать ручного подключения к экрану. Сначала проверяйте параметры через очередь; интерактивное подключение используйте только для диагностики, подтверждения состояния среды или действий, которые нельзя надёжно представить API-вызовом.

Если вам нужно оценить, подходит ли именно удалённая macOS-среда для Agent-задач, сопоставьте этот процесс с руководством по запуску Mac mini для AI Agent. Для задач с Docker отдельно проверьте совместимость Mac mini и Docker, потому что изоляция процесса не равна изоляции всей операционной среды.

Не выдавайте решение одной среде другой. Согласование для контейнера не должно автоматически разрешать действие на удалённом Mac, даже если Agent считает их взаимозаменяемыми.

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

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

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

Если процесс Agent перезапустился, порядок восстановления должен быть таким:

1. Прочитать постоянную запись задачи и убедиться, что она действительно ожидает решения.
2. Проверить, что ожидающий вызов ещё существует и не был выполнен до сбоя.
3. Сверить модель, инструкции, схему инструмента и версию входных данных.
4. Проверить наличие рабочей области, репозитория и требуемых полномочий.
5. Если среда не изменилась, восстановить RunState и продолжить с согласованного вызова.
6. Если обнаружено расхождение, не переиспользовать старое решение: остановить задачу, построить новый план и запросить согласование заново.

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

Полезно заранее измерять не «интеллект Agent», а качество контура управления: сколько запросов ждут согласования, сколько отклоняются, сколько восстанавливаются после перезапуска и сколько требуют ручного подключения к среде. Эти показатели помогают решить, где допустимо правило автоматического разрешения, а где нужен человек.

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

После пилота соберите журнал по типам задач. Для каждого запуска фиксируйте причину вмешательства, время ожидания, результат отказа, повторные побочные эффекты, состояние рабочей области и итог независимой проверки. Не переносите внутренние показатели OpenAI напрямую на собственную команду: исследовательская методика OpenAI отвечает на другой вопрос и не заменяет ваши журналы.

Перед расширением параллелизма отметьте каждый пункт:

• [ ] Для каждого инструмента назначен уровень: автоматический, условно согласуемый или требующий обязательного одобрения.
• [ ] Ожидающий вызов сохраняется вне терминала и чата.
• [ ] В состоянии нет API-ключей, токенов и паролей.
• [ ] После перезапуска процесса задача восстанавливается в том же статусе.
• [ ] Оператор видит хост, репозиторий, версию и область записи.
• [ ] Отклонённая операция не повторяется бесконечно.
• [ ] Для нескольких Codex-задач назначены владелец и резервный согласующий.
• [ ] При изменении модели, схемы или рабочей области старое решение аннулируется.
• [ ] Задания macOS и Xcode выполняются в изолированной среде.
• [ ] Финальный результат проверяется независимо от текста, сгенерированного Agent.

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

В итоге у вас должно быть три понятных режима. Ручной режим подходит для внешних записей и нестабильных инструментов. Правила автоматического согласования оправданы для повторяемых обратимых операций с узким диапазоном параметров. Отдельный удалённый пул нужен тогда, когда рабочее окружение само является частью риска — например, при доступе к macOS-инструментам, Xcode или графическим приложениям.

Что выбрать: текущая машина или облачный Mac

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

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

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

Главный недостаток текущего подхода «одна разработческая машина плюс ручное наблюдение» — отсутствие независимой среды, слабая передаваемость задачи и высокий риск продолжить работу с устаревшей версией решения. В таких условиях аренда Mac у MacPull может дать более управляемый опыт: вы отделяете исследовательскую рабочую область от основной машины и можете заранее привязать её к процедуре паузы, согласования, восстановления и очистки. Но для постоянной тяжёлой нагрузки или требований к физическим интерфейсам собственный Mac всё ещё может оказаться рациональнее.

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