💻 computer science

SWE-Manager: Selecting and Synthesizing Golden Proposals Before Coding

本文介绍了 SWE-Manager，这是一个 8B 参数规模的强化学习模型，它通过模仿技术经理的行为，在不执行代码的情况下选择最佳候选方案并合成软件问题的“黄金”解决方案，从而在 SWE-Lancer Manager 基准测试中实现了最先进的性能。

原作者： Boyin Tan, Haoning Deng, Junyuan Zhang, Junjielong Xu, Pinjia He, Youcheng Sun

发布于 2026-07-07

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Boyin Tan, Haoning Deng, Junyuan Zhang, Junjielong Xu, Pinjia He, Youcheng Sun

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下你是一位船长（一个软件项目），而一场风暴袭来了（一个 Bug 或一个新的功能需求）。在你可以操舵之前，你需要决定走哪条路径。

在现实世界中，你的船员不会瞎猜。他们可能会听到三位水手喊出三条不同的路线：

水手 A 说：“走穿过暗礁的捷径！很快，但有风险。”
水手 B 说：“绕过这座岛屿。很安全，但要花三天时间。”
水手 C 说：“我们先修好引擎再出发。这是最彻底的做法，但成本很高。”

通常，人类管理者必须听取这三者的意见，权衡风险，观察天气（问题的具体语境），然后选出最好的计划。这篇名为 SWE-Manager 的论文在问：AI 能学会成为那样的管理者吗？

以下是他们如何构建它的过程，用简单的语言进行了解释：

1. 问题所在：AI 擅长写作，但不擅长抉择

目前的 AI 模型（比如那些写代码的模型）非常擅长生成一个解决方案。但在真实的软件团队中，人们经常会写出多个解决方案，然后针对哪一个更好进行争论。

差距： AI 还没有真正被教会如何坐在“管理者的椅子”上，去倾听所有的选项，进行比较，然后说：“好吧，我们决定采用水手 B 的方案，但让我们把它优化得更快一点。”
问题在于： 这种“挑选赢家”的技能仅仅是一种随机的人类偏好，还是存在一种 AI 可以学习的逻辑模式？

2. 侦探工作：真正的管理者是如何做事的？

研究人员扮演了侦探的角色。他们查看了 GitHub（一个程序员分享代码的地方）上成千上万条关于如何修复 Bug 的真实讨论。他们发现了人类管理者进行选择时的三个大秘密：

秘密 #1：这不是随机的。 管理者并不会随心所欲地挑选。他们总是遵循一些“高层规则”，例如：“这安全吗？”“这会破坏其他东西吗？”“以后容易修复吗？”
秘密 #2：这是一个比较过程，而不是单纯的测试。 你不能孤立地判断一个提议。你必须在特定的问题语境下将它们相互比较。（例如：“水手 A 的方案很快，但既然我们正处于风暴中，安全性比速度更重要。”）
秘密 #3：最好的计划是融合。 通常，最终的计划并不只是某一位水手的想法。它是一个“黄金提议（Golden Proposal）”，它结合了水手 A 的优点、水手 B 的安全性以及水手 C 的彻底性，并将它们融合成一个完美的计划。

3. 解决方案：SWE-Manager（AI 管理者）

基于这些秘密，团队构建了 SWE-Manager。把它想象成一种新型的 AI，它不只是写代码，它还管理对话。

SWE-Manager 不仅仅是说“这是代码”，它会做三件事：

阅读问题： 它理解问题所在。
评审候选方案： 它查看所有不同的提议（就像水手们的航线）。
“黄金”合成： 它挑选出最好的方向，解释为什么它选择了这个方向，然后编写一个新的、“黄金提议”，将所有候选方案中的精华部分结合成一个清晰的指令。

他们训练了一个特定的版本，称为 SWE-Manager-8B（一个拥有 80 亿参数的模型），使用了特殊的两步法：

第一步（学校）： 他们教它如何进行比较和解释的格式（监督微调）。
第二步（实践）： 他们让它练习做出选择，并在它选对时给予奖励，从而教会它像管理者一样去“思考”（强化学习）。

4. 结果：AI 管理者有效吗？

他们通过两种方式对 AI 进行了测试：

测试 A：“谁是老大？”测试（选择能力）
他们给 AI 一个问题和三个不同的解决方案，要求它选出人类管理者会选出的那个。

结果： SWE-Manager-8B 在 53% 的情况下做对了。
对比： 一个非常强大且著名的 AI（GPT-5）仅在 44% 的情况下做对了。尽管 SWE-Manager 是一个更小、更便宜的模型，但它在选择正确路径方面表现得更好。

测试 B：“它能帮助构建吗？”测试（实现能力）
他们建立了一个工作流（称为 P2A），流程如下：

一个 AI 编写提议。
SWE-Manager 挑选出最好的一个，并编写“黄金提议”。
第三个 AI 根据该“黄金提议”尝试构建修复程序。

结果： 当使用 SWE-Manager 作为管理者时，团队成功修复了 55.6% 的问题。
对比： 这优于完全没有管理者的情况（修复率为 48.5%），并且达到了使用巨型 GPT-5 作为管理者的性能水平。

核心总结

这篇论文证明了选择正确的计划是一种 AI 可以学习的技能。

这不仅仅关乎是否有足够的智能去写代码，更关乎是否有足够的智能去比较选项、理解风险，并将最好的想法组合成一条清晰的指令。通过教 AI 扮演“技术管理者”的角色，我们可以让软件开发变得更加可靠和高效，即使是使用规模较小、成本较低的 AI 模型也是如此。

简而言之： 论文表明，如果你教 AI 成为一名优秀的评判者和编辑，它在帮助人类构建软件方面会变得更加出色。

技术摘要：SWE-Manager

问题陈述

在现实世界的软件工程工作流中，代码生成之前有一个关键步骤：提案选择（proposal selection）。团队通常会针对单个问题（如漏洞修复、功能实现）起草多个候选提案，而维护者必须从中选择最合适的一个来指导实现。这种决策很少仅仅基于技术可行性；它需要平衡正确性、回归风险、修复深度、可维护性以及组织约束。

虽然大语言模型（LLMs）在代码生成和错误修复方面取得了进展，但提案选择阶段仍未得到充分探索。目前尚不清楚维护者的选择决策是依赖于可重用的、可学习的推理模式，还是仅仅是特定实例的偏好。此外，现有的基准测试（如 SWE-Lancer）虽然形式化了“管理者（Manager）”任务，但并未探讨其背后的逻辑依据，也未探索从竞争候选方案中合成一个精炼的“黄金提案（golden proposal）”的可能性。

研究方法

1. GitHub 讨论的手动研究

作者首先对 2,852 个具有赏金支持结果的公开 GitHub 问题进行了手动研究，以刻画现实世界的提案选择过程。他们分析了 339 个存在多个完整提案的采样问题。研究揭示了三个关键属性：

循环出现的高层逻辑依据： 维护者的选择受一致的工程关注点引导，主要是风险与安全性（42.8%）、修复深度（29.2%）和可维护性（16.2%）。
上下文条件的比较： 选择并非对单个提案的孤立评估，而是将候选方案与特定问题约束进行对比判断（例如，针对高回归风险倾向于极简修复，针对系统性脆弱则倾向于深度修复）。
通过讨论进行合成： 最终的实现方向通常通过讨论进行精炼，在此过程中，假设被澄清，范围被缩小，且来自竞争提案的有益观察被整合进来。

2. SWE-Manager 框架

基于这些发现，作者提出了 SWE-Manager，一种联合选择与合成的方法。该模型承担的任务包括：

联合比较： 同时分析问题上下文和所有候选提案。
选择： 识别最佳提案。
解释： 基于问题约束对选择进行辩护。
合成： 生成一个**“黄金提案”**，该提案整合了所选方向的优势以及来自其他提案的有益观察，从而形成一个精炼的实现计划。

3. 模型训练 (SWE-Manager-8B)

作者将此方法实例化为 SWE-Manager-8B，这是一个基于 Qwen3-8B 的 8B 参数模型。

数据准备： 构建了一个包含 2,852 个问题的语料库。使用 GPT-5 从碎片化的 GitHub 讨论线程中重建结构化训练目标（比较推理轨迹和黄金提案），而地面真值（ground-truth）的选择标签则锚定在实际的赏金获得者身上。
训练策略： 采用了两阶段过程：
1. 监督微调 (SFT)： 教导模型学习结构化输出格式（推理轨迹、选择 ID、理由、黄金提案）。
2. 强化学习 (RL)： 使用 DAPO（解耦裁剪与动态采样策略优化）配合加权奖励函数（ $r = 0.4r_{sel} + 0.2r_{think} + 0.2r_{justi} + 0.2r_{gold}$ ）来优化决策策略，而非仅仅模仿推理过程。

4. 评估框架 (P2A)

为了评估合成的黄金提案的下游效用，作者引入了 P2A (Proposal-to-Action)，一个模拟真实开发的工作流：

提案智能体 (Proposal Agent)： 生成多个候选提案。
技术管理者 (Technical Manager, 即 SWE-Manager)： 选择并合成黄金提案。
实现智能体 (Implementation Agent)： 使用黄金提案生成代码补丁。
该工作流在 SWE-Lancer IC 基准上进行了测试，以衡量问题解决率。

关键结果

提案选择性能 (SWE-Lancer Manager 基准)

SWE-Manager-8B 实现了 53.21% 的选择准确率和 57.75% 的收益率（$152,750）。
其表现优于 GPT-5（44.15% 准确率，$99,875 收益）和基础的 Qwen3-8B（34.72% 准确率）。
即使在给予 GPT-5 大部分提案数量的代码访问权限（Agent 设置）的情况下，SWE-Manager-8B 依然超越了 GPT-5，尽管 GPT-5 在处理最高价值（$2K+）和最复杂（6 个以上提案）的实例时表现略好。

下游实现性能 (SWE-Lancer IC 基准)

通过使用 P2A 工作流，SWE-Manager-8B 达到了 55.6% 的问题解决率。
这与使用 GPT-5 作为管理者的 P2A 性能持平，并比基线 mini-SWE-agent（直接实现而不进行提案选择）提升了 7.1%。
关于合成能力的消融实验： 将合成的“黄金提案”替换为原始的“被选中的提案”会导致 SWE-Manager-8B 的性能显著下降（从 55.6% 的通过率降至 46.5%），这证明了合成能力除了简单的选择之外，提供了切实的价值。

训练消融实验

合成目标： 如果仅训练模型预测提案 ID（而不合成黄金提案），其准确率较低，这表明合成任务迫使模型进行更深层次的比较推理。
训练阶段： 采用两阶段方法（先 SFT 后 RL）比直接对基础模型应用 RL 具有更好的稳定性和性能。

重要性与主张

本文声称，提案选择是 LLM 的一种可学习能力，它是由循环出现的高层工程逻辑而非任意偏好驱动的。

可学习性： 一个小型 8B 模型，在经过大规模选择数据和合成目标训练后，可以在选择最佳技术提案方面超越规模大得多的模型（如 GPT-5）。
实际效用： 合成“黄金提案”的能力不仅仅是一个辅助输出；它提供了能够显著改善下游代码生成和问题解决的可操作性指导。
工作流集成： P2A 框架表明，在编码之前集成一个“技术管理者”角色，比直接使用实现智能体能带来更好的端到端软件工程结果。

作者得出结论，虽然目前的模型在面对极大规模提案池时表现出鲁棒性限制（由于训练数据分布偏移），但基于上下文的比较与合成这一核心能力，是一种可行且有效的 LLM 软件工程系统策略。