多智能体系统（Multi Agent）：何时拆分，何时一个就够？

搭建多智能体系统（Multi Agent）之前，先从 1 个智能体和更好用的工具做起。只有当不同执行者能够独立调查、保留各自的上下文，或分别负责不同工作时，多智能体才有价值。如果规划、研究、编码和审查角色总要依赖同一份信息，协调它们所花的精力，可能比真正推进工作还多。

判断是否该拆分，关键在于：执行者能否接到明确任务，在不必反复沟通的情况下完成有用的工作，再交回可供核验的结果？如果做不到，把一个智能体拆成多个，通常只是把难题转移到了智能体之间的消息往来中。

下文涉及的框架行为，已于 2026 年 10 月 26 日对照开发方当时的在线文档核验。决策表则将这些有文档依据的模式，应用于开发者常见的任务。

Multi Agent 多智能体系统是什么？

多智能体系统把一项大任务的不同部分交给不同智能体负责，并提供交换工作成果的机制。 在大语言模型（LLM）应用中，智能体是运行在循环里的模型：它可以选择工具、检查执行结果，再决定下一步做什么。多个智能体共同协调这些决策，而不是把所有决策都放在同一个执行者身上。IBM 的概述介绍了智能体相互交互的更广义结构。

这些智能体可以使用相同的底层模型。让它们彼此独立的是执行上下文和职责，而不是模型名称是否不同。例如，可以让研究智能体拿到资料和搜索工具，让编码智能体拿到代码仓库和明确的修改要求。

可以把它想成音乐制作人合并分别录制的音轨。乐手们对编曲已有共识时，分开录制很有效；如果每个人都在改速度、重写同一段旋律，制作人就只能忙着协调彼此不兼容的录音。智能体团队也面临同样的取舍：哪些工作能独立完成，哪些工作需要持续协调。

本文讨论的是哪类 AI 多智能体系统？

正如 Google Cloud 的概述所介绍的，多智能体这一领域还包括机器人、自动驾驶汽车和仿真。本文聚焦于承担研究、软件开发和业务任务的 LLM 智能体，讨论何时值得拆分。

调用模型多次，并不自动构成多智能体系统。一个智能体可以搜索、读文件、写代码、检查成果，整个过程仍然只有一个智能体。固定顺序的提示词调用，也可能只是工作流，并没有自主执行任务的智能体。区别在于：由谁做决策，以及决策使用哪一份上下文。

如果想先了解模型调用、工具使用和停止机制，可以从智能体循环读起。无论有多少智能体，更完整的 AI 智能体架构都需要状态管理、权限和可观测的结果。

多智能体系统怎么设计？先看任务如何拆分

当职责边界消除的复杂度多于它带来的复杂度时，再选择多个智能体。 有价值的边界能够分开不同证据、专业领域或责任；如果只是给下一条提示词安上一个职位名称，这种拆分就只是形式。

选框架之前，可以先按下表判断：

对创业者来说，第一版助手不需要一张组织架构图。对开发者来说，需要明确指出：究竟是哪项依赖，让执行者无法独立推进？对运营者来说，应评估整个任务完成得怎么样，把纠错成本也算进去，而不是统计有多少专门角色参与。

常见的规划、研究、编码、审查，确实是一份有用的工作清单，却不一定适合拆成独立进程。规划可以在编码智能体内部完成，研究可以通过一次工具调用完成，审查则可以先从能给出明确通过或失败结果的测试做起。

假设任务是修复发票导出功能。计划依赖数据库结构，而实施时又发现结构中存在例外，那么独立的规划智能体就必须反复接收更新。这种情况下，规划应当紧贴实施过程。不过，如果另设的审查者能拿到最终补丁、导出要求和相关测试结果，仍然可能有帮助。

多智能体架构有哪些常见模式？

这些模式的主要区别，是谁对最终答案负责，以及执行者之间需要传递多少信息。 监督者、层级结构、交接和群聊，可以组合使用，并不是互斥的产品类别。

监督者与编排者—执行者模式：由一个智能体对结果负责

LangGraph 是支持有状态智能体工作流的运行时，支持由监督者分配边界明确的任务并汇总结果。监督者始终对面向用户的结果负责，执行者则返回发现或产物。

在 LangChain 当前的监督者教程中，日历智能体和邮件智能体被封装为高层工具。监督者调用这些工具，接收专门角色的最终回复，无需把每一步中间操作都放进自己的对话上下文。

这里有一个重要的实现区别：langgraph-supervisor 参考文档仍然记录了 create_supervisor，但建议大多数场景直接通过工具实现监督者模式。这样可以更细致地控制执行者接收和返回的上下文。该软件包也记录了由监督者管理其他监督者的用法。

如果一份研究简报包含多个独立问题，就可以考虑这种模式：分别调查产品能力、检查技术依赖、从不同来源集合收集证据。每个执行者都能完成有意义的任务，主导智能体则对汇总后的答案负责。

它的瓶颈在于整合。 如果每个执行者都需要其他执行者的最新发现，监督者就成了传话者。证据缺失时，监督者也无法靠一段语气笃定的综合结论来弥补。

层级团队：通过管理者分派任务

CrewAI 是协调不同角色智能体的框架，以智能体、任务和执行流程来组织团队。其层级流程使用 Process.hierarchical，并搭配 manager_llm 或 manager_agent。管理者负责分派工作、审查输出，并判断任务是否完成。

层级结构可以扩展为管理者统筹多个团队，但一个 CrewAI 层级团队本身并不意味着存在多层嵌套的组织。CrewAI 也支持 Process.sequential，让任务按预定顺序执行。这些是不同的执行方式，并不是可以互换的“协作”叫法。

以产品评估为例，其中可能同时有研究和实施两条工作线。如果每条工作线已经具备清晰一致的职责，且能交付稳定的成果，采用层级结构就有道理。如果整个任务只需一个简短回答，而管理者主要是在相互复述指令，这种结构就很难成立。

它的瓶颈在于管理开销。 每增加一层，都需要重新理解任务并汇报结果。增加管理层，应当因为工作本身存在团队边界，而不是因为人类公司设有部门。

交接模式：让专门角色接管对话

OpenAI Agents SDK 是用于运行智能体和工具的代码库，其交接机制会将控制权转移给另一个智能体。handoffs 配置列出当前智能体可以委派到的目标。接收任务的专门角色负责下一次回复。这与使用 as_tool() 调用专门角色不同，后者仍由管理者对答案负责。OpenAI 的编排文档明确说明了这一差别。

客服对话能清楚说明这种区别。如果账单专员需要继续追问并解决发票问题，把对话交给它是合理的。如果主助手只是需要先算一笔账，再回答范围更广的问题，那么一个工具或一次边界明确的专门角色调用，可能就够了。

它的瓶颈在于交接边界。 接手的智能体需要拿到相关事实、未解决的问题和必要权限。发生交接，并不自动证明之前的工作都正确，也不代表专门角色有权执行所有操作。访问控制和审批规则必须由应用代码落实。

需要转移责任时，再使用交接。如果只是为了让每个环节都换一种人设，只会增加上下文丢失的机会。

群聊模式：通过共享对话协作

Microsoft Agent Framework 是构建智能体应用和工作流的框架，其群聊模式由编排者选择下一个发言者。Python 中的 GroupChatBuilder 支持选择函数或基于智能体的编排者，并支持终止条件。参与者各自拥有独立会话，会话历史会同步。Microsoft 的群聊文档介绍了具体机制。

这种模式适合需要通过互动来完善的提案：审查者指出缺失的要求，写作者据此修改草稿，再由另一个专门角色检查修改后的论证。与独立研究分支不同，这里的后续轮次本来就需要依赖前面的贡献。

它的瓶颈在于不断膨胀的对话。 参与者可能把轮次花在讨论工作上，却没有实际修改产物。共享讨论还会让各个执行者受到同一个错误前提的影响。在这段对话里达成一致，并不等于完成了独立核验。

给群聊指定一个需要改进的产物、明确的验收条件，以及停止规则。如果任务本来就有清晰的固定顺序，简单工作流通常更容易理解。

AI 智能体框架对比讨论了更广泛的实现选择。确认值得拆分后，可以继续阅读 AI 智能体编排，了解协调、状态、审批和运行控制。

多智能体协作案例：哪些任务值得拆分？

相比紧密耦合的编辑任务，多方向研究更适合作为起点。 Anthropic 公开介绍的 Research 系统，由一个主导智能体协调并行执行者，后者分别调查不同方向，再返回发现。在其公布的内部评估中，由 Claude Opus 4 主导、Claude Sonnet 4 子智能体参与的系统，表现比单智能体 Claude Opus 4 高出 90.2%。这是该研究评估中报告的相对提升，并非 90.2% 的成功率，也不是增加智能体就能普遍获得的收益。这项比较还同时改变了模型组合和计算资源安排。Anthropic 的工程介绍。

对于正在评估集成方案的开发者，类似做法是让执行者分别研究每个候选方案的文档，并按同一组要求返回证据。最终仍需要有人处理相互冲突的说法和缺失的信息。并行研究可以扩充可用证据，却不能让互不相容的证据自动一致。

编码任务的依赖关系则不同。独立执行者可以分别检查身份验证代码、寻找相关测试、研究某个库在文档中说明的行为。这些都是边界明确的调查。但如果让多个执行者同时重写同一套身份验证流程，协调就会困难得多，因为它们各自的决策可能让其他人的工作失效。

客服场景体现了另一种拆分理由：责任归属。通用助手识别问题，再由专门角色处理独立领域。收益来自专门角色更聚焦的指令和工具，而不是把对话拉长。

以上编码和客服场景是设计示例，并非已报告的部署案例或量化改进。它们是否有用，取决于新增执行者的工作，是否确实比让原智能体配合更好的工具或范围更明确的提示词来做更清晰。

多智能体 LLM 系统为什么会失败？

即使每个执行者单独看都很能干，系统仍可能在交接处失败。 智能体越多，要解读的任务就越多，要信任的中间结果也越多，原始要求在传递中偏离原意的机会随之增加。

Token 开销增加，依赖环节仍要等待

委派任务会增加指令、执行者上下文、返回结果和汇总工作。反复尝试与共享会话历史还会带来额外消耗。Anthropic 报告，在其自身数据中，多智能体系统的 token 用量约为普通聊天的 15×。这里的基准是聊天，而不是单智能体运行；不能把它当成通用的预算倍数。Anthropic 报告的 token 用量。

Token 开销是需要测量的风险，并不意味着所有多智能体结构都必然消耗更多 token。独立上下文可能避免反复加载无关材料。真正该看的是，得到一个通过验收的结果，总共消耗了多少，包括失败分支和返工。

只有任务彼此独立，并行执行者才能缩短总耗时。如果研究完成后规划者才能行动，规划完成后编码者才能开工，那仍是一条依赖链。给这些步骤换上不同的角色名称，并不会让它们变成并发执行。

调试更难定位源头

最终答案可能掩盖最早出现的错误决策。编码者可能准确实现了一条错误需求，审查者又依据同一条错误需求通过了这份实现。如果只看最后的回复，就会找错问题所在。

Anthropic 报告，完整的执行追踪有助于区分其研究系统中的搜索失败、来源选择失败和工具失败。它也描述了错误如何在有状态的智能体运行过程中不断叠加。相关工程经验。

比较不同设计时，应当问：能否找出最早偏离任务的那一步？执行者接到了什么指令，收到了哪些证据，返回了什么，下一个执行者又把什么当成了既定事实？如果无法检查这些交接边界，就无法判断新增审查者究竟改善了系统，还是只多写了一段让人安心的最终回复。

错误沿着交接链不断累积

设想研究者写道：“这个端点似乎支持导出，但权限要求还不明确。” 规划者将其压缩为“使用导出端点”，编码者按计划实现，审查者再将补丁与计划对照，认为没有出入。

最初的不确定性就这样消失了，却没有任何人真正解决它。参与的智能体更多了，但缺失的证据始终无人核查。

返回摘要时，也应附上来源引用、明确列出的未知项，以及实际产物。让审查者拿到原始要求，而不只是产出者对要求的转述。这些做法也说明，相比一长串职责含糊的角色，规模小、过程可检查的团队更值得优先考虑。

智能体团队的哪些能力被高估了？

角色数量并不能有效衡量能力。 更多智能体，不会自动带来更多知识、更独立的判断或更快的执行。真正要问的是：拆分之后，新增了什么原本做不到的工作？

单个智能体也可以并行使用工具，所以仅仅要同时进行多次搜索，并不需要组建团队。它也可以按需加载专门指令。LangChain 记录了一种技能模式，由同一个智能体保持控制权，同时按需引入相关知识。

也不要把提示词分开，误认为已经实现了安全隔离。把一个智能体叫作研究者、另一个叫作审批者，本身不会限制它们的访问权限。预期的工具权限和审批边界，必须由应用落实。

支持多智能体的有力理由通常很具体：这个执行者需要独立上下文，可以独立调查一个问题，或者应当负责不同的对话领域。“它看起来像一个团队”，还远远不够。

下一步怎么做？从最小的有效拆分开始比较

保留单智能体基线，只针对已经看见的问题增加执行者。 如果现有系统已经能够完成任务，再加入管理者和审查者，就等于引入了一个需要重新证明价值的新系统。

1. 1

   明确现有工作流的问题

   选择真实任务，找出智能体遗漏证据、选错工具、丢失要求或产出不合格结果的情况。先补齐缺失工具、澄清含糊指令，再判断问题是否出在智能体数量上。

2. 2

   设计边界明确的对照方案

   对于编码助手，仍让主智能体对补丁负责，只有在审查确实是短板时才增加独立审查者。明确审查者的输入，以及它必须返回的证据。避免一次改动整个工作流。

3. 3

   比较通过验收的结果

   让基线方案和对照方案处理同一组任务，使用相同的验收标准。记录完成质量、token 总用量、总耗时，以及诊断或修复失败所需的人工投入。解读结果时，要把模型差异考虑进去。

4. 4

   决定保留还是撤销拆分

   如果执行者带来的结果改善足以抵消运行负担，就保留它。如果它主要是在重复上下文，或复述另一个智能体的工作，就把这项活动收回原智能体。尚未测出能力缺口的运营者可以先等等；拥有独立研究分支的开发者，则更有理由现在就试验。

多智能体系统常见问题

ChatGPT 是多智能体系统吗？

仅凭 ChatGPT 这个名称，无法判断某个具体工作流的架构。要认定一个功能属于多智能体，需要找到文档证据，确认存在相互交换工作成果或转移控制权的独立智能体。聊天界面、工具使用或长篇回答，都不足以证明这一点。

多智能体系统有哪些例子？

Anthropic 的 Research 系统将调查任务委派给执行者，再汇总它们的发现，是编排者—执行者模式的一个例子。

哪个多智能体系统最好？

没有适合所有场景的最佳选择。应让模式匹配任务：边界明确的专门工作可以交给监督者模式；对话责任需要转移时采用交接；反复评议确实有助于改进时采用群聊。如果拆分不能改善结果，就保留单智能体。

AI 智能体的 4 大角色是什么？

行业并没有一份公认的“4 大角色”标准名单。规划者、研究者、编码者和审查者，是智能体团队方案中常见的角色标签，并非必备组件。先定义每个角色的工作，再决定是否将其做成独立智能体。

ChatGPT 是智能体，还是 LLM？

ChatGPT 是应用名称，LLM 是底层模型的类别。智能体则描述一种利用模型选择行动、并根据结果作出响应的系统。这些概念属于不同层次，因此应检查具体功能，而不要把名称当成可以互换的标签。

AI 智能体有哪 7 种类型？

列出七种类型的文章往往混合了不同分类维度，例如决策规则、学习行为、任务角色或协作模式。并不存在一套必须实现的固定七部分架构。就本文的选择而言，应区分单个智能体的行为，以及多个智能体之间的组织方式。

常见的 AI 智能体有哪些？

有实用价值的业务分类包括客服助手、研究智能体和编码智能体。这些是任务类别，并非经过核实的热门程度排名。仅凭名称，无法判断它们是独立运行、受监督者管理，还是通过交接协作。

能举几个 AI 智能体的例子吗？

例如，查询订单并选择下一步操作的客服智能体，搜索并核验来源的研究智能体，以及编辑文件并运行测试的编码智能体。即使执行了很多步骤，它们也都可以是单个智能体。

AI 智能体的 5 种经典类型是什么？

IBM 介绍的经典分类包括简单反射型、基于模型的反射型、目标驱动型、效用驱动型和学习型智能体。它划分的是智能体如何决策或学习，并没有规定应用应使用多少个 LLM 执行者。

想了解用 AI 构建产品时的实用决策方法，可以订阅简报。