多智能体编排原语
定义
多智能体编排原语 是指在 Agent 系统中反复出现、可独立组合的基础工作流模式，用来组织任务拆分、分发、执行、汇总与校验。
在本文语境里，它不是某个单独产品，也不是某种固定架构图，而是一组比“team / swarm / crew”更底层、更实用的组织方式。作者的核心判断是：生产级多 Agent 系统真正稳定复用的，通常就是几种朴素原语，而不是更花哨的命名。
在本文档中的语境
这组原语被放在 Sub-Agent 与 Agent Team 的讨论之后提出，作用是给多智能体选型“降温”：
- 多 Agent 不应先从“拆几个角色”开始想，而应先从任务的上下文边界、依赖关系和协作方式开始想。
- 真正该问的问题不是“要不要搞一个 team”，而是“这个任务需要顺序串联、路由、并行、调度-执行，还是评估-优化”。
- 因此，多 Agent 不是单一产品形态，而是一组可组合的工作流原语。
作者明确反对把多 Agent 理解成一种看起来更高级的组织外观。若任务结构并不需要复杂协作，强行套上 team、crew、swarm 之类名称，只会掩盖任务建模没有完成的问题。
五种核心原语
1. Prompt Chaining（顺序串联）
Prompt Chaining 指把任务拆成线性的多个阶段，由前一步输出驱动后一步输入，即“A 做完给 B，B 做完给 C”。
它适合步骤明确、前后依赖稳定、每一步目标单一的任务。文中给出的典型场景是：
- 先抽取
- 再翻译
- 再润色
这类任务的特点是：后一步不需要与前一步持续协商，只需要接收已经整理好的结果继续处理。因此它更像流水线，而不是协作团队。
其优点是结构简单、可解释性强、调试容易；边界也很清楚：如果后续步骤需要频繁回看前序中间状态、不断反向修改前面的判断，那么单纯顺序串联就会变得脆弱，可能需要升级为更复杂的编排方式。
2. Routing（路由）
Routing 指系统先判断任务特征，再把任务分发给最合适的 Agent、技能或处理路径。
文中的典型场景是“先识别意图再分流”。这类场景下，关键不在于多个 Agent 同时协作，而在于入口处能否把任务送到正确分支。
在上文关于 Sub-Agent 的例子中，路由还有一个非常具体的实现细节：子代理定义里的 description 字段并不只是注释，而是路由信号。父代理如何决定把任务派给哪个 Sub-Agent，很大程度上依赖这段描述是否写得边界清楚、职责明确。描述含糊，路由就含糊；描述清楚，分发才清楚。
因此，Routing 的工程重点不是“多建几个 Agent”，而是把分流依据写清楚，包括：
- 这个分支处理什么问题；
- 不处理什么问题；
- 输入特征是什么；
- 何时应交给其他分支。
3. Parallelization（并行）
Parallelization 指把彼此互不依赖的子任务同时执行，最后再集中汇总结果。
文中的典型场景包括：
- 代码审查的多维分析；
- 文档的多维度分析。
例如同一段代码可以同时让不同执行单元分别检查安全、性能、测试覆盖率等维度；它们之间不需要互相通信，因此可以并发运行，完成后再由上层统一汇总。
并行模式的前提是子任务之间“互不影响”。如果一个子任务的发现会立刻改变另一个子任务下一步该怎么做，那它们就不再适合纯并行。
文中也借此强调了 Sub-Agent 的价值：子代理之间不能直接通信、不能继续生成新 Agent、所有流量都要经过父级，而且只返回结论不返回中间思考。正因为这些约束存在，子任务才更容易被安全地并行化。这也是作者所说的 Sub-Agent 主要解决“隔离 + 压缩 + 并行”的含义。
4. Orchestrator-Worker（调度-执行）
Orchestrator-Worker 指一个上层调度者负责拆解任务、分配任务、回收结果，多个执行者各自处理分到的工作。
文中的典型表述是“父代理派工与收结果，高度符合 Sub-Agent 的运行方式”。作者甚至直接指出：这个模式其实就是 Sub-Agent 的标准形态。
也就是说，在本文语境里，Sub-Agent 不是一种与原语并列的神秘结构，而是 Orchestrator-Worker 的常见、标准化实现：
- orchestrator 负责理解总任务；
- orchestrator 按边界拆出子任务；
- workers 在各自独立上下文中完成工作；
- workers 返回的是结论，而不是完整推理过程；
- orchestrator 再把多个结果组合为最终输出。
这种模式适用于子任务定义相对清楚、彼此不要求共享持续状态的场景。它的优势是可控、易隔离、便于压缩上下文；边界则在于：当执行者之间必须看到彼此的中间进展，或者必须直接对话和同步状态时，单纯的调度-执行就不够了，这时更接近 Agent Team 的问题。
5. Evaluator-Optimizer（评估-优化）
Evaluator-Optimizer 指先生成候选结果，再由评估环节检查质量、发现问题、提出修正意见，然后继续迭代优化。
文中的典型场景是高质量生成后的自检迭代，例如：
- 生成式报告先产出初稿，再评估再打磨；
- 代码补全先给出结果，再进行自检和修正。
这类模式特别适合对质量要求高、允许多轮改进的任务。它不是把工作横向拆给不同角色，而是把同一产物放进“生成—检查—修正”的循环里。
它的价值在于提升最终质量，但代价是延迟、成本和控制逻辑都会增加。因此只有在“高质量产出”明显重要于“一次出结果”的任务中，这种模式才特别划算。
与 Sub-Agent、Agent Team 的关系
本文的一个关键观点是：Sub-Agent 与 Agent Team 不应被理解为两种彼此对立、必须二选一的宏大范式，而应被放回更基础的编排原语中理解。
其中关系最明确的一点是：
- Sub-Agent 被作者视为 Orchestrator-Worker（调度-执行）模式的标准形态。
这意味着很多所谓“多 Agent 设计”，本质上只是一个父代理把任务分给若干子代理执行，再回收结论。它解决的不是持续协作，而是清晰拆分、上下文隔离、结果压缩和并行执行。
相比之下，Agent Team 处理的是另一类问题：多个执行单元共享上下文、直接沟通、持续同步状态、互相影响后续动作。它更适合“做着做着会发现问题，并且需要即时互相调头”的任务，而不是一般性的任务拆分。
因此，这篇材料实际上把“原语”和“结构”区分开了：
- 原语描述的是工作流模式；
- Sub-Agent、Agent Team 描述的是更高层的协作结构；
- 选型时应先判断任务需要什么原语，再判断是否需要更重的协作结构。