模型是 V8 引擎，Harness 就是装着引擎的车。引擎再牛，没有变速箱、刹车和仪表盘，这车没法上路。

---

一、AI 数年历史：从 Prompt 到 Harness 的演进之路

1.1 Prompt Engineering —— 学会和模型"说话"

AI 编程的起点，所有人都从同一个动作开始：写 Prompt。早期 Prompt Engineering 研究的是"怎么说，模型才能给出更好的回答"：

你是一个资深算法工程师，请用 JavaScript 实现一个快速排序，
要求：时间复杂度 O(nlogn)，原地排序，带详细注释。

但很快人们发现——哪怕用完全相同的 Prompt，模型也可能给出参差不齐的结果。这就是所谓的"抽卡"：Prompt 质量只能提升抽到金卡的概率，做不到百分百可控。

1.2 Context Engineering —— 不止是一句 Prompt

当单次 Prompt 不够用，人们开始往模型里塞更多背景信息：历史对话、项目文档（RAG 检索增强生成）、开发规范和代码风格（System Prompt / Rules）。

这就是 Context Engineering（上下文工程）：模型还是那个模型，但给它更充分的上下文，让它做出更准确的判断。

RAG（Retrieval-Augmented Generation）：先从知识库检索相关内容（Retrieval），再作为增强信息喂给模型（Augmented），最后生成结果（Generation）。这是上下文工程的典型范式。

1.3 Harness Engineering —— 比上下文工程更大的格局

上下文工程的核心问题仍然是 怎么"告诉"模型更多信息。Harness Engineering 问的是一个更大的问题：怎么在模型外面，建造一整套系统，让模型能力可以被稳定、重复地驾驭？

阶段	核心问题	手段
Prompt Engineering	怎么说模型才听？	优化提示词
Context Engineering	给模型什么背景信息？	上下文注入、RAG
Harness Engineering	怎么让模型稳定干活？	记忆 / 工具 / 循环 / 约束

Harness 不再是把 Prompt 提升一个档次——它比 Prompt 大一个量级。

---

二、Harness Engineering 是什么？

2.1 行业背景

2025 年下半年，AI Coding 进入工程化时代：

• Claude Code 接棒 Cursor，重新定义 Agent 工作流
• OpenClaw / Hermes 切入办公自动化，让 AI 操作桌面软件
• 腾讯 CodeBuddy 深耕 Coding，WorkBuddy 进军办公自动化，微信 + WorkBuddy 意味着 Agent 进入国民级应用

这些产品的共同点：它们都不是"裸调大模型"，都在模型外面套了一层厚重的工程架构。 这层架构，就是 Harness。

2.2 两个比喻

比喻一：想象一匹千里马，力量惊人。但让它能耕田、拉车、作战的，不是马本身——而是挽具（Harness）：缰绳、马鞍、笼头、肚带。LLM 就是那匹马，很智能，但"智能"不等于"能稳定产出好的输出"。

比喻二：模型是 V8 引擎，Harness 就是装着引擎的整车。引擎再牛，没有变速箱（任务调度）、刹车（安全约束）、仪表盘（可观测性），这车没法上路。

Harness 要做的事很明确：研究怎么在模型外面套上好的"挽具"，让模型能力可以被稳定、重复地驾驭。 这不是某个具体框架，而是围绕模型构建的几类基础设施的总称。

---

三、LLM 的四大结构性缺陷

要理解"为什么需要 Harness"，先要理解模型本身"缺什么"。

3.1 无状态（Stateless）

LLM 是基于 HTTP 的无状态推理服务——每次请求独立，服务端不保存会话状态。

请求1: "我叫张三，是前端工程师" → 模型: "好的张三。"
请求2: "我叫什么？"            → 模型: "抱歉，我不知道。"  ← 无状态！

为什么必须无状态？ 支撑海量并发，服务端保存状态则水平扩展无从谈起。

3.2 无法主动操作外部世界

纯 LLM 的能力边界：输入文本 → 输出文本，结束。但真实任务需要读文件、调 API、操作浏览器、查数据库、通过 MCP 连接第三方服务——这些模型本身都做不到。

3.3 输出是概率性的

LLM 本质是概率模型，每次生成 token 都在概率分布中采样：

• 创意写作：概率性是好事，“文无第一”
• 代码生成：概率性是坏消息——你希望每次结果都确定可预期

同一段 Prompt "写一个二分查找"，两次结果：
结果1: while (left <= right) { ... }  ← 正确
结果2: while (left < right) { ... }   ← 边界条件不同，可能出错

这就是"武无第二"——Coding 赛道上，正确答案只有一个，概率性天然是敌人。

面试重点：temperature 参数控制采样随机性。0→选最高概率 token（确定），1→更随机（有创造性）。代码生成通常设 0~0.3。

3.4 上下文窗口有限

虽然 DeepSeek-V4-Flash 已支持 100 万 Token，但窗口终究有限。更棘手的是：上下文越长，模型对中间信息关注度越低（“迷失在中间”）；Token 消耗与上下文长度成正比，成本线性增长。

3.5 小结：缺陷驱动设计

LLM 缺陷	带来的问题	Harness 应对层
无状态	不记得项目背景和规范	记忆层
无法操作外部	只能"说"不能"做"	工具层
概率性输出	代码质量不稳定	约束层 + 循环校验
上下文有限	无法处理超大项目	上下文管理策略

每一个 Harness 层次，都对应 LLM 的一个结构性缺陷。

---

四、Harness 的核心四层架构

记忆层（Memory Layer）

解决问题：模型无状态。本质是在每次请求时，把模型"该知道但记不住"的关键信息手动带进上下文。

核心载体

项目根目录/
├── CLAUDE.md          ← 项目级记忆（最核心）
├── .claude/
│   ├── settings.json  ← 项目配置
│   └── memory/        ← 持久化记忆文件
└── agent.md           ← Agent 行为约束

CLAUDE.md —— 模型的"导航地图"

它不是代码，而是一份告诉 Agent "这个项目是什么、该怎么做"的约束文档，每次对话自动注入上下文：

# 项目概述
电商后台管理系统，React + TypeScript + Ant Design。

## 技术栈
- 前端：React 18, TypeScript, Ant Design 5.x, Zustand
- 后端：Node.js, Express, PostgreSQL

## 开发规范
- 使用函数组件 + Hooks，禁止 Class 组件
- 状态管理统一用 Zustand，不要引入 Redux
- API 调用统一封装在 /src/api/ 目录下
- 所有组件必须有 TypeScript 类型定义

## 目录结构
- /src/components/ 通用组件
- /src/pages/     页面组件
- /src/api/       API 请求封装
- /src/store/     Zustand store

## 注意事项
- 不要修改 /src/api/client.ts 中的请求拦截器
- 所有表单使用 Ant Design Form 组件，不要手写
- 颜色使用 Design Token，不要硬编码色值

核心原理：服务端仍然无状态，但客户端每次请求时把 CLAUDE.md 拼接到 System Prompt 中，模型就能"看见"这些约束，表现得像"记得"一样。

如何用：在claude 中输入指令 /init， claude 会在根目录创建claude.md 文件

余下三层会在后面的文章继续深入，欢迎订阅这个专栏

---

五、案例驱动：从零构建项目记忆

核心原则：不要急于生成代码，先建立记忆。

5.1 /init：初始化项目记忆

/init 是进入项目后的第一步，扫描项目结构生成初始 CLAUDE.md，包含项目描述、技术栈、开发规范、目录结构。这份文件每次对话自动带上，从根源解决 stateless。

/init   # 在项目根目录执行

5.2 手动创建记忆文件

新项目手动创建 CLAUDE.md：

# 智能客服助手

## 技术栈
- 前端：Vue 3 + TypeScript + Element Plus
- 后端：Python FastAPI
- 数据库：PostgreSQL + Redis

## 编码规范
- 后端 PEP 8 + Black 格式化
- 前端 ESLint + Prettier，Vue 3 Composition API
- 所有 API 接口需 OpenAPI 文档注释
- Git 提交遵循 Conventional Commits

## 目录结构
- /frontend/  /backend/  /docs/  /scripts/

5.3 记忆更新

项目约束不是一成不变的。技术栈升级、规范调整后，重新 /init 确保 Agent 基于最新约束工作。

5.4 Vibe Coding 与记忆

“Vibe Coding”（氛围编程）= 持续用自然语言指挥 AI 写代码。看起来很酷，但没有记忆层，每次对话都是"从零开始"——Agent 不知道项目用什么框架、命名习惯、哪些文件不能动。记忆层让 Vibe Coding 从"纯靠运气"变成"有据可依"。

---

六、全文总结

Harness Engineering 代表的是 AI 工程化从"调 Prompt"到"建系统"的范式跃迁。核心逻辑链：

1. 演进路径：Prompt → Context → Harness，每一步解决前一步的局限
2. 核心比喻：模型是引擎 / 马，Harness 是整车 / 挽具
3. 缺陷驱动设计：无状态→记忆层
4. 记忆层是基石：CLAUDE.md 作为导航地图，/init 建立记忆，持续更新——这是 Harness 的首要切入点

---

七、核心知识点复盘

知识点	总结
Prompt Engineering	研究怎么"说"模型才听——有用但不够
Context Engineering	给模型更多背景信息——比 Prompt 进了一步
Harness Engineering	在模型外面建系统——从"调参"到"建工程"
Stateless	LLM 的 HTTP 本质，每次请求独立——记忆层来补
RAG	检索 → 增强 → 生成，上下文工程典型范式
CLAUDE.md	项目级记忆文件，Harness 记忆层核心载体
/init	初始化/更新项目记忆的命令

---

八、常见问题 / 避坑指南

Q1：CLAUDE.md 应该写多长？

200~500 行。太短覆盖不全，太长吃上下文窗口。原则：只写模型"不知道但应该知道"的关键约束。

⚠️ 别在 CLAUDE.md 堆砌教科书规范（如"驼峰命名"），模型本来就知道。写的是项目特有的——目录结构、技术选型、禁用手法、团队约定。

Q2：/init 生成内容不准确？

/init 是起点不是终点。输出是草稿，必须人工校对和补充，核心部分（技术栈、目录结构、约束）一定确认准确。

Q3：记忆层和 RAG 的区别？

维度	记忆层（CLAUDE.md）	RAG
内容	项目约束、规范、结构	知识库、文档内容
更新频率	低频（项目级）	高频（文档级）
注入方式	每次自动带入	按需检索后注入
典型场景	“这个项目该怎么写”	“这个 API 怎么用”

两者互补，不是替代。

Q4：是不是过度工程化？

200 行脚本不需要。多人协作、长期维护的复杂项目，没有 Harness 就是"裸奔"。适度工程化是对团队生产力的投资。

---

Harness Engineering 中，Memory 最重要。 这是所有上层能力的地基——模型先要知道"你是谁、在哪、该怎么做"，才能开始真正干活。