1 前言

本文面向已做出该决策、现在需要确定哪种协调模式适合自己的问题的团队。

我们见过团队根据"哪种听起来更先进"来选择模式,而不是根据实际问题本身。我们建议从最简单的可行模式开始,观察其局限性,再逐步演进。本文将深入分析五种模式的机制与局限:

  • **生成器-验证器(Generator-verifier):**适用于质量关键型输出且评估标准明确的场景
  • **编排器-子智能体(Orchestrator-subagent):**适用于任务分解清晰、子任务有边界的场景
  • **智能体团队(Agent teams):**适用于并行、独立、长期运行的子任务
  • **消息总线(Message bus):**适用于事件驱动流水线且智能体生态系统不断增长的场景
  • **共享状态(Shared state):**适用于智能体相互构建成果的协作型工作

2 模式一:生成器-验证器

这是最简单的多智能体模式,也是部署最广泛的模式之一。在前文中我们将它称为验证子智能体模式;本文采用更宽泛的"生成器-验证器"框架,因为生成器不必充当编排器。

2.1 工作原理

生成器接收任务并产生初始输出,随后将其传递给验证器进行评估。验证器检查输出是否满足既定标准:若满足则接受为最终结果;若不满足则连同反馈一并退回。生成器根据反馈产生修订版本。此循环持续进行,直至验证器接受输出或达到最大迭代次数。

2.2 适用场景

以客服工单邮件回复生成为例。生成器根据产品文档和工单上下文产生初始回复;验证器对照知识库检查准确性,对照品牌指南评估语气,并确认回复是否解决了每个提出的问题。未通过的检查项会返回生成器,并附上具体问题说明,例如将功能错误地归因于错误的定价层级,或遗漏了工单中的某个问题。

当输出质量至关重要、且评估标准可以明确制定时,可采用此模式。该模式适用于代码生成(一个智能体写代码,另一个智能体编写并运行测试)、事实核查、基于评分标准的评分、合规验证,以及错误输出代价高于额外生成成本的任何领域。

2.3 局限性

验证器的好坏完全取决于其标准。如果验证器只被告知"检查输出是否好",而没有进一步的标准,它就会橡皮图章般地通过生成器的输出。团队最常犯的错误是实现了循环但没有定义何为"验证",这创造了质量控制的假象而没有实质。(在前文中我们讨论过这个"早期胜利"问题。)

该模式还假定生成与验证是可分离的技能。如果评估创意方案和生成创意一样困难,验证器可能无法可靠地发现问题。

最后,迭代循环可能停滞。如果生成器无法解决验证器的反馈,系统会在不收敛的情况下振荡。设置最大迭代次数并配合后备策略(升级给人工处理、返回带警示的最佳尝试)可防止无限循环。

3 模式二:编排器-子智能体

层次结构是此模式的核心。一个智能体扮演团队负责人角色,负责规划工作、分配任务和整合结果。子智能体处理特定职责并返回报告。

3.1 工作原理

主导智能体接收任务后决定如何处理。它可以直接处理部分子任务,同时将其他子任务分派给子智能体。子智能体完成工作并返回结果,编排器将结果整合为最终输出。

Claude Code 使用的就是此模式。主智能体自行编写代码、编辑文件和运行命令;当需要搜索大型代码库或调查独立问题时,它在后台分派子智能体,使工作继续进行的同时结果流回。每个子智能体在各自的上下文窗口中运行,并返回提炼后的发现。这使编排器的上下文专注于主要任务,而探索工作并行进行。

3.2 适用场景

以自动化代码评审系统为例。当拉取请求到达时,系统需要检查安全漏洞、验证测试覆盖率、评估代码风格,以及评价架构一致性。每项检查都各不相同,需要不同的上下文,并产生明确的输出。编排器将每项检查分派给专门的子智能体,收集结果后整合为统一的评审意见。

当任务分解清晰、子任务之间依赖性最小时,可采用此模式。编排器保持对整体目标的连贯视图,而子智能体专注于各自的职责。

3.3 局限性

编排器成为信息瓶颈。当子智能体发现与其他子智能体工作相关的信息时,该信息必须经由编排器中转。如果安全子智能体发现了一个影响架构子智能体分析的认证漏洞,编排器必须识别这一依赖关系并适当地路由信息。经过多次这样的交接,关键细节往往丢失或被总结掉。

顺序执行也限制了吞吐量。除非明确并行化,子智能体逐一运行,意味着系统承担了多智能体的 token 成本而没有获得速度收益。

4 模式三:智能体团队

当工作分解为可以独立进行较长时间的并行子任务时,编排器-子智能体模式可能变得不必要地受限。

4.1 工作原理

协调器将多个工作智能体作为独立进程启动。队友从共享队列中认领任务,自主地跨多个步骤处理任务,并发出完成信号。

与编排器-子智能体的区别在于工作智能体的持久性。编排器为一个有界子任务生成一个子智能体,子智能体在返回结果后终止。队友在多次任务中保持存活,积累上下文和领域专长,随时间推移提升性能。协调器分配工作并收集结果,但不会在任务之间重置工作智能体。

4.2 适用场景

以大型代码库从某一框架迁移到另一框架为例。一个队友可以独立迁移每个服务,拥有各自的依赖项、测试套件和部署配置。协调器将每个服务分配给一个队友,每个队友自主完成迁移工作:依赖项更新、代码修改、测试修复、验证。协调器收集已完成的迁移,并在整个系统上运行集成测试。

当子任务相互独立且受益于持续的多步骤工作时,可采用此模式。每个队友积累其领域的上下文,而不是每次分派时从头开始。

4.3 局限性

独立性是关键要求。与编排器-子智能体不同,编排器可以在子智能体之间调解并路由信息,队友自主运作,无法轻易共享中间发现。如果一个队友的工作影响另一个队友的工作,双方都无从知晓,其输出可能产生冲突。

完成检测也更困难。由于队友自主运作的时长可变,协调器必须处理部分完成的场景——一个队友两分钟完成,另一个队友需要二十分钟。

共享资源加剧了这两个问题。当多个队友操作同一代码库、数据库或文件系统时,两个队友可能编辑同一文件或做出不兼容的变更。该模式需要仔细的任务划分和冲突解决机制。

5 模式四:消息总线

随着智能体数量增加和交互模式变得更加复杂,直接协调变得难以管理。消息总线引入了一个共享通信层,智能体在此发布和订阅事件。

5.1 工作原理

智能体通过两个原语进行交互:发布(publish)和订阅(subscribe)。智能体订阅它们关心的主题,路由器(router)递送匹配的消息。新增的具有新能力的智能体可以开始接收相关工作,而无需重新连接现有交互。

5.2 适用场景

安全运营自动化系统是此模式优势的体现案例。警报来自多个来源,分类智能体按严重程度和类型对每个警报进行分类,将高严重程度的网络警报路由到网络调查智能体,将凭证相关的警报路由到身份分析智能体。每个调查智能体可能发布丰富化请求,由上下文收集智能体满足。调查结果流向响应协调智能体,由其决定适当的行动。

此流水线适合消息总线,因为事件从一个阶段流向下一个阶段,团队可以随着威胁类别的发展添加新的智能体类型,且团队可以独立开发和部署智能体。

对于事件驱动流水线(工作流从事件中出现而非预先确定的顺序),以及智能体生态系统可能增长的场景,可采用此模式。

5.3 局限性

事件驱动通信的灵活性使追踪更加困难。当一个警报触发跨五个智能体的事件级联时,理解发生了什么需要仔细的日志记录和关联分析。调试比跟踪编排器的顺序决策要困难得多。

路由准确性也至关重要。如果路由器错误分类或丢弃了一个事件,系统会静默失败——什么都不处理但永远不会崩溃。基于 LLM 的路由器提供语义灵活性,但也引入其自身的故障模式。

6 模式五:共享状态

前几种模式中的编排器、团队负责人和消息路由器都集中管理信息流。共享状态通过让智能体通过一个持久存储直接读写来协调,消除了中间人。

6.1 工作原理

智能体自主运作,从共享数据库、文件系统或文档中读取并向其写入。没有中央协调器。智能体检查存储中的相关信息,根据发现的内容采取行动,并将发现写回。工作通常从初始化步骤开始——用问题或数据集填充存储;结束于满足终止条件时:时间限制、收敛阈值,或指定一个智能体判断存储中是否已包含足够答案。

6.2 适用场景

以研究综合系统为例。多个智能体调查复杂问题的不同方面:一个探索学术文献,另一个分析行业报告,第三个审查专利申请,第四个监控新闻报道。每个智能体的发现可能影响其他智能体的调查。学术文献智能体可能发现一位关键研究者,其公司正是行业智能体应该更仔细审查的对象。

使用共享状态,发现直接进入存储。行业智能体可以立即看到学术智能体的发现,而无需等待协调器路由信息。智能体在彼此的工作基础上构建,共享存储成为一个不断发展的知识库。

共享状态还消除了协调器作为单点故障的问题。如果任何一个智能体停止,其他智能体继续读写。在编排器和消息总线系统中,协调器或路由器故障会使一切停止。

6.3 局限性

没有明确的协调,智能体可能重复工作或采取矛盾的方法。两个智能体可能独立调查同一条线索。智能体交互产生系统行为而非自上而下的设计,这使得结果不太可预测。

更难解决的故障模式是反应循环。例如,智能体 A 写下一个发现,智能体 B 读取后写跟进,智能体 A 看到跟进后做出回应。系统持续消耗 token 在不收敛的工作上。重复工作和并发写入有已知的工程解决方案(锁、版本控制、分区)。反应循环是行为问题,需要专门的终止条件:时间预算、收敛阈值(N 个周期无新发现),或指定一个智能体负责判断存储中是否已包含足够答案。把终止作为事后考虑的系统往往会无限循环,或者在某个智能体的上下文填满时任意停止。

7 模式的选择与演进

正确的模式取决于关于系统结构的几个关键问题。在前文中,我们主张上下文为中心的分解(context-centric decomposition),即按每个智能体需要什么上下文来划分工作,而非按工作类型划分。这个原则在这里同样适用。这些模式的区别在于它们如何管理上下文边界和信息流。

7.1 编排器-子智能体与智能体团队

两者都涉及协调器向其他智能体分派工作。问题是工作智能体需要保持上下文多长时间。

  • 当子任务短小、专注且产生明确输出时,**选择编排器-子智能体。**代码评审系统很适合,因为每项检查运行分析、生成报告并在一次有界调用中返回。子智能体不需要在多个周期之间保持上下文。
  • 当子任务受益于持续的多步骤工作时,**选择智能体团队。**代码库迁移很适合,因为每个队友对分配给它的服务形成真正的熟悉度:依赖图、测试模式、部署配置。积累的上下文以单次分派无法复制的方式提升性能。

当子智能体需要在调用之间保持状态时,智能体团队是更好的选择。

7.2 编排器-子智能体与消息总线

两者都可以处理多步骤工作流。问题是工作流结构的可预测程度。

  • 当步骤顺序是预先知道的,**选择编排器-子智能体。**代码评审系统遵循固定流水线:接收 PR、运行检查、综合结果。
  • 当工作流从事件中出现且可能因发现的内容而变化时,**选择消息总线。**安全运营系统无法预测会收到什么警报或需要什么调查路径。新的警报类型可能需要新的处理方式。消息总线通过将事件路由到有能力的智能体来适应这种可变性,而不是遵循预定顺序。

随着条件逻辑在编排器中积累以处理越来越多的情况,消息总线使这种路由变得明确和可扩展。

7.3 智能体团队与共享状态

两者都涉及智能体自主工作。问题是智能体是否需要彼此的发现。

  • 当智能体工作在互不交互的独立分区上时,**选择智能体团队。**代码库迁移很适合,因为每个队友处理其服务,协调器在最后合并结果。
  • 当智能体的工作是协作性的,发现应该实时流动时,**选择共享状态。**研究综合系统更合适,因为学术智能体发现一位关键研究者会立即与行业智能体的调查相关。

一旦队友需要相互通信而不仅仅是共享最终结果,共享状态使这变得更自然。

7.4 消息总线与共享状态

两者都支持复杂的多智能体协调。问题是工作是作为离散事件流动还是累积到共享知识库。

  • 当智能体在流水线中响应事件时,**选择消息总线。**安全运营系统逐阶段处理警报,每个事件在完成之前触发下一个。模式在将事件高效路由到有能力的智能体方面很有效。
  • 当智能体随时间积累发现时,**选择共享状态。**研究综合系统持续收集知识。智能体反复返回存储,查看他人发现的内容并调整调查。

消息总线仍然有路由器,这意味着一个中央组件决定事件去向。共享状态是去中心化的。如果消除单点故障是优先事项,共享状态更彻底地提供这一点。

如果消息总线系统中的智能体发布事件是为了共享发现而非触发动作,共享状态是更好的选择。

8 入门建议

生产系统通常组合使用多种模式。一种常见的混合模式是整体工作流使用编排器-子智能体,协作密集型子任务使用共享状态。另一种是使用消息总线进行事件路由,每个事件类型由类智能体团队的工作智能体处理。这些模式是构建块,不是互斥的选择。

下表总结了每种模式的适用场景。

场景 模式
质量关键型输出,评估标准明确 生成器-验证器
任务分解清晰,子任务有界 编排器-子智能体
并行工作负载,独立长期运行的子任务 智能体团队
事件驱动流水线,智能体生态系统增长 消息总线
协作研究,智能体共享发现 共享状态
无需单点故障 共享状态

对于大多数用例,我们建议从编排器-子智能体开始。它以最少的协调开销处理最广泛的问题。观察其局限性,然后根据具体需求的明确程度向其他模式演进。

学AI大模型的正确顺序,千万不要搞错了

🤔2026年AI风口已来!各行各业的AI渗透肉眼可见,超多公司要么转型做AI相关产品,要么高薪挖AI技术人才,机遇直接摆在眼前!

有往AI方向发展,或者本身有后端编程基础的朋友,直接冲AI大模型应用开发转岗超合适!

就算暂时不打算转岗,了解大模型、RAG、Prompt、Agent这些热门概念,能上手做简单项目,也绝对是求职加分王🔋

在这里插入图片描述

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料,手把手帮你快速入门!👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型(GPT、文心一言等)特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架(LangChain等)实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块,看似清晰好上手,实则每个部分都有扎实的核心内容需要吃透!

我把大模型的学习全流程已经整理📚好了!抓住AI时代风口,轻松解锁职业新可能,希望大家都能把握机遇,实现薪资/职业跃迁~

这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费

在这里插入图片描述

Logo

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地,聚焦技能开发、插件实践与部署教程,为开发者提供可直接落地的方案、工具与交流平台,助力高效构建与落地 AI 应用

更多推荐