引言“你的 AI 编程 Agent 生成代码很快但你的工作流是瓶颈。”这是「每日一个开源项目」系列的第 176 篇。今天的项目是Better Harness—— QoderAI 出品的开源评估工具分析 AI 编程 Agent 的工作流而不只是看它生成的代码。大多数对 AI 编程 Agent 的评估集中在生成的代码质量上测试通过率、漏洞密度、功能正确性。But Better Harness 的观点是Agent 之所以出错很多时候不是因为模型能力不够而是因为周围的工作流有漏洞。目标模糊、没有可复用的执行路径、变更后没有验证、质量检查被跳过、每次任务的经验都凭空消失——这些问题在 diff 里看不出来只有审查工作流本身才能发现。Better Harness 的方案收集项目和会话证据用五个维度评估工作流健康度输出优先级排序的改进建议每条建议都附带可执行的修复方案。1,500 颗 StarMIT 许可支持 Claude Code、Codex、GitHub Copilot、Cursor、Qwen Code。你会学到什么Better Harness 的核心模型前馈引导 反馈传感器五个维度具体评估什么每个维度的证据来源三个独立证据 Agent 并行分析的架构报告结构发现、修复计划、历史趋势为什么它刻意保守不从配置存在推断使用效果在 Claude Code 和 Codex 里的安装和使用方式前提知识使用过 Claude Code、Codex 或 Cursor 等 AI 编程工具了解 AGENTS.md、Hooks、Skills 等 harness 概念会有帮助对软件工程的质量保障流程CI/CD、测试、代码审查有基本认知项目背景问题Agent 改代码很快但工作流是弱点AI 编程 Agent 引入了一个新的失败模式速度。Agent 能在几分钟内完成以前需要几小时的工作但这个速度也容易绕过那些本来有价值的慢环节——仔细理解需求、在已有路径上工作、验证变更、通过人工审查。Better Harness 识别出五种常见工作流漏洞漏洞类型表现目标模糊Agent 不清楚完成是什么样子反复改错方向临时执行每次从头摸索没有可复用的执行路径未经验证的变更代码改完了但没有证据证明改动有效绕过检查AI 速度使质量检查变成了可选项经验丢失这次任务的教训不会沉淀到下次任务这五种问题在代码 diff 里通常不可见。代码通过了 review但工作流层面的问题仍然存在会在下次任务里以同样的方式出现。QoderAI 和 QoderBetter Harness 由 QoderAI 开发他们自己也做一个桌面 AI 编程 Agent——QoderBetter Harness 作为原生功能内置在 Qoder 里。开源的 Better Harness 则以插件形式支持其他主流 Agent。项目数据⭐ GitHub Stars:1,500 Forks: 123 许可证: MIT运行环境: Node.js 22.20.0–25.0.0核心概念前馈 反馈双信号Better Harness 的评估模型建立在一个框架上有效的 Agent 工作流需要两类信号共同工作。工作开始前 工作进行中/完成后 ───────────── ────────────────── 前馈引导Feedforward 反馈传感器Feedback AGENTS.md Linters 规范文档specs 测试套件 Skills可复用步骤 Hooks事件触发 验收标准 评估 Agent 诊断工具前馈引导在 Agent 动手之前就提供方向——AGENTS.md 告诉 Agent 规则和目标specs 定义任务范围Skills 提供经过验证的执行路径验收标准定义完成是什么样。反馈传感器在 Agent 行动后观察结果——linters 检查代码规范测试套件验证功能Hooks 在特定事件触发后捕获信号评估 Agent 对输出质量打分。一个工作流健康的核心指标这两侧都在工作而且工作结果有证据记录。五个维度详解维度一任务理解Task Understanding核心问题Agent 知道目标是什么知道完成是什么样子吗评估内容AGENTS.md 是否存在并包含有效的规则和目标定义是否有规范文档specs定义任务范围是否有明确的验收标准让 Agent 知道何时停止Agent 是否能识别项目起点和适合的变更粒度常见问题目标描述模糊“改进登录流程而不是给错误状态添加具体错误信息”Agent 不知道什么时候算完成反复过度修改或反复在错误方向上迭代。维度二受控执行Controlled Execution核心问题Agent 工作在有支撑的、可复用的路径上吗评估内容Skills 的配置情况是否有可复用的 SDLC 执行步骤MCP 工具的可用性和边界设置沙箱边界Agent 的权限范围是否合理受限Agent 是否在已知有效的路径上工作而不是每次从头摸索常见问题每次任务都重新发明执行流程Agent 有过多权限做了超出任务范围的修改没有可复用的步骤相似任务的质量差异很大。维度三变更验证Change Validation核心问题有证据证明改动实际生效了吗评估内容测试是否在变更后实际运行不只是存在测试lint 检查是否在变更后实际执行Hooks 是否捕获了验证信号验证失败后是否有重新验证的记录诊断工具是否实际被使用关键区别Better Harness 区分配置了测试和测试被执行了。一个项目可以有完整的测试套件但如果没有证据显示 Agent 在变更后运行了测试这个维度就不能得分。维度四可靠交付Reliable Delivery核心问题AI 的速度是否绕过了质量关卡评估内容是否有任务验收证据不只是代码改完了高风险操作是否有人工审批路径是否有回滚机制CI/CD 管道是否在 Agent 的工作流里人工 review 是否实际发生核心担忧Agent 可以在没有任何人察觉的情况下完成大量修改。可靠交付评估的是这些修改在交付前经过了哪些验证关卡。维度五经验沉淀Learning Capture核心问题这次任务的教训会影响到下次任务吗评估内容重复出现的问题是否沉淀为可复用的 Rules 或 SkillsLoop Discovery 是否在工作识别模式并生成建议Memory 系统是否在使用类似任务是否在复用已有经验还是每次从零开始一个信号Better Harness 会标记长时间会话超过 45 分钟供人工审查——这通常意味着 Agent 在做大量摸索而这些经验应该被沉淀下来以避免重复。分析架构三个独立证据 AgentBetter Harness 不用一个 Agent 做所有分析而是用三个独立的只读子 Agent 并行收集不同类型的证据最后由主 Agent 做统一分析。三个独立子 Agent并行 ├── Agent 1: 定制化资产分析 │ → Rules、Skills、Hooks、配置的完整性 │ ├── Agent 2: 真实任务会话分析 │ → Agent 实际做了什么如何执行 │ └── Agent 3: 项目工程基础分析 → 项目结构是否支撑 Agent 工作流 ↓独立收集完成后 主 Lead Agent统一分析 生成报告为什么要保持独立让三个子 Agent 独立工作防止一类证据的结论影响另一类的解读。如果 Agent 1 发现 Skills 配置完整这不应该影响 Agent 2 对实际会话记录的分析——后者只看执行证据不看配置。缺失证据的处理未观察到的行为不会被推断。如果没有测试执行记录变更验证这一维度就是未知状态不会因为项目里有测试文件而假设测试被运行了。报告结构运行分析后生成三个文件report.html自包含的可视化报告独立浏览器打开report.mdMarkdown 格式方便版本控制和团队分享findings.json结构化数据方便程序处理报告内容五维概览每个维度的评分条形图 相关发现数量范围快照当前配置的资产清点——Rules 数量、Skills 数量、自定义 Agents、MCP 工具、Memories、Hooks优先级发现每条发现包含优先级High / Medium / Low所属维度原因具体的配置缺口预期输出修复后达到的效果修复说明可编辑的预填充提示词以/harness开头会话观察从分析的会话中提取的典型模式超过 45 分钟的长会话单独标出历史趋势多次运行的结果对比显示各维度随时间的变化刻意保守的评分Better Harness 在评分上有一个明确限制“配置了某个资产只能证明机制存在只有与任务链接的证据才能证明它被实际使用了。”这意味着一个项目配置了完整的 Skills但如果没有实际使用记录受控执行这个维度不会因此得满分。通过当前检查只能证明干预被执行了只有比较后续结果才能证明工作流改善了。历史视图展示的是记录的趋势不是因果改善的证明。安装与使用在 Claude Code 里安装/plugin marketplaceaddQoderAI/better-harness其他平台平台安装方式Codex DesktopSettings Plugins Add from MarketplaceCodex CLIcodex plugin marketplace add [repo URL]GitHub Copilotcopilot plugin marketplace add QoderAI/better-harnessQwen Codeqwen extensions install QoderAI/better-harnessCursorclone 仓库到本地source-local 安装Qoder原生内置无需安装运行分析安装完成后在任意支持的 Agent 里/better-harness analyze this projects AI coding workflow and generate an evidence-backed report输出自包含的report.htmlreport.mdfindings.json。修复工作流Better Harness 不直接修改任何东西只识别问题并提供修复起点发现一个高优先级问题 → 点击 Plan a fix ↓ 打开修复详情 - 原因当前配置的具体缺口 - 预期输出修复后达到的效果 - 修复指令预填充的提示词可编辑 ↓ 点击 Start Fix → 启动 Quest 任务 ↓ Agent 在可检查、可回滚的 Quest 任务里执行修复 ↓ 重新运行 /better-harness → 确认工作流实际改善修复结果可以进一步沉淀为 Rules、Skills 和 Memories让后续任务直接受益。项目地址与资源GitHub: QoderAI/better-harness文档: docs.qoder.com/user-guide/knowledge-engine/better-harness总结Better Harness 解决的是一个元层面的问题AI 编程 Agent 的输出质量取决于围绕它的工作流而不只取决于模型能力。一个 Claude Sonnet 在有完整 AGENTS.md、明确验收标准、运行后自动测试、经验沉淀为 Skills 的工作流里比同一个 Claude Sonnet 在没有这些的随意工作流里输出质量差异很大。五维框架的价值在于把工作流健康度变成了可测量的东西不是感觉工作流不太好而是变更验证这个维度评分低因为没有找到测试执行的证据记录。优先级排序让你知道先修什么修复方案让你知道怎么修历史趋势让你确认修复实际有效。“刻意保守的评分策略是这个工具最值得信任的地方。它不从项目里有测试文件推断测试被运行了”也不从历史视图显示改善推断是这次修复导致的改善。这种诚实让工具的输出可以被信任而不是被质疑。探索 PrimeSkills —— 精选 AI Agent 与技能的市场每一个都经过真实企业工作流验证去掉浮夸留下真正有用的。欢迎访问我的个人主页发现更多有价值的见解和有趣的产品。