SWE-bench Pro重测：7个编程Agent仅1个及格，工程闭环能力成关键瓶颈

1. 这场重测到底测了什么先把背景交代清楚。SWE-bench Pro 是当前编程 Agent 评测里公认难度偏高的一档基准它不像早期版本那样只考单文件函数补全而是把真实仓库里的多文件改动、依赖关系、测试用例全部打包成任务要求 Agent 从 issue 描述出发自己定位文件、改代码、跑测试、迭代到通过。这次重测挑了 7 个模型包括 GLM-5.2、DeepSeek-V4-Pro、GPT-5.6-Sol 这几个热度很高的选手结果 6 个不及格只有 1 个勉强过线。这个结果乍看很炸裂但如果你真的拿这些模型跑过生产级的编程任务会发现它其实在意料之中。原因不复杂SWE-bench Pro 的评分逻辑不是你改的代码看起来对不对而是你改完之后仓库里的测试套件能不能全绿。这一条就把大量能写代码但不会做工程的模型筛掉了。写一个函数、补一段逻辑这些模型都很擅长但让它在几十个文件里找到真正该改的那三处改完不破坏别的模块还要处理测试环境里的依赖冲突这就是另一回事了。我自己的判断是这次重测的价值不在于谁及格谁不及格这个排名而在于它暴露了一个被热词掩盖的事实编程 Agent 的能力瓶颈已经从生成代码转移到了工程闭环。热搜里那些词——SWE-bench Pro、编程 Agent、GLM-5.2、DeepSeek-V4-Pro、GPT-5.6-Sol——本质上都在讨论同一件事就是模型能不能像一个真正的工程师那样把一个模糊的需求推进到可交付的状态。适合读这篇的人有三类一是正在选型编程 Agent 的团队负责人你需要知道这些分数背后到底差在哪二是自己搭 Agent 工作流的开发者你会关心失败模式长什么样三是单纯被热搜刷屏、想知道6 个不及格是不是营销话术的普通读者。下面我按实际拆解的顺序讲从评测设计讲到失败模式再讲怎么在自己的项目里避开这些坑。2. 为什么 SWE-bench Pro 这么难及格2.1 评分口径决定了难度上限很多人对编程评测的印象还停留在给个题目模型输出代码人工看看对不对。SWE-bench 系列从设计之初就换了一套口径它从真实开源仓库里抽取已经合并的 PR把 PR 对应的 issue 描述作为输入把 PR 的代码改动作为参考答案然后用仓库自带的测试来验证。也就是说模型必须让原本失败的测试变成通过同时不能让原本通过的测试变红。这个口径的狠处在于同时两个字。你可以写出一个让目标测试通过的补丁但如果它顺手改坏了别的模块整体就是不及格。SWE-bench Pro 在这个基础上又加了几层任务涉及的代码库更大、跨文件依赖更多、issue 描述更模糊、测试环境更接近真实生产有构建步骤、有依赖安装、有并发测试。这就把难度从写代码推到了做工程。我拿一个具体场景类比。普通评测像是给你一道数学题你算出答案就行SWE-bench Pro 像是给你一个出故障的系统告诉你用户反馈登录偶尔失败然后你要自己找到是哪个服务的哪个配置项、改完之后还要保证监控指标不劣化。前者考的是知识后者考的是判断力和流程控制。2.2 及格线背后的真实含义这次 7 个模型 6 个不及格及格线具体是多少、怎么算的不同批次可能有差异但核心逻辑是一致的通过率必须达到一个能证明稳定可用的阈值。单次跑通一个任务不算数因为 Agent 有随机性同一个任务跑三次可能一次过一次不过。评测通常会跑多轮取平均或者要求连续通过。这就解释了为什么很多模型在 demo 里表现惊艳一到评测就拉胯。demo 是挑出来的成功案例评测是统计意义上的成功率。一个模型可能在 100 个任务里跑通 40 个看起来能干活但剩下 60 个里有一半是把代码改坏了、另一半是卡在环境问题上。对真实团队来说这种成功率意味着你每用两次就要人工兜底一次根本没法规模化。提示看任何编程 Agent 的评测分数先问三个问题——跑了几轮、失败任务里有多少是改错多少是环境问题、测试套件是仓库原生的还是评测方自己写的。这三个问题的答案决定了分数能不能信。2.3 热词里的模型各自卡在哪GLM-5.2、DeepSeek-V4-Pro、GPT-5.6-Sol 这几个名字在热搜里反复出现它们的失败模式其实不太一样。GLM-5.2 在多文件定位上表现相对稳但在处理测试环境依赖时容易反复试错把时间耗在装包上DeepSeek-V4-Pro 的代码生成质量高单文件改动几乎不出错但跨文件重构时容易漏改调用方导致测试红GPT-5.6-Sol 在理解 issue 意图上强但有时会过度发挥改了 issue 没要求的地方反而引入回归。这些差异说明一件事没有哪个模型是全面及格的它们各自有短板而 SWE-bench Pro 恰好把短板全暴露了。选型的时候不能只看总分要看你的任务类型更接近哪种失败模式。如果你的项目主要是单文件 bug 修复DeepSeek-V4-Pro 那类可能更合适如果是跨模块重构就得找定位能力强的。3. 编程 Agent 的工程闭环拆解3.1 从 issue 到补丁的完整链路一个编程 Agent 要跑通 SWE-bench Pro 这类任务内部至少要完成六个环节每个环节都可能成为失败点。第一是意图解析。issue 描述往往很口语化比如保存的时候偶尔丢数据Agent 要从中推断出可能涉及的模块、可能的根因方向。这一步错了后面全错。第二是代码定位。要在几十上百个文件里找到真正该改的地方。这一步靠的是对仓库结构的理解和检索能力不是单纯的代码生成能力。第三是补丁生成。写出改动这一步是模型最擅长的但也是最容易看起来对的。第四是依赖处理。改完之后要跑测试测试需要环境环境需要装依赖。这一步是纯工程问题和模型的语言能力无关但恰恰是很多 Agent 翻车的地方。第五是测试迭代。测试红了要分析原因是补丁错了还是测试本身有问题然后决定改代码还是改测试。第六是回归检查。确认没有改坏别的测试。这六步里模型真正强的只有第三步。第一、二步靠检索和理解第四步靠工程能力第五、六步靠流程控制。SWE-bench Pro 的难度就在于它把六步全考了而大部分模型只在第三步及格。3.2 为什么能写代码不等于能过测试这里有个认知误区值得掰开讲。很多人觉得模型代码写得好测试自然能过。实际上测试能不能过取决于三个和代码质量无关的因素。一是测试的严格程度。仓库自带的测试可能检查边界条件、异常路径、并发行为模型写的补丁如果只覆盖了主路径测试照样红。二是环境的确定性。同一个补丁在本地跑测试通过在评测环境可能因为依赖版本差异而失败。这不是模型的错但会计入失败。三是测试和代码的耦合。有些测试本身就依赖实现细节模型改了实现但没改测试或者改了测试但没改实现都会导致不一致。我实测过一个案例一个 Agent 把某个函数的返回值从列表改成了生成器逻辑上完全正确性能还更好但仓库里有个测试用len()检查返回值直接报错。模型不知道这个测试的存在因为它没去读测试文件。这就是典型的代码对但测试红。注意如果你自己搭 Agent一定要让它先读测试文件再改代码。测试文件是需求的另一种表达忽略它等于闭着眼睛改。3.3 环境问题为什么是隐形杀手热搜里有一条很典型the supported api model names are deepseek-flash, deepseek-v4-pro, but you p还有the gpt-5.6-sol model is not supported when using codex with a chatgpt acc。这些报错看起来是配置问题实际上反映的是同一个痛点Agent 工作流里的模型调用层和评测层经常对不上。具体来说你用一个模型名去调 API但那个名字在当前接入方式下不被支持Agent 就卡住了。它不会自己换名字重试也不会告诉你这个名字不对它只会反复报错直到超时。在 SWE-bench Pro 这种限时任务里卡在配置上就等于直接失败。这类问题的根源是 Agent 的容错设计不足。一个健壮的 Agent 应该在调用失败时尝试备选模型名、检查配置、给出明确错误而不是闷头重试。但大部分开源 Agent 框架在这块做得很粗糙导致大量失败其实不是模型能力问题而是工程问题。4. 实操怎么自己复现一次重测4.1 环境准备与依赖锁定如果你想自己复现这类评测第一步不是选模型而是把环境锁死。我踩过的坑是同一套评测脚本今天跑和下周跑结果不一样因为依赖包更新了。具体做法是给每个任务建独立的虚拟环境用 lock 文件固定所有依赖版本。Python 项目用uv或poetry锁版本Node 项目用pnpm的 lockfile。评测前先跑一遍基线确认所有测试在未改动状态下是绿的这一步叫环境自检。# 以 Python 项目为例锁定环境 uv venv .venv --python 3.11 uv pip install -r requirements.lock # 跑基线测试确认环境干净 pytest --tbshort -q基线不绿就别往下跑否则你分不清是模型改坏了还是环境本来就坏。4.2 任务选取与难度分层不要一上来就跑全量。SWE-bench Pro 的任务难度差异很大有的只需要改一行有的要动十几个文件。我的做法是先按改动文件数分层单文件任务、2-5 文件任务、5 文件以上任务各选一批。这样做的目的是定位模型的失败边界。如果模型在单文件任务上通过率 80%在 5 文件以上掉到 10%那你就知道它的瓶颈在跨文件推理而不是代码生成。选型时就能针对性判断。难度层级改动文件数典型任务观察重点L11单函数 bug 修复代码生成质量L22-5跨模块小重构调用方定位L35架构级改动全局一致性L4任意含环境变更工程闭环能力4.3 跑测与结果记录跑测的时候要记录的不只是过没过还要记录过程。我一般会抓这几项Agent 的完整操作轨迹、每步耗时、失败时的最后状态、测试输出的原始日志。这些数据比最终分数有用得多。比如你发现某个模型 80% 的失败都发生在装依赖这一步那它的分数低就不是推理能力问题而是工具调用问题。换个装依赖的策略可能分数就上去了。# 记录 Agent 轨迹的简化结构 trace { task_id: repo-issue-123, steps: [ {action: read_file, path: src/auth.py, ok: True}, {action: edit_file, path: src/auth.py, ok: True}, {action: run_test, cmd: pytest tests/test_auth.py, ok: False}, {action: install_dep, pkg: pytest-asyncio, ok: False}, ], final_status: failed, failure_stage: dependency, }有了这个结构你就能统计失败分布而不是只看一个总分。4.4 结果解读的常见陷阱解读结果时最容易犯的错是唯分数论。一个模型 45 分另一个 42 分不代表前者更好。要看置信区间、看任务分布、看失败类型。还有个陷阱是单轮定生死。Agent 有随机性同一个任务跑三次结果可能不同。至少要跑三轮取平均或者用 passk 指标。只看一轮的结果噪声可能比信号还大。提示如果评测方只给了一个总分没有失败分布和轮次信息这个分数的参考价值要打对折。5. 失败模式速查与避坑5.1 六类高频失败及应对我把实际跑测中遇到的失败归了六类每类的应对方式不同。失败类型典型表现根因应对定位错误改了无关文件检索能力弱加代码索引先检索再改漏改调用方测试报 NameError跨文件推理弱改完搜索所有引用环境卡死反复装依赖失败工具调用粗糙预装依赖锁定版本过度改动引入回归意图理解偏差限制改动范围测试误改改测试而非改代码目标混淆明确禁止改测试配置不匹配模型名不支持接入层问题启动时校验配置这六类里前两类是模型能力问题后四类是工程问题。工程问题占比往往超过一半这也是为什么我说6 个不及格不能全怪模型。5.2 配置类报错的排查顺序热搜里那些model is not supported的报错排查有固定顺序。先确认模型名拼写再确认接入方式支持的模型列表再确认账号权限最后确认版本兼容。# 先列出当前接入方式支持的模型 curl -s https://api.example.com/v1/models | jq .data[].id # 确认你要用的名字在列表里 # 不在就换名字别硬试很多人卡在这里是因为不看支持列表凭记忆填名字。模型名更新很快上个月能用的名字这个月可能就改了。5.3 让 Agent 少翻车的三个设置第一强制先读测试。在系统提示里明确要求 Agent 改代码前先读相关测试文件理解验收标准。第二限制单次改动范围。告诉 Agent 一次只改一个逻辑单元改完立刻跑测试不要攒一堆改动一起跑。第三失败即停并报告。连续两次同样的失败就停下来报告不要无限重试。无限重试是时间和额度的最大杀手。这三个设置看起来简单但能把通过率拉高不少。我实测下来光是强制先读测试这一条就能让跨文件任务的通过率提升一截因为模型不再闭着眼睛改。6. 选型建议与我的实际体会回到最初的问题7 个模型 6 个不及格这个结论对实际选型意味着什么。我的看法是不要把 SWE-bench Pro 的分数当成唯一标准。它测的是全自动闭环能力但真实工作流里人机协作往往比全自动更高效。一个模型在评测里 40 分但在人给方向、模型执行的模式下可能非常好用。反过来一个评测 70 分的模型如果它的失败模式恰好踩中你的核心场景那也不适合你。具体选型时我会看三件事一是失败分布看它主要卡在哪一步二是可干预性看它失败时能不能被人接手三是成本包括 token 消耗和人工兜底的时间。这三件事比一个总分有用得多。GLM-5.2、DeepSeek-V4-Pro、GPT-5.6-Sol 这几个我都在不同项目里用过。DeepSeek-V4-Pro 在单文件任务上确实稳适合做代码补全和局部修复GLM-5.2 在多文件定位上有优势适合做重构类任务GPT-5.6-Sol 理解意图强适合从模糊需求出发的探索性任务。但它们没有一个能独立跑通完整的工程闭环都需要人在关键节点介入。最后分享一个我踩过好几次坑才总结出的经验评测分数低不代表模型不能用代表你不能把它当全自动工具用。把 Agent 当成一个执行力强但需要明确边界的初级工程师给它清晰的任务、可验证的标准、及时的反馈它的产出会比你想象的好。反过来指望它自己搞定一切那 6 个不及格的结果就是你的日常。