薄编排器：让路由器少做事，我们如何把 AI 代理做得更可靠

Engineering at Meta 2026-10-22T21:40:11.432294

有时候，把所有知识都塞给一个 AI Agent 反而是错误做法。在 Meta，我们发现，刻意把数据流水线 Agent 的编排层做"薄"，能显著提升效率和准确率：这一层只负责派发任务、执行可靠性检查，具体的领域推理交给专门的 Agent 完成。下面我们分享自己的实践过程和经验，也讲讲任何团队该如何把这套方法用到生产环境的 AI Agent 上。

我们做了一个 1300 行的编排器，把 20 多条工作流派发给 14 个专门的 AI Agent。它自己不做任何领域工作——这正是关键所在。

最初，我们用 AI Agent 去自动化 Meta 推荐系统里的数据列接入流程。这个流程横跨三个代码仓库、三种编程语言，以及最多六个必须保持同步的流水线阶段。当时我们的做法和大多数团队一样：造一个无所不知的聪明 Agent。它在演示里跑得挺好。一上生产就开始胡编。

解决办法不是更好的提示词，也不是更大的上下文窗口，而是让这个中心 Agent 少干点活。我们把这种思路叫作薄编排器模式：路由器只管任务排序和可靠性检查，所有领域决策都留给专家 Agent。

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

我们的流水线是"配置即代码"：Python 配置驱动 C++ 代码生成，生成的代码再供给数据处理服务，服务最终填充分析系统。要接入一个数据列，就得在配置注册表、后端服务和数据流水线之间做协调一致的改动；每一列的数据要经过最多六个阶段才能到位。

我们的第一版方案是一个单一的 AI Agent，把所有领域知识都灌进去：配置 schema、代码生成规则、流水线路由逻辑、校验要求，还有 10 多个数据源的填充模式。它该有的全都有了——问题也出在这儿。

一旦超过某个上下文阈值，额外的知识不但没帮忙，反而拖了后腿。Agent 会把不同概念搅在一起：把一个子系统的字段命名规范套到另一个子系统上，或者在从另一个数据源填充数据时，用上本来只适用于某个数据源的代码生成模式。

Mount Sinai 的 Windreich 人工智能与人类健康系（Windreich Department of Artificial Intelligence and Human Health）发布的一篇预印本论文发现，在 80 项任务的批次中，经过编排的多代理系统保持了 65.3% 的准确率，而单一代理的准确率降至 16.6%，同时令牌使用量最多减少了 65 倍。作者将这一优势归因于该设计对任务进行了隔离，从而防止了上下文干扰。

我们遇到的却是相反的情况：单一代理被自身的知识所淹没。我们还评估了另一种单一代理方案。在针对每项任务手动编写提示词的情况下，其成功率为 70-80%：工程师必须为每个具体任务手工编写自定义系统提示词。一旦失去这种人工支持，成功率便降至 10-20%。

这并非提示词工程的问题，而是架构的问题。

方法：薄路由器与专家工作器

我们将系统拆分为两层：

一个确定性的编排器，不执行任何领域工作。 它负责对意图进行分类、收集必填字段、执行可靠性检查，并将任务委派给合适的专家。它从不推理代码，从不生成配置，也从不接触代码库。它就是一个路由器。

十四个专业化子代理，每一个都是拥有隔离上下文的完整领域专家。一个 schema 管理代理了解配置注册表。一个种群代理知道如何为 10 个数据源分别生成代码。一个验证代理了解构建系统与质量检查。没有任何代理能看到全貌——这是特性，而非缺陷。

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

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

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

我们构建了什么：工作流模板，而非新智能体

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

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

每个工作流模板都以不同的顺序，复用同一个由 14 个子智能体组成的池子。当我们需要支持管道迁移这个全新用例时，我们没有去构建新的智能体，而是写了一个新的工作流模板，把现有智能体按不同顺序重新编排。没有新增一行智能体代码，就具备了完整的生产可用能力。

每个子智能体都遵循一套标准结构：

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

这种统一性意味着，新增一个子智能体就是照模板填空，而不是从零开始搞一套完整工程。第 15 个子智能体在结构上和第一个完全一样。

知识文件在子智能体执行时按需加载，而不是嵌在编排器里。我们维护了 25 个以上知识文件，按工作流领域分门别类。某个知识文件更新后，下一次会话会自动用上最新版本——不用改动编排器。同一批知识文件也服务于我们智能体的多个平台实现。

结果

为一个新列做配置准备，手工需要三到四天，用我们早期的配置驱动系统大约一天，而薄编排器系统把时间压到了不到一小时。放到更大的背景看：系统大约三分之二的改动无需大量人工修改就能落地。它靠的是用通用性换取深度领域知识，这是一个刻意的架构选择。编排器负责通用，子智能体负责专精。

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

传统做法是把编排器做成最聪明的组件——把所有上下文都塞给它，让它自己推理该做什么、怎么做。这套思路在某个临界点之前都管用，然后就会突然失效，而且偏偏在你最需要它的时候失效——在大规模场景下、在复杂的多步工作流中、在跨越异构子系统的时候。

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

确定性决策保持确定性。 “哪个子代理来处理这个任务？”这是一个路由决策，不是推理任务。别用大语言模型（LLM）来做这件事。

上下文隔离防止交叉污染。 负责数据源 A 的群体代理永远不会看到数据源 B 的模式。它不可能凭空编造出错误的那一个。

故障被隔离在局部。 如果某个子代理失败，编排器会重试或升级处理。故障不会污染编排器的状态，也不会波及其他子代理的上下文。

系统每一层都能独立改进。 换一个更好的模型，14 个子代理同时受益。更新一个知识文件，立即生效。新增一个工作流模板就能解锁新能力，不用碰任何代理。没有任何单个组件承担全部重量。

如何把这套方法用到你的 AI 代理上

这个模式并不只适用于数据管道。任何构建生产级 AI 代理的团队都能从中受益：

把路由和推理分开。 如果你的编排器在做领域决策，那它管得太多了。路由应该是确定性的：关键词匹配、意图分类、字段收集。把所有领域推理推到隔离的子代理里去。

把子代理设计成结构统一的专家。 每个子代理都应该有相同的结构：知识来源、必需输入、执行步骤、错误处理。这样新增能力就是模板化的工作，而不是架构改造。

用工作流模板来扩展，而不是新增代理。 需要支持一个新场景时，先问自己：我能不能把已有的代理换一种顺序编排？如果你没法在不同工作流之间复用代理，说明你的代理和具体场景耦合得太紧了。

在运行时加载知识，而不是在构建时加载。

把知识嵌进编排器里，每次更新都得重新部署。按需加载就不一样了：更新立即生效，所有平台同时生效。要把确定性边界和概率性边界划清楚。每个组件都要先判断：这是路由决策（确定性的），还是推理任务（概率性的）？编排器站一边，子智能体站另一边。两者不能混。支持轻量编排器的最强论据，恰恰来自反面的失败模式。重型编排器一旦产生幻觉，错误会一路扩散到下游：路由到错误的智能体、收集到错误的字段、跳过可靠性检查。轻量编排器几乎没有幻觉空间，因为它的路由和可靠性步骤不依赖大模型推理，而是遵循固定协议。创造力发生在下游，在相互隔离、限定领域的上下文里，那里幻觉风险最小，失败也被控制在小范围内。

下一步

我们正在扩展这套架构，以处理新管道领域中增加的数据列。可组合性主张预测这能行得通，因为扩展意味着增加工作流模板和知识文件，而不是重建智能体。我们也在探索如何让系统从生产使用中持续改进，用自动反馈回路识别失败模式，并对子智能体知识提出针对性改进建议，所有变更始终由人工审核把关。

反直觉的教训是：在我们这套 AI 智能体系统里，最重要的组件恰恰是干活最少的那个。让编排器保持轻薄，让专家保持深厚，整个系统就会更可靠。

致谢

这项工作是团队协作的成果。参与贡献的还有：Mani Bhushan、Rahul Maliakkal、Jae Ha、Chakrapani Kumar、Vivek Tiwari 和 Amanda Yin。

The post The Thin Orchestrator: How We Made Our AI Agents More Reliable by Giving the Router Less to Do appeared first on Engineering at Meta .

查看原文