Harness Engineering：给千里马套上缰绳

Prompt Engineering 教你怎么跟模型说话。Context Engineering 教你怎么给模型喂资料。而 Harness Engineering 回答的是一个更根本的问题：怎么管住一个比你聪明、但完全不靠谱的模型，让它稳定地干活？

答案是：不给它自由发挥的空间，给它一套被约束的执行环境。

---

一、AI 工程化的三个时代

2022 到 2026，AI 工程化走了三个阶段，每个阶段回答的问题不同：

阶段	时间	要解决的问题	思路	代表产品
Prompt Engineering	22-23	模型不知道你要什么	优化输入文本	ChatGPT, GitHub Copilot
Context Engineering	24-25	模型不知道背景信息	检索+增强输入	Cursor, Trae, RAG
Harness Engineering	25-26	模型不可控	约束行为	Claude Code, Codex, Hermes

三个阶段不是替代关系，是叠加关系。但思路上有一条清晰的分界线：

Prompt 和 Context 都是在"增强输入"------给模型更好的信息，期望它产出更好的结果。 Harness 换了思路------不再期望模型自己变好，而是从外面框住它。

这个区别很微妙，但它解释了一个现象：为什么当年大家花那么多精力写"完美 prompt"，效果却总是不稳定？

因为你在教马听话，但马有时候就是不听。Harness 不教------它直接上缰绳。

---

二、理解 Harness 之前，先理解 LLM 的四个"硬伤"

LLM 有四个结构性缺陷，不是 bug，是它本质决定的。修不了，只能约束：

1. 无状态（Stateless）

每次调用 LLM 接口，本质上是一次 HTTP 请求。HTTP 是无状态协议------服务器处理完就忘了你是谁。这和你在 ChatGPT 网页里"连续对话"的体验完全不同------那是前端在帮你拼接上下文。

LLM 每一次推理都是独立事件。上一轮说了什么，它真的不记得。

Harness 的思路：不在模型内部建记忆，而是在外部建记忆文件（CLAUDE.md、MEMORY.md），每次 prompt 强制带上。你不是在给模型装脑子，你是在给它配地图。

2. 无法操作外部世界

那个在显卡里疯狂跑的 LLM，本质上还是词语接龙------Next Token Prediction。它是被困在服务器里的"缸中大脑"，看不见屏幕，摸不到键盘。

它能生成文字说"我帮你查一下天气"，但它真的查不了。

Harness 的思路：在外部注册工具（MCP/Skills），模型只负责决策"该调哪个工具、传什么参数"，执行由 runtime 完成。工具调用不是模型的能力，是 Harness 赋予的能力。

这里隐藏着一个精妙的设计------认知植入。LLM 只懂语言，不懂什么叫 API、什么叫数据库查询。于是你把工具的接口，降维成一份它看得懂的 JSON Schema 使用说明书，写进 System Prompt。

当用户问"青岛啤酒股价多少"，LLM 的推理链是这样的：

这个问题训练数据里没有当前股价 → 但 System Prompt 里有个工具叫 getPrice → 
我按说明书生成一段调用代码 → tool_calls: [{ function: { name: 'getPrice', arguments: { symbol: '青岛啤酒' } } }] → 
我赌这段代码发出后有人会响应

LLM 不执行工具，它只是"说"出了调用的意图。真正执行的是 Harness 层的 runtime------拿到返回结果，再喂给 LLM，让它知道怎么回答。这是一个精心设计的错觉：用户以为 LLM 干了所有事，其实是 Harness 在背后调度。

3. 输出是概率性的

同样的输入，可能得到不同的输出。Transformer 架构的底层是概率计算------它不"知道"正确答案，它"猜"哪个下一个词的概率最高。

这在创造性任务（写文章、起名字）中是好事------"文无第一"。但在确定性任务（写代码、算价格、调接口）中是灾难------"武无第二"。

Harness 的思路：不用 prompt 去求它"请你认真点"，而是在流程层面加验证闭环。生成 → 检查 → 不达标 → 重来。Loop 就是为此而生的------gen 生成，check 审查，两个角色用同一个 LLM 但不同的 System Prompt。gen 是创作者，check 是审查者。角色分离是自检查机制能跑稳的关键。

4. 上下文有限

即使是 DeepSeek-V4 的 1M token 超长上下文，也装不下一个项目全部的历史对话、代码文件和参考文档。

Harness 的思路：分层管理。核心规范（CLAUDE.md）每次都带，参考资料按需检索（RAG），历史对话摘要压缩。不是"给模型看一切"，而是"给模型看关键"。

---

三、Prompt 和 Context 的局限性

在聊四层架构之前，先回答一个问题：为什么 Prompt Engineering 和 Context Engineering 不够？

Prompt Engineering 的底层逻辑是：我写一段足够精准的文字，模型理解了我的意图，输出好结果。问题是------模型的理解力不是你能控制的。同样一段 prompt，不同模型表现不同，同一个模型不同时刻也可能不同。你写了一千字的 prompt，模型可能只抓住了其中一句。

Context Engineering 往前走了一步：它不靠"写得精准"，而靠"把相关资料塞进去"。Cursor 把你的整个代码库作为上下文，RAG 先检索再增强。这确实让准确度提升了一个台阶。但底层逻辑没变------还是在依赖模型自身的能力去理解和利用这些上下文。

资料给了它，它不用，你也没办法。在 Prompt 和 Context 的范式里，你对模型行为的控制力几乎为零。

Harness 不再走"依赖模型"的路线。它走的是"约束模型"的路线。 这不是 prompt 的升级版，这是控制逻辑的根本逆转。

---

四、Harness 的四层约束架构

Harness 不是某个具体的框架或工具，它是围绕模型构建的一套约束基础设施。核心有四层，从内到外，层层约束：

第一层：记忆层 --- 地图

回答：这是谁、在哪、要干什么。

这层直接对治"无状态"的硬伤。关键设计：

• CLAUDE.md：项目级核心约束，每次对话都强制注入。不是"建议"，是绑定到每一轮请求里的约束声明。它告诉 Agent：这是什么项目、技术栈是什么、代码规范是什么、目录结构是怎样的。
• MEMORY.md：跨项目的持久记忆。用户偏好、工作习惯、长期约定。
• 对话摘要：当历史对话超过上下文窗口，压缩成摘要继续带。

记忆层是 Harness 的基石。一个没有 CLAUDE.md 的 Agent，就像一个没有导航地图的司机------能开，但不知道往哪开。

第二层：护栏层 --- 围栏

回答：什么不能做。

Prompt 里写"请遵守安全规范"，这是请求。请求可以被模型忽略。

Harness 的护栏是在系统层设限：

• 规则声明：CLAUDE.md 和 rules 文件定义行为边界，强制注入，每轮都带
• 权限控制：能调哪些工具、能读哪些文件、能写哪些目录------白名单机制，不在名单上的根本不可见
• 安全围栏：敏感操作拦截（部署、删除、付款）、代码执行沙箱

Prompt 里的规则是"建议"，Harness 里的规则是"墙"。

第三层：工具层 --- 手脚

回答：能做什么、怎么调用。

这层直接对治"无法操作外部世界"的硬伤。三个关键机制：

（1）认知植入 --- 把工具翻译成 LLM 懂的语言

LLM 不懂什么是 API，不懂什么是数据库。但它懂语言。所以你把每个工具写成一个 JSON Schema------名称、描述、参数类型、返回值。这不是给开发者看的 API 文档，这是一份 LLM 能理解的使用说明书。

（2）意图识别 --- LLM 的"自言自语"

当 LLM 判断自己回答不了，它会查自己在 System Prompt 里被植入了什么工具。找到匹配的，生成一段 tool_calls------不是真正的函数调用，而是一段结构化的"调用请求"。LLM 在赌：这段请求发出去后，会有人（runtime）响应。

（3）Runtime 介入 --- 真正的执行者

LLM 只负责"我要调 getPrice('青岛啤酒')"，真正执行的是 Harness 层的 runtime。runtime 拿到结果后，不是直接返回给用户，而是追加到 messages 里，再发给 LLM，让它结合上下文生成最终回复。

整个链条是这样的：

用户提问 → LLM 推理 → 生成 tool_calls → Runtime 执行 →
结果返回 LLM → LLM 再次推理 → 最终回复

用户看到的是"AI 帮我查了股价"，实际上 LLM 只是做了两次推理。操作是 Harness 层完成的。

第四层：流程层 --- 执行链

回答：按什么顺序做、怎么验证、什么时候停。

这层直接对治"输出概率性"和"上下文有限"两个硬伤。核心机制是 Loop（循环）：

生成 → 检查 → 不达标 → 重来
       ↓
     达标 → 交付

Loop 不是简单的"再试一次"。它包含了完整的设计考量：

• 从哪里开始：任务描述 + System Prompt + 能力声明
• 重复做什么：Plan（推理）→ Act（调工具）→ Observe（拿结果）→ Check（验证）→ Learn（追加历史）
• 什么时候结束：目标达成 / 最大轮次 / 超时 / 人工介入 / 连续失败

检查机制有五层，由轻到重：

1. 规则校验（0 token）：正则、JSON Schema、字数------不用 LLM 的事就别用 LLM
2. LLM 自检（低 token）：同一个模型，不同 System Prompt，创作者变审查者
3. 执行验证（最可靠）：代码能跑就是能跑，测试能过就是能过，不依赖 LLM 判断
4. 多维检查：格式 + 安全 + 业务规则 + 语义，多个 checker 串行
5. 人在回路：部署、删数据、付款------最后一道防线，等人点确认

Loop Engineering 出现后，你的位置变了。以前你人在 Loop 里面------写 prompt → 看结果 → 不满意 → 改 prompt → 再看。现在你站在 Loop 外面------设计规则、定义检查、设好刹车，让 Agent 自己跑。

---

五、Harness 的整体图景

把四层拼在一起，就是一张完整的 Harness 构架图：

你的 Prompt
    │
    ▼
┌─────────────────────────────────────────┐
│            Harness 约束系统               │
│                                          │
│  🗺️  记忆层：CLAUDE.md + MEMORY.md       │
│      → 这是谁、在哪、要干什么              │
│                                          │
│  🛡️  护栏层：规则声明 + 权限控制           │
│      → 什么不能做                         │
│                                          │
│  🔧 工具层：MCP + Skills                 │
│      → 能做什么、怎么调用                  │
│                                          │
│  ⚙️  流程层：Loop + 验证闭环              │
│      → 按什么顺序做、怎么验证              │
│                                          │
│         ┌──────────┐                    │
│         │   LLM    │   ← 引擎           │
│         │ (发动机)  │                    │
│         └────┬─────┘                    │
│              ▼                          │
│         输出 → 验证 → 不达标 → 重来       │
│              → 达标 → 交付              │
└─────────────────────────────────────────┘

这张图解释了一个核心逻辑：LLM 只是引擎，不是整辆车。 引擎提供动力，但变速箱（工具层）、刹车（护栏层）、仪表盘（记忆层）、方向盘（流程层）------这些才是让车能上路的东西。

---

六、一切从哪里开始：数据

讨论 Harness 这个"模型之上"的控制系统时，有必要看一眼"模型之下"的东西。

LLM 的智能从哪来？三个要素：数据 + 算力 + 算法。

算力（GPU/显存/CUDA）是硬件基础。算法（Transformer 架构）是计算规则。但真正决定模型"懂得什么"的，是预训练数据。

数据在模型训练中的角色，像学生的学习路径：

• 训练集（80%）：课本------吸收知识，寻找规律
• 验证集（10%）：课后作业------频繁检验，调节参数
• 测试集（10%）：高考------评估模型在没见过的数据上的泛化能力

泛化能力是关键------模型不是死记数据，而是在全新输入上做出正确判断。这依赖于数据工程的精细程度：采集 → 清洗 → 标注 → 去重 → 污染检测 → 交叉验证。K 折交叉验证确保模型不偏科------把数据分成 K 份，每次轮换测试集，轮完 K 次后所有数据都被训练过也被测试过。

在模型之上，是 Harness 的约束艺术。在模型之下，是数据的地基。

---

七、Harness 的现实映射：Vibe Coding 为什么能工作？

氛围编程（Vibe Coding）------用自然语言持续编程而不跑偏------不是 LLM 变强了，而是 Harness 变完整了。拆开来看：

Harness 层	在 Vibe Coding 中的对应
记忆层	CLAUDE.md 定义技术栈、代码风格、项目结构，每次对话都带
护栏层	命名规范、架构约定、禁止某些写法的规则，不是建议是约束
工具层	MCP（读写文件、执行命令）+ Skills（/review、/test、/deploy）
流程层	生成代码 → /review → /test → 通过才合入，不达标自动重来

Claude Code 的 core loop 就是典型的 Harness 架构：

用户说需求
  → LLM 推理：读哪些文件、改什么、怎么改
  → 调工具：Read → Edit → Bash（跑测试）
  → 观察结果：测试通过了？lint 报错了？
  → 不达标 → 把报错喂给 LLM → 重新改 → 再跑
  → 达标 → 交付

整个过程中，LLM 只负责"推理和生成"，所有执行、验证、重试都在 Harness 层完成。这就是为什么你不需要盯着它------你的位置在 Loop 外面。

实操上最重要的一条经验：新项目先 /init，生成 CLAUDE.md。先套缰绳，再让马跑。 CLAUDE.md 改变后重新 /init，因为模型第一次读取后会放进缓存，改文件不会自动更新缓存。

---

八、Agent 的三位一体

理解了 Harness，再回头看 Agent，它的组成就清晰了：

Agent = LLM（大脑）+ Tools（手脚）+ Harness（控制系统）

三个要素各司其职：

• LLM 负责推理和生成，决定了 Agent 的上限
• Tools 补齐操作短板，让 Agent 能对接外部世界
• Harness 把单次调用变成可重复的确定性交付

没有 Tool，AI 只有空推理。没有 Harness，人必须反复下场盯着。Harness 是 Agent 从"玩具"变成"工人"的临界点。

---

九、总结：Harness Engineering 的核心信条

整篇文章可以用几句话概括：

1. LLM 很强，也很不靠谱。 它不是故意的，是本质决定的------无状态、无法操作世界、概率性输出、上下文有限。

2. 别想着修模型，想着管模型。 Prompt 和 Context 都在"增强输入"，还在依赖模型自己变好。Harness 换了一个方向------在外部建约束系统。

3. 控制力的来源不是 prompt，是约束。 记忆层给地图，护栏层给围栏，工具层给手脚，流程层给执行链。四层环环相扣，把模型的概率性输出变成确定性交付。

4. 你的位置变了。 以前你在 Loop 里面，一遍遍改 prompt。现在你站在外面------设计约束、定义规则、设好刹车，让 Agent 自己跑。

5. 模型是引擎，Harness 是车。 引擎再牛，没有变速箱、刹车、仪表盘、方向盘------这车没法上路。

---

Harness Engineering 的终极目标不是让模型变得更强，而是让模型变得可控。不是提升上限，而是守住底线。

把千里马套上缰绳，比追着马跑，高效得多。

---

文中涉及的关联知识：Prompt/Context/Harness 三代工程演进、LLM 四缺陷（无状态/无法操作世界/概率性/上下文有限）、Tokenization 与 Embedding、Tool Use 三阶段（认知植入/意图识别/Runtime 介入）、数据集划分与交叉验证、Loop 三要素与五环架构、检查机制五层分级、Agent = LLM + Tools + Harness 三位一体模型。