Hacker News 上“九种 coding harnesses 对比你的笔记本”获得 106 points 和 29 条评论。标题有点夸张，问题却很实在。现在评价代码代理，很多人只盯着模型名称和单次回答质量，忽略了代理如何读仓库、调用工具、运行测试、保存状态和处理失败。决定代理能否长期工作的，往往是这一层编排。
Harness 是什么
可以把 coding harness 理解为包在模型外面的工作程序。模型负责提出下一步，harness 决定它能看到哪些文件，能否执行命令，怎样截取输出，何时要求确认，怎样把测试失败重新交回模型。它还负责上下文压缩、任务记录和停止条件。
同一个模型接入不同 harness，结果可能完全不同。一个只给模型当前文件的工具适合小修改。另一个能搜索全仓库、执行测试并持续修正的工具，适合较长任务，却也更容易扩大权限和费用。
评价代理时看四个指标
第一是观察能力。代理能否准确找到入口、调用者、配置和测试，而不是反复猜文件名。
第二是执行边界。命令是否默认只读，危险操作是否需要确认，工作目录和网络权限是否明确。
第三是验证能力。代理有没有运行与改动相关的测试，能否区分编译通过、页面可见和真实服务生效。
第四是状态管理。长任务中，模型是否知道已经做过什么、哪些失败可重试、哪些结论仍未验证。
给团队的落地方法
- 选三类真实任务，分别是小修复、跨文件功能和故障排查。
- 固定模型版本、仓库快照、权限和测试命令，避免比较结果混入环境差异。
- 记录首次定位时间、无效工具调用、测试通过率、人工返工和总 token 消耗。
- 给每个 harness 写清默认权限、停止条件、日志位置和人工接管点。
为什么“更自主”不总是更好
代码代理拥有的动作越多，错误的代价越高。它可能把测试生成的文件误提交，把过期接口当成当前接口，也可能为了修一个用例改动公共配置。自主性应该和回滚、审查、沙箱、最小权限一起增加。
对个人开发者，最有价值的配置往往是让代理先搜索和解释，再请求执行；对团队，重点是让每次改动都留下可复现的命令、差异和测试结果。
还有一个常被忽略的成本是上下文重放。代理每次重新发送仓库片段、测试输出和历史指令，长任务的 token 消耗会逐步上升，模型也可能被旧错误带偏。工程团队可以给任务设置上下文预算，定期把已确认事实压缩成短记录，把失败命令和未解决假设分开保存。
如果要比较九种工具，最好把它们放进同一个小型基准集。测试用例要包含需要搜索的缺陷、会失败一次的构建、需要人工确认的写操作。只看一条漂亮的演示，很难判断工具是否适合日常仓库。
FAQ
模型能力和 harness 哪个更重要？任务短且边界清楚时模型差异明显，任务长且需要工具时 harness 对结果的影响会迅速放大。
本地笔记本够用吗？取决于任务。编排、测试和权限控制可以本地完成，模型推理是否本地运行是另一项选择。
如何避免代理乱改？限制目录和命令权限，让它先给计划，所有写入都通过可审查的差异完成。