多智能体协作指南：五种主流模式怎么选、怎么用？【译】

多智能体协作指南：五种主流模式怎么选、怎么用？【译】 多智能体协作指南：五种主流模式怎么选、怎么用？【译】 Modified April 13 在这个模式下，没有所谓的“中心指挥官”。智能体们像在一个公共的大黑板前工作：他们看着黑板上有什么线索，拿走自己能处理的去干活，有了新发现再写回黑板上。通常，启动流程就是在黑板上写下一个大问题或放下一堆初始数据；当满足某个结束条件时，工作就停止——比如时间到了、大家很久没新发现了（收敛阈值），或者某个被专门指派的智能体站出来说“黑板上的答案已经足够好了”。 它在何时最好用 想象一个负责跨领域综合研究的系统。为了调查一个复杂问题，有的智能体负责翻学术论文，有的看行业报告，有的扒专利文件，还有的盯着新闻动态。每个人查到的东西都可能成为别人的关键线索。比如，看论文的智能体偶然发现了一位核心研究员，看行业报告的智能体立马就可以去深挖这家研究员背后的公司。 在共享状态下，所有的发现都直接上黑板。看行业的智能体立马就能看到看论文智能体的新发现，根本不用等协调者来回传话。大家互相踩着对方的肩膀往上爬，这块共享黑板也就渐渐变成了一个不断进化演进的知识库。 这种模式还有一个好处：消除了单点故障。即便某个智能体宕机了，其他人依然能对着黑板继续读写。但在调度模式或消息总线模式里，一旦指挥官或路由器罢工，整个系统就全瘫痪了。 它的局限性在哪 失去了统一指挥，智能体很容易会重复造轮子，或者南辕北辙。比如两个智能体可能不约而同地去调查了同一条线索。系统的最终行为是大家碰撞出来的，而不是从上往下设计好的，这也让结果变得难以预测。 最致命的故障模式是陷入 “反应式死循环” (Reactive loops) 。比如，智能体 A 写下了一个发现，智能体 B 看到后写了一句补充，A 看到补充后又回了一句…… 整个系统就像两个机器人在无限套娃聊天，疯狂燃烧昂贵的算力 (Token) 却无法得出结论。针对重复工作和并发写入，工程师们有成熟的解决办法（比如加锁、版本控制、分区）；但这这种“无限套娃”是一个行为模式问题，你必须在系统设计之初就设定好“一票否决”的终止条件：比如只给固定的时间预算，或者一旦连续几轮都没有新发现就强制停止，或者指派一个“裁判”智能体随时判定答案是否已经圆满。 （注：如果忽略了停止机制的设计，系统要么会无限循环到破产，要么会因为某个智能体的大脑（上下文窗口）被塞满而死机。） 如何在不同模式间选择与进化 选哪种模式，取决于你对系统的几个核心结构问题的判断。在我们之前的文章中，我们提倡 围绕“上下文”来拆解工作（Context centric decomposition） ，即按照每个智能体“需要知道哪些背景信息”来分工，而不是按“它干什么类型的活”来分工。这个原则在这里同样适用。这五种模式最大的区别，就在于它们如何划分上下文的边界，以及如何管理信息的流动。 调度 子智能体 vs. 智能体团队 两者都有一个“分配工作”的协调者。怎么选？问自己：干活的智能体需要长时间保留记忆（上下文）吗？ • 选调度 子智能体 ：如果子任务短平快，目标集中，且输出明确。代码审查系统就适用，因为每次检查都是单次的：跑分析、出报告，直接交差。子智能体不需要在多次任务间保留记忆。 • 选智能体团队 ：如果子任务需要跨越多步、长时间处理才能出成效。代码库迁移适用这个，因为成员们需要长期对付同一个服务模块，慢慢摸透它的依赖关系、测试规律和部署配置。这种积累下来的背景知识，是“用完即走”的调度模式给不了的。 当子智能体需要在多次被唤醒之间记住以前的状态时，智能体团队是更好的选择。 调度 子智能体 vs. 消息总线 两者都能处理多步工作流。怎么选？问自己：你的工作流程是可以提前预测的吗？ • 选调度 子智能体 ：如果步骤早就定好了。就像代码审查系统，永远是那三板斧：接收提交请求、跑检查、汇总结果。 • 选消息总线 ：如果工作流是由突发事件触发的，而且随时可能改变方向。安全运营系统永远猜不到下一秒会来什么警报，或者需要开展什么调查。它甚至需要随时容纳新类型的警报。消息总线通过把事件推给能干活的智能体来适应这种变数，而不是死守着预设的剧本。 如果为了应付越来越多的特殊情况，你的“调度者”脑子里的“If Else”判断语句越堆越多，那么是时候换成消息总线，让分发机制变得更加清晰和容易扩展了。 智能体团队 vs. 共享状态 两者里的智能体都是自主干活的。怎么选？问自己：智能体之间需要互相对答案、抄作业吗？ • 选智能体团队 ：如果大家各人自扫门前雪，互不干涉。代码库迁移中，每个人负责自己的服务，最后统一合并就行。 • 选共享状态 ：如果这是一场需要高度协作的任务，且线索需要实时流转。综合研究系统就很合适，看论文的智能体只要有新发现，看行业的智能体立马就能用上。 一旦团队成员们不再仅仅是交差时汇总结果，而是需要在干活途中频繁互通有无，那赶紧换成共享状态模式吧，它会让交流顺畅得多。 消息总线 vs. 共享状态 两者都擅长处理复杂的多智能体协作。怎么选？问自己：任务是像流水线一样一个个解决事件，还是为了慢慢攒出一个知识库？ • 选消息总线 ：如果智能体是对流水线上的事件做出反应。安全系统就是一环扣一环，处理完上一步才触发下一步。这个模式对“精准派活”非常在行。 • 选共享状态 ：如果智能体是要基于日积月累的线索持续深入。综合研究系统是在不断汇聚知识。智能体们会反复回到黑板前，看看别人发现了什么，然后调整自己的调查方向。 记住，消息总线里依然有个“路由器”在中心掌控全局决定谁接活。而共享状态是彻头彻尾的去中心化。如果你非常在意消除“单点故障”，共享状态能给你最大的安全感。 另外，如果你的消息总线系统里，大家发布消息主要只是为了“共享情报”而不是为了“触发别人的动作”，那说明你选错了，这活儿更适合共享状态模式。 新手指南 在真实的商业环境（生产环境）中，我们往往会混搭使用这些模式。一种常见的组合是：大方向的工作流用 调度 子智能体 ，而在某个需要大量协作的子任务里套用 共享状态 。还有的系统会用 消息总线 来分发事件，而在处理每类事件的末端挂上一个个 智能体团队 。这些模式本质上是积木，并非水火不容。 下表总结了各种模式的适用场景： 适用场景 推荐模式 看重输出质量，且有明确的评估标准 生成 验证者 (Generator Verifier) 任务拆解清晰，子任务边界分明且短平快 调度 子智能体 (Orchestrator Subagent) 工作量可并行，且子任务独立、需要长时间运行 智能体团队 (Agent Teams) 事件驱动的流水线，智能体生态系统还在不断增长 消息总线 (Message Bus) 协作式研究，智能体之间需要频繁共享新发现 共享状态 (Shared State) 绝对不允许出现单点故障导致系统瘫痪 共享状态 (Shared State) 对于绝大多数刚刚起步的需求， 我们强烈建议从“调度 子智能体 (Orchestrator subagent)”开始。 它能以极低的协调成本搞定最广泛的问题。先用它跑起来，观察系统在哪里卡了脖子，然后再根据具体痛点进化到其他模式。 在接下来的文章中，我们将结合生产级别的实际案例，深入探讨每种模式的具体落地做法。如果你想回顾“我们到底什么时候值得投入多智能体系统”，请参阅： 《构建多智能体系统：何时及如何使用它们》 [2] 。 致谢 本文由 Cara Phillips 撰写，Eugene Yang, Jiri De Jonghe, Samuel Weller 以及 Erik Schluntz 亦有贡献。 引用链接 [1] Claude Code: https://code.claude.com/docs/en/overview [2] 《构建多智能体系统：何时及如何使用它们》: https://claude.com/blog/building multi agent systems when and how to use them 在这个模式下，没有所谓的“中心指挥官”。智能体们像在一个公共的大黑板前工作：他们看着黑板上有什么线索，拿走自己能处理的去干活，有了新发现再写回黑板上。通常，启动流程就是在黑板上写下一个大问题或放下一堆初始数据；当满足某个结束条件时，工作就停止——比如时间到了、大家很久没新发现了（收敛阈值），或者某个被专门指派的智能体站出来说“黑板上的答案已经足够好了”。 它在何时最好用 想象一个负责跨领域综合研究的系统。为了调查一个复杂问题，有的智能体负责翻学术论文，有的看行业报告，有的扒专利文件，还有的盯着新闻动态。每个人查到的东西都可能成为别人的关键线索。比如，看论文的智能体偶然发现了一位核心研究员，看行业报告的智能体立马就可以去深挖这家研究员背后的公司。 在共享状态下，所有的发现都直接上黑板。看行业的智能体立马就能看到看论文智能体的新发现，根本不用等协调者来回传话。大家互相踩着对方的肩膀往上爬，这块共享黑板也就渐渐变成了一个不断进化演进的知识库。 这种模式还有一个好处：消除了单点故障。即便某个智能体宕机了，其他人依然能对着黑板继续读写。但在调度模式或消息总线模式里，一旦指挥官或路由器罢工，整个系统就全瘫痪了。 它的局限性在哪 失去了统一指挥，智能体很容易会重复造轮子，或者南辕北辙。比如两个智能体可能不约而同地去调查了同一条线索。系统的最终行为是大家碰撞出来的，而不是从上往下设计好的，这也让结果变得难以预测。 最致命的故障模式是陷入 “反应式死循环” (Reactive loops) 。比如，智能体 A 写下了一个发现，智能体 B 看到后写了一句补充，A 看到补充后又回了一句…… 整个系统就像两个机器人在无限套娃聊天，疯狂燃烧昂贵的算力 (Token) 却无法得出结论。针对重复工作和并发写入，工程师们有成熟的解决办法（比如加锁、版本控制、分区）；但这这种“无限套娃”是一个行为模式问题，你必须在系统设计之初就设定好“一票否决”的终止条件：比如只给固定的时间预算，或者一旦连续几轮都没有新发现就强制停止，或者指派一个“裁判”智能体随时判定答案是否已经圆满。 （注：如果忽略了停止机制的设计，系统要么会无限循环到破产，要么会因为某个智能体的大脑（上下文窗口）被塞满而死机。） 如何在不同模式间选择与进化 选哪种模式，取决于你对系统的几个核心结构问题的判断。在我们之前的文章中，我们提倡 围绕“上下文”来拆解工作（Context centric decomposition） ，即按照每个智能体“需要知道哪些背景信息”来分工，而不是按“它干什么类型的活”来分工。这个原则在这里同样适用。这五种模式最大的区别，就在于它们如何划分上下文的边界，以及如何管理信息的流动。 调度 子智能体 vs. 智能体团队 两者都有一个“分配工作”的协调者。怎么选？问自己：干活的智能体需要长时间保留记忆（上下文）吗？ • 选调度 子智能体 ：如果子任务短平快，目标集中，且输出明确。代码审查系统就适用，因为每次检查都是单次的：跑分析、出报告，直接交差。子智能体不需要在多次任务间保留记忆。 • 选智能体团队 ：如果子任务需要跨越多步、长时间处理才能出成效。代码库迁移适用这个，因为成员们需要长期对付同一个服务模块，慢慢摸透它的依赖关系、测试规律和部署配置。这种积累下来的背景知识，是“用完即走”的调度模式给不了的。 当子智能体需要在多次被唤醒之间记住以前的状态时，智能体团队是更好的选择。 调度 子智能体 vs. 消息总线 两者都能处理多步工作流。怎么选？问自己：你的工作流程是可以提前预测的吗？ • 选调度 子智能体 ：如果步骤早就定好了。就像代码审查系统，永远是那三板斧：接收提交请求、跑检查、汇总结果。 • 选消息总线 ：如果工作流是由突发事件触发的，而且随时可能改变方向。安全运营系统永远猜不到下一秒会来什么警报，或者需要开展什么调查。它甚至需要随时容纳新类型的警报。消息总线通过把事件推给能干活的智能体来适应这种变数，而不是死守着预设的剧本。 如果为了应付越来越多的特殊情况，你的“调度者”脑子里的“If Else”判断语句越堆越多，那么是时候换成消息总线，让分发机制变得更加清晰和容易扩展了。 智能体团队 vs. 共享状态 两者里的智能体都是自主干活的。怎么选？问自己：智能体之间需要互相对答案、抄作业吗？ • 选智能体团队 ：如果大家各人自扫门前雪，互不干涉。代码库迁移中，每个人负责自己的服务，最后统一合并就行。 • 选共享状态 ：如果这是一场需要高度协作的任务，且线索需要实时流转。综合研究系统就很合适，看论文的智能体只要有新发现，看行业的智能体立马就能用上。 一旦团队成员们不再仅仅是交差时汇总结果，而是需要在干活途中频繁互通有无，那赶紧换成共享状态模式吧，它会让交流顺畅得多。 消息总线 vs. 共享状态 两者都擅长处理复杂的多智能体协作。怎么选？问自己：任务是像流水线一样一个个解决事件，还是为了慢慢攒出一个知识库？ • 选消息总线 ：如果智能体是对流水线上的事件做出反应。安全系统就是一环扣一环，处理完上一步才触发下一步。这个模式对“精准派活”非常在行。 • 选共享状态 ：如果智能体是要基于日积月累的线索持续深入。综合研究系统是在不断汇聚知识。智能体们会反复回到黑板前，看看别人发现了什么，然后调整自己的调查方向。 记住，消息总线里依然有个“路由器”在中心掌控全局决定谁接活。而共享状态是彻头彻尾的去中心化。如果你非常在意消除“单点故障”，共享状态能给你最大的安全感。 另外，如果你的消息总线系统里，大家发布消息主要只是为了“共享情报”而不是为了“触发别人的动作”，那说明你选错了，这活儿更适合共享状态模式。 新手指南 在真实的商业环境（生产环境）中，我们往往会混搭使用这些模式。一种常见的组合是：大方向的工作流用 调度 子智能体 ，而在某个需要大量协作的子任务里套用 共享状态 。还有的系统会用 消息总线 来分发事件，而在处理每类事件的末端挂上一个个 智能体团队 。这些模式本质上是积木，并非水火不容。 下表总结了各种模式的适用场景： 适用场景 推荐模式 看重输出质量，且有明确的评估标准 生成 验证者 (Generator Verifier) 任务拆解清晰，子任务边界分明且短平快 调度 子智能体 (Orchestrator Subagent) 工作量可并行，且子任务独立、需要长时间运行 智能体团队 (Agent Teams) 事件驱动的流水线，智能体生态系统还在不断增长 消息总线 (Message Bus) 协作式研究，智能体之间需要频繁共享新发现 共享状态 (Shared State) 绝对不允许出现单点故障导致系统瘫痪 共享状态 (Shared State) 适用场景 适用场景 推荐模式 推荐模式 看重输出质量，且有明确的评估标准 看重输出质量，且有明确的评估标准 生成 验证者 (Generator Verifier) 生成 验证者 (Generator Verifier) 任务拆解清晰，子任务边界分明且短平快 任务拆解清晰，子任务边界分明且短平快 调度 子智能体 (Orchestrator Subagent) 调度 子智能体 (Orchestrator Subagent) 工作量可并行，且子任务独立、需要长时间运行 工作量可并行，且子任务独立、需要长时间运行 智能体团队 (Agent Teams) 智能体团队 (Agent Teams) 事件驱动的流水线，智能体生态系统还在不断增长 事件驱动的流水线，智能体生态系统还在不断增长 消息总线 (Message Bus) 消息总线 (Message Bus) 协作式研究，智能体之间需要频繁共享新发现 协作式研究，智能体之间需要频繁共享新发现 共享状态 (Shared State) 共享状态 (Shared State) 绝对不允许出现单点故障导致系统瘫痪 绝对不允许出现单点故障导致系统瘫痪 共享状态 (Shared State) 共享状态 (Shared State) 对于绝大多数刚刚起步的需求， 我们强烈建议从“调度 子智能体 (Orchestrator subagent)”开始。 它能以极低的协调成本搞定最广泛的问题。先用它跑起来，观察系统在哪里卡了脖子，然后再根据具体痛点进化到其他模式。 在接下来的文章中，我们将结合生产级别的实际案例，深入探讨每种模式的具体落地做法。如果你想回顾“我们到底什么时候值得投入多智能体系统”，请参阅： 《构建多智能体系统：何时及如何使用它们》 [2] 。 致谢 本文由 Cara Phillips 撰写，Eugene Yang, Jiri De Jonghe, Samuel Weller 以及 Erik Schluntz 亦有贡献。 引用链接 [1] Claude Code: https://code.claude.com/docs/en/overview [2] 《构建多智能体系统：何时及如何使用它们》: https://claude.com/blog/building multi agent systems when and how to use them 🔗 原文链接： https://mp.weixin.qq.com/s/UowaONlX... https://mp.weixin.qq.com/s/UowaONlX... Cara Phillips Cara Phillips 宝玉AI2026年4月12日 16:03 美国 我们常常看到，有些团队在挑选模式时，只顾着选听起来“高大上”的，却忽略了到底适不适合手头的问题。我们的建议是： 从最简单的、能跑通的模式开始，观察它在哪里会遇到瓶颈，然后再逐步升级。 今天这篇文章，我们就来拆解五种常见模式的运作原理和局限性： • 生成 验证者 (Generator verifier) ：适用于看重输出质量、且有明确评估标准的场景。 • 调度 子智能体 (Orchestrator subagent) ：适用于任务拆解清晰、子任务边界分明的场景。 • 智能体团队 (Agent teams) ：适用于可以并行处理、互不干扰且需要长时间运行的子任务。 • 消息总线 (Message bus) ：适用于事件驱动的流水线作业，以及系统还在不断扩展新智能体的场景。 • 共享状态 (Shared state) ：适用于需要高度协作、智能体之间需要互相参考别人发现的场景。 这是最简单的多智能体模式，也是目前落地应用最广泛的模式之一。在我们之前的文章中，曾将其称为“验证子智能体模式”，这里我们使用更宽泛的“生成 验证者”来称呼它，因为这里的“生成者”不一定非得是个指挥全局的调度者。 它是如何运作的 生成者 (Generator) 接到一个任务后，会先给出一版初步结果，然后把它传给验证者 (Verifier) 去评估。验证者会检查这个结果是否符合规定的标准。如果符合，就盖章通过；如果不符合，验证者会把具体的修改意见（反馈）打回去。生成者拿着这些反馈再重新修改一版。这个“修改 审核”的循环会一直进行，直到验证者满意，或者达到了系统设定的最大修改次数限制。 它在何时最好用 想象一个用来回复客户工单的自动邮件系统。生成者利用产品文档和工单详情写出一封初稿。验证者则充当“质检员”：核对知识库看事实准不准、检查语气符不符合品牌要求、确认客户提到的每个问题是不是都回答了。如果检查没通过，验证者会把具体问题甩回给生成者，比如指出“把某个功能错误地归到了低配版里”或者“漏答了某个问题”。 当 输出质量至关重要，而且你能把“什么是好结果”用明确的标准写出来 时，用这个模式准没错。它非常适合代码生成（一个智能体写代码，另一个写测试并运行）、事实核查、按固定评分表打分、合规性审查，以及任何“一次错误的代价远大于多跑一圈修改流程”的领域。 它的局限性在哪 这个系统的下限，完全取决于验证者的审核标准有多细。 （注：如果你只告诉验证者“帮我看看这东西好不好”，却不给它具体的条条框框，它往往就会变成一个闭着眼睛盖“合格”章的橡皮图章。） 团队在应用这个模式时最常犯的错误，就是建好了循环机制，却没定义清楚“验证”到底意味着什么，这只会营造出一种“我们在做质量控制”的虚假繁荣。 另外，这种模式假设“生成”和“验证”是两种可以拆开的技能。但如果你要评估的是一个绝妙的创意，评估它的难度可能和想出它一样高，这时候验证者往往就不太靠谱了。 最后，这种循环很容易陷入“死胡同”。如果生成者就是无法解决验证者提出的问题，系统就会在两者之间来回踢皮球，永远无法收敛。因此，必须设置一个最大循环次数限制，并准备好后备方案（比如转交人工，或者带着提示说明返回当前最好的一版），防止它变成死循环。 模式二：调度 子智能体 (Orchestrator subagent) 这个模式的核心在于“层级制”。有一个像“团队主管”一样的核心智能体负责规划工作、分发任务，并最终汇总结果；而各个子智能体 (Subagents) 则负责处理具体的分摊工作，做完后向上级汇报。 它是如何运作的 主导的调度者 (Orchestrator) 收到任务后，会先思考该怎么动手。它可以自己解决一部分，把剩下的指派给不同的子智能体。等小弟们把活干完、交上结果后，调度者再把这些碎片拼成一份完整的最终答案。 Claude Code [1] 用的就是这种模式。主智能体自己负责写代码、改文件、跑命令，但当它需要在庞大的代码库里大范围搜索，或者需要调查一些独立问题时，它就会在后台派发给子智能体。这样主线工作不会停，搜索结果也会源源不断地送回来。每个子智能体都在自己独立的上下文窗口 (Context window) 里工作，只返回精炼后的调查结果。 （注：这就好比老板的脑子（上下文）只需专注于大方向，而查资料等繁杂信息都在员工的大脑里消化，从而保证老板的思路不被琐事塞满。） 它在何时最好用 想想一个自动化的代码审查 (Code review) 系统。当有人提交了新代码，系统需要检查安全漏洞、验证测试覆盖率、评估代码风格、并检查架构一致性。这几个检查方向互不干涉，需要的背景知识也不同，并且都能产出清晰的报告。此时，调度者就可以把任务分发给几个专门的子智能体，等它们查完，再把报告融合成一份全面的审查意见。 当 任务拆解非常明确，且子任务之间互相没啥依赖 时，这个模式非常得心应手。调度者能时刻保持对大目标的掌控，而子智能体则心无旁骛地干好自己的细分工作。 它的局限性在哪 调度者很容易变成信息的“瓶颈”。一旦某个子智能体发现了可能影响另一个子智能体工作的信息，这个情报必须先上报给调度者，再由调度者下发。比如，查安全的智能体发现了一个认证漏洞，这个漏洞恰好会影响查架构的智能体的分析。如果信息在上下级之间倒手太多次，关键细节很容易就在被一次次“总结汇报”的过程中弄丢了。 另外，如果不做专门的并行处理，子智能体会按顺序一个个干活。这意味着你要花着多智能体处理数据（Token）的钱，却享受不到“人多干活快”的速度优势。 模式三：智能体团队 (Agent teams) 当一份大工作可以被拆成多个并行的子任务，而且这些任务需要花很长时间独立完成时，“组长派活”的层级制就会显得太死板了。 它是如何运作的 一个协调者 (Coordinator) 会创建出多个作为独立进程运行的团队成员 (Teammates)。这些成员会从一个共享的任务队列里自己“抢单”，接单后自主完成多步操作，干完再举手示意。 它和“调度 子智能体”最大的区别在于 成员的持久性 。调度者通常是为了一件小事临时叫出一个子智能体，干完就解散。但在团队模式里，成员们是长期存在的，它们在接手一个个任务的过程中，会不断积累领域知识和上下文，越干越熟练。协调者只管派活和收作业，并不会在每次任务结束后把它们的记忆清空。 它在何时最好用 假设你要把一个庞大的代码库从一个框架迁移到另一个框架。每个团队成员都可以独立负责迁移其中一个服务模块，自己处理依赖项、改代码、修测试 bug、做验证。协调者把一个个模块分给成员，成员们自主完成这一整套迁移流程。最后协调者把所有迁移好的模块攒在一起，跑一遍系统级的集成测试。 当 子任务相互独立，且需要跨越多步、长时间处理 时，用这个模式最爽。因为每个成员都在不断积累自己那个小领域的经验，而不是每次接活都像个失忆的新手。 它的局限性在哪 “独立”是这个模式的生命线，也是软肋。不像调度模式里有个组长帮忙传话，团队成员们都是闷头干活的，彼此之间很难共享中间进度。如果 A 的工作会影响到 B，他们俩却毫不知情，最后交上来的结果可能就打架了。 进度管理也是个让人头疼的问题。因为大家干活的时间长短不一，有的两分钟搞定，有的要弄二十分钟，协调者必须得有耐心处理这种“参差不齐”的部分完成状态。 如果大家还要抢夺公共资源，问题就更大了。当多个成员同时在改同一个代码库、数据库或文件时，很容易发生两个人改同一个文件或者做出互相冲突的修改。这就要求我们在任务分配时划好“楚河汉界”，并准备好冲突解决机制。 模式四：消息总线 (Message bus) 随着智能体数量增加，大家互动的方式越来越复杂，直接让他们面对面交流会变成一场灾难。这时候，消息总线 (Message bus) 就登场了：它提供了一个共享的通讯大厅，让智能体们通过“发布”和“订阅”来协调工作。 它是如何运作的 智能体只靠两个基本动作交流：发布 (Publish) 和订阅 (Subscribe)。智能体会订阅自己关心的“话题”，一个路由器 (Router) 会把相关的消息精准推给它们。 （注：这就好比在一个大型公司群里，有人在群里发需求，相关部门的人看到了自动领走，你根本不需要知道具体是谁接了单。） 如果未来有了新功能的智能体加入，它们只要订阅相应的话题就能直接上岗，完全不需要改动现有的网络线路。 它在何时最好用 自动化安全运营系统是这个模式的完美舞台。各种渠道的警报像雪片一样飞来，一个“分诊智能体”负责评估严重程度和类型，把高危的网络警报推给“网络调查智能体”，把账号相关警报推给“身份分析智能体”。调查智能体在干活时，可能还会发布一条“需要更多背景”的需求，专门负责收集情报的智能体看到后就会去帮忙。最后，所有的发现都会流向“响应协调智能体”，由它来拍板怎么处理。 这种流水线简直就是为消息总线量身定制的：事件从上一个环节顺畅地流向下个环节；随着新型威胁出现，团队可以随时往里塞新的安保智能体；各个智能体的开发和部署也可以互不干扰。 当系统是一个 由事件驱动的流水线（工作流是由突发事件决定的，而不是定死的顺序），而且你的智能体团队未来很可能会继续扩编 时，选它。 它的局限性在哪 这种事件驱动的通讯过于灵活，导致排查问题非常困难。当一个警报像多米诺骨牌一样触发了五个智能体的连锁反应时，想搞清楚中间到底发生了什么，你必须查阅非常仔细的日志记录并进行关联对比。这可比跟着“调度者”一步步按顺序查 bug 痛苦多了。 路由器的分发准确性也至关重要。如果路由器把消息分错了类，或者干脆漏发了，系统就会陷入“静默崩溃”——它不报错，没死机，但就是什么也不干。基于大语言模型 (LLM) 的路由器虽然能在理解语义上更灵活，但也带来了 LLM 特有的失灵风险（比如理解偏差或幻觉）。 模式五：共享状态 (Shared state) 在前几种模式里，无论是调度者、协调者还是路由器，本质上都在充当信息流的“中间商”。而共享状态 (Shared state) 模式则彻底干掉了中间商，它让所有智能体共同面对一个持久化的存储区（比如数据库、文件系统或文档），大家可以直接从中读取信息、写入结果。 它是如何运作的