Meta 详解 Thin Orchestrator 模式：让路由少干活提升 AI 智能体可靠性

Meta Engineering Blog·2026-10-19 23:30· 50 分钟前精选AI 评分70

The Thin Orchestrator: How We Made Our AI Agents More Reliable by Giving the Router Less to Do

AI 导读

Meta 工程团队介绍其数据管道智能体采用的瘦编排器（thin orchestrator）模式：一个约 1300 行的编排器只负责路由和可靠性检查，将 20+ 工作流分派给 14 个上下文隔离的专项子智能体，自身不做任何领域推理。

推荐理由

Meta 工程团队给出可直接迁移的瘦编排器架构方法，用固定路由协议和隔离子智能体降低生产智能体的幻觉风险。

有时，把 AI 智能体所需的所有知识都交给它，反而是错误的做法。
在 Meta，我们通过刻意保持数据管道智能体编排层的精简，在效率和准确性上看到了显著提升：它负责路由工作并执行可靠性检查，而由专业智能体负责领域推理。
我们分享自己的流程和见解，以及任何团队如何将其应用到自己的生产级 AI 智能体中。

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

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

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

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

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

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

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

这个智能体拥有它所需的一切。问题恰恰就在这里。

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

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

方法：薄路由器与专业工作者

我们将系统拆分为两层：

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

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

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

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

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

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

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

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

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

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

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

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

结果

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

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

为什么这有效（以及为什么重量级编排器不行）

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

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

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

如何将此应用于你的 AI 代理

这种模式并非数据管道特有。任何构建生产 AI 代理的团队都能受益：

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

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

下一步

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

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

致谢

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

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

来源：Meta Engineering Blog · engineering.fb.com