Перейти к основному содержимому

Нативные мультиагентные API: бета Responses Multi-Agent от OpenAI против самостоятельной сборки

Продвинутый

Полтора года «мультиагентность» означала, что fan-out пишете вы. Вы писали промпт координатора, запускали N параллельных вызовов, склеивали их JSON и обрабатывали повторные попытки. 9 июля 2026 года OpenAI свела всё это к параметру запроса: multi_agent.enabled: true в Responses API, обёрнутому в потребительскую функцию Sol Ultra Mode. Модель сама решает, сколько субагентов породить, запускает их параллельно и синтезирует результат — всё внутри одного HTTP-вызова. Ни один другой фронтирный вендор не выпустил симметричный примитив. Эта страница показывает, что именно выпущено, какие цифры за этим стоят, что предлагает Anthropic вместо этого и — самое важное — три нагрузки, на которых нативный примитив окупает свою цену, и две, где самодельный fan-out по-прежнему выигрывает.

What you'll learn
  • Прочитать точное тело мультиагентного запроса к Responses API и понимать, что на самом деле ограничивает max_concurrent_subagents
  • Посчитать стоимость: сколько на самом деле стоит «модель породила 4 субагента» по ценам Sol
  • Сопоставить то же самое на стороне Anthropic — Cowork, Managed Agents и субагенты Claude Code — и увидеть разрыв в примитивах
  • Выбрать правильный примитив под нагрузку: нативная мультиагентность, самодельный fan-out, A2A или один длинный ход
  • Избежать четырёх сценариев сбоя, из-за которых вызов Ultra с 4 агентами превращается в счёт х4 без выигрыша в точности

Версия в одном предложении​

Ultra Mode — это потребительская оболочка над multi_agent.enabled: true в Responses API: нативный примитив, позволяющий модели порождать субагентов параллельно внутри одного запроса, синтезировать их результаты и возвращать единый ответ. Он даёт небольшой, но реальный прирост точности на параллелизуемых задачах (Terminal-Bench 2.1: 88,8% → 91,9%) при счёте за токены, который растёт примерно линейно с числом субагентов, которых решит породить модель.

Что именно выпущено 9 июля 2026 года​

В одном запуске появились две разные вещи, и их стоит разделять:

  • Ultra Mode — продуктовый переключатель в ChatGPT и Codex. Доступен на флагманском уровне (Sol). При включении сложные задачи раскладываются на параллельные запуски субагентов перед синтезом. В маркетинге — «порождает 4+ агентов»; на нескольких собственных графиках OpenAI по GA-бенчмаркам BrowseComp и SEC-Bench Pro также видны конфигурации с 16 агентами, но рабочее значение по умолчанию — четыре.
  • Бета мультиагентности в Responses API — разработческий примитив. Та же базовая возможность, доступная как multi_agent.enabled: true в client.beta.responses.create(). Именно им вы пользуетесь, чтобы собрать собственный аналог Ultra.

Путаница после маркетинга вполне реальна: разработчики постоянно спрашивают «как вызвать Ultra Mode из API?». Ответ: никак — вы включаете мультиагентную бету, то есть примитив, лежащий под продуктовой функцией.

Мультиагентный запрос к Responses API​

Вот как он выглядит конкретно (Python SDK):

Минимальный мультиагентный вызов Responses API

from openai import OpenAI

client = OpenAI()

resp = client.beta.responses.create(
  model="gpt-5.6-sol",
  input="Audit this repo for auth-bypass patterns and write a report.",
  multi_agent={
      "enabled": True,
      "max_concurrent_subagents": 3,
  },
  tools=[...],  # your MCP tools, function tools, etc.
  extra_headers={"OpenAI-Beta": "responses_multi_agent=v1"},
)

Четыре неочевидных момента этой формы:

  • max_concurrent_subagents — не общий бюджет. Он ограничивает активные ходы субагентов во всём дереве в любой момент — корень плюс потомки. Модель может породить гораздо большее общее число субагентов за время жизни запроса; просто одновременно работать их может не больше N.
  • Глубина не ограничена. Субагент сам может порождать субагентов. Нет фиксированного предела ни на глубину дерева, ни на общее число субагентов за запуск. Ваша поверхность затрат — это не «N вызовов», а дерево, которое модель формирует во время выполнения.
  • Синтезирует корень. Корневой агент отвечает за слияние ответов субагентов в итоговый ответ. Структурированный объект {subagents: [...]} вам не вернут; вы получаете один ответ, а промежуточные ходы агентов для вашего кода непрозрачны.
  • Некоторые параметры молча отключаются. reasoning.summary и max_tool_calls не поддерживаются при включённой мультиагентности, а эндпоинт compaction не поддерживается для мультиагентных ответов. Если вы полагаетесь на сводки рассуждений для наблюдаемости, вы теряете их в момент включения.

Расчёт стоимости, которого нет на маркетинговой странице​

При GA-ценах Sol $5 за миллион входных / $30 за миллион выходных токенов арифметика безжалостна. По разборам разработчиков, которые реконструировали реальные запуски Ultra:

  • Задача, которую Ultra раскладывает на 2 субагента ≈ 2x стоимости выходных токенов одного вызова Sol — потому что оба субагента генерируют вывод, а корень затем генерирует ещё и синтез.
  • Задача, под которую Ultra порождает 5 субагентов ≈ 5x — то же рассуждение плюс пропорционально больше повторной подачи входных токенов по дереву.
  • Графики BrowseComp / SEC-Bench с конфигурациями на 16 агентов — это не бесплатный обед: это демонстрация исследовательского уровня, а не значение по умолчанию. При 16 одновременных субагентах на Sol только за выходные токены выходит сумма порядка двузначного числа долларов за один сложный запрос.

Как об этом думать: вы платите за Монте-Карло из вызовов Sol плюс один проход синтеза сверху. Иногда это покупает достаточно точности, чтобы иметь значение. Иногда это просто счёт х4 за задачу, которую решил бы и один вызов.

Что на самом деле покупает точность​

Опубликованные приросты на параллелизуемых оценках — именно для таких нагрузок создан Ultra Mode — реальны, но скромны:

БенчмаркSol (одиночный)Sol UltraРазницаЧто измеряет оценка
Terminal-Bench 2.188,8%91,9%+3,1Многошаговое планирование в командной строке, координация инструментов
BrowseComp87,5%92,2%+4,7Веб-исследование по многим источникам и синтез
SEC-Bench Pro—74,3%(значение для одиночного режима не опубликовано)Рассуждение по нормативным документам на больших корпусах

Три замечания к таблице:

  • Диапазон +3–5 пунктов согласуется с тем, что параллельное сэмплирование исторически давало на других фронтирных моделях (best-of-N, self-consistency). Примитив действительно полезен; прирост — не качественный скачок.
  • Это лучший случай — оценки, выбранные, чтобы показать режим в выгодном свете. На последовательных задачах (линейная правка кода, переписывание одного файла, короткий чат) Ultra добавляет задержку и стоимость синтеза, не двигая точность.
  • На том же графике Terminal-Bench 2.1 Opus 4.8 от Anthropic набрал 78,9% — то есть преимущество Sol Ultra складывается из и более сильной базовой модели, и мультиагентного прироста поверх неё. Если вы переходите на Sol Ultra с Opus, не списывайте весь разрыв на мультиагентный примитив.

Что вместо этого делает Anthropic​

Anthropic не выпустила симметричный примитив API. Ближайшие аналоги решают каждый свой фрагмент той же задачи:

  • Cowork — продуктовая поверхность. Агентное настольное рабочее пространство, где агент выполняет длительную многошаговую работу рядом с пользователем. Сопоставим с Ultra Mode как функция, но не как примитив API.
  • Managed Agents и хранилища памяти managed agents — размещённый агентный цикл с постоянным состоянием и планированием. Закрывает нишу «долгоживущий фоновый агент», а не «породить 4 параллельно и объединить».
  • Субагенты Claude Code и лимиты флота субагентов — первоклассный примитив субагентов, но ограниченный CLI Claude Code. Документирован, параллельно запускается и является ближайшим аналогом multi_agent.enabled — с важным отличием: промпт координатора вы пишете сами.
  • Building Agents поверх Messages API — самодельный путь. Вы параллельно запускаете N вызовов messages.create, пишете промпт синтеза и обрабатываете повторные попытки. Тот же результат, больше кода.

Разрыв: ни одна поверхность API Anthropic сейчас не позволяет переключить один булев флаг так, чтобы сама модель решала, сколько субагентов породить, и объединяла их работу. Если нужно такое поведение для Claude, его придётся построить — продуктовую сторону см. в Cowork & Agent Teams, а примитив размещённого цикла — в Managed Agents.

Выбор примитива под нагрузку​

Guided walkthrough1 of 5
  1. Если подзадачи могут выполняться, не дожидаясь результатов друг друга — аудит репозитория, исследование темы по многим источникам, независимый рефакторинг N файлов — форма fan-out окупает свою цену. Если задача последовательна (правка A, затем чтение результата A, затем правка B), любой мультиагентный примитив добавляет накладные расходы на синтез без выгоды.

Четыре сценария сбоя, превращающие Ultra в счёт х4 впустую​

  • Включение для последовательных задач. Модель всё равно раскладывает и синтезирует, даже если задача не параллелизуется. Вы платите накладные расходы на координацию работы, которой они не нужны. Практическое правило: если вы не можете сформулировать, чем занимался бы второй субагент, пока работает первый, не включайте мультиагентность.
  • Оставить наблюдаемость на сводках рассуждений на дашборде. reasoning.summary молча не поддерживается при мультиагентности. Если ваш мониторинг от него зависит, вы получите пустые поля и решите, что модель не думает. Выкатите изменение схемы до того, как включать флаг.
  • Использовать max_tool_calls как защитный лимит. Также молча отключается при мультиагентности. Гарантия, которая, как вам казалось, у вас есть — «не более 20 вызовов инструментов на запрос», — исчезает. Ограничивайте число вызовов инструментов на уровне адаптера инструментов, а не параметром запроса.
  • Считать max_concurrent_subagents ограничителем стоимости. Он ограничивает активных субагентов в момент времени, а не общее число порождённых за запрос. Один вызов Ultra может последовательно породить десятки субагентов и при этом соблюдать лимит max_concurrent_subagents: 3. Если ваш потолок — стоимость, добавьте max_output_tokens на уровне запроса.

Чем «нативная мультиагентность» не является​

Два соседних примитива с ней часто путают:

  • Не сэмплирование n > 1. Старый параметр n у OpenAI сэмплирует несколько завершений и возвращает все; вы выбираете одно. Мультиагентность запускает разных субагентов, делающих разную работу, и синтезирует их результаты. Первое — температурное сэмплирование; второе — декомпозиция задачи.
  • Не пакетный инференс. Batch API обрабатывает много независимых запросов в фоне. Мультиагентность — это много скоординированных субагентов внутри одного интерактивного запроса. Batch ориентирован на пропускную способность, мультиагентность — на результат.

Куда всё движется​

Протокол A2A (см. A2A: протокол Agent-to-Agent) покрывает мультиагентность между вендорами. multi_agent.enabled: true покрывает мультиагентность внутри модели. Незаполненная ниша — кросс-вендорный примитив: модель вендора A порождает субагента у вендора B и объединяет результат; публичной спецификации для него пока нет. Когда она появится, это будет A2A плюс нативный глагол передачи, а не новый API ни с одной из сторон. Следите за этим направлением.

Check yourself

0/4
  1. Что ограничивает max_concurrent_subagents в бете мультиагентности Responses?
  2. Вы включили мультиагентность, и на дашборде мониторинга вдруг появились пустые поля сводок рассуждений. Что произошло?
  3. Вам нужны параллельные субагенты, работающие в разных клиентских аккаунтах у двух вендоров. Какой примитив правильный?
  4. Какая из этих задач плохо подходит для Ultra Mode / multi_agent.enabled?
Карточек пока нет — добавьте их, чтобы начать заниматься. 🃏

Источники и дополнительное чтение​

Дальше​