Meta 的瘦调度器架构：为什么让中心智能体知道得越少，系统反而越可靠？

给大模型喂的上下文越多，它干活就越聪明吗？

Meta 的工程团队刚刚用真金白银踩过一个大坑。

在 Meta 的推荐系统里，上线一个数据列是一件繁琐的重体力活。 它横跨三个代码仓库、三种编程语言，还要穿过六个必须严格同步的处理阶段。 从写 Python 配置，到生成 C++ 代码，再推给数据处理服务，最后流进分析系统。 以前工程师纯靠手工配置，上一条新数据要花整整三到四天。

看到大模型火了，团队最直接的直觉就是： 咱们做一个全知全能的超级智能体吧。

他们把整个系统能找到的所有资料全塞了进去： 配置规范、C++ 代码生成规则、管线路由逻辑、校验标准，再加上十几个数据源的填充模板。 这个智能体手里握着系统需要的一切知识。 在内部演示环节，它表现极其惊艳，有问必答。

然后，一放进真实的生产环境，系统当场崩了。

这个全能智能体开始疯狂产生幻觉。 而且上下文喂得越多，它的表现反而越糟糕。 它把子系统 A 的字段命名规范，胡乱套到了子系统 B 身上。 或者拿数据源 X 的代码模板，去强行写数据源 Y 的入库逻辑。 各种概念在它的脑子里疯狂打架、互相污染。

是不是提示词没写好？ Meta 的工程师试过另一种单智能体方案。 如果让工程师为每一个具体任务单独人工定制一段提示词，系统的成功率能维持在 70% 到 80%。 可是一旦把人工手把手的保姆提示词撤掉，让它自主跑，成功率直接暴跌到 10% 到 20%。 工程师每天的工作，变成了给大模型写定制提示词擦屁股。

这根本不是提示词的问题。这是系统架构出了硬伤。

西奈山人工智能与人类健康系（Windreich Department of Artificial Intelligence and Human Health）的一篇论文专门验证过这种崩溃。 在连续处理 80 个任务的批处理中，把所有任务全压给一个单智能体，它的准确率会从前面的水平一路垮塌到 16.6%。 而一旦把任务隔离给受编排的多智能体系统，准确率就能维持在 65.3%，同时把 token 消耗直接砍掉了最高 65 倍。 原因很残酷：单个大模型被自己的海量知识给淹死了。

Meta 是怎么解决的？ 他们既没有去买更大的上下文窗口，也没有写更玄学的提示词。 他们的做法恰恰相反： 剥夺中央调度器的智力，给它减负。

团队搭建了一套被称为瘦调度器（Thin Orchestrator）的架构。 整个中央调度器，只有 1300 行代码。 由它来管理 20 多个工作流，向下调度 14 个专职智能体。

这 1300 行代码最绝的地方，是它自己不做任何业务推演。 它不分析代码。 它不生成配置。 它甚至连业务代码库碰都不碰。 它就是一个纯粹的路由器。

每来一个任务，这个瘦调度器只跑固定死板的七步协议： 第一步，读取对应专职智能体的规则说明文件。 第二步，检查目标是否已存在，防止重复干活。 第三步，向用户收集必要的输入字段。 第四步，自动推断环境信息，比如仓库类型和已有配置。 第五步，过一道可靠性安全闸，排查警告和审批人要求。 第六步，把打包好的上下文移交给专职智能体。 第七步，接收处理结果，向用户报错或者确认成功。

这七个步骤里，第一步到第五步，以及第七步，全都是确定性的死代码。 从头到尾只有第六步，才会触发大语言模型去推理。 而且这个推理，只在那个被完全隔离的专职智能体沙盒里发生。

这 14 个专职智能体，每个人都是只懂自己那一点的绝对专家。 管配置的专职智能体，只认配置注册表。 管代码生成的，只懂 10 个数据源的代码模板。 管校验的，只懂构建系统和质量检查。 没有任何一个智能体能看到全貌。 这正是整个系统最关键的设计。 代码生成智能体根本看不到配置注册表的细节，它就算想胡思乱想，也完全没有机会把配置命名污染到 C++ 代码里。

那要是业务增加了新场景，比如要做整个管线迁移，怎么办？ 按过去的惯性，是不是又要重新训一个模型，或者重新写一套庞大的智能体？ Meta 的做法极其聪明： 他们不写新的智能体，只写工作流模板。

工作流模板就是一个确定性的有限状态机。 上线数据列，流程是：配置结构、校验、填充、测试。 管线迁移，流程是：评估、规划、填充、校验、监控。 他们把现有的 14 个专职智能体重新排列组合，串进新状态机里。 零行新增智能体代码，一个全新的复杂业务能力直接上线。

每个专职智能体加载的领域知识，被拆成了 25 个独立文件，通常只有几千 token，运行时按需读取。 修改一个知识文件，下一次调用立刻生效，调度器完全不需要重新部署。

这套系统上线之后的结果呢？ 过去人工配置一个新数据列要三到四天，早期自动化工具要一天左右。 现在这套瘦调度器系统跑完，不到一个小时。 而且系统产出的代码和配置修改，大约三分之二完全不需要人类工程师插手，直接合入主分支。

做复杂大模型工程，所有人本能的第一反应，都是把中央中枢做成最聪明的那个大脑，恨不得把所有业务逻辑都塞进它的上下文里。 但真实世界的工程规律往往很讽刺。 一个庞大而聪明的中央大模型一旦产生幻觉，下游的所有路由、字段收集和安全检查就会全线雪崩。 最终让整套 AI 系统稳定跑通的，恰恰是那个只写了 1300 行代码、老老实实当路由器的调度层。 确定性的规则交给确定性的代码。 不确定性的推理，关在窄门里自生自灭。