为什么重要
现有代码基准（SWE-bench、SWE-Lancer 等）依赖人工策划的 GitHub issue，扩展困难、评测易饱和，且无法区分局部推理与系统级推理。Breakpoint 填补了这一关键空白：
- 可自动扩展：通过对真实仓库函数进行对抗性破坏（corruption），可自动生成任意数量的新任务，无需人工策划
- 难度可控：沿两个正交维度控制系统化控制难度——局部推理（代码复杂度）和系统级推理（调用图中心性 + 同时破坏的函数数量）
- 区分推理类型：首次明确区分局部推理 vs 系统级推理，发现推理时间预算增加主要改善局部推理，对系统级推理帮助有限
构建方式
两种破坏模式
- Remove 模式：删除函数体，模型需推断原始实现
- Discovery 模式：由另一个 SWE Agent 引入更隐蔽的破坏，模型需先发现破坏位置再修复
难度控制维度
| 维度 | 指标 | 说明 |
|---|---|---|
| 局部推理 | 圈复杂度 (Cyclomatic Complexity) | 被破坏函数自身的代码复杂度 |
| 系统级推理 | 调用图中心性 (Call-graph Centrality) | 被破坏函数在调用网络中的核心程度 |
| 系统级推理 | 破坏集大小 (Corruption Set Size) | 同时破坏的相互依赖函数数量 |
生成流程
- 处理真实 GitHub 仓库，提取候选函数
- 按圈复杂度和调用图中心性筛选
- 生成 remove 模式或 discovery 模式的破坏
- 在 Docker 容器中验证任务可解性
关键发现
- 难度可无限扩展：最简单任务成功率 55%，最难任务成功率 0%，证明 Breakpoint 能持续区分模型能力
- 推理时间预算的边际效应：增加推理时间预算（more inference compute）主要提升局部推理能力，对系统级推理提升有限
- 模型策略差异显著：不同模型在信息收集策略上差异巨大——有的偏好广泛浏览代码，有的直接开始修复
- 系统级推理是真正的瓶颈：即使是最强的模型，在面对需要协调多个相互依赖函数的修复时，成功率趋近于零
- SWE-bench 饱和问题：Breakpoint 的自动生成能力使其不会像 SWE-bench 那样快速饱和
与 SWE-bench 的对比
| 特性 | SWE-bench | Breakpoint |
|---|---|---|
| 数据来源 | 人工策划 GitHub issue | 自动对抗性破坏 |
| 扩展性 | 受限于人工策划 | 可自动生成无限任务 |
| 难度控制 | 无法系统控制 | 沿两个维度精确控制 |
| 推理类型区分 | 无法区分 | 明确区分局部/系统级 |
| 饱和风险 | 高（Verified 已达 93.9%） | 低（最难任务仍为 0%） |
| 数据污染 | 已确认存在 | 通过动态生成规避 |
局限性
- 目前仅支持 Python/pytest 仓库
- 对抗性破坏生成的任务与真实 GitHub issue 在语义上有差异
- Discovery 模式的质量依赖于生成破坏的 Agent 能力
- 930 个任务覆盖 30 个仓库，仓库多样性仍有限
关联基准
- SWE-bench Verified：人工验证的代码修复基准
- SWE-bench Pro：高难度企业级代码修复
- Terminal-Bench 2.0：终端环境操作评测
- Aider Benchmark：代码编辑能力评测
编者评
Breakpoint 代表了代码基准设计的范式转变——从”人工策划 + 固定数据集”转向”自动生成 + 难度可控”。其核心洞察是：真正的软件工程能力不仅仅是修复单个 bug，而是理解并协调复杂代码库中的多个组件。930 个任务中，SOTA 模型在最简单任务上仅 55%，最难任务上 0%，这比 SWE-bench Verified 上 93.9% 的 SOTA 更能反映 AI 编程助手的真实能力边界。随着 LLM 在 SWE-bench 上快速饱和，Breakpoint 这类可自动扩展、难度可控的基准将成为评测的新方向。