Better Harness：用任务证据评估并持续改进 AI Coding 工作流
- 原文链接：https://mp.weixin.qq.com/s/PuMpxU1ruXlTgT_JWKoHfQ?scene=1&click_id=8
- 作者：phodal
- 发布时间：2026-07-28 21:28
- 开源项目：https://github.com/QoderAI/better-harness
- 获取时间：2026-07-30
核心结论（一句话）
Better Harness 把 Harness Engineering 从“仓库配置体检”推进到“任务级证据评估”：只有将真实任务的证据、最小修复和后续可比较结果连成闭环，才能证明 Coding Agent 工作流在改善。
分类提炼
- 场景：Coding Agent 工作流诊断、Harness 建设、持续改进
- 标签：#主题/AI-Agent #主题/Harness #主题/Loop-Engineering #主题/AI-Coding #节点/Agent-Work-Loop #节点/任务证据 #节点/证据边界 #节点/Findings
- 类型：开源工具拆解 / 评估模型 / 工程实践
知识节点（8 个独立概念）
- 任务级证据：评估单位是一次具体任务，而不是整个仓库或一段会话。
- 证据边界：未观测到的行为必须保留为未知，不能用代理信号补成结论。
- 三类证据：会话、项目 Harness 与 Agent 定制证据独立采集，最后才综合判断。
- Agent-Work-Loop：以任务理解、可控执行、改动验证、可靠交付、经验沉淀覆盖交付闭环。
- 可追溯Finding：每个问题必须同时给出证据、用户影响、最小修复边界和验收方式。
- 前馈反馈：规则、规格与 Skill 在行动前引导；测试、Hook 与评审在行动后纠偏。
- 评估校准：评估准则通过多模型对比、人工校准与复跑迭代，而非由单一模型决定。
- 纵向复验：修复完成只证明干预已执行；后续可比较任务变好，才证明工作流改善。
运行模型
Better Harness 公开的对象不是单条 Prompt，而是相互连接的三层：
| 层级 |
作用 |
对应问题 |
| 工程实践 |
分领域的判断依据 |
什么值得检查，什么不能只凭配置推出 |
| Agent Work Loop |
任务中心的评估模型 |
证据、评分、结论与 Finding 如何约束 |
| 可运行实现 |
采集、分析、报告与修复入口 |
如何在项目中持续执行和复验 |
其中最重要的约束是“资产存在”与“任务使用”不可混为一谈。AGENTS.md、Rules、Skills、MCP、Hooks、Memory、测试和 CI 能证明一个机制存在；但只有可关联到本任务的证据，才能支持“Agent 使用了它”或“它改善了交付”的结论。
工具先冻结任务范围，再并行采集三类信息：Session Evidence 还原实际行为；Project Harness 检查项目是否可启动、诊断、验证和恢复；Agent Customize 检查规则、Skill、MCP、Memory、Hook 的配置、路由与使用线索。它们在采集阶段不互相代偿，最终才结合 references 和 Agent Work Loop 给出综合判断。
五维评估与修复闭环
| Agent Work Loop 维度 |
要回答的问题 |
典型证据 |
| 任务理解 |
Agent 是否知道目标和完成标准 |
规格、AGENTS.md、验收条件 |
| 可控执行 |
是否沿可支持、可复现的路径行动 |
Skill、命令、MCP、沙箱边界 |
| 改动验证 |
是否有证据证明改动真的有效 |
测试、lint、Hook、诊断信号 |
| 可靠交付 |
是否绕过质量门禁或验收 |
人工评审、审批、CI/CD、恢复路径 |
| 经验沉淀 |
下一次任务能否受益 |
Loop Discovery、可复用 Skill、Memory |
报告的交付单位不是一个总分，而是一条 Finding。它应当写清：
- 哪些可见证据支撑这个判断，以及哪些证据尚不可见。
- 对用户或交付造成什么具体影响。
- 最小、可评审的修复范围是什么。
- 修复后应以什么验证方式确认。
修复顺序也应保持保守：先挑一条证据清楚、影响具体、验收便宜的问题；修完重跑检查；再观察后续相似任务。评分只能帮助定位，不能替代改进因果的证明。
评估模型的价值与边界
公众号称，首轮内部评测选取 30 个 GitHub 真实项目，使用四类模型生成 120 份标准化报告，经跨模型对比和人工校准后复跑；并在 200 多份 Spec 的积累中，把关注点从静态资产转向任务实际行为。这个过程的价值是把“什么算好 Harness”变成可讨论、可修订的准则，而不是模型的主观偏好。
但这不是通用成熟度认证：
- 公众号所述评测规模和 Qoder 内部实践尚未由本条目独立复跑。
- 不同宿主的会话分析、证据覆盖和报告形式并未完全对齐；原文将 Qoder 视为当前最完整的实现。
- 单次通过的检查只能证明某个干预被执行，不能证明它改善了下一次任务。
- 缺少可靠验证器的高主观任务，仍然需要人工评审，不能被分数自动放权。
关联图谱
上游（基于 / 来自）
- [[Lilian-Weng-Harness-Engineering-自我改进]]：给出 Harness 是模型外部运行系统、应围绕反馈演进的理论坐标。
- [[Harness工程AgentLoop]]：提供 Loop 走向工业交付时需要工程决策与失败处理的骨架。
- [[Loop-Engineering-验证才是瓶颈]]：说明 Better Harness 的“改动验证”和证据边界为什么不能被总分替代。
下游（应用于 / 验证于）
- [[若飞-Agent-记忆与可验证自我改进怎么设计]]：可把连续报告中被证实的经验，经过准入与回归门后再升级为长期记忆或 Skill。
- [[WorkBuddy-Harness工程复盘-从模型到可用Agent]]：其前馈与反馈分层为三类证据和五维工作循环提供产品化解释。
同级（横向 / 并列）
- [[Lilian-Weng-Harness-Engineering-自我改进]]：偏理论与递归自我改进；本文偏任务证据、报告和运行实现。
- [[WorkBuddy-Harness工程复盘-从模型到可用Agent]]：偏概念分层；本文给出开源评估工具的具体边界。
- [[Loop-Engineering-验证才是瓶颈]]：偏验证器的上限；本文把验证扩展成可追溯证据与修复工作流。
相关链接