OpenBench — Harness Benchmarks for Coding Agents
OpenBench — Harness Benchmarks for Coding Agents
一句话结论
OpenBench 是一个面向 coding-agent harness 的 benchmark：它尽量固定底层模型与任务，把变量放在 Codex、Pi、OpenCode、Cursor、Devin 等 CLI / harness 的 run loop、工具面、权限策略、token 税、墙钟时间与任务通过率上。它的关键价值不是又做一个模型排行榜，而是把“同一个模型换不同 harness 会发生什么”变成可复现实验。
为什么对用户重要
用户的 Hermes / llm-wiki radar 本身也是一个 harness：orient、搜索、读原文、保存 raw、写 source/concept、更新 _index.md / log.md、重建向量索引、最后报告。OpenBench 提醒我们，不能只说“模型强/弱”或“日报质量好/坏”；真正要评估的是整条 workflow 的结构变量：上下文加载、工具选择、权限边界、验证器、成本和时延。
这也能指导用户选择 coding agents。OpenBench README 明确把 Harness Bench 和 Gateway Bench 分开：前者看 harness 差异，后者看 API gateway 路径差异。对未来 Hermes 接入 Codex / Claude Code / OpenCode / Pi 的任务分派来说，这种分层比笼统比较“哪个 agent 最强”更可迁移。
机制 / 一阶原理
OpenBench 的一阶原理是控制变量：
- 任务自包含：每个任务有可执行 checker，exit 0 才算 solved，避免让 harness 自己声明完成。
- Track A 固定模型：保持 canonical model 与任务不变，让差异更多来自 harness 的 scaffolding、tools、prompting、permission policy。
- 多指标报告：正确率之外，还看 wall-clock、token tax、成本、重复 trials 与 transcripts。
- 分层 benchmark family：Harness Bench、Gateway Bench、未来 Router Bench 不混在一个分数里。
- 私有代码库 eval 路径：README 指向
obench init、task authoring、polarity validation、local transcripts，说明 benchmark 可以迁移到团队内部任务。
这对 Agent-Benchmarks 的补充是：benchmark 不只是任务集，也是一套变量隔离方法。一个 agent 做得好，可能来自模型、harness、gateway、工具授权、任务污染、checker 设计或运行预算；如果不分层记录，结论不可迁移。
与既有 wiki 概念的关系
- 对 Agent-Benchmarks：补充“harness 作为被测变量”的具体实现，尤其是固定模型、任务、gateway 与 transcripts 的分层。
- 对 Harness-Engineering：把 harness 的好坏从结构成熟度、policy 正确性推进到可量化运行表现。
- 对 Agentic-Coding：提醒 coding-agent 生产力应按 correctness、latency、token/cost、permission friction 和 verifier strength 一起评估。
- 对 coder-eval-skill-evaluation-ci：coder_eval 更偏本地 skill/workflow CI；OpenBench 更偏跨 harness 的公开/私有任务矩阵，两者互补。
对 Hermes / llm-wiki 的可执行启发
- 为每日 AI radar 增加一个轻量“workflow cell”记录：发现源、候选数、晋升数、raw 数、更新页数、reindex 状态、主要失败源。
- 把“同一 source ingest 在不同工具路径下的差异”作为未来回归测试：GitHub API、raw README、网页抽取、arXiv API 失败时的 fallback 是否仍能产出同等证据。
- 对 coding-agent 选型，不要只看 leaderboard；优先找能暴露 transcripts、checker、成本和权限策略的 harness。
- wiki 页面里的“深度判断”可以被当作 micro-checker：没有回答重要性、机制、关系、启发、失败模式的 source 不晋升。
失败模式与边界
- README 中的 headline findings 可能随任务集、模型版本、闭源 harness 菜单变化而漂移，当前只应作为 medium confidence 线索。
- 如果任务过于 synthetic，frontier harness 容易 correctness ceiling，必须引入 Terminal-Bench / private tasks / harder tasks 才能区分。
- 固定模型有助于隔离 harness，但真实使用常常同时变化模型、gateway、预算与权限；生产选型仍需本地复验。
- benchmark 可能被 harness 特化优化，因此需要新鲜任务、transcripts 和污染控制。
深度判断
值得深挖并正式入库。它直接澄清了 llm-wiki 已有 Harness-Engineering 与 Agent-Benchmarks 的交叉盲点：harness 不只是规则集合，也应成为可测变量；而且它给出私有代码库 eval、checker、transcripts、gateway 分层等可执行机制。
写入记录
- 2026-07-25 09:00 CST：新增 source 页面，分析 OpenBench 对 harness-as-variable、coding-agent benchmark 分层和 llm-wiki radar micro-benchmark 的启发。