让智能体并行调用工具，收益不在”快”，而在”上下文干净”：把多个独立调用的结果在代码里过滤、聚合后再回填，模型上下文里只留下要判断的那部分。真正决定能不能并行的，是调用之间有没有依赖关系，而不是模型想不想并行。
先分清三种”并行”，别混为一谈
| 类型 | 并行的是什么 | 上下文 | 适用 |
|---|---|---|---|
| 并行工具调用 | 同一轮里多个工具请求 | 共享同一上下文 | 彼此独立的取数、查询 |
| 程序化工具调用 | 用代码编排多个调用 | 中间结果不进上下文 | 批量数据处理、过滤聚合 |
| 并行子智能体 | 多个独立任务流 | 各自隔离的上下文 | 需要独立推理的探索任务 |
很多团队一上来就上子智能体，其实他们要的只是第一种。 OpenAI 在 GPT-5.6 构建指南里给的判断标准很实用：智能体工作分两类，一类需要判断力，一类主要是搬运、过滤、合并数据。后者应该用代码做，而不是让模型在上下文里推理每一个中间结果。
程序化工具调用：并行的正确姿势
做法是让模型写一段代码来编排工具，独立调用并行跑，结果的处理在代码里完成，只有相关结果回到上下文。
# 概念示意：模型产出编排代码，中间结果不进上下文
results = await Promise.all([
fetchFilings(ticker, "2025-Q1"),
fetchFilings(ticker, "2025-Q2"),
fetchFilings(ticker, "2025-Q3"),
])
# 过滤与聚合在代码里做
relevant = [r for r in results if r.amount > threshold]
# 只把结论交给模型
return {"count": len(relevant), "total": sum(r.amount for r in relevant)}
OpenAI 公布的一个客户案例里，金融研究场景用这种方式在保持评分质量的同时，输入 token 减少了约 21%。这类收益的来源不是”并行更快”，而是”没用的内容根本没进上下文”。
上下文管理的杠杆比并行本身更大
同一份指南里还有一组更夸张的数字：在 ARC-AGI-3 上，标准执行框架下得分 13.3%，启用保留推理与压缩之后升到 38.3%，同时输出 token 用了大约六分之一。模型没换，只改了执行框架。
能不能并行，取决于依赖图
模型并不可靠地知道哪两个调用是独立的。工程上要显式给出判断规则。
可以并行的三种情况
- 只读且互不依赖：多个查询、多个文档读取、多个 API 取数。
- 写不同资源：目标 ID 不同、字段不重叠。
- 幂等的重试：失败后重发，不会产生额外副作用。
必须串行的三种情况
- 后一步依赖前一步的输出：先查 ID 再查详情，这是最常见的伪并行。
- 共享可变状态：两个调用都要改同一个资源，并行会互相覆盖。
- 有顺序副作用：创建再更新、加锁再操作。
用一个显式声明表达依赖
# 让模型输出依赖声明，编排层据此调度
calls:
- id: a tool: search_docs args: {q: "退款政策"} depends_on: []
- id: b tool: search_docs args: {q: "退款时效"} depends_on: []
- id: c tool: get_order args: {id: "${a.result.order_id}"} depends_on: [a]
# a 、 b 并行；c 必须等 a
这种”模型声明依赖、代码负责调度”的分工，比让模型自己决定顺序可靠得多。确定性更强的场景，也可以直接上状态机编排，做法参考什么时候该用状态机代替模型决策。
并行带来的四个新问题
一、结果顺序不能靠返回先后判断
并发完成的顺序是不确定的。必须给每个调用带显式 ID，按 ID 而不是按数组下标组装结果。这是最基础也最容易出错的一点。
二、部分失败要有独立策略
五个并行调用里挂了一个，是整体失败还是降级继续？答案取决于这个调用是否关键。做法是把调用分成”必需”和”可选”两档：必需失败则整体失败并重试，可选失败则记为缺失并在结果里标注。失败重试与降级的完整策略见工具调用失败的重试与降级设计。
三、并发上限要显式设置
不限流的并行会把下游打挂。 OpenAI 的 Agents API 在多智能体配置里直接提供了 max_concurrent_subagents 这样的参数，就是在提醒这件事。工具调用同理：按目标服务的承受能力设全局和单服务两级限制。
四、结构化输出要在并行之前定好
并行调用的结果要能被代码可靠聚合，前提是每个结果的形状是可预期的。先定义好 JSON Schema 再做并行，否则聚合逻辑会退化成一堆 try/except。约束与校验的做法见结构化输出的三道关。
什么情况下该换成并行子智能体
当每个分支本身需要”思考”而不只是”取数”时，工具并行就不够用了——这时候要靠子智能体，给每条分支独立的上下文。
LangChain 在多智能体上下文组织里给了一个好用的判据：继续主智能体工作的用 fork（继承上下文），独立评判主智能体工作的用 isolated（全新上下文）。前者省去重复取数，后者避免被主智能体的判断锚定。这个取舍在并行工具调用里同样成立——共享上下文省 token，独立上下文保质量。
工具数量多到影响选择质量时，则要先用渐进式工具发现缩小候选集，再谈并行。流式场景下并行结果的呈现顺序问题，参考流式输出与终态处理。
模型能自己判断哪些调用可以并行吗？
并行调用会让成本变高吗？
并行和批量调用有什么区别？
部分结果缺失时模型会乱猜吗？
参考来源：openai.com（GPT-5.6 构建者指南、 Agents API 发布说明）、 langchain.com（多智能体上下文组织、结构化工具设计）。本文基于上述公开材料重新组织，并补充工程实践经验。
评论 (0)