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 可能把任务转给 BB 又转回给 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 可能把任务转给 BB 又转回给 A形成无意义的往返。生产系统必须记录已访问节点并设置 MaxHops 边界否则循环检测缺失会导致 token 消耗失控。%% title: 多智能体协调拓扑对比flowchart LRsubgraph 集中式S[Supervisor]A1[Agent A]A2[Agent B]A3[Agent C]endsubgraph 隔离式O[Orchestrator]subgraph 子任务T1[Task 1]T2[Task 2]T3[Task 3]endendsubgraph 流水线P1[阶段1]P2[阶段2]P3[阶段3]endS -- A1S -- A2S -- A3O -- T1O -- T2O -- T3P1 -- P2P2 -- P3Supervisor 与 Orchestrator 的取舍本质上是「动态调度」与「预先分解」的权衡。Supervisor 采用串行、动态调度并共享任务进展适合任务边界模糊、需要实时调整的场景。Orchestrator 则预先分解任务、并行执行子任务并限制子代理上下文进入主流程适合任务结构清晰、需要上下文隔离的场景。Channel Pipeline 是另一种常见拓扑。当一批数据需要依次经过固定阶段时Pipeline 是最直接的拓扑。例如批量处理文档每条数据都要经过分类、检索资料、起草内容、质检四个阶段。每个阶段由一个或一组 Agent 负责阶段之间通过 channel 串联。这正是 Go 常见的 pipeline 并发模式一个阶段启动多个 worker 并行消费输入再把结果汇入同一个输出 channel。这种模式的上下文隔离价值在于下游 Agent 不会看到上游 Agent 的完整历史只接收经过浓缩的中间结果。代价是信息损失某些边界情况可能在浓缩过程中被过滤掉。工程实践中需要在信息密度与上下文长度之间找到平衡点。[[reactionbackend-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?hlzh-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?hlzh-cn[8] 什么是多智能体系统| NVIDIA 术语表 - 英伟达. https://www.nvidia.cn/glossary/multi-agent-systems