27. SWE-bench：执行结果驱动的 Coding Agent 评测
Benchmark 专题 · 3～5 小时
学习目标
- 理解真实 Repository Issue Eval
- 掌握 Patch + Test 的执行型评分思想
- 认识测试覆盖和 contamination 风险
前置知识
- 基本 Git / Test 知识
- 第 9、23 章
本章产物： 设计一个内部 Coding Agent Regression Case。
27.1 为什么 SWE-bench 成为代表性 Benchmark
任务来自真实 GitHub issue 和对应代码库。Agent 需要：
理解 Issue
↓
阅读 Repository
↓
修改多个文件
↓
运行测试
↓
生成 Patch这远比“写一个独立函数”更接近软件工程 Agent。
27.2 最重要的思想：执行测试
Coding Agent 最终评价应该尽可能基于：
Does the patch actually fix the problem?而不是 Judge 觉得代码“看起来不错”。
27.3 Test Coverage 决定 Reward 可信度
如果测试只检查一小部分行为，错误 Patch 也可能 PASS。
所以 Benchmark 的 Evaluator 和软件项目本身的 tests 同样重要。
27.4 Repository Snapshot
必须固定：
- commit；
- dependency；
- environment；
- test command；
- patch application；
- timeout。
否则历史版本难以复现。
27.5 Internal SWE Eval
企业内部可以从历史 Issue 构造：
issue description
repo snapshot
hidden tests
expected behavior不要把真实修复 PR 直接暴露给 Agent。
27.6 Coding Agent Trace
分析：
- file search；
- code read；
- test execution；
- patch iteration；
- repeated failures；
- context cost。
最终测试 PASS 是主证据，Trajectory 用于诊断。
27.7 污染与记忆
热门开源 Repository 可能被模型训练过，所以内部 fresh issue / private repo 更接近泛化能力。
27.8 验收问题
- SWE-bench 为什么比 HumanEval 更像 Agent Eval？
- Hidden Test 不充分会造成什么问题？
- 为什么 Repository commit 必须固定？