Anthropic 研究指出，随着 AI 智能体在共享代码库、市场等社会系统中承担更多任务，智能体间交互量或将超过人机交互。实验显示，45 个协调智能体在 2700 万 token 运行中发现 266 个漏洞，而独立并行方法在 650 万 token 中仅发现 21 个，两种方法仅有 12 个重叠，且协调智能体学会专业化分工。研究同时警示个体层面的良性行为怪癖可能叠加为意外的系统性失败。
Agent 运行时过载
协调智能体的专业化分工
从独立并行到协作发现
独立并行方法的问题在于每个智能体只看到局部视图。45 个协调智能体通过共享上下文和任务分解，形成了类似「代码审查流水线」的协作结构：有的负责静态分析，有的负责边界条件，有的负责跨模块依赖追踪。这种分工不是预设的，而是在 2700 万 token 的运行中自发涌现的。
相比之下，独立并行的 21 个漏洞发现几乎完全来自随机覆盖。两者的 12 个重叠说明协调机制确实发现了独立方法遗漏的问题，而非简单重复。
循环检测：去中心化的保命机制
Swarm 模式的灵活性来自去中心化，但去中心化也意味着没有全局视角。李文周在 M08 课程中指出，Swarm 容易形成 A → B → A 的循环转交，因此 MaxHops 是必要边界。生产系统还应记录已访问节点，以便提前发现循环。
后端系统设计
Swarm 循环风险与检测机制
去中心化系统的另一个问题是缺乏全局视角。Anthropic 研究提到，个体层面的良性行为怪癖可能叠加为系统性失败。例如，每个智能体都倾向于保守确认，导致整个系统对异常输入的反应速度下降。这种「集体平庸」在独立并行模式下不会发生，因为每个智能体是孤立的。
多智能体协作模式
Supervisor 与 Orchestrator 的取舍
Supervisor 模式采用串行、动态调度并共享任务进展，适合任务依赖关系不明确、需要实时调整的场景。Orchestrator 模式则预先分解任务、并行执行子任务，并限制子代理上下文进入主流程，适合任务结构清晰、可预见的场景。
SAP 的治理建议指出，当智能体和任务数量增加时，需要重新测试系统性能，并评估容错恢复能力。这意味着 Supervisor 的动态调度在规模扩大后可能成为瓶颈，因为所有决策都经过单一节点。
Channel Pipeline 的上下文隔离
Channel Pipeline 是最直接的拓扑，适用于批量数据依次经过固定阶段的场景。例如文档处理流水线：分类 → 检索资料 → 起草内容 → 质检。每个阶段由一个或一组 Agent 负责，阶段之间通过 channel 串联。
这种模式的核心价值是上下文隔离。每个阶段的 Agent 只需关注当前阶段的输入和输出，不需要了解上游的历史决策或下游的处理逻辑。Go 的 pipeline 并发模式提供了参考：一个阶段可以启动多个 worker 并行消费输入，再把结果汇入同一个输出 channel。
程序员日常
Google Cloud 的多代理 AI 系统架构展示了迭代优化的流程：任务子代理执行后，质量评估器检查输出，如果不满意则调用提示增强子代理优化提示，再让任务子代理重新执行。这个循环持续到输出满意或达到最大迭代次数。
治理跟不上速度的代价
个体怪癖的系统性叠加
Anthropic 研究的核心警示是：个体层面的良性行为怪癖可能叠加为系统性失败。这在多智能体系统中尤为危险，因为每个智能体的「怪癖」在独立运行时可能无害，但在协作网络中会通过反馈循环被放大。
例如，一个智能体倾向于过度确认输入，另一个智能体倾向于保守输出，两者协作时可能导致整个系统对模糊输入的响应时间呈指数级增长。这种问题在独立测试中难以发现，因为每个智能体的行为都是「合理」的。
人类监督与可审计性
SAP 的治理框架强调「人在回路」的工作流模式，确保与人类价值观保持一致。具体做法包括：设置人类监督节点，监控和防止未经授权的自主行为；保持 AI 智能体决策的可视性，建立信任；提高多智能体系统运作的透明度，满足法规要求。
大佬点头
多智能体治理闭环
治理不是事后补救，而是嵌入系统设计的。Anthropic 的实验表明，协调智能体在运行中自发形成了专业化分工，但这种分工缺乏显式的治理机制。当系统规模扩大时，这种隐式分工可能演变为不可控的协作网络。
落点：在速度与可控之间
多智能体系统的核心矛盾是：管道跑得越快，治理越要跟上。协调智能体在 Anthropic 实验中展现了超越独立并行的发现能力，但这种能力建立在 2700 万 token 的试错成本之上。对于生产系统，这个成本是不可接受的。
在任务结构清晰、依赖关系明确的场景，Orchestrator + Channel Pipeline 是更稳妥的选择。上下文隔离降低了耦合风险，预分解任务避免了动态调度的不确定性。在任务结构模糊、需要实时调整的场景，Supervisor 模式更灵活，但需要配套循环检测和人类监督节点。
无论选择哪种模式，循环检测和治理机制都不是锦上添花，而是保命机制。去中心化带来灵活性的同时，也意味着没有全局视角。当个体智能体的「良性怪癖」在协作网络中叠加时，系统可能表现出与预期完全相反的行为。
Agent 运行时过载
协调智能体并非简单地「一起干活」，而是通过任务分配与结果汇总形成了隐性的分工结构。某些智能体倾向于聚焦于代码审查，另一些则主动承担漏洞复现。这种专业化不是预设的，而是在多次交互中涌现出来的。对工程团队而言，这意味着多智能体系统的价值不在于并行加速，而在于通过协作发现单一智能体容易遗漏的边界情况。
然而，去中心化协作的代价是缺乏全局视角。Swarm 模式把「下一步由谁处理」的决策交给当前 Agent，这提升了灵活性，但也引入了循环转交的风险。一个 Agent 可能把任务转给 B，B 又转回给 A，形成 A → B → A 的死循环。生产系统必须在 handoff 工具中增加 MaxHops 边界，并记录已访问节点，以便提前检测循环。这不是锦上添花的功能，而是保命机制。
多智能体协作模式对比
Supervisor 与 Orchestrator 是两种常见的集中式协调模式，但它们的上下文管理策略截然不同。Supervisor 采用串行、动态调度，并共享任务进展；Orchestrator 则预先分解任务、并行执行子任务，并限制子代理的上下文进入主流程。前者适合任务路径不确定的场景，后者适合流程相对固定的场景。选型的关键在于：你的任务是否需要实时调整策略，还是可以在启动时确定完整路径。
Channel Pipeline 是另一种思路。当一批数据需要依次经过固定阶段时，Pipeline 是最直接的拓扑。例如批量处理文档，每条数据都要经过「分类 → 检索资料 → 起草内容 → 质检」。每个阶段由一个或一组 Agent 负责，阶段之间通过 channel 串联。这种模式的核心价值是上下文隔离：每个阶段的 Agent 只能看到本阶段的数据，不会污染全局上下文。Go 的 pipeline 并发模式提供了参考实现，一个阶段可以启动多个 worker 并行消费输入，再把结果汇入同一个输出 channel。
后端系统设计
但 Pipeline 的灵活性有限。一旦任务需要跨阶段回溯或动态调整流程，Pipeline 的刚性结构就会成为瓶颈。相比之下，Swarm 模式允许 Agent 之间自由转交任务，适应动态变化的能力更强，但代价是循环检测和状态追踪的复杂度上升。没有一种模式在所有场景下都最优，选型取决于任务的可预测性和对灵活性的需求。
治理滞后是多智能体系统最常见的隐性成本。Anthropic 的研究提到，个体层面的良性行为怪癖可能叠加为系统性失败。一个 Agent 的「过度自信」在独立运行时无伤大雅，但在协作网络中可能通过 handoff 链条放大，最终导致整个系统输出偏离预期。SAP 的治理框架建议包括：制定 AI 使用伦理规范、确定每个智能体的性能评估指标、当智能体数量增加时重新测试系统性能、评估容错恢复能力、持续监控和审计。这些建议听起来像传统软件工程的最佳实践，但在多智能体系统中，监控的粒度需要从单个 Agent 扩展到 Agent 间的交互模式。
人类监督在关键节点上是必要的，但「人在回路」的设计需要权衡。Google Cloud 的参考架构中包含了一条 human-in-the-loop 路径，允许人类用户在必要时介入智能体流程。但这种介入应该是例外而非常态，否则系统的自动化价值会被稀释。更现实的做法是设置监督阈值：当智能体协作的置信度低于某个标准时，自动触发人工复核。
打工现场
选型建议可以归纳为几条经验法则。任务路径可预测、阶段固定时，优先选择 Channel Pipeline，利用上下文隔离降低调试成本。任务路径不确定、需要动态调整时，选择 Orchestrator 模式，预先分解任务并限制子代理上下文。需要高度灵活性、能接受循环检测成本时，选择 Swarm 模式，但必须实现 MaxHops 和已访问节点记录。对可靠性要求极高的场景，Supervisor 模式配合人工监督节点是更稳妥的选择。
今天可以做的三件事：第一，审查现有智能体系统的 handoff 逻辑，确认是否实现了循环检测；第二，为每个 Agent 定义明确的上下文边界，避免信息过载；第三，在关键协作节点设置置信度阈值，低于阈值时触发人工复核。这些改动不需要重写整个系统，但能显著降低多智能体协作的隐性风险。
Agent 运行时过载
协调智能体并非简单地「一起干活」，而是通过任务分配与结果汇总形成了隐性的分工结构。某些智能体倾向于聚焦于代码审查，另一些则主动承担漏洞复现。这种专业化不是预设的，而是在多次交互中涌现出来的。对工程团队而言，这意味着多智能体系统的价值不在于并行加速，而在于通过协作发现单一智能体容易遗漏的边界情况。
然而，去中心化协作的代价是缺乏全局视角。Swarm 模式把「下一步由谁处理」的决策交给当前 Agent，这提升了灵活性，但也引入了循环转交的风险。一个 Agent 可能把任务转给 B，B 又转回给 A，形成无意义的往返。生产系统必须记录已访问节点，并设置 MaxHops 边界，否则循环检测缺失会导致 token 消耗失控。
%% title: 多智能体协调拓扑对比
flowchart LR
subgraph 集中式
S[Supervisor]
A1[Agent A]
A2[Agent B]
A3[Agent C]
end
subgraph 隔离式
O[Orchestrator]
subgraph 子任务
T1[Task 1]
T2[Task 2]
T3[Task 3]
end
end
subgraph 流水线
P1[阶段1]
P2[阶段2]
P3[阶段3]
end
S --> A1
S --> A2
S --> A3
O --> T1
O --> T2
O --> T3
P1 --> P2
P2 --> P3
Supervisor 与 Orchestrator 的取舍，本质上是「动态调度」与「预先分解」的权衡。Supervisor 采用串行、动态调度并共享任务进展，适合任务边界模糊、需要实时调整的场景。Orchestrator 则预先分解任务、并行执行子任务，并限制子代理上下文进入主流程，适合任务结构清晰、需要上下文隔离的场景。
Channel Pipeline 是另一种常见拓扑。当一批数据需要依次经过固定阶段时，Pipeline 是最直接的拓扑。例如批量处理文档，每条数据都要经过分类、检索资料、起草内容、质检四个阶段。每个阶段由一个或一组 Agent 负责，阶段之间通过 channel 串联。这正是 Go 常见的 pipeline 并发模式：一个阶段启动多个 worker 并行消费输入，再把结果汇入同一个输出 channel。
这种模式的上下文隔离价值在于：下游 Agent 不会看到上游 Agent 的完整历史，只接收经过浓缩的中间结果。代价是信息损失，某些边界情况可能在浓缩过程中被过滤掉。工程实践中，需要在信息密度与上下文长度之间找到平衡点。
[[reaction=backend-system-design|caption=系统架构设计]]
治理跟不上速度的代价，往往在系统规模扩大后才显现。Anthropic 的研究同时警示，个体层面的良性行为怪癖可能叠加为意外的系统性失败。一个 Agent 的过度自信、另一个 Agent 的回避冲突，在孤立状态下各自合理，但在协作网络中可能产生级联效应。
这意味着多智能体系统的工程落地，不能只关注单个 Agent 的能力，更要关注交互协议的设计。循环检测、上下文隔离、人类监督节点，这些机制不是锦上添花，而是保命机制。当智能体数量从个位数增长到数十个时，缺乏这些边界的系统会迅速失控。
从经验看，建议团队在引入多智能体系统时，先明确三个问题：任务结构是否足够清晰以支持预先分解？交互频率是否高到需要动态调度？系统规模是否会超过单个 Supervisor 的有效管理范围？答案决定了应该选择哪种拓扑，以及需要投入多少资源在治理机制上。
Agent 运行时过载
协作模式的取舍
Supervisor 与 Orchestrator 的边界
Supervisor 模式采用串行、动态调度，共享任务进展。每个子智能体都能看到全局上下文，适合需要频繁调整策略的场景。Orchestrator 则预先分解任务、并行执行子任务，并限制子代理上下文进入主流程，适合任务结构相对固定的流水线。
选择的关键在于上下文成本。Supervisor 模式下，每个智能体都要处理完整上下文，token 消耗随智能体数量线性增长。Orchestrator 通过隔离子任务上下文，将主流程的 token 消耗控制在较低水平，但代价是失去了动态调整的能力。
Supervisor 与 Orchestrator 架构对比
Channel Pipeline 的上下文隔离
当一批数据需要依次经过固定阶段时，Pipeline 是最直接的拓扑。例如批量处理文档，每条数据都要经过分类、检索资料、起草内容、质检四个阶段。每个阶段由一个或一组 Agent 负责，阶段之间通过 channel 串联。
这正是 Go 常见的 pipeline 并发模式。每个阶段启动多个 worker 并行消费输入，再把结果汇入同一个输出 channel。每个 SwarmAgent 内部仍然可以使用独立的 Agent，只需增加一个表达转交目标的 handoff 工具。
Swarm 容易增加新角色，但也可能形成 A → B → A 的循环。因此 MaxHops 是必要边界。生产系统还应记录已访问节点，以便提前发现循环转交。
参考文献
[1] M08 多智能体系统 – 李文周的个人站点. https://liwenzhou.com/courses/ai-agent/08-multi-agent
[2] 构建AI 智能体应用（三）：多智能体协作与编排模式 - ApFramework. https://apframework.com/blog/essay/2026-02-17-multiagent-coordination
[3] 什么是多智能体系统？| SAP. https://www.sap.cn/resources/what-are-multi-agent-systems
[4] 多智能体（Multi-Agent）架构深度拆解：协作模式、框架与落地建议 | 人人都是产品经理. https://www.woshipm.com/ai/1546717.html
[5] 什么是AI 中的多智能体系统？ - Google Cloud. https://cloud.google.com/discover/what-is-a-multi-agent-system?hl=zh-CN
[6] Pipeline（管道） - AgentScope Java. https://java.agentscope.io/v1/zh/docs/multi-agent/pipeline.html
[7] 构建多智能体系统 - Codelabs. https://codelabs.developers.google.com/codelabs/production-ready-ai-roadshow/1-building-a-multi-agent-system/building-a-multi-agent-system?hl=zh-cn
[8] 什么是多智能体系统？| NVIDIA 术语表 - 英伟达. https://www.nvidia.cn/glossary/multi-agent-systems