Appearance
有时候，语言模型不是不够聪明，它只是缺少人类为它设计好的行动环境。
Harness Engineering最近被越来越频繁地提起。有人说它是Prompt Engineering的新说法，有人说它是Context Engineering的升级版。
但从李宏毅老师的课程出发，最值得抓住的不是术语本身，而是那条更朴素的主线：
当一个概率模型不再只是聊天，而是要读文件、调用工具、修改代码、运行测试、观察日志、操作浏览器、跨会话推进任务时，我们怎样让它持续看见事实、执行动作、接收反馈、保存进度，并在失败后修正下一轮行动？
问题从来不是"模型不够聪明"
李宏毅老师讲了一个很关键的例子：让一个小模型修复email parser的bug。
任务本身并不复杂：目录里已经有parser.py和verify.py，模型要修改parser，然后让验证脚本通过。
但模型一开始失败了。它没有先看目录，也没有读真实文件，而是根据题目描述幻想了一个parser.py，又幻想自己已经验证成功。
可是，当人类只补上几条工作原则：
- 先
ls看目录里有什么 - 再
cat读取真实文件 - 修改后运行
verify.py - 用验证结果判断任务是否完成
同一个模型就能把任务做出来。
这件事重要的地方在于：模型并不是完全不会写代码，它缺的是一条可执行、可观察、可验证的行动链路。
Agent失败的真正原因
很多Agent失败，问题不一定出在某一个瞬间，而是出在链路断了：
| 常见问题 | 根因 |
|---|---|
| 文件在磁盘里 | ≠ 模型已经看见 |
| 规则在团队脑子里 | ≠ 模型已经知道 |
| 测试脚本存在 | ≠ 模型会主动运行 |
| 输出看起来合理 | ≠ 任务真的完成 |
| 上一轮成功了 | ≠ 下一轮不会在同一地方跌倒 |
Harness是什么
从这个角度看，Harness可以先被理解成：模型外部的控制系统。
它把意图、上下文、工具、权限、状态、验证、反馈和生命周期组织成闭环，让Agent不只是"生成一个看起来合理的答案"，而是更稳定地把真实任务做完。
Harness的核心要素
一个完整的Harness系统，通常包含这几个要素：
1. 意图层（Intent）
清晰地告诉Agent要完成什么目标，不是描述性语言，而是可验证的验收条件。
2. 上下文层（Context）
确保Agent能看到真实文件、真实状态，而不是幻想出来的答案。
3. 工具层（Tooling）
给Agent配备正确的工具集，并且让它知道什么时候用什么工具。
4. 验证层（Verification）
任务完成后必须通过某种形式的验证，不能只是"看起来完成了"。
5. 反馈层（Feedback）
让Agent知道自己的行动产生了什么结果，包括成功和失败。
6. 生命周期层（Lifecycle）
任务可能是跨会话的，需要有状态保存和恢复机制。
与Prompt Engineering的区别
| 维度 | Prompt Engineering | Harness Engineering |
|---|---|---|
| 核心问题 | 怎么说更清楚 | 怎么让行动更稳定 |
| 关注点 | 提示词质量 | 工程闭环设计 |
| 衡量标准 | 回答质量 | 任务完成率 |
| 适用场景 | 单次对话 | 复杂多步骤任务 |
实践建议
从简单开始
不要一开始就设计复杂的Harness系统。先从一条可执行的工作流开始：
- 明确任务目标（验收条件）
- 定义必需的上下文（真实文件路径）
- 列出验证方式（如何判断完成）
- 测试这条链路是否稳定
渐进式完善
当简单的链路稳定后，再逐步加入：
- 错误处理和重试机制
- 状态保存和恢复
- 多步骤任务的拆解和编排
测量并迭代
记录Harness的失败模式：
- 哪类任务经常失败
- 失败的原因是什么
- 需要补充什么上下文或工具
写在最后
大模型的能力已经不是问题。问题在于：我们有没有为它搭建一个能让它稳定工作的环境。
Harness Engineering做的，就是这件事。
