Meta 如何通过精简编排器提高 AI 智能体可靠性

有时，让 AI 智能体掌握所需的全部知识并不是正确的做法。
在 Meta，我们刻意让数据流水线智能体的编排层保持精简，从而显著提高了效率和准确性：编排层负责分派工作并执行可靠性检查，而由专用智能体进行领域推理。
我们将分享自身的实践过程和见解，以及任何团队如何将这一方法应用于生产环境中的 AI 智能体。

我们构建了一个 1,300 行代码的编排器，将 20+ 个工作流分派给 14 个专用 AI 智能体。它本身完全不处理领域工作。这正是设计的核心。

我们最初部署 AI 智能体，以自动完成 Meta 推荐系统中数据列的接入工作时，采用了大多数团队的做法：构建一个无所不知的智能体。这一接入流程横跨三个代码仓库、三种编程语言，以及多达六个必须保持同步的流水线阶段。

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

解决办法不是更好的提示词，也不是更大的上下文窗口，而是减少中央智能体的职责。我们将其称为精简编排器模式：由一个路由器负责执行顺序和可靠性检查，并将所有领域决策交给专用智能体。

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

我们的流水线采用配置即代码模式：Python 配置驱动 C++ 代码生成，生成的代码用于数据处理服务，后者再向分析系统填充数据。接入一个数据列，需要协调修改配置注册表、后端服务和数据流水线，而每个数据列在数据到达之前都要经过多达六个阶段。

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

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

上下文超过某个阈值后，新增知识非但没有改善表现，反而使其下降。智能体会混淆不同概念，将一个子系统的字段命名约定应用到另一个子系统，或在从某个数据源填充数据时，使用原本适用于另一个数据源的代码生成模式。西奈山 Windreich 人工智能系的一篇预印本与人类健康领域相关，研究发现，在每批 80 项任务的情况下，经过编排的多智能体系统保持了 65.3% 的准确率，而单智能体的准确率降至 16.6%，同时 token 用量最多减少了 65 倍。作者将其归因于该设计对任务的隔离，这种隔离避免了上下文干扰。我们当时经历的恰恰相反：单个智能体淹没在自身的知识中。

我们还评估了另一种单智能体方案。在针对每项任务进行人工提示词工程的情况下，其成功率为 70-80%：工程师必须为每项具体工作编写定制的系统提示词。没有这种手把手的指导，成功率就会降至 10-20%。这不是提示词工程问题，而是架构问题。

方法：精简路由器搭配专用执行智能体

我们将系统分为两层：

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

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

读取相关子智能体的指令文件。
检查目标是否已经存在（防止重复）。
收集用户提供的必填字段。
自动发现可推断的信息（仓库类型、现有配置）。
可靠性关卡检查是否存在有效警告或必须参与的审核者。
委派任务给子智能体，并提供完整上下文。
处理结果并呈现错误，确认成功。

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

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

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

列接入：模式 → 验证 → 数据填充 → 测试
事件接入：模式 → 数据填充 → 验证 → 测试 → 事件处理
流水线迁移：评估 → 规划 → 数据填充 → 验证 → 监控

每个工作流模板都以不同的顺序复用同一组 14 个子智能体。当我们需要支持流水线迁移这一全新用例时，我们没有构建新智能体，而是编写了一个新的工作流模板，以不同的顺序编排现有智能体。没有新增任何智能体代码，却具备完整的生产能力。

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

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

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

知识文件在子智能体执行时按需加载，而不是嵌入编排器中。我们按工作流领域组织并维护着 25+ 个知识文件。知识文件更新后，下一个会话会自动使用最新版本，无需更改编排器。同一套知识文件可供我们的智能体在多个平台上的实现使用。

成果

为一个新列准备配置，手动操作需要三到四天，使用我们早期的配置驱动系统则需要大约一天。轻量级编排器系统可在不到一小时内完成。

从更广的角度来看：该系统约三分之二的变更无需人工大幅修改即可落地。它通过牺牲通用性来换取深厚的领域知识，从而达到这一水平，这是刻意做出的架构选择。编排器是通用的；子智能体则是专家。

为什么这种方式有效（而重量级编排器不行）

传统做法是让编排器成为最智能的组件：为它提供所有上下文，让它推理该做什么以及如何做。这种方式起初有效，但终究会失效，而且恰恰会在你最需要它的时候失效：规模扩大、工作流涉及复杂的多步骤操作、需要跨异构子系统运行时。

轻量级编排器之所以有效，是因为它让架构边界与计算边界保持一致：

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

如何将这种方式应用于你的 AI 智能体

这种模式并非仅适用于数据流水线。任何构建生产级 AI 智能体的团队都能从中受益：

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

支持轻量级编排器的最有力论据，是另一种方案的故障模式。当重量级编排器产生幻觉时，错误会传播到所有下游环节：它会将任务路由给错误的智能体、收集错误的字段，或跳过可靠性检查。轻量级编排器几乎不给幻觉留下空间，因为它的路由和可靠性步骤不依赖 LLM 推理。它遵循固定协议。创造性工作在下游开展，处于相互隔离、限定领域范围的上下文中，幻觉风险得以降至最低，故障影响也被限制在局部。

下一步

我们正在扩展这一架构，以应对新流水线领域中数据列数量的增加。组合式设计理念预示，这种扩展会奏效，因为扩展意味着增加工作流模板和知识文件，而不是重建智能体。我们也在探索系统如何通过生产环境中的使用持续改进，利用自动化反馈循环识别故障模式，并提出有针对性的子智能体知识改进建议，同时始终将人工审核作为任何变更的前置条件。

这个经验有些反直觉：在我们的 AI 智能体系统中，最重要的组件恰恰是工作量最少的那个。让编排器保持轻量，让专业智能体深耕各自领域，整个系统就会更加可靠。

致谢

这项工作是团队共同努力的成果。其他参与这项工作的人员包括： Mani Bhushan、Rahul Maliakkal、Jae Ha、Chakrapani Kumar、Vivek Tiwari 和 Amanda Yin。

文章轻量级编排器：我们如何通过减少路由器的工作来提高 AI 智能体的可靠性最初发表于 Meta 工程博客。