范叶亮写智能体、模型和数据系统时，习惯先把定义和边界钉死。把「多智能体系统」整理成可落地的中文笔记：问题在哪、默认做法会踩什么坑、该怎么选。原站导航和广告已去掉。
单智能体
在单智能体中，ReAct 框架 1 作为当前智能体的一个核心设计模式，其通过 Reasoning（推理）和 Acting（行动）两个模块实现了大语言模型推理能力与外部环境交互能力的深度协同。ReAct 框架的整体执行过程如下图所示：
当模型判断已获得最终答案后，会停止循环迭代并将结果输出给用户。除此之外也会存在异常输出的情况，例如：循环迭代达到最大限制次数，工具调用超时或返回错误等等。
初始化
我们以 Hotpot QA 数据集中的一个问题为例，对比其他方法展示 ReAct 框架是如何解决问题的。
当单智能体配置的工具过多导致难以正确决策，或任务需要庞大的专业领域知识，抑或需要施加特定的顺序约束时，单智能体往往力不从心，此时多智能体架构成为更优的选择 2 。归纳来看，引入多智能体主要是为了获得以下三方面能力：
循环迭代
多智能体并非银弹。Anthropic 的研究 3 表明，以 Claude Opus 4 作为主智能体、Claude Sonnet 4 作为子智能体的多智能体系统，在其内部研究类评测中比单体 Claude Opus 4 高出 90.2% ，关键在于多个子智能体各自拥有独立的上下文窗口，从而实现了单智能体难以企及的并行推理。但同时也应注意，单智能体更易于构建、推理和调试，应当优先从单智能体加良好的提示词与工具设计开始，只有在确实触及瓶颈时再引入多智能体。
根据 LangGraph v0.x 版本文档（已过时） 4 ，其将多智能体模型划分为： 网络模式（Network） 、 监督模式（Supervisor） 、 工具化监督模式（Supervisor as Tools） 、 层级模式（Hierarchical） 和 自定义模式（Custom Workflow） 。
终止输出
整体而言，没有最好的模式只有最适合的模式。在搭建多智能体系统时，需要根据实际的业务场景选择最合适的多智能体模式。
根据 LangChain v1.x 版本文档 5 ，其将多智能体模型划分为： 子智能体模式（Subagents） 、 传递模式（Handoffs） 、 技能模式（Skills） 、 路由模式（Router） 和 自定义模式（Custom Workflow） 。
多智能体
类似上文中的监督模式。主智能体以工具方式调用子智能体对其进行协调，主智能体决定调用哪个子智能体、提供什么输入以及如何组合结果。子智能体是无状态的，所有记忆由主智能体维护。该模式的主要特点如下：
当存在多个独立的场景（例如：日程、电子邮件、数据库等）时，子智能体无须同用户直接交互或者你希望通过统一流程进行控制，适合使用该模式。
LangGraph 定义
该模式下专业能力被打包成可调用的“技能”（Skill），用于增强智能体的行为能力。技能由专业化的提示词构成，智能体可以按需调用。该模式的主要特点如下：
当你希望单个智能体具有多种专业化，无须在技能之间施加强制约束，或者不同团队需要独立开发能力时，适合使用该模式。
值得单独记下的点
- 推理 ：用于分析任务目标，根据历史反馈和当前状态确定下一步动作。
- 行动 ：将模型推理的结果转化为可执行的工具指令（Tool Calling 或 Function Calling）。
- 观测 ：将工具执行结果返回给 LLM 用于确定下一步动作。
- 上下文管理（Context Management） ：单一提示词难以容纳所有能力所需的专业知识，需要按需将相关信息呈现给模型，避免上下文窗口被无关内容占满。
- 分布式开发（Distributed Development） ：不同团队可以在清晰的边界内独立开发和维护各自的能力，再将其组合成更大的系统，而非维护一个庞大且难以协作的单体提示词。
- 并行化（Parallelization） ：为不同子任务派发专门的智能体并发执行，从而获得更快的响应。
- 无用户直接交互：子智能体将结果返回给主智能体而非用户。
- 并行执行：主智能体可以在单轮对话中调用多个子智能体。
落地时建议先做的 5 件事
- 先写清任务能不能被自动验证：能验证的交给系统和评测，不能验证的留给人审。
- 本地部署先算显存、延迟和失败回滚，不要只看能跑通一次。
- 多智能体只在单智能体触到上下文或专业边界时再拆。
- Token、微调和压缩都要有对照数字，避免口号式优化。
- 结论写成可检查清单：接口、超时、评测集、回滚版本。
和智能体产品怎么接
龙虾PRO做 OpenClaw 落地时，最该拿走的是「单智能体先做好工具和提示，再谈编排」。数字员工、技能市场和网关应共用同一套评测与权限，而不是各写一套角色人设。
本文侧重智能体生命周期与技能边界。若你要动手验证，优先用 Playground 做小任务压测；权限与托管再单独规划，避免「先装一堆再治理」。 相关：Playground · 创建智能体 · 学习中心
常见问题 FAQ
引入多智能体架构，主要为了获得哪三方面能力？
说白了，当单个智能体忙不过来时，我们就需要“团队协作”。引入多智能体主要是为了获得三种核心能力：一是让不同子任务能同时并行处理，大幅提升效率；二是允许不同团队独立开发和维护各自的专业技能，再整合起来；三是实现更精细的上下文管理，避免把所有信息都塞进一个提示词里导致模型“迷糊”。
什么时候单个智能体就不够用了，需要考虑拆分成多智能体？
根据文章，当你发现单个智能体配置了太多工具，导致它决策困难；或者任务本身需要非常庞大的专业领域知识，一个智能体难以掌握；再或者任务流程有严格的先后顺序约束，单智能体处理起来力不从心时，这就是引入多智能体架构的典型信号。
LangGraph 定义中，什么是“监督模式”的多智能体系统？
监督模式就像一个项目经理带着一群专家。主智能体充当协调者，决定把任务分派给哪个“专家”子智能体，以及如何整合他们的结果。子智能体本身是无状态的，所有记忆和上下文都由主智能体统一维护。这种模式适合那些需要统一流程控制、且子智能体无需直接面对用户的场景。
文章建议，在搭建多智能体系统前，首先应该做好哪件事？
作者在“落地时建议先做的5件事”里，第一条就是：先写清楚你的任务能不能被自动验证。这意味着你要区分好，哪些部分可以交给系统和自动化评测来检查，哪些部分必须留给人类审核。这是确保系统可靠性和后期可维护性的基础，比一上来就搞复杂编排更重要。
采用多智能体架构，具体能带来什么性能提升？
文章引用了 的一项研究作为例子。他们使用主智能体（ Opus）搭配子智能体（ Sonnet）的多智能体系统，在内部研究类评测中，性能比单独使用强大的 Opus 高出了 90.2%。关键就在于多个子智能体拥有独立的上下文窗口，实现了单体模型难以达到的并行推理能力。
在考虑采用多智能体之前，应该优先把什么做好？
文章的核心建议之一，也是龙虾PRO在OpenClaw落地时强调的一点：必须先在单智能体层面，把工具设计和提示工程做到位。单智能体更容易构建、推理和调试。应该优先用良好的单智能体方案去尝试解决问题，只有在确实碰到了能力或上下文瓶颈时，才考虑拆分成多智能体架构。