用 SWE-bench Harness 评测 DeepSeek 编程能力：从补丁生成到 Docker 判分

SWE-bench 不是把 issue 文本发给模型后做字符串匹配。完整流程分为两段：模型或 Agent 阅读仓库与 issue，生成 Git patch；官方 Harness 再把 patch 应用到指定提交，在隔离的 Docker 环境中运行测试，判断问题是否真正解决。

一、先验证评测环境

SWE-bench 官方建议先用 gold patch 验证 Docker、镜像和测试链路。这个步骤不调用 DeepSeek，却能提前排除大量环境问题。

git clone https://github.com/SWE-bench/SWE-bench.git
cd SWE-bench
pip install -e .
swebench eval lite --gold -i sympy__sympy-20590 --run-id validate-gold

官方文档提醒完整评测资源开销较高，并建议准备充足的 x86_64 CPU、内存和磁盘。第一次不要直接并发跑完整数据集。

二、让 DeepSeek 生成预测补丁

生成阶段需要你自己的 Agent 或脚本：检出数据集指定的 base_commit，把 issue 和必要仓库上下文交给模型，允许其检索、编辑并运行测试，最终导出统一 diff。API Key 只应存在于生成环境，不应进入预测文件。

Harness 接受 JSONL，每行至少包含以下字段：

{"instance_id":"sympy__sympy-20590","model_name_or_path":"deepseek-v4-pro","model_patch":"diff --git a/..."}

model_patch 必须是可由 Git 应用的补丁，不是 Markdown 代码块、文件全文或修改说明。生成失败也应保留空补丁与失败原因，避免只提交成功样本造成选择偏差。

三、运行 Docker 判分

swebench eval lite -p ./predictions/deepseek.jsonl --run-id deepseek-v4-pro-20260904 -j 4

旧版的 python -m swebench.harness.run_evaluation 入口仍可用，但新项目宜优先按当前 Quick Start 使用 swebench eval。并发数应与 Docker 可用 CPU 和磁盘吞吐相匹配。

四、避免 run_id 缓存陷阱

Harness 会按 run_id 和 instance_id 缓存结果。如果修改了某个预测补丁却沿用原 run_id，可能继续读到旧结果。每次模型、Prompt、工具策略或补丁变化，都应创建新的、有语义的 run_id。

五、正确阅读结果

resolved：补丁应用后，要求的测试通过。
unresolved：评测完成，但补丁没有解决问题。
empty patch：没有可执行补丁，不能当作基础设施错误忽略。
error / infrastructure failure：容器、镜像、补丁应用或超时导致无法可靠判分，应查看实例日志。

最终报告应同时给出 resolved 比例、提交覆盖率、空补丁率、基础设施失败数、平均调用成本和生成阶段成功率。若只展示 resolved 数字，读者无法判断模型能力和工程稳定性分别贡献了多少。

SWE-bench 测到的是“模型 + Agent 工具链 + 上下文策略 + 执行环境”的组合能力，不能简单等同于裸模型代码能力。