# 编程智能体排行榜能支持什么采购判断？

截至2026年10月14日，三套评测可以帮助选择值得试点的智能体，但没有一套能单独支持“节省多少研发工时”的承诺。采购应比较完整系统在相同任务、预算和评分版本下的表现，再用本企业仓库验证收益。旧榜高分、复杂任务低分和历史奖金各自回答不同问题；评测有缺陷也不等于真实工程任务失去评估价值。

| 评测 | 研究对象与任务 | 环境、评分及边界 |
|---|---|---|
| SWE-bench Verified | 2024年8月发布，从原始SWE-bench筛选500题；原任务池来自12个开源Python仓库，输入issue与修复前代码，输出补丁。 | Docker执行；隐藏的FAIL_TO_PASS测试须从失败变通过，PASS_TO_PASS回归测试须保持通过。人工筛题改善可解性，但覆盖仍偏仓库问题修复，无法代表整个研发流程。[原始发布](https://openai.com/index/introducing-swe-bench-verified/) |
| SWE-Bench Pro | 2025年9月发布，原版1865题、41仓库：731公开、858保留、276商业；覆盖Python、JavaScript、TypeScript、Go的多文件缺陷与功能任务，并人工补充需求及接口。 | 语言专用容器内提交补丁，两类测试共同验收；原始实验用SWE-Agent报告pass@1。公开、商业、保留集是不同总体；GPL降低污染风险是设计主张，不能当作训练数据排除证明。[原始发布](https://scale.com/blog/swe-bench-pro)、[论文第3–5节](https://static.scale.com/uploads/654197dc94d34f66c0f5184e/SWEAP_Eval_Scale%20%289%29.pdf) |
| SWE-Lancer | 2025年2月发布；初版取自Expensify在Upwork的1488项工作，含764项个人贡献者任务（IC）和724项经理提案选择任务。 | Docker与代码快照；IC由Playwright端到端测试验收，经理题匹配历史经理的选择；报告单次尝试成功率和通过题对应的历史奖金。[发布](https://openai.com/index/swe-lancer/)、[论文第2–3节](https://arxiv.org/html/2502.12115v1) |

Lancer把应用交互和方案判断纳入比较，仍集中于一个产品，选择正确提案也不等于实施成功。初版总奖金100万美元，公开Diamond为502题、500800美元；2025年7月17日更新将公开IC部分从237题缩至198道离线可运行题，移除39题。官方只接受断网运行结果，当前断网机制依赖Linux；联网试跑不能当作有效成绩。Manager必须用monolith镜像，不能直接沿用IC的单题镜像配置。采购材料须注明Full、Diamond、IC/Manager及离线版本，不能把不同分母连成进步曲线。[官方版本说明](https://raw.githubusercontent.com/openai/preparedness/main/project/swelancer/README.md)

解题率按题等权，奖金指标按历史支付加权。假设两题分别值100与900美元，任解一题都是50%解题率，奖金覆盖率却是10%或90%；这是口径示例，不是模型实测。历史成交价还包含供需、等待和议价，不能视为本企业可节省的工资。净收益须扣除推理、环境、审查、返工与接管成本。pass@1指一次完整尝试，允许其间多轮工具操作；多次采样择优、更多预算或不同工具配置产生的成绩也不能直接并排排名。

2026年的审查使旧分数更需谨慎解释。OpenAI在2月检查了138道模型反复失败的Verified题，称其中59.4%有实质问题，并展示若干模型复现历史补丁或题文的污染迹象。59.4%的分母不是全部500题；这些证据足以削弱其前沿排名解释力，却不足以量化每个模型有多少分来自记忆。[2月审查](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/)

7月8日，OpenAI对Pro公共731题先筛出286道疑似问题题，再进行人工监督的智能体调查及每题五位工程师复核；两条路径分别识别200道（占全公共集27.4%）和249道（34.1%）问题题，概括估计约30%，并撤回先前推荐Pro的建议。这不是两批互斥缺陷，不能相加，也不是随机抽样得到的误差区间；结论不自动覆盖商业集。过严测试、需求缺失和误导题文会错杀正确解，覆盖不足会放过残缺解，故不能统一给旧成绩加减30%。[7月审查及方法](https://openai.com/index/separating-signal-from-noise-coding-evaluations/)

审查中的OpenLibrary-77c16d5提供了具体反例：题文要求Markdown表格前导一个空格，隐藏测试却要求两个，遵循题文也会被判错。修复应对齐需求和断言，而非把“模型没过测试”直接记为能力不足；再用有效替代解和不完整补丁核对误杀与漏放。参考补丁能过、空补丁不能过只是两端控制，不能覆盖全部边界行为。

后续修复已有原始证据。Scale于9月22日发布Pro V2，公共集从731减至642题、覆盖11仓库。官网列出69道题文与测试矛盾任务的修正；仓库另列529道题文重写、214份测试补丁及38份参考补丁修改。这些计数对象不同，不能将69当作全部改动，也不能据此认定已逐项解决OpenAI判定的249题。[V2发布](https://labs.scale.com/leaderboard/swe_bench_pro_public_v2?tab=full)、[V2协议与变更](https://raw.githubusercontent.com/scaleapi/SWE-bench_Pro-os/main/v2/README.md)。V1/V2改变了题集、题文和执行条件，分数差不能直接解释为模型进步。

执行时须使用V2任务与镜像，不能混用保留的v1脚本、Docker Hub镜像或数据配置。锁定协议每题50分钟，超时仍抓取部分补丁评分，不能把超时样本从分母剔除。Agent阶段仅可访问模型端点；准备和验证阶段仍可联网，部分Go任务会拉取依赖。提交的补丁在全新镜像中重评，以重评成绩为准并公开两次结果。

发布者记录参考补丁642题全通过、空补丁全失败，但两组首轮各有3次基础设施故障，经重跑才完成。采购复测应把这些重试及成本单列，不能写成首轮零失败。HARD-51由模型失败情况筛选，只适合困难题诊断；模型端点信任与补丁代码执行仍有残余风险。本研究未运行这套基准，以上是发布者记录。[发布验证记录](https://raw.githubusercontent.com/scaleapi/SWE-bench_Pro-os/main/v2/GATE.md)

据此，Verified可保留为固定环境的历史回归与工具链排错资料，旧总分不足以排序今天的前沿能力；Pro的语言、仓库与失败轨迹可帮助判断适配性，V2可在复核后用于同协议候选筛选；Lancer的IC结果更适合观察应用修复，Manager结果适合观察方案选择，二者应分别报告。任何一项都不能独自证明长期维护质量、发布速度或无需人工接管。选择流程应按以下顺序推进：

1. 先选两类高频工作，例如后端缺陷与前端交互修复，明确语言、权限和人工介入边界。用少量任务先验证指定版本环境及参考／空补丁，再扩大运行；尤其核对Pro的V1/V2工具链和Lancer的Linux断网条件。供应方应提供模型与智能体版本、任务清单、容器摘要、网络策略、预算、重试、补丁及评分版本；无法复核的宣传分只作线索。镜像准备、缓存和重评开销单列，区分共享准备成本与逐题成本。
2. 对满足部署与费用约束的候选，用同一批经维护者校验的题、相同时间和费用上限复测。分别公布任务成功率、全部尝试总成本÷验收通过数（含失败、重试费用）、人工接管和失败原因；对成功样本同样抽查漏检。小分差须结合重复运行波动和任务组成判断，不能凭一次榜次定标。
3. 建议以四周、两个代表性仓库、30–50个近期未公开任务作为试点起点，由一名技术负责人组织、仓库维护者验收，样本不足时延长。按语言、难度和任务类型分层，保留功能开发及跨文件任务；先封存需求、环境和隐藏验收，再在各层内随机分配到现有人工流程与使用智能体的流程。平衡工程师经验，避免同一人先做人工版再做智能体版产生记忆优势。
4. 维护者在尽量不知候选身份的情况下审查补丁，用业务验收、回归、安全及可维护性标准共同判定。记录从接单到合并的时间、实际人工分钟、审查返工、运行费用、未完成和接管；合并后继续观察回滚与缺陷。失败样本始终留在分母。工具、模型或验收规则变更须标新版本并补测。

采购扩大条件应事先按现有质量要求和成本基线设定：在缺陷与回滚没有不可接受恶化的前提下，扣除全部辅助成本后仍稳定节省人工，才逐步扩展任务类别；若收益只见于少数简单题，则限定使用范围；若审查返工抵消收益或出现严重回归，则暂停扩展并定位原因。30–50题只用于起步诊断，不能保证统计精度；对差异不清或波动较大的候选应补样。合同中的提效承诺应绑定内部试点的任务范围、验收标准与人工投入，而非某个公开排行榜百分比。