AI智能体在生产环境里翻车，问题常常不在模型不够聪明，而在总调度知道得太多。2026 年 10 月 19 日，Meta 工程团队在官方技术博客中公开了自家数据管道智能体的瘦编排器（Thin Orchestrator）模式：一套约 1300 行代码的编排层只负责路由和可靠性检查，自身完全不做领域推理，20 多条工作流被分发给 14 个上下文互相隔离的专项子智能体完成。
全能调度为什么先在演示里成功、再在生产里幻觉
Meta 最初的做法和多数团队一样：造一个装下全部领域知识的智能体，配置结构、代码生成规则、管道路由、校验要求、10 多个数据源的填充模式全塞给它。这个智能体在演示里表现正常，进了生产却开始把不同子系统的命名规范和生成模式互相串用。Meta 给出的对照数据很直白：单智能体方案靠工程师逐任务手写提示词时成功率有 70%–80%，没人逐个伺候就掉到 10%–20%。博客还引用了西奈山伊坎医学院人工智能与人类健康系一篇预印本的结果：在 80 个任务的批量测试中，编排式多智能体系统保持 65.3% 的准确率，单智能体只剩 16.6%，前者 token 用量最高可省 65 倍，差距来自任务隔离避免了上下文互相污染。
瘦编排器的分工：七步里只有一步用到模型推理
新架构把系统拆成两层。编排层执行固定七步：读取目标子智能体的说明书、检查目标是否已存在防重复、收集必填字段、自动推断仓库类型等可推断信息、过可靠性关卡、把任务连同完整上下文委派给子智能体、处理返回结果。其中只有第六步涉及大模型推理，而且发生在上下文隔离的子智能体内，每个子智能体只加载自己领域的几千 token 知识文件。扩展方式也随之变了：新增的管道迁移场景没有写任何新智能体代码，只是把 14 个现有子智能体换个顺序编成新的工作流模板；25 个以上的知识文件在运行时按需加载，更新后下一次会话自动生效。
效果不错，但抄作业有前提
按 Meta 公布的数据，新增一个数据列的配置准备，手工要三四天，早先的配置驱动系统约一天，瘦编排器系统压到一小时以内；系统约三分之二的变更无需人工大幅修改即可落地。Meta 总结的做法包括：路由与推理分开、子智能体结构统一、用工作流模板而不是新智能体扩展、把确定性决策和概率性推理的边界画清楚。需要泼的冷水是，这套成绩建立在每个子智能体深厚的领域知识文件之上，编排器可以瘦，前提是专家知识已经被认真沉淀成文档；手里没有这份家底的团队照搬结构，省不掉补知识的功课。
