Harness Engineering 完全解读：让 AI Agent 从跑偏到可控

模型是商品，Harness 才是护城河。

---

一、什么是 Harness Engineering

Harness Engineering 是 2026 年 AI 工程领域最被低估的热词。它由 HashiCorp 创始人 Mitchell Hashimoto 在 2026 年 2 月正式定义。核心哲学就只有八个字：

人类掌舵，智能体执行（Human Steer, Agent Execute）

用一句话说清楚：AI Agent 犯了错，别改 prompt，加约束——让同样的错误在结构上不可能再犯。

这不是一套理论，而是一种工程实践。它不优化模型本身，而是优化模型运行的环境。你可以把 Harness 想象成给 AI 装上的「马鞍 + 缰绳 + 围栏」——AI 依旧是那匹快马，但你给了它跑道和安全边界。

核心公式

Agent = Model + Harness

• Model：大模型（GPT、Claude、DeepSeek……）是大脑，负责生成和推理

• Harness：约束、反馈、工作流、上下文、工具、安全——是神经系统

OpenAI 的工程师直言："我们 80% 的工作是在建 Harness，不是调模型。"

---

二、AI 应用开发的三代进化历程

Harness Engineering 不是凭空出现的。它是 AI 应用开发范式演变的必然结果。

第一代：Prompt Engineering（2023）

一切始于"写好 prompt"。开发者把精力放在提示词的结构、示例的编排、few-shot 的选择上。

特点：黑盒调试、靠玄学、不可复制。同一个 prompt 换一个模型版本就失效。

教训：Prompt 再漂亮，也拦不住模型在边缘场景跑偏。

第二代：Context Engineering + RAG（2024）

业界意识到"光靠 prompt 不够"，开始引入外部知识。RAG（检索增强生成）登场，模型能实时检索知识库、数据库。

同时，Context Engineering 崛起——动态组装上下文，挂载相关文档、指令、记忆。

特点：引入知识，模型跑偏率下降，但工具调用、多步规划仍然不可靠。

第三代：Harness Engineering（2025-2026）

模型能力在接近天花板（Scaling Law 放缓），但 Agent 的可靠性远未达标。Harness Engineering 应运而生——把模型当成 CPU，把 Harness 当成操作系统内核。

这不是词汇的堆砌，而是工程范式的跃迁：从"怎么跟模型说话"到"怎么给模型造一个不会出错的运行环境"。

---

三、拆解 Harness 的三大核心支柱

Harness 不是一个单一技术栈，而由三个互相咬合的工程层面组成：

支柱一：Feedforward Guides（前馈指南）

在模型输出之前，通过结构化的约束引导它走对的方向。

• Schema 约束：用 JSON Schema、正则、枚举限定输出格式

• Workflow 编排：预设 Agent 的执行流程节点（比如：先检索 → 再分析 → 再执行 → 最后验证）

• Skill / Tool 白名单：Agent 能用的工具必须注册，不能自己"发明"工具调用

• Rules 层：硬编码的业务规则，不可被 prompt 覆盖

金句：Guide 让你第一次输出就往对的方向走。

支柱二：Feedback Sensors（反馈传感器）

在模型输出之后，通过自动化系统校验结果，发现问题立即修正。

• Validation 层：输出格式校验、JSON 合法性、字段约束

• Eval 层：LLM-as-Judge（用另一个模型评估输出质量）

• Test 层：单元测试、集成测试、Golden Set 对比

• Sanity Check：结果是否明显荒谬（比如返回 404 却说成功）

金句：Sensor 让你跑偏了也能在失控之前拉回来。

支柱三：Observability & Memory（可观测与记忆）

Harness 不是"一次性"的，而是一个持续优化的闭环。

• Trace：记录每次 Agent 执行的完整链路（决策路径、调用明细、耗时）

• 回放：能从历史数据中复现失败的执行场景

• Memories：成功和失败的案例被持久化，成为未来决策的参考

• 持续改进：通过反馈数据自动调整参数、阈值、规则

---

四、从零搭建一个可用的 Harness

理论说得再多，不如动手。假设我们要用一个 AI Agent 来自动化发布公众号文章，Harness 应该长什么样？

Step 1：定义 Skill 规范

不是让模型自由决定"要调用什么工具"，而是预先注册 Skill：

skills/
├── wechat-publisher/    # 发布公众号
│   ├── SKILL.md         # 技能描述
│   ├── scripts/         # 执行脚本
│   └── _meta.json       # 元数据
└── content-writer/      # 内容生成
    ├── SKILL.md
    └── templates/

Step 2：加 Schema 约束

强迫模型输出符合格式的内容，而不是"随缘输出"：

文章输出约束：
- title: 必须存在，长度不超过 64 字
- cover: 必须存在，指向可访问的图片
- body: Markdown 格式，不超过 5000 字

Step 3：加反馈校验

• 发布前：wenyan-cli 自动校验 Markdown 格式、封面存在性

• 发布后：检测 API 返回码，确认发布成功，否则自动回滚

• 失败时：记录完整 trace，供后续复盘

Step 4：建可观测层

• 每次发布的耗时、成功率、失败原因

• 模型出错的模式（是封面图挂了？还是内容超长了？）

• 基于失败模式自动调整约束

你看，这个"Harness"里没有魔法。它只是把工程的最佳实践推进到 AI Agent 的每个接口。

---

五、真实工程实践的核心启发

翻遍 Anthropic、OpenAI、Stripe、Cursor 等一线团队的开源文档和演讲，有以下共识：

启发一：Harness 的 80/20 法则

80% 的可靠性提升来自前 20% 的 Harness 投入——约束输出格式 + work flow 编排就能消掉一大半的模型偏差。真正难的 20% 在边界情况（Edge Cases）的处理。

启发二：不要相信 model 会自我纠正

模型在同一个 session 里越跑越偏是常态，不会"知错就改"。Harness 必须在模型外部做校验和修正。

启发三："出错"的定义权在 Harness，不在模型

"什么是正确的输出"由业务规则定义，不由模型"觉得"。输出不符合业务逻辑，就是错的，Harness 要拦下来。

启发四：从 In-the-loop 到 On-the-loop

• In-the-loop：你审每个输出 → 不可扩展

• On-the-loop：你设计运行条件，系统自动验证 → 可规模化

启发五：Harness Engineering 正在变成新的系统设计面试考点

JavaGuide、菜鸟教程、各大 AI 社区都在加相关专题。面试官不再问"你用过什么模型"，而是问"你怎么保证模型不出错"。

---

总结

Harness Engineering 不是某个技术名词的换皮，而是 AI 应用工程化走到深水区后的必然产物。

当模型能力不再是瓶颈，如何让 AI 系统在真实业务中稳定运行就成了真正的护城河。

• 模型是商品化的，今天你有 GPT-5，明天别人有同等水平的开源模型

• Harness 是你的，数据、约束、反馈、工作流——这些才是竞争对手抄不走的

从 Prompt Engineering 到 Context Engineering，再到 Harness Engineering，每一步都是让 AI 从"能跑"走向"可靠"的必经之路。

模型负责聪明，Harness 负责靠谱。