我三种编排模式都试了。不是顺序试的，是写同一个系统时被迫用的——因为不同任务类型需要不同的模式。
当你的 Agent 从一个变成 N 个，你必须要回答：Agent 之间怎么组织、谁听谁的、信息怎么流动。这个问题不回答，Agent 越多越乱。
市面上有三种主流模式。我分别说说试下来的感受。
结构：一个中央 Agent 拆任务，多个 Worker 各干各的。Worker 之间不直接通信。这是我最先用也是最常用的模式。
我的系统里是怎么用的：每天的文章生产流水线——我是 Supervisor，Hermes 是 Worker。我定选题，Hermes 拆成研究、写作、审计、发布四个子任务，各自独立执行。研究 Agent 只负责搜资料，不关心发布。发布 Agent 只负责构建部署，不关心内容。
我遇到的实际问题： Supervisor 的上下文窗口。当内容流水线跑了几个月后，我需要记住每个 Worker 上次的执行质量、偏好、踩过的坑。这些信息堆在 Supervisor 的上下文里，最终超出了可用窗口。后来拆出了记忆系统（情景记忆 + 语义知识）来分担——Supervisor 只管"当前任务"，不用记住"历史经验"。
适合：任务可以明确拆解为独立子任务的场景。内容生产、数据分析、项目规划。
成本：每个 Worker 独立消耗 Token。我实测过，一个 4-Worker 的流水线，总 Token 消耗大约是单 Agent 直答的 5-8 倍。
结构：没有中心节点。Agent 之间直接对话，协商、传递任务、互相纠错。
我试过的场景：一次让两个 Agent 互相审查代码——一个写，一个审，来回迭代三版。效果不错，总 Token 消耗比一个人干加一个人审高约 3 倍。
但这是我能想到的唯一适用场景。更多时候，我需要的是"确定性的结果"而不是"几个专家讨论出来的结果"。Swarm 的输出质量取决于 Agent 之间的辩论质量——而辩论质量取决于模型能力、提示词、甚至 Agent 的"性格"。不可预测性太高了，不适合生产系统。
结论：Swarm 在学术论文和 Demo 中看起来很酷，但在我的生产系统里几乎没有用武之地。唯一例外是代码审查/方案评审这类"需要多个视角"的场景。
成本：N 个 Agent 并行对话，总 Token = (单次消耗 × 轮次 × N)。成本可控但不可预测。一次辩论可能 3 轮结束，也可能 10 轮还在绕。
结构：预定义执行图。每个节点是独立处理步骤，数据沿定义好的路径流动。有分支、有条件、有并行。
我试过的场景：就是前两天的 LangGraph 实战。我搭了一个 5 节点的 Pipeline——Supervisor → Retriever → Analyst → Quality → End，带两条条件边（结果不足时改写重查、质量不通过时回退重试）。效果：执行过程可预测、可观测、可调试。每一步的输入输出都清楚。
发现的问题：Pipeline 一旦编译就不能改。我的内容是动态的——每天的问题都不一样，我需要在运行时决定"今天这个查询走哪个流程"。Pipeline 做不到这个。
适合：步骤固定的操作——批量数据处理、定时报告、标准质检流程。
成本：最省的模式。因为流程图定了，不需要模型在每一步"思考下一步该做什么"，只需要执行。我的实测中，相同步骤 Pipeline 比 Orchestrator 省约 30% 的 Token。
这是最关键的部分。不是"选一种"，是在同一个系统里根据任务特征切换：
用户来了一个问题
↓
Router（轻量分类 → 判断任务类型）
├── "写一篇文章" → Orchestrator + Worker（动态拆解）
├── "查一下库存" → Pipeline（固定流程）
├── "审查这段代码" → Swarm（辩论模式）
└── "今天天气" → 单 Agent 直答（不编排）决定的依据不是个人偏好，是任务特征：
| 任务特征 | 选什么 | 为什么 |
|---|---|---|
| 步骤可以预先确定 | Pipeline | 省 Token，可预测 |
| 步骤不确定，但可拆解 | Orchestrator | 灵活，职责清晰 |
| 需要多视角结论 | Swarm | 辩论产生深度 |
| 简单查询（1-2 步） | 单 Agent | 不编排，最快 |
同一套系统里，三种模式共存。Router 在最前面做意图分类，把不同的任务路由到不同的执行引擎。用户不会感知到背后用了哪种模式——他只知道问题被回答了。
一句话：编排模式不是选择题——你最终的系统会需要三种模式同时存在。区别在于你先用哪种，以及你什么时候意识到需要加另一种。
💬 评论