От модели к агенту: Оснащение Responses API компьютерной средой

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

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

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

Responses API от OpenAI вместе с инструментом shell и рабочей областью хостируемого контейнера предназначен для решения этих практических задач. Модель предлагает шаги и команды, а платформа выполняет их в изолированной среде с файловой системой для входных и выходных данных, дополнительным структурированным хранилищем, например SQLite, и ограниченным доступом к сети.

В этом посте мы разберем, как мы создали компьютерную среду для агентов и поделимся первыми уроками о том, как использовать её для более быстрых, воспроизводимых и безопасных производственных процессов.

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

Чтобы понять инструмент shell, сначала полезно понять, как языковая модель в целом использует инструменты: например, чтобы вызывать функцию или взаимодействовать с компьютером. Во время обучения модели показывают примеры того, как используются инструменты и какие эффекты это дает, шаг за шагом. Это помогает модели научиться решать, когда использовать инструмент и как его использовать. Когда мы говорим «использование инструмента», мы имеем в виду, что модель на самом деле лишь предлагает вызов инструмента. Она не может выполнить вызов самостоятельно.

Инструмент shell делает модель значительно более мощной: он взаимодействует с компьютером через командную строку, чтобы выполнять широкий спектр задач — от поиска текста до отправки запросов API на вашем компьютере. Созданный на основе привычных Unix-инструментов, наш инструмент shell может делать все, что вы ожидаете, а такие утилиты, как grep, curl и awk, доступны сразу из коробки.

По сравнению с нашим существующим интерпретатором кода, который выполняет только Python, инструмент оболочки поддерживает гораздо более широкий спектр сценариев использования, например запуск программ на Go или Java или запуск сервера NodeJS. Эта гибкость позволяет модели выполнять сложные агентные задачи.

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

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

Когда Responses API получает промпт, он собирает контекст модели: промпт пользователя, состояние предыдущего диалога и инструкции для инструментов. Чтобы выполнение в shell работало, в промпте нужно упомянуть инструмент shell, и выбранная модель должна уметь предлагать команды shell — этому обучены модели GPT‑5.2 и новее. Получив весь этот контекст, модель решает, какое действие сделать следующим. Если она выбирает выполнение в shell, то возвращает сервису Responses API одну или несколько команд shell. Сервис API отправляет эти команды в среду выполнения контейнера, получает поток вывода shell и передаёт его модели в контексте следующего запроса. После этого модель может проверить результаты, выдать дополнительные команды или сформировать окончательный ответ. Responses API повторяет этот цикл, пока модель не вернёт завершение без новых команд shell.

Когда Responses API выполняет команду shell, он поддерживает потоковое соединение со службой контейнеров. По мере формирования вывода API передает его модели почти в реальном времени, чтобы модель могла решить, ждать ли дальнейшего вывода, выполнить еще одну команду или перейти к окончательному ответу.

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

Когда команда включает операции с файлами или обработку данных, вывод shell может стать очень большим и расходовать бюджеты контекста, не добавляя полезных сигналов. Чтобы этого избежать, модель задаёт лимит вывода для каждой команды. Responses API обеспечивает соблюдение этого ограничения и возвращает ограниченный результат, который сохраняет как начало, так и конец вывода, при этом помечая пропущенное содержимое. Например, вывод можно ограничить 1 000 символами, сохранив начало и конец:

текст в начале ... 1000 символов усечено ... текст в конце

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

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

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

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

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

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

Первая часть контекста контейнера — это файловая система для загрузки, организации и управления ресурсами. Мы создали API контейнера и файлов⁠(открывается в новом окне), чтобы дать модели карту доступных данных и помочь ей выбирать целевые операции с файлами вместо выполнения широких, шумных сканирований.

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

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

Например, если вы спросите: «У каких товаров в этом квартале снизились продажи?», модель может запросить только релевантные строки вместо того, чтобы сканировать всю таблицу. Это быстрее, дешевле и лучше масштабируется для более крупных наборов данных.

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

Чтобы решить эти проблемы, не ограничивая полезность агентов, мы создали размещенные контейнеры, использующие sidecar-прокси для исходящего трафика. Все исходящие сетевые запросы проходят через централизованный слой политик, который применяет списки разрешений и контроль доступа, сохраняя при этом наблюдаемость трафика. Для учётных данных мы используем внедрение секретов на уровне egress с привязкой к домену. Модель и контейнер видят только заполнители, а реальные значения секретов остаются вне доступного модели контекста и подставляются только для разрешённых адресов назначения. Это снижает риск утечки данных, при этом по-прежнему позволяя выполнять аутентифицированные внешние вызовы.

Команды shell — мощный инструмент, но многие задачи повторяют одни и те же многошаговые паттерны. Агентам приходится заново восстанавливать рабочий процесс при каждом запуске — перепланировать, повторно отдавать команды и заново осваивать соглашения — что приводит к непоследовательным результатам и напрасным затратам на выполнение. Навыки агента⁠(открывается в новом окне) упаковывают эти паттерны в многоразовые и комбинируемые блоки. Конкретно, навык — это комплект папок, который включает «SKILL.md⁠(открывается в новом окне)» (содержащий метаданные и инструкции), а также любые вспомогательные ресурсы, такие как спецификации API и ресурсы UI.

Эта структура естественным образом соответствует архитектуре среды выполнения, которую мы описали ранее. Контейнер даёт постоянное файловое пространство и контекст выполнения, а инструмент shell — интерфейс для исполнения команд. Благодаря этому модель может при необходимости находить файлы навыков с помощью команд shell (\ls`, `cat` и т. д.), интерпретировать инструкции и запускать скрипты навыков — всё в рамках одного агентного цикла.

Мы предоставляем API⁠(открывается в новом окне) для управления навыками на платформе OpenAI. Разработчики загружают и хранят папки навыков в виде версионированных пакетов, которые позже можно получить по идентификатору навыка. Перед отправкой промпта в модель Responses API загружает навык и включает его в контекст модели. Эта последовательность детерминированная:

1. Получить метаданные навыка, включая имя и описание.
2. Получить пакет навыка, скопировать его в контейнер и распаковать.
3. Обновите контекст модели, добавив метаданные навыков и путь к контейнеру.

При определении релевантности навыка модель постепенно изучает его инструкции и выполняет его скрипты с помощью команд shell в контейнере.

Чтобы собрать все части воедино: Responses API обеспечивает оркестрацию, shell — обеспечивает исполняемые действия, хостируемый контейнер — постоянный контекст среды выполнения, навыки добавляют многоразовую логику рабочих процессов, а сжатие контекста позволяет агенту работать долгое время с нужным ему контекстом.

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

Диаграмма ниже показывает, как эта система работает при создании таблицы из данных в реальном времени.

Чтобы ознакомиться с подробным примером объединения инструмента shell и компьютерной среды для сквозных рабочих процессов полного цикла, см. нашу публикацию в блоге для разработчиков⁠(открывается в новом окне) и руководство⁠(открывается в новом окне), где пошагово показано, как упаковать навык и выполнить его через API Responses.

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