SWE-bench 与大模型评测：五分钟看懂跑分，选对测试方向

大模型评测的价值，在于帮你判断下一步该测试什么。SWE-bench Verified 衡量的是模型解决 500 个经过筛选的软件问题的表现；分数再高，也不能说明智能体能否遵守你的退款政策。看榜首分数之前，先弄清楚测了什么任务、测试如何运行，以及按什么规则评分。

本文已于 2026 年 10 月 15 日对照各基准测试作者的页面及 Google 模型卡核验。 下文的基准介绍解释各项测试的内容；实例中的分数来自 Google 公布的结果。解读与评估清单由我们整理。

选择编程助手，先看代码仓库或终端任务；选择客服智能体，先看对话中的工具调用与政策遵循；选择文档助手，先看长上下文推理。综合知识分数可以作为参考，但不能替你做决定。

SWE-bench 等大模型基准测试，究竟测什么？

基准测试衡量的是模型在特定规则下完成特定任务的表现。它更像一场体育比赛，而不是一张智力证书：短跑成绩有参考价值，却不能决定谁最适合执行山地救援。

数据集提供问题或任务。评测协议规定模型收到哪些输入、能获得哪些辅助，以及结果如何判分。**运行框架（harness，也称 scaffold）**则是模型外围的软件，包括提示词、工具和执行循环。

看到新模型发布时宣称“会编程”，这些区别就很关键。根据简短提示写一个函数，与搜索代码仓库、编辑文件、运行测试并从错误中恢复，是两种不同的任务。后一种分数衡量的是整套系统，也包括它的运行框架。

SWE-bench 排行榜区分了不同评测设置，其中就有共用的 mini-SWE-agent 环境，因此能直观看到这种差别。你的编程产品可能提供不同的工具、指令或限制。把榜单分数用于判断自己的工作流程之前，先确认模型外围到底运行着什么。

模型发布时常见的基准测试名称

比较分数之前，先把基准测试和实际工作对上号。下面列出了 2026 年通用模型、编程模型和语音模型发布时需要认识的测试类别，以及有助于理解相关宣称的上下文测试。每个基准名称都链接到其作者页面或代码仓库。

基准名称必须带着版本一起看。 HLE-Diamond包含 1,000 道经过修订的题目，而定稿的原版 HLE包含 2,500 道。Terminal-Bench 4.0调整了资源和任务。当前 tau 仓库同时记录了新增模态和评分修正。新旧两个分数放在一起，变化的可能是试卷，而不是模型能力。

哪些评测分数与你的工作有关？

先想清楚要避免哪类失败，再选择最接近的测试类别。为产品选择 AI 功能的创始人、审批智能体上线的 CTO，以及处理客服工单的运营人员，不该给发布表格中的每一行相同权重。

编程智能体评测：先看仓库与终端任务

维护现有产品的开发者，应先看代码仓库修复和终端操作。SWE-bench 可以为解决软件问题的能力提供证据；Terminal-Bench 可以为在 shell 中执行工作的能力提供证据。LiveCodeBench 和 HumanEval 则用于回答范围更窄的编程问题。任何一项单独的测试，都无法说明生成的补丁在你的代码库中是否便于维护。

设想一位独立开发者让智能体修改账号注销功能。写出正确的辅助函数只是其中一部分。智能体还必须找到所有受影响的调用位置、保留权限约束、更新测试，并避免客户记录出现不一致。你的评估应覆盖整个修改过程，且使用正式计划提供的代码仓库访问权限和工具。

**判断原则：**如果工作涉及多个文件和执行步骤，就应先看到智能体完成任务的证据，再将其列入候选。函数级分数可作为辅助参考。在自己的测试案例足以支持减少审查之前，验收流程仍应保留代码审查。

大模型推理评测：分清考查的推理类型

GPQA、HLE、MMLU-Pro、AIME 和 ARC-AGI 考查的是不同类型的推理。它们能提示哪些能力值得进一步验证，尤其是在任务涉及高难度科学或数学问题时。但它们很难替代直接验证模型能否遵守你的业务规则。

GPQA Diamond 的 198 道题是专门筛选出的科学题集。评估内部研究助手的 CTO 可以据此形成候选名单，再用必须依赖公司内部资料才能回答的问题进行测试。客服负责人则应更关注受政策约束的工具调用和升级转交。

看 Humanity's Last Exam 时，要把名称所表达的雄心与实际测量的能力分开。其作者明确区分了有确定答案的学术题表现与自主科研能力。能回答一道已有解答的难题，并不能证明系统会选择有价值的研究问题、收集可信证据，或意识到自己犯了错。

长上下文与语音能力，需要各自的证据

上下文窗口代表容量，即系统能接收多少输入。长上下文评测关心的则是系统能利用这些输入做什么。检索测试要求找到信息；推理测试要求把信息联系起来。RULER 作者说明了为什么找到一条隐藏信息，不能代表整体长上下文能力。

对于审核合同的业务人员，有价值的测试是：助手能否把附录中的例外条款与主协议中的条款联系起来，并正确引用两处内容。测试文档应包含找不到答案、答案已被后续内容取代，或存在相互矛盾信息的情况。如果系统信心十足地混用了不兼容的版本，即便检索到了每段文字，也算失败。

语音场景要分别考查听辨、推理、表达和对话控制。FLEURS 可作为转写评估的参考；Big Bench Audio 关注根据语音问题进行推理；VoiceBench 覆盖语音指令任务。当前 tau 系列也评估语音交互。这些测量各有侧重。

电话客服试点应覆盖背景噪声、姓名、打断、纠正，以及转接人工。要听实际交互，并核验最后执行的操作。文字转写看起来可能完全正确，但语音交流仍让人烦躁，或者系统更新了错误的账号。

大模型性能评测：放回工作流程中判断

决定是否采用模型时，应把性能定义为：在工作流程的限制内，完成能够通过验收的工作。答案质量、任务完成的可靠性和响应时间，是彼此独立的要求。使用大量推理资源得到的成绩，可能适合通宵运行的调查任务，却不适合实时客服对话。

采购方应索取所需任务细分项在实际产品配置下的结果。运营人员应检查失败及恢复过程。开发者应能够复现评测设置。如果供应商说不清测的是哪套配置，这个分数就不足以支持将其投入生产。

五分钟，读懂一张模型发布成绩表

用这套五分钟阅读流程，判断一次模型发布是否值得深入评估。它只是读表方法；这点时间不足以证明模型在你的应用中安全或有用。

1. 1

   第 1 分钟：明确自己的任务

   写下你需要的结果：修复代码仓库问题、解决客服请求、基于文档回答问题，或处理语音来电。标出与目标相近的行。与任务无关的领先成绩，不应左右是否采用模型的决定。

2. 2

   第 2 分钟：确认到底考了什么

   记录基准版本、子集、语言和题目的时间范围。留意 Diamond、Verified、离线、纯文本、使用工具等限定条件。标签写得不完整，就查看基准测试自己的页面。

3. 3

   第 3 分钟：核对测试设置

   找到运行框架、工具、推理设置、时间额度和尝试次数规则，再判断自己的产品是否会使用这些条件。搜索权限、代码执行能力或更多重试机会，都会改变分数所代表的含义。

4. 4

   第 4 分钟：弄清评分指标

   准确率是被判为正确的结果所占比例。F1 兼顾返回结果中有多少是正确的，以及应找出的项目中实际找到了多少。部分得分可以奖励进展，即使任务尚未完成。错误率则是越低越好。把百分比当作工作完成比例之前，先读清楚指标定义。

5. 5

   第 5 分钟：追溯是谁跑出的结果

   确认测试由谁运行：模型厂商、基准组织方，还是其他评估者。逐行阅读脚注，不要默认整张表都采用同一套流程。保存来源和设置，再选出值得用自己案例测试的候选。

最终应形成一份简短的判断记录：“任务类别相关，版本有效，测试设置已弄清，值得用我们的案例验证。”如果这些信息填不全，先记下缺口，再考虑更换正在正常工作的系统。

实例：如何读 Google 的 Gemini 4 Argon 成绩表

Google 的通用 AI 模型 Gemini 4 Argon 是一个合适的例子，因为它的成绩表混合了不同任务类别和评分规则。下列各行复现了 Google 在 10 月模型卡中发布的结果，核对日期为 2026 年 10 月 15 日。这些是引述的厂商结果，并非本文自行测得。

每个数值都要结合行标题和备注一起读。这些百分比的分母与含义并不相同。

BFS 指广度优先搜索，即按深度逐层遍历图中的连接。Token 是衡量模型上下文的单位，并不等同于单词。

得出结论前，先读脚注

Google 的评测方法说明指出，Argon 通常使用最高思考档位和 pass@1，但存在例外。DeepSWE 结果使用 mini-swe 运行框架。Terminal-Bench 结果由 Google 自行计算，而对比结果来自官方排行榜。GraphWalks 中各模型的结果均由 Google 自行计算。OSWorld 取三次运行中的最高值，并报告离线部分得分。

这里混合了多种评测安排，不能据此认定每个单元格都来自同一次受控实验。开发者接下来要问：编程运行框架是否接近计划采用的智能体？采购方要问：应用拟采用的配置是否与这些证据一致？运营人员要问：评分指标奖励的是否是最终完成的结果？

**我们做的计算：**99.7 减去 84.2，两个已公布的 GraphWalks F1 结果相差 15.5 个百分点。两行使用的是不同长度子集，因此这次相减无法单独识别长度对同一批问题的因果影响。但它确实说明，如果只引用较短上下文那一行，就会遗漏与长文档工作流程有关的证据。

计算机操作成绩的解读同样要具体：不能把部分得分理解成“智能体能完成同样比例的桌面工作”。对于会把工作交还给人的助手，部分进展可能有价值；无人值守的流程则需要证明任务能够完整、正确地完成。

有关具体模型的采用建议，可参阅 Gemini 4 Argon 详解，以及单独的 Gemini 4 Argon 与 Opus 5.5 对比。

为什么高分也可能误导？

高分可以完全有效，却仍然回答了错误的业务问题。有用的做法是先找出它的局限，再判断需要什么证据来弥补。

数据污染与针对测试的优化

数据污染是指评测问题或答案进入了训练材料。模型可能因此受益于事先接触过内容，而非真正解决未见过的问题。公开测试也可能成为反复优化的目标：围绕同一批任务不断调整提示词或运行框架，会削弱测试作为全新检验的价值。

LiveCodeBench为题目标注日期，让评估者可以选择训练截止时间之后发布的题目。这是有用的设计，但不能据此认定名称里带“Live”的结果都不存在污染。要检查实际题目时间范围。看到异常大的提升，应进一步检查评测协议，而不是直接断定存在不当行为。

做自己的评估时，要保留一组不用于调试提示词的留出测试集。某个失败案例被纳入开发样例后，就应向留出集补充新案例。否则，系统可能在熟悉的样例上表现极佳，换个场景却仍然脆弱。

运行框架可能改变你实际比较的系统

由什么程序运行模型，非常关键。同一个模型，配上搜索、文件工具、重试和精心编写的指令，与只回答一次提示时，已经是不同的部署系统。改进运行框架可以是有价值的工程进步；问题在于把全部成绩都归功于底层模型。

如果要单独判断更换模型带来的影响，就使用相同的运行框架。如果要在完整产品之间做选择，就评估完整产品。两种问题得出不同结论，完全合理。

厂商自测有价值，但不等于独立复现

方法清楚时，厂商结果有参考价值；配置适合所做比较时，基准组织方的结果也有参考价值。两种身份都不能替代对评测协议的阅读。要区分提交到排行榜的结果，与在统一条件下由独立方重新运行得到的结果。

检查提示词、模型标识、运行框架、评分方法、排除项和不确定性。如果没有足够信息说明结果的波动，小幅分差不应决定是否迁移。某项结果未公布，代表证据缺失，并不自动等于零分。

还要检查分数如何汇总。整体平均分包含了评估者对任务和权重的取舍。你的客服队列可能有大量例外情况，却几乎不影响这个平均分。不要把互不相关的基准百分比再取平均，拼成自己的“智力分数”。

评分做得好，也可能测错目标

单元测试、标准答案、模型裁判和人类偏好，奖励的是不同的东西。测试覆盖可能漏掉缺陷；标准答案可能有误；模型裁判可能偏爱流畅的解释，而非正确的操作。偏好胜出衡量的是参与者在那套流程下更喜欢什么。

当前的 tau 仓库记录了任务与评分修正。这些修正改善了评测，也让版本追踪变得不可或缺。测试是一套需要维护的测量系统，而非不容质疑的真理来源。

什么时候必须做自己的评估？

只要决策取决于你的数据、政策、工具、用户或对失败的容忍度，就应开展自己的评估。公开分数足以帮助识别有希望的候选，但不足以批准一个会修改客户记录或基于私有文档作答的智能体上线。

如果某项相关基准的提升，恰好对应当前系统已知的失败类型，就立即行动：针对这类失败开展受控比较。如果提升与业务任务无关，或者公布的测试配置在你的产品中无法使用，就暂缓迁移。如果现有系统已经符合验收标准，而新候选尚未证明有相关改进，就继续使用现有系统。

对于中型企业的客服团队，一个可操作的初始试点可以包含 50 个案例：20 个常规请求、10 个政策例外、10 个输入缺失或互相矛盾的情况，以及 10 个权限或升级转交案例。这些只是测试设计上的数量建议，并不代表该样本在统计上足以支持部署。最终规模应取决于你需要检测的失败率和差异。

运行候选系统之前，先定义什么叫成功。退款案例可能要求资格判断正确、账号和金额正确、没有未授权操作，并且解释清楚。升级转交案例中，只要智能体正确完成交接，即使没有自行解决请求，也应判定通过。

每个候选都应使用计划上线的提示词、检索、工具和权限。检查最终记录与操作轨迹，而不只是最后一条回复。对不稳定的案例重复运行，单独跟踪延迟，并在认定有改进之前复核存在分歧的结果。为最终决策保留一组留出测试集。

Promptfoo 是一款评估工具，可用测试案例与断言比较提示词、模型和应用。它的文档介绍了执行方式；我们的 Promptfoo 评测则解释它适用于哪些环节，以及哪些工作仍需你自己负责。

对于可以直接验证的事实，例如所选账号或禁止执行的操作，使用确定性检查。对于需要判断的质量，例如解释是否完整、是否有依据，使用评分量表，并对照人工标注进行校准。LLM-as-a-judge 指南介绍了这一评分层及其常见失效方式。

**周一就能开始的行动：**选定一个工作流程，写下验收标准，收集近期案例，在相同条件下比较现有系统与一个候选系统。是否部署，应由那些真正影响用户的结果和失败来决定。

大模型评测表常见问题

常见的大模型基准测试有哪些？

先认识各个类别：SWE-bench 和 Terminal-Bench 用于编程智能体，GPQA 和 Humanity's Last Exam 用于学术问答，tau 系列用于对话中的工具使用，长上下文和语音则各有专门测试。每个分数都应连同版本和设置一起记录。

评估大模型编程能力，该看哪个基准？

选择最接近实际任务的基准。SWE-bench 关注代码仓库问题的解决；Terminal-Bench 关注终端工作；HumanEval 关注函数生成；LiveCodeBench 包含带日期的竞赛任务。证据是否适用于你，最终要靠自己代码仓库中的实际修改来验证。

大模型评测数据集是什么？

数据集提供问题或任务。要让基准结果具有可比性，还需要明确评测协议：提示词、工具、限制、尝试次数和评分方式。仅仅使用同名数据集，并不能证明两个结果可以直接比较。

想获得评估和采用 AI 的实用建议，可订阅邮件通讯。