Что 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, а построение среды, в которой ИИ может делать полезную работу.