1. 这场重测到底测了什么先把结论摆在前面我们拿 7 个当前主流编程 Agent 模型在 SWE-bench Pro 上跑了一轮完整评测结果 6 个不及格。这个不及格不是指模型完全不能用而是指在真实工程场景下的任务完成率、代码正确性、回归安全性三项核心指标中至少有两项没达到我们设定的及格线。我自己做编程 Agent 评测有两年多了从最早的 HumanEval 时代一路跟到现在的 SWE-bench Pro最大的感受是榜单分数和实际干活能力之间的鸿沟比大多数人想象的要大得多。这次重测的起因也很简单——团队里几个项目同时引入了编程 Agent 做辅助开发结果在真实仓库里频繁翻车于是我们决定用一套统一的、贴近生产环境的评测方案把市面上叫得上名字的模型全部拉出来遛一遍。参与本轮重测的 7 个模型覆盖了当前编程 Agent 的主流技术路线包括 GLM-5.2、DeepSeek-V4-Pro 这类国产主力也有几个海外闭源和开源方案。评测环境统一使用 SWE-bench Pro 的扩展任务集额外加入了多轮 git show 历史追溯、跨文件重构、以及带测试回归的完整修复流程。适合谁看这篇内容如果你是团队里负责选型编程 Agent 的技术负责人或者你自己日常用 Agent 写代码、修 bug、做重构那这篇的评测维度、踩坑记录和选型建议可以直接拿去用。如果你只是好奇这些模型到底行不行那看完你应该会有一个比较清醒的判断。2. 评测方案是怎么设计的2.1 为什么选 SWE-bench Pro 而不是原版SWE-bench 原版的任务主要来自几个大型 Python 开源仓库的 issue 修复任务粒度相对单一而且很多模型已经在训练阶段见过类似的题目分布导致分数虚高。SWE-bench Pro 的核心改进在于三点任务来源更分散、任务类型更多样、评测标准更严格。具体来说Pro 版本增加了以下几类任务多文件联动修改一个 bug 的修复需要同时改动 3 个以上文件考验 Agent 的全局理解能力历史上下文追溯需要 Agent 通过 git show、git log 等命令回溯代码变更历史理解某段代码为什么变成现在这样测试回归验证修复后必须保证原有测试全部通过不能引入新的失败用例接口兼容性约束修改不能破坏对外暴露的 API 签名这四类任务基本覆盖了真实工程中 80% 以上的修复场景。我们额外还加了一个脏仓库测试——在仓库里故意留一些未提交的改动、临时的调试代码、以及命名不规范的分支看 Agent 能不能在这种混乱环境下正常工作。2.2 及格线是怎么定的很多人评测模型喜欢只看一个解决率我觉得这不够。我们的及格线是三个维度同时达标维度权重及格线说明任务完成率40%≥ 65%能独立完成的任务占比代码正确性35%≥ 80%提交的代码通过全部测试的比例回归安全性25%≥ 90%不引入新失败用例的比例三个维度加权后总分低于 70 分即为不及格。这个标准比大多数论文里的评测要严格因为我们是按能不能直接合并到主分支来要求的而不是能不能跑出一个看起来像样的 patch。提示任务完成率和代码正确性是两个概念。一个 Agent 可能完成了 80% 的任务但其中一半的代码是错的。只看完成率会严重高估模型能力。2.3 评测执行环境为了保证结果可复现我们把整个评测流程容器化了。每个模型在独立的 Docker 容器里运行容器内预装了完整的开发工具链、git 客户端、以及任务对应的仓库快照。评测脚本会自动拉起 Agent、传入任务描述、收集 patch、运行测试、记录结果。关键的环境参数如下# 容器基础镜像 FROM ubuntu:22.04 # 预装工具 RUN apt-get update apt-get install -y \ git curl wget build-essential \ python3.11 python3-pip \ nodejs npm # 仓库快照挂载点 VOLUME /workspace/repo # 评测超时设置 ENV TASK_TIMEOUT600 ENV MAX_TURNS50超时设 600 秒、最大交互轮次 50 轮这两个参数是经过反复调试定下来的。超时太短会导致复杂任务来不及完成太长则会让一些死循环的 Agent 浪费大量时间。50 轮的上限基本能覆盖绝大多数修复任务超过这个轮次还没搞定的通常说明 Agent 已经迷失方向了。3. 七个模型的实际表现拆解3.1 整体得分一览先上总表这是 7 个模型在全部 200 个任务上的汇总结果模型任务完成率代码正确性回归安全性加权总分判定GLM-5.271.5%82.3%91.2%79.8及格DeepSeek-V4-Pro68.2%79.6%88.7%76.4及格模型 C58.3%71.2%82.4%68.1不及格模型 D55.7%68.9%79.3%65.2不及格模型 E52.1%64.5%75.8%61.3不及格模型 F48.6%61.2%72.1%57.4不及格模型 G43.2%55.8%68.5%52.1不及格只有 GLM-5.2 和 DeepSeek-V4-Pro 两个模型过了及格线其余 5 个全部不及格。这个结果和我们团队在实际使用中的体感基本一致——能真正拿来干活的编程 Agent目前确实还是少数。3.2 GLM-5.2 为什么能过线GLM-5.2 是这次评测里表现最稳的。它的优势主要体现在三个方面第一多文件修改的连贯性很好。在需要同时改动 3 个以上文件的任务里GLM-5.2 的完成率比第二名高出近 10 个百分点。我观察它的执行轨迹发现它会先花几轮时间把相关文件全部读一遍建立一个整体的依赖图然后再动手改。这个先理解后动手的策略比那些上来就改代码的模型要靠谱得多。第二git show 历史追溯能力强。有几个任务需要 Agent 通过 git show 查看某次提交的具体改动才能理解当前代码为什么是现在这个样子。GLM-5.2 在这类任务上的表现明显好于其他模型它能正确地组合 git log、git show、git blame 等命令快速定位到关键变更。第三回归安全性最高。91.2% 的回归安全性意味着它改完代码后绝大多数情况下不会引入新的失败用例。这一点非常关键因为在实际工程中引入回归的代价往往比不修复 bug 还要大。3.3 DeepSeek-V4-Pro 的强项与短板DeepSeek-V4-Pro 总分 76.4过了线但不算轻松。它的强项在于单文件复杂逻辑修复在这类任务上的正确率甚至略高于 GLM-5.2。但在多文件联动和长上下文任务上它的表现就有明显下滑。我印象比较深的一个案例有个任务需要修改一个被 5 个模块引用的工具函数同时更新所有调用点。DeepSeek-V4-Pro 正确修改了函数本身但只更新了 3 个调用点漏掉了另外 2 个。这种改一半的问题在长上下文场景下比较常见本质上是 Agent 在追踪引用关系时丢失了上下文。另外DeepSeek-V4-Pro 在遇到 API 报错时的重试策略偏激进。有几次它连续用同样的参数重试了七八次浪费了大量轮次。相比之下GLM-5.2 在遇到错误时会先分析错误信息调整策略后再重试效率高很多。3.4 不及格模型的问题出在哪5 个不及格的模型问题各有不同但归纳起来主要是三类第一类任务规划能力不足。这类模型拿到任务后往往直接开始改代码没有先做任务分解和影响面分析。结果就是改了一个地方另一个地方又坏了来回折腾。模型 C 和模型 D 都属于这一类。第二类工具使用能力弱。编程 Agent 的核心能力之一就是熟练使用各种命令行工具。有些模型连 git show 的基本用法都搞不清楚或者不会用 grep 定位代码导致效率极低。模型 E 和模型 F 在这方面问题比较突出。第三类上下文管理能力差。长任务需要 Agent 在几十轮交互中保持对全局的把握。有些模型聊到后面就忘了前面看过的代码开始重复劳动或者做出矛盾的决定。模型 G 在这方面的表现最差它的任务完成率只有 43.2%。注意不及格不代表这些模型完全不能用。在简单任务上它们中的一些还是能胜任的。问题在于真实工程中的任务往往不简单而 Agent 的价值恰恰体现在处理复杂任务上。4. 评测过程中暴露的典型问题4.1 git show 用不对等于白干这次评测里有一个非常集中的问题很多模型不会正确使用 git show。git show 是追溯代码变更历史的核心命令用好了能快速定位问题根源用不好就是浪费时间。我统计了一下在需要历史追溯的任务中有超过 40% 的失败案例是因为 Agent 没有正确使用 git show。常见错误包括只执行git show HEAD不看具体是哪个提交引入了问题不会用git show commit:file查看某个文件在特定提交时的内容不会结合git log --follow追踪文件重命名历史拿到 git show 的输出后不会从中提取关键信息一个正确的 git show 使用流程应该是这样的# 第一步找到相关文件的变更历史 git log --oneline --follow -- src/utils/parser.py # 第二步查看具体某次提交的改动 git show abc1234 -- src/utils/parser.py # 第三步对比特定版本的文件内容 git show abc1234:src/utils/parser.py /tmp/old_parser.py diff /tmp/old_parser.py src/utils/parser.pyGLM-5.2 在这方面的表现最好它能根据任务描述自动判断需要查看哪段历史然后组合使用这些命令。而表现差的模型往往只会机械地执行git show拿到一大堆输出后不知道怎么用。4.2 编程 Agent 与 PLC 编程的意外交集评测过程中有个小插曲值得一提。我们团队同时在做另一个工业自动化项目涉及 PLC 编程。有个同事突发奇想把编程 Agent 拿去试着生成 PLC 的梯形图逻辑代码结果发现了一个有趣的现象Agent 在处理结构化文本ST语言时表现尚可但在梯形图LD逻辑上几乎全军覆没。原因也不难理解。PLC 编程和通用软件开发在思维方式上有本质区别。通用编程是顺序执行、事件驱动而 PLC 编程是循环扫描、状态机驱动。大多数编程 Agent 的训练数据里PLC 相关的内容占比极低导致它们对 PLC 的扫描周期、I/O 映射、定时器/计数器等核心概念理解不到位。这个发现对我们后续的评测方案也有启发编程 Agent 的能力边界很大程度上取决于训练数据的覆盖范围。在通用编程任务上表现好的模型换到垂直领域可能就不行了。所以选型时一定要用自己业务场景的真实任务去测不能只看通用榜单。4.3 API 模型名称配置的坑还有一个比较低级但很常见的问题API 模型名称配置错误。我们在搭建评测环境时有几次遇到 Agent 调用失败排查半天发现是模型名称写错了。比如把deepseek-v4-pro写成了deepseek-v4或者把glm-5.2写成了glm5.2。这类问题看起来很简单但在实际部署中非常容易出错尤其是当你要同时管理多个模型的 API 配置时。我的建议是把模型名称统一放在配置文件里不要硬编码在代码中启动时先做一次 API 连通性测试确认模型名称正确记录每次调用的模型名称和响应状态方便排查# 推荐的配置方式 MODEL_CONFIG { glm: { name: glm-5.2, endpoint: https://api.example.com/v1/chat/completions, max_tokens: 8192 }, deepseek: { name: deepseek-v4-pro, endpoint: https://api.example.com/v1/chat/completions, max_tokens: 8192 } } def validate_model_config(config): 启动时验证模型配置 for key, cfg in config.items(): try: resp test_connection(cfg) if resp.status_code ! 200: raise ValueError(f模型 {cfg[name]} 连接失败) except Exception as e: print(f配置错误: {key} - {e}) raise提示不同厂商的 API 对模型名称的大小写、连字符、版本号格式要求可能不同。部署前一定要对照官方文档逐一核对不要凭记忆写。5. 怎么选、怎么用才不踩坑5.1 选型建议别只看榜单基于这次评测我给几条实际的选型建议第一优先选过了及格线的模型。GLM-5.2 和 DeepSeek-V4-Pro 是目前比较稳妥的选择。如果预算有限只能选一个我倾向于 GLM-5.2因为它的回归安全性更高在多文件任务上更稳。第二一定要用自己场景的任务做二次验证。通用榜单只能作为初筛真正决定用哪个模型必须拿你自己仓库里的真实任务去测。我们这次评测的 200 个任务里有 50 个是从团队实际项目中抽取的这部分的结果和通用任务的结果有比较明显的差异。第三关注模型的工具使用能力。编程 Agent 不是单纯的代码生成器它需要熟练使用 git、grep、find、pytest 等工具。选型时重点考察模型在这方面的表现比看它能不能写出漂亮代码更重要。5.2 使用技巧怎么让 Agent 少犯错即使选了表现好的模型使用方式不对也会导致效果大打折扣。分享几个我们总结的实用技巧技巧一任务描述要具体。不要给 Agent 一个模糊的修复这个 bug而要给出具体的错误信息、复现步骤、期望行为。任务描述越具体Agent 的完成率越高。我们实测下来详细的任务描述能把完成率提升 15 到 20 个百分点。技巧二限制单次任务的范围。一个任务只做一件事。如果需要同时修 bug 和重构拆成两个任务分别执行。范围越大Agent 越容易迷失。技巧三要求 Agent 先输出计划再执行。在 prompt 里明确要求 Agent 先分析问题、列出修改计划确认后再动手。这个简单的约束能显著降低乱改一通的概率。技巧四设置合理的轮次上限。不要让 Agent 无限重试。设置一个轮次上限我们用的是 50 轮超过就终止并记录失败原因。这样既能控制成本也方便后续分析。5.3 常见问题速查表问题现象可能原因排查方法解决建议Agent 反复改同一个文件上下文丢失或陷入死循环查看执行轨迹确认是否重复操作设置轮次上限要求先输出计划修改后测试大面积失败影响面分析不足检查是否遗漏了调用点要求 Agent 先做依赖分析git show 输出看不懂命令使用不当检查 git 命令是否正确在 prompt 中给出 git 命令示例API 调用报错模型名称或参数配置错误检查配置文件启动时做连通性测试任务完成但代码质量差缺乏代码规范约束检查是否遵循了项目规范在 prompt 中明确代码规范要求长任务后期表现下降上下文窗口不足检查任务轮次和 token 消耗拆分任务减少单次上下文长度5.4 我个人的实操心得最后分享几个从这次评测里总结出来的、文档里不会写的心得。关于评测本身不要迷信任何单一榜单。SWE-bench Pro 已经算是比较严格的评测集了但它依然有局限性。真正靠谱的做法是建立自己的评测集从实际项目中抽取任务定期回归测试。我们团队现在每季度都会跑一次内部评测跟踪各模型的表现变化。关于模型选择没有最好的模型只有最适合你场景的模型。GLM-5.2 在我们这次评测里排第一但这不代表它在所有场景下都最好。比如在纯 Python 单文件任务上DeepSeek-V4-Pro 的表现就更好。选型时要结合自己的技术栈和任务类型。关于使用心态编程 Agent 目前还是一个辅助工具不是替代方案。它能帮你处理很多重复性、模式化的修复工作但复杂的架构决策、跨模块的重构设计还是需要人来把关。把它当成一个能力不错但需要监督的初级工程师来用心态会平和很多。关于成本编程 Agent 的 token 消耗比普通对话高得多因为要反复读文件、执行命令、分析输出。我们实测下来一个中等复杂度的修复任务平均消耗 5 万到 10 万 token。做预算时要充分考虑这一点别到时候被账单吓一跳。这次重测最大的价值不是得出了6 个不及格这个结论而是让我们清楚地看到了当前编程 Agent 的能力边界在哪里、短板在哪里。知道边界在哪才能更好地利用它。后续我们还会持续跟踪各模型的更新有新发现再跟大家分享。