163道仓库题平均只解31.5%,近半失败出在隐式需求

A Unified Issue Resolution Benchmark for Requirement Clarification, Planning, and Code Generation for Coding Agents

Xin Zhou, Chun Yong Chong, Kisub Kim, Yun Peng, Rui Shu, Zihan Wu, Xu Han, Guowen Yuan, Zeyang Zhuang, Jounghoon Kim, Jeongjin Ju, Seongmin Ju, Taein Yoon, David Lo

cs.SE, cs.AI

2026-08-10

新加坡管理大学等用31个Python与Java仓库的163道真实PR评三家主流coding agent。平均只解31.5%,最好的OpenCode配Kimi-K3也只有49.7%;失败里需求澄清占24.5%到46.0%。

这篇在解决什么

仓库级 coding agent 现在的主流考法,还是 SWE-bench 那一套:改完跑测试,过了就算解决。真实把 issue 做成正确改动,中间要补全没写明的约束、在仓库里排实施步骤、再写成代码。最终 0/1 看不出失败发生在哪一段。

RACE-bench、Dialogue SWE-Bench 开始碰中间过程,但前者不提供「原需求里没写、实现时又必须有」的隐式需求参考,后者用故意删细节再对话补回的合成设定。SWE-RPG 想回答的问题更硬:失败时,主因到底是需求澄清、实施规划,还是写代码。

方法

163 题来自 31 个成熟 Python/Java 仓库的已合并 issue–PR,113 道修 bug、50 道加功能,Java 85 / Python 78。漏斗很狠:2000+ 候选,可跑环境 400+,稳定测试 200+,中间 GT 审过只剩 163。仓库平均 27.3 万行,最大 159 万行;gold patch 平均 56.7 行,每题平均 2249 个测试。

需求 GT 来自对 10 位 Fortune Global 500 工程师的研讨式访谈,压成六类问答:功能意图、业务语义、技术上下文、接口协议、结构命名惯例、数据结构语义。每题平均 4.53 个隐式澄清点。规划 GT 是可执行步骤(平均 2.06 步、11.80 条约束):每一步要对上 gold subpatch,让 coding agent 按该步能写出功能等价实现,通不过就改步骤。两边都由两名作者独立复核。合成阶段用的是当时最新的 GPT-5.4。

评测矩阵是 3 个架子 × 6 个后端,每配置每题跑两次。架子:Claude Code、Codex、OpenCode。后端:Claude-Sonnet-5、DeepSeek-V4-Pro、GLM-5.2、GPT-5.6-Terra、MiniMax-M3、Kimi-K3。Resolve 定义跟 SWE-bench 一样:patch 能应用、fail-to-pass 全过、pass-to-pass 不回归。失败归因用 GPT-5.6-Sol 当 judge,对齐到最早偏离的阶段;50 条分层样本里 46 条与人工一致(92%)。覆盖判定同意率 96%。

结果

18 组配置平均 Resolve 只有 31.5%。最好是 OpenCode×Kimi-K3 的 49.7%,Claude Code×Kimi-K3 49.1%,最弱 Codex×MiniMax-M3 17.8%。架子均值:OpenCode 33.0%、Claude Code 32.8%、Codex 28.5%。后端均值:Kimi-K3 46.6%,DeepSeek-V4-Pro 38.7%,其余 22.3%–29.2%。单题平均成本 $1.59、平均耗时 8.5 分钟。Kimi-K3 配 OpenCode 在均线以下成本拿到最高分;同一后端配 Claude Code 更贵。时间更长并不稳定换来更高分。

失败切到阶段后,需求失败是多数配置里最大一块,占全部 run 的 24.5%–46.0%;写代码 7.4%–37.4%;规划 5.5%–17.8%。论文把 46.7% 的 run 记成死在需求或规划。相近的总分可以完全不是同一类病:Codex 和 Claude Code 配 DeepSeek-V4-Pro 分别 40.5% 和 39.3%,但需求失败是 26.4% vs 40.5%,实现/验证失败是 23.9% vs 7.4%。

规划覆盖从「改哪里」掉到「怎么改、怎么验」:Claude Code 79.7% → 64.5% → 41.6%,Codex 65.6% → 49.0% → 37.1%,OpenCode 43.8% → 31.1% → 24.8%。澄清侧,意图和范围还行,接口、结构惯例、数据语义更差:Claude Code 结构 54.2%,Codex 结构 42.0%、数据语义 41.9%。

为什么重要

这是给 agent 研发看的诊断基准,不是又一张排行榜。总分接近时,该补的模块可能完全相反:有的该加强隐式约束回收,有的该把验证义务写进计划。隐式需求是最大头,符合一线工程直觉,issue 很少把「只改 TSV、CSV 行为不许动」写全。

规模比 SWE-bench Verified 小很多,语言也只有 Python 和 Java。拿它当训练信号或日常回归可以,拿它宣布某架子「全面更强」还早。

局限与存疑

作者自己列了:163 题、31 仓、只有 Python/Java;全程无人类反馈,测的是一次性自治;中间 GT 和归因标签都靠 LLM 辅助,虽经人工审,但没报标注者一致性。judge 只在 50 条样本上对过。GT 从已合并 PR 反推,带事后视角,真实开发时这些约束未必事先清楚。规划平均只有 2.06 步,对大改动的计划复杂度可能不够。评测模型名单偏 2026 年中的商业模型,开源小模型没进矩阵。

术语

原文与代码

社区讨论

相关论文

全部论文解读