Multi-Agent 与工作流编排 ​

本文不把 Multi-Agent（多智能体）当成“更高级的 Agent 形态”，而是把它当成一种需要被证明有正收益的架构选择。

真正要回答的问题是：

什么时候 Single Agent（单智能体）已经不够？为什么一定要拆？拆完以后，控制权、上下文、权限、状态、并发、失败和结果聚合应该怎样重新设计？

本文以工程机制和公开实现为依据。产品能力的动态事实以 2026-09-13 为核验基线；公开实现用于验证架构机制，不代表必须照抄某一家产品方案。

文中的 Agent 数量、上下文长度、截止时间和成本倍数均为帮助解释机制的假设示例，不是生产基准或供应商能力承诺。实际阈值必须由企业自己的任务分布、服务等级和压力测试确定。

一、为什么会从单 Agent 演进到 Multi-Agent ​

1.1 Multi-Agent 不是成熟度等级 ​

最容易犯的错误是把架构演进想成：

Single Agent
→ Workflow
→ Multi-Agent
→ 更高级

这种理解是错的。

Multi-Agent（多智能体）不是 Agent 系统的“高级阶段”，而是：

当一个决策主体无法再低成本地同时承担全部上下文、能力、权限、并发和责任边界时，把系统拆成多个独立决策主体。

如果一个 Agent 已经可以：

• 稳定理解任务；
• 正确选择 Tool；
• Context 不爆炸；
• 权限边界清晰；
• 延迟和成本可接受；
• 结果可验证；

那么继续拆 Agent 往往只会增加：

• 更多模型调用；
• 更多 Context 复制；
• 更多协调；
• 更多失败点；
• 更复杂的 Debug。

所以默认选择仍然应该是：

能用一个 Agent 稳定解决，就先不要拆。

1.2 Workflow Orchestration 与 Multi-Agent 有什么区别 ​

Workflow（工作流）和 Multi-Agent 经常被混在一起。

Workflow 的核心是：

执行结构由系统明确控制。

例如：

读取 PRD
→ 生成代码
→ 跑测试
→ 生成 Diff
→ 等待审批

这些步骤由代码、状态机或图结构明确决定。

Multi-Agent 的核心是：

系统里存在多个拥有独立决策边界的 Agent。

例如：

主 Agent
→ 决定把安全审计交给 Security Agent
→ 决定把性能分析交给 Performance Agent

这两个 Agent 各自会：

• 看到不同 Context；
• 拥有不同 Tool；
• 做自己的模型决策；
• 产生独立结果。

所以两者的区别不是：

“有没有多个节点”

而是：

Workflow
→ 谁走下一步主要由系统规则决定

Multi-Agent
→ 至少一部分下一步由独立 Agent 决策决定

两者完全可以组合。

例如：

确定性 Workflow
  ↓
某一步调用 Research Agent
  ↓
继续走确定性 Verification

这通常比“全程所有东西都交给多个 Agent 自由协作”更容易治理。

生产系统通常采用“确定性骨架承载治理、有限智能节点承担判断”的组合。阅读下图时从左向右看主路径：编排层先建立预算、权限和恢复边界，再选择单个或多个决策主体；所有结果必须经过汇聚与验证，不能由 Worker 直接宣布整体完成。

这张图不是要求所有系统都建设 Supervisor，而是强调两个固定点：委托前要建立执行边界，返回后要验证业务结果。中间是否拆 Agent，仍由后文的边界和净收益判断决定。

1.3 什么情况下单 Agent 才真的不够 ​

真正合理的拆分原因主要有六类。

Context Boundary（上下文边界） ​

一个 Agent 如果同时承担：

数据分析
代码仓库理解
安全规范
业务规则
运维知识

Context 可能越来越大。

问题不是“Token 不够”这么简单，而是：

• 无关信息增多；
• Tool Description 互相干扰；
• 模型注意力被稀释；
• Prompt Cache（提示词缓存）命中变差；
• 调试时很难知道哪段 Context 导致错误。

这时可以把某个专业域放进独立 Agent，让它只看到：

完成当前子任务真正需要的信息。

所以 Context Isolation（上下文隔离）不是为了“角色好听”，而是为了提高 Decision-relevant Information Density（决策相关信息密度）。

Capability Boundary（能力边界） ​

如果一个 Agent 暴露 100 个 Tool，模型 Tool Selection 可能明显下降。

拆出专门 Agent 的价值是：

主 Agent
→ 只知道“可以找数据库专家”

数据库专家
→ 只看到 SQL / Dataset / Metric 相关 Tool

这样减少：

• Tool 混淆；
• Prompt 长度；
• 高风险能力误选。

Permission Boundary（权限边界） ​

这是企业场景里最有价值的拆分理由之一。

例如：

Research Agent
→ 只允许 Web Read

Data Agent
→ 允许读企业数据

Release Agent
→ 允许生产发布

如果全部集中在一个 Agent：

这个 Agent 会拥有非常宽的权限面。

拆分以后可以做到：

每个 Agent
→ 只拿完成自己任务需要的最小权限

这就是 Least Privilege（最小权限）。

Parallelism Boundary（并行边界） ​

如果一个任务能自然拆成彼此独立的子问题：

研究市场趋势
研究竞品变化
研究用户反馈
研究财务影响

这些可以并行。

此时多个 Worker（工作智能体）可能缩短关键路径时延。

但前提是：

子任务真的独立。

如果最后所有 Worker 都查同样的资料，就只是把成本放大。

Model Specialization（模型专业化） ​

某些子任务可能适合不同模型。

例如：

代码修改
→ 强代码模型

简单分类
→ 低成本模型

视觉检查
→ 多模态模型

此时 Specialist Agent（专家智能体）可以绑定不同 Model Profile（模型配置档案）。

但如果只是“同一个模型换个角色 Prompt”，收益未必足以抵消协调成本。

Service / Ownership Boundary（服务 / 责任边界） ​

当一个能力本来就由另一个团队独立维护：

Risk Agent
Data Agent
Research Agent

它们可能拥有：

• 独立发布节奏；
• 独立 SLA（Service Level Agreement，服务等级协议）；
• 独立权限；
• 独立 Runtime。

这时把它们作为 Remote Agent（远端智能体）集成，比强行打包进同一个进程更合理。

六类边界不是拆分理由的名词清单，而是六种可以被观测和验证的工程压力。只有压力已经出现、简单方案已经接近边界，并且拆分后的证据能够覆盖新增协调成本，才应该引入新的 Agent。

反过来，如果主要问题只是步骤多、工具多或提示词过长，确定性工作流、动态工具加载和上下文工程通常比多智能体更直接。多智能体解决的是独立决策边界，不是所有复杂任务。

1.4 为什么最终会变成分布式系统问题 ​

一旦系统里有多个独立 Agent，就自然出现：

谁负责哪个任务？
谁拥有共享资源？
谁可以修改状态？
消息重复怎么办？
某个 Agent 失败怎么办？
多个结果冲突怎么办？
什么时候整体算完成？

这些分别对应：

• Ownership（所有权）；
• Coordination（协调）；
• Distributed State（分布式状态）；
• Partial Failure（部分失败）；
• Consistency（一致性）；
• Scheduling（调度）；
• Conflict Resolution（冲突解决）；
• Failure Containment（故障隔离）。

但 Multi-Agent 比普通分布式系统更难的一点是：

每个节点本身还是非确定性的模型决策主体。

因此可以记住：

Multi-Agent
=
Distributed Systems Problems
+
Non-deterministic Decision Makers

这也是为什么 Agent 数量从 1 变成 5，复杂度可能远远不只是 5 倍。

二、几种常见协作模式到底有什么区别 ​

2.1 哪些模式仍然保持中心控制权 ​

单智能体加工具：默认起点 ​

Single Agent + Tools（单智能体加工具）适合：

• Context 可以被一个 Agent 管理；
• Tool 数量可控；
• 没有明显权限隔离需求；
• 没有显著并行收益。

它的最大优势是：

控制权、状态和上下文都集中在一个地方。

因此：

• Debug 简单；
• Trace 简单；
• 成本更容易预测；
• 不需要跨 Agent Merge。

如果系统的问题只是：

“Tool 太多。”

优先考虑 Tool Search、动态 Tool Loading 或更好的 Context Engineering，而不是立刻拆 Agent。

Workflow：确定性复杂优先用流程解决 ​

如果任务步骤很多，但顺序和条件其实很明确：

读取文件
→ 生成草稿
→ 跑检查
→ 不通过则修复
→ 审批
→ 发布

这类问题首先应该考虑 Workflow。

为什么？

因为确定性流程如果交给多个 Agent 自由协商：

• 每一步都可能增加模型调用；
• 控制路径更难预测；
• 失败恢复更难；
• 成本更高。

Workflow 的价值就是：

把不需要模型决策的部分从模型手里拿回来。

Agent as Tool：什么时候最值得用 ​

Agent as Tool（把 Agent 作为工具）指：

主 Agent 保留控制权，把一个专业 Agent 包装成受控 Tool 来调用。

典型链路：

Main Agent
→ call_research_agent(...)
→ Research Agent 独立完成
→ 返回结构化结果
→ Main Agent 继续决策

它适合：

• 子任务边界清晰；
• Specialist 不需要直接接管用户会话；
• 主 Agent 需要统一汇总最终结果；
• 希望集中控制 Guardrail / Verification。

为什么这比 Handoff 更容易治理？

因为：

控制权始终在主 Agent。

子 Agent 更像一个“高智能 Tool”。

OpenAI Agents SDK 和 LangChain 当前都把这一模式作为重要多 Agent 形式。[^openai-orchestration][^langchain-multi-agent]

2.2 哪些模式会改变控制权归属 ​

Handoff：什么时候应该真的转移控制权 ​

Handoff（移交）不是“调用另一个 Agent”。

它真正表示：

当前 Active Agent（活动智能体）发生变化。

例如：

Triage Agent
→ 判断这是退款问题
→ Handoff Refund Agent
→ Refund Agent 直接继续和用户对话

为什么要 Handoff，而不是 Agent as Tool？

因为有些场景里，专业 Agent 需要：

• 直接拥有后续用户会话；
• 使用自己的 Prompt；
• 使用自己的 Tool；
• 持续维护自己的状态。

OpenAI 当前明确区分：

Agents as Tools
→ Manager 保持控制

Handoffs
→ Specialist 接管当前会话控制权

[^openai-orchestration][^openai-handoffs]

Handoff 的代价是：

• Conversation History 怎样传；
• 权限怎样重新计算；
• 谁负责最终响应；
• 怎样避免 A→B→A 死循环。

所以 Handoff 是 Control Transfer（控制权转移），不是普通 Tool Call。

Router 为什么不等于 Supervisor ​

Router（路由器）解决的是：

根据输入快速决定应该交给哪个 Agent。

通常：

用户请求
→ Router 分类
→ 选择 Data Agent / Coding Agent / Support Agent

Router 往往只做一次决策。

Supervisor（主管智能体）则是：

在一个持续任务里不断观察状态，并动态决定下一步调用哪个 Worker。

LangChain 当前也明确区分 Router 和 Supervisor：Router 更接近单次分类，Supervisor 是持续参与的完整 Agent。[^langchain-multi-agent][^langchain-router]

因此：

只需要一次分类
→ Router

需要持续计划、调用、汇总
→ Supervisor

2.3 并行与对等协作什么时候才值得 ​

并行扇出为什么有时反而更慢 ​

Fan-out / Gather（扇出 / 汇聚）指：

Parent
→ Worker A
→ Worker B
→ Worker C
并行执行
→ Gather / Merge

理论上它可以减少时延。

但并行收益不是“Worker 同时启动”就自动成立。真正端到端时间还会被 Delegation（委托）、Queueing（排队）、Merge（合并）和 Verification（验证）吃掉。

本节只保留一个判断：

只有子任务真正独立，而且协调与合并成本足够低，并行才可能更快。

正式的定量公式和成本模型统一放到第四章。

如果 Worker 做的是高度重叠工作：

• 重复检索；
• 重复加载 Context；
• 重复调用 Tool；

那么只是并行烧 Token。

Supervisor 集中协调的收益和代价 ​

Supervisor 模式让一个 Agent 负责：

• 拆任务；
• 选 Worker；
• 分发；
• 收集结果；
• 合并；
• 继续决策。

优势：

控制逻辑集中。

风险：

所有信息最后都回到 Supervisor，Supervisor 可能变成 Context 黑洞和吞吐瓶颈。

所以成熟设计不会让 Worker 返回完整聊天历史，而更倾向返回：

Typed Result
+ Evidence
+ Artifact Reference

Peer / Group Chat 为什么不宜默认使用 ​

多个 Agent 在共享对话里自由讨论，看起来很自然。

但它容易产生：

• Token 快速增长；
• 谁拥有最终事实不清楚；
• 观点重复；
• 局部错误互相强化；
• 难以判断何时结束。

Group Chat 适合：

• 探索性讨论；
• 少量 Agent；
• 输出本身就是观点碰撞。

但不适合作为企业默认生产架构。

Microsoft Agent Framework 当前提供 Group Chat 等模式，但同样将其作为编排工具箱中的一种选择，而不是默认模式。[^microsoft-orchestration]

2.4 协作模式怎样落到同一套选择标准 ​

模式选择首先看控制权是否需要转移，其次看子任务是否独立、是否需要持续协调，以及结果能否按确定性规则汇聚。下表中的“主要代价”也是不采用该模式的理由，不能只看它能够做什么。

一个常见的稳妥组合是：外层用确定性工作流固定审批、重试和发布边界，开放式步骤用 Agent，专业子任务优先用 Agent as Tool，只有确实需要转移会话责任时才使用 Handoff。这样把模型决策留在需要判断的地方，把恢复和治理留给运行时。

三、Multi-Agent 真正难的是哪些内部机制 ​

3.1 委托和上下文怎样形成稳定边界 ​

“为什么会从单 Agent 演进到 Multi-Agent”已经解释了 Context、Capability、Permission、Parallelism、Specialization、Ownership 如何构成拆 Agent 的理由；本节不再重新定义这些边界，只说明它们怎样被 Delegation Contract（委托契约）落到可执行字段和运行规则。

委托契约不能只靠一句 Prompt ​

最危险的委托方式是：

“你帮我查一下这个问题。”

因为 Parent 和 Worker 对以下问题没有共同理解：

• 到底负责什么；
• 可以看什么；
• 可以做什么；
• 可以花多少资源；
• 什么叫完成。

所以需要 Delegation Contract（委托契约）。

一个完整委托至少要表达六类边界。

Task Boundary（任务边界） ​

回答：

Worker 到底负责什么，不负责什么。

例如：

负责：查找 2026 年竞争对手发布信息
不负责：给最终商业结论

Context Boundary（上下文边界） ​

回答：

Worker 可以看到哪些输入。

不要默认把 Parent 全部 Conversation History 都复制过去。

应该只传：

• 当前子任务；
• 必要背景；
• 必要 Artifact；
• 相关约束。

Capability Boundary（能力边界） ​

回答：

Worker 可以使用哪些 Tool / Skill。

例如 Research Worker 不应该默认拥有生产数据库写权限。

Permission Boundary（权限边界） ​

Capability 存在不代表可以执行。

Delegation 需要明确：

• Resource Scope（资源范围）：Worker 只能访问哪些仓库、表、服务或文件；
• Environment（环境）：开发、测试还是生产；
• Write / Read（读写级别）：只读、可修改还是可发布；
• Approval（审批）：高风险动作是否需要人在回路确认。

这些字段描述的是“申请什么”，不是已经获得授权。Parent 先用自身可委托范围与任务最小范围形成授权请求；Policy Service（策略服务）再根据当前主体、委托链、资源、环境和策略签发短期、可验证、可撤销的 Scoped Ticket（限域授权票据）。Harness 在模型外强制门禁，Execution 在执行前验票；Runtime 只保存票据引用、有效期和等待状态。

也就是说，即使 Parent 能做某件事，也不能默认把同样权限复制给 Worker。

Budget Boundary（预算边界） ​

至少限制：

• Max Turns（最大轮数）：防止 Worker 无限思考；
• Token Budget（Token 预算）：限制模型上下文和生成成本；
• Tool Calls（工具调用上限）：防止循环调用外部能力；
• Runtime（运行时长）：限制一个子任务最长占用资源多久；
• Cost（成本预算）：把模型、Tool、Sandbox 总成本封顶；
• Fan-out（扇出上限）：限制 Worker 还能继续创建多少子任务。

否则一个 Worker 可以继续创建 Subagent，形成递归 Fan-out，成本和并发呈指数式膨胀。

Completion Boundary（完成边界） ​

回答：

什么结果才算完成。

例如：

至少 3 个独立来源
+
每个 Claim 有 Citation
+
时间范围满足要求

所以一个生产 Delegation Contract（委托契约）至少应该把这些边界落成明确字段：

这些字段不是为了标准化 JSON，而是为了让 Parent 和 Worker 对任务、权限、资源和完成条件拥有共同语义。

委托消息还要具有稳定的投递语义。网络超时只表示调用方没有收到结果，不能证明 Worker 没有启动。生产接口至少需要 delegation_id 作为幂等键、attempt 区分执行尝试、schema_version 支持契约演进，并把“接收委托”和“完成任务”拆成两个状态。Worker 返回的结果也不能只有自然语言正文，而应至少包含任务标识、结果状态、产物引用、候选证据、验证状态、消耗和可重试性。这里的候选证据只有通过独立验证后，才有资格升级为可采纳事实。

Parent 提交 delegation_id=D123
→ Runtime 原子记录委托并返回已接收
→ Worker 以 attempt=1 执行
→ 结果写入持久产物存储
→ Parent 按 D123 对账并决定采纳、重试或降级

如果 Parent 因超时再次提交 D123，运行时应返回既有委托，而不是创建第二个逻辑任务。只有失败策略允许并且前一次尝试已经进入可重试终态时，才创建新的 attempt。这样才能区分“同一任务的重新查询”“同一委托的执行重试”和“业务上真的要再做一次”。

Context 应该怎样在 Agent 之间流动 ​

Multi-Agent 最大成本之一就是 Context Duplication（上下文重复）。

错误做法：

Parent 100k Context
→ 每个 Worker 全量复制
→ 8 Workers

这会导致：

• Token 成本爆炸；
• 无关信息污染；
• Worker 失去专业隔离价值。

更合理的设计是：

Parent Context
↓
Task-specific Context Projection
↓
Worker
↓
Typed Result / Artifact
↓
Parent

也就是说：

Delegation 时传的是任务投影，不是父 Agent 的全部大脑。

共享状态为什么最容易失控 ​

最差设计是：

所有 Agent 共用一个可以随意读写的大 State。

此时多个 Agent 同时写：

status
plan
draft
file
memory

很快就会出现数据竞争。

优先采用：

Single Writer（单写者）
+
Multiple Readers（多读者）

或者：

Scoped Workspace（隔离工作空间）
+
Explicit Merge（显式合并）

例如 Coding Agent：

Worker A → Worktree A
Worker B → Worktree B
Integration Stage → Merge

而不是两个 Worker 同时修改同一目录。

如果必须共享可变状态，至少定义：

• Owner（所有者）；
• Version（版本）；
• Write Precondition（写前提）；
• Conflict Policy（冲突策略）；
• Merge Semantics（合并语义）。

为什么共享产物优于共享聊天 ​

自然语言聊天很适合人与 Agent 沟通。

但作为多个 Agent 之间长期协作接口，它存在：

• 结构不稳定；
• 事实和观点混合；
• 很难 Diff；
• 很难做版本；
• 很难做自动 Verification。

更可靠的是 Structured Artifact（结构化产物）。

例如 Research Worker 返回：

claims
evidence
source_urls
confidence
open_questions

Coding Worker 返回：

diff
test_result
build_result
changed_files
risk

Artifact 的价值是：

让结果成为可验证、可版本化、可合并的工程对象，而不是“另一个 Agent 说了一段话”。

3.2 多主体协作怎样处理失败、权限和冲突 ​

Partial Failure 为什么是默认情况 ​

Single Agent 常问：

成功 / 失败？

Multi-Agent 必须问：

5 个 Worker 成功 4 个，整体怎么办？
某个 Worker 超时，其他都完成怎么办？
结果互相冲突怎么办？

因此系统需要 Aggregation Contract（聚合契约）。

常见策略：

All Required（全部必需）
所有结果都必须成功。

适合：

• 审批；
• 强依赖流水线。

Quorum（法定数量）
达到一定成功数就可以继续。

适合：

• 多源验证；
• 投票型任务。

Best Effort（尽力而为）
允许部分失败。

适合：

• 并行 Research。

First Successful（首个成功）
多个路径谁先成功用谁。

适合：

• 冗余 Provider。

Human Resolve（人工解决）
结果冲突且风险高时交给人。

所以：

Multi-Agent Completion（多智能体完成）不是“所有 Agent 都 Done”，而是业务级聚合规则满足。

局部错误怎样变成全局错误 ​

Worker A 输出一个错误 Claim。

Supervisor 如果直接把它写进 Shared State：

Worker Claim
→ Shared Truth

后续所有 Agent 都会在错误前提上继续。

因此要区分：

claim（声明）
verified_fact（已验证事实）

重要中间结论需要：

• Evidence；
• Provenance；
• Verification Gate。

这叫 Semantic Promotion Gate（语义升级门）：

一个 Agent 的输出不能因为被 Supervisor 看见，就自动升级成系统事实。

Handoff 为什么一定要有终止机制 ​

典型死循环：

Agent A
→ 觉得 B 更合适
→ Handoff B

Agent B
→ 觉得 A 更合适
→ Handoff A

系统在花 Token，但没有 Task Progress。

因此 Handoff 需要一组明确的终止机制：

• Handoff Graph（移交图）：定义哪些 Agent 之间允许转移控制，避免任意互跳；
• Visited Agent Set（已访问集合）：记录当前任务已经经过哪些 Agent，用于检测重复路径；
• Max Hop（最大跳数）：无论模型怎样判断，都不允许无限移交；
• Progress Signal（进展信号）：每次移交以后必须产生新 Evidence、Artifact、已完成子任务或被消除的不确定性；
• Escalation（升级处理）：无法继续推进时转人工、退回 Parent 或进入失败状态，而不是继续循环。

为什么需要 Progress Signal？

因为“发生了 Handoff”不代表“任务取得进展”。

如果连续多次 Handoff，但：

• 没新增 Evidence；
• 没生成 Artifact；
• 没完成子任务；

系统应该停止继续循环。

权限为什么不能默认继承 ​

Parent Agent 有：

Web
Database
Git
Production Deploy

不代表 Research Worker 也应该全拿到。

Delegation 时应该先收窄授权请求，再由 Policy Service 决策：

Parent Delegable Scope
∩
Task Required Permission
=
Worker Authorization Request

Worker Authorization Request
→ Policy Service Decision
→ Scoped Ticket
→ Harness Gate
→ Execution Verification

这叫 Scope Narrowing（权限收窄）。

原则是：

权限可以随着委托缩小，不应该随着委托自动扩大。

并发为什么需要资源所有权 ​

多个 Worker 同时工作时，最危险的是共享真实资源。

例如：

两个 Coding Worker
→ 同时改同一个 config

单独测试都通过，Merge 后失败。

因此并发需要明确：

• File Ownership（文件所有权）：哪些 Worker 有权修改哪些文件；
• Record Ownership（记录所有权）：数据库 / 业务对象由谁负责写；
• Workspace（工作空间）：每个 Worker 是否有隔离文件系统和中间状态；
• Lock（锁）：必须共享写资源时是否需要互斥；
• Optimistic Version（乐观版本）：提交写入时检查“我读取以后是否已被别人修改”；
• Merge Stage（合并阶段）：并行结果在哪里统一做冲突检测、集成测试和验证。

如果资源无法安全分区：

并行可能根本不应该发生。

3.3 运行时怎样治理任务树、并发和恢复 ​

Task Tree 和取消传播怎样设计 ​

Multi-Agent 任务通常天然形成 Task Tree（任务树）：

Parent Run
├─ Task A
│  ├─ Task A1
│  └─ Task A2
└─ Task B

一旦有任务树，就必须定义生命周期传播规则。

Deadline Propagation（截止时间传播） ​

Parent 只剩 30 秒时，不能给新 Worker 一个 5 分钟 Deadline。

更合理是：

child_deadline
=
min(parent_deadline, task_specific_deadline)

这样下游任务不会活得比上游业务目标更久。

Cancellation Propagation（取消传播） ​

用户取消 Parent Run 后，需要明确：

• 已排队 Worker 是否取消；
• 正在运行 Worker 是否停止；
• 已产生副作用的 Worker 是否需要 Compensation（补偿）；
• Remote Agent 是否支持真正 Task Cancel。

不能只：

Parent 返回 canceled

但后台 Worker 继续跑 20 分钟。

Failure Propagation（失败传播） ​

Worker 失败不一定让 Parent 失败。

要由 Aggregation Contract 决定：

Required Worker 失败
→ Parent Block

Optional Research Worker 失败
→ Best Effort 继续

所以 Task Tree 本质上也是：

一个明确的状态和失败传播模型。

重试、超时和结果未知怎样收敛 ​

跨 Agent 调用最危险的状态不是明确失败，而是 Unknown（结果未知）：调用方超时，但远端可能尚未接收、正在执行，也可能已经产生副作用。此时直接重试会创建重复 Worker，直接判失败又可能丢失已完成结果。

处理顺序应该是：

阅读这张图时从左向右看：先对账，再决定是否重试。重试策略需要同时约束最大尝试次数、剩余截止时间、退避、可重试错误类型和副作用幂等性；取消则要记录是否已送达 Worker，以及已经发生的外部动作是否需要补偿。平台只有同时保存逻辑委托、执行尝试和最终采纳状态，才能在 Parent 或 Worker 重启后收敛到同一个业务结果。

死锁和活锁为什么都需要进展检测 ​

死锁是多个任务互相等待资源或结果，所有任务都无法继续；活锁是 Agent 仍在路由、移交或重试，但没有产生新证据、产物或已完成子任务。只看“进程仍活着”和“模型仍在调用”无法区分正常长任务与活锁。

运行时应记录等待关系、资源所有者、最近进展时间和进展类型。等待图形成环时触发死锁处理，常见策略是超时释放、取消低优先级分支或交由人工裁决；连续多步没有有效进展时触发活锁处理，停止继续移交或重试。这里的关键不是统一设置一个较大的超时，而是把“什么算进展”定义成可观测事件。

Fan-out Storm 和背压怎样控制 ​

Multi-Agent 有一个单 Agent 很少遇到的风险：

Agent 可以创建 Agent，而新 Agent 还可以继续创建 Agent。

如果：

每个 Agent 创建 5 个子 Agent

三层以后理论上就是：

1
→ 5
→ 25
→ 125

这叫 Fan-out Storm（扇出风暴）。

不能只靠 Prompt 说：

“不要创建太多 Agent。”

平台必须有硬限制。

Concurrency Limit（并发上限） ​

限制：

• 每个 Run 最大活跃 Worker；
• 每个 Tenant 最大并发；
• 每种高成本 Worker 最大数量。

Admission Control（准入控制） ​

当系统资源不足时，新 Worker 不能无限进入。

可以：

• 排队；
• 拒绝；
• 降级成 Single Agent；
• 减少 Fan-out。

Backpressure（背压） ​

如果下游：

• Model Provider；
• Browser；
• Tool；
• Database；

已经过载，上游 Supervisor 应该降低派发速度，而不是继续创建任务。

Fan-out Budget（扇出预算） ​

除了并发数，还应该限制：

Total Child Tasks
Total Model Calls
Total Tool Calls
Total Cost

这意味着：

Multi-Agent 的自治必须运行在确定性的资源预算之内。

Multi-Agent Trace 应该看到什么 ​

普通 Agent Trace 只需要回答：

一次 Run 做了哪些 Model / Tool Call。

Multi-Agent Trace 还必须表达 Coordination Topology（协调拓扑）。

至少需要看到：

Parent Run
↓ delegated
Worker A
↓ produced
Artifact A

Parent Run
↓ delegated
Worker B
↓ failed
Timeout

关键关联字段包括：

• parent_run_id；
• child_run_id；
• delegation_id；
• task_id；
• active_agent；
• handoff_from / handoff_to；
• artifact_id；
• verification_result。

为什么需要 delegation_id？

因为同一个 Parent 可能多次调用同一个 Worker。

只知道：

worker = research_agent

不足以区分哪一次委托导致问题。

Multi-Agent Observability（多智能体可观测性）最终应该回答：

• 谁创建了这个 Worker；
• 为什么创建；
• 传了什么 Context；
• 花了多少成本；
• 返回了什么；
• 结果有没有被采纳；
• 哪一跳第一次出现错误；
• 错误如何传播到最终结果。

没有这层 Trace，Multi-Agent 的 Debug 成本会迅速失控。

为什么需要持久化 Multi-Agent Runtime ​

Multi-Agent 系统一旦进入长任务和跨服务场景，Supervisor 不能只靠内存记住：

• 创建了哪些 Worker；
• 哪些已经完成；
• 哪些仍在等待；
• 哪些结果已经被合并。

因为 Supervisor 自己也会：

• 崩溃；
• 重启；
• 扩容；
• 升级版本；
• 被调度到另一台机器。

所以生产级 Multi-Agent 需要 Durable Multi-Agent Runtime（持久多智能体运行时）。

它至少要持久化：

Supervisor 崩溃以后怎么办 ​

错误做法：

Supervisor 内存里有 5 个 Worker
→ Supervisor crash
→ 重启
→ 又创建 5 个 Worker

这会产生重复任务。

正确方式：

恢复 Parent Checkpoint
→ 查询 child_run_id 状态
→ 已完成的不重建
→ 运行中的继续观察
→ 未创建成功的再补建

这里的核心不是“重启 Supervisor”，而是：

重建对整个 Task Tree 的真实认知。

Parent 重启以后怎样避免重复 Worker ​

创建 Worker 时应该使用稳定 delegation_id / operation_id。

同一个委托如果因为网络失败再次提交：

create_worker(delegation_id = D123)

Runtime 应该能判断：

D123 已经存在，不要再创建第二个逻辑 Worker。

这和《Agent 运行时与持久执行》中的幂等副作用问题完全一致。

Worker 返回时 Parent 已经重启怎么办 ​

Worker 的结果不能只发到某个 Supervisor 进程内存。

更稳妥：

Worker Result
→ Durable Result Store / Artifact Store
→ Event / State Update
→ Parent Runtime 重新读取

这样 Parent 重启以后仍然可以继续 Join / Merge。

Join 为什么也是持久状态 ​

例如：

并行 5 个 Worker
→ 至少 3 个成功即可继续

这不是简单的内存计数器。

系统需要持久记录：

• 哪 3 个已经完成；
• 哪些结果被采用；
• 是否已经触发 Merge；
• Merge 是否已经执行。

否则重启后可能重复 Merge 或错误等待。

所以：

Multi-Agent Orchestration 不是 Supervisor Prompt，而是一套需要 Durable State 的分布式执行系统。

本地子智能体和远端智能体有什么区别 ​

逻辑上，它们都可以叫“另一个 Agent”。

但工程复杂度差异非常大。

Local Subagent（本地子智能体） ​

通常：

• 同进程或同 Runtime；
• 低网络延迟；
• 身份和 Trace 容易共享；
• 状态存储边界简单；
• Failure Domain 较小。

适合：

• Agent as Tool；
• 小型专业化；
• 低延迟子任务。

Same-platform Worker（同平台工作智能体） ​

可能是独立 Worker，但仍在同一 Agent Platform 内。

需要额外处理：

• Queue；
• Scheduling；
• Durable State；
• Resource Quota；
• Retry。

Remote Agent（远端智能体） ​

跨服务以后，逻辑上的“调用另一个 Agent”会变成真正的分布式系统调用，因此新增：

• Network Timeout（网络超时）：调用方无法通过一次超时判断远端任务有没有真实开始；
• Authentication（认证）：远端服务必须验证调用 Agent / 用户身份；
• Protocol Version（协议版本）：双方可能独立升级，需要兼容协商；
• Task Identity（任务身份）：长任务需要稳定 task_id / operation_id，不能绑定单次连接；
• Partial Failure（部分失败）：远端 Agent 失败时 Parent 可能仍可继续其他分支；
• SLA（服务等级）：跨团队服务需要明确时延、可用性和责任边界；
• Trace Propagation（追踪传播）：本地 Run 必须能继续关联到远端 Task 和结果。

Cross-organization Agent（跨组织智能体） ​

还会进一步新增：

• Trust Domain（信任域）：双方依据什么身份、策略和审计规则建立信任；
• Identity Federation（身份联合）：不同身份系统怎样映射同一用户或服务主体；
• Delegated Credential（委托凭证）：远端 Agent 代表谁执行，以及权限如何继续收窄；
• Data Boundary（数据边界）：哪些数据可以跨组织传输、留存和再次使用；
• Contract / Compliance（合同与合规）：数据处理、模型使用和监管责任如何约束；
• Incident Ownership（故障责任）：跨组织失败由谁响应、取证和恢复。

所以工程复杂度大致是：

Local Subagent
<
Same-platform Worker
<
Remote Agent
<
Cross-organization Agent

这也是为什么：

同进程能解决的问题，不应该为了“标准化”强行升级成远程 Agent。

只有当独立部署、团队所有权、跨语言、跨供应商或跨组织边界真实存在时，Remote Agent 才有足够收益。

四、怎样判断 Multi-Agent 到底值不值 ​

4.1 Multi-Agent 净收益怎么看 ​

核心不是：

“我们有几个 Agent？”

而是：

拆分后的净收益是否为正。

可以用概念模型：

Multi-Agent Net Benefit
=
Parallelism Gain
+ Context Isolation Gain
+ Permission Isolation Gain
+ Specialization Gain
+ Failure Containment Gain
-
Coordination Cost
-
Context Duplication Cost
-
Merge Cost
-
Error Propagation Cost
-
Runtime / Scheduling Cost

这个公式不是为了精确打分，而是为了阻止：

“感觉拆开更专业。”

这种架构决策。

4.2 Latency：并行不一定更快 ​

单 Agent 时间：

T_single

Multi-Agent 时间：

T_multi
≈
max(worker_time)
+ delegation
+ queueing
+ merge
+ verification

只有：

T_multi < T_single

才有真正时延收益。

如果每个 Worker 很快，但 Merge 很慢：

并行仍然可能更慢。

4.3 Cost：Agent 数量不是成本倍数 ​

真实 Multi-Agent 成本至少包含：

• Parent Context（父上下文）：主 Agent 自己每轮仍需处理的上下文；
• Delegation Prompt（委托提示）：为每个 Worker 重新描述目标和边界；
• Worker Context（子上下文）：每个 Worker 独立加载专业信息；
• Worker Result（子结果）：返回结果再次进入 Parent Context；
• Supervisor Merge（主管合并）：综合多个结果还需要额外模型推理；
• Verification（验证）：验证子结果和最终结果的额外计算；
• Retry（重试）：子任务失败会放大重复成本；
• Handoff（移交）：控制权切换也会增加模型调用和 Context 处理；
• Runtime（运行时）：并发调度、状态和等待都消耗平台资源；
• Tool（工具）：外部搜索、数据库、Browser、Sandbox 本身也有成本。

所以：

Agent Count × N

并不等于：

Cost × N

成本可能超线性增长。

4.4 Multi-Agent 不天然更可靠 ​

只有当拆分真正带来：

• Failure Isolation（故障隔离）：某个 Worker 失败不会拖垮整个任务；
• Smaller Context（更小上下文）：减少无关信息和 Tool 混淆；
• Independent Verification（独立验证）：关键结果可以被另一个机制校验；
• Permission Reduction（权限收窄）：单个 Agent 被攻破时影响范围更小；

并且这些收益大于新增的：

• More Failure Points（更多失败点）：每个 Agent / Queue / Merge 都可能失败；
• Message Loss（消息丢失）：跨 Agent 通信带来网络和投递风险；
• Merge Conflict（合并冲突）：并行结果可能互相矛盾；
• Error Propagation（错误传播）：局部错误可能通过协调层扩散；

可靠性才会上升。

4.5 企业决策树 ​

建议按这个顺序判断：

单 Agent 能否稳定完成？
├─ 能
│  → 保持 Single Agent
│
└─ 不能
   ↓
   问题是不是主要来自确定性步骤太多？
   ├─ 是
   │  → Workflow
   │
   └─ 否
      ↓
      是否存在明确 Context / Capability / Permission / Parallelism / Ownership 边界？
      ├─ 否
      │  → 先优化 Single Agent / Context / Tool
      │
      └─ 是
         ↓
         子任务是否边界稳定、结果可验证？
         ├─ 否
         │  → 暂不拆
         │
         └─ 是
            ↓
            选择 Agent as Tool / Router / Handoff / Parallel / Supervisor

4.6 什么时候应该把协调能力平台化 ​

一个团队只有少量、边界稳定的 Agent 时，应用内代码通常足够。平台化应由重复出现的生产信号触发，而不是由 Agent 数量本身触发：多个团队开始重复实现委托标识、任务树、取消传播、权限收窄、预算、Trace 和故障对账；跨应用无法复用同一种 Worker；或者审计方无法从统一入口回答“谁代表谁做了什么”。

平台适合收敛稳定不变量，例如身份传播、持久任务、配额、遥测字段和产物协议；不应过早统一业务拆解策略、领域提示词和结果语义。后者变化快且依赖场景，强行平台化会把应用迭代变成平台排期。

平台化没有消除复杂度，只是把复杂度从每个应用转移到共享控制面。转移后新增的责任包括多租户隔离、兼容升级、配额公平、平台故障半径和统一值班。只有重复建设成本与治理收益持续高于这些平台责任，并且应用仍保留降级或退出路径时，平台化才有净收益。

五、主流实现到底怎样做 Multi-Agent ​

5.1 先用统一维度看清六种实现路线 ​

先看控制权、Context、状态、并行、Handoff、聚合和 Durable Runtime 放在哪里，再看具体产品。产品只用于验证这些架构差异。

统一维度横向比较 ​

单看“支持哪些模式”价值有限，更重要的是比较：

这张表最重要的不是“谁最好”，而是看出真正的分歧。

分歧一：控制权应该集中还是转移 ​

OpenAI 明确区分：

Agent as Tool
→ Manager 保持控制

Handoff
→ Specialist 接管控制

LangChain 也做类似区分。

Microsoft 则把 Handoff 作为多种 Orchestration 中的一种。

这说明：

控制权模型必须显式设计，不能靠 Prompt 隐式猜。

分歧二：Context 是共享还是隔离 ​

LangChain / LangGraph 特别强调 Context Engineering。

OpenAI 的 Agent as Tool 也天然形成局部 Context。

AWS Supervisor 模式则更依赖 Supervisor 与 Collaborator 的职责划分。

所以架构设计必须明确：

Shared Context
vs
Projected Context
vs
Isolated Context

分歧三：确定性 Workflow 放多重 ​

Google ADK 和 Microsoft 更强调 Agent + Workflow / Graph 混合。

OpenAI SDK 更偏轻量 Agent 原语。

这说明：

企业复杂任务越强调可靠性，越应该把确定性步骤留给 Workflow / Runtime，而不是全部交给 Agent 协商。

分歧四：Durable Runtime 由谁负责 ​

一些 Framework 只定义多 Agent 协作模式。

真正生产运行仍需要：

• Durable State；
• Queue；
• Retry；
• Checkpoint；
• Worker Recovery。

所以 Framework 支持 Multi-Agent，不等于企业已经拥有 Production Multi-Agent Runtime。

主流实现共同收敛了什么 ​

跨 OpenAI、LangChain、Microsoft、AWS、Google，可以看到五个共同方向。

第一，Single Agent 仍然是重要默认选项。

第二，Agent as Tool / Subagent 是最容易治理的拆分方式之一。

第三，Handoff 代表控制权切换，不只是普通调用。

第四，Parallelism 的价值必须用时延 / Token / Context 实际证明。

第五，确定性 Workflow 与 Agentic Decision 正在融合，而不是互相替代。

所以企业不应该建设：

“万能 Multi-Agent Framework。”

而应该建设：

少量稳定 Coordination Primitive（协调原语）+ 清晰的任务 / Context / Permission / Artifact Contract。

5.2 再看各家实现怎样体现这些差异 ​

OpenAI：控制权是核心区别 ​

OpenAI Agents SDK 当前明确区分两种主要模式：

Agents as Tools（Agent 作为工具）

Manager Agent 保留：

• 用户会话控制权；
• 最终答案；
• Specialist 调用时机。

适合：

Specialist 只是有边界的子任务执行者。

Handoffs（移交）

Specialist 接管当前会话的 Active Agent 身份。

适合：

后续用户交互应该由 Specialist 直接负责。

这说明：

多 Agent 模式最根本的区别之一，是“谁拥有下一步控制权”。

[^openai-orchestration][^openai-handoffs]

LangChain / LangGraph：上下文工程是核心 ​

LangChain 当前的 Multi-agent 文档明确提醒：

复杂任务并不等于一定需要 Multi-Agent；单 Agent 配合正确的动态 Tool 和 Prompt，很多时候足够。[^langchain-multi-agent]

它把常见模式分成不同控制和上下文策略：

• Subagents（子智能体）：主 Agent 把有边界的子任务交给独立 Agent，适合 Context / Tool 隔离；
• Handoffs（移交）：当前 Agent 把后续会话控制权转给另一个 Agent；
• Skills（技能）：不一定创建新的 Agent，而是按需加载专业知识和工具；
• Router（路由）：通常只做一次任务分类，把请求送到最合适的 Agent；
• Custom Workflow（自定义工作流）：把确定性节点和 Agent 决策节点组合起来。

更值得关注的是它给出的性能对比。

在多 Domain（领域）任务里，Subagents / Router 可以通过 Context Isolation 减少 Token；而 Handoff 更适合持续直接用户交互。[^langchain-multi-agent]

这验证了一个重要判断：

Multi-Agent 的核心设计问题之一，不是 Agent 数量，而是 Context 如何分配。

Microsoft：编排模式是工具箱 ​

Microsoft Agent Framework 当前提供多种编排原语，而且每一种都对应不同问题：

• Sequential（顺序编排）：上一步完成后再进入下一步，适合强依赖流程；
• Concurrent（并发编排）：多个独立任务并行执行，适合缩短关键路径；
• Handoff（移交）：把当前控制权转给更合适的专业 Agent；
• Group Chat（群组对话）：多个 Agent 在共享讨论空间里交互，适合探索但治理成本高；
• Magentic（动态管理式编排）：由 Manager 根据当前状态持续规划和分配任务。

官方文档的含义非常明确：

不同 Orchestration 是不同问题的工具，而不是成熟度层级。[^microsoft-orchestration]

AWS：Supervisor 模式的现实边界 ​

Amazon Bedrock Agents 的多智能体协作公开实现提供了典型的 Supervisor / Collaborator（主管与协作者）模型。这里把它作为架构案例，而不据此推导 AWS 其他产品线的选型结论。[^aws-multi-agent]

它使用：

Supervisor（主管智能体）
+
Collaborator Agents（协作智能体）

Supervisor 可以：

• 汇总多个 Collaborator；
• 或只做 Routing，让 Collaborator 直接响应。

AWS 的公开文档还要求明确每个 Agent 的职责、减少职责重叠。[^aws-multi-agent]

这个实现说明两个事实：

第一：

Supervisor 本身就是成本和延迟中心。

第二：

Collaborator 职责重叠越高，协调价值越低。

Anthropic Research：Orchestrator–Worker 为什么适合高并行研究，而不适合所有任务 ​

Anthropic 的 Research 产品是一个很有价值的真实 Multi-Agent 生产案例：Lead Agent 负责制定研究策略并创建多个并行 Subagent，Subagent 独立搜索、筛选和压缩信息，再把高价值结果交回 Lead Agent。[^anthropic-multi-agent-research]

它证明了 Multi-Agent 的几个核心收益：

1. Parallel Search（并行搜索）：多个独立方向可以同时探索；
2. Context Isolation（上下文隔离）：每个 Subagent 有自己的 Context Window，不必让主 Agent 承担全部搜索轨迹；
3. Compression Boundary（压缩边界）：Subagent 把大规模外部信息压成高价值 Finding，再交给 Lead Agent；
4. Specialization（专业化）：不同 Agent 可以使用不同 Prompt / Tool / Search Strategy。

但更重要的是它公开了代价和适用边界。

Anthropic 的内部研究 Eval 中，多智能体方案在适合 Breadth-first（广度优先）的任务上明显优于单智能体；但 Multi-Agent Token 消耗也显著更高，并且当任务具有强依赖、共享 Context 很重或难以真正并行时，收益会下降。[^anthropic-multi-agent-research]

这直接支持本文前面的判断：

Multi-Agent 的核心不是“Agent 数量”，而是有没有足够独立的 Decision / Context / Work Partition（工作分区）来抵消 Coordination Cost。

Anthropic 还暴露了几个非常生产化的 Failure：

• Lead Agent 一次生成过多 Subagent；
• 不同 Subagent 重复搜索同一方向；
• Tool Description 不清导致走错搜索路径；
• 同步等待某个慢 Subagent 造成整体阻塞；
• 大结果都经主 Agent 转述造成信息损失。

其中最后一个问题又验证了本文的另一条原则：

Shared Artifact / Durable Result 往往比让所有信息经过主 Agent 的 Chat 更可靠。

Google ADK：智能体和工作流可混合 ​

Google ADK 的设计方向强调：

Agent 节点和确定性 Workflow / Graph 可以混用。

这很重要。

因为生产系统不应该在：

全部 Deterministic

和：

全部 Agentic

之间二选一。

更合理的是：

需要推理
→ Agent

需要稳定顺序 / Gate / Retry
→ Workflow / Runtime

所以 Multi-Agent 最成熟的形态通常不是“Agent 自由聊天”，而是：

确定性编排框架里嵌入有限的智能决策节点。

六、生产故障怎样推演和防止 ​

本章案例是基于前述机制构造的故障推演，不是对某家企业真实事故的陈述。它们用于回答三个问题：故障如何出现，简单修补为什么不够，以及上线前用什么证据证明防线有效。

6.1 并行和共享资源怎样产生故障 ​

两个 Coding Agent 同时改同一份文件 ​

现象 ​

Worker A 修改：

config.yaml

Worker B 也修改：

config.yaml

两个 Worker 单独测试都通过。

合并后系统失败。

为什么最初看起来合理 ​

团队认为：

“两个 Agent 在不同子任务上工作，应该可以并行。”

问题是：

子任务逻辑独立，不代表写资源独立。

根因 ​

没有定义 Resource Ownership（资源所有权）。

正确做法 ​

每个 Worker
→ 独立 Worktree / Workspace

完成后
→ Integration Stage

统一
→ Merge + Test

如果多个 Worker 必须写同一对象，则需要：

• Lock；
• Version Precondition；
• Conflict Detection。

架构结论 ​

并行边界必须由资源所有权决定，不是由 Prompt 里的“任务不同”决定。

Research Workers 重复研究 ​

现象 ​

8 个 Worker 并行。

结果：

• Query 高度相似；
• Source 重叠；
• 最终 Evidence 重复。

成本明显增加，Coverage 却没增加。

根因 ​

Supervisor 只说：

“你们分别研究一下。”

没有定义互斥研究边界。

正确做法 ​

Delegation Contract 明确：

• Unique Research Question；
• Exclusion；
• Source Constraint；
• Expected Evidence。

并做 Duplicate Task Detection（重复任务检测）。

验证方式 ​

比较：

Unique Source Coverage
/
Total Source Count

以及：

新增 Worker
→ 新增多少独立 Evidence

如果边际收益迅速下降，应停止继续 Fan-out。

Supervisor 变成 Context 黑洞 ​

现象 ​

每个 Worker 都把：

• 完整对话；
• 全部网页；
• 全部 Tool Result；

返回给 Supervisor。

最终 Supervisor 的 Context 比单 Agent 更大。

根因 ​

把 Worker 输出设计成“聊天历史”，而不是“任务产物”。

正确做法 ​

Worker 只返回：

Typed Result
Evidence
Artifact Reference
Open Questions

原始大内容保留在外部 Artifact Store，需要时再加载。

架构结论 ​

Subagent 的价值之一是隔离 Context，如果最后把全部 Context 再塞回 Parent，就失去了拆分意义。

6.2 控制权和信任边界怎样产生故障 ​

Handoff A ↔ B 形成死循环 ​

现象 ​

A → B
B → A
A → B
重复循环

Token 一直增长。

但：

• 没新 Evidence；
• 没新 Artifact；
• 没新 Task 完成。

根因 ​

系统只限制 Agent Turn，没有限制 Handoff Graph。

正确做法 ​

• Visited Agent Set；
• Max Hop；
• Progress Signal；
• Loop Detection；
• Escalation。

验证 ​

定义：

Progress =
New Evidence
or
New Artifact
or
Completed Subtask
or
Resolved Uncertainty

连续 N 次 Handoff 无 Progress 就终止。

弱 Worker 的错误被升级成全局事实 ​

现象 ​

Worker A 输出错误结论：

X

Supervisor 没验证，直接把 X 写进最终 Plan。

其他 Worker 继续基于 X 工作。

局部错误被放大。

根因 ​

没有区分：

Agent Claim

和：

Verified Fact

正确做法 ​

高影响中间结论必须带：

• Evidence；
• Provenance；
• Confidence；
• Verification Status。

只有通过 Verification Gate 才能进入 Shared Truth。

Fan-out 让成本超线性增长 ​

现象 ​

1 Parent
× 8 Workers
× 每个 40k Context
× 2 次 Retry

表面看是 8 个 Agent。

真实成本还包括：

• Parent Planning；
• Delegation；
• Worker Context；
• Result；
• Merge；
• Verification；
• Retry；
• Runtime。

正确做法 ​

• Minimal Context Pack；
• Worker Budget；
• Dynamic Fan-out；
• Early Stop；
• Cost-aware Routing；
• Duplicate Task Detection。

架构结论 ​

Fan-out Count 必须是系统预算变量，不能是模型自由发挥变量。

Subagent 继承 Parent 全量权限 ​

现象 ​

Research Worker 只是查网页。

却继承了 Parent 的：

Database Write
Git Merge
Production Deploy

根因 ​

把 Delegation 当成“复制一个 Agent”。

正确做法 ​

每次委托先收窄请求，再走统一授权链：

Parent Delegable Scope
∩
Task Required Scope
=
Worker Authorization Request

Worker Authorization Request
→ Policy Service
→ Scoped Ticket
→ Harness Gate
→ Execution Verification

架构结论 ​

多 Agent 的一个真实收益应该是权限隔离；如果拆完反而复制全权限，就失去了重要价值。

Supervisor 凭感觉合并结果 ​

现象 ​

三个 Worker 给出不同结论。

Supervisor 直接选择“看起来最合理”的一个。

根因 ​

没有 Aggregation Contract。

正确做法 ​

根据任务选择：

• Deterministic Checker；
• Evidence Ranking；
• Quorum；
• Schema Merge；
• Human Resolve。

架构结论 ​

Merge 本身也是一个需要设计和验证的计算阶段。

七、怎样验证 Multi-Agent 真的创造了价值 ​

7.1 不要看 Agent 数量 ​

不要用：

“我们已经有 12 个 Agent”

证明系统先进。

应该看：

• Verified Success；
• End-to-end Latency；
• Cost per Successful Run；
• Error Propagation；
• Duplicate Work；
• Human Intervention；
• Merge Conflict。

7.2 核心指标分别代表什么 ​

Coordination Overhead（协调开销）

协调 Token / 总 Token

越高说明大量资源花在“Agent 互相解释”。

Parallel Efficiency（并行效率）

比较：

理论串行时间
vs
真实并行端到端时间

如果并行后只快 5%，但成本翻 4 倍，可能不值得。

Duplicate Work Rate（重复工作率）

多个 Worker 是否在做高度相似任务。

Cross-agent Error Propagation（跨 Agent 错误传播率）

局部错误有多少次污染了其他 Worker 或最终结果。

Merge Conflict Rate（合并冲突率）

并行结果多少次无法自动合并。

Worker Utilization（Worker 有效利用率）

Worker 启动以后，有多少真正产生有效贡献。

7.3 怎样设计可归因的 Multi-Agent 实验 ​

不要从：

1 Agent

一次性改成：

8 Agent

然后比较总成功率。

因为你无法知道变化来自：

• Worker 数；
• Model；
• Delegation Prompt；
• Merge Strategy；
• Context；
• Verification。

更好的方式是分别灰度：

Fan-out Count
Worker Model
Delegation Contract
Context Pack
Merge Strategy
Verification Strategy

7.4 什么情况下应该退回 Single Agent ​

如果 Multi-Agent 以后出现：

• 成功率没提升；
• 成本明显上涨；
• 延迟更慢；
• Debug 时间变长；
• Worker 大量重复；
• Context 最后仍然汇总回一个 Agent；

就应该考虑：

重新合并。

架构不是只能“拆出去”，也要允许“收回来”。

7.5 发布和灰度为什么要拆变量 ​

Multi-Agent Release（多智能体发布）不能只记录一个：

system_version = v12

因为结果可能同时受这些变量影响：

• Worker Count（Worker 数量）；
• Worker Model（Worker 模型）；
• Routing Policy（路由策略）；
• Delegation Contract（委托契约）；
• Context Projection（上下文投影）；
• Merge Strategy（合并策略）；
• Verification Policy（验证策略）。

如果一次同时改 5 个变量，成功率上升或下降都无法归因。

通用发布链路由《企业级 Agent 平台参考架构》统一定义；本文只强调多智能体特有的发布对象：

真正需要版本化的是 Coordination Topology（协调拓扑）和每条边上的 Contract，而不是一个笼统的 system_version。

至少要记录 Worker Count / Model、Routing Policy、Delegation Contract、Context Projection、Merge Strategy 和 Verification Policy。一次只改变少量变量，才能把质量、成本和延迟变化归因到具体协调机制。

7.6 容量规划为什么不能只看请求 QPS ​

Multi-Agent 平台还要关注：

• Active Worker Count（活跃 Worker 数）；
• Fan-out Width（扇出宽度）；
• Task Tree Depth（任务树深度）；
• Concurrent Model Calls（并发模型调用）；
• Waiting Child Tasks（等待中的子任务）；
• Merge Queue（合并队列）；
• Artifact Throughput（产物流量）；
• Coordination Token（协调 Token）。

例如用户 QPS 只有 10：

10 User Requests
× 8 Workers
× 2 Retry
=
最多 160 个 Worker Execution

所以外部请求量很低，也可能把内部 Runtime 和 Model Provider 打满。

容量规划必须从：

User Request

进一步展开成：

Task Amplification Factor（任务放大系数）

这也是为什么 Fan-out 必须被平台治理。

7.7 Multi-Agent 评测为什么不能只看成功率 ​

一个系统最终成功，不代表每个 Worker 都有价值。

例如：

8 个 Worker
→ 只有 2 个结果被最终采用
→ 其余 6 个没有产生独立贡献

总成功率可能很好，但架构明显浪费。

所以 Multi-Agent Evaluation（多智能体评测）要同时评估：

Delegation Success（委托成功） ​

Parent 交给 Worker 的任务：

• 是否边界清楚；
• Worker 是否真正完成；
• 是否因为任务描述不清反复返工。

Contribution Rate（贡献率） ​

Worker 输出有多少真正进入：

• 最终 Artifact；
• 最终 Plan；
• Verified Fact；
• 用户答案。

如果某个 Worker 长期启动但结果从不被采用，它很可能没有存在价值。

Marginal Utility（边际效用） ​

新增一个 Worker 后：

质量增加多少
延迟减少多少
成本增加多少

真正要看：

新增一个 Agent 带来的边际收益。

Merge Acceptance Rate（合并采纳率） ​

并行结果进入 Merge 后，有多少：

• 被直接采纳；
• 被修改；
• 被丢弃；
• 因冲突需要人工处理。

高丢弃率说明任务拆分或 Worker 质量有问题。

Topology Ablation（拓扑消融） ​

这是非常重要的评测方法。

例如：

完整拓扑
→ 8 Workers

然后分别做：

去掉 Worker C
去掉 Reviewer
把 Handoff 改成 Agent as Tool
把 8 路 Fan-out 改成 4 路

观察：

• Verified Success；
• Cost；
• Latency；
• Error Propagation。

如果去掉某个 Agent 后质量不变、成本下降：

这个 Agent 大概率不应该存在。

Error Attribution（错误归因） ​

Multi-Agent 失败时，不只标记：

task_failed

而应该找到第一处偏离：

Delegation Error
Context Error
Worker Decision Error
Tool Error
Merge Error
Verification Error

否则团队只能：

“整个 Multi-Agent 系统不稳定。”

却不知道应该改哪一层。

最终：

Multi-Agent Eval 的目标不是证明“多 Agent 能工作”，而是证明“每一个新增 Agent 和每一条协调边都值得存在”。

7.8 平台采购与自建怎样做可退出的验证 ​

采购多智能体框架时，演示中的“多个 Agent 能对话”几乎没有区分度。真正影响生产采用的是：任务和结果是否持久化，控制权与权限是否显式，失败后能否对账，协调拓扑能否观测和版本化，以及平台退出时能否带走关键资产。

概念验证（Proof of Concept，PoC）应该用同一组真实任务同时跑单 Agent、确定性工作流和候选多智能体方案。除任务质量外，还要记录端到端时延、成功任务成本、重复工作率、人工介入、故障恢复时间和跨 Agent 错误传播。若供应商只展示最终答案而无法导出任务树、委托输入、执行尝试、产物和验证记录，就无法证明收益来自协调机制，也难以承担生产审计。

采购评审至少覆盖以下问题：

服务等级协议（Service Level Agreement，SLA）不能只承诺 API 可用性，还应覆盖已接收任务的状态可查性、取消语义、结果持久时间和故障责任。总拥有成本（Total Cost of Ownership，TCO）也不能只比较 Token 单价，因为协调、重试、产物存储、观测和人工排障往往决定长期成本。

采用条件可以收敛为一句话：候选平台必须在真实任务上证明多智能体相对简单基线有稳定净收益，并且核心委托契约、产物和遥测能够迁移。否则先保留单 Agent 或确定性工作流，把多智能体作为局部能力，而不是平台前提。

八、最终架构判断 ​

本文最终留下十条稳定的架构判断：

1. Multi-Agent 不是成熟度等级，默认仍然应该从 Single Agent 开始。

2. Workflow 解决确定性执行结构，Multi-Agent 解决多个独立决策边界。

3. 拆 Agent 的真正理由是 Context、Capability、Permission、Parallelism、Specialization、Ownership 或 Failure Boundary。

4. Agent as Tool 和 Handoff 最大区别之一是控制权是否转移。

5. Context Isolation 是 Multi-Agent 最重要的潜在收益之一，但 Context Duplication 也是最主要成本之一。

6. 多 Agent 以后，Delegation Contract、Ownership、Partial Failure、Aggregation Contract 都必须成为一等机制。

7. Shared Artifact 通常比 Shared Chat 更适合作为生产协作接口。

8. Worker 输出是 Claim，不是 Shared Truth；高影响事实必须经过 Verification Gate。

9. Fan-out Count、Handoff Hop、Worker Budget 都应该是平台预算变量。

10. 只有 Multi-Agent Net Benefit > 0 时，拆分才真正值得。

附录 A：高频架构问题与快速回答 ​

附录只用于快速复述，不再复制正文完整推导；需要机制细节时回到对应章节。

A.1 什么情况下应该拆成多智能体 ​

至少应该出现一个明确边界：

• Context；
• Capability；
• Permission；
• Parallelism；
• Model Specialization；
• Ownership。

如果只是“任务很复杂”，但所有步骤共享相同 Context、Tool 和权限，优先考虑 Workflow 或增强单 Agent。

A.2 工作流和多智能体最大区别是什么 ​

Workflow 的控制结构主要由系统定义。

Multi-Agent 至少存在多个独立模型决策主体。

一个 Workflow 可以包含 Agent，一个 Agent 也可以调用 Workflow。

所以两者不是互斥关系。

A.3 Agent as Tool 和 Handoff 如何选择 ​

如果主 Agent 应该继续：

• 面向用户；
• 汇总结果；
• 保持全局控制；

用 Agent as Tool。

如果 Specialist 应该：

• 接管后续会话；
• 使用自己的 Prompt / Tool；
• 成为当前 Active Agent；

用 Handoff。

A.4 为什么不能照搬人类岗位拆 Agent ​

因为人类组织结构主要解决：

• 人员专业；
• 责任；
• 管理跨度。

机器 Agent 的拆分更应该看：

• Context；
• Permission；
• Tool；
• Parallelism；
• Failure Boundary。

如果一个模型能低成本完成规划、实现和测试，强行复制人类岗位只会增加协调。

A.5 为什么 Multi-Agent 会变成分布式系统 ​

因为多个 Agent 意味着：

• 多个执行主体；
• 多份状态；
• 多个失败点；
• 多个结果。

因此必然出现 Ownership、Partial Failure、Consistency、Scheduling、Merge。

区别只是这些节点还是非确定性的。

A.6 Supervisor 为什么容易成为瓶颈 ​

因为所有 Worker：

任务来自 Supervisor
结果回 Supervisor
下一步再由 Supervisor 决定

如果 Worker 返回大量 Context，Supervisor 的 Token、Latency 和推理复杂度会不断增长。

解决方法不是“换更大模型”，而是：

• 结构化 Result；
• Artifact；
• 局部 Merge；
• Hierarchical Coordination；
• Context Projection。

A.7 为什么共享产物比共享聊天可靠 ​

Artifact 可以：

• Schema 校验；
• Version；
• Diff；
• Evidence；
• Provenance；
• Access Control。

Chat 更适合交流，不适合作为长期共享事实存储。

A.8 多 Agent 怎样做权限最小化 ​

不要复制 Parent 权限。

应该：

Parent Permission
∩ Task Required Permission
∩ Policy

得到 Worker Permission。

委托链越深，权限应该保持或收窄。

A.9 怎样避免 Handoff 死循环 ​

至少需要：

• Visited Agent；
• Max Hop；
• Progress Signal；
• Escalation。

不要只限制 Turn Count。

因为系统可能每一轮都在“合法 Handoff”，但没有任何任务进展。

A.10 并行 Agent 怎样判断是否真的有收益 ​

比较：

Latency Delta
Cost Delta
Verified Success Delta
Unique Evidence Delta

只有时延 / 质量收益能够覆盖成本和 Merge 开销，才值得保持并行。

A.11 Partial Failure 应该怎样处理 ​

不要默认：

“有一个 Worker 失败，整个系统失败。”

而要根据业务选择：

• All Required；
• Quorum；
• Best Effort；
• First Successful；
• Human Resolve。

这是 Aggregation Contract。

A.12 Multi-Agent 什么时候应该重新合并 ​

如果拆分后：

• 没产生 Context / Permission / Parallelism 收益；
• 协调成本长期过高；
• Agent 边界高度重叠；
• Worker 频繁重复工作；
• Merge 成为主要失败点；

应该重新合并。

架构拆分不是单向演进。

[^anthropic-multi-agent-research]: Anthropic, How we built our multi-agent research system, 2025-06-13. https://www.anthropic.com/engineering/multi-agent-research-system [^openai-orchestration]: OpenAI Agents SDK, Orchestrating multiple agents. https://openai.github.io/openai-agents-python/multi_agent/ [^openai-handoffs]: OpenAI Agents SDK, Handoffs. https://openai.github.io/openai-agents-python/handoffs/ [^langchain-multi-agent]: LangChain, Multi-agent. https://docs.langchain.com/oss/python/langchain/multi-agent [^langchain-router]: LangChain, Router. https://docs.langchain.com/oss/python/langchain/multi-agent/router [^microsoft-orchestration]: Microsoft Agent Framework, Workflow orchestrations. https://learn.microsoft.com/en-us/agent-framework/workflows/orchestrations/ [^aws-multi-agent]: Amazon Bedrock, Multi-agent collaboration. https://docs.aws.amazon.com/bedrock/latest/userguide/agents-multi-agent-collaboration.html

附录 B：主要官方资料 ​

动态事实以 2026-09-13 为核验基线：

• OpenAI Agents SDK — Agent orchestration
  https://openai.github.io/openai-agents-python/multi_agent/

• OpenAI Agents SDK — Handoffs
  https://openai.github.io/openai-agents-python/handoffs/

• Microsoft Agent Framework — Workflow orchestrations
  https://learn.microsoft.com/en-us/agent-framework/workflows/orchestrations/

• LangChain — Multi-agent
  https://docs.langchain.com/oss/python/langchain/multi-agent

• LangChain — Subagents / Handoffs / Router
  https://docs.langchain.com/oss/python/langchain/multi-agent/subagents
  https://docs.langchain.com/oss/python/langchain/multi-agent/handoffs
  https://docs.langchain.com/oss/python/langchain/multi-agent/router

• Amazon Bedrock — Multi-agent collaboration
  https://docs.aws.amazon.com/bedrock/latest/userguide/agents-multi-agent-collaboration.html

• Google Agent Development Kit
  https://google.github.io/adk-docs/