![[智能体设计 #1] 什么是 Harness Engineering？Prompt 之后的下一步 封面图](/assets/images/posts/e5b7d384-3107-41fb-a62e-34369bc15f27/harness-engineering-1.jpg)
使用同一个模型，团队之间的产出质量却不同。一边能让 AI 完成整个重构，另一边连简单修改都要由人全部重写。
差异不在 Prompt 的措辞，而在包裹模型的执行环境，也就是 Harness。
用一句话概括，Harness Engineering 就是设计整个循环，让模型使用工具、验证结果并持续工作。如果 Prompt Engineering 是“如何把话说好”，Harness Engineering 就是“如何搭建一个能把工作做好的工作场所”。
本文将整理 Harness 的确切定义、组成部分，以及判断优秀 Harness 的标准。
先从核心摘要开始。
- Harness 是包裹模型的执行循环。组成部分包括工具、权限、上下文管理和反馈。
- 智能体的性能由模型智能 × Harness 质量决定。
- 优秀 Harness 的核心，是让模型能够自行检查结果的反馈循环。
- Claude Code、Cursor 等编程智能体的本质，就是 Harness。
Harness 究竟是什么
Harness 原本指马匹使用的马具。它不会增强马本身的力量，而是把这种力量转化为拉车等有用的工作。
测试 Harness 这一术语也源自同一脉络。
LLM Harness 也是如此。它不改变模型（智能）本身，而是指包裹模型、让这种智能转化为实际工作的全部软件。
具体来说，包括以下内容。
- 工具层：模型可以调用的函数，例如读写文件、执行 Shell、搜索。
- 权限层：关于询问并执行什么、自动批准什么的策略。
- 上下文层：向模型展示什么、隐藏什么，以及何时进行摘要。
- 循环层：接收工具结果并连接到下一步行动的重复结构，以及终止条件。
我们称 Claude Code 或 Cursor 为“AI 编程工具”，但模型本身就是 API 背后的同一个模型。产品的本质是 Harness。
性能 = 模型 × Harness
即使使用同一个模型，基准测试分数出现明显差异的案例也很常见。在智能体基准测试排行榜中，即使模型相同，成功率也会因 Harness 不同而相差几十个百分点。
原因很简单。智能体任务是由数十次工具调用串成的链条，而 Harness 会介入每一个步骤。
| Harness 不佳时 | Harness 良好时 |
|---|---|
| 把完整的工具结果全部倒入上下文 | 只总结并传递必要部分 |
| 即使失败也重复相同的尝试 | 将错误消息作为下一次尝试的输入 |
| 根据模型的声明判断任务完成 | 通过测试和构建进行验证，成功后才结束 |
模型会以概率方式犯错。Harness 的作用不是消除错误，而是让错误在验证阶段被拦截，并由模型自行修正。
优秀 Harness 的三个条件
从实际工作角度看，区分 Harness 质量的条件可以归纳为三项。
第一，可验证的反馈循环。模型修改代码后，必须运行测试并向它展示结果。
就像人不会相信未经编译的代码一样，没有反馈的智能体只会不断积累自信。这也是测试完善的代码库最能发挥智能体引入效果的原因。
第二，上下文预算管理。上下文窗口是有限的，但工具结果会无限涌入。
截断长输出、总结旧内容，以及将探索工作隔离到子智能体中，都是 Harness 的职责。
第三，安全的失败路径。必须通过权限策略和沙箱定义“即使出错也能恢复的范围”。
例如，自动批准可撤销的操作，只向人询问具有破坏性的操作。
与 Prompt Engineering 的关系
这并不是说 Prompt Engineering 已经没用了，只是所处的层次不同。
Prompt 优化一次请求。Harness 优化由数十个连续请求组成的循环。编写系统 Prompt 会成为 Harness 设计的子集。
关注重点已经从“该说什么”转向“该提供什么环境”。模型越好，这种趋势越明显。因为指令可以变短，但工具和验证循环的价值反而会提高。
总结
如果智能体的产出不尽如人意，请先检查 Harness，再调整 Prompt。模型是否有办法检查结果？上下文是否塞满了杂物？失败是否会进入下一次尝试？
下一篇文章将深入探讨上下文工程，也就是对上下文层进行深挖。