薄编排器：如何通过减少路由器的职责让我们的AI代理更可靠
内容提要
Meta的数据管道AI代理最初采用单一全能代理，但在生产环境中因上下文过载而频繁产生幻觉。团队随后改为“薄编排器”架构：由1300行确定性路由器负责意图分类、字段收集、可靠性检查与任务分派，不进行任何领域推理；14个上下文隔离的专业子代理各司其职。系统通过工作流模板复用子代理，并按需加载知识文件。改造后，新列配置时间从三四天缩短至一小时以内，约三分之二的变更无需人工大幅修改。
延伸解读
上下文过载：知识越多，表现越差
文章指出，单一全能代理在演示中可行，但生产环境中因加载全部领域知识而出现概念交叉污染，例如把某个子系统的字段命名规则套用到另一个子系统。作者引用一项预印本研究：在80任务批次下，编排式多代理系统准确率为65.3%，而单代理降至16.6%，且token用量最多减少65倍。这说明问题不在提示词或上下文窗口大小，而在架构设计。
确定性路由与概率性推理的边界
薄编排器执行固定的7步协议，其中步骤1至5和7均为确定性操作，只有步骤6的委派涉及LLM推理，且发生在隔离的子代理内部。文章强调，路由决策不应交给LLM，而应通过关键词匹配、意图分类和字段收集完成。这种划分让编排器几乎不留幻觉空间，同时把创造性工作限制在领域范围明确的子代理中，失败也不会污染全局状态。
工作流模板复用：新场景不必新建代理
文章提到，支持管道迁移这一全新用例时，团队没有编写新代理代码，而是新增一个工作流模板，以不同顺序复用已有的14个子代理。每个子代理遵循统一结构，包括知识来源、预收集清单、执行步骤、发现模式和故障排查。知识文件在运行时按需加载，更新后下一次会话自动生效，无需改动编排器。这种设计使扩展能力主要体现为增加模板和知识文件，而非重建代理。
效果与适用边界
改造后，新列配置时间从手工的三到四天、早期配置驱动系统的一天，缩短到一小时以内；约三分之二的系统变更无需大幅人工修改。文章将这一收益归因于用通用性换取深度领域知识：编排器保持通用，子代理高度专业。不过，这一模式依赖清晰的领域边界和稳定的工作流定义，文章未讨论领域频繁变动或任务高度开放时的表现，读者需结合自身场景评估。
Q&A
Meta的数据管道AI代理最初遇到了什么问题？
最初采用单一全能代理，加载了所有领域知识，但在生产环境中因上下文过载而频繁产生幻觉，出现概念交叉污染，例如将子系统的字段命名约定错误应用到另一个子系统。
什么是“薄编排器”架构？
薄编排器是一种将路由与领域推理分离的架构：一个确定性的编排器（约1300行代码）负责意图分类、字段收集、可靠性检查和任务分派，自身不做任何领域推理；14个上下文隔离的专业子代理各自负责领域决策。
薄编排器如何保证可靠性？
编排器遵循固定的7步协议，其中6步是确定性的（如读取指令、检查重复、收集字段、自动发现、可靠性门禁、处理结果），只有第6步委托给子代理涉及LLM推理，且发生在隔离的上下文中，从而减少幻觉和错误传播。
工作流模板在系统中起什么作用？
工作流模板是确定性的状态机，定义阶段顺序以约束LLM的决策空间。它们复用同一组14个子代理的不同序列，例如列上线、事件上线和管道迁移各有模板，新增用例时只需编写新模板，无需新建代理。
采用薄编排器后取得了哪些效果？
新列配置时间从手工的三到四天缩短到一小时以内；约三分之二的系统变更无需人工大幅修改即可落地。
如何将薄编排器模式应用到自己的AI代理系统？
关键实践包括：将路由与推理分离，路由用确定性方法（关键词匹配、意图分类）；子代理设计为结构统一的专家；用工作流模板而非新代理来扩展；知识文件在运行时按需加载；明确划分确定性/概率性边界。
