第三站：Harness Engineering - 关键一跃

第三站：Harness Engineering - 关键一跃#

Harness定义#

到了 2026 年初，模型已经能连续干好几个小时的活了。这时候你会发现：

提示词没毛病
上下文也没毛病
可它在长链路任务里还是会跑偏

一个全新的问题冒出来了：谁来监督它？谁在它跑偏时把它拉回来？

这就是 harness 要解决的。

Harness 直译是"马具、缰绳"。引申含义：让模型这匹烈马的力量真正为你所用，而不是被它带着跑。

Mitchell Hashimoto的定义#

最早把 harness 这个词点响的，是 Terraform 的作者 Mitchell Hashimoto。他给出了一个朴素到极致的定义：

每次你发现 agent 犯了一个错，就花时间去工程化一个解决方案，让它再也不可能犯同样的错。

两个关键点：

每次犯错都触发工程化响应——错误不是"踩过就算"，而是"必须修复"
修补必须沉淀到环境里——不是留在你脑子里靠下次记住

agent犯错 → 识别错误模式 → 工程化解决方案 → 沉淀到环境 → 该错误永久消失

复利效应#

这套做法的威力在于它是"复利"的：

每犯一次错 → 环境就强一点 → 下次同类错误不再发生
    ↓
环境强度 = 初始环境 + ∑(所有已修复错误的防护)
    ↓
时间越长，环境越强，agent越稳

时间维度	传统做法	Harness 做法
短期	靠人盯，错误反复发生	投入工程化时间，初期慢
中期	错误率基本持平	同类错误清零
长期	疲于补救	复利累积，agent 稳定度持续上升

复利的本质：每犯一次错，环境就强一点。这是一个正向循环。

Agent = 模型 + Harness#

公式：Agent = 模型 + Harness

组件	决定什么
模型	决定上限（能力天花板）
Harness	决定它能不能真正落地（实际交付质量）

含义：

模型再强，没有 harness 也只是个"会跑偏的天才"
harness 再好，模型太弱也跑不出有用结果
真正决定 agent 能否稳定交付的是 harness，不是模型

关键一跃#

这就是那一跃。

前两站再怎么折腾，重心都在"怎么把模型这一步伺候好"：

Prompt：让模型这一步说对话
Context：让模型这一步有足够且精准的输入

而 harness 第一次把整个工程的重心，搬到了"模型之外的那一整套世界"：

不再只优化"模型这一步"
而是设计"模型工作于其中的环境"
让环境本身承担起监督、纠错、强化的职责

前两站重心：模型 ← 工程优化方向
    ↓ 关键一跃
Harness重心：环境 ← 工程优化方向（模型外部世界）

这一跃是范式性的：从"调教模型"转向"设计模型外部世界"。

层层包含#

三站不是谁取代谁，是层层包含：

Prompt ⊂ Context ⊂ Harness

Prompt 是 Context 的一部分：提示词是上下文的一个组成
Context 是 Harness 的一部分：上下文管理是环境设计的一个组成
Harness 是更完整的世界：包含提示词、上下文、工具、监督机制、错误防护等

工程含义：做 Harness 工程时，前两站的知识仍然有效且必要，只是被纳入更完整的体系。

Harness工程化方法论#

基于 Mitchell Hashimoto 的定义，可提炼四条方法论：

1. 错误即资产#

每次 agent 犯错，都是一次发现环境漏洞的机会。错误不是负面事件，而是改进环境的资产。

实践：建立错误日志，记录每次跑偏的模式、原因、影响。

2. 修补必沉淀#

修补不能停留在"我下次记得提醒它"，必须沉淀到环境——以代码、配置、规则、检查器等形式固化。

反模式：

"下次我会告诉它注意 X" → 留在你脑子里，会忘、会漏
"我手动修一下这次输出" → 下次还会犯

正模式：

写一个 lint 规则禁止 X → 环境自动拦截
配置一个检查器验证 X → 环境自动验证
修改工具描述明确禁止 X → 模型每次都看到

3. 复利积累#

环境建设是复利过程，不是一次性工程。

短期看投入大、产出慢
长期看错误清零、稳定度持续上升
关键是持续投入而非"搭好一套就完事"

4. 结构化防御#

错误防护应是结构化的，而非零散的补丁：

防御层	职责	示例
输入校验层	拒绝非法输入	任务描述必须含明确输出格式
过程监督层	中间状态检查	长链路任务每 N 步检查进度
输出验证层	结果合规性检查	代码必须通过测试 + lint
错误恢复层	跑偏后拉回	检测到偏离自动重启子任务

← 返回索引页 | 上一节 03-Context Engineering | 下一节 05-Loop Engineering