先把结论讲明白#

如果这篇文章只留一句话，我会这么说：

MultiAgent 不是“多开几个模型实例”，也不是“把三个终端一起跑”。它更像是在组织一套可分工、可协作、可治理的智能系统。

这篇稿子不打算只从 CodeAgent 视角聊这个话题。

我这次更想把它横着讲清楚：

• 它为什么在 2024 到 2026 重新变热
• 它到底有哪些主流技术路线
• 哪些场景真的适合多 Agent，哪些只是想象很美
• 今天谈 MultiAgent，到底应该抓哪些原则，警惕哪些坑

资料基线

这篇文章主要基于 Anthropic、OpenAI、Google、Microsoft、MCP 官方文档、IJCAI 和 OpenReview 的资料来写。

我会尽量把判断写成“资料事实 + 基于资料的归纳”，而不是凭印象喊口号。

为什么现在必须重新看 MultiAgent#

严格说，MultiAgent 根本不新。

多智能体系统本来就是传统 MAS（Multi-Agent Systems，多智能体系统）和分布式人工智能里的老题目。IJCAI 2024 的综述 和 OpenReview 2024 的综述 都已经把这条历史线梳理得很完整。所以今天重新看 MultiAgent，不是因为这个词突然被发明出来了，而是因为问题的重心变了。

以前大家讨论 AI，核心问题更像是：模型够不够聪明，回答够不够像人，补全够不够快。

但到了 2024 到 2026，这个问题开始不够用了。越来越多真实任务卡住的，不是模型会不会说，而是一个单体 Agent 根本不适合同时承担这么多事：它既要理解目标，又要调工具、跨系统、维持长上下文、处理异步反馈、自己给自己验收，最后还要保证别失控。换句话说，瓶颈正在从“模型能力”迁移到“系统组织能力”。

如果把这件事翻成人话，其实很像下面这个场面：

你让一个 Agent 一个人同时干 PM、开发、测试、值班同学和 reviewer 的活。它前一秒在读需求，下一秒要去查资料、调工具、改代码、跑测试、写总结，中途还得处理新插进来的反馈和越来越长的上下文。它不是不聪明，而是你把太多原本就该分开的职责，一股脑塞给了一个执行单元。

这时候系统开始出问题，真的不奇怪。奇怪的是，过去我们居然经常默认这套做法应该成立。

这才是今天必须重新看 MultiAgent 的真正原因。

不是因为“多几个 Agent 看起来更高级”，而是因为很多任务已经开始逼着我们承认：单 Agent 不是万能执行单元，很多时候它只是一个被过度期待的总包工头。

Anthropic 在 2024 年 12 月 19 日发布的《Building Effective AI Agents》 和 OpenAI 在 2025 年 3 月 11 日发布的《New tools for building agents》 其实都在释放同一个信号：Agent 已经不只是聊天技巧，而是在进入真正的系统工程阶段。到了这个阶段，问题就自然会升级成：

• 任务怎么拆
• 上下文怎么分
• 谁来执行，谁来验收
• 长任务怎么恢复
• 出问题时怎么追踪、怎么治理

一旦问题变成这样，MultiAgent 就不再是“要不要追新概念”，而是“有没有必要重新设计系统组织方式”。

再往下看，Anthropic 在 2025 年 6 月 13 日公开的 multi-agent research system 把这个转折讲得特别直接：多 Agent 真正成立，不是因为它让模型突然更聪明了，而是因为它让系统终于能把广度探索、并行检索、跨上下文压缩这些单 Agent 很难同时做好的事情拆开处理。这是一个很关键的信号，它说明 MultiAgent 的价值开始从“概念想象”变成“在某些任务里确实更合适的结构”。

与此同时，企业侧的诉求也在变。ServiceNow、Workday 和 Microsoft Azure AI Foundry 这些材料背后讲的根本不是“多 agent 很酷”，而是另一件更现实的事：企业已经不满足于一个会回答问题的助手，它们要的是一套能跨角色、跨系统、跨流程协作，还能被管理、被问责、被治理的智能流程层。

这时候再看 MCP 和 A2A，你会发现它们的重要性也不是“又多了两个名词”，而是行业终于开始认真补基础设施了。MCP 的起点更偏 agent <-> tool / resource，A2A 更偏 remote agent service <-> remote agent service。而且到 2026 年，MCP 自己也已经开始往 UI、任务和 agent communication 延展。这不代表标准已经统一，但至少说明大家已经意识到：如果继续每家都写私有胶水代码，MultiAgent 很难真的长成产业能力。

最后，真正让我觉得这个方向必须重看的，不是热度，而是冷水。OpenReview 在 2025 年发布的《Why Do Multiagent Systems Fail?》 和 《Why Do Multi-Agent LLM Systems Fail?》 很重要，因为它们把话题从“MultiAgent 能干什么”往前推了一步，开始问“MultiAgent 为什么经常干砸”。这意味着行业已经不只是沉迷想象力，开始进入更像工程学的阶段了：要讨论 specification、coordination、verification、observability 和治理。

一句话判断

今天重新看 MultiAgent，不是为了追热词，而是因为 AI 系统真正难的部分，正在从“让模型回答”变成“让一套智能系统长期协作而不失控”。

这波热度当然有 hype，但它背后对应的问题也确实比以前更真了。

先别把所有 MultiAgent 混成一个词#

今天很多文章的问题，不是资料少，而是把完全不同的东西都叫成了 MultiAgent。读者一眼看过去，会觉得这些词都认识，但根本不知道差别在哪里。

如果你也有过这种感觉: 一会儿看到它像“团队协作”，一会儿又像“工作流编排”，再往后又突然变成“协议互通”或者“自治网络”，那多半不是你没看懂，而是很多文章确实把不同层面的问题混着写了。

如果要把这件事讲明白，我觉得不能先扔术语，得先回答三个更人话的问题：

1. 谁在指挥？ 是不是有一个总协调者统一拆任务、分配工作、汇总结果？
2. 任务怎么流？ 是按固定步骤接力推进，还是多个 Agent 同时展开，再回到一起？
3. Agent 靠什么协作？ 是互相发消息、围着共享状态工作，还是干脆各自独立协商？

只要这三个问题想清楚，很多看起来很玄的名词就会突然变得很好懂。

先别急着记术语

先拿这三个问题去压一遍任何一个系统：

• 谁在指挥
• 任务怎么流
• Agent 靠什么协作

能回答这三句，再去看它叫 team、swarm、workflow 还是 committee，基本就不太容易被名字带跑。

还有一句最好先讲死：这三个问题是三个观察维度，不是一棵只能选一条分支的分类树。

一个系统完全可能同时满足这几句：

• 控制上是中心化的
• 任务组织上是 orchestrator-worker
• 状态上围着 shared state 工作
• 运行时又靠 event-driven 往前推

很多文章写乱，就是因为前面刚把维度分开，后面又把不同维度的答案重新揉成一团。

先看“谁在指挥”#

最粗的一刀，其实是看控制拓扑，也就是谁在掌控全局。

中心化编排#

这类系统有一个明显的主脑，或者至少有一个主控制流。

人话一点，就是：

• 有一个总负责人知道目标是什么
• 它决定把任务拆给谁
• 它决定什么时候继续、什么时候停止
• 最后也是它来汇总结果

这类系统更像“项目经理带专项同事”。

现在公开的一手工业案例，大多数都偏这一类。比如 Anthropic 的 multi-agent research system，本质就是 orchestrator-worker。好处是清楚、好 debug、好加护栏；坏处是主协调者容易变瓶颈。

去中心化协作#

这类系统没有单一主控，多个 Agent 更像平等节点。

人话一点，就是：

• 没有一个“总经理”永远说了算
• 每个 Agent 会根据局部信息和能力做决定
• 它们之间更像协作网络，而不是上下级关系

这类系统更像“多个独立团队临时联合干活”。

AgentNet 这类研究很看重这条路，因为中心化天然有单点瓶颈、扩展性问题和隐私边界问题。但它的工程难度也更高：路由怎么收敛、冲突怎么解决、谁来背责任，这些都更难。

再看“任务怎么流”#

在“谁指挥”之外，第二个关键问题是：主任务到底按什么路径往前推进。

这里读者最容易混淆的一点是：任务怎么流，不等于 Agent 之间怎么说话。很多系统表面上看上去很热闹，好像到处都在消息乱飞，但真正决定系统骨架的，往往还是主任务到底怎么推进。

这里先只看两种最常见的主路径：

• 一种是有人拆题、派工、回收结果
• 一种是按固定步骤接力推进

像 committee、blackboard、async messaging 这些，不是主路径本身，更像协作和收敛机制，我放到下一节单独讲。

监督者 / Orchestrator-Worker#

这是今天最容易落地，也最常见的一种。

它的基本逻辑是：

• 一个 supervisor 先理解总任务
• 把任务拆成多个子问题
• 分给不同 worker
• 最后再把结果收回来整合

它最像什么？最像一个总协调者带一组专项执行者，也最像现实团队里的“项目经理 + 专项同事”。

它适合什么？

• Research
• 宽搜型信息处理
• 可以明显拆成几个子问题的大任务

它的主要好处是：

• 责任边界清楚
• 上下文容易隔离
• 结果更容易汇总

它的主要坏处是：

• supervisor 很容易变成瓶颈
• 一旦主脑判断错了，整串任务都会跟着偏
• 如果拆分本身不合理，worker 再努力也没用

流水线 / Graph Workflow#

这一类不要想成“大家在开会”，要想成“大家在接力”。

它的逻辑是：

• 第一个 Agent 做完第一步
• 结果交给第二个 Agent
• 第二个做完再交给第三个
• 整条链像流程图一样往前走

它最像什么？最像审批流、生产流水线或者一个可回放、可恢复的任务图。

它适合什么？

• 企业流程
• 长任务 orchestration
• 需要断点恢复、回放、人工插手的场景

为什么很多团队喜欢它？

• 可预测
• 好观察
• 好恢复
• 适合合规和人工接管

它的主要坏处是：

• 前面一环歪了，后面全会跟着歪
• 流程过于僵硬时，不适合探索型任务
• 图越来越复杂后，维护成本会上升得很快

最后看“Agent 靠什么协作 / 收敛”#

前面两节讲的是“谁在带队”和“主任务怎么走”。但真实系统真正容易写乱的，往往是第三件事：Agent 彼此到底靠什么交换信息、共享中间结果、收敛结论。

这一层才是很多文章最喜欢一股脑混成 swarm、committee、blackboard、async、peer-to-peer 的地方。它们也不是互斥的，很多系统会同时出现两三种。

评审 / 辩论 / Committee#

这一类的核心不是“分工执行”，而是“多视角交叉判断”。

它的逻辑是：

• 多个 Agent 对同一问题独立思考
• 它们互相批评、投票，或者由一个 judge 汇总
• 最终不是看谁先说，而是看谁更站得住

它最像什么？最像作者、评审、元评审者组成的小型评审会，或者同一份方案被不同角色交叉 review。

它适合什么？

• 高不确定性推理
• 方案评审
• 红队、安全、judge 类任务

它的主要价值是：

• 不是更快，而是更稳
• 当你不希望单个 Agent 一路自洽到底时，这类机制特别有用

它的主要坏处是：

• 很贵
• 很耗 Token
• 很容易出现“多数人一起错”

Multi-LLM Debate 就提醒过，辩论不一定天然带来更好答案，它也可能收敛成多数意见，甚至放大共同误区。

共享状态 / Blackboard#

这一类最容易被写糊。

它不是“Agent 之间一直互相聊天”，而是多个 Agent 围着同一个共享工作区工作。

它的逻辑是：

• 大家不是直接互相来回传话
• 而是把中间结果写进共享状态
• 其他 Agent 再根据共享状态决定下一步动作

它最像什么？最像多人围着同一块白板工作，或者围着同一份不断更新的任务面板工作。

它适合什么？

• 需要回放、审计、断点恢复的系统
• 长任务 orchestration
• 需要明确状态流转的系统

为什么这类模式重要？

• 很多长任务系统真正需要的，不是 endless chat，而是一个可追踪、可恢复、可审计的状态空间
• LangGraph 的 StateGraph 就很适合拿来理解这一点

它的主要坏处是：

• 状态 schema 很难设计
• 并发更新容易冲突
• reducer 和状态合并逻辑一复杂，系统会越来越像状态机地狱

事件驱动 / Asynchronous Messaging#

这一类更接近真实分布式系统。

它的逻辑是：

• Agent 不一定同步轮流说话
• 谁收到事件、谁满足条件，谁就开始干活
• 任务可以异步推进，不必所有人都等同一个时钟

它最像什么？最像消息队列、工单系统或者事件总线。

它适合什么？

• 多系统集成
• 长任务
• 企业级 runtime

为什么这类模式值钱？

• 弹性更强
• 更适合跨系统
• 更适合异步长任务

AutoGen Core 对这一层就讲得很清楚，它的底层更偏 actor model 和异步消息，不是单纯的多轮聊天。

它的主要坏处是：

• 调试明显更难
• 重试、幂等、状态一致性、事件顺序都会变成真问题
• 业务链一长之后，很容易出现“事情在跑，但没人能一眼看懂现在跑到哪了”

对等 / Peer-to-Peer / Decentralized#

这是最容易让人脑补出“智能体社会”的一类。

它的逻辑是：

• 没有固定主控
• 多个 Agent 按能力和局部信息自己协商
• 网络结构本身会影响协作效果

它最像什么？最像多个独立组织共同完成一件事，而不是一个团队内部排班。

它适合什么？

• 跨组织协作
• 强隐私边界场景
• 没有谁愿意把全部控制权交给中心节点的系统

为什么它吸引人？

• 理论上更可扩展
• 更适合跨组织和隐私边界
• 不容易形成单点瓶颈

它的主要坏处是：

• 最难治理
• 谁可信、谁说了算、怎么防串谋、怎么防死循环、怎么保证收敛，全是硬问题

所以这类路线很值得关注，但至少从今天公开的一手工业材料看，它更像前沿方向，不像默认起点。

两个最近很值得看的案例#

如果这一节要讲，我觉得就别再讲词义了，直接看案例。

因为今天真正有信息量的，不是 Agent Team 和 Agent Swarm 这两个词本身，而是：最近最有信息量的公开案例，到底把多 Agent 做成了什么样子。

我会抓两个案例。

案例一：Claude Code Agent Teams#

这是最近最典型的“把多 Agent 做成团队协作产品”的例子。

根据 Claude Code 官方文档，Agent Teams 目前还是 experimental，但它已经把很多过去只停留在 demo 里的东西做成了明确机制：

• 一个 team lead 负责整体协调
• 多个 teammates 作为独立 session 并行工作
• 团队围着 shared task list 推进
• 队员之间可以通过 mailbox 直接通信
• 每个 agent 都有自己的上下文窗口，可以单独被打断、重定向和继续执行

这套设计为什么值得看？因为它把多 Agent 最现实的一类需求做出来了：不是让一群 Agent 一起“思考”，而是让它们像一个真实小组一样分工干活。

如果再看 Anthropic 在 2026 年 2 月 5 日发布的《Building a C compiler with a team of parallel Claudes》，这个方向会更清楚。那篇文章最有价值的不是“很多 agent 一起写编译器”这个噱头，而是它把工程上真正难的东西暴露出来了：

• 多个 agent 并行时，怎么避免撞车
• 谁来锁任务，谁来合并结果
• 怎么让 review agent 和实现 agent 分开
• 怎么靠测试和 harness 保证团队没有一起跑偏

所以 Claude Code Agent Teams 这个案例真正说明的是：

MultiAgent 的一个重要方向，不是继续强化单个超级 Agent，而是把任务所有权、并行执行、review 和回收结果做成团队闭环。

案例二：Kimi K2.5 的 Agent Swarm 研究预览#

如果说 Claude Code 代表的是“把团队协作产品化”，那 Kimi K2.5 更像另一条线：把大规模动态拆分和集群协作能力往模型侧和 runtime 侧推。

按 Kimi K2.5 技术报告 里的描述，这条线最值得看的，不是名字，而是它背后的协作原理：

• 不是先把角色和 workflow 全部写死
• 而是围绕大目标，动态决定还要不要继续拆
• 把并行探索规模直接拉到最多 100 个 sub-agents、1500 个协同步骤
• 同时保留一个可训练的 orchestrator，负责拆解、调度和回收子任务结果

这其实是在做一件很明确的事：把“任务怎么拆、拆到多细、哪些支线该并行”从人工预设流程，往系统自己的调度能力上推。

所以 Kimi 这条线真正想推的，不只是“多起几个 agent”，而是：

• 让系统自己决定该不该继续拆
• 让并行探索规模大幅上去
• 让长链路任务不再只能靠人工预先写死 workflow
• 但同时，又不是完全放弃协调者，而是把协调本身也做成可训练能力

所以这个案例真正值钱的地方，不是 Swarm 这个词够不够帅，而是它把另一种多 Agent 方向讲得很具体：

MultiAgent 不一定只是在 UI 层做团队协作，也可以在模型和 runtime 层把动态拆解、并行扩张、长链路协同本身推到更大规模。

如果想看它的原始技术描述，可以直接看 Kimi K2.5 技术报告 和 Moonshot 平台的 Agent Support 文档。

这两个案例合在一起，说明了什么#

如果把这两个案例放在一起看，我觉得最值得讲的，不是“谁才代表真正的 Team 或 Swarm”，而是它们在不同层面回答同一个问题：

• Claude Code 更像把“组织形态”显性化，让 lead、teammates、task ownership、mailbox 这些关系直接长在产品交互里
• Kimi K2.5 更像把“动态拆解和并行扩张”往模型与 runtime 内部推，把拆题和调度本身做成系统能力

前者更强调可见的团队协作界面。

后者更强调更深一层的调度与扩张能力。

所以这两个案例不是在争一个标准答案，而是在不同层面推进 MultiAgent：

• 一个把组织关系做得更清楚
• 一个把并行协同做得更大

这一节真正该记住的

看 Claude Code Agent Teams，重点看它怎么解决分工、review、任务回收和并行开发。

看 Kimi K2.5，重点看它怎么把动态拆分、并行协同和长链路执行做大。

这两个案例真正说明的，不是两个词是什么意思，而是多 Agent 现在正在往哪两边长。

如果不想只看开发者工具，还有这些公开产品也值得看#

如果只盯着 Claude Code 和 Kimi，视野还是太窄了。公开产品里，至少还有下面几类很值得看，而且它们各自代表的问题完全不同。

• Microsoft Agent Framework 1.0，2026 年 4 月 3 日 这个例子最适合看“多 agent 编排开始从实验框架走向生产 SDK”。它把 multi-agent orchestration、跨运行时互通和稳定 API 一起推到 1.0，说明这条线已经不再只是研究玩具。

• Oracle Fusion Agentic Applications，2026 年 3 月 24 日 这个例子最适合看“多 Agent 开始直接长进企业业务软件本体”。它强调的是由一组有不同职责和决策权限的 agent team 去持续推进业务目标，而不是只做一个外挂式助手。

• IBM watsonx Orchestrate 的 Multi-agent Orchestration 当前产品页 这个例子最适合看“多 Agent 已经被做成正式可卖的企业编排层”。它把 supervisor、router、planner、workflow styles 和治理放在同一个产品能力里，讲得非常直接。

• NVIDIA Multi-Agent Warehouse AI Command Layer，2026 年 1 月 9 日 这个例子最适合看“MultiAgent 不只发生在聊天窗口，也会进入物理世界的运营系统”。它把仓储里的设备、人员、安全、预测、文档理解拉进同一个 command layer，很适合说明多 agent 为什么会长到真实业务系统里。

• Kimi K2.5，2026 年 1 月 这个例子最适合看“模型侧怎么把 cluster 协作和动态拆解往更大规模推”。它代表的不是传统工作流编排，而是更底层的 agent cluster 能力。

• Anthropic《Building a C compiler with a team of parallel Claudes》，2026 年 2 月 5 日 这个例子最适合看“多 Agent 公开案例里，真正难的是怎么组织团队而不是怎么凑人数”。它把并行开发、review、测试、任务锁定和结果回收写得非常具体。

• Oracle AI Agents for Supply Chain，2026 年 2 月 10 日 这个例子最适合看“多 Agent 怎么进入高约束、强流程、跨职能的企业场景”。它不是在讲一个抽象 agent，而是在讲供应链计划、采购、制造、物流这些角色怎么被 agent 化。

把这些形态压成一张表#

如果只想先建立一个最小判断框架，可以先记这张速查表。

这张表是速查表，不是严格 taxonomy

它故意把最常见的“长相”压在一起，里面同时混了控制拓扑、任务组织方式和协作 / 通信机制。

目的不是给所有 MultiAgent 系统一刀切地贴标签，而是帮读者先认长相。真要设计系统，还是得回到前面那三个问题分别判断。

这张表背后不是我自己拍脑袋分的，而是综合了 IJCAI 2024 survey、Anthropic 的 industrial case、AutoGen、LangChain/LangGraph 文档、Multi-LLM Debate 和 AgentNet 这些资料。

更有意思的是，不同来源之间其实有明显分歧。

• 工业界更偏中心化，因为更好 debug，更好加护栏。
• 研究界更愿意推去中心化，因为中心化天然有单点瓶颈和隐私边界问题。
• 一部分综述会把今天很多系统都算作 MultiAgent；但 《Large Language Models Miss the Multi-agent Mark》 这类研究会提醒你：很多现在被叫作 multi-agent 的系统，本质上更像“多个 LLM 角色一起干活”，还没到传统多智能体理论里那种高度自治、彼此持续互动、还会被环境实时反馈牵着走的程度。

一个现实判断

今天工业界主流公开案例，仍然明显偏中心化监督者和工作流编排。

去中心化很重要，但至少从公开的一手生产经验来看，它还不是主流落地方向。

底层关键技术：别把 Workflow、Memory、MCP、A2A 写成一团#

很多讨论一到这里就开始堆词：

• skill
• memory
• shared state
• orchestration
• event bus
• MCP
• A2A

最后读完只剩一种感觉：好像什么都重要，但又不知道它们到底是不是同一层。

如果你以前读 agent 文章时经常在这一段开始掉线，这很正常。因为从这里往后，大家最容易把“能力”“记忆”“编排”“消息流”和“跨系统协议”全写成一锅粥。

问题往往不在于资料不够，而在于这些词其实在回答完全不同的问题：

• skill 回答的是“这个 Agent 被封装成擅长哪类任务”
• workflow 回答的是“任务怎么往前走”
• memory 回答的是“系统怎么记住东西”
• MCP 回答的是“Agent 怎么接工具和资源”，而且到 2026 年已经开始往 UI 和部分边界能力延展
• A2A 回答的是“独立 Agent 服务怎么跨边界互通”

它们本来就不是同类东西，硬写在一层当然会乱。

前面那张表是帮读者先认长相，这一节开始才进入更严格的系统分层。

你可以把这里想成在拆一台机器：

• 先看它有没有手脚
• 再看它记不记事
• 再看谁在调度
• 再看消息怎么流
• 最后才看不同系统之间怎么接线

这么看，后面那五层会顺很多。

我更建议把 MultiAgent 的底层技术拆成五层。

这一节不要按名词背

真正有用的读法不是把这五层硬记下来，而是每次碰到一个词，先问它到底在回答哪类问题：

• 单个 Agent 的能力问题
• 状态怎么维持的问题
• 多 Agent 怎么分工的问题
• 工作怎么流转的问题
• 独立服务怎么跨边界互通的问题

层级一分开，很多原本看起来缠在一起的讨论会立刻清楚很多。

第 1 层：执行与能力层#

这一层最容易理解，它回答的是：

单个 Agent 到底能做什么。

比如：

• 会不会推理
• 会不会调工具
• 有没有相关 Skill
• 能不能通过 MCP 接工具和资源
• 能不能查知识库
• 能不能跑代码
• 能不能调外部 API

如果没有这一层，后面所有“多 Agent 协作”都没意义，因为连单个节点能干什么都不成立。

所以这层更像每个 Agent 的“手脚”和“工具箱”。

第 2 层：上下文与状态层#

这一层回答的是：

系统靠什么维持连续性。

这里最容易混淆三个词：

• memory
• shared state
• artifact

但它们其实不是一回事。

• memory 更像记忆。 比如系统记得这个用户之前问过什么、上一次推理得出了什么中间结论。
• shared state 更像当前局势面板。 比如现在工单状态是 high-priority，退款检查已经完成，权限检查还没完成。
• artifact 更像阶段性产物。 比如一份摘要、一张表、一段 JSON 结果、一版中间报告。

如果把它们翻成人话：

• memory 是“记住过什么”
• state 是“现在局面是什么”
• artifact 是“已经产出了什么”

这三者一混，系统设计就会开始发虚。

第 3 层：编排与协作层#

这一层回答的是：

多个 Agent 怎么分工。

也就是前面刚讲过的那些组织方式：

• centralized / decentralized topology
• supervisor-worker
• workflow
• committee

这里有两个特别容易放错层的词，需要单独讲一句：

• blackboard 是“状态层 + 协作层”的交叉物。共享状态本身在第 2 层，围着共享状态怎么分工才属于第 3 层。
• async / event-driven 更接近第 4 层，因为它描述的是消息和任务怎么流，不是谁带队。

这一层说的不是工具，不是协议，也不等于所有运行时机制，而是“组织结构”。

如果把 MultiAgent 比作一个团队，这一层回答的就是：

• 谁带队
• 谁做什么
• 谁和谁协作
• 出问题时谁兜底

这一层决定的是角色划分和控制拓扑，不回答独立 Agent 服务跨边界怎么接起来；那是下一层的问题。

第 4 层：通信与任务层#

这一层回答的是：

工作在节点之间怎么移动。

比如：

• 一条消息直接发给某个 Agent
• 写进 shared task list 或 task store
• 广播给一组订阅者
• 发到 event bus，等订阅者异步接手
• handoff 给更合适的 Agent
• 建一个 task，再持续更新它的状态

这一层更像系统里的“任务流转机制”。

前面讲的 async messaging，基本就落在这一层。它和 workflow 紧挨着，但不是一回事。

为什么很多人会把它和 workflow 混掉？因为它们确实紧挨着。但区别很重要：

• workflow 更像流程图
• communication / task layer 更像流程图里的线、消息和任务状态

一个系统可以有 workflow，但用 very simple direct message。 一个系统也可以没有固定 workflow，却靠 event bus 和 task lifecycle 协作。

第 5 层：跨系统互通与服务边界层#

这一层回答的是：

独立 Agent 服务跨系统、跨团队、跨框架怎么接起来。

A2A 在这一层更关键，因为它主要解决的是：

• 一个 Agent 服务怎么把任务交给另一个 Agent 服务
• 怎么持续跟踪任务状态
• 怎么交换结果和中间产物

这一层真正关心的是这些问题：

• 这个服务是谁
• 它暴露哪些能力
• 怎么发现它
• 怎么认证和授权
• 怎么保证版本兼容

更关键的是，不是所有 MultiAgent 都必须上这一层的标准协议。

Google 的 ADK 文档 就明确区分 local sub-agents 和 remote agents。如果你的系统主要是本地子代理、共享内存、低延迟内部协作，那跨系统互通这层根本不一定需要很重的标准化。到了真的存在独立 Agent 服务、跨团队边界、跨框架边界时，A2A 这类协议才会开始变得值钱。

最容易误写的一句

不要把跨系统互通这一层理解成“所有多 Agent 系统都必须上标准协议”。很多系统在本地 runtime 里就能协作得很好，只有真的跨服务、跨团队、跨框架时，这一层的成本和价值才会同时变高。

设计原则：真正难的不是“多开几个 Agent”#

如果把 Anthropic、Microsoft、OpenReview 的 failure taxonomy 和 Why Do Multi-Agent LLM Systems Fail? 放在一起看，比较稳的原则大概有七条。

如果只把这七条原则写成一句话一句话，它们确实很容易发虚。更有用的方式，是把它们放回几个反复出现的工程矛盾里看。

因为真正折磨人的，从来不是 demo 里那种“它能不能跑起来”，而是另一类很现实的问题：它明明跑起来了，为什么老是在奇怪的地方翻车，而且翻车后还没人说得清到底是哪一层先歪了。

做系统评审时，至少先连问四句

• 为什么不是单 Agent 或简单 workflow
• 谁拿什么上下文和工具
• 谁负责独立验收
• 长任务失败后怎么恢复

如果这四句答不出来，系统大概率还没准备好进生产。

第一组：不是“能拆就拆”，而是“拆了以后有没有净收益”#

第一条原则其实最重要：

先证明单 Agent 或简单 workflow 不够，再上 MultiAgent。

这句话听起来保守，但它其实是在帮系统省掉大量伪复杂度。

很多团队一上来就想加更多 Agent，本质上是把“任务定义不清、工具接入混乱、验证链不完整”这些更底层的问题，伪装成“需要更多角色”。结果不是系统更强，而是混乱被复制了更多份。

这组原则真正对应的是两个判断：

1. 当前任务到底有没有明显的可拆分收益？
2. 拆完之后，职责是不是更清楚了，而不是更模糊了？

所以这组里有两条常常要一起看：

• 先证明单 Agent 或简单 workflow 不够
• 职责分离比堆数量更重要

真正值钱的拆法，通常不是“从 1 个 Agent 变成 8 个 Agent”，而是把原来混在一起的几种责任拆开，比如：

• 规划和执行分开
• 执行和验收分开
• 对外沟通和内部分析分开

如果拆完之后，每个 Agent 还是在做一团混合职责，那它只是从“一个大黑盒”变成了“三个小黑盒”。

第二组：不是“上下文越多越好”，而是“上下文和工具都要做减法”#

很多 MultiAgent 系统看上去像是因为模型不够强才翻车，实际上更常见的原因是：

• 每个 Agent 拿到的上下文太杂
• 工具挂得太多
• 同类能力重叠太严重

所以第二组原则，核心其实是“减法”：

• 上下文要最小高信号，不要做全量广播
• 工具和 Agent 都不是越多越好，过多会互相干扰

这两条放在一起看，意思就很清楚了：

一个 Agent 不应该因为“也许有用”就被塞进全部历史、全部规则、全部工具。真正稳的系统，通常会把上下文裁成任务需要的最小集合，把工具裁成角色需要的最小集合。

否则就会出现两种非常典型的故障：

• 上下文噪声过高，模型抓不住真正权威的信息
• 工具过载，模型在一堆相似能力里来回试错，最后反而更慢、更乱、更贵

这类问题在单 Agent 里已经常见，到了 MultiAgent 里只会被放大。

第三组：不是“能跑完就行”，而是“谁来证明它真的做对了”#

很多多 Agent 系统的危险，不在执行，而在验收。

如果一个系统里：

• 负责做事的 Agent 自己判断自己有没有做好
• 负责写结果的 Agent 自己决定结果够不够可信
• 负责调用工具的 Agent 自己解释工具输出有没有问题

那它很容易一路自洽到底。

所以第三组原则是：

• 验收权最好和执行权分开
• 可观测性必须内建，而且不能只看日志

这两条之所以经常要放在一起，是因为它们本质上都在回答一个问题：

系统拿什么来反驳自己。

执行权和验收权分开，解决的是“不要让同一个脑回路从头判到尾”。

可观测性内建，解决的是“即使它做错了，人能不能看见它到底错在哪”。

Reflection 很有用，但它不等于独立验收

很多团队会把 Reflection 当成万能纠错机制，比如让 agent 在完成后再自我复盘一轮、再挑一轮自己的漏洞。

这当然有价值，但它解决的更像“同一个执行链能不能自我修正一点”，不是“系统有没有独立的证明机制”。

如果执行者、反思者、总结者本质上还是同一条脑回路，那它仍然可能一路自洽到底，只是自洽得更认真了一点。

evaluation 真正回答的是“怎么证明它做对了”

到了多 Agent 系统里，evaluation 不该再只是“最后看起来像不像对”。

更稳的 evaluation 往往至少要落到这些东西里：

• end-state checks：最终状态到底有没有达到目标
• constraint checks：有没有触碰明确禁止的边界
• regression checks：有没有把原本正常的链路带坏
• judge / reviewer：有没有独立于执行链的审查视角
• trace-based review：出了问题时，能不能顺着轨迹定位是哪一层先歪了

换句话说，Reflection 更像过程内自检，evaluation 才是系统级验收。

而且今天讲 observability，已经不能再只理解成：

• 有没有日志
• 有没有 trace id
• 有没有耗时指标

更关键的其实是：

• 有没有看得懂的任务轨迹
• 有没有中间状态
• 有没有失败分类
• 有没有办法知道是 spec 错了、路由错了、工具错了，还是验收错了

否则系统一复杂，最后就只剩一句“它又跑偏了”，但没人知道到底哪里偏了。

第四组：不是“能 demo 出来”，而是“能不能长期跑而不失控”#

到了生产环境，很多问题就不再是“这次能不能跑通”，而是：

• 跑到一半挂了怎么办
• 升级部署时断了怎么办
• 长任务能不能从中间恢复
• 权限和边界出了问题谁负责

所以最后一组原则是：

• 长任务系统必须支持持久化、检查点和恢复

这条看起来像运行时细节，但它其实很核心。因为一旦进入多 Agent 长任务，错误不再只是“一次答错”，而会变成：

• 状态错着往后传
• 子任务错着继续扩散
• 中途失败后全部从头再来
• 系统越来越贵，但没有越来越稳

这也是为什么很多公开的一手经验最后都会落到同一个方向：MultiAgent 不是玩一次性的编排炫技，而是要把状态、恢复、治理和失败隔离都做成长期机制。

这些原则到底在防什么#

如果把这些原则压回 failure taxonomy，它们大概在防四类大坑：

我很喜欢这类 failure taxonomy 的原因就在这儿：

它逼着我们承认一件事：MultiAgent 的难点从来不只是“让它们协作起来”，而是“让它们在现实系统里长期不失控”。

到 2026 年 4 月，再看 MultiAgent：真正收束出的几件事#

把最近 3 到 6 个月的一手资料放在一起看，至少有五个判断已经比较稳定。

如果前面信息密度有点高，这一节可以直接当复盘看。这里不再重新讲术语，只讲到 2026 年 4 月，哪些判断已经比较能站住。

第一，它先收束成“有组织的执行系统”，不是“更多聊天角色”#

最近半年最有代表性的公开材料，其实已经把方向讲得很清楚了。

Anthropic 在 2026 年 2 月 5 日发布的《Building a C compiler with a team of parallel Claudes》 讲得很具体：真正难的不是多开几个 session，而是任务怎么锁、结果怎么合、review 怎么插进去、harness 和测试怎么兜底。另一边，模型侧也已经开始把更大规模的动态拆分和并行调度往前推，像 K2.5 技术报告 里展示的，就是让 orchestrator 去动态拆任务、回收结果，而不是先把流程全写死。

这几条线合在一起，其实已经很说明问题了：

MultiAgent 到今天先成熟的，不是“大家一起聊”，而是“有人负责任务组织，有人负责并行执行，有机制负责把结果收回来”。

第二，它先收束成“长任务 runtime”，不是“一次性 prompt 技巧”#

最近 3 到 6 个月里，最明显的变化之一，就是大家已经不再把 agent 当成一次性会话了。

Anthropic 在 2025 年 11 月 26 日写 long-running harnesses，核心就是怎么跨上下文窗口持续推进任务；OpenAI 现在的文档里也把 background mode、conversation state 这些能力直接做成平台原语。

这背后其实说明了同一件事：

真正可用的 MultiAgent，已经越来越像一个长任务 runtime。

它必须解决的，不再只是“这次能不能答出来”，而是：

• 任务跑很久怎么办
• 中途断了怎么办
• 上下文滚太长怎么办
• 哪些信息该进 memory，哪些该进 state，哪些该落成 artifact

也就是说，前面文章里讲的那套分层，到这里已经不是写作框架，而是产品现实了。

第三，它先收束成“可验收、可追踪、可恢复”，不是“能跑完就算赢”#

如果只看最近一两个月的官方文档，这个信号已经非常强。

OpenAI 现在把 Agent evals、trace grading、Agent Builder 放在一条线上讲；Microsoft 则在 2026 年 3 月 28 日更新的 Foundry tracing 文档 里，直接把 multi-agent observability 往 OpenTelemetry 语义约定上推。

这说明什么？

说明行业已经不再把“agent 跑起来了”当成终点，而是开始把下面这些问题当成一等问题：

• 最终结果到底做没做对
• 哪一步先歪了
• 是路由错了，还是工具错了，还是验收错了
• 出问题之后能不能从中间恢复，而不是整条链重跑

所以今天真正拉开差距的，已经不是“谁的 prompt 更玄”，而是：

谁的系统能被看见，能被验收，能被恢复。

第四，它先收束成“边界协议化”，但不是“一个协议统一世界”#

到 2026 年，这一层真正发生的变化，是 agent 的边界开始被正式协议化。

Anthropic 在 2025 年 12 月 9 日把 MCP 捐给 Agentic AI Foundation，已经说明它不再只是某一家公司的私有约定；MCP 在 2026 年 1 月 26 日把 MCP Apps 变成官方扩展，说明它开始覆盖 UI 和交互能力；2026 年 3 月 9 日的 roadmap 又把 agent communication、enterprise readiness 这些问题摆上主线。

如果把这些变化压成一句话，就是：

过去大家是在写胶水代码接边界，现在大家开始认真把边界本身做成协议。

但这不等于会出现一个“一统天下”的协议。到今天为止，更像是：

• 能力接入是一层边界
• UI / 人机交互是一层边界
• 远程 agent / 服务互通又是另一层边界

所以真正收束出的，不是“大一统”，而是“分层协议化”。

第五，它没有收束成“多 Agent 默认更强”#

这一点反而是最近的官方文档里越来越诚实的地方。

OpenAI 最新的 evaluation best practices 已经直接写了：是否使用 multi-agent architecture，应该由 evals 驱动。也就是说，多 Agent 不是默认答案，而是结构选择。

这和前面讲过的案例也一致。并行开发、review、任务拆分边界清楚的工作，很适合团队式多 Agent；复杂长任务、宽搜索、动态拆解收益很高的工作，也确实能从更大规模的并行协同里获益。

但没有任何一条严肃的一手材料在认真说：“从现在开始，所有高级 agent 都必须 multi-agent。”

所以到 2026 年 4 月，更稳的总结其实不是“MultiAgent 已经证明自己一定是未来”，而是：

MultiAgent 已经证明自己在某些任务形态下非常值钱，但它依然是一种结构优势，不是默认信仰。

这一节最后只记一句

到 2026 年 4 月，MultiAgent 真正收束出的，不是一个更响的新名词，而是一套更像工程系统的共识：有组织、有状态、可验收、可恢复、边界清楚，而且只在真正值得拆的时候才去拆。

延伸阅读#

如果想继续往下挖，我建议按三组来读。

官方工程与协议#

• Anthropic: Building Effective AI Agents
• Anthropic: How we built our multi-agent research system
• Anthropic: Effective context engineering for AI agents
• OpenAI: New tools for building agents
• OpenAI: Introducing deep research
• Model Context Protocol 官方文档
• MCP Specification Overview
• Google Developers Blog: A2A
• A2A Specification

综述与失败分析#

• IJCAI 2024: Large Language Model Based Multi-agents: A Survey of Progress and Challenges
• OpenReview: Large Language Model based Multi-Agents
• OpenReview: Multi-Agent Collaboration Mechanisms: A Survey of LLMs
• OpenReview: Why Do Multiagent Systems Fail?
• OpenReview: Why Do Multi-Agent LLM Systems Fail?
• OpenReview: Multi-LLM Debate
• OpenReview: AgentNet
• OpenReview: Large Language Models Miss the Multi-agent Mark