Meta 工程博客 2小时前 · 2026-10-20 00:54:02 · 6 阅读

薄编排器模式：让 AI Agent 路由层“做减法”以提升可靠性

有时，把 AI Agent 所需的全部知识一股脑塞给它，反而是一种错误的做法。
在 Meta，我们发现通过刻意保持数据管道 Agent 编排层的“薄度”，在效率和准确性上取得了显著提升：由它负责任务路由和执行可靠性检查，而将领域推理工作交给专门的 Agent。
本文将分享我们的实践过程和见解，以及任何团队如何将此应用于其生产环境的 AI Agent。

我们构建了一个 1,300 行的 Orchestrator（编排器），将 20 多个工作流路由给 14 个专用 AI Agent。它本身不做任何领域工作。这正是设计的初衷。

当我们最初部署 AI Agent 来自动化 Meta 推荐系统中的数据列上线流程时——这一过程横跨三个代码库、三种编程语言，且多达六个管道阶段必须保持同步——我们做了大多数团队都会做的事：构建一个“无所不知”的智能 Agent。

它在演示中表现良好，但在生产环境中，它开始产生幻觉。

解决办法并非更优化的 Prompt 或更大的上下文窗口，而是给中央 Agent 减轻负担。我们将此称为“薄编排器”（Thin Orchestrator）模式：路由器负责处理时序和可靠性检查，并将所有领域决策权交给专家。

问题：上下文越多，结果越差

我们的管道采用配置即代码（config-as-code）：Python 配置驱动 C++ 代码生成，进而供数据服务处理，最终填充分析系统。上线单个数据列需要在配置注册表、后端服务和数据管道之间进行协调变更，每个数据列需经过多达六个阶段才能送达其数据。

我们最初的做法是部署单个 AI Agent，并赋予它所有领域知识、配置架构、代码生成规则、管道路由逻辑、验证要求以及 10 多个数据源的填充模式。

Agent 拥有一切所需。问题也正在于此。

上下文一旦超过某个阈值，新增的知识非但不会提升性能，反而会导致性能下降。Agent 会混淆概念，比如把某个子系统的字段命名规范套用到另一个子系统上，或者在处理新数据源时，错误地套用为另一个数据源设计的代码生成模式。纽约西奈山医院 Windreich 人工智能与人类健康部门的一份预印本研究表明，在 80 个任务组成的批量处理中，多智能体协同系统的准确率保持在 65.3%，而单智能体系统的准确率仅为 16.6%，前者的 Token 消耗量最高可降低 65 倍。作者将此归因于该设计实现了任务隔离，从而避免了上下文干扰。我们经历的则是相反的情况：单个 Agent 被海量的自身知识淹没了。

我们还评估了一种替代性的单 Agent 方案。在每次任务都需要手动提示词工程的情况下，其成功率为 70% 至 80%，工程师必须为每个具体工作定制专属的系统提示词。若缺乏这种精细的人工干预，成功率会骤降至 10% 至 20%。这不是提示词工程的问题，而是架构层面的缺陷。

方案：轻量级路由器加专家型 Worker

我们将系统拆分为两层：

一个确定性的 Orchestrator（编排器），它不执行任何领域工作。它负责意图分类、收集必要字段、运行可靠性检查，并将任务委派给合适的专家。它从不推理代码，从不生成配置，也从不触碰代码库。它只是一个路由器。
14 个专职子 Agent，每个都是拥有隔离上下文的领域专家。Schema 管理 Agent 熟悉配置注册表；数据填充 Agent 知道如何针对 10 种数据源分别生成代码；校验 Agent 精通构建系统与质量检查。没有哪个 Agent 能看清全貌，这是特性，而非缺陷。

对于每个请求，Orchestrator 遵循固定的 7 步协议：

读取相关子 Agent 的指令文件。
检查目标是否已存在（防止重复）。
从用户处收集必要字段。
自动发现可推断的信息（如仓库类型、现有配置）。
执行可靠性门禁检查，确认是否有活跃警告或必须指定的审阅者。
携带完整上下文委派任务给子 Agent。
处理结果，展示错误信息，确认操作成功。

步骤 1–5 和 7 都是确定性的。只有步骤 6 需要大语言模型（LLM）推理，而且这一步发生在隔离的 subagent 内部，只加载它所需的领域知识。

我们的做法：工作流模板，而不是新 Agent

架构上的一个关键洞察是：把「要做什么」和「每一步怎么做」分开。编排器通过工作流模板来定义阶段顺序——这是确定性的状态机，用来约束 LLM 的决策空间：

字段接入：Schema → 验证 → 数据填充 → 测试
事件接入：Schema → 数据填充 → 验证 → 测试 → 事件处理
Pipeline 迁移：评估 → 规划 → 数据填充 → 验证 → 监控

每个工作流模板都以不同的顺序复用同一批 14 个 subagent。后来需要支持 pipeline 迁移这个全新场景时，我们没有新建任何 agent，只是写了一个新的工作流模板，把现有 agent 按不同顺序串起来——零新增 agent 代码，却完整具备了生产环境的能力。

每个 subagent 都遵循统一的结构：

知识源：运行时加载哪些领域文件（每个通常几千 token）。
预采集清单：编排器委派任务前必须收集的信息。
分步工作流：该领域的具体执行计划。
发现模式：如何在 monorepo 中找到相关代码模式。
故障排查：常见错误与对应解决方案的映射。

这种统一性意味着新增一个 subagent 只是套模板的活儿，而不是从零开始的工程。第 15 个 subagent 在结构上和第 1 个别无二致。

知识文件是在 subagent 执行时按需加载的，而不是内嵌在编排器里。我们维护着 25 个以上的知识文件，按工作流领域分类。知识文件更新后，下一次会话就会自动使用最新版本，无需改动编排器。同一批知识文件还能服务于 agent 的多种平台实现。

效果

新字段的配置准备，纯手工要做三到四天，我们早期的 config-driven 系统也需要约一天，而这套轻量编排系统一小时内就能完成。

从更宏观的角度看：该系统约三分之二的变更无需人工修改即可落地。这是通过牺牲通用性换取深度领域知识实现的，一种刻意的架构选择。Orchestrator（编排器）负责通用调度，而子代理（subagents）则是领域专家。

为什么有效（以及为什么重型 Orchestrator 会失效）

传统做法是让 Orchestrator 成为最“聪明”的组件，赋予它所有上下文，并让它负责推理该做什么以及怎么做。这种做法起初有效，但随着规模扩大、多步工作流变复杂、且涉及异构子系统时，它就会失效——恰恰在最需要可靠性的时刻失效。

轻量级 Orchestrator 之所以有效，是因为它让架构边界与计算边界对齐：

确定性决策保持确定性。“该由哪个子代理处理？”是一个路由决策，而非推理任务，因此不要使用 LLM 来解决。
上下文隔离防止交叉污染。处理数据源 A 的子代理永远不会看到数据源 B 的模式，因此不会幻觉出错误的数据。
故障被限制在局部。如果某个子代理失败，Orchestrator 只会重试或升级处理，该故障不会污染 Orchestrator 的状态或其他子代理的上下文。
系统每一层都能独立进化。更好的模型会同时提升所有 14 个子代理；知识文件更新可立即生效；新工作流模板能解锁新能力而无需修改子代理。没有任何单一组件需要承载整个系统的重量。

如何在你的 AI 代理中应用此模式

这一模式并非仅限于数据管道，任何构建生产级 AI 代理的团队都可从中受益：

将路由与推理分离。如果你的 Orchestrator 在做领域决策，说明它承担了过多职责。路由应是确定性的，例如关键词匹配、意图分类、字段收集。将所有领域推理推给隔离的子代理。
设计结构统一的专业化子代理。每个子代理应具有相同的结构：知识源、所需输入、执行步骤、错误处理。这样添加新能力就变成模板化工作，而非架构变更。
用工作流模板而非新代理来扩展规模。当需要新用例时，先问：能否通过重新编排现有代理来实现？如果代理无法跨工作流复用，说明它们与特定用例耦合度过高。

知识应在运行时加载，而非构建时。若将知识嵌入 Orchestrator，每次更新都需重新部署；按需加载则能立即生效，并覆盖所有平台。

明确划定确定性与概率性操作的边界。为每个组件做决策：这是路由决策（确定性）还是推理任务（概率性）？Orchestrator 应位于一侧，子 Agent 位于另一侧，切勿混淆。

支持“薄 Orchestrator”最有力的论据，恰恰是“重 Orchestrator”的故障模式。当重量级 Orchestrator 产生幻觉时，错误会向下游一切环节扩散：它可能路由到错误的 Agent、采集错误的字段，或跳过可靠性检查。薄 Orchestrator 极大地减少了幻觉空间，因为其路由和可靠性步骤不依赖 LLM 推理，而是遵循固定协议。创造性发生在下游，发生在隔离的、领域限定上下文中，这里的幻觉风险最小，故障也被遏制在局部。