跳到主要内容

原生多智能体 API：OpenAI 的 Responses 多智能体 Beta 与自己动手搭建

高级

过去十八个月里，“多智能体”意味着扇出（fan-out）要你自己写：你写协调者提示词，你并行发起 N 个调用，你合并它们的 JSON，你处理重试。2026 年 7 月 9 日，OpenAI 把这一切压缩成了一个请求参数：Responses API 上的 multi_agent.enabled: true，并包装成一个名为 Sol Ultra Mode 的消费级功能。模型自己决定生成多少个子智能体，并行运行它们，再综合结果——全部在一次 HTTP 调用之内。目前没有其他前沿厂商发布过对等的原语。本页梳理实际发布了什么、背后的数字、Anthropic 提供的替代方案，以及最关键的部分：原生原语物有所值的三类工作负载，和自己搭建扇出仍然更优的两类。

What you'll learn
  • 读懂 Responses API 多智能体请求体的确切形态，并知道 max_concurrent_subagents 究竟限制了什么
  • 做成本核算：按 Sol 的价格，“模型生成 4 个子智能体”实际要收你多少钱
  • 在 Anthropic 一侧画出同样的版图——Cowork、Managed Agents 和 Claude Code 子智能体——并看清原语上的差距
  • 按工作负载选对原语：原生多智能体、自建扇出、A2A，还是单次长回合
  • 避开四种会让 4 智能体 Ultra 调用变成 4 倍账单却没有准确率提升的失败模式

一句话版本​

Ultra Mode 是 Responses API 上 multi_agent.enabled: true 之上的一层消费级外壳——一个原生原语，让模型在一次请求内并行生成子智能体、综合它们的输出，并返回单一响应。它在可并行的任务上能换来虽小但真实的准确率提升（Terminal-Bench 2.1：88.8% → 91.9%），而 token 账单大致与模型选择生成的子智能体数量成线性增长。

2026 年 7 月 9 日实际发布了什么​

同一次发布里落地了两样东西，值得分开看：

  • Ultra Mode——ChatGPT 和 Codex 内的产品开关。在旗舰档（Sol）上可用。开启后，困难任务会先被拆解成并行的子智能体运行，再做综合。宣传为“生成 4 个以上智能体”；OpenAI 自己的一些 GA 基准图表在 BrowseComp 和 SEC-Bench Pro 上也展示了 16 智能体的配置，但实际默认值是四个。
  • Responses API 多智能体 Beta——开发者原语。同样的底层能力，以 client.beta.responses.create() 上的 multi_agent.enabled: true 暴露出来。想自己搭一个类 Ultra 的体验，就用这个。

营销留下的困惑是真实的：开发者不断在问“我怎么从 API 调用 Ultra Mode？”答案是：你不能——你启用的是多智能体 Beta，它正是产品功能底下的那个原语。

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 端点。如果你依赖推理摘要做可观测性，一旦打开它就会失去这些。

营销页不会印出来的成本核算​

按 Sol 的 GA 定价每百万 token 输入 $5 / 输出 $30，这笔账毫不留情。以下来自对真实 Ultra 运行做逆向分析的开发者文章：

  • Ultra 拆成 2 个子智能体的任务 ≈ 单次 Sol 调用输出 token 成本的 2 倍——因为两个子智能体都要生成输出，根还要在其上生成综合内容。
  • Ultra 生成 5 个子智能体的任务 ≈ 5 倍——理由相同，再加上整棵树上按比例增多的输入 token 重放。
  • 展示 16 智能体配置的 BrowseComp / SEC-Bench 图表不是免费的午餐：它们是研究级的演示，不是默认值。在 Sol 上并发 16 个子智能体时，单单输出 token 一项，每个困难查询就是两位数美元的中段。

可以这样理解：你付的是一次 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 图表上，Anthropic 的 Opus 4.8 得分为 78.9%——也就是说，Sol Ultra 的领先来自更好的基础模型与叠加其上的多智能体增益两者。如果你从 Opus 迁移到 Sol Ultra，不要把全部差距都归功于多智能体原语。

Anthropic 的做法​

Anthropic 尚未发布对等的 API 原语。最接近的几个类比各自解决同一问题的不同切片：

  • Cowork——一个产品界面。一个智能体式桌面工作区，智能体在其中与用户并肩完成持续的多步工作。作为功能可与 Ultra Mode 相比，但不是 API 原语。
  • Managed Agents 与 managed-agents memory stores——带持久状态和调度的托管智能体循环。填补的是“长时间运行的后台智能体”这个位置，而不是“并行生成 4 个再合并”那个位置。
  • Claude Code 子智能体与子智能体集群限制——一等的子智能体原语，但范围限定在 Claude Code CLI。有文档、可并行生成，是 multi_agent.enabled 最接近的类比——重要区别在于协调者提示词要你自己写。
  • Messages API 上的构建智能体——自己动手的路径。你并行扇出 N 个 messages.create 调用，自己写综合提示词，自己处理重试。结果相同，代码更多。

差距在于：目前没有任何 Anthropic API 接口能让你拨一个布尔开关，就由模型自己决定生成多少个子智能体并合并它们的工作。 如果你想在 Claude 上得到这种行为，就得自己搭——产品侧的情况见 Cowork 与 Agent Teams，托管循环原语见 Managed Agents。

按工作负载选对原语​

Guided walkthrough1 of 5
  1. 如果子任务可以在不等待彼此结果的情况下运行——审计一个仓库、跨多个来源调研一个主题、彼此独立地重构 N 个文件——扇出的形态就值回成本。如果任务是顺序的（编辑 A，读取 A 的结果，再编辑 B），任何多智能体原语都只会增加综合开销而没有收益。

四种让 Ultra 变成白付 4 倍账单的失败模式​

  • 在顺序任务上打开它。 即使任务无法并行，模型仍会拆解并综合。你为本不需要的工作付了协调开销。经验法则：如果你说不出在第一个子智能体运行时第二个要做什么，就不要启用多智能体。
  • 让推理摘要的可观测性留在你的仪表盘上。 多智能体下 reasoning.summary 被静默地不支持。如果你的监控依赖它，你会看到空字段，还以为模型没在思考。在拨动开关之前先发布 schema 变更。
  • 把 max_tool_calls 当作安全限制。 多智能体下它同样被静默禁用。你以为拥有的安全保障——“每个请求最多 20 次工具调用”——没了。应在工具适配器层强制工具调用上限，而不是通过请求参数。
  • 以为 max_concurrent_subagents 是成本上限。 它限制的是某一时刻的活跃子智能体，而不是整个请求期间生成的总数。一次 Ultra 调用可以依次生成几十个子智能体，同时仍遵守 max_concurrent_subagents: 3 的限制。如果成本是你的天花板，请加上请求级的 max_output_tokens。

“原生多智能体”不是什么​

有两个相邻的原语常被与它混淆：

  • 不是 n > 1 采样。 OpenAI 较早的 n 参数会采样多个补全并全部返回，由你挑一个。多智能体则是让不同的子智能体做不同的工作，并综合它们的输出。前者是温度采样；后者是任务分解。
  • 不是批量推理。 批处理 API 在后台处理大量彼此独立的请求。多智能体是在一次交互式请求内的许多相互协调的子智能体。批处理面向吞吐量，多智能体面向结果。

走向何方​

A2A 协议（见 A2A：智能体到智能体协议）涵盖跨厂商的多智能体。multi_agent.enabled: true 涵盖模型内部的多智能体。尚未填补的空位是跨厂商原语——厂商 A 的模型在厂商 B 上生成一个子智能体并合并结果——目前还没有公开规范。它出现时，会以 A2A + 一个原生移交动词的形式出现，而不是任何一方的新 API。请关注这个方向。

Check yourself

0/4
  1. max_concurrent_subagents 在 Responses 多智能体 Beta 上限制的是什么？
  2. 你启用了多智能体，监控仪表盘上的推理摘要字段突然变空。发生了什么？
  3. 你需要在跨两家厂商、不同客户账户中运行的并行子智能体。哪种原语是正确的？
  4. 下列哪一项不适合使用 Ultra Mode / multi_agent.enabled？
还没有卡片 — 添加一些开始学习吧。🃏

来源与延伸阅读​

下一步​