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

薄编排器：通过减少路由器负担提升 AI 代理可靠性 - Meta 工程实践

发布日期

2026 年 10 月 19 日

分类

AI 研究

,

机器学习应用

薄编排器：通过减少路由器负担提升 AI 代理可靠性

.entry-meta

.entry-header

作者

Plawan Rath

Akhil Jindal

Ashwini Verma

• 有时，向 AI 代理提供所有所需知识并非正确做法。

• 在 Meta，我们通过刻意保持数据管道代理的编排层"精简"，显著提升了效率和准确性：它负责工作路由和可靠性检查，而领域推理则由专业代理完成。

• 我们将分享自身实践过程和见解，并说明任何团队如何将其应用于生产环境的 AI 代理。

我们构建了一个 1300 行的编排器，将 20 多个工作流路由到 14 个专业 AI 代理。它本身不执行任何领域工作。这正是设计初衷。

当我们将 AI 代理首次部署到 Meta 推荐系统中自动化数据列上线流程时——该过程涉及三个代码仓库、三种编程语言和最多六个需要保持同步的流水线阶段——我们采取了大多数团队的做法：构建一个无所不知的智能代理。

在演示中运行良好。但在生产环境中开始产生幻觉。

解决方案不是更好的提示词或更大的上下文窗口，而是让中心代理承担更少的工作。我们称之为"薄编排器模式"：一个负责序列控制和可靠性检查的路由器，将所有领域决策交给专家。

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

我们的流水线采用配置即代码方式：Python 配置驱动 C++ 代码生成，进而为数据处理服务提供支持，最终填充分析系统。单个数据列的上线需要跨配置注册表、后端服务和数据流水线进行协调变更，每个列最多要经过六个阶段才能完成数据传输。

我们的初始方案是构建一个装载所有领域知识的单一 AI 代理，包含配置模式、代码生成规则、流水线路由逻辑、验证要求和 10 多个数据源的填充模式。

代理拥有所有所需信息。这正是问题所在。

当上下文阈值超过一定限度后，额外知识反而会降低性能。代理会产生概念交叉污染，将一个子系统的字段命名规范应用于其他系统，或在填充不同数据源时使用本应属于其他数据源的代码生成模式。来自梅约诊所人工智能与人类健康系的预印本研究发现，在 80 个任务批次中，多代理系统保持 65.3% 的准确率，而单一代理系统下降至 16.6%，同时将 token 使用量减少高达 65 倍。作者将这种差异归因于任务隔离设计，防止了上下文干扰。我们遇到的却是相反情况：单一代理被自身知识淹没。

我们还评估了另一种单一代理方案。其成功率在每项任务手动提示工程下达到 70-80%：工程师需要为每个具体任务定制系统提示。没有这种人工干预，成功率降至 10-20%。这不是提示工程问题，而是架构设计问题。

方案：配备专业工作者的精简路由器

我们将系统拆分为两层：

• 一个确定性协调器，不执行任何领域工作。它负责识别意图、收集必要字段、执行可靠性检查，并委托给合适的专家。它从不分析代码、从不生成配置、也从不接触代码库。它本质上是一个路由器。

• 十四个专业子代理，每个都是拥有独立上下文的完整领域专家。模式管理代理了解配置注册表。数据源代理知道如何为10种数据源生成代码。验证代理熟悉构建系统和质量检查。没有任何一个代理能掌握全局信息。这正是其特性，而非缺陷。

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

• 读取相关子代理的指令文件
• 检查目标是否已存在（防止重复）
• 从用户处收集必要字段
• 自动发现可推断信息（仓库类型、现有配置）
• 执行活跃警告或必要审核人员的可靠性检查
• 将完整上下文委托给子代理
• 处理结果并显示错误，确认成功

步骤1-5和7都是确定性操作。只有步骤6涉及大语言模型（LLM）推理，且该推理发生在仅加载其领域知识的独立子代理中。

我们构建的内容：工作流模板，而非新代理

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

• 列新增：模式 → 验证 → 数据生成 → 测试
• 事件新增：模式 → 数据生成 → 验证 → 测试 → 事件处理
• 管道迁移：评估 → 规划 → 数据生成 → 验证 → 监控

每个工作流模板在不同序列中复用相同的14个子代理池。当需要支持管道迁移这一全新用例时，我们没有创建新代理，而是编写了一个新工作流模板，以不同顺序排列现有代理。零新增代理代码，即可实现完整生产功能。

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

• 知识源：运行时需要加载的领域文件（通常每个文件包含几千个标记）
• 预收集清单：委托前协调器必须收集的信息
• 分步工作流：领域特定的执行计划
• 发现模式：在单体仓库中查找相关代码模式的方法
• 故障排除：常见失败的错误到解决方案映射

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

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

结果

手动准备新列的配置需要3到4天，早期配置驱动系统需要约1天。而轻量级协调器系统可在不到1小时内完成。

为什么这种设计有效（而重型协调器为何失效）

传统方法是让协调器成为最智能的组件——赋予它所有上下文，让它推理该做什么以及如何做。这种方法在失效前有效，而它失效的时刻正是你最需要它的时候——在大规模、复杂多步骤工作流、跨异构子系统时。

轻量级协调器之所以有效，是因为它将架构边界与计算边界对齐：

• 确定性决策保持确定性。“哪个子代理处理这个？”是路由决策，而非推理任务。不要用大语言模型处理它。

• 上下文隔离防止交叉污染。数据源A的种群代理永远看不到数据源B的模式。它不会误判错误模式。

• 故障被隔离。如果子代理失败，协调器会重试或升级。故障不会破坏协调器状态或其他子代理的上下文。

• 系统在每一层独立改进。更好的模型能同时提升所有14个子代理。知识文件更新立即生效。新工作流模板无需修改代理即可解锁新功能。没有哪个组件需要承担全部重量。

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

这种模式不局限于数据管道。任何构建生产级AI代理的团队都能受益：

• 将路由与推理分离。如果协调器在做领域决策，它承担了过多职责。路由应是确定性的：关键词匹配、意图分类、字段收集。将所有领域推理推送到隔离的子代理中。

• 设计结构统一的专家型子代理。每个子代理应有相同结构：知识源、必需输入、执行步骤、错误处理。这使添加新功能成为模板化工作，而非架构变更。

• 用工作流模板而非新代理实现扩展。当需要新用例时，首先问：能否用不同顺序排列现有代理？如果你无法在不同工作流中复用代理，说明你的代理过于耦合特定用例。

• 运行时加载知识，而非构建时。将知识嵌入协调器会导致每次更新都需要重新部署。按需加载知识，更新能立即生效，覆盖所有平台。

• 明确划分确定性/概率性边界。对每个组件判断：这是路由决策（确定性）还是推理任务（概率性）？协调器应位于一侧，子代理位于另一侧。不要混用它们。

轻量级协调器最强的论据是其替代方案的失效模式。当重型协调器产生幻觉时，错误会传播到所有下游组件：它路由到错误代理、收集错误字段或跳过可靠性检查。轻量级协调器几乎没有幻觉空间，因为其路由和可靠性步骤不依赖大语言模型推理。它遵循固定协议。创造性发生在下游，位于隔离的、领域限定的上下文中，这些上下文的幻觉风险最低且故障可被隔离。

下一步

我们正在扩展这一架构，以应对新流水线领域中数据列数量的增加。组合性理论预测这将有效，因为扩展意味着添加工作流模板和知识文件，而不是重建代理。我们也在探索系统如何通过生产使用持续改进，利用自动化反馈循环识别故障模式，并针对子代理知识提出定向优化方案，任何变更都必须经过人工审核。

反直觉的教训：在我们的AI代理系统中，最重要的组件反而是工作量最少的那个。保持协调器精简、专家模块深入，整个系统将变得更加可靠。

致谢

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