Qoder开源Agent评估工具

阿里云开始给 Coding Agent 做“工程体检”

阿里云旗下智能体编程平台 Qoder 于 7 月 28 日宣布开源 Better Harness，一套面向 Coding Agent 工作流的分析与持续改进工具。截至 2026 年 7 月 29 日，该项目已适配 Claude Code、Codex、Qoder 和 Cursor，首轮内部评测覆盖 30 个真实 GitHub 项目。

Better Harness 是一套检查编程智能体工程能力是否真正生效，并基于运行证据给出改进建议的开源工具。它关心的不是项目目录里有没有规则、技能或 MCP 配置，而是 Agent 在实际任务中有没有调用这些能力、调用后是否帮助任务完成。

这一区别看起来细微，实际上击中了当前 Coding Agent 落地中最容易被忽视的问题：配置存在，不等于能力生效。

一个项目可以写满规则文件，接入多个工具，配置测试命令和代码规范，但 Agent 仍可能没有读取规则、没有调用测试、没有利用持久化记忆，甚至在遇到失败后直接向用户宣称任务已经完成。传统静态检查通常只能证明“消防栓装上了”，Better Harness 想检查的则是“发生火灾时，消防栓有没有被使用，而且是否真的把火扑灭”。

Better Harness 不评模型，而是评模型外面的系统

Harness Engineering 是围绕 Agent 搭建工具、上下文、规则、沙箱、观测和安全护栏的工程方法。大模型提供推理能力，Harness 则决定模型能看到什么、能调用什么、如何执行、怎样验证以及何时停止。

Loop Engineering 是对 Agent 规划、执行、验证、纠错和终止循环进行设计与优化的工程方法。它解决的不是一次回答写得好不好，而是一个持续数分钟乃至数小时的任务能否稳定收敛。

Better Harness 把这两套方法连接了起来：前者描述一个成熟 Coding Agent 项目应该具备哪些工程设施，后者检查这些设施是否进入了真实工作循环。项目因此没有停留在“最佳实践清单”层面，而是进一步提供评估模型和可重复运行的工程实现。

这也是 Better Harness 与代码生成 Benchmark 的根本区别。Benchmark 往往给模型一批固定题目，再统计通过率；Better Harness 更接近一套针对 Agent 工作流的持续审计机制，检查能力声明、实际行为、任务结果和证据之间是否一致。

| 对比维度 | Better Harness | 代码生成 Benchmark | Agent 可观测平台 | 配置静态检查 | |---|---|---|---|---| | 主要对象 | Coding Agent 工作流 | 模型或 Agent 的任务结果 | 调用轨迹、耗时与成本 | 配置文件与项目结构 | | 核心问题 | 能力是否被使用并支持任务完成 | 题目是否通过 | 运行过程中发生了什么 | 配置是否存在、格式是否正确 | | 证据来源 | 会话、项目 Harness、Agent 定制配置 | 测试用例与最终输出 | Trace、日志、工具调用 | 文件和规则扫描 | | 输出形式 | Finding、影响、修复范围、验证方式 | 分数或通过率 | 轨迹与统计指标 | 警告或错误 | | 是否面向持续改进 | 是 | 通常不是 | 需要团队自行建立闭环 | 通常只覆盖配置修正 |

Better Harness 最有价值的地方不是再做一个排行榜，而是把“怎样证明 Agent 工作流有效”变成可执行的工程问题。对于已经在团队中部署 Claude Code、Codex、Cursor 或 Qoder 的开发者，这比单纯比较模型跑分更贴近生产环境。

三层开源体系，把方法论压进可运行工具

Better Harness 采用三层开源体系，分别覆盖工程实践、评估模型和运行实现。三层设计的意义在于让评估规则既可讨论、可扩展，也能在真实项目中反复执行。

第一层：Harness Engineering 实践

Harness Engineering 实践层定义了 Coding Agent 周围需要检查的工程组件。目前公布的范围包括 Session、CLI、可观测性、Rules、Skills、MCP、Memory、Hooks 和自动化。

这些组件共同决定 Agent 是否具备稳定工作的外部条件：

• Session 负责承载任务过程与上下文，决定长任务是否能够被回看和诊断；
• CLI 代表 Agent 操作项目、执行命令和接入研发流程的入口；
• 可观测性 用于记录模型决策、工具调用、错误和验证结果；
• Rules 为 Agent 提供项目约束、代码规范与操作边界；
• Skills 封装可复用的任务能力和领域流程；
• MCP 是模型上下文协议，用于以标准化方式向 Agent 暴露外部工具和数据；
• Memory 保存跨步骤或跨会话仍然有价值的信息；
• Hooks 在特定事件发生前后触发检查、审批或自动操作；
• 自动化 则把测试、检查、构建和交付动作接入 Agent 工作流。

完整列出这些组件并不意味着项目一定成熟。Better Harness 的判断逻辑是：项目中存在一份规则文件，只能证明规则被声明；会话证据显示 Agent 读取规则、按规则修改代码并通过验证，才能证明规则真正参与了任务。

第二层：Agent Work Loop 评估模型

Agent Work Loop 评估模型是把工程实践转化为可逐项检查问题的规则体系。它约束证据、评分与结论之间的关系，避免评估者仅凭印象给出“好用”或“不好用”的主观判断。

每一条 Finding 都需要附带四类关键信息：可追溯证据、用户影响、修复范围和验证方式。Finding 是 Better Harness 对具体工作流问题形成的结构化发现，不只是日志里的一条报错。

例如，Agent 在会话中修改了核心模块，却没有运行项目已有的测试命令。一个合格的 Finding 不应只写“缺少测试”，而应指出相关会话步骤和项目测试入口，解释这会增加回归风险，明确需要修改 Agent 规则还是 Hook，最后给出重新执行任务并检查测试记录的验证方法。

结构化 Finding 的价值在于把问题从“Agent 偶尔不靠谱”压缩成可分派、可修复、可复测的工程任务。团队不必重新阅读完整会话，也能判断问题影响了谁、应该改哪一层以及怎样确认修复有效。

第三层：可运行的工程实现

可运行的工程实现负责让实践和评估模型进入真实项目，而不是停留在文档中。Better Harness 因而可以被重复执行，用同一套检查方式观察项目改造前后的变化。

持续运行能力比单次诊断更重要。Coding Agent 的模型版本、项目规则、工具权限和代码仓库都在变化，一次检查通过无法保证几周后仍然有效；只有周期性采集证据、输出 Finding、修复并复测，才能形成真正的改进闭环。

三类证据，避免 Agent 自己给自己判卷

Better Harness 会独立采集 Session Evidence、Project Harness 和 Agent Customize 三类证据。独立采集意味着评估不只依赖 Agent 在最终回复里对自身工作的描述，而是交叉检查真实会话、项目设施和定制配置。

| 证据类别 | 定义 | 主要回答的问题 | 典型风险 | |---|---|---|---| | Session Evidence | Agent 实际运行过程留下的会话证据 | Agent 做了什么、调用了什么、是否验证 | Agent 声称完成，但会话中没有验证动作 | | Project Harness | 项目为 Agent 准备的规则、工具和自动化设施 | 项目提供了哪些可用能力 | 设施存在，但入口失效或未被 Agent 使用 | | Agent Customize | 针对具体 Agent 设置的规则、技能和扩展 | Agent 被要求如何工作 | 配置被覆盖、忽略或与项目规则冲突 |

三类证据交叉后，Better Harness 能区分至少三种过去容易混在一起的问题：项目根本没有提供能力、项目提供了能力但 Agent 没有使用、Agent 使用了能力但仍未支持任务完成。

这种区分对修复成本有直接影响。如果测试入口不存在，团队需要改 Project Harness；如果测试入口存在但 Agent 从不调用，问题可能落在 Rules、Skills 或 Hooks；如果 Agent 已经调用测试但错误地忽略失败结果，则应检查工作循环和完成条件。没有证据分层时，团队往往只能不断改提示词碰运气。

首轮覆盖 30 个项目，但离行业标准还有距离

Better Harness 首轮内部评测覆盖了 30 个真实 GitHub 项目，这一数字证明工具至少已经离开概念验证阶段，开始面对不同仓库结构和 Agent 配置。真实项目也比人工构造的演示仓库更容易暴露规则缺失、入口不一致和自动化失效等问题。

30 个项目仍不足以证明评估模型具有广泛代表性。官方目前披露的信息没有给出项目语言分布、规模区间、任务类型、Finding 命中率、误报率以及修复前后的量化变化，外部开发者因此暂时无法判断评估结果在 Java、Python、TypeScript 或大型单体仓库中的稳定性。

公开基线将决定 Better Harness 能否从 Qoder 的工程方法论变成社区标准。后续值得关注的数据至少包括：同一项目跨 Agent 的一致性、同一 Finding 多次运行的复现率、人工复核后的准确率、每次评估耗时，以及修复建议对任务成功率和 Token 消耗的实际影响。

项目对 Claude Code、Codex、Qoder 和 Cursor 的适配也需要区分“能够读取基本会话”与“完整理解各平台特性”。四类产品在规则文件、技能系统、工具调用、会话存储和权限机制上并不相同，统一评估层如果只抽取最小公约数，可能会遗漏平台特有能力；如果为每个平台维护深度适配器，长期维护成本又会迅速上升。

Better Harness 的真正对手是团队里的 Excel 和经验主义

Better Harness 当前最直接的竞争对象不是某个单一商业产品，而是研发团队依赖人工抽查、故障复盘和经验判断的旧流程。许多团队已经能查看 Agent 日志，却没有统一规则判断哪些行为构成问题，更没有把问题自动关联到修复范围和复测方式。

可观测性只能告诉团队发生了什么，评估模型才负责判断发生得对不对。Better Harness 把二者向前推进了一步：它既读取运行证据，也试图给出带约束的结论，因此更像 Coding Agent 的工程审计层。

这一方向比继续堆叠 Prompt 模板更有长期价值。模型能力提升可以减少部分低级错误，却不会自动解决权限失控、验证缺失、规则冲突、长循环不终止和上下文污染等系统问题；模型越能自主执行，外围 Harness 的责任反而越重。

Better Harness 也不能取代软件测试和安全审计。它检查的是 Agent 工作流是否按照预期使用能力，而不是证明代码没有漏洞、业务逻辑绝对正确或依赖链完全安全。团队仍然需要单元测试、集成测试、静态分析、依赖扫描和人工评审，只是可以进一步检查 Agent 有没有正确触发并处理这些机制。

对开发团队有什么实际用处

Better Harness 最适合已经让 Coding Agent 进入真实仓库、但难以解释质量波动的团队。个人开发者只有少量短会话时，手工查看过程仍然可行；当团队同时运行多个 Agent、多个仓库和大量长任务后，统一证据模型才会体现价值。

开发团队可以把 Better Harness 用在以下场景：

1. 上线前审查 Agent 配置。 团队可以检查 Rules、Skills、MCP、Memory 和 Hooks 是否不仅存在，而且在代表性任务中确实被调用。
2. 比较不同 Coding Agent。 团队不只比较最终代码，还可以观察不同 Agent 对同一项目 Harness 的利用程度。
3. 复盘失败任务。 团队可以根据会话证据定位失败来自模型决策、工具缺失、规则冲突还是验证环节。
4. 验证工程改造。 团队加入测试 Hook 或新的 Skill 后，可以重新运行评估，确认改变是否进入工作循环。
5. 建立组织级标准。 平台团队可以把高频 Finding 沉淀成项目模板和统一规范，而不是在各仓库重复踩坑。

团队采用这类工具时应先选取少量高价值任务建立基线，而不是一开始追求覆盖所有仓库。一个更现实的过程是先挑选代码修改、缺陷修复和测试补全等典型任务，记录当前 Finding，再逐项修复 Project Harness 和 Agent Customize，最后用相同任务验证变化。

OpenAI Hub 观点：Agent 工程进入“先证明，再交付”阶段

Better Harness 代表了 Coding Agent 竞争从模型能力转向系统可靠性的趋势。过去开发者关注模型能不能写代码，现在更关键的问题是它能否理解仓库约束、调用正确工具、验证结果，并在失败时留下足够证据。

Qoder 这次开源最值得肯定的不是又增加了一组检查规则，而是提出了一条明确原则：能力是否生效，必须由行为和结果证明。这个原则足够简单，却比“项目已经配置某某功能”的功能清单更接近生产现实。

Better Harness 的短板同样明确。30 个项目的内部评测规模有限，公开材料中的量化指标也不够完整，跨平台适配深度仍需社区验证；如果后续不能持续公开评估集、误报率和修复收益，项目容易退化成一套包装完整但难以校准的最佳实践清单。

Better Harness 是否能成为通用基础设施，最终取决于评估模型能否被不同团队复用。规则应该允许社区扩展，证据应该能够复现，结论应该经得住人工复核，版本升级还要避免同一项目的评分无故漂移。

Coding Agent 的下一阶段不会只靠更大的模型推动。模型负责提供智力，Harness 负责把智力约束在可观察、可验证、可回滚的生产流程里，而 Better Harness 试图补上的，正是这套流程长期缺失的“体检与复查”环节。

参考来源

• IT之家：阿里云 Qoder 开源 Better Harness：报道项目发布时间、三层开源体系、三类证据、适配产品及首轮 30 个 GitHub 项目的内部评测信息。
• GitHub：Better Harness 相关仓库检索：用于查找项目代码、版本更新、Issue 与社区贡献情况。