多智能体编排模式（考点 1.2）· CCAF 备考

本页目录5

这个考点是什么

多智能体编排（multi-agent orchestration）考的是：当一个任务复杂到单个 LLM 调用难以胜任时，如何在多个 LLM 调用/agent 之间分配工作，以及分配之后如何把结果收回来。

这个考点建立在 Anthropic「Building Effective Agents」给出的五种 workflow 分类基础上——prompt chaining（固定顺序流水线）、routing（分类后分发到单一路径）、parallelization/sectioning（预先切分好的独立子任务并发执行）、orchestrator-workers（中心 LLM 在运行时动态分解任务、委派给 worker、再综合结果）、evaluator-optimizer（生成者与评估者之间的反馈迭代循环）。

备考重点集中在 orchestrator-workers 这一条轴上，因为它和 parallelization「拓扑上相似」却语义不同，最容易混淆。

另一半内容来自 Anthropic 多智能体研究系统的实践文章：一个协调者（lead/coordinator）动态判断要不要拆、拆给谁、拆多细，子智能体在各自独立的上下文窗口里工作，只把提炼过的结论返回给协调者。

这里考的不是「有没有用多个 agent」，而是编排质量本身——任务粒度是否与查询复杂度匹配、协调者本该自己做的工作有没有被不必要地甩给子智能体、以及跨 agent 传递的上下文是否会在多次转手中衰减。

最后一层是「值不值得引入多智能体」的判断题：多智能体架构会显著推高 token 消耗，只对能拆成独立并行方向、且信息量或工具复杂度超出单一上下文能力的高价值任务划算；对需要紧密共享上下文、agent 间强依赖的任务（官方点名 coding 是典型反例），目前反而是最差契合场景。

为什么考

出题角度集中在两类：

一类是「给一段场景描述，反推它属于五种 workflow 中的哪一种」，干扰项通常是把 orchestrator-workers 和 parallelization/sectioning 放在一起比，或者把 prompt chaining 和确实存在数据依赖的多步流水线区分开；
判分点往往落在一个词上——子任务是「预先定义」还是「运行时决定」。

另一类是场景应用题，考编排系统本身的工程判断：协调者要不要对每个查询都跑满全部子智能体、follow-up 请求要不要重新 spawn 子智能体去处理协调者自己已持有的数据。这类题的正确项往往不是「用不用多智能体」，而是「编排动作是否与任务复杂度、上下文所有权相匹配」。

此外还会考「什么场景最不适合多智能体」的反向判断，以及 evaluator-optimizer 与 orchestrator-workers 的角色边界（前者是同一任务反复打磨，后者是任务被拆开各自完成）。

核心辨析

1
orchestrator-workers 与 parallelization/sectioning 的边界只有一条：子任务是否在执行前就能预先定义好。能预先枚举、各子任务互相独立、直接并发跑，是 parallelization；子任务的数量和内容要等中心 LLM 在运行时分析完任务才能确定，是 orchestrator-workers。

官方原文称二者「拓扑上相似」，考题常用这条线索本身作为题干直接送分，鉴别力低，但仍是最容易被想当然合并的一对概念。
2
orchestrator-workers 与 prompt chaining 的边界在于有没有「决策式分解+综合」。chaining 是开发者预先写死的线性步骤序列，下一步消费上一步的确定性输出；orchestrator-workers 里由中心 LLM 决定要拆成几份、拆给谁、怎么整合。

如果几个步骤之间根本没有数据依赖（谁先跑谁后跑都不影响结果），即便看起来像「多步骤流程」，本质也是 parallelization 而非 chaining，不能只因为「有先后顺序」就贴 chaining 标签。
3
evaluator-optimizer 和 orchestrator-workers 都涉及两个以上角色，但目的不同：
- evaluator-optimizer 是同一份产出在生成者与评估者之间反复打磨（如翻译草稿+反馈迭代），没有任务拆分；
- orchestrator-workers 是把一个任务拆成互不相同的子任务分别完成后再合并，子任务之间通常内容不同、不是同一产出的多轮修订。
4
多智能体架构的最佳契合场景是「广度优先、可并行、独立方向」的查询，且信息量或工具复杂度超出单一上下文承载能力；最差契合场景是所有 agent 需要共享同一份持续演进的上下文、且 agent 间存在大量强依赖——官方明确点名 coding 类任务属于此类，因为当前 LLM agent 还不擅长实时协调与委派。判断一个场景该不该上多智能体，先看它是不是「可拆成互不干扰的并行分支」。
5
编排质量体现在细节动作上而非「用没用多智能体」
协调者应根据查询复杂度动态决定调用哪些/多少子智能体，而不是不论难易都跑满整条流水线；协调者若本就持有某份上下文（比如此前编排研究时积累的 findings），对同一份数据的后续总结应直接在协调者层面完成，不必为了「走一遍委派」而重新 spawn 子智能体并搬运全部 token——委派的价值在于隔离上下文或实现并行，单纯总结已有数据两者都不需要。

至于「发现子智能体只完成部分范围时具体该如何重新委派」这类更细的操作协议，站内题目考察的是对「委派应聚焦缺口、避免重复劳动」这一原则的场景化应用，不等于某条可逐字引用的官方规程，理解工程逻辑即可，不必去背裁判词。
6
跨 agent 传递结果时容易出现类似「game of telephone」的信息衰减和引用错位，例如引用来源在传递中和原始论断脱节。官方文章给出的应对是工程机制层面的：用文件系统/artifact 的方式传递产出以降低多次转手带来的衰减，并在最后阶段设置独立的引用校验角色，对照原始文档核实报告中的引用位置——而不是笼统地说「换一种输出格式就能解决」。

遇到这类「引用/来源丢失怎么修」的场景题，要分清楚选项描述的是官方点名的具体机制，还是命题者自行编造的操作细节，后者即便听起来合理也不能当作官方原文来记。

反模式对照

常见做法

只要题干出现「任务可以拆成几部分分别处理」就直接选 orchestrator-workers

正确做法

先确认子任务是执行前能预先枚举好的（parallelization/sectioning），还是必须由中心 LLM 在运行时临场判断才能确定（orchestrator-workers），再下结论

两者拓扑相似，唯一区分点是分解发生在设计期还是运行期，题目常把这条线索作为唯一判分依据。

常见做法

把几个步骤之间没有真实数据依赖、只是「顺序执行」的多步流程标注为 prompt chaining

正确做法

判断是否为 chaining 要核实下一步是否真的消费了上一步的输出；若各步骤独立无依赖，本质是 parallelization/sectioning

素材中的辨析记录明确指出，若三个环节互不消费彼此输出，按 Anthropic 分类应归入 parallelization，只是并行选项被写成有缺陷的措辞才让 chaining 显得「唯一正确」。

常见做法

对需要多个 agent 共享同一份持续演进上下文、且相互强依赖的任务（如多文件协同改动的 coding 场景）套用多智能体并行架构

正确做法

识别出「共享同一上下文+高度相互依赖」正是官方点名的当前最差契合场景，这类任务更适合单 agent 或有明确数据依赖的顺序流水线

官方原文直接以 coding 为例说明 LLM agent 尚不擅长实时协调与委派，把它当作多智能体的典型好场景是常见反向陷阱。

常见做法

协调者对每一个 follow-up 查询都重新 spawn 一个综合子智能体，并把此前积累的全部 findings 重新搬进其上下文

正确做法

若协调者自身已持有这些 findings，直接在协调者层面完成总结，不为不需要隔离或并行的工作走一次完整委派

委派的价值在于隔离上下文或实现并行，单纯对已有数据做总结既不需要隔离也不需要并行，委派只会增加一次上下文搬运的开销。

练这个考点

练习模式支持按考点专练（需 Google 登录，不占用正式考机会）。

专练考点 1.2

该考点的公开题（免登录，含完整解析）：