阿里云 Qoder 开源 Better Harness：以任务级证据评估编程智能体工作质量
阿里云将 Qoder Desktop 内置的 Better Harness 开源，可接入 Claude Code、Codex、Qoder 与 Cursor，用来检查编程智能体在一次任务中是否真正完成理解、执行、验证与交付。
该工具不以配置文件或测试是否存在作为能力证明，而是要求每条改进建议附带可追溯证据、用户影响、最小修复范围和验证方式； 阿里云同时说明，评估模型仍主要基于其最熟悉的项目类型，跨技术栈可能存在盲区。
阿里云在博客中宣布开源 Better Harness，代码托管于 GitHub 的 QoderAI/better-harness。 该工具接入 Claude Code、Codex、Qoder Desktop 和 Cursor；
Qoder 为内置支持、无需安装，Claude Code 通过插件市场安装，Codex 通过 Git 市场安装，Cursor Agent 从源码加载，安装后在项目中运行 /better-harness 生成报告。 四个平台共用同一评估模型，但在会话分析、证据覆盖和输出能力上尚未完全对齐，Qoder 集成为当前最完整的参考实现。
工具分三层：Harness Engineering 最佳实践知识库、Agent Work Loop 评估模型、可运行的工程实现。 证据分为会话证据、项目工程证据和智能体定制证据三类，独立采集后由 Lead 汇总判断。 内部首轮评估选取 30 个真实 GitHub 项目，由四类模型独立评估产生 120 份标准化报告，再经跨模型比较与人工校准后按更新标准重评；
模型逐步收敛为任务理解、受控执行、变更验证、可靠交付和留存学习五个维度（阿里云称累计撰写 200 余份 spec）。 每条 Finding 需包含可追溯证据、对用户的具体影响、最小修复范围和验证方式。 若某类证据不可获得，报告会明确保留该限制，不以配置计数或其他平台数据替代。
这项工作的看点在于把编程智能体评估的单位从“仓库里有什么”收窄到“一次任务里实际发生了什么”。 传统成熟度清单会奖励文档、测试和持续集成（CI，持续集成）的存在，但无法证明智能体调用了相关测试、看懂失败日志或完成可交付变更。 Better Harness 把每条改进建议绑定证据、影响、修复范围与验证方法，等于把评估结果变成可复核的工程产物，而非单一分数。
对使用多平台编程智能体的团队，这提供了一种可迁移的审查思路； 但其评估标准仍由单一厂商主导，跨栈适用性需要外部反例检验。
后续观察信号
- Better Harness 的 Agent Work Loop 五维模型具体如何定义证据充分性
- Claude Code、Codex 与 Cursor 的证据采集差异会导致哪些结论不可比
- 开源后是否出现独立的人工校准流程与公开基准