自己复现 DeepSWE 基准DeepSeek 官方跑分到底怎么测出来的DeepSeek V4-Pro 正式版在 AI 编程智能体基准 DeepSWE 中从预览版的 12.8% 飙升至 62.7%。这个数字你以为只能看新闻其实 DeepSeek 官方把跑分用的基础设施也开源了——V4 Flash 和 V4 Pro 公布的 Agent 基准成绩都跑在 Harness 的极简模式下。这意味着官方跑分是可以自己复现的。这一篇带你把完整链路走一遍拉取环境、配置模型、跑极简模式、解读分数。一、先说清楚DeepSWE 是什么DeepSWE 是一个 AI 编程智能体基准Benchmark测试的是「AI 能不能像真实工程师一样解决真实软件问题」——给定一个真实 GitHub 仓库和一段失败的测试看 Agent 能不能独立修复。数值含义12.8%V4-Pro 预览版的 DeepSWE 得分62.7%V4-Pro 正式版的 DeepSWE 得分国产最强这个跃升背后既是模型后训练优化的功劳也离不开 Harness 这个「执行层」的配合——官方基准就是在 Harness 极简模式上跑的。矩阵关键点DeepSWE 得分 模型能力 × 执行框架能力。换执行框架得分就会变。二、为什么「复现官方跑分」有意义很多人觉得复现跑分是「闲得慌」但至少有三个实际价值验证模型差异你在用 V4 Flash 还是 Pro本机实测一次就知道你的模型真实能力有多强调你的 Harness每次改插件、调配置跑一遍基准看分数涨不涨——这就是最硬核的回归测试对比评测方法官方说「极简模式只留两个工具跑分」你自己跑一遍就知道是真话还是宣传。一个可复现的基准就是一套可迭代的调优闭环。三、环境准备复现需要的东西不多依赖说明Node.js LTSHarness 内核Python 3.10Python SDK / 评测脚本DSF_API_KEYDeepSeek API Key跑分会烧钱建议先用小样本官方推荐直接拉源码装git clone https://github.com/deepseek-ai/deepseek-harness.git cd deepseek-harness pnpm install pnpm run build四、配置模型极简模式 V4 Flash官方BENCHMARK.md里有详细指引。核心思路用 Harness 的极简模式只挂 bash 文件编辑两个工具跑基准这样能尽量排除「工具增强」的干扰测出模型 最小执行层的真实水平。Python SDK 侧的最小调用接系列第 4 篇from deepseek_harness import DeepSeekHarness with DeepSeekHarness( providerdeepseek-official, modeldeepseek-v4-flash, cwdstr(workspace), # 被测仓库的工作副本 session_rootstr(sessions), # 会话日志落盘 ) as harness: result harness.run( Inspect the repository and fix the failing tests., session_idfdeep-swe-{task_id}, )注意两点每个任务用独立 workspace克隆一份仓库副本互不污染每个任务用独立 session_id因为 DeepSWE 的每个 issue 是独立任务不该共享 shell 状态。五、跑分的关键一份标准评测脚本可以把官方流程封装成你的评测脚本import json, subprocess from pathlib import Path from deepseek_harness import DeepSeekHarness TASKS json.load(open(deep-swe-tasks.json)) # 任务清单repo issue def run_task(task): repo, issue_id task[repo], task[issue_id] ws Path(./work) / f{repo}-{issue_id} subprocess.run([git, clone, fgitgithub.com:{repo}.git, str(ws)]) subprocess.run([git, checkout, task[base_commit]], cwdws) with DeepSeekHarness( providerdeepseek-official, modeldeepseek-v4-flash, cwdstr(ws), session_rootstr(ws / .sessions), max_tokens49_152, ) as harness: result harness.run(task[prompt], session_idfswe-{issue_id}) passed subprocess.run( task[test_command], cwdws, shellTrue, capture_outputTrue ).returncode 0 return {task: issue_id, passed: passed, output: result} results [run_task(t) for t in TASKS[:5]] # 先用 5 个小样本验证链路 score sum(r[passed] for r in results) / len(results) print(fDeepSWE 复现得分: {score:.1%})跑这个脚本前先回答一个灵魂问题你的测试命令怎么定官方基准用隐藏的测试用例判分你自己复现时只能用仓库自带的测试命令近似——所以你的得分会比官方略低官方用你猜不到的隐藏用例。这是正常现象不代表模型不行。六、跑完怎么解读分数假设你跑了 5 个 issue2 个修好得到 40%。怎么解读现象可能原因下一步得分远低于官方你用隐藏测试判分官方可能用了真隐藏测试对比官方选用的子集某些 issue 稳定失败模型热点领域问题 / 仓库冷启动慢换 V4 Pro 对比修好了但测试没过判分方式不同官方可能有更宽松的断言检查是代码问题还是判分问题时间超长 / Token 爆炸上下文压缩没开 / 缓存没打上回到第 6 篇的省钱策略最重要的对比不是「跟官方比」而是跟你自己的基线比上次跑 30%这次改完配置跑 35% → 配置有效Flash 跑 25%Pro 跑 40% → 模型差距量化了极简模式 25%标准模式 32% → 「工具增强」值 7 个点这些数字比任何「体验评测」都有说服力。七、复现的注意事项避坑清单先小样本验证链路别上来就全量跑5 个 issue 能跑通再扩量注意上下文边界V4-Flash 的上下文窗口有限超长仓库要开上下文压缩沙箱不是摆设给 Agent 克隆副本不是真实项目跑完直接删缓存策略前后任务的相似 prompt 会命中缓存成本大降接第 6 篇记录 session trace每个任务的会话日志落盘失败时回头分析 Agent 在哪个环节卡住。复盘的时候session trace 是金矿——它记录了 Agent 每一步做了什么、每轮思考是什么比跑分数字本身更能暴露问题。八、小结DeepSWE 是「模型 执行层」的综合基准官方跑分复现链路已开源Harness 极简模式复现步骤拉源码 → 配模型 → 最小脚本跑任务 → 用自带测试近似判分复现的价值不在「追上官方」而在「建立自己的基线」量化每次配置迭代避坑小样本先行、副本隔离、trace 复盘下一篇我们不看代码了看生态盘点 dsh-plugin 这个刚出生就破千的插件宇宙聊聊为什么说「Agent 时代的应用商店」可能正在这里萌芽。八、补充读懂 trace 日志——复现的真正价值在复盘为什么跑完分不是终点很多人复现基准只盯着那个百分比其实分数只是结果trace 才是矿。每个任务的 SessionEvent 日志完整记录了 Agent 的每一步读了哪个文件、执行了什么命令、在哪个环节改错了方向。把失败任务的 trace 读一遍你对「Agent 为什么会失败」的理解会突飞猛进。失败模式分类学实测常见五类失败类型trace 特征改进方向定位失败Agent 反复 grep 却从不读关键文件提示词补充「先看测试报错堆栈」理解偏差改对了文件但改错了逻辑方向模型能力问题换更强的模型对比验证缺失改完不跑测试就宣布完成强制「修改后必须运行测试命令」死循环同一命令重复执行 5 次以上加轮次上限 重复检测环境干扰依赖没装好导致测试本身跑不起来任务模板里加 setup 步骤前三类靠工程手段能救第四五类靠流程约束能防——这就是复现的价值把玄学的「AI 不行」拆成可修复的工程问题。复现的开销核算别跑破产给一组参考数字帮你控制预算单个 DeepSWE 任务平均消耗数万到十几万 Token取决于任务难度和 Agent 轮数用 V4-Flash 缓存复用单任务成本可压到几毛钱人民币级别用 V4-Pro 会贵数倍建议路径先用 Flash 跑 5 个小样本验证链路花费可忽略链路通了再决定要不要上 Pro 跑大样本。另外别忘了时段全程安排在低谷时段跑单价再打对折。评测是典型的「可延迟批量任务」没有任何理由在高峰时段烧钱。建立你自己的回归基线复现一次只是快照持续复现才是资产。推荐的迭代闭环固定 10~20 个代表性任务作为「私有基准集」每次改配置/换模型/升级 Harness 版本跑一遍基准集记录通过率、平均轮数、平均 Token、平均耗时四个指标通过率回升才允许合并配置变更——把 Agent 调优变成有门禁的工程流程。官方开源了跑分工具链等于把「AI 效果玄学」的最后一块遮羞布也掀掉了。剩下的事只有一件动手。九、补充DeepSWE 任务分类与难度分布任务从哪里来DeepSWE 的任务集来自真实 GitHub 仓库的 issue涵盖多种语言和项目类型语言占比约典型任务Python45%修函数逻辑 bug、补类型标注、修测试JavaScript/TypeScript25%修组件渲染、补边界条件Java15%修 NPE、修并发问题Go / Rust / C10%修内存问题、修接口实现其他5%Shell 脚本、配置文件难度分层官方把任务按「修复所需推理深度」分为三档Easy约 30%单文件、单函数、明确报错信息。V4-Flash 能修好 60%Medium约 50%跨 2-3 个文件需要理解调用链。V4-Flash 约 35%V4-Pro 约 65%Hard约 20%跨模块架构问题需要理解设计意图。V4-Pro 约 40%。62.7% 的总分是加权平均。如果你只关心「能不能修日常 bug」看 EasyMedium 的子集得分更有参考意义——那个数字比 62.7% 更接近日常使用体验。复现时如何选任务子集全量跑成本高建议按需选子集验证链路选 5 个 Easy Python 任务跑通即可模型对比选 20 个 Medium 任务Flash vs Pro 对比配置迭代选 30 个固定任务作为回归集每次改配置跑一遍论文级复现全量任务按官方BENCHMARK.md的判分方式严格对齐。十、补充复现结果如何写进报告与简历复现跑分最终要落到「能给别人看」的产出上否则只是一堆日志。写报告和简历时核心是把三个素材翻译成可验证的结论复现分数、解决率、trace 复盘结论。报告里写「方法 基线 增量」。不要只写“跑了 DeepSWE 得 40%”要写清楚在 Harness 极简模式下用 V4-Flash 对 20 个 Medium 任务复现基线通过率 35%加入「修改后必须运行测试」约束后提升到 45%。这种写法让读者能复现你的实验也能看出你的贡献点。简历里写「做过什么 量化结果 可复现性」。例如“基于 DeepSeek Harness 搭建 DeepSWE 基准复现流水线完成 30 个真实 issue 的自动修复评测V4-Pro 解决率 62%并将失败任务按 trace 归为五类形成可落地的提示词与流程优化方案。”这里的关键不是数字本身而是数字有对照、过程有记录、结论可追溯。避免夸大成绩三条红线要守住不要把你的自测分说成官方分——你用仓库自带测试近似判分和官方隐藏测试不是一回事不要把小样本当结论——5 个任务跑出 40% 不能写成“达到 40% 解决率”要标注样本量和任务子集不要只报最好的那次——多次实验取均值或报告区间并说明模型、模式、成本等条件。真正有说服力的写法是“在 XX 条件下测得 XX与官方 XX 的差距来自判分口径”而不是“跑分 XX很强”。报告和简历里的每一个数字都应能被你的 session trace 和评测脚本重新拉出来——这才是把基准测试写进履历的底气。标签#DeepSeek #DeepSWE #基准测试 #AI Agent #Harness