Meta 如何用薄编排器架构让 AI 智能体更可靠

有时，把 AI 智能体所需的所有知识都交给它，反而是错误的做法。
在 Meta，我们发现，让数据流水线智能体的编排层保持刻意精简，可以显著提升效率和准确性：它负责路由工作并执行可靠性检查，而领域推理则交由专门的智能体完成。
我们在此分享自己的流程与洞察，以及任何团队如何将其应用到自己的生产环境 AI 智能体中。

我们构建了一个 1,300 行的编排器，将 20 多个工作流路由到 14 个专门的 AI 智能体。它本身不执行任何领域工作。这正是关键所在。

当我们首次部署 AI 智能体，在 Meta 的推荐系统中自动化数据列接入时——这一流程横跨三个代码仓库、三种编程语言，以及最多六个必须保持同步的流水线阶段——我们做了大多数团队都会做的事：构建一个无所不知的智能体。

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

解决办法不是更好的提示词或更大的上下文窗口，而是让中央智能体承担更少的任务。我们称之为薄编排器模式：一个负责排序和可靠性检查的路由器，将所有领域决策交给专家。

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

我们的流水线采用配置即代码的方式：Python 配置驱动 C++ 代码生成，C++ 代码生成再供给数据处理服务，数据处理服务最终填充分析系统。接入单个数据列需要在配置注册表、后端服务和数据流水线之间进行协调变更，并且每个列的数据在到达之前要经过最多六个阶段。

我们的第一种方法是使用一个单一的 AI 智能体，加载所有领域知识、配置模式、代码生成规则、流水线路由逻辑、验证要求，以及 10 多个数据源的填充模式。

这个智能体拥有它所需的一切。而这正是问题所在。

超过某个上下文阈值后，额外的知识反而会降低而非提升性能。智能体会出现概念交叉污染，把一个子系统的字段命名约定应用到另一个子系统，或者在从不同数据源填充时使用本应针对某一数据源的代码生成模式。西奈山 Windreich 人工智能与人类健康系的一篇预印本发现，在 80 个任务的批次中，经过编排的多智能体系统保持了 65.3% 的准确率，而单智能体则降至 16.6%，同时 token 使用量最多减少了 65 倍。作者将此归因于该设计对任务的隔离，从而防止了上下文干扰。我们遇到的正是相反的情况：单个智能体淹没在自己的知识中。

我们还评估了另一种单智能体方案。在为每个任务手动进行提示词工程的情况下，其成功率为 70-80%：工程师必须为每个具体任务精心编写自定义系统提示词。没有这种人工辅助，成功率降至 10-20%。这不是提示词工程的问题，而是架构的问题。

方法：薄路由器加专家工作者

我们将系统拆分为两层：

确定性编排器，不执行任何领域工作。它负责对意图进行分类、收集必需字段、执行可靠性检查，并委派给合适的专家。它从不对代码进行推理，从不生成配置，也从不接触代码库。它就是一个路由器。
十四个专业子代理，每个都是拥有隔离上下文的完整领域专家。schema 管理代理了解配置注册表。数据填充代理知道如何为 10 种数据源分别生成代码。验证代理了解构建系统和质量检查。没有任何一个代理能看到全貌。这是特性，不是缺陷。

编排器对每个请求都遵循固定的 7 步协议：

读取相关子代理的指令文件。
检查目标是否已存在（防止重复）。
收集向用户获取必需字段。
自动发现可以推断出的信息（仓库类型、现有配置）。
可靠性门禁检查是否存在活跃警告或必需的审查者。
委派将完整上下文交给子代理。
处理结果并暴露错误，确认成功。

第 1 至 5 步和第 7 步是确定性的。只有第 6 步涉及大语言模型（LLM）推理，而且它发生在一个仅加载了自身领域知识的隔离子代理内部。

我们构建了什么：工作流模板，而非新代理

一个架构洞察是将需要发生什么与每个步骤如何执行分离。编排器通过工作流模板来定义阶段顺序——这些确定性状态机约束了 LLM 的决策空间：

列接入：Schema → 验证 → 填充 → 测试
事件接入：Schema → 填充 → 验证 → 测试 → 事件处理
管道迁移：评估 → 规划 → 填充 → 验证 → 监控

每个工作流模板都以不同顺序复用同一组 14 个子代理。当我们需要支持管道迁移这一全新用例时，我们没有构建新代理。我们编写了一个新的工作流模板，以不同方式对现有代理进行排序。零新增代理代码。完整的生产级能力。

每个子代理都遵循标准化结构：

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

这种统一性意味着添加新的子代理是模板化工作，而非从零开始的工程。第 15 个子代理在结构上与第一个完全相同。

知识文件在子代理执行时按需加载，而非嵌入编排器中。我们按工作流领域组织维护了 25+ 个知识文件。当知识文件更新时，下一个会话会自动使用最新版本——无需改动编排器。同一批知识文件可服务于我们代理的多个平台实现。

结果

为一个新列准备配置，手工需要三到四天，用我们早期的配置驱动系统约需一天。而薄编排器系统不到一小时就能完成。

更宏观地看：系统中约三分之二的变更无需大量人工修改即可落地。它通过以通用性换取深度领域知识来实现这一点，这是一种刻意的架构选择。编排器是通用的；子代理是专才。

为什么这套方案有效（以及为什么重型编排器不行）

传统做法是让编排器成为最聪明的组件——把所有上下文都交给它，让它推理该做什么以及怎么做。这种做法在失效之前一直有效，而它失效的时机恰恰是你最需要它的时候——在大规模、复杂多步工作流、跨异构子系统的情况下。

薄编排器之所以有效，是因为它让架构边界与计算边界对齐：

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

如何将这套方法应用到你的 AI 代理中

这一模式并非数据管道专属。任何构建生产级 AI 代理的团队都能从中受益：

将路由与推理分离。如果你的编排器在做领域决策，那它就做得太多了。路由应当是确定性的：关键词匹配、意图分类、字段收集。把所有领域推理推入隔离的子代理中。
将子代理设计为结构统一的专才。每个子代理都应具有相同的结构：知识来源、必需输入、执行步骤、错误处理。这样一来，添加新能力就成了模板化工作，而非架构变更。
用工作流模板而非新增代理来扩展。当你需要新的用例时，先问：我能否以不同方式编排现有代理？如果你无法在不同工作流之间复用代理，说明你的代理与特定用例耦合过紧。
在运行时加载知识，而非在构建时。把知识嵌入编排器，每次更新都需要重新部署。按需加载，更新就能立即在所有平台上生效。
明确划出确定性/概率性边界。对每个组件，都要决定：这是一个路由决策（确定性），还是一个推理任务（概率性）？编排器应位于一侧，子代理位于另一侧。不要把它们混在一起。

支持瘦编排器的最有力论据，是替代方案的失败模式。当重量级编排器产生幻觉时，错误会扩散到下游所有环节：它会把任务路由到错误的代理、收集错误的字段，或跳过可靠性检查。瘦编排器留下的幻觉空间很小，因为它的路由和可靠性步骤不依赖 LLM 推理。它遵循固定协议。创造力发生在下游，在隔离的、按领域划分的上下文中，那里幻觉风险被最小化，失败也被限制在局部。

下一步

我们正在扩展这一架构，以应对新管道领域中数据列增加的情况。组合式论点预测这会奏效，因为扩展意味着增加工作流模板和知识文件，而不是重建代理。我们还在探索系统如何从生产使用中持续改进，利用自动反馈循环识别失败模式，并提出针对子代理知识的定向改进，且任何更改始终需要人工审核把关。

反直觉的教训是：我们 AI 代理系统中最重要的组件，是干活最少的那个。让编排器保持瘦、让专家保持深，整个系统就会变得更可靠。

致谢

这项工作是团队努力的结果。其他为此做出贡献的人包括： Mani Bhushan、Rahul Maliakkal、Jae Ha、Chakrapani Kumar、Vivek Tiwari 和 Amanda Yin。

文章瘦编排器：我们如何通过减少路由器的职责让 AI 代理更可靠首次发表于 Engineering at Meta。