API управляемых агентов OpenAI: хостинг в песочницах против самостоятельной обработки

Подготовительные этапы до создания агента

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

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

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

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

Что включает в себя управляемая инфраструктура

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

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

Выбор места работы агента

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

Рабочее пространство на хостинге

В первом варианте OpenAI создаёт полную рабочую среду Linux для каждой сессии и запускает её. Python, Node.js и распространённые утилиты командной строки предустановлены, что позволяет агенту выполнять код, работать с файлами и генерировать результаты, при этом разработчику не нужно управлять виртуальной машиной, образом контейнера или пайплайном развертывания. Результаты выполненных задач могут быть преобразованы в неизменяемые артефакты, что удобно для команд, желающих иметь постоянную, неизменяемую запись о том, что именно было произведено в ходе конкретной сессии.

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

"environment": {
  "type": "openai_hosted",
  "capability_directories": ["/workspace/capabilities/skills"]
}

Выполнение на собственном хостинге

Второй вариант предполагает выполнение кода на инфраструктуре, принадлежащей разработчику — будь то контейнер, виртуальная машина или удаленная среда от поставщика третьих сторон. Внутри этой среды находится компонент под названием сервер выполнения, который устанавливает соединение с OpenAI через WebSocket. Команды поступают от управляющего инструмента по этой ссылке, а сервер выполнения выполняет операции в оболочке и взаимодействует с локальным протоколом Model Context Protocol на машине разработчика, прежде чем отправить результаты обратно.

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

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

Что в любом случае остаётся у OpenAI

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

Длительные сессии и большие каталоги инструментов

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

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

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

В настройках перечислены инструменты в блоке агента, включая запись сервера MCP.

"agent": {
  "tools": [
    {
      "type": "mcp",
      "server_label": "internal_docs",
      "transport": {
        "type": "http",
        "server_url": "https://docs.example.com/mcp"
      }
    }
  ]
}

Несколько агентов над одной задачей

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

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

Чтобы включить эту функцию, достаточно установить соответствующий флаг в настройках агента наряду с выбором модели.

"agent": {
  "model": "gpt-6-astra",
  "multi_agent": {
    "enabled": true,
    "max_concurrent_subagents": 3
  }
}

Какой путь подходит для каждой команды

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

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

Кто должен подождать

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

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

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

Открытые основы

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

Цены и статус бета-версии

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

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

Вопрос о внедрении сводится к вопросу, актуальному для любого нового слоя инфраструктуры: устраняет ли он работу, которую никто не хотел брать на себя, и позволяет ли команде полностью контролировать то, что определяет продукт?