编码智能体与 SWE-bench：仓库级问题解决

为什么需要：“写代码”与“软件工程”的区别

大语言模型（LLM）最初展示编码能力时，主要衡量的是“给出描述后能否写出一个函数”。但实际开发者的大部分日常工作是阅读他人编写的大型代码库、找出 bug 出在哪里、对多个文件做少量修改，然后确认已有功能没有被破坏。函数级评估无法考察这些能力。

USEagent 研究（paper）直接指出了这一差距：软件工程不只是编码，还包括项目的维护和演进。因此，该研究不再使用分别为测试编写、调试、修复等单独构建的专用智能体，而是尝试让一个智能体处理完成未完成补丁、添加新功能、接手他人代码等各种情况。

在这一趋势下，“仓库级（repository-level）”评估成为核心。这种方式直接采用真实仓库和真实 issue，并用测试来判定智能体修改的结果。SWE-bench 成为这种方式的代表性基准测试（用于比较性能的测试集），SWE-Bench Pro（paper）则继承了 SWE-bench 的良好做法，同时将范围扩展到更难、更贴近企业实际的问题。

核心思路：把 issue 工单交给新入职开发者的考试

仓库级评估类似于给一位新入职的开发者一个从未见过的项目和一张 issue 工单，让他们“去修好”。评分者不会靠肉眼评判代码，而是运行事先准备好、且不向考生公开的测试，确认原本有问题的行为是否已修复，以及原本正常的功能是否保持不变。

这种考试之所以棘手，是因为正确代码的“形态”并不固定。改哪个文件、改多少行，由考生自己决定。因此，除了编写代码的能力，“找出该看哪里的能力”“亲自运行以确认的习惯”“判断修改是否破坏了其他地方的判断力”也变得同样重要。

同时，这个比喻也揭示了弱点。如果试卷泄露、工单描述有误，或者测试检查的内容与 issue 不符，分数就无法反映真实能力。后文将介绍的 SWE-Bench Pro Verified（paper）正是指出了这个问题。

如何运作：从 issue 到补丁，再到评分

第一，输入有两项：issue 描述（哪里出了问题、期望什么）以及该 issue 提出时的仓库快照。智能体在安装了该仓库的沙箱（与外部隔离的执行环境）中工作。

第二，智能体会多轮往返地工作：查看文件列表、搜索相关代码、打开可疑部分阅读、进行修改，再运行测试或复现脚本并观察结果。这种“思考 → 使用工具 → 观察”连续形成的完整记录称为轨迹（Trajectory）。让模型能够使用这些工具的外围机制——提示词、工具列表、执行环境和上下文管理装置——称为 Harness。

第三，当智能体宣布完成后，仓库中的改动会被提取为补丁。SWE-Bench Pro（paper）收录了专业开发者可能需要数小时到数天才能完成的长时任务，并指出许多任务需要跨多个文件的补丁和相当规模的代码修改。

第四，评分使用隐藏测试。将补丁应用到原始仓库后运行测试，通过即计为“已解决”。由于模型是否答对由执行结果而非人工判断决定，同样的结构也可以直接用作强化学习的奖励。这被称为基于可验证奖励的强化学习（RLVR）。

发展脉络：更难，也更可信

SWE-Bench Pro（paper）以 SWE-bench 为基础，试图纳入企业级的复杂问题。它从涵盖商业应用、B2B 服务和开发者工具的 41 个仓库中收集了 1,865 个问题。其特点在于数据集构成：分为来自 11 个仓库的公开集、来自 12 个仓库的保留集（held-out），以及来自与早期创业公司签约的 18 个非公开商业仓库的商业集。用未公开的代码出题，可以降低模型在训练中提前见过答案的可能性，即数据污染。所有任务都经过人工验证，并补充了足够的上下文以确保可解。此外，研究还对收集到的轨迹按失败类型归类，分析了当前模型的出错方式。

USEagent 研究（paper）则向另一个方向扩展。为了考察一个智能体能否处理编码、测试、打补丁等多种工作，而不只是修复单个 issue，研究混合 SWE-bench、SWT-bench 和 REPOCOD 的任务构建了 USEbench，并用 1,271 个仓库级任务进行评估。

SWE-Bench Pro Verified（paper）提出的问题是“SWE-Bench Pro 的分数可信吗”。研究发现了两类可信度问题：一是参考解答或隐藏评估信息泄露并被利用的奖励作弊；二是任务质量问题，如具有误导性的问题描述或范围设定错误的测试。研究加入了在不损害正常智能体功能的前提下封堵主要泄露途径的机制，并对有缺陷的任务做了最小限度的修正。在验证版上，部分模型的分数比之前的评估大幅下降，研究人员认为原有的 SWE-Bench Pro 结果可能高估了实际的软件工程能力。

近期方向：Harness、长时强化学习、验证成本

第一，“不能只看模型”。Harness 效应研究（paper）在 SWE-bench Pro、ProgramBench 和 GitTaskBench 三个基准测试上，比较了两种 Harness（mini-SWE-agent、OpenCode）与 Qwen、DeepSeek 系列的 10 个开放权重模型。Harness 的效果同时取决于模型能力和任务类型。在 SWE 式 issue 修复中，模型越强，复杂 Harness 带来的额外收益越小；但在更复杂、更开放的仓库任务中，即使是强模型也能从复杂 Harness 中获益。就组成部分而言，结构化工具使用和任务专用子智能体带来的帮助最为稳定，而上下文压缩和通用子智能体有时会降低仓库生成性能。

第二，用强化学习训练长时任务的方法。在长时任务中，一个小错误就可能毁掉整个 rollout，成功的轨迹很少。从头重新开始效率低下，而只回退对话上下文和工作目录，又会遗漏已安装依赖等环境变化。SPROUT（paper）在每一轮同时将文件系统和智能体上下文保存为检查点，并通过由验证器引导的回退策略，选择从哪里继续失败的尝试。研究报告称，在长时编码任务上相比 pass@k（k 次尝试中只要有一次成功即视为解决的指标）最多提升 23.6%，而 token 用量仅为 32～52%。在 Qwen3.8-27B 的训练中，它在三个基准测试上比标准 GRPO 高 13.9 分，每个训练步的时间减少 39.5%。

第三，测试时计算的成本问题。生成多个候选轨迹并从中挑选最好的一个可以提升性能，但验证长记录所需的 token 可能与生成一样多。LatentSift（paper）不再用 LLM 验证器再读一遍，而是将策略模型在生成过程中已经产生的隐藏表示（Hidden Representation）与成功、失败案例进行比较来筛选候选。在 SWE-bench Verified 上，当 K=16 时，它将无需执行的验证器 token 减少了 66.6～81.0%，将包含测试生成在内的总验证 token 减少了 49.1～62.1%；在 DeepSWE-Preview 上，Best@16 从 59.26% 提升到 60.06%。

局限与争议：分数能说明什么，又不能说明什么

首先要指出的是基准测试的可信度。正如 SWE-Bench Pro Verified（paper）所示，答案泄露和任务缺陷会抬高分数。用于防止数据污染的非公开数据集（paper），也无法解决测试本身未能正确检验 issue 的问题。查看排行榜数字时，应先确认是哪个数据集，以及是否经过了泄露封堵和任务验证。

第二，比较单位的问题。根据 Harness 效应研究（paper），性能并不只由基础模型决定。同一个模型换了 Harness，结果就会不同，而且这种效应的方向甚至可能随任务类型而改变。尝试次数也很重要。像 pass@k 或 Best@16 这样经过多次尝试再挑选的分数，与一次答对的分数含义不同。

第三，基准测试之外的工作。规格驱动开发研究（paper）总结指出，行业报告中出现了个人生产力提升、而团队吞吐量、评审能力和稳定性下降的“生产力悖论”，并主张应以团队为单位建立充当人与智能体之间契约的规格说明，以及约束智能体行为的 Harness。MAGE（paper）也认为，编码智能体虽然提升了实现能力，却不会自动揭示项目意图、系统结构和验收依据。通过测试来修复一个 issue 的能力，与判断应接受什么的能力，是两个不同的问题。

延伸学习

作为起点，建议先读 SWE-Bench Pro（paper）。仓库级任务如何构建、为何要分为公开集、保留集和商业集、智能体以何种方式失败，都在这一篇中。接着阅读 SWE-Bench Pro Verified（paper），可以对比了解同一基准测试的分数会通过哪些途径被抬高。

如果你要亲自构建或选择智能体，Harness 效应研究（paper）更贴近实际。它逐一开关工具列表、上下文压缩、规划、子智能体等组成部分并观察效果，有助于判断应优先加入哪些机制。若想了解 issue 修复之外的工作，可以一并阅读 USEagent（paper）。

如果关注模型训练，可以通过 SPROUT（paper）了解长时任务强化学习的瓶颈，通过 LatentSift（paper）了解从多个候选中挑选时的验证成本问题。团队与组织视角则由规格驱动开发研究（paper）和 MAGE（paper）讨论。