多 Agent 总串台？Meta 把总控缩到 1300 行

Agent 一开始很好用：给它接几个工具，塞点项目文档，再让它找两个子 Agent 帮忙。等任务变成“查代码、改配置、跑验证、提 PR”这一串之后，问题会开始变味。

它不是完全不会做，而是偶尔把 A 服务的规则用到 B 服务；该问你的字段没问，先跑了；本来只是选路由，顺手替你拍了一个业务板。你越往总控里塞说明、示例和兜底提示，下一次错法往往越新。

Meta 昨天公开了一套很反直觉的生产做法：他们没有继续把总控训得更懂业务，而是把它缩成约 1,300 行的确定性路由层。这个总控负责调度 20 多条工作流、调用 14 个专项子 Agent，但不做任何领域推理。官方复盘在这里。

这篇不准备把“多 Agent”再讲一遍。只想把其中最值得抄的一刀拆出来：总控该做什么，哪些事必须从总控手里拿走。

不是 Agent 太笨，是总控管得太多

Meta 的场景是数据列接入。一次改动会横跨配置注册、代码生成、数据服务和分析系统，涉及三套仓库、三种语言，以及最多六个必须同步的流水线阶段。

他们最开始也选了常见路线：给一个中心 Agent 加齐配置 schema、代码生成规则、路由逻辑、校验要求和十多个数据源的习惯。演示能跑；进生产后，问题来了。

某个数据源的字段命名规则会串到另一个数据源；适用于 A 的生成方式被带到 B；为了救一条任务，工程师得重新手写专用提示词。Meta 记录的单 Agent 方案，在人工为每个任务精调提示词时成功率能到 70%～80%，没有这层手工照看时会落到 10%～20%。

这里容易误判成“上下文还不够”或者“模型还得换”。Meta 的判断是：边界放错了。一个中心 Agent 同时负责理解需求、补字段、选流程、判断业务规则、生成内容和验收结果，它拿到的上下文越多，互相污染的机会也越多。

图注：Meta 官方工作流图。图中展示“列接入、事件接入、流水线迁移”复用同一批专项 Agent；来源：Meta Engineering。

可以把它想成值班总机。总机应该确认来电属于哪一类、信息齐不齐、有没有风险提示，然后接给对应团队。总机不该同时兼职数据库专家、构建工程师和业务审计员。兼职越多，转错线的代价越大。

Meta 的分法：总控只做确定的事

他们把系统划成两层。

• 薄总控：识别请求、收集必填字段、自动发现已有信息、做可靠性门禁、按流程派工、汇总结果和报错。
• 专项子 Agent：只带自己的领域知识，负责 schema、代码生成、数据填充、验证等具体推理与执行。

关键不在“有 14 个 Agent”，而在第一层主动放弃了业务聪明。总控不改代码、不写配置、不判断某个数据源该用哪一种生成模式。它是路由器，也是流程警察。

Meta 把一次请求固定成七步：

1. 读取当前专项 Agent 的说明；
2. 检查目标是否已存在，先挡住重复操作；
3. 收集这个任务不可缺的字段；
4. 自动发现能从仓库或现有配置推断出的信息；
5. 检查告警、必需 reviewer 等可靠性门禁；
6. 把完整但只与该领域有关的上下文交给专项 Agent；
7. 接住结果与错误，确认是否真的完成。

前五步和第七步都尽量写成确定规则；只有第六步留给模型推理。这个分界很朴素：“该找谁”和“能不能继续”通常有规则，“具体怎么做”才需要模型判断。

很多系统恰好反着来。它们让总控先读一大包文档，要求模型自己判断该不该问、该不该停、该叫哪个工具，然后再让它做领域活。出错时，你很难知道是路由错了、字段缺了，还是领域推理真的错了。

先别重构：用这张表给现有总控做体检

如果你已经有一个负责“调度一切”的 Agent，不需要今天就拆成十几个子 Agent。先逐项看它的职责。

总控正在做的事	应该留下吗	更合适的去处
判断用户请求属于哪条固定流程	留下	显式路由规则或受限分类器
检查目标是否已经存在、字段是否完整	留下	预检与状态查询
判断是否有高风险告警、是否需要人工确认	留下	确定性门禁
根据业务规则生成 SQL、配置或代码	拿走	对应领域的专项 Agent
同时携带所有服务的文档“以备不时之需”	拿走	运行时按需加载到专项 Agent
新增一种任务时复制一套新 Agent	先停一下	优先新增流程模板，复用已有专项 Agent

表里最容易被忽视的是“按需加载”。Meta 维护了 25 份以上的知识文件，但不把它们压进总控。执行哪个专项任务，才加载那一小部分。文档更新后，下一次运行自然拿到新版本，也不用为了改一段知识重新改总控。

这会让排障路径变短很多。一个专项任务失败，先看它收到的领域上下文、执行步骤和工具返回；你不用从一团全局提示词里猜它是不是偷看了不该看的规则。

“复用流程”比“再造一个 Agent”更值钱

Meta 的另一个做法是把流程模板和 Agent 本体拆开。列接入、事件接入、流水线迁移的步骤顺序不同，但可以复用同一批专项 Agent。

这给实际搭系统的人一个很实用的判断题：来了一个新需求时，先别问“要不要新建 Agent”，先问“现有的专业能力换个顺序能不能完成”。

能完成，就加一份流程模板：把哪些步骤是必经、哪些需要人工门禁、失败后回到哪里写清楚。不能完成，再补一个只负责新领域的专项 Agent。这样长出来的系统，新增场景是在拼积木，不是在养一堆名字很像、提示词略有不同的机器人。

图注：根据 Meta 官方结果图的公开指标重绘。约 70% 无需逐任务提示词的成功率、约 95.5% 上线评测分与约 0.2% 生产回退率来自 Meta；这是官方生产数据，不是本文实测。

Meta 给出的结果也说明了这套设计不是为了架构好看：配置准备原本靠人工要三到四天，之前的配置系统约一天，薄编排器版本可以在一小时内完成；约三分之二的改动无需明显人工修改就能落地。它们适用的是 Meta 自己的数据管道，数字不能直接搬到你的项目 KPI 上，但失败模式很有普适性：中心层一旦替所有人做领域判断，错误会沿着后续步骤一起扩散。

这套做法不等于“多拆就更好”

薄总控也不是把复杂度变没了。你要为每个专项 Agent 写清输入、可加载的知识、执行步骤、常见错误和交付验收；流程模板也得被测试。拆得太细而没有稳定接口，只会把一个大提示词换成十个互相推锅的小提示词。

有三种场景先别急着拆：

• 任务本身只有一两步，错误成本低，单 Agent 已稳定运行；
• 你还没能说清每个子任务的输入和完成条件；
• 子任务之间高度依赖同一段实时推理，硬隔离反而要反复传递关键信息。

真正值得拆的信号，是你已经开始靠“在总提示词里再加一条提醒”救问题，而且同类错误仍然轮换出现。那时先把总控的职责画出来：哪些是确定性的流程决定，哪些才是概率性的领域判断。前者尽量固化，后者才交给模型。

总控不必最懂业务。它最该擅长的，是让真正懂业务的那个 Agent 在正确的时刻、拿着正确的一小段上下文干活。

你现在的 Agent 系统里，哪一项本来应该是确定规则，却还在让模型临场猜？

小岛AI