Claude 团队最近公开了他们内部高频使用的两种多智能体模式，Advisor 和 Orchestrator。这两个词听起来像是企业软件里的架构名词，但背后的数据挺有意思。

在 SWE-bench Pro 的 482 道题上，Sonnet 5 单独跑，准确率 75.5%，单次成本 0.75 美元。如果让 Sonnet 5 干活，但遇到困难时去咨询 Fable 5，准确率能提到 84%，成本 1.40 美元。Fable 5 单独跑更准，91.5%，但成本 2.25 美元。组合方案用大约 63% 的成本，拿到了接近 92% 的性能。

这不像是一次简单的模型升级，更像是一种新的成本与性能调度策略。

一、为什么多智能体突然变得这么重要

过去一年，AI 编程工具的竞争已经从「谁的模型更聪明」转到了「谁能用更低的成本稳定输出高质量代码」。Claude Code、Cursor、GitHub Copilot 这些产品的用户体验差距，很多时候并不取决于底层模型是不是最新，而是取决于系统能不能把不同能力层调度好。

我自己做 Agent 项目时也有过类似的感受。早期我们总想让最大的模型处理所有事情，因为省事， prompt 好写，错误也好定位。但项目一上量，成本就压不住了。一次复杂任务调用的上下文可能几十万个 token，如果每个步骤都上最强模型，账单数字会涨得比预期快得多。

多智能体不是为了让架构图更好看，而是为了解决一个现实问题，不同子任务的认知负荷不一样，不该用同一个模型全部包办。

二、Advisor 模式，小模型干活，大模型当顾问

Advisor 模式的核心逻辑很简单。让 Sonnet 5 这类性价比更高的模型作为执行者，负责实际写代码、改文件、跑测试。但当它遇到不确定的事情时，可以通过 tool call 调用 Fable 5 获取指导。

你可以把它想象成一个年轻工程师在写一个复杂模块，旁边坐着一个资深架构师。年轻工程师负责动手，架构师不直接写代码，只在关键决策点给出方向。比如「这个接口应该遵循现有的错误处理规范」「这个测试用例需要覆盖边界条件」或者「这个重构方案有风险，换一种方式」。

从数据上看，这个模式的效果非常明显。Sonnet 5 单独跑 75.5%，加顾问后跳到 84%。成本只增加了不到一倍。而 Fable 5 单独跑虽然能到 91.5%，但成本是前者的三倍。组合方案用 63% 的成本拿到了 92% 的性能，这个性价比曲线很陡峭。

我自己觉得这个模式最有价值的地方，不是成本节省，而是它把「推理能力」和「执行能力」分开了。在真实的工程流程里，真正需要深度推理的决策点其实不多，大量工作是模式匹配、文件操作、测试验证。把这些交给执行模型，只在关键节点请出顾问，是符合直觉的分配方式。

具体怎么判断该不该求助？Claude 团队的做法是把这个决策权交给执行模型自己。执行模型在每一步输出时，先做一个内部评估。如果它对自己的答案足够有信心，就直接执行；如果信心不足，就通过 tool call 向 Fable 5 发送一份摘要，包含当前文件状态、已经尝试过的方案、失败原因。Fable 5 返回一份简短建议，执行模型再决定怎么继续。这种方式比固定规则更灵活，因为不同任务的难度分布不一样。

但这个机制也有代价。每次咨询都会产生一次额外的模型调用，增加延迟。如果顾问回复得很长，上下文也会膨胀。所以实际落地时，通常会对顾问的回复长度做限制，比如要求只返回三行以内的建议。这样才可能在成本和质量之间取得平衡。

三、Orchestrator 模式，大模型当导演，小模型跑龙套

Orchestrator 模式则是反过来。让 Fable 5 作为编排者，负责理解整个任务、拆分子步骤、决定调用哪个工具或哪个小模型。具体的子任务执行交给更轻量的模型或专用工具。

如果说 Advisor 模式是「小老板带大顾问」，那 Orchestrator 模式就是「大导演指挥一群演员」。导演不演戏，但他决定每场戏怎么拍、谁上场、节奏怎么控制。演员们各司其职，只在自己的场景里表现。

这个模式在复杂任务里特别有用。比如一个需求涉及多个文件修改、测试、文档更新、lint 检查，强模型先做整体规划，然后把每个子任务派发给专用模型或工具。子任务完成后，编排者再汇总结果，决定下一步。

Claude 团队没有公开 Orchestrator 模式的具体数字，但从架构逻辑上看，它适合处理那种「步骤多、依赖复杂、需要全局视角」的任务。LangGraph 里常见的 StateGraph、条件边、并行节点，说到底都是在实现类似的编排能力。

我举个例子。假设你要在一个 Spring Boot 项目里新增一个 REST 接口，涉及控制器、服务层、数据访问层和测试用例。Orchestrator 模式会先让强模型理解需求，然后拆成四个子任务，设计 API 签名、实现业务逻辑、写数据库查询、补单元测试。每个子任务交给一个专门的执行模型或工具。强模型不直接写代码，而是持续检查各子任务的输出是否符合整体约束，比如参数命名一致性、异常处理是否统一、测试覆盖率是否达标。

这种分工和传统的流水线不太一样。传统流水线是固定的，每个阶段都有预定义的职责。Orchestrator 模式里的任务拆分是动态的，根据输入需求变化而变化。同样的需求描述，如果项目里没有测试框架，编排者可能会把写测试用例改成写手动验证步骤。

四、这两种模式到底怎么选

Advisor 和 Orchestrator 不是互斥的，它们解决的是不同层级的问题。

Advisor 模式关注的是「单个决策点的质量」。执行模型在每一步都可以选择是否求助，求助的粒度很细，适合代码生成、代码审查、单文件修改这种连续型任务。

Orchestrator 模式关注的是「任务级别的结构」。它更适合多步骤、多工具、多文件协作的场景，比如一次完整的 feature 开发、一次系统重构、一次跨服务的 bug 修复。

我在自己的项目里尝试过类似的做法。用 LangGraph 搭工作流时，通常会把「规划节点」和「执行节点」分开。规划节点用强模型，输出任务列表和依赖关系。执行节点用便宜模型，负责具体实现。最后用验证节点跑测试和 lint。这个结构和 Orchestrator 模式很像。

但 Advisor 模式的启发是，即使在执行节点内部，也可以再嵌套一层咨询机制。不是所有执行步骤都需要同等级别的思考。有些步骤可以硬写，有些步骤需要问一问。这个动态咨询的想法，比固定的工作流更灵活。

实际上，这两种模式可以叠加。一个复杂任务进来，先用 Orchestrator 做整体规划，把大任务拆成多个子任务。每个子任务在执行时，再用 Advisor 模式做局部决策。这样既能保证全局结构正确，又能在每个执行点获得高质量的局部判断。

我在 LangGraph 里尝试这种叠加结构时，发现状态管理变得复杂。每个子任务都有自己的状态，顾问调用又会引入新的中间状态。如果图的状态定义不够清晰，很容易出现状态丢失或循环依赖。所以我的建议是，先从单一模式开始，跑通了再考虑叠加。

五、成本与能力的平衡曲线

这次 Claude 团队公布的数据里，我最关注的是那张成本-性能曲线。Sonnet 5 单独跑 75.5% / 0.75 美元，Fable 5 单独跑 91.5% / 2.25 美元。Advisor 组合方案 84% / 1.40 美元，接近 92% 性能但成本只有 63%。

这说明在模型能力已经很强的情况下，系统设计的边际收益可能比单纯换模型更大。过去几年大家的直觉是「模型大了自然就好」，但现在的趋势是「把模型用得巧，比用更大的模型更重要」。

对于开发者来说，这代表一个转变。以前选型主要看模型排行榜，现在需要同时考虑

  • 我的任务里有多少步骤是真正需要深度推理的
  • 能不能把任务拆成「执行密集」和「决策密集」两部分
  • 是否值得引入 tool call 或咨询机制来动态调用强模型
  • 延迟和成本能不能接受

六、实践中的坑

多智能体听起来很美好，但落地时有不少细节会踩坑。

第一个问题是上下文传递。Advisor 模式里，执行模型向顾问模型求助时，需要把当前状态、已有尝试、错误信息都传过去。如果上下文压缩得不好，顾问给出的建议可能偏离实际。如果传得太完整，成本又上去了。

第二个问题是决策点的设计。什么时候该求助，什么时候不该求助，这个阈值不好定。太频繁，成本省不下来；太少，准确率上不去。可能需要根据任务类型动态调整，甚至让模型自己学习这个决策。

第三个问题是错误累积。Orchestrator 模式里，如果第一步的拆分就错了，后面所有子任务都会跟着跑偏。所以需要验证和回滚机制，不能一条道走到黑。

第四个问题是可观测性。多个模型之间互相调用，出问题时的调试难度比单模型高很多。每个 tool call 的输入输出、每个节点的状态变化、每次咨询的结果，都需要被记录下来。

第五个问题是延迟。多一次模型调用，就多一段等待时间。Advisor 模式如果每一步都咨询，用户体验可能明显下降。Orchestrator 模式如果拆得太细，子任务串行执行也会拖慢整体速度。所以生产环境里通常需要设置并行度上限，或者给整个流程加一个超时机制。

延迟和成本往往是一对矛盾。省钱通常意味着更多调用，更多调用意味着更慢。设计多智能体系统时，不能只盯着账单，也要看用户能不能接受响应时间。

七、这和 LangGraph 有什么关系

很多做 Agent 的开发者会拿 LangGraph 和 Claude 的这两种模式做比较。我的看法是，它们不是竞争关系，而是互补的。

LangGraph 提供的是一个状态机和图结构的执行框架，你可以在里面定义节点、边、条件分支、并行路径。Advisor 和 Orchestrator 更像是高层设计模式，告诉你节点内部和节点之间应该怎么分配模型能力。

在 LangGraph 里实现 Advisor 模式，可以在执行节点里加一个 tool call 边，当执行模型 confidence 不够时，路由到顾问节点。实现 Orchestrator 模式，则可以有一个专门的规划节点作为入口，然后分发到各个执行节点。

在 LangGraph 里实现这两种模式，核心是要用好 state 和 tools。state 保存全局任务状态，tools 定义模型可以调用的能力。Advisor 模式可以封装成一个 consult tool，执行节点在需要时调用它。Orchestrator 模式可以封装成一个 plan tool，由入口节点调用。

另外，LangGraph 的 interrupt 和 checkpoint 机制对多智能体系统特别有用。当编排者拆分任务后，可以为每个子任务设置 checkpoint。如果某个子任务失败，可以回滚到上一个 checkpoint 重新尝试，而不需要从头开始。这种可恢复性在生产环境里很重要。

对于熟悉 Java 和 Spring 的开发者来说，这有点像微服务架构里的「服务编排」和「服务咨询」。编排是顶层流程控制，咨询是局部专家支持。两者结合，才能搭出既灵活又经济的系统。

八、我的判断

Claude 团队这次公开这两个模式，不只是分享技术细节，更像是在传递一个信号，前沿 AI 应用的竞争重点，正在从模型能力转向系统能力。

过去半年，我们看到 OpenAI 在推 Agent 框架，Google 在推 Gemini 的 Managed Agents，Anthropic 在推 Claude Code 的模型与努力级别设置。这些产品的共同方向是，让模型在正确的场景做正确的事，而不是一味追求模型本身的规模。

对于普通开发者来说，这个趋势是好消息。它意味着你不需要一直追最新最强的模型，也能做出好用的 Agent。关键是理解任务结构，设计好模型之间的协作关系。

Advisor 和 Orchestrator 不是银弹。它们有适用边界，也有实现成本。但它们代表了一种更成熟的 Agent 设计思路，把模型当团队用，而不是当超人用。

九、给普通开发者的落地建议

如果你还没在项目上引入多智能体，我的建议是从 Advisor 模式开始。它的改动最小，只需要在执行节点里加一个咨询工具。你可以先定义几个高频的低信心场景，比如复杂正则表达式、跨文件重构、不熟悉的 API 调用。当执行模型遇到这些场景时，再请求更强的模型介入。

不要一开始就追求完美的成本优化。先让系统能稳定运行，再逐步收紧咨询阈值。同时一定要做好日志记录，把每次咨询的原因、输入、输出都保存下来。过一段时间后，你就能分析出哪些咨询是有效的，哪些是可以省掉的。

Orchestrator 模式更适合已经有明确工作流的项目。如果你的项目经常需要处理多文件、多步骤的任务，而且错误率居高不下，可以考虑引入一个规划节点。规划节点不需要做所有决策，它只需要把任务拆成合理的子任务，并定义好依赖关系。剩下的执行工作仍然可以交给现有的工具或模型。

最重要的是，不要为了用多智能体而拆分。拆分的标准是认知负荷是否不均匀。如果每个子任务都需要同样的深度思考，那拆分后反而增加复杂度。只有当强弱模型的能力差异能被清晰利用时，拆分才有意义。

十、结语

回到开头那组数据。Sonnet 5 加 Fable 5 顾问，用 63% 的成本拿到 92% 的性能。这个比例不是偶然的，它说明多智能体协作已经到了可以实际产生经济效益的阶段。

我接下来会在自己的项目里尝试把 Advisor 模式嵌到现有的 LangGraph 工作流里，看看在真实业务场景中能不能复现类似的效果。如果有进展，再和大家分享踩过的坑。

如果你也在做 Agent 项目，不妨先问自己一个问题，你的任务里，有多少步骤是必须让最强模型来做的？把这个比例降下来，可能就是成本和质量同时优化的起点。