10 个关键问题 Q&A
-
Q：什么是轻量编排器？ A：只负责路由、流程管控、可靠性校验的确定性调度层，不做任何领域 LLM 推理，领域任务交给隔离的专精子智能体。 -
Q：Meta 为什么放弃单体全能 AI 智能体？ A：上下文超过阈值后知识互相串扰，幻觉频发；单纯优化提示词、扩大上下文窗口无法解决架构缺陷。 -
Q：编排器 7 步流程是什么？ A：读指令文件→查重防重复→收集必填字段→自动信息发现→可靠性关卡→委派子智能体→处理结果与报错。 -
Q：子智能体之间是否互通上下文？ A：不互通，上下文隔离，避免不同领域规则、命名、代码范式互相污染。 -
Q：新增业务场景，需要开发新智能体吗？ A：多数情况不需要，新增工作流模板，重新编排现有子智能体调用顺序即可。 -
Q：知识文件如何更新？要不要重新部署编排器？ A：子智能体执行时按需加载知识文件；更新知识库无需发布编排器，即时生效。 -
Q：轻量编排和重型编排器最大差别？ A：重型编排器本身做领域推理，容易把错误向下传导；轻量编排器是确定性路由，几乎不依赖 LLM，幻觉面极小。 -
Q：这套架构适合哪些场景？ A：适合复杂多步骤生产 Agent，比如数据流水线、配置变更、代码自动化，不限于 Meta 的数据列接入场景。 -
Q：子智能体的标准化结构包含哪些部分？ A：知识源、前置收集清单、分步流程、仓库发现规则、错误故障映射。 -
Q：这套架构的核心取舍是什么？ A：编排器保留通用性，牺牲通用推理能力；子智能体放弃全局视野，换取垂直领域深度和稳定性。
发布于：2026 年 10 月 19 日 发布栏目：Meta 工程博客 AI 研究、机器学习应用板块 作者：Plawan Rath、Akhil Jindal、Ashwini Verma
有时候，给一个 AI 智能体灌入它需要的全部知识，本身就是错的思路。
在 Meta，我们刻意把数据流水线智能体的编排层做 “薄”，以此显著提升系统效率与准确率：编排器只负责调度任务、执行可靠性校验，而领域相关的推理工作交给各类专精智能体完成。 本文将分享我们的落地流程、实践心得，以及其他团队如何把这套模式应用到生产级 AI 智能体上。
我们实现了一段仅 1300 行代码的编排器，它把 20 余种工作流路由分发到 14 个专精 AI 智能体；编排器本身不做任何领域推理—— 这正是设计的核心。
最早，我们部署 AI 智能体，用来自动化 Meta 推荐系统的数据列接入流程。这套流程横跨 3 个代码仓库、3 种编程语言，最多包含 6 个需要同步对齐的流水线阶段。和大多数团队一样，我们最初做了一个 “全知全能” 的单体智能体。 它在演示环境里表现良好，但上线生产之后，开始频繁出现幻觉问题。
解决办法不是优化提示词、扩大上下文窗口，而是让中心智能体少干活。我们称之为轻量编排器模式（thin orchestrator pattern）：一个路由组件，只负责流程顺序管控和可靠性校验，所有领域决策交给专精智能体。
问题：上下文越多，效果越差
我们的流水线采用 “配置即代码”：Python 配置驱动 C++ 代码生成，供给数据处理服务，最终写入分析系统。接入一条新数据列，需要同步修改配置注册表、后端服务与多条数据流水线；一条数据列最多要走完 6 个阶段，数据才能正常落地。
第一版方案是单体智能体，内置全部领域知识、配置范式、代码生成规则、流水线调度逻辑、校验规则，以及十多个数据源的数据填充规范。 这个智能体看似应有尽有，而这恰恰是问题所在。
当上下文体量超过某个阈值后，新增知识反而会拖累性能。智能体会混淆不同概念：把 A 子系统的字段命名规范套到 B 子系统，或是把适配某一个数据源的代码生成逻辑，错误用在另一个数据源上。《自然》子刊的一项研究指出：在 80 个任务的批量场景下，多智能体编排系统准确率可达 65.3%，而单体智能体仅有 16.6%，同时 Token 消耗最高可降至原来的 1/65。研究归因于任务隔离设计，避免了上下文互相干扰。而我们遇到的，恰恰是反面情况：单体智能体被海量知识淹没。
我们还测试了另一种单体方案：如果工程师为每一项任务手工定制系统提示词，成功率在 70%–80%；一旦去掉这种人工加持，成功率直接跌到 10%–20%。这不是提示词工程的问题，而是架构问题。
方案：轻量路由层 + 专精工作智能体
系统拆分为两层：
- 确定性编排器
完全不做领域推理。它识别意图、收集必填参数、执行可靠性校验、把任务委派给对应专精智能体。它不理解代码、不生成配置、不操作代码仓库，它只做路由。 - 14 个专精子智能体
每一个都是独立领域专家，上下文互相隔离。配置范式智能体只懂配置注册表；数据填充智能体只负责为 10 类数据源生成对应代码；校验智能体熟悉编译构建系统与质量检查。没有任何一个子智能体掌握全局全貌 —— 这是设计特性，而非缺陷。
编排器对每一条请求，都遵循固定的 7 步协议：
-
读取目标子智能体的指令文件 -
检查目标资源是否已存在，防止重复创建 -
向用户收集必填字段 -
自动推导可推断信息（仓库类型、已有配置等） -
可靠性关卡：检查是否存在告警、是否需要审批人 -
将完整上下文委派给子智能体执行 -
接收执行结果、抛出错误、确认任务完成
第 1–5 步、第 7 步都是确定性逻辑；只有第 6 步会调用大模型推理，并且推理发生在独立隔离的子智能体内，仅加载它自身领域的知识。
实现成果：复用工作流模板，而非新增智能体
一个关键架构洞察：把需要做什么和每一步怎么做解耦。编排器通过工作流模板定义阶段顺序，也就是一套约束大模型决策空间的确定性状态机：
-
数据列接入：范式定义 → 校验 → 数据填充 → 测试 -
事件接入：范式定义 → 数据填充 → 校验 → 测试 → 事件处理 -
流水线迁移：评估 → 方案规划 → 数据填充 → 校验 → 监控
每一套模板，都是复用这 14 个子智能体、只是调换执行顺序。当我们需要支持流水线迁移这个全新场景时，我们没有开发新智能体，只是写了一份新的工作流模板，重新编排已有智能体的调用顺序。零新增智能体代码，直接具备生产能力。
所有子智能体采用统一结构：
-
知识源：运行时加载哪些领域文档（通常每份几千 token） -
前置收集清单：编排器在委派前必须集齐的参数 -
分步执行流程：领域专属执行计划 -
自动发现规则：如何在单体仓库检索相关代码范式 -
故障排查：常见报错和对应的修复方案
标准化意味着新增子智能体属于模板化开发，不是从零搭建架构。第 15 个专精智能体，结构和第一个完全一致。
知识文件是子智能体执行时按需加载，不是硬编码在编排器内部。我们维护 25 + 份按领域划分的知识文档；文档更新后，新会话自动读取最新版本，无需改动、重新发布编排器。同一份知识文件还可以供给平台上多个版本的智能体使用。
落地效果
手动新增一条数据列的配置准备，需要 3–4 天；旧的配置驱动系统大约需要 1 天；这套轻量编排架构，耗时缩短到1 小时以内。 另外，大约三分之二由系统产出的变更，不需要人工大幅修改。这套效果来自一个主动的架构取舍：牺牲通用能力，换取深度领域专精。编排器追求通用调度，子智能体深耕垂直领域。
为什么这套方案可行，而重型编排器不行
传统思路，是把编排器做成系统里最 “聪明” 的组件：灌入全部上下文，让它自主判断要做什么、怎么做。这种模式早晚会失效，并且往往是在规模化、多步骤复杂工作流、跨异构子系统的场景下崩盘。
轻量编排器的优势，在于架构边界和计算边界对齐：
-
确定性决策保持确定性：“该交给哪个子智能体” 属于路由判断，不是推理任务，不用大模型来做 -
上下文隔离杜绝知识串扰：数据源 A 的填充智能体，永远看不到数据源 B 的代码范式，不会错用规则产生幻觉 -
故障隔离：某个子智能体失败时，编排器可以重试或者上报，故障不会污染编排器状态、也不会干扰其他子智能体 -
分层独立迭代：模型升级，14 个子智能体同时受益；知识文件修改即时生效；新增工作流模板就能解锁新能力，不用改动智能体。不再由单个组件承载全部复杂度
如何在你的 AI 智能体项目落地这套模式
该模式不局限于数据流水线，所有开发生产级智能体的团队都可以参考：
- 路由逻辑和推理逻辑分离
如果你的编排器还在做领域判断，说明它负担过重。路由尽量做成确定性逻辑：关键词匹配、意图分类、参数收集。所有领域推理下沉到隔离的子智能体。 - 子智能体设计成结构统一的专精单元
每个子智能体拥有相同框架：知识源、入参清单、执行步骤、错误处理。新增能力变成模板化工作，而不是架构重构。 - 优先用工作流模板扩展，而不是新增智能体
遇到新场景先自问：能不能重新组合已有智能体的执行顺序？如果智能体和场景强耦合、无法复用，说明耦合度太高。 - 知识运行时按需加载，不要打包在构建产物里
知识嵌入编排器，每次更新都要重新部署；按需加载，修改即时生效、多平台共享。 - 明确划分确定性边界与概率推理边界
给每一个组件划清定位：是路由调度（确定性），还是领域推理（大模型概率输出）。编排器归前者，子智能体归后者，不要混在一起。
支持轻量编排模式最有力的理由，来自反面方案的故障风险：重型编排器一旦幻觉，错误会向下传导，选错子智能体、收集错误参数、跳过可靠性校验。而轻量编排器遵循固定流程，路由和校验环节不依赖 LLM 推理，几乎没有幻觉空间；创造性推理交给下游隔离的领域智能体，幻觉风险更低、故障范围可控。
后续规划
我们正在把这套架构扩展到更多流水线领域，支撑更多数据列接入。这套组合式架构的核心假设是：扩容只需要新增工作流模板和知识文档，而不是重构智能体。我们同时在探索生产侧持续自优化机制：搭建自动化反馈回路，识别失败模式、定向更新子智能体知识库，所有变更都保留人工审核关卡。
一个反直觉的结论：AI 智能体系统里最重要的组件，恰恰是干活最少的那一个。让编排器保持轻薄，让专精智能体深耕领域，整个系统会变得更加可靠。
致谢
本项目是团队协作成果，其他贡献者包括：Mani Bhushan、Rahul Maliakkal、Jae Ha、Chakrapani Kumar、Vivek Tiwari、Amanda Yin。