为什么重要
传统仓库级基准（如 SWE-bench）只评测”最终 patch 是否通过测试”，一个 pass/fail 结果无法解释失败轨迹到底在哪一步偏离——是没读懂需求、规划错了，还是代码写坏了。SWE-RPG 是首个把仓库级 Issue 解析拆成需求澄清、实现规划、代码生成三个阶段分别评测的基准，通过经验证的中间 GT 对完整 agent 轨迹做”GT 对齐的回顾式诊断”。
这填补了一个关键空白：让”未解决”这一结果从黑盒变成可归因的诊断信号，直接指向该修的能力。
构建方式
- 163 个任务来自 31 个 Python/Java 真实仓库，含 113 个 bug fix + 50 个 feature addition。
- 三层 GT：
- 需求澄清 GT：以问答形式给出原请求中隐含的实现关键需求，分 6 类（功能意图/业务语义/技术上下文/接口协议/代码结构与约定/数据结构语义）。
- 实现规划 GT：有序可执行步骤，通过”从每步生成 patch 并验证语义等价”来保证可复现。
- 可执行 patch oracle：来自合并 PR 的 fail-to-pass / pass-to-pass 测试作为最终正确性判据。
- 评测对象：3 个 agent 框架（Claude Code、Codex、OpenCode）× 6 个 LLM 后端（Claude-Sonnet-5、GPT-5.6-Terra、Kimi-K3、DeepSeek-V4-Pro、MiniMax-M3 等）。
- LLM 判断器将 agent 轨迹与 GT 对齐，把每个未解决任务归因到最早偏离的阶段（需求/规划/代码生成/其他）。
关键发现
- 平均 resolved 率仅 31.5%：当前主流 coding agent 在真实仓库实现用户请求的能力仍显著不足。
- 隐式需求恢复是最大瓶颈：需求失败占 24.5%–46.0% 的 run，远超代码生成（7.4%–37.4%）和规划（5.5%–17.8%）。
- 相同 resolved 率背后是不同瓶颈剖面：Codex 与 Claude Code 搭配 DeepSeek-V4-Pro 的 resolved 率接近（40.5% vs 39.3%），但需求失败率分别为 26.4% 和 40.5%——端到端分数会掩盖真实差异。
- 澄清覆盖集中在高层意图：三个 agent 都能较好覆盖 intent/scope，但在接口契约、代码结构、数据语义等实现层面覆盖明显下滑（如 Claude Code 结构覆盖仅 54.2%）。
- 规划覆盖呈阶梯式衰减：从 target location（79.7%）→ implementation approach（64.5%）→ constraints/validation（41.6%），agent 常”知道改哪、却说不清怎么改和怎么验证”。
局限性与展望
- 163 个任务规模较小（相对 SWE-bench Verified），仅 Python/Java，多语言与生态泛化未覆盖
- agent 全程自主端到端运行，无法评估人类反馈/交互式迭代的效果
- 中间 GT 与回顾式对齐标签依赖 LLM 辅助构造与判定（虽经人工验证，但独立标注团队的复现验证尚缺）
- 未来方向：扩展任务/模型覆盖、强化标注审计与标注者间一致性
关联基准
- SWE-bench Pro：仓库级 Issue 修复
- Tencent WorkBuddy Bench：多领域抗污染代码 Agent
- DeepSWE：零污染 SWE 基准