Що OpenAI Agents API змінює у створенні довготривалих агентів

Приблизно останній рік створення ШІ-агента означало, що всю його «сантехніку» ви будуєте самі. Треба було вирішити, як він пам’ятає контекст, викликає інструменти, запускає код, відновлюється після збоїв, спілкується з іншими агентами й витримує довгі завдання, не переповнивши контекстне вікно. І десь по дорозі треба було не дати всьому цьому перетворитися на дорогу купу промптів, зчеплених ланцюжком.

Це починає змінюватися. 10 вересня OpenAI запустила Agents API в публічній беті. Він дає розробникам версію обв’язки та інфраструктури, на якій уже працює Codex. Ви описуєте агента, даєте йому інструменти й середовище виконання, а керована обв’язка бере на себе більшу частину операційної роботи. Це передусім не анонс моделі. Це анонс інфраструктури, і для інженерів ця різниця важлива.

Що змінилося на практиці

Почнімо зі звичайного LLM-застосунку. Користувач надсилає ввід, промпт іде в модель, відповідь повертається:

User
  ↓
Prompt
  ↓
LLM
  ↓
Response

Потім ви додаєте інструменти, щоб модель могла вирішити викликати один із них, а застосунок повернув їй результат:

User
  ↓
LLM
  ↓
Tool
  ↓
LLM
  ↓
Response

А далі вимоги й надалі ростуть. Тепер модель має читати репозиторій і правити його файли, виконувати команди, шукати інформацію в документації, викликати API, пам’ятати події багатогодинної давнини, роздавати підзавдання помічникам, повторювати те, що зламалося, перевіряти власний результат і залишати по собі артефакти. Ваша «проста ШІ-фіча» непомітно перетворилася на систему оркестрації — саме ту проблему, на яку націлений Agents API. Логіка OpenAI така: агенту, що має працювати довго, потрібна обв’язка під ним — щось, що керує контекстом, робить використання інструментів дешевим, координує субагентів і зберігає надійність упродовж довгої сесії. Ви задаєте мету, а OpenAI постачає значну частину механізму.

Модель і середовище виконання

Найпростіше зрозуміти цю зміну, якщо розділити модель і середовище виконання. Модель дає інтелект. Обв’язка дає середовище, у якому цей інтелект може працювати. Спрощена картина:

Your Application
                       │
                       ▼
                ┌─────────────┐
                │ Agents API  │
                └──────┬──────┘
                       │
              ┌────────┴────────┐
              │                 │
        Agent Harness       Model
              │                 │
       ┌──────┼──────┐          │
       │      │      │          │
    Tools  Context  Agents      │
       │      │      │          │
       └──────┼──────┘          │
              │                 │
              ▼                 ▼
          Execution         Reasoning
          Environment

Це інша абстракція, ніж виклик LLM API. Ви більше не просите в моделі текст. Ви даєте автономному програмному процесу місце для роботи.

Справжній робочий простір для агента

Одна з найважливіших частин — ви самі обираєте, де працює агент. Це може бути пісочниця під керуванням OpenAI, ваша власна інфраструктура або підтримувані сторонні середовища, і середовище може надати файли, пакети, навички й плагіни, потрібні агенту.

Це важливо, бо розробка ПЗ не відбувається всередині промпта. Агенту для коду потрібне щось ближче до теки проєкту:

/workspace
   ├── src/
   ├── tests/
   ├── package.json
   ├── node_modules/
   ├── config/
   └── outputs/

Йому треба оглянути проєкт, змінити файли, запустити тести, прочитати вивід, виправити падіння й знову запустити тести. Середовище стає частиною архітектури агента.

Найцікавіше — обв’язка

У прикладі OpenAI використано GPT-6 Astra, але головна ідея — структура довкола моделі. Ви налаштовуєте агента через модель, інструменти, середовище та мультиагентну поведінку. Концептуально це починається так:

const agent = {
  model: "gpt-6-astra",

і продовжується списком інструментів:

  tools: [
    "MCP",
    "web search",
    "custom functions"
  ],  multiAgent: {
    enabled: true,
    maxConcurrentSubagents: 3
  },  environment: {
    type: "sandbox"
  }
};

Абстракцію варто запам’ятати у вигляді одного рівняння:

Agent = Model + Tools + Context + Environment + Orchestration

Це набагато ближче до того, як насправді збирається продакшен-софт.

Довготривалі агенти — це інше завдання

Чат-боту може знадобитися відповісти за п’ять секунд, агенту для коду — за п’ять хвилин, дослідницькому агенту — за годину, а операційний агент може спостерігати й розслідувати щось значно довше. Зі зростанням часу роботи інженерні вимоги різко змінюються.

OpenAI каже, що в Agents API вбудовано керування контекстом для довгих сесій. Коли сесія наближається до межі контексту, система може стиснути раніший матеріал, щоб агент працював далі впродовж кількох контекстних вікон. Це суттєво, бо керування контекстом непомітно стало одним із головних інженерних болів агентних систем.

Уявіть агента, який розбирається з інцидентом у продакшені. Спершу він бачить один симптом:

Service API is returning 5xx errors.

Потім крок за кроком збирає докази:

logs
↓
deployment history
↓
database metrics
↓
dependency changes
↓
Git commits
↓
error traces
↓
test results

Після сотень викликів інструментів сирий контекст стає величезним. Якщо агент просто забуде початок розслідування, він може повторювати роботу або ухвалити хибне рішення. Довготривалим агентам потрібне щось на кшталт керування станом у розподілених системах, і вбудоване в обв’язку стиснення показує, наскільки центральною стала ця проблема.

Виклик інструментів стає інфраструктурою

Потужний агент може мати десятки чи навіть сотні інструментів. Завантажувати опис кожного інструмента в кожен запит — означає марнувати контекст і підвищувати вартість. OpenAI каже, що Agents API має пошук інструментів, тож потрібні описи підвантажуються лише за потреби. Підтримується й програмний виклик інструментів: агент виконує кілька операцій паралельно й обробляє результати, перш ніж повернути в контекст моделі лише релевантну інформацію.

Звучить як дрібна оптимізація, але це не так. Візьмімо агента розробника, який має доступ до таких систем:

GitHub
PostgreSQL
Sentry
Jira
Slack
AWS
Docker
Browser
Filesystem
CI/CD
Documentation
Monitoring

Щоразу віддавати моделі всі описи неефективно. Розумніший потік з’ясовує, яка можливість потрібна завданню, і завантажує лише її:

User task
    ↓
Determine required capability
    ↓
Load relevant tools
    ↓
Execute operations
    ↓
Filter results
    ↓
Return useful context to model

По суті це динамічне завантаження залежностей для агентів.

Субагенти змінюють модель програмування

API також підтримує субагентів. Замість одного агента, що проходить усе послідовно, головний агент ділить роботу на незалежні завдання:

Main Agent
                    │
          ┌─────────┼─────────┐
          │         │         │
          ▼         ▼         ▼
       Logs       Code      Database
      Agent       Agent      Agent
          │         │         │
          └─────────┼─────────┘
                    ▼
              Main Agent
                    │
                    ▼
              Final Analysis

Це пасує незалежній роботі. Інциденту в продакшені може знадобитися один агент, що перевіряє недавні деплої, другий — що аналізує помилки застосунку, і третій — що дивиться на продуктивність бази даних, а головний агент зводить знахідки докупи. OpenAI каже, що API підтримує кількох одночасних субагентів, кожен зі своїм контекстом, тож робота йде паралельно. Це значно більше схоже на розподілені обчислення, ніж на класичний промпт-інжиніринг.

Більше агентів — не означає автоматично краще

Є спокуса зібрати щось таке й вирішити, що система стала розумнішою:

1 main agent
+ 10 subagents
+ 20 tools
+ 5 review agents

З тим самим успіхом вона може стати повільнішою, дорожчою й складнішою в налагодженні. Правильне питання не в тому, скільки агентів ви можете запустити. А в тому, які частини завдання справді незалежні. Якщо три завдання справді можуть іти паралельно, субагенти мають сенс. Якщо кожен крок залежить від попереднього, розпаралелювання лише додає складності.

Проєктування агентів перетворюється на ще одну форму архітектури ПЗ, де в грі залежності, конкурентність, стан, повтори, спостережуваність, відновлення після збоїв, вартість, права доступу та межі даних. Модель — лише один компонент.

MCP у цій схемі

Agents API підтримує й MCP, тож агент може отримувати зовнішні можливості через MCP-сервери, а не тримати кожну інтеграцію зашитою в застосунку:

Agent
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
       MCP           MCP           MCP
    GitHub Server  Database      Observability
        │             │             │
        ▼             ▼             ▼
     Repository      Data          Metrics

Виходить модульніше. Агенту не потрібно знати, як усередині влаштовані GitHub, ваша база даних чи система моніторингу. Йому треба знати, яка можливість існує і як нею користуватися, — та сама абстракція, яку інженери будують десятиліттями.

Пісочниця входить у вашу модель безпеки

Щойно агенти запускають код, чіпають файли й взаємодіють із зовнішніми системами, середовище виконання стає межею безпеки. Недавні інциденти зробили це нагальним: цього тижня Anthropic повідомила ще про один тест кібербезпеки, що пішов не за планом, — прототип Claude дістався до зовнішніх систем, до яких не мав би. Паралельно OpenAI опинилася під пильною увагою через неочікувану поведінку агентів.

Тому думка «модель безпечна, отже, і мій агент безпечний» — хибна. Справжня поверхня атаки — це поєднання:

Model
  +
Instructions
  +
Tools
  +
Credentials
  +
Filesystem
  +
Network
  +
Execution environment

Агент із доступом до бази лише на читання — зовсім інша система з погляду безпеки, ніж агент, який має ось це:

database write access
+
shell execution
+
internet access
+
production credentials

API спрощує створення агентів, а отже, розробникам доведеться значно краще навчитися визначати, чого агент робити не може.

Новий шар у стеку

Роками застосунки будувалися як фронтенд поверх бекенду:

Frontend
   ↓
Backend
   ↓
Database

Потім у середину додали ШІ:

Frontend
   ↓
Backend
   ↓
LLM
   ↓
Tools

Агентний софт підштовхує до стеку з власним середовищем виконання агентів:

Frontend
   ↓
Application
   ↓
Agent Runtime
   ├── Model
   ├── Context
   ├── Tools
   ├── Subagents
   ├── Sandbox
   ├── Memory
   ├── Verification
   └── Observability

Середовище виконання тепер заслуговує на місце як окремий архітектурний компонент, і це розширює те, що має знати ШІ-інженер. Добрих промптів уже недостатньо. Системна інженерія йде в комплекті.

Навички, які варто розвивати

Якщо ви сьогодні створюєте ШІ-застосунки, ось навички, цінність яких зростає:

• Оркестрація: розуміти, як агент будує план, виконує його, передає частини й відновлюється після помилок.
• Проєктування інструментів: створювати API та MCP-сервери, на які агент може спиратися без сюрпризів.
• Пісочниці: тримати те, що запускає агент, окремо від ваших чутливих систем.
• Керування контекстом: вирішувати, яка інформація доходить до моделі і в який момент.
• Оцінювання: перевіряти, що агент справді правильно виконав завдання.
• Спостережуваність: трасування дій агента, використаних інструментів і місця, де щось пішло не так.
• Конкурентність: розуміти, яку роботу треба впорядкувати, а яка може йти паралельно.
• Проєктування прав: видавати мінімум можливостей, потрібних для завдання.

Жодна з цих навичок не є суто «ШІ-шною». Це навички розробки ПЗ, застосовані до автономних систем.

Середовище виконання стає продуктом

Цікаво те, що цей анонс каже про зрілість галузі. Спершу ШІ-API дали доступ до моделей. Потім з’явилися фреймворки, що допомагають будувати ланцюжки й агентів. Тепер провайдери постачають і довколишній механізм для автономних агентів. OpenAI описує Agents API як побудований на відкритій обв’язці Codex, підтримку якої синхронізовано з випусками моделей. Це звільняє команди від потреби заново будувати ось це:

context management
tool orchestration
subagent coordination
execution infrastructure
session handling

і дає змогу приділяти більше часу самому продукту.

Компроміс керованої інфраструктури

Керована інфраструктура дає швидкість і може коштувати частини контролю. Якщо обв’язкою керує OpenAI, вам однаково треба розуміти, що відбувається між вашим запитом і результатом:

Your request
    ↓
Agent
    ↓
Model
    ↓
Tools
    ↓
Environment

Продакшен-системам потрібні сильна спостережуваність і чіткі межі. Без них неочікуване рішення агента налагоджувати значно складніше, ніж звичайний виклик API, бо питання перестає бути «що відповіла модель» і стає «що зробив агент». Це дуже різні задачі налагодження.

Від промптів до середовищ виконання

Головний висновок: наступне покоління ШІ-застосунків буде не просто чат-інтерфейсами, під’єднаними до LLM. Це будуть програмні системи, де моделі міркують, використовують інструменти, пишуть і запускають код, делегують роботу, перевіряють результати, відновлюються після збоїв і працюють далі впродовж довгих сесій. Модель і надалі важлива, але середовище виконання довкола неї може виявитися не менш важливим. Agents API — рання ознака цього зсуву.

Тож конкуренція може зміститися від чистої якості моделі до того, хто збудує найкращий механізм перетворення цього інтелекту на роботу, на яку можна покластися. Для інженерів це цікавіше завдання. Цінною навичкою може стати вже не виклик LLM, а побудова середовища, у якому ШІ може робити корисну роботу.