看到一篇写Harness Engineering非常透彻的文章，我大概知道了cc、codex、dsh为啥会火成这样。

看到一篇写Harness Engineering非常透彻的文章，我大概知道了cc、codex、dsh为啥会火成这样。很多人有个误区，agent跑出的结果很拉垮时，首先想到去优化提示词，或者去换更nb的模型，再不济去补充上下文，瞎灌大量知识库。


可哪怕你这样做了，agent依旧不行，根源在于环境定义不足，而不是智力不够。模型只负责去推理给出建议，但具体用什么工具、执行什么操作、哪里该保存、到哪里该结束，都需要你定义好agent的执行环境，也就是Harness。

比如你要做个编程agent，那就把模型放在能随时调用终端、测试、浏览器、项目记忆和审查循环的环境里，并且给出各种规则和限制，让ai会用、善用、不瞎用。

打个不恰当的比方，聪明人到处都有，可是如果遇不到好的教育和工作环境，也就没有用武之处。harness就好像规则制度完善、软硬件条件拉满的大学和公司，能让人才的产出质量更好。

我看了文章给的建议，一个好用的生产级harness得有8个能力。

1、对用户的请求限制好边界，让任务有约束不跑偏。比如codex用用清晰的任务描述 + 验收标准，而不是模糊指令。

2、做好查询手册，让agent知道去哪找工具和文档，codex的AGENTS.md 就是查询手册。

3、工具接口必须有说明书，用途、输入、输出写清楚

4、把对话后的决策、产出、错误，风险等保存为会话记忆，而不是只记得对话本身，比如说重要结论这一定一定要写进文件里，方便随时读取使用。

5、做好监测，用截图、日志、检验器等去观察和记录，备着证据给agent判断，让它知道自己做的对不对。

6、给模型设置权限，要对模型的动作加以判断，如果有风险就阻止和优化，比如沙箱加上人工审批。

7、agent重要的规则要当成基础设施，有的人只是把规则写到系统提示词，但有时候模型会忽略，所以要把规则写两遍，第一遍强调遵守该规则，第二遍要检查是否遵守了规则。

8、要把把反复出现的问题固化成规则、检查和工具，而不是出现一次就修改一次。

我感觉harness就像是一套ai世界的物理法则，好的harness能指挥ai把石头雕刻成精美的玉器，差劲的harness只能把一块石头变成另一块石头。
#