# 原文摘要 - Better Harness：用任务证据持续改进 Coding Agent 工作流

- 原文：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

## 一句话总结

Better Harness 不是检查项目有没有 AGENTS.md、测试或 Skill，而是把一次真实任务作为评估单位，分离采集会话、项目与 Agent 配置证据，在五维 Agent Work Loop 中输出可修复、可验证、可纵向复验的 Finding。

## 核心观点

1. **配置存在不等于任务中生效**：仓库有测试、Rules 或 MCP，只能说明机制存在；只有与当前任务关联的行为证据，才能支持“它被使用并帮助交付”的结论。
2. **先保留证据边界，再讨论评分**：缺少会话或宿主测试时应显示“未观测”，不能用配置数量、时间邻近或单次命令成功补成结论。
3. **完整开源物应包含三层**：工程判断依据（references）、任务中心的 Agent Work Loop 评估模型、以及证据采集与报告生成的可运行实现。
4. **改进单元是 Finding，不是总分**：每条 Finding 应同时给出可追溯证据、用户影响、最小修复范围和验收方式，便于逐项处理。
5. **改善只能由后续同类任务证明**：修复后再跑一份报告只能确认干预被执行；只有可比较的后续任务数据，才能证明工作流真的变好。

## 核心结构速查

| 层级 | 解决的问题 | 关键产物 |
| --- | --- | --- |
| Harness Engineering 实践 | 什么该检查，哪些结论不能只靠配置推出 | 分领域 references |
| Agent Work Loop 模型 | 如何连接证据、评分与结论 | 五维评估、证据状态、Finding 边界 |
| 可运行实现 | 如何在真实项目重复采集、分析与修复 | 插件或 CLI、采集器、分析器、报告 |

| 证据域 | 回答的问题 | 不能替代什么 |
| --- | --- | --- |
| Session Evidence | Agent 在这次任务实际做了什么 | 项目长期能力 |
| Project Harness | 项目是否可启动、诊断、验证与恢复 | Agent 是否实际使用了这些能力 |
| Agent Customize | Rules、Skills、MCP、Memory、Hooks 是否配置及有无使用线索 | 任务结果是否得到证明 |

## 七个分析角度与开头钩子

### 1. 配置清单和交付证据

- 仓库里有一百个 Skill，为什么 Agent 还是会在关键任务里迷路？
- 测试目录存在，不等于这次改动已经被测试证明。
- “配置齐全”为什么是 Agent 工程里最容易出现的假安全感？

### 2. 证据边界

- 没有宿主测试记录时，报告最该说的不是“失败”，而是“我不知道”。
- 一条成功命令，为什么还不足以证明一次可信交付？
- 当工具看不见某段行为，评分系统如何避免把沉默误判成优秀？

### 3. 任务级评估

- 为什么 Better Harness 不直接给整个仓库打成熟度分？
- 从“仓库里有什么”转向“任务里发生了什么”，难在哪里？
- 会话为什么只是证据容器，而不应天然等于评估对象？

### 4. 五维 Agent Work Loop

- Agent 真正做错时，问题到底出在理解、执行、验证、交付还是经验沉淀？
- 如何把“它看起来很能干”拆成五个可检查的问题？
- 为什么改完代码后的测试，并不是 Agent 工作流的全部？

### 5. Finding 驱动修复

- 总分只能制造焦虑，什么样的报告才真正能推动下一次改进？
- 一条好的 Finding，为什么必须同时写出影响、修复边界和验收？
- Agent 工程如何从“大改造”退回到一次只修一个可验证问题？

### 6. 评估模型如何校准

- 谁来定义“好的 Harness”？为什么不能让一个模型拍板？
- 30 个真实项目、四类模型和人工校准，究竟在校准什么？
- 评估规则会过时，怎样让它本身进入持续复验的循环？

### 7. 从报告到长期改进

- 修完一条 Finding 后，为什么不能立刻宣布工作流提升了？
- 什么时候重复工作应该沉淀为 Skill、Hook、Script 或 Automation？
- Harness Engineering 的终点为什么不是一份漂亮报告，而是后续任务真的少走弯路？

## 可执行的最小闭环

1. 选择一个边界明确、能回滚的真实任务，而不是笼统扫描整座仓库。
2. 冻结任务范围，独立采集会话、项目和 Agent 配置证据。
3. 按任务理解、可控执行、改动验证、可靠交付、经验沉淀五维判断，并将未观测项保留为未知。
4. 只选择一条证据充分、影响明确、能快速验收的 Finding 修复。
5. 重跑同一类检查确认干预被执行；积累可比较的后续任务后，再判断工作流是否改善。

## 证据边界

- “30 个 GitHub 项目、四类模型、120 份报告、200 多份 Spec”来自公众号作者对项目建设过程的陈述，本文未独立复跑该评测。
- 官方 README 已在 2026-07-30 读取，确认项目开源、MIT 许可、五维 Agent Work Loop、三类证据边界及 Claude Code、Codex、Qoder、Cursor 的宿主支持；宿主能力和安装命令可能随版本变化，应以项目 README 为准。
- 评分、单次报告与修复完成都不能单独证明因果改进；项目 README 同样明确需要可比较的后续结果。

标签：#主题/AI-Agent #主题/Harness #主题/Loop-Engineering #主题/AI-Coding #节点/Agent-Work-Loop #节点/任务证据 #节点/Findings #场景/开源项目 #场景/公众号长文