本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

The Thin Orchestrator: How We Made Our AI Agents More Reliable by Giving the Router Less to Do

By Plawan Rath, Akhil Jindal, Ashwini Verma. Sometimes, giving an AI agent all of the knowledge it needs is the wrong approach. At Meta, we’ve seen notable improvements in efficiency and accuracy by keeping the orchestration layer of our data pipeline agents deliberately thin: It routes work and enforces reliability checks, while specialized agents do the domain reasoning. We’re sharing our own process and insights, plus how any team can apply this to their production AI agents.

作者：Plawan Rath, Akhil Jindal, Ashwini Verma。有时，为 AI 智能体提供其所需的所有知识并非正确的方法。在 Meta，我们通过刻意保持数据流水线智能体编排层的“轻量化”，在效率和准确性方面看到了显著提升：编排层负责路由工作并执行可靠性检查，而专门的智能体则负责领域推理。我们在此分享我们的流程与见解，以及任何团队如何将其应用于生产环境中的 AI 智能体。

We built a 1,300-line orchestrator that routes 20+ workflows to 14 specialized AI agents. It performs zero domain work itself. That’s the point. When we first deployed AI agents to automate data column onboarding across Meta’s recommendation systems — a process spanning three code repositories, three programming languages, and up to six pipeline stages that must stay in sync — we did what most teams do: We built one smart agent that knew everything. It worked in demos. In production, it started hallucinating. The fix wasn’t better prompts or a bigger context window. It was giving the central agent less to do. We call this the thin orchestrator pattern: a router that owns sequencing and reliability checks, and leaves every domain decision to specialists.

我们构建了一个 1,300 行代码的编排器，将 20 多个工作流路由至 14 个专业 AI 智能体。它本身不执行任何领域工作，这正是其核心所在。当我们首次部署 AI 智能体以自动化 Meta 推荐系统中的数据列接入（这是一个跨越三个代码库、三种编程语言、多达六个必须保持同步的流水线阶段的过程）时，我们采取了大多数团队的做法：构建了一个无所不知的智能体。它在演示中表现良好，但在生产环境中却开始产生幻觉。解决方案并非优化提示词或扩大上下文窗口，而是减少中央智能体的工作量。我们称之为“轻量编排器模式”：一个负责排序和可靠性检查的路由器，将所有领域决策留给专家。

The Problem: More Context, Worse Results. Our pipeline is config-as-code: Python configurations drive C++ code generation, which feeds data processing services, which populate analytics systems. Onboarding a single data column requires coordinated changes across configuration registries, backend services, and data pipelines, and each column moves through up to six stages before its data arrives. Our first approach was a single AI agent loaded with all domain knowledge, configuration schemas, code generation rules, pipeline routing logic, validation requirements, and population patterns for 10+ data sources. The agent had everything it needed. That was the problem. Past a certain context threshold, additional knowledge degraded rather than improved performance.

问题：上下文越多，结果越差。我们的流水线采用“配置即代码”模式：Python 配置驱动 C++ 代码生成，进而为数据处理服务提供输入，最终填充到分析系统中。接入单个数据列需要协调配置注册表、后端服务和数据流水线的变更，且每个数据列在数据到达前需经过多达六个阶段。我们最初的方法是使用一个加载了所有领域知识、配置模式、代码生成规则、流水线路由逻辑、验证要求以及 10 多个数据源填充模式的单一 AI 智能体。该智能体拥有所需的一切，但这正是问题所在。一旦超过特定的上下文阈值，额外的知识反而会降低而非提升性能。

The agent would cross-contaminate concepts, applying field naming conventions from one subsystem to another, or using a code generation pattern meant for one data source when populating from a different one. A preprint from the Windreich Department of Artificial Intelligence and Human Health at Mount Sinai found that orchestrated multiagent systems held 65.3% accuracy at 80-task batches where single agents fell to 16.6%, while reducing token usage up to 65-fold. The authors attribute this to the design’s isolation of tasks, which prevented context interference. We were experiencing the inverse, a single agent drowning in its own knowledge.

智能体会混淆概念，将一个子系统的字段命名规范应用到另一个子系统，或者在填充不同数据源时使用错误的代码生成模式。西奈山医院 Windreich 人工智能与人类健康系的一篇预印本论文发现，在 80 个任务的批处理中，编排的多智能体系统保持了 65.3% 的准确率，而单一智能体则降至 16.6%，同时 Token 使用量减少了多达 65 倍。作者将其归因于该设计对任务的隔离，从而防止了上下文干扰。我们所经历的恰恰相反：单一智能体淹没在自身的知识中。

We also evaluated an alternative single-agent approach. Its success rate was 70-80% with manual prompt engineering per task: An engineer had to craft a custom system prompt for each specific job. Without that handholding, success dropped to 10-20%. This wasn’t a prompt engineering problem. It was an architectural one.

我们还评估了另一种单一智能体方案。在针对每个任务进行手动提示工程的情况下，其成功率为 70-80%：工程师必须为每项具体工作编写自定义的系统提示词。若没有这种人工干预，成功率会降至 10-20%。这并非提示工程问题，而是架构问题。

The Approach: A Thin Router With Specialist Workers. We split the system into two layers: A deterministic orchestrator that performs zero domain work. It classifies intent, gathers required fields, runs reliability checks, and delegates to the right specialist. It never reasons about code, never generates configurations, and never touches the codebase. It’s a router. Fourteen specialized subagents, each a complete domain expert with isolated context. A schema management agent knows configuration registries. A population agent agent knows how to generate code for each of 10 data sources. A validation agent knows build systems and quality checks. No agent sees the full picture. That’s the feature, not the bug.

方法：带有专家工作者的轻量路由器。我们将系统分为两层：一个不执行任何领域工作的确定性编排器。它负责分类意图、收集所需字段、运行可靠性检查并委派给合适的专家。它从不进行代码推理，从不生成配置，也从不触碰代码库。它只是一个路由器。另外有 14 个专业子智能体，每个都是拥有独立上下文的完整领域专家。模式管理智能体了解配置注册表；填充智能体知道如何为 10 个数据源中的每一个生成代码；验证智能体了解构建系统和质量检查。没有任何智能体能看到全貌，这正是其特性，而非缺陷。

The orchestrator follows a fixed 7-step protocol for every request: Read the relevant subagent’s instruction file. Check if the target already exists (prevent duplicates). Gather required fields from the user. Auto-discover what can be inferred (repository type, existing configurations). Reliability gate check for active warnings or required reviewers. Delegate to the subagent with full context. Handle results and surface errors, confirm success. Steps 1–5 and 7 are deterministic. Only step 6 involves large language model (LLM) reasoning, and it happens inside an isolated subagent with only its domain knowledge loaded.

编排器对每个请求遵循固定的 7 步协议：读取相关子智能体的指令文件；检查目标是否已存在（防止重复）；从用户处收集所需字段；自动发现可推断的信息（仓库类型、现有配置）；进行可靠性门控检查以查看活动警告或所需审核人；在拥有完整上下文的情况下委派给子智能体；处理结果并显示错误，确认成功。第 1-5 步和第 7 步是确定性的。只有第 6 步涉及大语言模型（LLM）推理，且该过程发生在仅加载了特定领域知识的隔离子智能体内部。

What We Built: Workflow Templates, Not New Agents. One architectural insight was separating what needs to happen from how each step is performed. The orchestrator defines phase ordering through workflow templates — deterministic state machines that constrain the LLM’s decision space: Column Onboarding: Schema → Validation → Population → Testing. Event Onboarding: Schema → Population → Validation → Testing → Event Processing. Pipeline Migration: Assessment → Planning → Population → Validation → Monitoring. Each workflow template reuses the same pool of 14 subagents in different sequences. When we needed to support pipeline migration, a completely new use case, we didn’t build new agents. We wrote a new workflow template that sequenced existing agents differently. Zero new agent code. Full production capability.

我们构建了什么：工作流模板，而非新智能体。一个架构上的见解是将“需要发生什么”与“每一步如何执行”分离开来。编排器通过工作流模板定义阶段顺序——这些确定性状态机限制了 LLM 的决策空间：数据列接入：模式 → 验证 → 填充 → 测试；事件接入：模式 → 填充 → 验证 → 测试 → 事件处理；流水线迁移：评估 → 规划 → 填充 → 验证 → 监控。每个工作流模板都以不同的顺序重用相同的 14 个子智能体池。当我们支持流水线迁移这一全新的用例时，我们没有构建新智能体，而是编写了一个以不同方式排列现有智能体的新工作流模板。无需编写新的智能体代码，即可实现完整的生产能力。

Each subagent follows a standardized structure: Knowledge sources: which domain files to load at runtime (typically a few thousand tokens each). Pre-gathering checklist: what the orchestrator must collect before delegation. Step-by-step workflow: the domain-specific execution plan. Discovery patterns: how to find relevant code patterns in the monorepo. Troubleshooting: error-to-resolution mappings for common failures. This uniformity means adding a new subagent is templated work, not greenfield engineering. The 15th subagent looks structurally identical to the first. Knowledge files are loaded on demand at subagent execution time, not embedded in the orchestrator. We maintain 25+ knowledge files organized by workflow domain. When a knowledge file is updated, the next session automatically uses the latest version — no orchestrator changes required.

每个子智能体都遵循标准化的结构：知识源（运行时加载哪些领域文件，通常每个几千个 Token）；预收集清单（委派前编排器必须收集的内容）；分步工作流（特定领域的执行计划）；发现模式（如何在单体仓库中查找相关代码模式）；故障排除（常见故障的错误到解决方案映射）。这种统一性意味着添加新的子智能体是模板化工作，而非从零开始的工程。第 15 个子智能体在结构上与第一个完全相同。知识文件在子智能体执行时按需加载，而非嵌入在编排器中。我们维护着 25 个以上按工作流领域组织的知识文件。当知识文件更新时，下一次会话会自动使用最新版本，无需更改编排器。