ManagerWorker 架构：AI 模型互相指挥的可能性

论文链接：https://arxiv.org/abs/2603.19561

提交日期：2026年3月24日

核心问题

当前 AI 编码 Agent 面临一个根本性的成本-质量权衡：用强模型（GPT-5、Claude Opus）效果好但成本高，用弱模型成本低但质量差。这篇论文提出了一个不同的思路：不是让一个模型独自完成所有任务，而是让多个模型分工协作，各取所长。

具体来说，论文提出了 ManagerWorker 架构——由一个「经理模型」负责高层决策（分析 issue、制定计划、审查结果），由一个或多个「工人模型」负责执行层操作（在代码仓库中读取、搜索、修改代码）。经理模型可以是昂贵的 frontier 模型，工人模型可以是便宜的轻量模型。

关键数据

在 SWE-bench Verified 上，ManagerWorker 架构使用便宜工人模型时，成本降低 40-60%，而 solve rate 仅下降 2-5 个百分点
经理模型的分析质量直接决定整体表现：一个好的经理 + 差的工人，往往好过差的经理 + 好的工人
多工人协作模式下（多个工人并行尝试不同方案），成功率有额外提升
经理模型的 review 环节能有效过滤工人模型的低质量提交，充当质量门控

架构设计

1. Manager（经理模型）

接收 GitHub issue 描述
分析问题根因，制定修复计划
分配子任务给 Worker
审查 Worker 的提交结果，决定接受或打回
特点：需要强推理能力，适合用 frontier 模型

2. Worker（工人模型）

执行经理分配的具体任务：读文件、搜索代码、修改代码、运行测试
可以有多个 Worker 并行工作，各自尝试不同方案
特点：需要代码执行能力，但对推理深度要求较低，适合用便宜模型

3. 协作流程

Manager 解析 issue -> 制定计划 -> 分配子任务
Worker 执行子任务 -> 提交 patch
Manager review patch -> 接受/打回/修改
循环直到所有子任务完成或达到上限

关键洞察

1. 经理比工人更重要

论文的核心发现是：经理模型的质量对整体表现的影响远大于工人模型。一个强经理 + 弱工人的组合，往往能打败弱经理 + 强工人的组合。这说明在 AI Agent 协作中，「分析和决策」比「执行」更关键。一个好的经理能通过精确的计划和严格的 review，弥补工人执行能力的不足。

2. 多 Agent 分工 = 新的 harness 设计模式

ManagerWorker 本质上是一种 harness 设计模式：通过角色分工，把一个复杂任务拆解为多个简单子任务，每个子任务由最适合的模型执行。这和 Harness Engineering 的核心理念一致——不是让模型更强，而是让协作架构更好。环境设计（给 Worker 提供 repo 访问）+ 反馈循环（Manager review）+ 黄金原则编码（测试通过才算完成）= 三层 harness。

3. 成本优化的真实路径

之前降低成本的思路主要是：用更小的模型、做模型蒸馏、量化推理。ManagerWorker 提供了一个新的路径：不换模型，换架构。让贵的模型做高价值决策（分析、规划、review），让便宜的模型做低价值执行（读代码、改代码、跑测试）。这种分工方式在人类团队中早已成熟，现在被应用到了 AI Agent 协作中。

4. 与 Harness Engineering 的关联

这篇论文完美体现了 Harness Engineering 的几个核心原则：环境设计（给 Worker 提供结构化的代码仓库访问接口）、反馈循环（Manager 对 Worker 的提交进行 review 和打回）、渐进式披露（Worker 只看到分配给自己的子任务，不需要理解整体架构）。ManagerWorker 架构可以看作是 Harness Engineering 在多 Agent 协作场景下的一个具体实例。

引发思考

如果 ManagerWorker 架构被广泛采用，AI 编码 Agent 的成本结构将发生根本变化：之前是「一个模型吃掉所有 token」，现在是「按角色分配 token 预算」。这对产品设计有直接影响——用户可以用便宜的 Worker 模型处理 80% 的简单任务，只在需要深度分析时调用 Manager 模型。这也意味着，AI 编码工具的竞争重点可能从「谁的模型更强」转向「谁的协作架构更好」。

ManagerWorker 架构：AI 模型互相指挥的可能性 | 论文解读

核心问题

关键数据