开源工程 · 学术观察 001

SWE-bench Verified 说明 Benchmark 质量本身就是工程质量

只有 Issue、Test、Environment 与 Evaluator 都有效且可重建，Coding Agent Score 才有意义。

EA001Production Test V1 · 2026-08-02English →

Summary

原始 SWE-bench 论文从 12 个常用 Python Repository 的真实 GitHub Issue 与对应 Pull Request 中建立了 2,294 个 Software-engineering Problem。Agent 接收 Repository 与 Issue Description，修改 Codebase，再通过与已解决 Issue 相关的 Test 进行评估。

SWE-bench Verified 后续研究了另一个问题：Benchmark 本身有多可信？OpenAI 与 SWE-bench 作者组织 Professional Software Developer 审查 Issue Clarity 与 Test Validity，最终形成 500 个 Human-validated Sample，并使用 Containerized Evaluation Harness。

Research Center 的判断是：

Benchmark Quality 本身就是 Software-engineering Quality。如果 Issue 描述不足、过窄 Test 拒绝有效解法、Environment 无法重建，或者 Evaluator 不代表真实 Acceptance Contract，就无法可靠评估 Coding Agent。

对 CodeFlowMu 而言，这意味着建立 Internal Benchmark 时，Task Selection、Environment Pinning 与 Acceptance-test Review 必须得到与 Agent Implementation 同等程度的工程投入。

Source

主要研究对象

1. SWE-bench: Can Language Models Resolve Real-World GitHub Issues?：原始 Benchmark 论文，包含 12 个 Python Repository 的 2,294 个 Problem。
2. SWE-bench Official Repository 与 Evaluation Harness：可执行 Dataset 与 Docker-based Evaluation Infrastructure。
3. Introducing SWE-bench Verified：OpenAI 与 Benchmark 作者共同完成的 500-sample Human-validated Subset 报告。

Research Question

从 SWE-bench 到 SWE-bench Verified 的变化，揭示了 Production Engineering Team 应如何设计和解释 Agent Evaluation？

Observation

1. Task 由 Issue、Repository State 与隐藏 Acceptance Test 共同定义

一个 SWE-bench Instance 提供原始 Issue Text 和特定历史 Revision 的 Codebase。Agent 必须在看不到 Benchmark Acceptance Test 的情况下生成 Patch。

Evaluation 使用两类重要 Test：

• FAIL_TO_PASS：Reference Fix 之前失败、正确修复后应通过的 Test；
• PASS_TO_PASS：Fix 前后都应继续通过的 Existing Test，用于防止无关功能 Regression。

Patch 并不会因为能够 Clean Apply 或修改了预期 File 就获批；它必须同时满足 New-behavior Contract 与 Regression Contract。

2. 真实 Issue 可能不适合作为 Benchmark Task

Verified Project 邀请 Professional Developer 判断 Issue Description 是否足够明确，以及 FAIL_TO_PASS Test 是否会公平接受有效解法。

OpenAI 报告显示，93 位具有 Python 经验的 Software Developer 对 1,699 个 Random Test Sample 进行了 Annotation。每个 Sample 由三位独立 Annotator 标注，并保守采用最严重 Label。该过程过滤了描述不足、Test 不公平或存在其他 Major Issue 的 Sample，最终构建 500-sample Verified Set。

公开的 Annotation Result 表明，Benchmark Curation 不是简单清理。大量真实 Issue 可能存在歧义，或者由只编码某一种狭窄 Implementation Path 的 Test 评估。

3. Test 既可能低估，也可能高估能力

过度具体的 FAIL_TO_PASS Test 可能拒绝正确 Alternative Patch；不完整的 Regression Suite 可能接受破坏其他行为的 Patch；Environment 或 Result Parsing 缺陷也可能错误标记 Test。

因此，Benchmark Result 实际测量的是：

Agent Capability
× Issue Quality
× Repository Snapshot Quality
× Dependency/Environment Reproducibility
× Acceptance-test Validity
× Harness Correctness

图：joinwell52 Research Center 根据 SWE-bench 与 SWE-bench Verified 综合。

任意一个 Factor 失效，Score 就不再是 Agent Capability 的干净测量。

4. Containerization 使 Evaluator 成为 Release 的一部分

SWE-bench 项目迁移到 Fully Containerized Docker Evaluation Harness，以提高 Execution Reproducibility。一个 Task 与 Repository Code、Dependency、Operating Environment、Command 与 Expected Test Behavior 绑定。

这是一项 Engineering Release，而不只是 Dataset Download。Evaluator 必须 Versioned，必须用 Reference Patch 测试，并且在 Result 异常时接受审查。

5. Benchmark Score 不是 Production Capability Claim

SWE-bench 在特定 Interface 与 Evaluator 下测试 Repository-level Issue Resolution。它不直接衡量 Requirement Discovery、Stakeholder Communication、Architecture Design、Deployment、Incident Handling、Security Review、Maintenance Cost 或 Long-term Ownership。

高 Benchmark Score 可以是有价值 Evidence，但仍不足以证明 System 可以作为完整 Software-development Team 运行。

Discussion

Acceptance Contract 有四个层次

层次	目的	缺失时的 Failure
Problem Statement	定义目标变化与 Constraint	Agent 被未公开 Requirement 评判
Repository Snapshot	固定 Code 与 Dependency Context	Result 无法重建
New-behavior Tests	证明请求的 Issue 已解决	Patch 可能未解决问题
Regression Tests	保存 Existing Behavior	Patch 可能产生 Collateral Damage

表：joinwell52 Research Center 综合。

第五层 Human Review 仍然重要，用于判断 Maintainability、Scope、Style、Security，以及 Test 没有完整表达的情况。

Task Curation 是 Governance Function

Internal Benchmark 应具有 Admission Gate。Task 进入 Suite 之前，Reviewer 应回答：

1. Issue 是否足够明确，同时允许多种有效 Implementation？
2. Reference Patch 是否真实解决描述中的行为？
3. Acceptance Test 测试的是 Behavior，而不是 Implementation Detail 吗？
4. 重要 Regression Risk 是否被覆盖？
5. Environment 能否从 Pinned Artifact 重建？
6. Task 是否不依赖无法获得的 Secret、Service 或不稳定 External Dependency？
7. Task 是否代表目标 System 应完成的真实工作？

未通过这些检查的 Task 应被 Queue Reject 或 Defer。

Gold Patch 也必须测试

一个必要 Validation Step，是让 Reference 或 Gold Patch 通过完全相同的 Harness。如果 Known Solution 无法通过，Task 或 Environment 在查清之前就是 Invalid。

Harness 还应运行 No-op 或 Intentionally Incorrect Patch，验证 Evaluator 能够区分 Failure 与 Success。

单一 Aggregate Score 会隐藏工程行为

CodeFlowMu Internal Evaluation 不应只报告 Resolved Percentage：

evaluation_result:
  task_result:
  fail_to_pass_result:
  pass_to_pass_result:
  patch_applied:
  build_result:
  test_runtime:
  retries:
  tool_calls:
  changed_files:
  evidence_refs:
  human_review_result:
  maintainability_notes:
  security_notes:
  environment_version:
  harness_version:

这样可以支持 Diagnosis 与 Comparison，而不假装所有 Task 或 Failure 都等价。

Benchmark Leakage 与 Historical Repository 需要谨慎处理

Public Issue、Pull Request、Patch 与 Test 可能存在于 Model Training Data 中，或者在 Evaluation 期间被发现。严格 Setup 应控制 Network Access，向 Agent 隐藏 Evaluator Detail，记录 Contamination Risk，并为 Production Claim 增加 Private 或 Newly Authored Task。

Historical Repository 也可能与组织当前 Stack 与 Workflow 不同。Benchmark 必须由代表性 Internal Project 补充。

Evaluation 应覆盖 Team Process

CodeFlowMu 是 Multi-role Development Runtime，而不只是 Patch Generator。其 Benchmark 应测试：

• PM Decomposition 与 Acceptance Criteria；
• DEV Implementation；
• QA Independent Review 与 Executable Verification；
• OPS Environment 与 Release Evidence；
• Tool 或 Session Failure 后的 Recovery；
• ADMIN Decision 与 Release Authority；
• Task、Report、Evidence 与 Lifecycle History 的保存。

这把 SWE-bench 对 Patch Correctness 的启发，扩展为 Governed Project Execution。

Limitations

1. SWE-bench 集中于 Python Repository 与 GitHub Issue-resolution Task。
2. Verified 改善 Task Quality，但不保证 Complete Test Coverage。
3. Public Benchmark Data 存在 Contamination 与 Optimization Risk。
4. Docker 提高 Reproducibility，但不能消除 Host、Architecture、Timing 或 Dependency Variability。
5. Passing Tests 不会自动证明 Maintainability、Security 或 Architecture Quality。
6. Human Annotation 是特定 Rubric 下的 Judgment，不是 Absolute Ground Truth。

这些 Limitations 不降低 Benchmark 价值，而是界定 Result 应如何解释。

Engineering Impact

TMPA

本笔记不直接修改 TMPA 正式出版物。它支持 Requirement、Repository State、Environment、Test、Evaluator、Evidence、Review 与 Completion Decision 之间的显式 Integrity Reference。缺少这些 Reference 的 Benchmark Score 无法被确定性重建。

Digital Employee

Software-development Digital Employee 需要 Position-specific Evaluation Portfolio，而不是一个 Leaderboard Score。Portfolio 应覆盖 Code Repair、Feature Work、Review、Testing、Release Preparation、Recovery 与 Governance Scenario。

每个 Result 都必须保存准确 Task/Evaluator Version，并标明哪一个 Human Authority 接受了结果。

CodeFlowMu

下一套 CodeFlowMu Engineering Benchmark 应采用 Curated Internal Suite，并包含：

1. Version-pinned Repository 与 Docker 或同等 Isolated Environment；
2. Explicit Problem Statement 与 Acceptance Contract；
3. FAIL_TO_PASS 与 PASS_TO_PASS Test；
4. Gold-patch 与 Negative-control Validation；
5. 用于降低 Leakage 的 Private Task；
6. PM、DEV、QA、OPS 与 ADMIN Process Evidence；
7. Structured Result Record 与 Failure Taxonomy；
8. 对 Correctness、Maintainability 与 Security 的 Human Review。

Task 不应因为“难”就进入 Benchmark，而应因为它 Valid、Reproducible、Relevant，并且能够产生可信 Completion Judgment 而进入。

Future Work

1. 定义 CodeFlowMu Benchmark Task Standard。
2. 建立首批 Small、Medium 与 Multi-stage Task Suite。
3. 构建 Containerized Harness，并验证每个 Gold Patch。
4. 增加 Negative Control 与 Evaluator Self-test。
5. 分开 Patch Success、Process Governance、Evidence Completeness、Recovery 与 Maintainability Metric。
6. 比较 Public SWE-bench Task 与 Private CodeFlowMu Task。
7. 随每次 Result 发布 Benchmark Version 与 Immutable Manifest。

References

1. Jimenez 等，SWE-bench: Can Language Models Resolve Real-World GitHub Issues?：https://arxiv.org/abs/2310.06770
2. SWE-bench，Official Repository and Evaluation Harness：https://github.com/SWE-bench/SWE-bench
3. OpenAI，Introducing SWE-bench Verified：https://openai.com/index/introducing-swe-bench-verified/