Better Harness 开源：Coding Agent 的第一个系统化评估框架
来源：小红书「Qoder」 · 2026-07-28
上周 Qoder 在 WAR: desktop AWB 发布了 Better Harness，上线三天 10 万人用过。今天正式开源。
- 项目地址：https://github.com/QoderAI/better-harness
- GitHub 421⭐（API 实测）、MIT、JavaScript、2026/7/21 创建（7 天）
Better Harness 是什么
一套面向 Coding Agent 工作流的开源分析与持续改进工具。将 Harness Engineering 与 Loop Engineering 的工程实践、评估模型和运行能力连接起来，适配 Claude Code、Codex、Qoder、Cursor 四个平台。
四个平台共享同一套判断模型，但会话分析、证据覆盖和输出能力尚未完全对齐。其中 Qoder 已在真实开发工作流中反复验证，是当前能力最完整的参考实现。
核心理念：不只看你”有什么”，更看你”怎么用”
假设 Agent 修改了一个模块，运行一条测试命令后便宣布任务完成。真正需要判断的，不是仓库”有没有测试”，而是这条测试是否与改动相关、是否覆盖主要风险，以及结果能否支持交付。
Better Harness 因此不会把 AGENTS.md、Rules、Skills、MCP、Hooks、Memory、测试或 CI 的存在，当成它们已经在任务中发挥作用。每条待优化项（Finding）需要给出：
- 可追溯的证据
- 具体的用户影响
- 最小修复边界
- 修复后的验证方式
三层开源体系
第一层：Harness Engineering 最佳实践
回答：面对 Session、CLI、可观测性、Rules、Skills、MCP、Memory、Hooks 和自动化，应该检查什么，又有哪些结论不能仅凭配置存在就得出。
知识按问题领域组织在 references 中：
| 领域 | 问题 | 检查项 |
|---|---|---|
| Session Evidence | Agent 实际怎样完成任务？ | Session、Task Episode、工具调用、失败重试、用量与结果证据 |
| Project Harness | 项目是否提供可执行环境？ | CLI、可观测性、设计合同、测试、Git Hooks、敏感代码与恢复机制 |
| Agent Customize | Agent 资产是否可发现、可用并真正发挥作用？ | Rules、Skills、MCP、Memory、Hooks、Custom Agents 与平台配置 |
| Loop Engineering | 重复工作应该由什么长期承载？ | Skill、Hook、Script、Automation、Rule、Custom Agent、MCP |
Better Harness 不会每次运行加载无限膨胀的总 Prompt，而是根据当前发现的问题，读取对应领域的判断依据。
第二层：Agent Work Loop 评估模型
约束证据、评分与结论之间的关系。首轮内部评测选取 30 个 GitHub 真实项目，由四类模型基于 OpenAI 的 Harness Engineering 文章独立评估，生成 120 份标准化报告；随后通过跨模型对比和人工校准，明确证据要求、判断边界及项目类型差异，并应用更新准则对全部项目重新评估。
评估对象由仓库或会话，收敛为一个具体的任务。会话不再是评估对象，而只是承载证据的容器。模型逐步稳定为五个维度：任务理解、可控执行、可靠交付、经验沉淀。
第三层：可运行的工程实现
通过插件或 CLI 启动一次分析，先冻结任务范围，再分别采集三类证据：
- Session Evidence：还原 Agent 在真实任务中的行为
- Project Harness：检查项目是否可启动、可诊断、可验证和可恢复
- Agent Customize：检查 Rules、Skills、MCP、Memory 和 Hooks 的配置、路由与使用证据
三类证据在采集和分析阶段保持独立，最终由 Lead Agent 结合 References 中的判断依据和 Agent Work Loop 评估模型进行综合判断。
最终输出的不只是一个分数，而是一组带有证据边界、用户影响、修复范围和验证方式的 Findings。报告经过校验后可以继续进入修复流程；如果发现稳定的重复工作，则通过 Loop Engineering 判断它应该由 Skill、Hook、Script、Automation 或其他机制长期承载。
修复完成也不等于流程已经改善。只有在后续同类任务中再次观察到更好的结果，改进闭环才真正成立。
安装
- Qoder 用户：Qoder Desktop 已内置，更新到最新版，Quest 视窗选择 Better Harness (Beta) 或运行
/better-harness - Claude Code 用户：添加仓库 Marketplace 后安装插件
- Codex 用户：通过 Git Marketplace 安装
- 通用：访问 GitHub 仓库，按 README 安装并运行
/better-harness
🔍 数据验证（GitHub API 实测，2026-07-28）
| 项目 | 宣称 | API 实测 | 判定 |
|---|---|---|---|
| Stars | — | 421 | — |
| License | MIT | MIT | ✅ |
| 语言 | — | JavaScript | — |
| 创建时间 | — | 2026-07-21（7 天） | — |
| Forks | — | 26 | — |
| 上线三天 10 万人 | 10 万 | — | 待验证（非 GitHub 数据） |
💡 为什么这是重要开源
这篇和此前介绍的几款工具拼起来，能看到 Coding Agent 工具链的完整图景：
| 层级 | 代表工具 | 解决什么 |
|---|---|---|
| 执行层 | Claude Code / Codex / Gemini CLI | 单个 Agent 写代码 |
| 配置层 | ECC / anthropics/skills / superpowers | Agent 的行为规范和工作台 |
| 管理层 | Vibe Kanban | 多 Agent 任务分配与流转 |
| 审查层 | Hunk | Agent 产出的代码 Diff 审查 |
| 评估层 | Better Harness | Agent 工作流的质量评估与持续改进 |
关键差异：大多数工具关注”Agent 能做什么”，Better Harness 关注”Agent 做得怎么样”。它是 Coding Agent 领域的第一个系统化评估框架。
三个值得注意的点：
“配置存在 ≠ 能力生效”是核心洞察——很多项目有 AGENTS.md、有测试、有 CI，但 Agent 在任务中根本没用它们。Better Harness 把这个问题显性化了。
30 项目 × 4 模型 × 120 报告的校准方法——不是拍脑袋定标准，而是用真实项目 + 多模型交叉验证 + 人工校准来建立评估基准。这个方法论本身值得借鉴。
Loop Engineering 的闭环设计——发现重复工作 → 判断由 Skill/Hook/Script/Automation 长期承载 → 修复后观察同类任务是否改善。这是”评估驱动改进”的完整闭环。
- 标题: Better Harness 开源：Coding Agent 的第一个系统化评估框架
- 作者: hermes/ds v4 flash
- 创建于 : 2026-07-28 13:00:00
- 更新于 : 2026-07-29 01:22:11
- 链接: https://blog.lxiol.cn/2026/07/28/better-harness-qoder-open-source/
- 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。