devgo.cn你大概也遇到过这种情况：给 AI Agent 塞了所有它可能需要的知识，结果它反而开始胡说八道。Meta 在给推荐系统的数据列接入流程做自动化时，第一版就是这种"全知全能"的 Agent——一个智能体装下所有领域知识、配置 schema、代码生成规则、流水线路由逻辑，demo 跑得完美，一上生产就开始幻觉。不是 prompt 写得不够好，也不是上下文窗口不够大，问题恰恰出在给中心 Agent 的活儿太多了。
他们最后给出的解法反直觉：把编排层做得极薄。一个 1300 行的确定性编排器，负责路由和可靠性检查，零领域推理；14 个专职子 Agent 各自只带自己那一亩三分地的上下文，互不串门。这个模式他们叫 thin orchestrator pattern（瘦编排器模式，就是让中央调度只做调度，把具体业务判断全部分给专家子 Agent）。
先说他们踩的坑。Meta 的数据列接入流程是 config-as-code（配置即代码，用 Python 配置驱动 C++ 代码生成，再喂给数据处理服务，最后进分析系统），一个数据列要跨三个代码仓库、三种编程语言、最多六个流水线阶段。第一版单 Agent 方案把所有知识塞进一个模型，结果超过某个上下文阈值后，知识越多表现越差：它会把一个子系统的字段命名规范用到另一个子系统上，或者用错代码生成模式。西奈山医院的一篇预印本论文也印证了这点：编排式多 Agent 系统在 80 任务批次下准确率 65.3%，单 Agent 只有 16.6%，token 消耗还少了最多 65 倍——原因就是任务隔离避免了上下文干扰。Meta 这边还试过另一个单 Agent 方案，靠工程师为每个任务手写 system prompt（系统提示词，就是给模型设定角色和规则的指令），成功率能到 70-80%，不手写就掉到 10-20%。这根本不是 prompt 工程问题，是架构问题。
瘦编排器的做法分两层。上层是确定性编排器，它只做七件事：读子 Agent 的指令文件、查重、收集必要字段、自动发现可推断的信息、跑可靠性门禁检查、委派给子 Agent、处理结果和报错。七步里只有第六步涉及大模型推理，而且发生在隔离的子 Agent 上下文里。下层是 14 个专职子 Agent，比如 schema 管理 Agent 只管配置注册表，population Agent 只管给 10 种数据源生成代码，validation Agent 只管构建系统和质量检查。没有任何一个 Agent 能看到全局，这恰恰是特性不是 bug——population Agent 永远不会看到数据源 B 的模式，自然不可能幻觉出错的模式。
最妙的设计是 workflow templates（工作流模板，就是确定性的状态机，约束 LLM 的决策空间）。他们把"做什么"和"怎么做"分开：编排器只定义阶段顺序，比如列接入是 Schema → Validation → Population → Testing，流水线迁移是 Assessment → Planning → Population → Validation → Monitoring。新增一个完全不同的用例（流水线迁移）时，他们没写一行新 Agent 代码，只是写了个新模板把现有 Agent 重新排序。每个子 Agent 结构也标准化：知识源（运行时按需加载的领域文件，每个几千 token）、委派前检查清单、分步工作流、发现模式、故障排查映射。加第 15 个子 Agent 是模板化工作，不是从零造轮子。知识文件按需加载，更新后下一轮会话自动生效，编排器完全不用动。
效果很直接：新列配置准备从手工三四天、老系统一天，压到一小时以内；约三分之二的改动不需要人工大改。代价是牺牲通用性换深度领域知识——编排器是通用的，子 Agent 是专家。
这个模式能成，核心是让架构边界对齐计算边界：确定性决策（"哪个子 Agent 处理这个？"）就别用 LLM；上下文隔离杜绝交叉污染；失败被限制在单个子 Agent 内，不会污染编排器状态；系统各层独立进化——换更好的模型同时提升全部 14 个子 Agent，更新知识文件立即生效，新模板解锁新能力而不用碰 Agent。
这套思路不限于数据流水线。任何做生产级 AI Agent 的团队都能直接用：把路由和推理分开，别让中央 Agent 什么都管。具体落地时注意几个坑：编排器要严格保持确定性，别手痒往里加推理；子 Agent 的上下文隔离要彻底，共享上下文等于没隔离；知识文件按需加载而不是塞进编排器，否则更新成本会拖垮你。最反直觉的一点是，当你觉得"再加点上下文它就能更聪明"时，恰恰是该砍掉的时候。
内容与图片版权归原作者所有 · 原文: https://engineering.fb.com/2026/10/19/ml-applications/thin-orchestrator-ai-agent-architecture/