---
id: "mb-20261020-7df5cc"
kind: "deep"
title: "Meta 的瘦调度器架构：为什么让中心智能体知道得越少，系统反而越可靠？"
description: "Meta 推荐系统团队在自动化数据管线时发现，把所有代码与规范塞给单个大模型会导致严重的上下文交叉污染。他们用 1300 行确定性代码构建了只做路由与校验的瘦调度器，将推理任务隔离给 14 个专职智能体，成功将 3 到 4 天的手工流程压缩到 1 小时内，三分之二的改动无需人工介入。"
domain: "software"
domain_label: "软件与工程"
canonical_url: "https://mubeitech.com/deep/mb-20261020-7df5cc"
markdown_url: "https://mubeitech.com/deep/mb-20261020-7df5cc/markdown"
json_url: "https://mubeitech.com/api/interpretations/mb-20261020-7df5cc"
topic: "Meta 的瘦调度器架构：为什么让中心智能体知道得越少，系统反而越可靠？"
source_type: "generated"
status: "published"
generated_at: "2026-10-20 11:53:39"
frame_type: ["机制"]
legal_anchor_count: 0
transcript_citation_count: 0
---

# 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 行代码、老老实实当路由器的调度层。
确定性的规则交给确定性的代码。
不确定性的推理，关在窄门里自生自灭。

_Canonical: <https://mubeitech.com/deep/mb-20261020-7df5cc> · Source: 墓碑科技 MUBEITECH (mubeitech.com)_
_Rendered by mubei-terminal._