Better Harness
用可核验证据诊断并改进编码智能体的工作闭环。
证据显示了较强的最小权限和外部影响控制：CI 默认仅有 contents:read，Pages 权限按任务分离；Inspector 被描述为只读；预览服务默认绑定 127.0.0.1；跨来源读取被拒绝；制品编译会拒绝包导入和目录逃逸；插件生命周期命令只生成计划而不执行。安装、会话证据来源、报告落盘位置及覆盖缺口也有明确说明。扣分主要在于未见完整的敏感信息识别、脱敏、保留和删除政策；用户确认虽然体现在修复计划待审和生命周期计划化，但没有覆盖所有报告写入或读取本机会话的统一确认协议；回滚仅有移除计划和 recovery paths 的概念性提及，缺少具体、经文件证明的恢复流程。来源归属由 MIT 文件、包作者、仓库和问题入口充分支持，未验证的发布者身份仅按未知处理。
README、package 元数据、CI 配置和测试在支持的平台、Node 版本、输出形态、错误状态与安全边界上相互一致。测试覆盖流式事件重组、部分结果保留、中断和失败状态、并发编译缓存、来源限制及明确诊断，因此失败消息处理充分。依赖可用性扣分：Node 和 npm 范围较窄，多个宿主能力依赖外部产品及其当前命令契约，Cursor、Pi、WorkBuddy 等还存在 unavailable、manual 或部分覆盖状态；静态材料也不能证明所有依赖在目标环境实际可取。
材料针对团队、贡献者和多种编码代理宿主提供了清晰场景，并通过宿主矩阵、不同输出类型、无会话模式以及平台专属安装路径体现较强适配性。能力边界明确区分已配置机制、实际使用证据和结果改善，并公开缺失或部分证据。环境覆盖包括 Windows、macOS、Linux、多个 Node 版本和众多宿主。触发精度扣分是因为虽然每个宿主都有精确调用示例，但核心自然语言分析指令的任务选择、歧义处理和拒绝条件未在给定材料中完整展示。
README 将快速开始、架构、安装、开发、贡献和许可组织得较完整，并指向模型、适配器矩阵、参考资料和贡献指南。安装说明包含宿主差异、验证命令、输出位置和已知不可用路径；公开名称、包名、命令和版本化事件名称整体稳定。限制披露尤其充分，包括因果性边界、会话覆盖、Cursor 契约、Copilot 数据缺失及本地预览边界。MIT 许可文本和包元数据一致。扣分在于示例丰富但未提供明确 FAQ；CHANGELOG 被打包清单和生成脚本引用，却未给出其内容，无法确认发布记录质量；维护入口有作者、邮箱、问题和贡献路径，但未展示具体维护者、支持承诺或更新责任分工，且发布者身份未获企业注册表验证。
自包含 HTML、配套 Markdown、findings.json、证据摘要、优先级发现、影响、修复边界和验收检查构成可直接使用的输出，且不同宿主的输出差异被说明。相较只看最终 diff，项目提出了检查任务理解、执行、验证、交付和学习闭环的额外价值。扣分在于边际价值主要由项目自身阐述，未提供独立对照或量化成效；成本收益也没有给出运行时长、模型消耗、误报率或维护成本数据，严格 Node 要求和多宿主安装还会增加采用成本。
主要主张可追溯到具体模型、工作流、报告结构、宿主矩阵、脚本和测试；README 的关键运行与安全描述得到 package、CI 和测试材料的交叉支持。材料反复区分机制存在、任务证据、观察缺失和实际改善，并明确历史趋势不是因果证明，因此事实与推断分离处理充分。满分仅表示给定静态文件对这些文档性标准处理充分，不代表已执行或独立验证。
- 这是低置信度的静态审查；未执行代码、测试、安装流程或宿主集成。
- 工具可能读取本地、与工作区匹配的代理会话并默认写入报告；使用前应确认这些记录是否含密钥、客户数据、个人信息或受保密约束的提示内容。
- Studio 的来源限制和目录约束有测试证据，但给定材料未展示端到端的敏感数据脱敏、保留期限或安全删除政策。
- Cursor、Pi、WorkBuddy 及部分会话来源存在不可用、手工或部分覆盖边界，不应把宿主清单理解为完全等价的支持。
- 依赖和 GitHub Actions 使用了明确版本或标签，但未见锁定到提交摘要、漏洞扫描、SBOM 或依赖更新政策的证据。
- 改进趋势和项目自身的价值主张不构成因果证明；应在真实仓库中单独验证发现质量、误报率、成本和恢复流程。
这个 Agent 能做什么，适合哪些场景？
Better Harness 是面向编码智能体工作流的开源 Harness Engineering 平台，可将项目与受支持的会话证据整理成有优先级的改进建议。它围绕任务理解、受控执行、变更验证、可靠交付和学习沉淀五个维度评估 Agent Work Loop。仓库包含 `/better-harness` 工作流、证据采集器、分析器、报告渲染器、Harness Inspector，以及面向不同宿主的轻量适配器。根据宿主不同，它会生成原生 Canvas 报告，或自包含的 `report.html`、配套 `report.md` 和 `findings.json`。分析边界限定在相关任务片段及项目机制内；缺失或不完整的证据会明确标出，而不会被推测成评分或改进结论。它适合希望系统化审视编码智能体交付过程，而不只检查最终代码差异的团队。
运行 /better-harness 后，系统收集项目中的 AGENTS.md、规格、Skills、验收标准、测试、lint、Hooks、交付控制等证据，并在宿主支持时读取与当前工作区匹配的会话记录。三个证据域保持独立，随后由 lead agent 统一分析。分析按 Agent Work Loop 的五个维度建立任务范围内的基线，识别已配置的智能体资产，并生成带证据来源、影响、预期输出、修复边界和验收检查的优先级 findings。Claude Code、Codex、Qwen Code、GitHub Copilot 和 Kimi Code 输出自包含 HTML 与配套 Markdown；Qoder 和 Cursor 使用宿主原生 Canvas。Harness Inspector 以只读方式追踪产品意图与智能体活动、会话、文件及提交之间的联系；历史视图展示五个维度随报告变化的趋势，但不把趋势当作因果证明。独立 CLI 还提供 better-harness plugin status、doctor、plugin plan 和 plugin verify，用于检查或规划宿主插件生命周期，不会代替用户执行原生安装命令。
- 采用 Claude Code 或 Codex 的开发团队，在多个任务反复出现目标理解偏差时，用报告检查规格、
AGENTS.md和验收标准是否为智能体提供了足够的前置指导。 - 工程负责人准备扩大编码智能体使用范围时，评估测试、lint、Hooks、人工审核、审批和 CI/CD 是否构成可核验的交付保护链。
- 维护多个智能体宿主的团队，需要比较不同任务报告并观察 Agent Work Loop 五个维度的历史变化，同时保留证据强度与缺口。
- 开发者怀疑智能体声称“已经可用”但缺少验证时，用 Change Validation findings 定位缺失的测试、诊断或验收检查。
- 交付调查人员需要追踪需求、提示词、工具调用、文件和提交之间的关系时，在只读工作区中使用 Harness Inspector 检查证据链。
- 插件维护者需要在不直接修改宿主配置的情况下，检查各宿主安装状态并生成安装、升级或移除计划。
这个 Agent 有哪些优点和局限？
- 不只审查最终 diff，而是同时检查前置指导、执行路径、验证传感器、交付控制和经验沉淀。
- 每项 finding 都保留证据、影响、预期结果、修复范围和验收路线，便于逐项评审和验证。
- 对缺失、部分或未观察到的证据保持显式，不把配置存在误写成机制已被使用，也不把一次通过误写成长期改善。
- 覆盖 Claude Code、Codex、Qoder、Cursor、GitHub Copilot CLI，以及文档列出的 Qwen Code、Pi、Kimi Code、WorkBuddy 和 Grok 等多种宿主。
- 提供自包含 HTML、Markdown、JSON、原生 Canvas 和只读 Harness Inspector 等多种检查界面。
- 安装方式、调用入口、报告格式和会话证据覆盖因宿主而异，没有统一的跨宿主入口。
- Cursor 插件未发布到 marketplace，当前安装计划会报告为不可用；只有通过另行验证的原生加载路径才能执行验证。
- 部分宿主存在明确证据边界，例如 GitHub Copilot CLI 不记录逐响应 token 用量，VS Code Copilot Chat 没有受支持的持久会话记录。
- 历史视图只能展示已记录趋势，不能单独证明工作闭环改善与某项干预之间的因果关系。
- 从源码开发对运行时版本要求较窄，需要 Node.js 22.20 至 24.x 与 npm 10.9.3 至 11.x。
如何安装或部署这个 Agent？
无需凭据。Codex Desktop：打开 Settings > Plugins，选择 + Add > From Marketplace，填入 https://github.com/QoderAI/better-harness.git，Git ref 设为 main，Sparse paths 留空，然后从新 marketplace 安装 Better Harness 并开始新任务。Codex CLI：运行 codex plugin marketplace add 'https://github.com/QoderAI/better-harness.git' --ref main，再运行 codex plugin list --marketplace better-harness 和 codex plugin add better-harness@better-harness。Claude Code：运行 /plugin marketplace add QoderAI/better-harness，随后运行 /plugin install better-harness@better-harness，并以 claude plugin details better-harness@better-harness 验证出现 Skills (1) better-harness。Qoder Desktop 已内置，无需安装；安装或更新插件后应启动新的会话或任务。若从源码开发，需要 Node.js >=22.20.0 <25.0.0、npm >=10.9.3 <12.0.0，然后运行 npm ci、npm test 和 npm run pack:verify。
如何使用这个 Agent？
在要分析的仓库中新建宿主会话。Codex Desktop 使用：@better-harness analyze this project's AI coding workflow and generate an evidence-backed report。Codex CLI 使用：$better-harness:better-harness analyze this project's AI coding workflow and generate an evidence-backed report。Claude Code、Qoder Desktop 或 Qoder CLI 使用：/better-harness analyze this project's AI coding workflow and generate an evidence-backed report。Claude Code 默认将 report.html、report.md 和 findings.json 写入仓库的 .claude/better-harness 报告目录；也可以要求 inline 或 no-files 输出。仅从源码检查仓库证据且不读取本地会话时，可运行 node scripts/better-harness.mjs report --no-sessions。检查插件状态可运行 better-harness plugin status --host all 和 better-harness doctor --platform all。
常见问题
使用 Better Harness 需要付费或配置 API 密钥吗？
它会自动修改项目或执行插件安装计划吗？
没有会话记录还能生成报告吗？
node scripts/better-harness.mjs report --no-sessions 仅检查仓库证据。一次检查通过是否证明工作流已经改善？
所有宿主都会生成同一种报告吗？
findings.json。