Harness Engineering：给 AI 这匹千里马，套上一副好挽具
开篇：你有一匹千里马，然后呢？
想象一下：你拥有一匹绝世好马——日行千里、力量惊人。但问题是，光有马，你能骑着它上战场吗？
不能。你需要挽具、缰绳、马鞍——这一整套装备，在英文里就叫 Harness。
现在的 LLM（大语言模型）就是这匹千里马。Claude 4.6、GPT-5、Gemini 3，一个比一个"聪明"，推理能力一个比一个强。但——
模型再聪明，不等于它能稳定地产出好的结果。
2025 年下半年，AI 编程领域发生了一件大事：Claude Code 接棒 Cursor，成为 AI Coding 赛道的新王。与此同时，OpenClaw、Hermes 在办公自动化赛道崛起，腾讯推出 CodeBuddy（编程）+ WorkBuddy（办公），试图用"微信 + WorkBuddy"的组合拳打入 AI 办公场景。
这些产品背后的共同逻辑是什么？答案就是今天的主角——
Harness Engineering（挽具工程）：在模型外面，套上一整套让它稳定、可控、可重复完成任务的工程化系统。
一、AI 工程化的三代演进
在理解 Harness 之前，我们先快速回顾一下，人类是怎么一步步学会"驾驭"大模型的。
1.1 第一代：Prompt Engineering（提示词工程，2022-2023）
这是 AI 的"石器时代"。人们对 LLM 的理解还很粗浅，觉得只要把提示词写好，模型就能给出好结果。
你是一个资深前端工程师，请帮我用 React + TypeScript 写一个...
要求：
1. 使用函数组件
2. 添加错误边界
3. ...（一大堆详细指令）
这个阶段的核心问题是：不确定性。同一个 Prompt，模型可能这次输出完美代码，下次胡说八道。业内戏称为"抽卡"——Prompt 设计得再好，也只是提升"抽到金卡"的概率，做不到 100% 可控。
1.2 第二代：Context Engineering（上下文工程，2024-2025）
人们逐渐意识到：与其写越来越长的 Prompt，不如给模型提供更优质的上下文。
核心思路：不是直接让 LLM 凭"记忆"（预训练数据）回答，而是在提问前，先去检索相关资料，一起塞进 Prompt。
这就是 RAG（检索增强生成） 的思想——Retrieve（检索）→ Augment（增强）→ Generate（生成）。
Cursor 是这一阶段的标杆产品：它将你的整个代码库作为上下文（技术架构、代码风格、功能模块），让 AI 在充分"理解"项目后，再生成代码。
用户 Prompt → 检索知识库/代码库 → 增强后的 Prompt → LLM 生成
相比第一阶段，上下文工程让 AI 的输出更靠谱、更准确，一定程度上解决了"幻觉"问题。
1.3 第三代：Harness Engineering（挽具工程，2025-2026）
到了 2025 年，情况又变了：
- LLM 本身更聪明了（更强的推理能力）
- AI 已经和人类交互了数年，积累了海量数据，模型本身已经理解了人类的常见需求模式
- 你的 Prompt 在真正生成前，可能已经被 AI 自动优化过了
这时候，瓶颈不再是"提示词不够好"或"上下文不够多"，而是——
如何把 LLM 的能力工程化、系统化，让它像传统软件一样确定性交付？
Harness Engineering 应运而生。它不再是简单的技巧堆叠，而是比 Prompt 大一个量级的系统工程。
三代演进总结：
┌─────────────────────────────────────────────────────┐
│ Prompt Engineering → 怎么写提示词 │
│ Context Engineering → 给模型喂什么信息 │
│ Harness Engineering → 怎么构建一套可控的运行系统 │
└─────────────────────────────────────────────────────┘
二、LLM 的四大"结构性缺陷"
要理解 Harness 为什么重要，首先要理解 LLM 本身有无法消除的硬伤。这不是某个模型的 bug，而是当前 Transformer 架构的"基因"决定的。
缺陷一：无状态（Stateless）
每次对话结束，它什么都不记得。
LLM 的底层是 HTTP 调用——无状态协议。你和 ChatGPT 聊了一下午，你以为它在"记住"你说的话？不，是客户端每次把全部历史消息重新发过去。
// 你看到的
第1轮: 用户: "我叫小明"
第2轮: 用户: "我叫什么？" → AI: "你叫小明"
// 实际发生的
第2轮请求: messages = [
{ role: "user", content: "我叫小明" },
{ role: "assistant", content: "好的小明！" },
{ role: "user", content: "我叫什么？" } // ← 所有历史都在这里
]
📌 知识点：LLM 的无状态性来自于它的 HTTP 本质。HTTP 是无状态协议——每次请求都是独立的，服务器不保留任何客户端上下文。这带来了巨大优势：高并发、高可用、水平扩展——请求打到任何一台服务器都一样。但代价是：开发者必须自己管理"记忆"。
缺陷二：无法主动操作外部世界
LLM 只会生成文本（或图片），它不能读文件、搜网络、操作浏览器、调用 API。
一个纯粹的 LLM，就像一个困在房间里的天才——什么都知道，但什么都做不了。
要让 LLM 完成"帮我查一下青岛啤酒的股价"这样的任务，必须配合 Tool（工具）：
用户: "青岛啤酒股价多少？"
→ LLM 推理: 需要调用 getStockPrice 函数
→ Tool 执行: getStockPrice("青岛啤酒")
→ 返回结果: 128.50 元
→ LLM 再次生成: "青岛啤酒当前股价为 128.50 元"
📌 知识点 — Tool Use（函数调用）：OpenAI 等厂商提供了
tools接口，允许 LLM 在生成过程中"意识到"自己需要调用外部工具。LLM 会输出一个函数调用请求 → 开发者在本地执行 → 将结果返回给 LLM → LLM 基于结果生成最终回答。这就补齐了 LLM 操作外部世界的能力短板。
缺陷三：概率性输出（非确定性）
同样的输入，可能产生不同的输出。
LLM 的本质是基于概率预测下一个 token。这就意味着：
- 文无第一：生成文章、创意内容时，概率性是优势（多样性）
- 武无第二：写代码、做数学计算时，概率性是劣势（不可靠）
// 同样的 Prompt 调用两次
"用 JavaScript 写一个反转字符串的函数"
// 第一次: str.split('').reverse().join('')
// 第二次: [...str].reverse().join('') // 可能不一样！
Harness Engineering 要做的，就是通过规则、验证、重试等机制，把概率变成确定。
缺陷四：上下文窗口限制
LLM 不能无限处理信息。
以 DeepSeek-V4-Flash 为例，它有 100 万 Token 的超长上下文——看起来很厉害，但如果你真的塞满 100 万 Token：
- 成本飙升：每次请求的输入 Token 都是真金白银
- 注意力衰减：模型对"中间部分"的信息关注度下降（Lost in the Middle 现象）
- 响应变慢：处理长上下文需要更多计算
📌 知识点 — Token 与计价：Token 是 LLM 处理和计价的最小单位。1 个英文字符 ≈ 0.3 Token，1 个中文字符 ≈ 0.6 Token。你在对话中输入 + 输出的全部 Token 都会计入费用。所以上下文不是越多越好——精准的上下文比海量上下文更重要。
三、Harness 的四层核心架构
Harness Engineering 不是某个具体的框架或工具，而是围绕 LLM 构建的四类基础设施的总称。
🏎️ 模型是引擎，Harness 就是装着 V8 引擎的车。 引擎再牛，没有好的变速箱、刹车、仪表盘，这车根本没法上路。
3.1 第一层：记忆层（Memory Layer）—— 解决"无状态"
这是 Harness 最基础、最重要的一层。模型记不住，我们就帮它"记住"。
核心工具：CLAUDE.md / AGENTS.md
Harness 记忆模块
├── CLAUDE.md ← 项目级记忆（技术栈、规范、目录结构）
├── AGENTS.md ← Agent 行为规则
├── Memory 文件 ← 持久化事实记忆
└── Chat History ← 对话上下文管理
📌 知识点 — CLAUDE.md：这是 Claude Code 的记忆核心，相当于 AI 的导航地图。每次对话都会自动带上这个文件，告诉 Agent 项目最关键的技术栈、开发规范、文件结构等约束。可以把它理解为"AI 的员工手册"——每次干活前先看一眼，保证方向不跑偏。
# CLAUDE.md 示例
## 技术栈
- 前端：React 18 + TypeScript + Tailwind CSS
- 后端：Node.js + Express
- 数据库：PostgreSQL
## 开发规范
- 使用函数组件，禁止 class 组件
- API 路径统一前缀 /api/v1/
- 所有接口必须有 try-catch 错误处理
记忆管理策略
对话越聊越长，历史消息也不是全盘保留就好：
- Token 开销：messages 数组越大，每次请求成本越高
- LRU 策略：最近使用的保留，久远的适当清理
- 关键信息持久化：将重要决策、规范写入 Memory 文件，而非依赖消息历史
💡 最佳实践：新项目第一步 ——
/init初始化 CLAUDE.md，把项目核心约束写进去。后续规范变化后，再次执行/init更新记忆。这是 Harness 记忆层的"地基"。
3.2 第二层：工具层（Tool Layer）—— 让模型"动手"
没有工具，LLM 就是一个只会说话的脑子。有了工具，它才能真正干活。
工具生态体系
├── 基础工具 读写文件、执行命令、网络搜索
├── MCP 协议 标准化的工具接入规范（Model Context Protocol）
├── Skill 技能 封装好的"子程序"，一键调用
└── 自定义函数 业务相关的 API 调用（查股价、查数据库...）
📌 知识点 — Agent 的能力公式：
Agent 的能力 = LLM（大脑）× 工具（双手）× 上下文（眼睛）一个 Agent 有多强，取决于三件事：用什么大脑、装了什么工具、拿到了什么信息。缺一不可。
Tool Use 的工作流程
① 用户提问 → ② LLM 推理（我需要调用什么工具？）
→ ③ 生成工具调用指令（函数名 + 参数）
→ ④ 开发者在本地执行工具
→ ⑤ 执行结果返回 LLM
→ ⑥ LLM 基于结果生成最终回答
📌 知识点 — MCP（Model Context Protocol）：由 Anthropic 提出的标准化协议，让 LLM 可以通过统一接口接入各种外部工具和数据源。它类似于 USB 协议——不管设备是什么，只要支持 USB，就能即插即用。MCP 让工具管理从"手工对接"变成了"标准化接入"。
3.3 第三层：上下文层（Context Layer）—— 给模型"看清楚"
如果记忆层是"地图"，工具层是"双手"，那上下文层就是 LLM 的眼睛。
上下文来源
├── 代码库 整个项目的文件结构、代码风格、技术架构
├── 知识库 业务文档、技术文档、FAQ
├── RAG 检索 从外部知识源实时检索相关内容
├── 历史消息 当前对话的上下文
└── 规则约束 编码规范、安全策略、输出格式要求
📌 知识点 — RAG（Retrieval-Augmented Generation）： RAG 是上下文工程中最高阶、最核心的应用场景。它的工作流是：
- Retrieve：从知识库中检索与用户问题最相关的文档
- Augment：将检索到的文档拼接到 Prompt 中
- Generate：LLM 基于丰富后的 Prompt 生成回答
这就像考试时开卷 vs 闭卷——LLM 的预训练知识是"闭卷"，RAG 是给了它一本参考书。
上下文不是越多越好
记住 LLM 的缺陷四——上下文窗口限制。Harness 上下文层的核心挑战是：在有限的 Token 预算内，选择最有价值的上下文。
3.4 第四层：控制层（Control/Loop Layer）—— 让模型"有规矩"
这是 Harness Engineering 中最高级的一层，也是 2025-2026 年最热的方向。
控制层 = 规则 + 围栏 + 循环 + 验证
为什么要控制？
LLM 是概率性的（缺陷三）。同样的问题，两次回答可能不一样。而工程化的核心要求是"确定性交付"——同样的需求，必须给出可靠的结果。
控制层的几个关键机制：
| 机制 | 说明 | 类比 |
|---|---|---|
| 规则围栏 | 硬性约束：不能调用哪些 API、不能修改哪些文件 | 马路护栏 |
| Loop 循环 | 自动重试 → 检查 → 修正 → 再检查，直到合格 | 质检流水线 |
| Skill 封装 | 把高频操作封装为标准化"技能"，一键执行 | 宏/模板 |
| 验证机制 | 代码 review、测试运行、结果比对 | CI/CD |
📌 知识点 — Loop Engineering：AI 生成内容后，不是直接交付。而是进入一个循环验证流程：生成 → 检查 → 发现错误 → 自动修正 → 再检查。直到质量达标，才输出最终结果。这就像传统软件的 CI/CD 流水线，只不过每一步的执行者变成了 LLM。
四、一张图理解 Harness Engineering 全景
┌─────────────────────────────────────────────────────────┐
│ Harness Engineering │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌───────────┐ │
│ │ 记忆层 │ │ 工具层 │ │ 上下文层 │ │ 控制层 │ │
│ │ │ │ │ │ │ │ │ │
│ │ CLAUDE │ │ Tool │ │ RAG │ │ Loop │ │
│ │ .md │ │ MCP │ │ 代码库 │ │ Skill │ │
│ │ Memory │ │ API │ │ 知识库 │ │ 规则围栏 │ │
│ │ History │ │ Search │ │ 文档 │ │ 验证 │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ └─────┬─────┘ │
│ │ │ │ │ │
│ └────────────┴────────────┴──────────────┘ │
│ │ │
│ ┌────▼────┐ │
│ │ LLM │ ← 引擎（大脑） │
│ └─────────┘ │
│ │
│ 🏎️ 模型是引擎，Harness 是整车 │
└─────────────────────────────────────────────────────────┘
五、核心知识点总结
AI 工程化三代演进
| 阶段 | 时间 | 核心问题 | 代表产品 |
|---|---|---|---|
| Prompt Engineering | 2022-2023 | 怎么写好提示词 | ChatGPT |
| Context Engineering | 2024-2025 | 给模型喂什么信息 | Cursor, RAG |
| Harness Engineering | 2025-2026 | 如何构建可控系统 | Claude Code, Codex, WorkBuddy |
LLM 的四大结构性缺陷
| 缺陷 | 含义 | Harness 如何解决 |
|---|---|---|
| 无状态 | 每次对话独立，不记忆 | 记忆层（CLAUDE.md、Memory） |
| 无行动力 | 只会生成文本 | 工具层（Tool Use、MCP） |
| 概率性 | 输出不确定 | 控制层（Loop、验证、规则） |
| 上下文有限 | Token 窗口有上限 | 上下文层（RAG、精准检索） |
你必须知道的几个核心概念
| 概念 | 一句话解释 |
|---|---|
| Agent | LLM + 工具 + 上下文 = 能自主干活的 AI |
| LLM | Agent 的"大脑"，负责推理和生成 |
| Tool | 补全 LLM 操作外部世界的能力 |
| MCP | 标准化的工具接入协议（工具的"USB"） |
| RAG | 先检索再生成，给 LLM "开卷考试" |
| Token | LLM 计价和处理的最小单位 |
| Stateless | HTTP 无状态本质，LLM 自己没有"记忆" |
| Loop | 生成 → 验证 → 修正的自动化循环 |
写在最后
2025-2026 年，是 AI 从"玩具"走向"工程"的关键转折点。
Harness Engineering 的本质，是让 AI 开发从"抽卡"变成"确定性交付"。
企业全面拥抱 AI 数字化，需要的不是更强的单次生成能力，而是稳定、可控、可重复的 AI 工作流。这也是为什么 FDE（AI 工程落地）工程师被大量需要——把 AI 这匹千里马，真正套上挽具，让它能耕地、拉车、上战场。
下一次当你打开 Claude Code，看到它自动读取你的项目规范、调用工具、执行验证循环时——你看到的，就是 Harness Engineering 的完整落地。
模型是引擎，Harness 是整车。两样都懂，你才是真正的 AI 工程师。
如果这篇文章对你有帮助，欢迎点赞、收藏！对 Harness Engineering 有什么理解或疑问，也可以在评论区一起交流~ 🚀
