多 Agent 编排模式

Agent 开发进阶考 6 题讲解 3 段

五种编排模式里，orchestrator-workers 最常用：主 Agent 拆任务、派给 worker、再由合成器汇总。拆分唯一正当的理由是上下文隔离 —— 每个 worker 只背自己那份上下文；并行是副产品，不是目的。

也叫：多 Agent · orchestrator-workers · 编排模式 · 上下文隔离 · 合成器 · router

orchestrator-workers 的真实形态出自 T3-8

这个模式之所以最常被推荐，是因为它把"上下文隔离"表达得最直接：

原文示意

                 用户任务
                     │
            ┌────────▼────────┐
            │   Orchestrator  │  上下文里只有：任务、子任务清单、各 worker 的
            │  （拆解 + 汇总） │  **结构化摘要**——绝不放 worker 的完整过程
            └──┬────┬────┬────┘
               │    │    │   每个 worker 收到一份「结构化任务简报」
        ┌──────▼┐ ┌─▼───┐ ┌▼──────┐
        │Worker1│ │W2   │ │W3     │  各自独立上下文，互不可见
        │读50个 │ │查库 │ │读代码 │  ← 这三件事混在一个上下文里就是灾难
        │网页   │ │     │ │       │
        └───┬───┘ └─┬───┘ └───┬───┘
            └───────┴─────────┘
              返回：结构化摘要（不是 transcript）

两条被反复验证的工程纪律（截至 2026-08）：

子 Agent 必须收到结构化任务简报，不能是自由文本委派。简报至少包含四项：目标 / 输出格式 / 可用工具与信息源 / 任务边界（什么不要做）。自由发挥式的委派（"你去查一下这个"）是有记录的失败模式——worker 会自行发挥，做出编排器根本没要的东西。
子 Agent 必须返回结构化摘要，不能返回完整 transcript。把 worker 的全过程灌回编排器，既污染上下文又暴涨成本。这条不做，编排器会在 4 个 worker 左右就撑爆上下文，然后你会看到它开始遗忘最初的任务。

另外，子 Agent 要有自己的 system prompt，不要复用编排器的——角色不同，可用工具不同，约束也不同。

以上节选自T3-8 多 Agent 编排——唯一正当的理由是上下文隔离，读全文能看到前后语境。