薄编排器：如何通过让路由器少做工作，使我们的 AI 代理更可靠（11 分钟阅读）

# 瘦编排器：如何通过让路由器少做事情，让我们的 AI 智能体更可靠 Source: https://engineering.fb.com/2026/10/19/ml-applications/thin-orchestrator-ai-agent-architecture/ - 有时候，把 AI 智能体需要的所有知识都给它，反而是错误的做法。 - 在 Meta，我们通过刻意让数据流水线智能体的编排层保持"薄"，在效率和准确性上取得了显著提升：它只负责路由工作和执行可靠性检查，而由专门的智能体负责领域推理。 - 我们将分享自己的实践过程和心得，以及任何团队如何将其应用到生产环境中的 AI 智能体上。 我们构建了一个 1300 行的编排器，将 20 多个工作流路由到 14 个专门的 AI 智能体。它自身不执行任何领域工作。这正是重点所在。 最初，我们部署 AI 智能体来自动化 Meta 推荐系统中的数据列上线（onboarding）流程——这个流程横跨三个代码仓库、三种编程语言，以及最多六个必须保持同步的流水线阶段——我们采取了大多数团队的做法：构建一个无所不知的智能体。 它在演示中表现良好。到了生产环境，它开始产生幻觉。 修复方法不是更好的提示词或更大的上下文窗口，而是让中央智能体少做一些事情。我们称之为"瘦编排器"（thin orchestrator）模式：一个负责时序编排和可靠性检查的路由器，而将所有领域决策留给专门的智能体。 ## 问题：更多上下文，更差的结果 我们的流水线是"配置即代码"：Python 配置驱动 C++ 代码生成，代码生成服务于数据处理服务，数据处理服务填充分析系统。上线单个数据列需要在配置注册表、后端服务和数据流水线之间进行协调一致的更改，每个数据列在数据到达之前要经历多达六个阶段。 我们的第一种方案是一个单一的 AI 智能体，加载了所有领域知识、配置模式（schema）、代码生成规则、流水线路由逻辑、验证要求，以及 10 多个数据源的填充（population）模式。 这个智能体拥有它需要的一切。这就是问题所在。 超过某个上下文阈值后，额外的知识会*降低*而非提升性能。智能体会交叉污染概念，比如将一个子系统的字段命名规范应用到另一个子系统，或者在从不同数据源填充时使用了本应针对另一个数据源的代码生成模式。Windreich 人工智能与人类健康系（Mount Sinai）的一篇预印本（https://www.nature.com/articles/s44401-026-00077-0）发现，在 80 个任务的批量测试中，编排式多智能体系统保持了 65.3% 的准确率，而单智能体下降到 16.6%，同时 token 用量减少了最多 65 倍。作者将此归功于该设计对任务的隔离，防止了上下文干扰。我们经历的恰恰是反面：一个被自己的知识淹没的单一智能体。 我们还评估了另一种单智能体方案。它的成功率是 70-80%，但这*是建立在*每个任务都需要手动调优提示词的基础上的：工程师必须为每个具体任务精心编写定制的系统提示词。没有这种"手把手"辅助，成功率就跌到 10-20%。这不是提示词工程的问题，而是架构问题。 ## 方案：一个瘦路由器 + 专家型执行者 我们将系统拆分为两层： 1. **一个确定性的编排器**，不执行任何领域工作。它负责分类意图、收集所需字段、运行可靠性检查，并委派给合适的专家。它从不推理代码，从不生成配置，也从不触碰代码库。它是一个路由器。 2. **十四个专门的子智能体**，每个都是拥有独立上下文的完整领域专家。模式管理智能体了解配置注册表。填充智能体了解如何为 10 个数据源分别生成代码。验证智能体了解构建系统和质量检查。没有任何智能体能看到全局。这是特性，不是缺陷。 编排器对每个请求都遵循固定的 7 步协议： 1. **读取**相关子智能体的指令文件。 2. **检查**目标是否已存在（防止重复）。 3. **收集**用户提供的必需字段。 4. **自动发现**可以推断出的信息（仓库类型、现有配置）。 5. **可靠性关卡**检查是否有活跃警告或必需的评审人。 6. **委派**给子智能体，并附带完整上下文。 7. **处理**结果，暴露错误，确认成功。 第 1-5 步和第 7 步是确定性的。只有第 6 步涉及大语言模型（LLM）推理，而且它发生在隔离的子智能体内，只加载了该子智能体的领域知识。 ## 我们构建了什么：工作流模板，而非新智能体 一个架构上的洞察是：将*需要做什么*与*每一步如何执行*分离开来。编排器通过工作流模板定义阶段顺序——这些是确定性的状态机，约束了 LLM 的决策空间： - **数据列上线：**模式（Schema） → 验证（Validation） → 填充（Population） → 测试（Testing） - **事件上线：**模式 → 填充 → 验证 → 测试 → 事件处理 - **流水线迁移：**评估 → 规划 → 填充 → 验证 → 监控 每个工作流模板以不同的顺序复用同一批 14 个子智能体。当我们需要支持流水线迁移——一个全新的用例时，我们没有构建新智能体。我们编写了一个新的工作流模板，以不同的顺序编排现有智能体。零新智能体代码，完整获得生产能力。 每个子智能体遵循标准化结构： - **知识源：**运行时要加载哪些领域文件（通常每个几千 token）。 - **预收集检查清单：**编排器在委派之前必须收集什么。 - **分步工作流：**领域特定的执行计划。 - **发现模式：**如何在 monorepo 中找到相关代码模式。 - **故障排查：**常见失败的错误到解决方案映射。 这种一致性意味着添加新子智能体是模板化的作业，而不是从零开始的工程工作。第 15 个子智能体在结构上与第 1 个完全相同。 知识文件在子智能体执行时按需加载，而不是嵌入到编排器中。我们维护了 25 个以上的知识文件，按工作流领域组织。当知识文件更新后，下一个会话自动使用最新版本——无需修改编排器。相同的知识文件服务于我们智能体的多个平台实现。 ## 结果 新数据列的配置准备工作，手工操作需要三到四天，使用我们早期的配置驱动系统大约需要一天。瘦编排器系统在一小时内就能完成。 更大的背景是：大约三分之二的系统更改无需重大人工编辑即可落地。这是通过用通用性换取深度领域知识来实现的，这是一个刻意的架构选择。编排器是通用的；子智能体是专家。 ## 为什么这有效（以及为什么重型编排器无效） 传统做法是让编排器成为最聪明的组件——给它所有上下文，让它推理该做什么以及怎么做。这在有效时很管用，直到它不管用为止——而它失效的时刻恰恰是你最需要它的时刻：规模化时、面对复杂的多步骤工作流时、跨越异构子系统时。 瘦编排器之所以有效，是因为它使架构边界与计算边界对齐： - **确定性决策保持确定性。**"哪个子智能体处理这个？"是一个路由决策，不是推理任务。不要用 LLM 来做这件事。 - **上下文隔离防止交叉污染。**数据源 A 的填充智能体永远不会看到数据源 B 的模式。它无法幻觉出错误的模式。 - **故障被隔离。**如果某个子智能体失败，编排器会重试或升级处理。故障不会污染编排器的状态或其他子智能体的上下文。 - **系统在每一层独立改进。**更好的模型同时改进全部 14 个子智能体。知识文件更新立即生效。新的工作流模板解锁新能力，无需改动智能体。没有任何单一组件承担全部重量。 ## 如何将其应用到你的 AI 智能体上 这个模式不限于数据流水线。任何构建生产环境 AI 智能体的团队都能受益： 1. **将路由与推理分离。**如果你的编排器在做领域决策，它做得太多了。路由应该是确定性的：关键词匹配、意图分类、字段收集。把所有领域推理推进隔离的子智能体中。 2. **将子智能体设计为结构统一的专家。**每个子智能体都应该有相同的结构：知识源、必需输入、执行步骤、错误处理。这使得添加新能力成为模板化作业，而非架构变更。 3. **用工作流模板扩展，而非新智能体。**当你需要新用例时，先问：我能否以不同顺序编排现有智能体？如果你的智能体无法跨工作流复用，说明它们与特定用例耦合太紧。 4. **在运行时加载知识，而非构建时。**把知识嵌入编排器，每次更新都需要重新部署。按需加载则更新立即生效，覆盖所有平台。 5. **明确划定确定性/概率性的边界。**对每个组件，决定：这是一个路由决策（确定性）还是推理任务（概率性）？编排器应在一边，子智能体在另一边。不要混淆它们。 支持瘦编排器最有力的论据是替代方案的失败模式。当一个重型编排器产生幻觉时，错误会传播到下游的一切：它路由到错误的智能体、收集错误的字段、或者跳过可靠性检查。瘦编排器留给幻觉的空间很小，因为它的路由和可靠性步骤不依赖 LLM 推理。它遵循固定协议。创造力发生在下游，发生在领域范围隔离的上下文中——那里幻觉风险最小，故障被隔离。 ## 下一步 我们正在扩展这一架构，以应对跨新流水线领域的数据列增长。组合化论题（compositional thesis）预测这将会成功，因为扩展意味着添加工作流模板和知识文件，而不是重建智能体。我们还在探索系统如何从生产使用中持续改进，使用自动化反馈循环来识别失败模式，并针对子智能体知识提出定向改进建议，且始终由人工审核把关任何更改。 这个反直觉的教训是：我们 AI 智能体系统中最重要的组件，是做事最少的那个。让你的编排器保持精瘦，让你的专家保持深度，整个系统就会变得更可靠。 ## 致谢 *这项工作是团队协作的成果。其他为此做出贡献的人员包括：Mani Bhushan、Rahul Maliakkal、Jae Ha、Chakrapani Kumar、Vivek Tiwari 和 Amanda Yin。*