Agent 系统一扩张，中央路由器很容易变成最危险的组件。它开始理解所有业务规则、保存所有上下文、决定执行顺序，还要处理异常和审批。每增加一个能力，路由器都更聪明，也更难验证。
薄编排器模式给出的解法是收缩职责：编排层只维护顺序、状态、门禁和结果，领域推理全部交给上下文隔离的专门 Agent。核心收益是建立一条稳定边界，让概率性的模型工作运行在可检查、可恢复的控制平面里。
Meta 的生产案例说明了什么
Meta 最初把配置模式、代码生成规则、验证要求、路由逻辑，以及 10 多种数据源的填充方式全部交给同一个 Agent。演示能够运行，进入生产后却会混用不同子系统的命名和实现模式。
后来形成的架构分成两层：约 1,300 行的编排器负责 20 多条工作流，14 个专门 Agent 分别处理领域任务。编排器不生成代码，也不操作代码库。它只读取专门 Agent 的说明、检查目标是否存在、收集必要字段、自动发现可推断信息、执行可靠性门禁、发起委派，再处理结果和错误。
这套系统使用工作流模板表达阶段顺序。同一组专门 Agent 可以被重新组合成列接入、事件接入或管线迁移流程。25 份以上的领域知识文件在运行时按需加载，知识更新不要求修改中央路由器。
Meta 报告称，新列配置准备从人工 3 至 4 天、旧配置系统约 1 天，缩短到 1 小时以内；约三分之二的变更无需显著人工修改即可落地。这些数据来自单一内部系统，可以证明该案例有效，无法直接外推成所有多 Agent 架构的平均收益。
薄指的是职责，不是代码行数
几百行代码也可能是胖编排器，只要它同时承担领域判断。实现规模较大也可以保持薄，只要代码主要是确定性的基础设施。
| 责任 | 编排器 | 专门 Agent |
|---|---|---|
| 规范化和校验请求 | 负责 | 不负责 |
| 选择已知工作流和下一阶段 | 负责 | 不负责 |
| 持久化状态和尝试次数 | 负责 | 不负责 |
| 执行权限、策略与审批门禁 | 负责 | 不负责 |
| 理解领域规则并生成变更 | 不负责 | 负责 |
| 调用领域工具 | 不负责 | 负责 |
| 判断领域输出质量 | 路由到验证器 | 提交证据 |
| 提交外部可见结果 | 通过确定性门禁执行 | 不直接获得权限 |
这条边界把编排器变成控制平面。它知道当前处于哪个阶段、应收到什么工件、什么证据允许状态迁移。它无需理解工件内部的业务逻辑。
微软的多 Agent 架构指南提供了相同方向的约束：目的地和顺序已经明确时，使用确定性路由；只有路径必须在运行时逐步显现，才需要动态 handoff 或 manager。架构复杂度应该跟随任务中的不确定性，而不是跟随 Agent 数量。
上下文隔离降低的是干扰
上下文窗口是工作区，不是知识仓库。把全部 schema、工具、例外和历史样例塞入中央 Agent，会让本来无关的规则争夺注意力。Meta 看到的跨数据源概念污染，就是这种信息架构问题。
一项临床混合任务研究提供了不同领域的旁证：任务批次增加到 80 个时，多 Agent 编排方案仍保持 65.3% 准确率，单 Agent 下降到 16.6%；最高负载下，两者 Token 使用量相差 65 倍。临床任务与软件工程场景不同，这组结果只能支持一个有限结论：任务隔离会改变异构负载下的扩展曲线。
隔离还能限制故障范围。某个专门 Agent 失败后，编排器可以在同一阶段重试、执行声明过的回退方案，或携带失败工件升级处理。故障无需改写全局计划，也不会污染其他 Agent 的上下文。
隔离同样有成本。每次交接都需要稳定接口、持久状态和验证机制。一个知识域明确、执行时间短、无需恢复的任务，单 Agent 往往更简单。
给交接设计最小合同
编排器要能恢复，必须让每次状态迁移都可重建。一条阶段记录至少包含：
{
"run_id": "stable-run-id",
"workflow": "column_onboarding@3",
"phase": "validation",
"specialist": "validation_agent@7",
"input_ref": "artifact://normalized-request/sha256:...",
"expected_output": "validation_report@2",
"attempt": 1,
"policy_state": "allowed",
"status": "running",
"idempotency_key": "run:phase:target"
}
交接内容应小于整个系统的知识总量。只传递规范化目标、目标资源、相关领域资料、验收标准和权限边界。无关聊天历史、其他 Agent 的实现细节留在各自信息域内。
专门 Agent 返回工件和证据，而不是一句已经完成：
{
"status": "proposed",
"artifact_ref": "artifact://candidate-change/sha256:...",
"checks": [
{"name": "schema", "result": "pass", "evidence_ref": "..."},
{"name": "tests", "result": "pass", "evidence_ref": "..."}
],
"side_effects": [],
"retry_class": null
}
编排器校验结构，再把证据交给确定性检查或独立验证器。只有验收合同满足，状态才进入下一阶段。
恢复能力应写进状态机
系统无法判断上一次尝试是否已经产生副作用时，自动重试会放大风险。增加 Agent 之前，先定义失败后的动作。
| 失败类型 | 安全响应 |
|---|---|
| 输入不合法或缺少必要字段 | 委派前停止，补充或自动发现字段 |
| 专门 Agent 超时且确认没有副作用 | 沿用幂等键，在有限次数内重试 |
| 提交结果未知 | 先读取目标系统的事实状态，再决定是否重试 |
| 领域验证失败 | 保留工件和证据，把定向反馈交回原 Agent |
| 同一 Agent 连续失败 | 进入明确的回退或升级流程，禁止静默换路由 |
| 工作流或知识版本过期 | 让当前阶段失效，从最近兼容检查点恢复 |
| 策略或审批拒绝 | 记录拒绝并终止或等待，不能把拒绝解释成建议 |
一条实用生命周期可以写成：
已接收 → 已规范化 → 已通过门禁 → 已委派 → 已提出结果 → 已验证 → 已提交 → 已确认
每个状态都要定义责任主体、允许的迁移、超时行为和终止条件。调用专门 Agent 之前持久化状态，提交外部变更之前再次持久化，就能支持重放、恢复和事故复盘。
观测控制决策，而非隐藏推理
薄编排器天然暴露出最有用的事件：路由规则版本、工作流和阶段、迁移原因、Agent 与知识版本、输入输出工件哈希、延迟和 Token、重试与错误类别、审批结果、验证结论和目标系统回读。
这些记录与完整的 Agent 可观测性 分工明确：编排日志解释控制平面为什么迁移，工具轨迹与目标系统记录证明实际发生了什么。
长任务还要把唤醒和行动权限分开。定时器或完成事件可以重新激活流程，具体副作用仍需重新通过当前策略和审批。这里可以直接复用持久 Agent 的唤醒合同与行动合同。
胖路由器迁移清单
- 盘点路由器的每个决策，标记为确定性、概率性或策略约束。
- 把领域变换和工具调用移入拥有独立知识集的专门 Agent。
- 用带版本的输入输出 schema 替代自由文本交接。
- 把已知顺序写成有明确状态的工作流模板。
- 为每个产生副作用的阶段定义幂等、回读、重试上限和升级路径。
- 每增加一类 Agent，先补齐该阶段的验证器。
- 监测验证后完成率、恢复成功率、协调延迟和每个验收结果的成本。
- 移除协调成本高于隔离收益的专门 Agent。
最后一步决定了系统是否真的保持简洁。多 Agent 架构本身没有天然优势。目标是用最小控制平面和最少专门 Agent，维持干净的信息边界与可验证结果。
常见问题
什么是薄编排器模式？
它让确定性控制平面负责路由、顺序、状态、策略门禁、重试和结果处理，让领域推理与工具使用发生在专门 Agent 内部。
编排器是否应该使用大模型？
真正需要语义解释的决策可以使用。已知路由、工作流迁移、结构校验、幂等和审批执行适合保持确定性。只有执行路径无法预先确定时，才需要动态规划。
哪种 Agent 编排模式最好？
与任务拓扑匹配的最简单模式最好。单一知识域使用单 Agent；依赖关系已知时使用顺序或并发工作流；目的地已知时使用确定性分发；路径必须动态形成时再使用 handoff 或 manager。
如何让 Agent 编排器具备恢复能力？
持久化带版本的状态机；状态迁移前先保存工件；副作用使用幂等键；结果不明时先回读事实源；限制重试次数；明确升级路径与终止状态。
薄编排器必须配合多个 Agent 吗？
不必。即使只有一个专门 Agent，确定性控制与概率性执行的分层仍有价值，也为以后扩展保留清晰边界。