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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если собрать все элементы воедино: Responses API обеспечивает оркестрацию, инструмент оболочки (shell tool) предоставляет исполняемые действия, размещаемый контейнер обеспечивает постоянный контекст среды выполнения, навыки добавляют логику многоразовых рабочих процессов, а компактность (compaction) позволяет агенту работать долгое время с необходимым ему контекстом.

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

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

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

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

Автор