Meta 最近在工程博客里承认了一件很多做 Agent 的人都遇到过的事：
他们先做了一个”什么都懂”的 Agent。演示时一切正常，上了生产就开始幻觉。
最后的解法不是换更好的提示词，也不是换更大的上下文窗口，而是让中间那个 Agent 少干点活。
10 月 19 日，Meta 的三位工程师 Plawan Rath、Akhil Jindal、Ashwini Verma 把这套架构写了出来，起名叫”薄编排器”（Thin Orchestrator）。这篇把它拆开讲：问题出在哪，架构怎么分工，为什么有效，什么时候不该用，以及小团队怎么照着做。
一、问题：给的知识越多，结果越差
Meta 要自动化的场景是：在推荐系统里接入一个新的数据字段。
听起来简单，实际上要横跨 3 个代码仓库、3 种编程语言，最多经过 6 个必须保持同步的管线阶段。他们的管线是”配置即代码”：Python 配置驱动 C++ 代码生成，生成的代码喂给数据处理服务，处理服务再写进分析系统。
第一版方案和很多团队一样：做一个 Agent，把所有东西都塞给它。领域知识、配置 schema、代码生成规则、管线路由逻辑、校验要求，还有 10 多个数据源各自的填充模式。
原文有一句很扎心：“这个 Agent 拥有它需要的一切。问题就出在这里。”
上下文超过某个阈值后，多加的知识不但没帮忙，反而让表现变差。Agent 开始知识串味：把一个子系统的字段命名规则用到另一个子系统上，或者从 B 数据源取数时套用了 A 数据源的代码生成模式。
他们还试过另一种单 Agent 方案。工程师给每个任务手写一份定制的系统提示时，成功率是 70–80%；不手写，成功率就掉到 10–20%。
Meta 的结论是：“这不是提示工程问题，是架构问题。”
图 1：从「什么都懂」的单体 Agent，到薄编排器加 14 个专家 Agent。由作者根据原文绘制。来源：Meta Engineering《The Thin Orchestrator》，发布于 2026 年 10 月 19 日。
二、新架构：编排器只管路由，专家只管干活
整个系统被拆成两层。
第一层：确定性编排器
大约 1300 行代码，负责路由 20 多个工作流。
它的职责很窄：分类意图、收集必填字段、跑可靠性检查、把任务交给对的专家。原文的说法是：它从不推理代码，从不生成配置，从不碰代码库。“它就是个路由器。“
第二层：14 个专家 Agent
每个专家都是一个领域的完整专家，有自己隔离的上下文。
- Schema 管理 Agent 懂配置注册表
- 填充 Agent 知道怎么为 10 个数据源分别生成代码
- 校验 Agent 懂构建系统和质量检查
**没有任何一个 Agent 能看到全貌。**原文说：“这是特性，不是 bug。“
每个请求都走同一套 7 步协议
- 读取对应专家的说明文件
- 检查目标是否已经存在，防止重复
- 向用户收集必填字段
- 自动发现能推断出来的信息，比如仓库类型、现有配置
- 可靠性闸门：检查有没有生效中的警告，或者是否需要特定的人审核
- 把任务连同完整上下文交给专家
- 处理结果、暴露错误、确认成功
关键在这里：第 1–5 步和第 7 步都是确定性的，只有第 6 步用到大模型，而且是在一个只加载了本领域知识的隔离上下文里。
图 2：7 步协议里只有第 6 步用到大模型；三个工作流模板复用同一组专家。由作者根据原文绘制。来源：Meta Engineering《The Thin Orchestrator》，发布于 2026 年 10 月 19 日。
三、加新能力时写模板，不写新 Agent
我认为这是整篇最值得抄的设计：把”要做什么”和”每一步怎么做”分开。
“要做什么”由工作流模板定义。原文称之为”确定性状态机”，用来约束大模型的决策空间。文中举了三个例子：
- 字段接入：Schema → 校验 → 填充 → 测试
- 事件接入：Schema → 填充 → 校验 → 测试 → 事件处理
- 管线迁移：评估 → 规划 → 填充 → 校验 → 监控
三个模板复用的是同一组 14 个专家，只是顺序不同。
管线迁移是一个全新的场景。Meta 没有为它写新的 Agent，只写了一个新模板，把现有专家重新排了顺序。原文：“零新增 Agent 代码，完整的生产能力。”
每个专家的结构都一样，包括 5 个部分：
- 知识来源：运行时加载哪些领域文件，每个通常几千 token
- 预收集清单：分派前编排器必须先收集哪些信息
- 分步工作流：这个领域具体怎么执行
- 发现模式：怎么在 monorepo 里找到相关代码
- 故障排查：常见错误对应的解决办法
所以加一个新专家是”套模板”，不是从零开始做工程。原文说，第 15 个专家和第 1 个在结构上一模一样。
**知识不写死在编排器里。**他们维护着 25 个以上的知识文件，在专家执行时按需加载。知识文件一更新，下一次会话自动用上最新版本，编排器一行都不用改。
四、效果
Meta 给出了两组数字。先说清楚：这两组都是 Meta 在这篇工程文章里的自述，我尚未找到独立复现；文章也没有交代统计了多少个字段或改动、在什么时间段统计。
- 新字段的配置准备时间：纯手工要 3–4 天，他们之前的配置驱动系统要大约 1 天，薄编排器系统不到 1 小时。
- 改动质量：原文的说法是，约三分之二的改动落地时”没有经过大的人工修改”（without significant human edits）。
第一组的对比对象是 Meta 自己的两种旧做法（纯手工、之前的配置驱动系统），不是别的 Agent 方案。第二组没有给对照基线，也没说「大的人工修改」怎么界定。
这句话只说了三分之二的改动不需要大改。剩下三分之一里，有多少需要改、改动有多大，原文都没说；那三分之二里也可能有小的人工修改。所以不能反推成”只有三分之一需要人改”。能确定的是：人仍然在环里。
Meta 也很坦白：这个效果是”用通用性换领域深度”换来的，是有意为之。“编排器是通用的，专家是专精的。”
还有一个外部研究可以参照。Meta 引用了西奈山医学院的一项研究，Meta 称之为预印本；论文全文已于 2026 年 3 月 9 日发表在 npj Health Systems。论文测了 4 个模型（GPT-4.1-mini、GPT-4.1-nano、Llama-2-70B、Qwen-3-8B）。4 个模型的结果合并计算后，任务批量达到 80 个时，编排式多 Agent 的准确率是 65.3%，单 Agent 是 16.6%。「token 最多相差 65 倍」来自 GPT-4.1-mini 一个模型：80 个任务时，多 Agent 用了约 6 万 token，单 Agent 用了约 390 万。另外两个开源模型的单 Agent 大批量运行有不少直接失败，论文说这让 token 对比不够干净。
但要注意场景不同：那项研究用的是受控的检索、抽取和剂量计算任务，每题有确定的标准答案，按精确匹配打分，不是代码生成，也不是 Meta 这种跨仓库的工程任务。作者自己也说，还需要在真实病历和临床流程里验证。它能说明”任务隔离可以减少上下文干扰”这个方向，不能直接套用到你的产品上。
五、为什么有效
Meta 的解释是：让架构的边界和计算的边界对齐。原文给了四点。注意，下面是 Meta 对自己这套实现的描述，前提是专家之间真的隔离了上下文、编排器真的不靠大模型做路由。它不是这种架构的通用保证，这篇工程文章也没有给出对应的测量数据。
1. 确定性的决定，就用确定性的代码。“这个任务交给哪个专家”是路由决定，不是推理任务，别交给大模型。
**2. 上下文隔离，防止串味。**负责 A 数据源的填充 Agent 看不到 B 数据源的模式。原文的说法是”它没法幻觉出错误的那一个”（It can’t hallucinate the wrong one）。我的理解是，隔离能限制、降低”把 B 的模式套到 A 上”这一类跨数据源干扰的风险，但不等于消除：如果某个专家自己的知识文件写错了，或者编排器把任务分给了错的专家，照样会出错；在自己的领域里，专家也可能出错。
**3. 故障被隔离。**按 Meta 的描述，专家失败了，编排器会重试或上报，失败不会污染编排器的状态，也不会污染其他专家的上下文。我的理解是，这要靠具体实现来保证，比如专家之间不共享上下文、专家的结果先交回编排器再往下走。原文没有给出故障率或隔离失效的数据。
**4. 每一层可以独立变好。**原文的说法是，更好的模型会让 14 个专家同时变好，知识文件一更新就生效，新模板不碰任何 Agent 就能解锁新能力。这是 Meta 对架构的描述，原文没有给出换模型前后的对比数据；换了模型，各个专家的表现也不一定同步提升。
原文最有说服力的其实是反面：如果重编排器产生了幻觉，错误会一路传到下游，比如路由给错的 Agent、收集错的字段、跳过可靠性检查。我的理解是，薄编排器的路由和检查不依赖大模型推理，路由这一环出现幻觉的空间就小得多；但关键词和规则写错了，同样会路由错，只是这类错误更容易复现和排查。
| 维度 | 重编排器 / 全知单体 Agent | 薄编排器 + 专家 Agent |
|---|---|---|
| 路由谁来做 | LLM 推理决定交给谁、怎么做 | 确定性代码：关键词、意图分类、字段收集 |
| 上下文 | 所有知识塞进一个上下文 | 每个专家只加载自己的知识文件 |
| 出错时 | 错误向下游扩散：错路由、错字段、跳过检查 | 按 Meta 自述：失败被隔离，编排器重试或上报 |
| 适配新任务 | 文中另一单 Agent 方案：每个任务人工定制系统提示 | 先问能否用新模板复用现有专家 |
| 更新知识 | 知识写进编排器，改知识就要动编排器（作者归纳） | 运行时按需加载，下次会话即用新版，编排器不用改 |
| 代价（作者归纳） | 通用、上手快 | 牺牲通用性换领域深度；要维护模板和知识文件 |
表：重编排器和薄编排器的对比，标「作者归纳」的格子不是原文。来源：Meta Engineering《The Thin Orchestrator》，发布于 2026 年 10 月 19 日。
六、和”验证成为瓶颈”是同一件事
在《AI 写的代码越来越多，软件岗位招聘却在回升》里我写过，AI 写代码以后，瓶颈从”写”移到了”确认它是对的”。Addy Osmani 10 月 14 日在 Substack 上写了一篇《Agentic Verification》，副标题就是：“瓶颈已经从写代码，变成了知道代码是对的。”
他的几个核心观点，翻成中文大意是：
- 如果 Agent 没法验证自己的输出，它本质上就是在猜。
- 我们的工作，不再是逐行审代码，而是搭建 Agent 自己能跑的验证循环。
- 他宁可要一个好得多的反馈循环，也不要一个稍好一点的模型。
- 测试必须快且确定。否则 Agent 会学会”重跑一遍”，而不是修问题。
- 用独立上下文的评审 Agent 来做验证；生成的测试本身也要审查。
放到一起看，Meta 的架构其实就是在结构层面落实验证（以下对应关系是我的解读，Meta 原文没有引用 Osmani）：
- 第 2 步查重、第 5 步可靠性闸门，是写死在代码里的检查，不靠大模型自觉。
- 模板里的”校验""测试""监控”是固定阶段，由确定性的流程排定，不由模型决定要不要做。
- 有专门的校验 Agent，在自己的上下文里工作，接近 Osmani 说的”独立上下文评审”。
- Meta 下一步打算用生产数据自动发现失败模式、提议改进知识文件，但原文强调始终由人审核把关。这和 Osmani 说的”把每次出错写成规则，让品味复利”是一个思路。
一句话：Osmani 讲的是验证循环怎么建，Meta 展示的是怎么把这个循环钉进架构里。
七、什么时候不该用（我的判断）
以下几条是我的判断，不是 Meta 原文的内容。
- **流程还没固定下来时，先别拆。**模板的前提是你知道步骤和顺序。探索期的产品，一个 Agent 加少量工具迭代更快。
- 低负载时，先实测编排开销。西奈山那篇论文也提到，编排有固定开销（编排器和 worker 的调用、重复的提示词），批量小的时候，有的模型总 token 和延迟反而更高。任务量不大时，先在自己的场景里量一下再决定。
- 开放式、需要全局视野的任务不适合。“没有任何 Agent 看到全貌”对跨模块的大重构可能是缺点，需要额外设计专家之间如何交接。
- **维护成本从提示词转移到了模板和知识文件。**25 个以上的知识文件也得有人维护、做版本管理。
- **数据边界：**这篇工程文章未提供幻觉率、评估集、样本量等细节，“三分之二无需大改”也没有对比基线，目前也没有看到独立复现。别把它当成可以照搬的数字。
八、小团队落地清单（建议收藏）
前四组主要来自 Meta 和 Osmani 原文的建议，括号里标”我的补充”和最后一组是我加的。
架构
- 把每个组件标一下：这是路由决定（确定性），还是推理任务（概率性）？两类不要混在一起。
- 编排器里不放任何领域知识。如果它在做领域判断，就是做多了。
- 路由优先用关键词、意图分类、字段收集这类确定性手段。（我的补充：实在要用模型分类，也只让它输出一个枚举值。）
专家
- 每个专家套同一个结构：知识来源 / 必需输入 / 执行步骤 / 常见错误处理。
- 一个专家只加载自己领域的知识，别图省事把所有文档都塞进去。
- 知识用文件管理，运行时按需加载，改了就生效。（我的补充：放进 git 做版本管理。）
扩展
- 来了新需求，先问：能不能用现有专家换个顺序？
- 如果专家没法在多个流程里复用，说明它和某个场景绑得太死了。
验证
- 在分派前加确定性闸门：查重、必填字段、权限、“需要人审”的标记。
- 在模板里写死校验或测试阶段，不让模型自己决定要不要验证。
- 验证循环要快、要确定，失败信息要简短具体。
- 每次出错，都沉淀成一条知识文件规则或一个测试，并由人审核后合入。
起步顺序（我的建议）
- 先挑一个最高频、步骤最固定的流程，拆出 2–3 个专家，跑通再扩展。别一上来就做 14 个。
拿 AI 工作区这类产品来说（以下是一般性的举例，不代表任何具体产品已经采用这种架构）：高频、步骤固定的流程适合先做成模板，开放式对话可以继续留给通用 Agent。两种模式并存，不必二选一。
最后
Meta 这篇文章的结论是一句反直觉的话：在他们的 Agent 系统里，最重要的组件是干活最少的那个。
做 Agent 产品时，我们很容易把精力花在让中间的”大脑”更聪明。Meta 的经验是反过来：让中间那层尽量笨、尽量确定，把聪明留给边界清晰、上下文干净、能被验证的专家。
编排器要薄，专家要深，验证要钉进架构里。
觉得有用就收藏，转给正在做 Agent 的朋友。
（原文链接与引用出处见文末参考资料，原文于 2026 年 10 月 20 日核对。文中标注”我的判断""我的解读""我的理解”的内容为作者观点。）
