来源：GitHub (★126)
URL: https://github.com/minghinmatthewlam/openbench
精读日期：2026-08-20
模型：DeepSeek V4 Flash（AI 生成，人工未审校）
正文获取：全文

一、核心论点/事实

  • 核心问题：同一个底层模型和任务，外围 harness（脚手架、工具集、提示词、权限策略）对结果的影响有多大？OpenBench 从零构建基准来量化这一影响。
  • 两大基准族：Harness Bench（固定模型/提供商/采样/任务，变化 coding-agent harness）和 Gateway Bench（固定模型/提供商/采样/任务，变化 API 网关），另有 request-level 伴生基准对比冷/热同 socket 请求。
  • 关键发现：前沿 harness 在 repo 自建任务上正确率饱和（M4.5 等达到天花板，解决所有核心任务），正确率无法支撑排行榜；但效率（速度、token 成本）在正确率饱和时仍能区分 harness，早期矩阵中速度差异达 ~4×，token 开销差异达 ~8×。
  • 开源模型表现：72 次运行的 open-model 面板覆盖 45 个 cell（3 harness × 5 Terminal-Bench 任务 × 3 次试验），每个 harness 平均 12/15（均值 0.80），低于合成任务天花板；最精简/高效的 harness 在实测面板中胜出。
  • 成本可复现：open models × 3 个更难任务 × 3 次试验，约可复现（具体金额未给出，但强调低成本）。
  • 评测原则：任务由 checker 脚本评分（exit 0 = 解决，可选部分学分），绝不采用 harness 自身的成功声明。
  • 硬件要求：无需 GPU，Core 和 Exercism 任务可在普通笔记本运行；Terminal-Bench cell 需 Docker 隔离，真实 harness 运行需对应 CLI 和认证。

二、方法/架构拆解

  • 任务集构成：
  • 默认本地任务套件（Core 任务 + Exercism 任务）
  • 5 个 Apache-2.0 Terminal-Bench 任务，适配 OpenBench 的 Docker lane，含部分学分更难任务（如 spec 任务，带 per-task provenance）
  • 任务格式定义在 tasks/ 目录，checker 脚本为评分核心
  • Harness 覆盖：codex、pi、opencode、cursor、devin，通过适配器（adapters）接入，可触达各 harness 的 CLI 和认证。
  • Gateway Bench：使用 sealed proxy metering 和严格 Harbor evidence 验证，对比各网关与提供商直连的差异；obench gateway probe 用于无 harness 的网关探测（accounting、route-integrity probes）。
  • 命令体系：
  • 规范命令：obench gateway validate|doctor|run|report|publish|verify
  • 诊断/迁移命令：obench doctor --harness pi,opencode --model glm-4.7-flash、obench legacy run、obench report --efficiency --results-path results/results.jsonl
  • 高级命令为迁移/诊断工具，非日常使用
  • 模型面板：open-model 面板使用 glm-4.7-flash、glm-5.2、deepseek-v4-flash、kimi-k2.7-code；frontier Track A 使用订阅/OAuth 登录，open-model 面板使用第一方提供商 API key（存放在 repo 外）。
  • 评测流程：每个 harness 以 headless 模式运行，任务自包含，checker 脚本判定成败；Harbor-native task/suite/profile scaffold 为默认结构。
  • 未来方向：自动模型/提供商选择是不同产品面，提出 native automatic-routing benchmark 契约（不承诺可运行 runner）。

三、值得注意的局限/争议

作者承认的局限：

  • 正确率饱和问题：前沿 harness 在 repo 自建任务上全部解决，正确率无法区分，需依赖效率指标。
  • Terminal-Bench 任务在最新发布分析中表现 flaky（不稳定），需先验证原始提交数据集再外部引用。
  • open-model 面板仅限开源模型，避免意外计费到付费 API。
  • 真实 harness 运行需要对应 CLI 和认证，安装/认证有 caveat。

AI 判断的局限/争议：

  • 任务集规模有限（Core + Exercism + 5 个 TB 任务），可能不足以代表真实世界编码场景的多样性。
  • 效率指标（速度、token 成本）受 harness 实现细节影响大，可能反映工程优化而非智能水平，需谨慎解读。
  • Gateway Bench 的 sealed proxy metering 和 Harbor evidence 验证增加复杂度，可能引入额外开销或偏差。
  • 自动路由基准仅提出契约而无运行器，实际可行性未验证。
  • 部分任务（如 spec 任务）的 per-task provenance 可能引入数据泄漏风险，需检查任务来源与模型训练数据的重叠。

四、与 RRLab 研究的关联

  • Harness 工程：OpenBench 的核心命题——"同一模型，不同 wrapper"——直接对应 RRLab 的 harness 工程方向。可借鉴其 harness 对比方法论（固定模型/任务，变化 harness），建立 RRLab 自己的 harness 评测矩阵，量化脚手架、工具集、权限策略对结果的影响。
  • 多模型协同：Gateway Bench 的自动路由基准（automatic-routing）与 RRLab 的多模型协同方向高度相关。可参考其 gateway 对比方法（sealed proxy metering、route-integrity probes），设计多模型路由的评测方案，验证不同网关/路由策略的成本与质量权衡。
  • 模型评测：OpenBench 的 checker 脚本评分原则（exit 0 = 解决，绝不信任 harness 自报成功）是评测可靠性的关键实践。RRLab 可借鉴此原则，在模型评测中引入独立验证机制，避免模型/harness 的自我评估偏差。其效率指标（速度、token 成本）在正确率饱和时的区分能力，提示 RRLab 评测体系应包含效率维度。
  • Agent 落地：OpenBench 的 Docker lane 和 headless 运行模式，为 Agent 的自动化测试和 CI/CD 集成提供了参考。RRLab 在 Agent 落地时可参考其任务自包含、checker 评分、Docker 隔离的实践，确保 Agent 在真实环境中的可复现性和安全性。
  • AI 原生产品：OpenBench 的 leaderboard 设计（Harness Bench 和 Gateway Bench 分 tab）和低成本复现（open-model 面板约 72 次运行）为 RRLab 的 AI 原生产品提供了产品化思路——以可复现、低成本的方式向用户展示工具链的价值差异，而非仅依赖模型能力。

本笔记由 DeepSeek V4 Flash 自动生成，未经人工审校。原文链接：https://github.com/minghinmatthewlam/openbench