2026 年 10 月 19 日，Meta 工程团队在官方工程博客发文，复盘其数据流水线智能体的架构改造：他们把总控层做成一个约 1300 行代码的瘦编排器，只负责路由和可靠性检查，不做任何领域推理，再把 20 多个工作流分派给 14 个上下文互相隔离的专项子智能体。改造后，新数据列的配置准备从人工 3 到 4 天、旧系统约 1 天，压缩到 1 小时以内。
全能总控为什么先翻车
Meta 最初的做法和多数团队一样：一个装满全部领域知识的智能体，配置模式、代码生成规则、校验要求和 10 多个数据源的填充方式全塞进同一上下文。演示阶段没问题，上了生产就开始产生幻觉：上下文越过某个阈值后，新增知识反而拖累表现，不同子系统的命名规范和生成模式互相污染。团队实测，单智能体方案在工程师为每个任务手工定制提示词时成功率有 70% 到 80%，没人手把手盯着就掉到 10% 到 20%。他们引用的一项预印本研究也显示，多智能体编排在 80 个任务的批次中保持 65.3% 的准确率，单智能体只剩 16.6%，同时 token 用量最多可降至六十五分之一。
七步协议里只有一步用到大模型
瘦编排器对每个请求执行固定七步：读取对应子智能体的指令文件、检查目标是否已存在、向用户收集必填字段、自动推断可推断的信息、过可靠性关卡、把完整上下文交给子智能体、处理结果并反馈错误。前五步和第七步都是确定性程序，只有第六步涉及大模型推理，而且发生在只装了本领域知识的隔离上下文里。每个子智能体结构统一：知识来源、预收集清单、执行步骤、代码定位方式和常见故障对照表；25 个以上知识文件按需加载，更新后下一次会话自动生效，不用改编排器。一个子智能体失败时，编排器负责重试或升级处理，失败不会污染其他子智能体的上下文。
新场景靠排模板，不靠造新智能体
列接入、事件接入、流水线迁移三种工作流共用同一批 14 个子智能体，只是排序不同。流水线迁移是后来新增的场景，团队没有写新的智能体代码，只写了一份新的工作流模板就上线了生产能力。目前约三分之二的变更能基本不经人工大改直接落地。Meta 给同行的建议很直接：路由是确定性决策，不要交给大模型；领域推理全部下放到隔离的专项智能体。这与本站此前报道的 Anthropic 先向律师请教智能体规则 指向同一件事：智能体进入生产环境，靠的不是单个模型更聪明，而是边界和规矩先定清楚。
