- 有时，把 AI 智能体所需的全部知识都交给它，并不是正确做法。
- 在 Meta，我们发现，刻意让数据流水线智能体的编排层保持精简，能显著提升效率和准确性：它负责路由任务并执行可靠性检查，而专门的智能体负责领域推理。
- 我们将分享自己的流程和见解，以及任何团队如何将这种做法应用于生产环境中的 AI 智能体。
我们构建了一个 1,300 行的编排器，将 20 多种工作流路由给 14 个专门的 AI 智能体。它本身不执行任何领域工作。这正是关键所在。
最初，我们部署 AI 智能体，自动化处理 Meta 推荐系统中的数据列接入流程——该流程横跨三个代码仓库、三种编程语言，最多包含六个必须保持同步的流水线阶段——当时我们和大多数团队一样：构建了一个无所不知的智能体。
它在演示中运行良好。到了生产环境，它开始产生幻觉。
解决办法不是改进提示词，也不是扩大上下文窗口，而是减少中央智能体要做的事。我们称之为精简编排器模式：路由器负责安排顺序并执行可靠性检查，把所有领域决策留给专家智能体。
我们的流水线采用配置即代码：Python 配置驱动 C++ 代码生成，生成的代码再供数据处理服务使用，最终填充分析系统。接入单个数据列需要协调修改配置注册表、后端服务和数据流水线；每一列的数据到达前最多要经过六个阶段。
我们最初的方案是使用一个单一 AI 智能体，并向它加载所有领域知识、配置架构、代码生成规则、流水线路由逻辑、验证要求，以及 10 多种数据源的数据填充模式。
智能体拥有所需的一切。这正是问题所在。
上下文超过某个阈值后，增加知识反而会降低性能，而不是提升性能。智能体会混淆不同概念，把一个子系统的字段命名约定套用到另一个子系统，或者在填充另一种数据源时使用原本只适用于特定数据源的代码生成模式。西奈山伊坎医学院 Windreich 人工智能与人类健康系的一份 预印本发现，在每批 80 项任务的情况下，编排式多智能体系统的准确率保持在 65.3%，而单智能体降至 16.6%；同时，令牌用量最多减少 65 倍。作者将这一结果归因于设计对任务的隔离，从而避免了上下文干扰。我们的经历恰好相反：单个智能体被自身掌握的知识淹没了。
我们还评估了另一种单智能体方案。每项任务都经过人工提示词工程时，其成功率为 70%–80%：工程师必须为每项具体工作编写定制系统提示词。没有这种人工引导，成功率就会降至 10%–20%。这不是提示词工程的问题，而是架构问题。
我们把系统拆分为两层：
- 确定性编排器不执行任何领域工作。它对意图进行分类、收集所需字段、运行可靠性检查，并将任务交给合适的专家智能体。它从不推理代码，从不生成配置，也从不接触代码库。它就是一个路由器。
- 十四个专门的子智能体，每个都是拥有隔离上下文的完整领域专家。架构管理智能体了解配置注册表。数据填充智能体了解如何为 10 种数据源分别生成代码。验证智能体了解构建系统和质量检查。没有任何智能体能看到全貌。这是特性，不是缺陷。
编排器对每个请求都遵循固定的 7 步协议：
- 读取相关子智能体的指令文件。
- 检查目标是否已存在（防止重复）。
- 向用户收集所需字段。
- 自动发现可推断的信息（仓库类型、现有配置）。
- 可靠性关卡检查是否存在有效警告或必须参与的审阅者。
- 委派给掌握完整上下文的子智能体。
- 处理结果并报告错误，确认成功。
第 1–5 步和第 7 步都是确定性的。只有第 6 步涉及大语言模型（LLM）推理，而且推理发生在隔离的子智能体内部，该智能体只加载自身领域知识。
一个架构上的见解是，将需要做什么与每个步骤如何执行分开。编排器通过工作流模板定义各阶段的顺序——这些确定性状态机限制了 LLM 的决策空间：
- 数据列接入： 架构 â 验证 â 数据填充 â 测试
- 事件接入： 架构 â 数据填充 â 验证 â 测试 â 事件处理
- 流水线迁移： 评估 â 规划 â 数据填充 â 验证 â 监控
每个工作流模板都以不同顺序复用同一组 14 个子智能体。我们需要支持流水线迁移这一全新用例时，没有构建新智能体，而是编写了一个新的工作流模板，以不同方式安排现有智能体。没有新增智能体代码，却具备了完整的生产能力。
每个子智能体都遵循标准化结构：
- 知识来源： 运行时要加载哪些领域文件（通常每个文件只有几千个令牌）。
- 预先收集清单： 编排器在委派前必须收集哪些信息。
- 分步工作流： 领域专属的执行计划。
- 发现模式： 如何在单体仓库中查找相关代码模式。
- 故障排查： 常见故障的错误到解决方案映射。
这种统一性意味着，添加新的子智能体是套用模板的工作，而不是从零开始的工程。第 15 个子智能体在结构上与第一个完全相同。
知识文件在子智能体执行时按需加载，而不是嵌入编排器中。我们按工作流领域整理并维护着 25 多个知识文件。知识文件更新后，下一个会话会自动使用最新版本，无需修改编排器。同一批知识文件也供我们智能体的多个平台实现使用。
新数据列的配置准备工作，手动完成需要三到四天，使用我们较早的配置驱动系统约需一天。精简编排器系统可在一小时内完成。
从更广的角度看，系统中约三分之二的变更无需大量人工修改即可落地。它通过牺牲通用性来换取深厚的领域知识，这是有意为之的架构选择。编排器是通用的，子智能体则是专家。
传统做法是让编排器成为最聪明的组件——把所有上下文都交给它，让它推理该做什么以及如何去做。这种做法在失效之前都有效；而它恰恰会在最需要它的时候失效——在大规模场景中，面对复杂的多步骤工作流以及异构子系统时。
精简编排器之所以有效，是因为它让架构边界与计算边界保持一致：
- 确定性决策保持确定性。“该由哪个子智能体处理？”这是路由决策，不是推理任务。不要为此使用 LLM。
- **上下文隔离可防止相互混淆。**负责数据源 A 的数据填充智能体永远看不到数据源 B 的模式，因此不会产生错误的幻觉。
- **故障会被限制在局部。**如果子智能体失败，编排器会重试或升级处理。故障不会破坏编排器状态，也不会污染其他子智能体的上下文。
- **系统各层都能独立改进。**更好的模型会同时提升全部 14 个子智能体的表现。更新知识文件后会立即生效。新的工作流模板无需改动智能体，就能解锁新能力。没有任何单一组件需要承担全部负荷。
这种模式并非数据流水线专用。任何构建生产环境 AI 智能体的团队都能从中受益：
- **将路由与推理分开。**如果编排器正在做领域决策，它承担的工作就太多了。路由应当是确定性的：关键词匹配、意图分类、字段收集。把所有领域推理交给隔离的子智能体。
- **将子智能体设计成结构统一的专家。**每个子智能体都应采用相同结构：知识来源、必需输入、执行步骤、错误处理。这样，添加新能力就成为套用模板的工作，而不是架构变更。
- **通过工作流模板扩展，而不是新增智能体。**需要新的用例时，首先问自己：能否以不同方式安排现有智能体？如果无法在不同工作流中复用智能体，说明它们与特定用例耦合得太紧。
- **在运行时加载知识，而不是在构建时加载。**将知识嵌入编排器后，每次更新都需要重新部署。按需加载后，更新会立即在所有平台生效。
- **明确划分确定性与概率性边界。**对每个组件都要判断：这是路由决策（确定性）还是推理任务（概率性）？编排器应处于一侧，子智能体处于另一侧。不要混在一起。
支持精简编排器的最有力论据，是另一种方案的失效方式。重量级编排器一旦产生幻觉，错误就会扩散到所有下游环节：它可能路由给错误的智能体、收集错误的字段，或跳过可靠性检查。精简编排器几乎不给幻觉留下空间，因为其路由和可靠性步骤不依赖 LLM 推理。它遵循固定协议。创造性工作发生在下游、彼此隔离且限定领域范围的上下文中，在那里幻觉风险最低，故障也能被限制在局部。
我们正在将这种架构扩展到新的流水线领域，以应对数据列数量的增长。组合式设计的论点预测这种扩展会奏效，因为扩展意味着增加工作流模板和知识文件，而不是重建智能体。我们也在探索系统如何从生产环境的使用中持续改进：利用自动反馈循环识别故障模式，并为子智能体知识提出有针对性的改进建议，任何变更始终都须经过人工审核。
这个反直觉的经验是：我们的 AI 智能体系统中最重要的组件，恰恰是做事最少的那个。让编排器保持精简，让专家保持专业深度，整个系统就会更可靠。
这项工作由团队共同完成。其他参与这项工作的人员包括： Mani Bhushan、Rahul Maliakkal、Jae Ha、Chakrapani Kumar、Vivek Tiwari 和 Amanda Yin。
这篇文章 精简编排器：我们如何通过让路由器少做些事，使 AI 智能体更加可靠 最初发表于 Meta 工程博客。