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 дозволяє розробникам обирати варіант, який підходить їхній ситуації, не нав’язуючи всім одну модель розгортання.

Запит на впровадження зводиться до питання, яке стосується будь-якого нового шару інфраструктури: чи усуває він роботу, якою ніхто не хотів займатися, та чи дозволяє команді залишатися повністю відповідальною за те, що визначає продукт?