很多团队试用 AI 编程工具时，评价方式很随意：感觉它聪不聪明，代码写得快不快，某次 demo 是否惊艳。
这不够。Agent Harness 是工程工具，应该用工程指标评价。
一个 Harness 好不好，不只看模型回答质量，还要看它能否稳定完成真实任务，能否少走弯路，能否保护代码现场，能否让结果可验证。
评价维度一：任务完成率
最直接的指标是任务完成率。
选择一组真实任务，比如：
- 修一个已知 bug；
- 补一个接口字段；
- 写一组单元测试；
- 修复 CI 失败；
- 做一次小重构；
- 更新文档和示例。
然后记录 Agent 是否能在规定边界内完成。
不要只看成功案例。失败样本更重要，因为它能暴露 Harness 的短板：上下文找错、工具调用失败、测试不会跑、权限太紧或太松。
评价维度二：探索成本
编程 Agent 很多时间花在找上下文。
可以记录：
搜索次数
读取文件数量
工具调用次数
任务耗时
Token 消耗
无关文件读取比例
如果一个 Harness 每次都要读几十个文件才能找到入口，说明上下文组织有问题。CodeGraph、代码索引、项目规则、路径提示都可以降低探索成本。
评价维度三：验证能力
Agent 写完代码，如果不能验证，就只是生成器。
评价时要看：
- 是否主动运行测试；
- 是否能根据失败输出修正；
- 是否知道跑哪些测试；
- 是否能解释没跑测试的原因；
- 是否能处理 lint、typecheck、build；
- 前端任务是否能做截图或浏览器验证。
一个真实可用的 Harness，应该把验证放进循环，而不是最后一句“建议你运行测试”。
评价维度四：改动质量
改动质量不能只看能不能跑。
还要看：
- 是否遵守项目风格；
- 是否改动范围过大；
- 是否引入无关重构；
- 是否破坏兼容性；
- 是否补充必要测试；
- 是否处理错误路径；
- 是否有安全风险。
这里可以让人类 Review，也可以让另一个 Agent 做辅助 Review。但最终仍要有工程师把关。
评价维度五：可控性
可控性是 Harness 和普通聊天工具的重要区别。
要看：
- 是否支持计划模式；
- 是否能中断和改方向；
- 是否能限制文件范围；
- 是否能限制命令；
- 是否有权限提示；
- 是否能回滚改动；
- 是否记录会话和工具调用。
如果一个 Agent 很强，但用户不知道它下一步要做什么，也不敢让它自动执行，那它在团队里很难推广。
评价维度六：团队适配
单人好用，不等于团队好用。
团队落地还要看：
- 是否支持项目规则；
- 是否支持共享配置；
- 是否能接 CI；
- 是否能接内部文档；
- 是否支持审计；
- 是否能统一权限策略；
- 是否能和现有 Git 流程兼容。
真正进入团队流程后，Harness 的配置能力和治理能力会比 demo 更重要。
一个简单评测表
可以给每个任务记录：
任务名称
任务类型
是否成功
总耗时
工具调用次数
读取文件数量
修改文件数量
是否跑测试
测试是否通过
是否有无关改动
人工 Review 问题数
是否需要人工救场
跑 20-30 个真实任务后，你会比看宣传更清楚哪个工具适合团队。
常见误区
第一，只用 toy demo 评测。真实项目里的依赖、历史包袱、测试环境才是难点。
第二，只看速度。快但改错，比慢更危险。
第三，只看模型。Harness 的文件搜索、权限、上下文和验证能力同样重要。
第四，只看成功率。不看失败原因，就无法改进工作流。
第五，不区分任务类型。写测试、修 bug、重构、前端 UI、文档更新，对 Harness 的要求不同。
总结
评价 Agent Harness，要从“它聪不聪明”转向“它能不能稳定完成工程任务”。
一套实用指标包括：
任务完成率
探索成本
验证能力
改动质量
可控性
团队适配度
AI 编程工具最终不是拿来表演的，而是要进入日常研发。能被评估、能被复盘、能被改进，才有长期价值。
