Anthropic 解法：Agent 并行编排

Agent 系统达到一定复杂度后，通常会遇到一个现实瓶颈：任务数量过多、信息过于繁杂，单个 Agent 根本无法有效处理。

很多时候，问题并非模型本身不够智能，而是其上下文窗口、执行链路和注意力机制都存在明确的上限。如果强行将所有材料、步骤和判断都集中到同一个 Agent 中，短期看似省事，但从长期来看，上下文超限、输出质量下降、执行时间延长等问题大概率会接连出现。

因此，并行编排并非为了追求架构的复杂性，而是为了解决一个非常朴素的问题：当一个 Agent 无法承担全部工作时，如何将任务拆解、并行执行，再汇总结果。

把工作分出去，而不是堆在一起

解决问题的思路其实非常直接：拆解。

一个任务如果能够分解成若干个相对独立的子任务，就没有必要让同一个 Agent 串行处理。更合理的做法是将每个子任务分配给专属的子 Agent，让它们并行推进，再由一个主控 Agent 负责调度、校验和汇总。

Anthropic 将这种模式称为「多智能体编排」，即 Multiagent Orchestration。其整体结构大致如下：

┌─────────────────────────────────────┐
│          主控 Agent                  │
│  接收任务，分解，分配，汇总结果      │
└──────┬──────────┬──────────┬────────┘
       │          │          │
       ▼          ▼          ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 子 Agent │ │ 子 Agent │ │ 子 Agent │
│ 子任务A  │ │ 子任务B  │ │ 子任务C  │
│ 独立执行 │ │ 独立执行 │ │ 独立执行 │
└──────────┘ └──────────┘ └──────────┘
       │          │          │
       └──────────┴──────────┘
               │
               ▼
        ┌──────────────────┐
        │   汇总 / 输出     │
        └──────────────────┘

这个结构的关键并不仅仅是多开启了几个 Agent，而是先明确职责边界。每个子 Agent 只需要处理自己负责的信息，无需理解全局背景；主控 Agent 不深入所有细节，但保持对目标、进度、质量和依赖关系的控制。

主控和子 Agent 各自做什么

主控 Agent 的职责主要包括三件事：分解任务、分配工作、整合结果。它需要理解全局目标，并判断哪些任务可以并行，哪些任务必须等待前置结果。

子 Agent 的职责则更窄——只需把分配给自己的那块任务做好。例如，一个子 Agent 负责读取代码，一个子 Agent 负责查阅文档，一个子 Agent 负责运行验证，一个子 Agent 负责反向审查。它们不需要知道整个系统的最终交付方式，只要清晰处理自己的输入、输出和边界即可。

这种分工带来的一项关键收益是：子 Agent 的上下文只包含自己的任务材料，不会被其他子任务的信息污染。任务越复杂，这一收益越明显。因为复杂任务中真正拖垮质量的，往往不是某个步骤太难，而是无关信息过多，导致注意力被反复稀释。

但这里有一个边界需要警惕：主控不能仅仅会分派任务，还必须能准确判断子任务之间的依赖关系。如果两个子任务实际上有强依赖，却硬拆成并行执行，结果就是重复劳动、结果冲突，甚至出现子 Agent 各自正确、但合并后完全不成立的情况。

模型选型不能只看强弱

并行编排中有一个容易被忽视的优化点：模型选型。

许多人习惯全链路使用同一个最强模型，这种做法虽然简单，但未必划算。主控 Agent 需要全局判断、任务拆分和结果取舍，通常更依赖推理和规划能力；而子 Agent 若只是执行明确的小任务，不一定每个都需要最强模型。

Anthropic 案例中有一个典型例子：Spiral 这个写作工具，主控 Agent 使用 Haiku 进行任务路由和分发，子 Agent 则使用 Opus 进行正式写作。路由工作偏判断和调度，成本敏感；写作工作依赖生成质量，因此使用更强的模型。图示如下：

┌─────────────────────────────────┐
│   主控 Agent（轻量模型）        │
│   路由、分发、汇总              │
│   决策简单，成本敏感            │
└──────┬──────────────┬───────────┘
       │              │
       ▼              ▼
┌────────────┐  ┌────────────┐
│ 子 Agent  │  │ 子 Agent  │
│（强模型）  │  │（强模型）  │
│ 执行复杂   │  │ 执行复杂   │
│ 子任务     │  │ 子任务     │
└────────────┘  └────────────┘

这个例子想说明的，不是主控一定得用轻量模型、子 Agent 一定得用强模型，而是应当根据任务性质来选型。路由、分类、格式检查、简单抽取等任务，使用轻量模型即可；复杂写作、深度推理、代码修复、方案审查等任务，则交给能力更强的模型。

换句话说，并行编排不仅是为了提高速度，也是在为成本和质量做分层管理。同一条工作流中，不同角色应该承担不同难度的决策。

子 Agent 之间怎么通信

并行运行的子 Agent 彼此独立，但在实际工作中，它们经常需要共享中间结果。例如，一个子 Agent 处理完日志分析后，另一个子 Agent 需要基于这份分析继续定位问题；一个子 Agent 提取接口清单后，另一个子 Agent 需要用这份清单生成测试设计。

一种比较稳定的通信方式是共享文件系统：子 Agent 将自己的输出写到约定好的位置，需要这份输出的子 Agent 再直接读取。这种方式不依赖额外网络服务，也不需要引入消息队列，结构简单，问题也容易排查。

相比之下，通过上下文窗口传递信息容易受到长度限制；通过主控 Agent 中转则会增加主控负担，使其从调度者变成搬运工。共享文件听起来不高级，但在 Agent 编排中非常实用——它将中间结果变成了可检查、可复用、可追踪的材料。

当然，共享文件也需要基本约束。文件命名、输出格式、完成标记和错误信息都需要提前约定好，否则多个子 Agent 同时写入，容易出现覆盖、误读和版本混乱。工程中的许多麻烦并非来自工具太弱，而是来自协议过于含糊。

主控必须看得见执行过程

并行编排中最容易出现问题的环节，是主控 Agent 对子 Agent 执行状态的掌握。

如果子 Agent 只返回最终结果，主控 Agent 就相当于在进行盲调度：不知道任务进行到哪一步，不知道失败发生在哪里，也不知道结果是一次成功还是多轮修补后的产物。一旦最终输出有问题，只能整体重跑，排查成本非常高。

更好的做法是让每个子 Agent 记录执行日志。主控 Agent 可以在任意时间点查询某个子 Agent 的状态，而不是等所有任务结束后才知道发生了什么。日志不一定要很复杂，但至少要包含任务输入、当前阶段、关键决策、失败原因和最终产物位置。

这与软件测试中的思路一致：可观测性不是事后的补救手段，而是设计阶段就应该考虑的能力。没有状态记录的并行编排，跑得越快，失控也越快。

哪些任务适合并行编排

并非所有任务都适合拆开执行。并行编排真正产生收益，通常出现在以下几类场景中：

适合并行编排的场景：
1. 数据量大，可以分批处理 -> 不同批次分给不同子 Agent 并行处理
2. 多个数据源需要同时查询 -> 各自负责一个数据源，结果汇总给主控
3. 同一任务需要多个视角 -> 不同子 Agent 从不同角度分析，主控综合
4. 多个独立子任务没有强依赖关系 -> 直接并行，互不干扰

反过来，如果子任务之间有严格的前后依赖，或者任务本身过于简单、不值得拆成多个执行单元，那么并行编排的收益就很有限。为了并行而并行，往往不是提升效率，而是增加调度、同步、排错和汇总的成本。

一个比较实用的判断标准是：如果拆出去的子任务有清晰输入、独立产出、低耦合依赖，并且主控能明确验收结果，那么它就适合并行；如果子任务需要频繁互相确认，或者每一步都依赖全局判断，那就更适合串行处理。

小结

并行编排的核心，是将「一个 Agent 做所有事」转变为「主控 Agent 协调多个专注的子 Agent」。主控负责全局目标、任务拆分、依赖控制和结果验收；子 Agent 负责局部执行、产物输出和状态记录。

真正值得关注的不是启动了多个 Agent，而是任务边界是否清晰、通信协议是否稳定、执行过程是否可观测、模型分工是否合理。只有这些基础都做好，并行编排才能真正从形式上的多线程，转变为可控、可扩展的工程能力。