Qoder 开源 Better Harness：不只评代码，更要审视 AI 编程工作流

它解决的不是“模型会不会写代码”，而是“流程能不能稳定交付”

Qoder 的 Better Harness 是一个面向编程智能体工作流的开源审查与改进项目。它不把一次模型回答、一次提交或一个代码 diff 当作唯一评价对象，而是检查智能体周围的完整工程环境：仓库说明、规则、权限、脚本、测试、审查与发布检查，以及在条件允许时获取的真实会话记录。其目标是找出流程缺口，给出边界清晰的修复方案，并在后续运行中验证改进是否成立。124

据报道，Qoder 于 2026 年 7 月 28 日宣布在 GitHub 开源 Better Harness。5

这里的 Harness（支撑环境），可以理解为让智能体完成工程任务的一整套“轨道和护栏”。Qoder 文档列举的组成包括仓库指令、规则、技能、钩子、插件、连接器、脚本、测试命令、发布检查和人工审查步骤等。2

这一区分很关键：模型能力再强，如果任务上下文含糊、测试入口不明确、权限控制缺失，或失败经验无法沉淀，最终交付仍可能不可靠。Better Harness 关注的正是这些运行层面的薄弱点。14

三层框架：从工程做法到可运行的审查

Better Harness 将工程实践、评估模型和实际运行能力组合为三层框架。5

第一层：Harness Engineering 工程实践

第一层覆盖塑造智能体工作方式的具体机制，包括会话与命令行模式、可观测性、规则、技能、MCP 配置、记忆、钩子和自动化等。5

它试图回答几个很实际的问题：

• 智能体是否获得了清晰的目标、限制与仓库上下文？
• 执行路径和权限是否受到恰当控制？
• 测试、质量检查与人工审查是否真正接入工作流程？
• 任务中的经验能否沉淀为可维护的项目资产，而不是随会话结束而消失？

审查从梳理当前 Harness 开始，包括目标、上下文、执行入口、反馈回路、交付机制和学习沉淀方式。1

第二层：Agent Work Loop 评估模型

第二层把上述实践转化为五个相互连接的交付维度：任务理解、受控执行、变更验证、可靠交付和学习沉淀。14

因此，核心问题不再只是“智能体生成的代码看起来是否合理”，而是：这套端到端流程能否持续产出可理解、可控、经过验证、能够交付且能吸收既往经验的变更？

该模型意在定位工作循环中的断点，例如某个机制缺失、已有能力没有接通、关键步骤从未实际执行，或结果缺乏足够证据支撑。1

第三层：可运行的工程实现

第三层让前两层不止停留在方法论。Better Harness 可通过编程智能体运行，收集项目证据以及在支持情况下的会话证据，再输出按优先级排列、可以核验的后续改进项。4

Qoder 当前材料称该项目支持 10 个宿主适配器；发布报道则点名提到 Claude Code、Codex、Qoder 和 Cursor 等编程智能体环境。56 适配范围可能随版本变化，是否支持特定宿主应以项目最新适配器文档为准。现有资料并未证实其支持 OpenClaw。

三类证据：把“有配置”与“真生效”分开

Better Harness 的一个核心设计，是把证据收集与最终判断分离。Qoder 表示，主分析流程先收集原始数据，再交给三个彼此独立、只读的子智能体分析，最后再汇总结果。1

三类视角分别是：

• Project Harness（项目支撑环境）：仓库中的工程基础，例如指令、脚本、检查和交付控制；
• Agent Customization（智能体定制）：规则、技能、钩子及其他面向智能体的配置；
• Session Evidence（会话证据）：在可获得时，智能体在真实任务中实际做过什么的记录。

这种分层有助于区分“设计上具备能力”与“运行中确实使用”。项目或配置证据可以说明某项能力存在；会话证据则能帮助判断智能体是否在实际任务中恰当地调用了该能力。14

例如，仓库里有自动化测试，只能说明具备测试能力，不能自动证明智能体修改代码后运行了相关测试、正确理解了测试结果，或用结果避免了一次错误交付。规则、钩子、技能和审批门槛也是同样的道理。15

Finding 为什么强调“可追溯”

Better Harness 不应把缺失信息悄悄转成一个看似确定的分数。其报告会保留缺失证据，并将有支持的问题整理为优先级明确的 Finding，包含影响、预期产出、范围受限的修复方式和验收检查项。46

一条有用的 Finding，至少应让团队看清四件事：

1. 在项目、配置或会话记录中实际观察到了什么；
2. 这为何会影响智能体的交付闭环；
3. 建议采用什么小范围修复，例如增加规则、技能、钩子、脚本、自动化或人工审批；
4. 修复后如何验证它确实生效。

这使讨论从“感觉这套 AI 开发流程不稳”转向可检查的工程问题。它也意味着：没有证据，不应被包装成确定结论。

改进循环：检查、修复、再测量

Better Harness 的定位不是一次性体检，而是一套迭代流程：

1. 映射当前的 Harness；
2. 找出工作流断点和证据缺口；
3. 为有证据支持的问题创建边界明确的修复任务；
4. 依据预先定义的验收检查验证修复；
5. 再次运行审查，查看新的证据是否支持更好的评估。14

因此，它能够显示流程是否变化，以及是否出现了支持更强判断的新证据。但这不等于它能单独证明某项修复在每个项目、每个模型或每种宿主环境中都必然提升智能体表现。Qoder 的材料强调观测到的证据与明确的局限，而不是将分数变化直接当作因果证明。46

如何看待“审查了 30 个真实 GitHub 项目”

发布报道提到，Better Harness 在初始实践中审查了 30 个真实 GitHub 项目。5 这一信息更适合被视为框架的探索性应用，而非证明其能普遍提升所有编程智能体和代码库的受控实验。

现有一手材料足以支持其证据模型、Finding 结构与迭代修复流程；但所提供资料没有给出足够的一手细节，供外部独立评估这 30 个项目的样本选择、评分方法或汇总结果。因此，在将它与正式基准测试比较，或据此提出广泛性能结论时，仍需保持审慎。14

面向 AI 辅助开发的“质量基础设施”

Qoder 更大的主张，是让 Harness Engineering 成为 AI 辅助软件开发中的质量基础设施：用共同术语描述工作流控制，用可观测证据支撑判断，用可比较的交付维度进行讨论，并通过重复运行形成持续改进循环。12

Better Harness 提供了这一思路的一个实践版本。对使用受支持宿主的团队而言，它提供了一种审视智能体工作条件、围绕证据而非印象讨论问题、并在后续运行中复验改动的方法。它的价值不在于承诺“每一次修复都会更好”，而在于让编程智能体工作流更可检查、可审查，也更能被证伪。46