BeyondSWE：当代码智能体离开单一仓库

测量了错误的东西

SWE-bench Verified 80%+ 的解决率，三年来一直是 coding agent 采购评估的默认基准。但这个数字测量的是单仓库、单 commit 的 bug 修复能力。

真实世界的软件工程不是这样的。开发者要跨仓库推理、做依赖迁移、理解领域特定约束、，有时候要从规格说明生成完整代码仓库。

BeyondSWE（中国人民大学 / BAAI，arXiv:2603.03194v1）做了一件简单的事：把评测轴扩展到真实软件工程的范围。结果是，即使最前沿的模型，成功率也停滞在 45% 以下。

BeyondSWE 按两个正交轴组织任务：解决范围（local function → global repo）和知识范围（仓库内部 → 外部知识）。

CrossRepo：跨仓库方案复用。给定一个目标仓库里的问题，需要从其他仓库找到相似实现并适配。平均 190 行代码，跨 4 个文件。

DomainFix：领域专属问题求解。需要生物信息学、金融或物理领域的知识才能正确理解和修复问题，而不是靠通用编程能力。

DepMigrate：大规模依赖迁移。升级或降级一个库的版本，同时修复因此产生的全部连锁破坏。平均 281 行代码变更，跨 8+ 文件。

Doc2Repo：从规格说明生成完整仓库。从人类可读的规格文档重建整个项目结构，平均 3528 行代码，跨 26 个文件。

这四种任务和 SWE-bench 的核心区别不在难度，在知识来源。SWE-bench 所有信息都在给定的仓库里；BeyondSWE 要求模型调用外部知识。

论文还做了另一个有意思的实验：SearchSWE，一个把深度搜索集成到 coding agent 工作流的框架。直觉上，当 agent 遇到不熟悉的任务时，搜索外部知识应该有帮助。

结果相反：搜索增强带来的收益不一致，有时候反而降低性能。最反直觉的发现：Seed-Coder（专门针对代码训练的模型）加入搜索后性能下降得比通用模型更厉害。

这不是说搜索没用，而是说搜索能力和编码能力是独立成熟的。模型在预训练和 post-training 阶段把这两者分开学，分开强化，但真实任务要求它们紧密交织。简单地给一个编码 agent 加一个搜索模块，不能产生「搜索和推理交错进行」的开发者式工作流。

这个发现值得记住。社区里有一种常见的建议：「当 agent 遇到不熟悉的内容时，让它多搜索」。BeyondSWE 的数据指向一个更复杂的画面：搜索的质量和时机比搜索的频率重要得多，而且对于某些模型，加搜索反而引入更多噪声。

BeyondSWE 的另一个结论：没有单一模型在所有任务类型上都表现良好。

这意味着采购评估时只看一个综合分数是不够的——不同的任务类型暴露了不同的能力短板。如果你的场景是跨仓库的代码复用，选一个在 CrossRepo 上强的模型；如果你的场景是依赖迁移，选在 DepMigrate 上强的。

而当前所有模型的共同天花板是 45% 以下，说明整个领域在跨仓库推理这件事上还没有突破。

FeatureBench（ICLR 2026）揭示了 63 分的悬崖：Claude Opus 4.5 在 SWE-bench 上 74%，在 FeatureBench 上 11%。BeyondSWE 的 45% 上限和 FeatureBench 的 11% 不是同一个数字，但指向同一个方向：

当前模型擅长的是「从给定 patch 反向还原目标状态」，不擅长的是「从高层需求自己规划目标状态并获取所需知识」。

这两个 benchmark 从不同角度证明了同一个能力天花板。SWE-bench 体系的分数正在变成一个过时的指标。

参考