Benchmark 到底测量什么

Qwen3.8-27B 是一个相对紧凑的 270 亿参数模型。它的 Model Weights 以 Apache 2.0 License 公开，因此也可以运行在自己的 Infrastructure 上。在 SWE-bench Pro 上，它得到 61.7%。Anthropic 的大型商业模型 Claude Opus 4.6，在同一张比较表中是 53.4%。 [1][2]

第一眼看上去，结论似乎非常简单。如果我们比较 Coding Agents，一个模型是 61.7%，另一个是 53.4%，最自然的解释就是：Qwen3.8-27B 显然是更好的 Coding Agent。也许以后做技术比较根本不需要长篇讨论，只要看一张表，挑最大的数字就行。

但在下这个结论之前，有一个非常朴素的问题值得先问：这个百分比到底是什么意思？

有趣的是，我们甚至不需要离开 Qwen 的 Model Card，就已经能看到第一个复杂之处。表格确实给 Qwen3.8-27B 标出了 61.7，并给一个被 Qwen 标记为 “Opus4.6 Max” 的比较项标出了 53.4。Anthropic 自己则将这个结果报告为 Claude Opus 4.6 的 53.4%；从这里并不能推导出一个独立存在的 “Opus 4.6 Max” 模型版本。 [1][2]

表格下方还描述了 Evaluation Setup。除了直接引用的 Opus 结果之外，其他模型都使用 Claude Code Harness、temperature=1.0、top_p=0.95 和 256K Context Window 进行评测。Qwen 还说明，他们修正了一些有问题的 Tasks，并在这个 “refined benchmark” 上重新运行了 Baseline Models。Opus 明确是例外：Qwen 没有用同一套设置重新跑，而是直接采用 Anthropic 官方报告的 Score。 [1]

Dataset 来源也可以追踪。Qwen 公布的 Eval Metadata 指向 ScaleAI/SWE-bench_Pro，其公开 Test Split 包含 731 个 Tasks。完整的 SWE-bench Pro 更大，还包括 Held-out 和 Commercial 部分。 [1][6]

这并不说明这些数字是错误的或者可疑的。它只说明：即使两个百分比出现在同一张表里，也不代表它们天然就是完全可比的。模型、Harness、Sampling Settings、Dataset Variant，以及比较值本身来自哪里，都属于这个数字的解释范围。

问题不在 Score 本身，而在我们如何解释这个 Score。

Benchmark 到底是什么？

Benchmark 并不神秘。它本质上是一套标准化测试，或者一组任务，用来在尽可能明确的条件下测量和比较不同系统。

把 Benchmark 理解成一场考试，比把它理解成完整的职业能力评价更合适。数学考试可以很好地测量一个人解决某些数学问题的能力。高分当然是重要信息。但这并不自动回答：这个人以后作为工程师是否擅长处理模糊 Requirements、记录 Decisions，或者维护一个存在十年的复杂系统。

Coding Benchmark 也是一样。一个好的 Benchmark 可以非常有效地测量某种特定 Software Engineering 能力，但这并不意味着它覆盖了专业软件开发所需的全部能力。

Benchmark 不是对模型的最终判决，而是一种测量工具。比较数字之前，我们必须先理解这个工具究竟在测量什么。

SWE – Software Engineering

现在我们会在很多地方看到 SWE：SWE-bench、SWE-bench Verified、SWE-bench Pro、SWE-Lancer、SWE-rebench。

这个缩写其实一点都不神秘：

SWE 就是 Software Engineering。

它想表达的是，这些 Benchmark 希望测量的不只是“根据一段短描述生成一个函数”。它们到底有多接近真实的软件工程，则取决于具体 Benchmark。

SWE-bench – 从 Coding Problem 到真实 Repository

很多经典 Coding Benchmark 都是相对孤立的任务。模型收到一段描述和一个 Function Signature，写出实现，然后跑 Tests。

简单来说：

任务描述
↓
实现函数
↓
运行 Tests

这很有价值，但只覆盖了开发者日常工作的一部分。在真实项目里，我们很少会拿到一个空函数和完美需求。我们往往要先找出相关文件，理解现有系统，弄清楚 Requirement 真正想改什么，同时保证原有行为不被破坏。

SWE-bench 把 Evaluation 往真实 Repository 的方向推进了一步。最初的 Benchmark 包含 12 个热门 Python Repositories 中的 2,294 个 Tasks。任务来自真实 GitHub Issues 以及对应的人类修复。系统会拿到人工修复之前的 Repository State 和原始 Problem Description，然后生成一个 Patch。之后的 Evaluation 会检查原本失败的 Tests 是否通过，同时确保原有行为没有被破坏。 [3]

基本流程更像这样：

Repository State
+
GitHub Issue
↓
分析 Codebase
↓
找到相关位置
↓
生成 Patch
↓
运行 Tests
↓
resolved / unresolved

相比一个孤立函数，这已经明显更接近 Software Engineering。系统必须在陌生代码里定位问题，并把修改嵌入已有 Context。

但它依然是一项受控任务。没有人自动评估三年后 Architecture 是否还清晰、Naming 是否符合团队 Domain Language、这个 Patch 是否符合长期 Migration Strategy。SWE-bench 比单纯 Code Completion 现实得多，但仍然只测量一个明确的切片。

“61.7% resolved” 到底是什么意思？

在 SWE-bench 类型的 Leaderboard 上，通常会用 % Resolved 表示按照 Benchmark 规则成功解决的任务比例。 [3]

所以 61.7% 大致意味着：

在指定 Evaluation 条件下，测试任务中有 61.7% 根据该 Benchmark 的规则被判定为已解决。

听起来很普通，但这是整篇文章最重要的翻译。这个百分比的分母是 Benchmark Tasks，而不是“所有软件任务”、不是“一个开发者的全部工作”，也不是“某个公司会遇到的全部开发场景”。

因此，61.7% SWE-bench Pro 并不代表这个模型能解决所有 Software Tasks 的 61.7%。它也不代表模型是“61.7% 的软件工程师”，更不代表它可以替代一个开发岗位的 61.7%。

61.7% SWE-bench，不等于 61.7% 的软件工程师。

为什么会有 SWE-bench Verified？

使用真实 GitHub Projects 有一个明显优点：任务不是为了 Benchmark 人工编出来的。但这也带来问题，因为真实 Repositories、Issues、Dependencies 和 Tests 从来不是为了构建一个科学上干净的测量工具而存在的。

最初 SWE-bench 的 Tasks 大多通过自动化方式收集。后来发现，一些任务存在歧义、描述不足，或者测试与环境本身有问题。一个功能上正确的 Solution，可能因为 Test 过于狭窄而失败；另一些任务的 Hidden Tests 又默认了 Problem Description 里没有提供的信息。不同 Python Version、OS 或 Dependency State 也会影响可复现性。 [4][5]

因此，OpenAI 和 SWE-bench 团队让有经验的软件工程师审查了 1,699 个候选任务。每个任务都由三位专家独立评价，最终产生了包含 500 个 Tasks 的 SWE-bench Verified。 [4][5]

这里的 “Verified” 并不代表“数学上证明每个 Evaluation 都绝对正确”。它表示有人类专家检查过任务和评测方式，并过滤掉不合适的案例。

这是一个合理的改进。但 SWE-bench 后来的发展也说明，想要长期维护一个高质量的软件工程测量工具，其实非常困难。

当一个成功的 Benchmark 自己变成系统的一部分

SWE-bench Verified 变得非常成功。模型厂商发布 Scores，Agent 开发者分析成功和失败的 Trajectories，Harness 开始针对 Repository Work 进行优化，这个 Benchmark 也成为衡量 Coding Capability 的重要参考。

而成功本身，会逐渐改变测量条件。

Contamination

在 Benchmark 语境里，Contamination 指的是 Evaluation Data 或非常相似的信息，可能已经在模型的 Training 或 Post-Training 过程中出现过。

SWE-bench 的情况非常直观。原始 Repositories 是公开的，Issues 是公开的，很多 Pull Requests 或 Commits 里的人工解决方案也是公开的。如果模型使用大量公开代码和技术交流内容进行 Training，那么它与 Benchmark Material 发生重叠并不难理解。

这并不自动意味着模型在考试时“直接查答案”。Training Data 的普通重叠、学到某个项目的特定知识，以及真正复现一份已知 Solution，是不同程度的问题。Contamination 首先是 Evaluation Risk，而不是对某个模型“作弊”的指控。

2026 年 2 月，OpenAI 发布了新的 SWE-bench Verified 分析，并认为这个 Benchmark 已经受到 Contamination 和剩余 Task Quality 问题的影响，不再适合干净地测量当时的 Frontier Models。在部分任务上，所有被测试的 Frontier Models 都出现了复现 Gold Patch 或非常具体 Problem Information 的情况。OpenAI 随后停止报告自己模型的 SWE-bench Verified Score。 [4]

其他研究也开始针对静态、公开的 Software Engineering Benchmarks 做同样的改进。一个常见方向是不断收集新任务，并在时间上把 Evaluation 与旧 Training Data 分开。 [12][13]

Benchmark Overfitting

Contamination 和 Benchmark Overfitting 不是一回事。

一个 Benchmark 如果变得足够重要，Models、Post-Training、Prompts 或 Agent Harnesses 都可能越来越针对 Benchmark 奖励的能力进行优化。这并不要求任何人知道具体答案。仅仅更熟悉常见 Task Structure、Tool Sequence 或高成功率 Strategy，就可能让结果变好。

学校考试的比喻很好理解。如果一种考试多年保持近似结构，而且过去的试卷和答案全部公开，学生学习的不只是数学，也会学习“如何高效通过这场特定考试”。他们仍然可能需要真实知识，只是考试分数会越来越难与更广泛的能力完全区分。

这并不是 AI 特有问题。Machine Learning 很早就在处理对 Dataset、Benchmark 和 Leaderboard 的 Overfitting。一个指标越重要，针对这个指标做优化的动力就越强。

因此，一个系统在某个 Benchmark 上显著变好，并不意味着它在所有其他 Software Engineering Tasks 上也会按同样比例提升。

为什么会有 SWE-bench Pro？

Scale AI 开发 SWE-bench Pro，目的就是继续推动这些边界。Benchmark 一共包含 1,865 个 Tasks，来自 41 个 Repositories。其中 731 个属于 Public Split，858 个属于 Held-out 部分，另外 276 个来自 Commercial Codebases。覆盖 Python、Go、JavaScript 和 TypeScript。 [6]

任务平均也比经典 SWE-bench 更大。Scale 报告称，平均每个任务修改 107.4 行代码，涉及 4.1 个文件。由于原始 Commit Messages 和 Issues 不一定提供足够 Context，人类专家会补充 Problem Statements 和 Requirements，但不直接告诉模型如何实现。 [6]

这些不同 Split 解决的是不同问题。Public Split 保持开放和可复现。Held-out Tasks 不作为完整公开 Dataset 发布，因此更难直接针对具体 Eval Tasks 优化。Commercial Tasks 则来自 Private Codebases，进一步降低这些 Repository States 和 Solutions 已经出现在 Public Training Data 中的可能性。

但这里要非常精确：Held-out 并不自动等于“保证从未出现在 Training 中”。 它首先只是说明 Eval Data 被保留，没有完全公开。它是否真的与 Training Data 完全隔离，还取决于数据来源和模型 Training Pipeline。Private Commercial Codebases 通常能提供比“只是不公开的 Benchmark Tasks”更强的隔离。

Held-out 和 Private Data 可以降低 Contamination Risk，但并不能让 Benchmark 自动变得无缺陷。

然后 SWE-bench Pro 自己也被 Audit 了

2026 年 7 月，OpenAI 发布了 SWE-bench Pro 的 Audit。这个事件很有意思，因为几个月之前 OpenAI 还推荐从 Verified 转向 Pro。 [4][7]

这次分析覆盖了 Public Split 的 731 个 Tasks。自动化分析 Pipeline 标记了 200 个任务，也就是 27.4%，认为存在问题。之后的 Human Annotation 又识别出 249 个任务，也就是 34.1%，存在相关问题。因此 OpenAI 谨慎地把自己的判断总结为“大约 30% 的 Tasks 可能是 problematic 或 broken”，并撤回了之前对 SWE-bench Pro 的笼统推荐。 [7]

问题包括 Tests 过于严格、Prompt 描述不足、Test Coverage 太低，以及少数误导性的任务描述。这些数字来自 OpenAI 自己的 Audit，并不意味着“整个 SWE-bench Pro 中恰好 30% 客观且无争议地不可用”。自动分析和人工评价本身就给出了不同数字，这恰恰说明，评价 Benchmark 本身也需要判断。

这才是最值得学习的地方。SWE-bench Pro 并不会因为有人发现了问题就失去价值。它只是提醒我们：要让真实 Software Change 同时具备现实性、可复现性和自动可评分性，本身就非常困难。

测量真实 Software Engineering，本身就是一个困难的 Software Engineering Problem。

SWE-bench Multimodal 也提供了一个非常新的例子。第一版包含 517 个带 Visual Information 的 Issues。2026 年 9 月 1 日，SWE-bench 团队发布 Version 2，只保留 480 个更适合 Reproducible Evaluation 的 Tasks。他们移除了已知 Flaky 或难以稳定评分的 Tests，重建 Docker Environments 以处理 Dependency 和 Browser Drift，并增强 JavaScript Grading 与 Visual Test Assets 的处理。 [14]

所以 Benchmark 更像一个需要持续维护的技术产品，而不是一把刻在石头上的尺子。

Model Score，还是 System Score？

对于 Coding Agents 来说，一个最容易被忽略的问题是：Agentic Coding Benchmark 往往并不是只测 Base Model。

Model 和最终 Patch 之间还有整套 Runtime Environment。它决定系统可以搜索哪些 Files、能使用哪些 Tools、如何执行 Shell Commands、Test Results 如何返回给 Model、Context 如何管理，以及 Agent 还可以再尝试多少次。

作为一个思考模型，可以把 Score 看成：

这当然不是数学公式，这些部分不能直接相加。它只是提醒我们，最终 Score 是一个完整系统共同作用的结果。

Qwen 的例子特别清楚。它不仅说明 Model，还说明使用 Claude Code Harness、256K Context Window、具体 Sampling Parameters，以及修正后的 Task State。 [1]

如果我们只抄走 61.7%，其实把大部分实验说明都丢掉了。

Harness – 给模型一个工作环境

上一篇文章里我们已经介绍过 Agent Harness。它是包围 Model 的 Runtime 和 Control Layer。

Harness 可以搜索 Files、组织 Tool Calls、返回 Shell Output、管理 Context、控制 Iterations，并规定 Agent 在什么时候、以什么方式结束 Task。因此，同一个 Base Model 放在不同 Harness 里，最终成绩可以不一样。

这并不是一个必须从 Benchmark 中完全剔除的“干扰项”。对于 Coding Agent 来说，Harness 本来就是系统的一部分。更好的 Tooling 如果能让模型更快找到相关 File，或者更好地理解失败的 Test，那么这在真实使用里就是价值。

真正的问题是：当我们拿到一个 System Score，却把它完全归因于 Base Model。

当前 Leaderboard 也在尝试控制这一变量。例如 SWE-bench Verified 提供 Bash Only 视图，让不同 Models 在同一个 mini-SWE-agent Environment 中比较。 [3] 这不会消除所有差异，但至少标准化了一部分 Harness Variation。

Pass@1 和 Pass@k

Benchmark 后面一个很小的数字，也可能极大改变它的含义：k。

Pass@1 可以简单理解为一次尝试的成功情况。Pass@k 则描述或估计在生成多个 Candidates 时，至少其中一个成功的概率。这个概念通过 Codex 的 HumanEval Evaluation 被广泛普及。 [8]

如果每次尝试都有一定成功概率，那么允许多次尝试，自然会提高最终至少得到一个正确答案的机会。生成 8 个 Candidates 再挑出成功的一个，和只允许 1 次尝试，是两种不同的实验。

这并不意味着 pass@8 比 pass@1 “作弊”或者更差。现实产品里并行生成多个方案，再由自动系统或者人来选择，完全可能是合理策略。关键只是，不要把两个 Score 当成是在同样次数机会下得到的。

k 不是统计学脚注，而是 Experiment Setup 的一部分。

Token 和 Compute Budget

Compute Budget 也是一样。一个 Agent 用几次 Iteration 和 50,000 Tokens 完成 Task，和另一个 Agent 可以使用几百万 Tokens、很多 Tool Calls 和大量额外步骤，是完全不同的工作条件。

更多 Compute 本身不是坏事。如果额外 Inference 能稳定提升结果，而且真实场景允许这个 Budget，它可能就是正确的技术选择。

但做 Benchmark Comparison 时，我们必须知道系统到底被允许使用多少资源。否则，我们比较的不只是能力，还比较了“被允许工作的总量”。

SWE-rebench Leaderboard 上公开的 Token Usage 分析（访问日期 2026 年 9 月 10 日）很直观地展示了这种差异：不同 Agent Systems 在同一 Task Family 上比较时，Token Usage 的差距可以超过 30 倍。 [12]

这些额外 Budget 到底值不值得，从经济上看是另一个问题。这个系列后面会单独讨论。

连 Infrastructure 都能带来百分点

在传统 Text Benchmark 中，模型在哪台机器上生成答案往往几乎不可见。Coding Agent 则不同。它会主动操作环境，安装 Dependencies、启动 Compiler、运行 Tests，并可能产生 CPU 或 Memory Intensive Processes。

Anthropic 在 2026 年初用 Terminal-Bench 2.0 研究了这个影响。Model、Harness、Task Set 完全一样，只改变 Resource Configuration。测试中最紧张和最宽松的 Infrastructure 之间，Score 相差 6 个百分点。即使只看更温和的配置，仍然有接近 2 个百分点的波动。 [9]

这并不意味着每个 Benchmark Score 都“错了 6 个点”。它说明在 Agentic Eval 中，Runtime 本身也是 Experiment Setup 的一部分。一个进程因为 Memory Limit 被 Kill，最终同样会表现为 “Task unresolved”，即使原因和 Agent 做了错误修改完全不同。

当 Leaderboard 上两个模型只差 1 到 2 个百分点时，用“Model A 明显击败 Model B”这样的说法就应该更谨慎。

当 Benchmark 自己发生变化

Terminal-Bench 在 2026 年还提供了另一个很好的例子。Version 2.1 修正了 Terminal-Bench 2.0 中 89 个 Tasks 里的 28 个，并引入 Continuous Validation。重新 Evaluation 后，一些模型的 Score 发生明显变化。例如公开对比中，Claude Opus 4.6 + Claude Code 从 58.0 上升到 70.1。 [10]

Model 没有突然变聪明。变化的是 Benchmark，并且目标是让 Evaluation 更公平、更可复现。

只说“Terminal-Bench”这个名字是不够的：官方 Benchmark 概览已经列出 Terminal-Bench 3.0，而本文引用的 Qwen3.8 Model Card 仍然使用 Terminal-Bench 2.1。 [1][10] 对比时真正重要的是具体的 Version 和具体的实验设置，而不是假设存在某一个唯一的“当前”参考版本。

所以如果有人引用“Terminal-Bench Score”，就应该同时说明 Version 和实验设置。不同 Version 和不同 Setup 的分数并不能直接互相比较。

Benchmark Version Number 不是挑剔，它本身就是测量条件的一部分。

更高 Score，还不是采购决策

回到最开始的例子。Qwen3.8-27B 有 270 亿 Parameters，Model Weights 以 Apache 2.0 公开，Model Card 也给出了多种在自有 Infrastructure 上运行的方法。 [1]

Decision Maker 可能会看到：

Qwen3.8-27B:      61.7%
Claude Opus 4.6:  53.4%

然后得出结论：那就部署几台自己的 GPU System，显然比购买 Commercial Cloud Models 更划算。

Benchmark 本身并不能支持这个决策。真正的采购还需要看实际 Task Profile、需要的能力、Data Sovereignty、Privacy、Confidentiality、Operations、Concurrency、Latency、Context Requirements、Cost 和后续 Review Effort。

Local 或 Self-Hosted Processing 的含义也应该更精确，而不是一句“数据留在公司内部”就结束。Self-hosted Inference 可以让整个处理过程保持内部化，前提是 Tooling、Telemetry、Monitoring、Retrieval 以及其他所有组件也被相应部署和配置。

反过来，一个更高的 General Benchmark Score，也不意味着每个开发 Task 都应该使用最强 Frontier Model。一个边界明确、Specification 清晰的实现任务，可能用更小的模型就能很好完成；而另一些任务可能确实需要更强的分析或 Exploration。

这些都是重要决策，只是 SWE-bench Pro 并不测量这些决策。

不同 Benchmark，在问不同问题

SWE-bench 不会因为它不能覆盖所有 Software Engineering 就变成“坏 Benchmark”。实际上，没有任何单一 Benchmark 能合理做到这一点。

更有用的方式，是把不同 Benchmark 当成不同测量仪器：

Benchmark	大致测量什么？
SWE-bench Pro	在已有 Repository 中完成相对真实的软件工程修改
Terminal-Bench	在 Terminal Environment 中进行多步骤工作，包括 Tools、Programs 和系统交互
SWE-Lancer	真实、曾经付费的 Freelance Software Tasks 与技术决策任务
LiveCodeBench	持续新增、按时间隔离的 Algorithmic Coding Tasks，用来降低 Contamination
SWE-rebench	持续收集新的 Repository Tasks，保持 Software Engineering Eval 的 Freshness
SWE-bench Multilingual	跨多种 Programming Languages 的 SWE-bench 类型 Repository Tasks
SWE-bench Multimodal	Requirement 中包含 Visual Information 的 Repository Issues

Terminal-Bench 把 Agent 的 Action Space 扩展到 Repository Patch 之外。Agent 在 Terminal Environment 里工作，需要 Build Software、修改 Configuration、运行 Programs，或者和已有 Tools 交互。从 2.0 到 2.1 的大幅修订，也同时说明这种环境想要做到 Reproducible Evaluation 有多难。 [9][10]

SWE-Lancer 强调另一种维度。它包含 1,400 多个来自 Upwork 的真实 Freelance Tasks，这些任务原本总计对应约 100 万美元的真实报酬。范围从 50 美元的 Bugfix，到原始报价 32,000 美元的 Feature Implementation。Benchmark 还包含 Management Tasks，需要评价技术方案。 [11] 这些真实价格让它对于一些 Economic Questions 很有意思，但它仍然不是“一个开发者的总价值”。

LiveCodeBench 主要解决 Static Coding Benchmark 的时间问题。新的 Tasks 持续从 LeetCode、AtCoder、Codeforces 等 Programming Competitions 收集，并记录发布时间。因此可以在某个已知 Training Cutoff 之后出现的 Problems 上测试模型。 [13] 但它主要测的是 Algorithmic Coding，以及 Code Execution 或 Self-Repair 等相关能力，这和在一个存在十年的 Enterprise Codebase 中工作并不是一回事。

SWE-rebench 则直接在 Repository 层面追求 Freshness。2025 年最初版本收集了超过 21,000 个 Interactive Python Tasks，来自 3,400 多个 Repositories，并持续用新任务做更抗 Contamination 的 Evaluation。到了 SWE-rebench V2，2026 年版本已经扩展到 3,600 多个 Repositories、20 种 Programming Languages、超过 32,000 个可执行 Tasks，此外还公开了超过 120,000 个附带安装信息和 Metadata 的额外 Tasks。 [12] 核心思想仍然一样：持续提供新任务，避免一个静态 Dataset 变成整个行业永远重复的“统一试卷”。

SWE-bench Multilingual 扩展了 Programming Language Coverage。它包含 42 个 Repositories 中的 300 个 Curated Tasks，覆盖 C、C++、Go、Java、JavaScript、TypeScript、PHP、Ruby 和 Rust。 [15] 这很重要，因为一个主要基于 Python 的 Benchmark，很难告诉我们相同能力是否能可靠迁移到其他 Ecosystems。

SWE-bench Multimodal 则提出另一个问题：如果 Requirement 并不完全写在 Text 里，会怎样？Bug Screenshot、Design Mockup、Wireframe 或 Diagram 在 Frontend Work 中都非常常见。2026 年 9 月 1 日发布的 Version 2 包含 480 个适合 Reproducible Evaluation 的 Tasks。 [14]

因此，没有哪个 Benchmark 是“最好”的。它们在问不同问题。

公共 Benchmark 是地图，不是你自己的地形

Public Benchmarks 对建立初步认知非常有价值。一个在多个与你 Use Case 相关的 Coding Evals 上明显落后的模型，传递的信号当然和一个在多种测量工具上都很强的模型不同。

但对于某个具体组织，真正关键的问题可能完全不同。

也许大部分工作不是 Python Bugfix，而是 Angular Migration。也许 Repository 非常大、Architecture 高度模块化，而最重要的 Quality Criterion 是不要破坏现有 Boundaries。也许 Agents 主要用于补 Tests、分析 Legacy Code，或者准备 Proprietary .NET Codebase 的修改。

这时，自己的 Evals 可能更有价值。

Internal Eval 不需要变成一个新的学术世界级 Benchmark。哪怕只是一小组可复现、能够代表真实工作的 Tasks，也能帮助观察不同 Model-Agent Systems 在你自己环境中的表现：一个典型 Bugfix、一个 Feature、一次 Refactoring、一次 Migration、Test Extension，或者 Repository Analysis。

同样需要保持纪律。系统到底拿到什么 Task？使用哪个 Repository State？允许哪些 Tools？Agent 有多少 Budget？如何定义 Success？又由谁来确认自己的 Evaluation 真的测到了组织关心的东西？

公共 Benchmark 帮助我们定位模型。自己的 Evals 帮助我们准备具体决策。

回到 61.7%

开头是两个数字：

Qwen3.8-27B      61.7%
Claude Opus 4.6  53.4%

在理解完这些背景之后，这两个数字并没有变得不重要。对于这样规模的模型来说，Qwen3.8-27B 报告的 SWE-bench Pro 结果非常值得注意。它的 Model Weights 可获得，而且可以在自有 Infrastructure 上运行，这让结果在技术和战略上都很有意义。 [1]

只是现在，这些数字应该少一点“魔法感”。

我们知道 Qwen 的 61.7% 来自 ScaleAI/SWE-bench_Pro，使用 Claude Code、特定 Sampling Settings、256K Context Window 和经过修正的 Task State。我们也知道，同一张 Qwen 表中的 Claude Opus 4.6 53.4% 并不是同一个 Qwen Run 产生，而是直接引用 Anthropic 官方报告的结果。 [1][2]

我们知道 SWE-bench Pro 比很多传统、孤立的 Coding Tasks 更接近真实 Repository Work，但它并不等于完整的软件工程。我们知道为什么 Held-out 和 Private Data 可以降低 Contamination Risk，也知道为什么一个更新的 Benchmark 仍然可能包含有问题的 Tasks。我们还知道 Harness、Tools、Compute Budget，甚至 Infrastructure 都可能影响结果。

这些限制并不会让 Benchmark 失去价值。恰恰相反，只有理解边界之后，这个数字才真正有用。

当我们知道 Benchmark 在测量什么时，它很有价值。危险的是，我们从一个精确数字中推导出 Benchmark 从未测量过的结论。

Benchmark 不是对模型的最终判决，而是一种测量工具。

而且我们几乎顺便学到了另一件事：当我们评价 Coding Agent 时，我们已经很少只是在评价 Model。Context、Tools、Harness、Persistent State，以及系统如何向模型提供信息，都会影响最终表现。

因此，在后面讨论为什么同一个模型会产生不同解决方案之前，我们还需要先弄清这些周边层次到底有什么区别：Context、Memory、Skills 和 Agents。

这就是下一篇文章的主题。

参考资料

[1] Qwen Team: Qwen3.8-27B Model Card. Hugging Face, 2026；包括 2026 年 8 月 14 日发布的 ScaleAI/SWE-bench_Pro Eval Metadata。

[2] Anthropic: Project Glasswing: Securing critical software for the AI era. 2026。Claude Opus 4.6 报告的 SWE-bench Pro Score：53.4%。

[3] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik R. Narasimhan: SWE-bench: Can Language Models Resolve Real-World GitHub Issues? ICLR 2024；并参考截至 2026 年 9 月的官方 SWE-bench Documentation 与 Leaderboards。

[4] OpenAI: Why SWE-bench Verified no longer measures frontier coding capabilities. 2026 年 2 月 23 日。

[5] OpenAI: Introducing SWE-bench Verified. 2024 年 8 月 13 日。

[6] Scale AI Research Team: SWE-Bench Pro: Raising the Bar for Agentic Coding. 2025 年 9 月 19 日。

[7] OpenAI: Separating signal from noise in coding evaluations. 2026 年 7 月 8 日。

[8] Mark Chen et al.: Evaluating Large Language Models Trained on Code. 2021. arXiv:2107.03374.

[9] Gian Segato / Anthropic: Quantifying infrastructure noise in agentic coding evals. Anthropic Engineering, 2026 年 2 月 5 日。

[10] Terminal-Bench Team: Terminal-Bench 2.1, Release Notes, 2026 年 5 月 6 日；并参考 Terminal-Bench 3.0 与 Benchmark 概览，访问日期 2026 年 9 月 10 日。每个版本号都对应其具体的 Evaluation。

[11] Samuel Miserendino, Michele Wang, Tejal Patwardhan, Johannes Heidecke: SWE-Lancer: Can Frontier LLMs Earn $1 Million from Real-World Freelance Software Engineering? ICML 2025.

[12] Ibragim Badertdinov et al.: SWE-rebench: An Automated Pipeline for Task Collection and Decontaminated Evaluation of Software Engineering Agents. 2025. arXiv:2505.20411; Ibragim Badertdinov et al.: SWE-rebench V2: Language-Agnostic SWE Task Collection at Scale. 2026. arXiv:2602.23866; 以及 SWE-rebench Leaderboard 上的 Token Usage 分析，访问日期 2026 年 9 月 10 日。这个动态 Leaderboard 并不是一条不变的 Benchmark 时间序列。

[13] Naman Jain et al.: LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code. 2024. arXiv:2403.07974.

[14] John Yang, Carlos E. Jimenez, Alex L. Zhang et al.: SWE-bench Multimodal: Do AI Systems Generalize to Visual Software Domains? ICLR 2025；SWE-bench Multimodal v2，2026 年 9 月 1 日。

[15] Kabir Khandpur, Kilian Lieret, Carlos E. Jimenez, Ofir Press, John Yang: SWE-bench Multilingual. 来自 42 个 Repositories、覆盖 9 种 Programming Languages 的 300 个 Curated Tasks。