我今天不想先给大家下定义#

如果今天让我讲 MultiAgent，我大概率不会先放定义，也不会上来先讲一页分类框架。

因为我觉得那样很容易把人讲跑。

很多同学其实不是没见过这个词。问题不在于没听过，而在于越听越乱。你看过几篇文章之后，会发现它一会儿像团队协作，一会儿像工作流编排，一会儿又像协议互通，再往后甚至会突然开始聊自治网络、智能体社会、去中心化协商。

最后的感觉通常不是“我懂了”，而是“我好像每个词都见过，但我还是不知道它到底在解决什么问题”。

所以如果今天是做一场正式分享，我更愿意先从一个大家都能秒懂的画面讲起。

想象一下，你让一个 Agent 一个人同时干 PM、开发、测试、值班同学和 reviewer 的活。它前一秒还在读需求，下一秒要去查资料、调工具、改代码、跑测试、写总结，中间还得处理新插进来的反馈和越来越长的上下文。

这时候系统开始出问题，其实一点都不奇怪。

奇怪的是，过去我们居然经常默认这套做法应该成立。

所以我今天真正想讲的，不是“MultiAgent 这个词有多新”，而是另一件更现实的事：

为什么单 Agent 开始不够用，以及 MultiAgent 到底在解决什么问题。

如果想看资料密集版

如果想对照阅读原始资料版，可以看 《MultiAgent：协作形态、关键技术与现实判断》。

这篇是更细的标准讲稿，适合 40 到 60 分钟展开。

为什么这个问题现在必须重讲#

先讲第一件事：MultiAgent 根本不新。

传统 MAS，也就是 Multi-Agent Systems，多智能体系统，其实是老题目。分布式人工智能也不是今天才有。严格说，这个方向的历史比很多现在讨论 Agent 的文章要早得多。

那为什么到 2024 到 2026，这个词又重新热起来了？

我觉得真正的原因不是“这个词被重新发明了”，而是问题重心变了。

以前大家讨论 AI，更像是在问：

• 模型够不够聪明
• 回答像不像人
• 补全快不快
• 它写出的代码顺不顺手

但到了这两年，这套问法开始不够用了。

越来越多真实任务卡住的，不是模型会不会说，而是一个单体 Agent 根本不适合同时承担这么多责任。它既要理解目标，又要调工具、跨系统、维持长上下文、处理中断、自己给自己验收，最后还要保证别失控。

这时候你会发现，瓶颈已经不只是“模型能力够不够”，而是另一件事：

系统组织能力够不够。

这句话很重要，因为它决定了后面的很多讨论为什么会出现。

如果瓶颈在模型能力，那思路通常是：

• 换更强的模型
• 换更大的上下文
• 调更好的提示词

但如果瓶颈开始迁移到系统组织能力，那问题就会自然变成：

• 任务怎么拆
• 上下文怎么分
• 谁负责执行
• 谁负责验收
• 长任务怎么恢复
• 出问题时怎么追踪

也就是说，问题已经慢慢从“让模型回答”变成“让系统长期把事做完，而且别失控”。

我觉得这就是今天必须重新讲 MultiAgent 的根本原因。

我会先帮大家把一个误解打掉#

很多人一提 MultiAgent，就会脑补成一种很酷的场面：

屏幕上开了很多对话框，一群 Agent 像开会一样轮流发言，最后好像就比单个 Agent 更聪明。

这个画面不能说完全错，但它很容易把大家带偏。

因为今天工业界主流公开案例真正值钱的，不是“大家一起聊天”，而是：

• 有人负责组织任务
• 有人负责并行执行
• 有机制负责回收结果
• 有护栏负责限制失控
• 有长任务运行机制负责恢复

换句话说，MultiAgent 到今天先成熟的，不是“更多聊天角色”，而是“更有组织的执行系统”。

这也是为什么我不太喜欢一上来就讨论“它到底算不算群体协作”“它到底算不算真正的多智能体”。

这些问题当然可以讨论，但如果开场就卡在这里，反而会错过真正更现实的那一层：

为什么越来越多任务已经开始逼着我们承认，单 Agent 不是万能执行单元。

先别记术语，先记三个问题#

如果要把 MultiAgent 讲明白，我觉得最有用的方式不是背分类框架，而是先记住三个问题：

1. 谁在指挥？
2. 任务怎么流？
3. Agent 靠什么协作？

这三个问题特别重要，因为它们不是一棵只能单选的分类树，而是三个观察维度。

这一点非常关键。

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

• 控制上是中心化的
• 主任务按“主脑拆题、下面分头执行”的方式推进
• 中间结果围着共享状态收敛
• 运行时又靠事件触发往前推进

如果不把这些维度拆开，很多文章就会写成一种很奇怪的状态：

前面在讲控制拓扑，后面突然开始讲协作介质，再往后又拐到协议互通，读者自然会感觉“每个词都认识，但合在一起不知道在说什么”。

所以后面如果你们只记住一句方法论，我希望是这句：

看任何一个 MultiAgent 系统，先别急着问它叫什么，先问它这三个问题。

如果只讲主流落地，我会先讲两种骨架#

第一种骨架是中心化编排。

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

有一个主脑，或者至少有一个明显的主控制流。它知道目标是什么，知道该把任务拆给谁，也知道什么时候继续、什么时候该停下来收结果。

这类系统为什么今天最常见？

因为它现实。

它好排查问题，好加护栏，也比较容易做责任边界。今天公开的一手工业案例，大多数都偏这一类。像 Anthropic 的 multi-agent research system，本质上就很接近“一个主脑拆题、下面分头执行”。

当然，它也有缺点。

比如主协调者容易变瓶颈。一旦主脑判断错了，整串任务都会跟着偏。而且如果拆分本身不合理，下面的 worker 再努力也没什么用。

但即便如此，它依然是今天最容易落地的一类。

第二种骨架是固定主路径的流程推进。

这种系统更像接力赛，不像开会。

前一个节点做完，结果交给下一个节点，整条链像流程图一样往前走。企业为什么特别喜欢这种模式？因为它可预测、可回放、可恢复，也容易人工接管。

比如报销审批、复杂工单、审计流程、风控复核，这些场景天然就适合这种固定流程。因为每一步相对稳定，完成条件也比较清楚。

如果把这两种骨架压成一句话，就是：

今天工业界主流公开案例，更多是在解决“怎么让系统有组织地执行”，而不是“怎么造一个智能体社会”。

去中心化当然重要，而且学术上也很有意思。但至少到 2026 年 4 月，从公开生产经验来看，它还不是默认起点。

这里我要停一下，讲一个大家最容易混淆的点#

很多同学听到这里，会自然把“任务怎么流”和“Agent 之间怎么说话”混在一起。

但它们不是一回事。

任务怎么流，指的是主任务的推进骨架。

Agent 之间怎么说话，指的是中间结果怎么传、怎么共享、怎么收敛。

很多系统表面上看起来很热闹，到处都在发消息，但真正决定它骨架的，还是主任务到底怎么推进，以及结果怎么收敛。

所以如果再往下讲，我会把常见协作方式拆成几类，让大家看到它们到底分别在回答什么问题。

真正常见的协作方式，我会这样讲#

第一种是“主脑拆题、下面分头做事”。

它最像主脑拆题，下面的人分头做事。很适合宽搜型任务、research、复杂问题拆子问题。

第二种是“固定流程接力”。

它最像固定步骤接力推进。适合企业流程、长任务、需要断点恢复和人工接管的场景。

第三种是“评审团模式”。

它不是为了更快，而是为了更稳。几个 Agent 对同一个问题独立判断，再交给一个 judge 或 reviewer 汇总。很适合高不确定性推理、方案评审、红队、安全分析。

第四种是“共享白板模式”。

这个词特别容易被写糊。它不是“大家一直在聊天”，而是大家围着同一个共享状态空间工作。更像多人围着一块白板，或者围着同一份持续更新的任务面板。

第五种是“异步事件驱动”。

它更像消息总线。谁收到事件，谁满足条件，谁就开始干活。真正流动的不是长对话，而是 task、message、event 和状态变化。

第六种是“对等协作”或“去中心化”。

它更像多个独立组织协商，没有一个永远在线的总指挥。这个方向很迷人，但工程上也最难，因为它会立刻逼出信任、收敛、冲突解决这些真问题。

如果学生问我：“老师，这么多模式到底该怎么记？”

我会说，不要硬背词。

你只要先问清楚三件事：

• 有没有总指挥
• 主任务怎么推进
• 中间结果靠什么收敛

能回答这三句，后面的名字就只是标签。

如果要讲例子，我一定会讲一个大家能代入的 Bug 场景#

比如一个在线 SaaS 后台刚改完 RBAC 模型，结果线上出现了一个故障：

被邀请加入团队的新用户，点击邀请链接后会卡在 loading，永远进不去团队。

如果让一个大 Agent 从头查到尾，它通常会把前端、后端、鉴权、邮件链接、数据库状态全部塞进一个上下文里。最后不是漏掉关键线索，就是顺手改出一串副作用。

但如果我们按“一个主脑拆题、下面分头执行”去理解，就会很清楚：

• 主 Agent 先判断这是一个“邀请链路失效”问题
• 一个 subagent 看前端邀请页和 network trace
• 一个 subagent 看后端验签、token 解码和成员落库逻辑
• 一个 subagent 看最近和 RBAC / auth / invitation 相关的提交

最后再由主 Agent 汇总：

• 前端到底卡在哪个请求
• 后端权限逻辑到底哪一步变了
• 最近哪次提交最可疑

这个例子的重点不是“多叫几个 Agent 名字”，而是：

• 主 Agent 不再把所有细节都自己啃完
• 每个 subagent 只拿解决当前子问题需要的上下文
• 最后的判断和交付仍然回到主 Agent 手里

这就是为什么这种模式在 CodeAgent 场景里特别有说服力。

不是因为写代码天然需要很多 Agent，而是因为某些问题天然就需要拆视角、拆上下文、拆验证责任。

如果只挑两个公开案例，我会讲这两个#

第一个案例是 Claude Code 的 Agent Teams。

我觉得它很有代表性，因为它不是在演示“一群 Agent 一起思考”，而是在把多 Agent 做成一个真实的小组。

你会看到：

• 有 team lead
• 有并行工作的 teammates
• 有 shared task list
• 有 mailbox
• 每个 Agent 还有自己的上下文窗口

这个案例最值得看的地方，不是“Agent 数量变多了”，而是任务所有权、并行执行、review 和结果回收开始长成一个团队闭环。

如果再结合 Anthropic 那篇“用一组并行 Claudes 写 C 编译器”的文章去看，会更清楚。

那篇文章真正有信息量的地方不是“很多 Agent 一起写编译器”这个噱头，而是它暴露了工程上真正难的东西：

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

所以 Claude Code 这个案例最后告诉我们的，不是“Agent 多就更强”，而是：

多 Agent 一个非常现实的方向，是把任务所有权、并行开发、review 和结果回收做成团队闭环。

第二个案例是 Kimi K2.5 里提到的 Agent Swarm 研究预览。

它代表的是另一条线：不是先把角色和流程全部写死，而是围绕大目标动态决定还要不要继续拆，能不能继续并行扩张。

它最有价值的地方也不是名字，而是它在回答另一个问题：

任务拆到多细、哪些支线该并行，这件事能不能越来越多地交给系统自己决定。

从这个角度看，这两个案例其实不是在争一个标准答案，而是在不同层面推进同一件事：

• Claude Code 更像把组织关系做清楚
• Kimi K2.5 更像把并行协同做大

一个在把“团队长什么样”做实。

一个在把“系统能扩张到什么规模”往前推。

真正难的不是名字，而是底层几层东西总被写成一锅粥#

很多人读 agent 文章，读到这里就会开始掉线。

原因很简单：大家特别喜欢把“能力”“记忆”“编排”“消息流”和“跨系统协议”混成一锅讲。

如果我在讲座里讲这一段，我会把它讲得非常简单。

你可以把一个 MultiAgent 系统想成一台机器，然后按五层去拆。

第一层，看它有没有手脚。

也就是单个 Agent 到底会不会推理、会不会调工具、能不能查知识、能不能跑代码、能不能接外部 API。没有这一层，后面所有“多 Agent 协作”都没意义，因为连单个节点能做什么都不成立。

第二层，看它记不记事。

也就是长期记忆、当前状态和中间产物这些东西怎么分。哪些属于长期记忆，哪些属于当前局势，哪些属于已经产出的中间结果。

这里我通常会举一个工单例子。

比如“企业客户被重复扣费，同时管理员账号登不上去”。

那长期记忆可能是：

• 这个客户过去 30 天报过两次支付异常
• 这个工作区上周刚做过 RBAC 迁移

当前共享状态可能是：

• severity = high
• billing_check = done
• auth_check = pending

中间产物可能是：

• 一份重复扣费分析摘要
• 一段给客户的临时说明草稿
• 一份待人工确认的退款建议单

一旦把这三者拆开，系统设计就会稳很多。

第三层，看谁在调度。

也就是多个 Agent 到底按什么组织方式分工，是一个主协调者带队，还是固定流程接力，还是评审团式交叉判断。

第四层，看消息怎么流。

也就是任务、消息、事件到底怎么在节点之间移动。很多人会把这层和固定流程混掉，但它们不是一回事。

一个系统可以有固定流程，但只靠很简单的点对点消息协作。

一个系统也可以没有固定流程，却靠事件总线和任务状态推进。

第五层，看不同系统之间怎么接线。

也就是当一个 Agent 服务要跨团队、跨系统、跨框架协作时，边界怎么定义，认证怎么做，状态怎么追踪，协议怎么互通。

这也是为什么我会单独把 A2A 这类协议放在这一层，而不会和 MCP、固定流程、长期记忆这些东西混在一起讲。

如果把这五层记住，后面很多原本缠成一团的讨论会突然清楚很多。

讲到这里，我一定会开始泼一点冷水#

因为如果只讲能力、形态、案例，这场讲座很容易听起来特别热血，好像只要把 Agent 多开几个，世界就会自动变好。

但真实工程里，真正折磨人的不是“它能不能跑起来”，而是：

• 它明明跑起来了，为什么老在奇怪的地方翻车
• 翻车之后，为什么没人知道到底是哪一层先歪了
• 明明看起来很聪明，为什么上线以后还是容易自洽地做错事

所以我会把设计原则压成四句很现实的话。

第一，先证明单 Agent 不够，再上 MultiAgent。

这句话听起来保守，但它其实是在帮系统省掉大量伪复杂度。很多团队一上来就想加更多 Agent，本质上是把“任务定义不清、工具接入混乱、验证链不完整”这些更底层的问题，伪装成“需要更多角色”。

第二，上下文和工具都要做减法。

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

第三，执行权和验收权最好分开。

这是很多系统最容易翻车的一点。如果负责做事的 Agent 自己判断自己有没有做好，负责写结果的 Agent 自己决定结果够不够可信，那它就很容易一路自洽到底。

第四，长任务必须考虑持久化、检查点和恢复。

不然系统只会越来越贵，不会越来越稳。因为一旦进入多 Agent 长任务，错误不再只是“一次答错”，而会变成状态错着往后传、子任务错着继续扩散、中途失败后全部从头再来。

这四句听起来不花哨，但它们几乎决定了一个系统最后是不是 demo 玩具。

如果学生问，为什么现在大家突然开始重视验收、轨迹和可观测性#

我会说，因为行业已经开始从“能跑”转向“能证明”。

这两年一个很明显的变化就是，大家不再把“Agent 跑起来了”当成终点，而开始把下面这些问题当成一等问题：

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

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

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

这一点特别值得在分享里讲清楚，因为它跟很多人想象中的“AI 工程”很不一样。

很多人以为这件事的核心竞争力是提示词。

但越到后面你越会发现，真正的差距往往在长任务运行机制、任务轨迹、验收机制、护栏和恢复能力这些地方。

到 2026 年 4 月，我觉得比较稳的结论只有这几条#

如果前面讲了很多细节，最后我一定会把结论收回来。

我觉得到 2026 年 4 月，比较能站住的判断有五个。

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

第二，它先收束成“长任务运行系统”，不是“一次性提示词技巧”。

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

第四，它开始走向“边界协议化”，但这不等于会有一个协议统一世界。

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

最后这一句我会反复强调：

MultiAgent 是结构优势，不是默认信仰。

它只在真正值得拆、拆完职责更清楚、验收和恢复机制更完整的时候，才会比单 Agent 更值钱。

如果今天只能带走一句话#

如果这场讲座最后只能留一句话，我会留这句：

MultiAgent 不是多开几个模型实例，而是在组织一套可分工、可协作、可验收、可恢复的智能执行系统。

再说得更人话一点：

它不是为了让系统看起来更热闹，而是为了别再让一个 Agent 一个人去同时干五六个人的活。

如果我来收尾，我会这样结束#

我会说，今天大家回去之后，不一定非要立刻做一个 MultiAgent 系统。

更重要的是，先把看问题的方式换掉。

下次你再看到一个 agent 产品、一个研究 demo、或者一篇很花哨的介绍文章，先不要问它名字帅不帅，也不要先问它算不算真正的群体协作。

先问三件事：

1. 谁在指挥？
2. 任务怎么流？
3. 它靠什么协作和收敛？

然后再问一句更狠的：

这件事如果不用 MultiAgent，真的不行吗？

如果这几句都答得出来，那你大概率就不容易被概念带着跑。

这也是我觉得今天讲 MultiAgent 最重要的价值。

不是把大家讲成术语专家，而是把大家训练成能判断结构的人。