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

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

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

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

Важно: 6 сентября 2026 года OpenAI сообщила о достижении внутреннего этапа, который компания определяет как «автоматический исследовательский стажёр». Речь идёт о задачах, заданных человеком и сформулированных достаточно чётко; сложные исследования по-прежнему требуют человеческого руководства. Это не доказательство полностью автономной науки и не публичная гарантия успешности каждого запуска. Исходное описание OpenAI и границ измерения.

Последняя проверка: 8 сентября 2026 года. Факты сверены с публикацией OpenAI, материалами Codex и документацией GitHub по подтверждению происхождения артефактов.

Сначала отделите выполненную задачу от принятого результата

Главная ошибка при оценке исследовательского Agent — считать завершение задания доказательством правильности вывода. Эти события относятся к разным уровням:

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

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

Пять ворот приёмки

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

Шаг первый: заморозьте границы до запуска

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

Перед запуском сохраните отдельный файл задания или неизменяемую запись со следующими полями:

1. исследовательский вопрос;
2. версия исходного кода и точка входа;
3. точный набор данных и его контрольная сумма;
4. допустимые модели, параметры и методы оценки;
5. критерий успеха и минимальный набор отрицательных проверок;
6. запрещённые действия — например, изменение тестовой выборки или публикация результата;
7. формат ожидаемых артефактов;
8. условия остановки и человек, который может их изменить.

Не принимайте критическое условие, которое существует только в истории диалога. Если Agent должен «использовать последний набор данных», в задаче должна быть указана конкретная версия или способ разрешения версии. Если критерий успеха можно понять по-разному, запуск нужно остановить до уточнения.

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

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

Шаг второй: отделите исследовательскую среду от среды доказательства

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

Для каждого эксперимента заведите как минимум два режима:

В журнале укажите:

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

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

Если эксперимент использует Xcode, macOS-инструменты или графическое приложение, чистая среда должна быть отдельным Mac-окружением. Повторное открытие той же рабочей области не доказывает, что проект собирается на машине без локальных сертификатов, DerivedData, пользовательских плагинов и ранее запущенных сервисов. В этом случае полезно заранее подготовить профиль восстановления, но не подключать его автоматически к независимому запуску.

Что экономит время, а что создаёт риск

Плюсы общей рабочей области:

• быстрее исправляются ошибки;
• кэш ускоряет повторные сборки;
• Agent видит историю предыдущих попыток.

Минусы общей рабочей области:

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

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

Шаг третий: проведите независимую перепроверку

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

Организуйте процесс так:

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

Должны ли вы вручную проверять код, созданный Codex? Да, если код влияет на выбор данных, расчёт метрики, генерацию отчёта или управление ресурсами. Ревью не обязано построчно анализировать каждую вспомогательную функцию, но должно охватить точки, где Agent может незаметно изменить эксперимент: фильтрацию выборки, обработку пропусков, seed, порядок вычислений, обработку исключений и правила остановки.

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

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

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

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

Минимальная схема может выглядеть так:

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

Для критичных сборок можно использовать подтверждение происхождения артефактов. Документация GitHub описывает Artifact Attestations как механизм, который связывает созданный артефакт с процессом сборки и позволяет проверять его происхождение. Концепция Artifact Attestations и руководство по созданию подтверждений полезны для настройки цепочки поставки.

Однако attestation отвечает на вопрос «откуда взялся этот файл», а не на вопросы «правильно ли поставлен эксперимент» и «верно ли истолкована метрика». Подтверждённый артефакт может быть результатом неверной гипотезы или ошибочного теста.

Шаг пятый: разберите вмешательства человека

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

Разнесите действия по трём классам:

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

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

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

Шаг шестой: примите решение по трём уровням

Сведите результаты в короткий протокол, который может проверить человек, не участвовавший в запуске.

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

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

Перед расширением проверьте:

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

Если вам нужно сначала проверить такой процесс на одной воспроизводимой задаче, начните с руководства по изолированной среде для исследовательского Agent, а затем сопоставьте его с описанием доступных вариантов аренды вычислительной среды. Для Mac-пайплайна заранее проверьте ограничения восстановления и доступные способы подключения через раздел помощи kvmsync.

Что выбрать для первого пилота

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

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

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

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