LLM的“缰绳“之争：从Prompt Engineering到Harness Engineering，AI应用开发范式升级

如果说Prompt Engineering是教会AI说话，那么Harness Engineering就是教会AI干活。前者让你惊艳，后者让你交付。

写在前面

你有没有遇到过这样的场景：明明在Claude或ChatGPT里把代码调得好好的，一接入项目就各种"翻车"------上下文对不上、风格不一致、工具用不来、输出不稳定？

我过去半年在几个AI Coding项目里反复踩坑，从Cursor到Claude Code再到开源的OpenClaw，经历了从"Prompt写得好就能为所欲为"到"光靠Prompt真的不够"的完整心路历程。

这篇文章不是讲某个具体框架怎么用，而是想和你聊聊一个正在悄然兴起的新范式------Harness Engineering。它不是某个大厂推出的新工具，而是社区在大量实践中沉淀出来的一套"AI应用工程化"方法论。

说白了就是：怎么给LLM这匹野马套上缰绳，让它稳定、可控地干活。

一、从Prompt到Harness：AI工程化的三次跃迁

回顾AI应用开发这几年的演变，我把它归纳为三个阶段：

阶段	核心关注	典型实践	一句话概括
Prompt Engineering	怎么写好提示词	Few-shot、Chain-of-Thought、Role Prompting	教AI怎么回答
Context Engineering	怎么给AI喂好上下文	RAG（检索增强生成）、动态记忆窗口、知识库挂载	教AI参考什么资料
Harness Engineering	怎么让AI稳定干活	Memory管理、MCP工具编排、Skill调度、Multi-Agent协同	教AI怎么工作

你可能对RAG已经很熟悉了------先检索再生成，本质上是在解决"模型知识不够新/不够专"的问题。但现在我们面临的不只是"知识"问题，而是结构性缺陷问题。

RAG解决的是"模型不知道什么"，Harness解决的是"模型做不好什么"------前者是知识的边界，后者是能力的边界。

2025年下半年，Claude Code带着"AI程序员"的概念出圈，Cursor全力押注Agent模式，开源社区冒出OpenClaw、Hermes这类办公自动化项目，腾讯也在CodeBuddy和WorkBuddy上同时发力------你会发现，这些产品不约而同地在做同一件事：

不再把LLM当聊天机器人，而是把它当"数字员工"来管理。

而管理一个员工，光给KPI（Prompt）是不够的，你得给他配工位、发电脑、开权限、做培训、写SOP------这就是Harness要做的事。

二、LLM的"四宗罪"：为什么光靠Prompt不够？

在聊Harness具体包含什么之前，我们先要承认一个事实：当下的LLM有四条根深蒂固的"结构性缺陷"，这不是靠"把Prompt写得更好"能解决的。

缺陷一：Stateless（无状态）

每次对话结束，模型什么都不记得。你昨天跟它对齐了半小时的项目规范，今天打开新会话，它一脸懵："什么项目？什么规范？"

有人说"我用的是Claude Project啊，有Project Knowledge"------但本质上那只是把文档塞进System Prompt里，模型本身依然没有"记忆"能力。

缺陷二：无法主动操作外部世界

模型只能生成文本（或图片、音频），但它不能自己打开浏览器、不能修改文件、不能发HTTP请求、不能操作数据库。

它像一位只动嘴不动手的顾问，能给你方案，但不能替你执行。

要让AI真正干活，必须给它配工具。但问题来了：一个复杂项目可能涉及读写文件、执行命令、调用API、操作浏览器、发送通知......工具一多，怎么管理？怎么让AI在合适的时机用合适的工具？

缺陷三：概率性输出（非确定性）

同样的输入，每次输出都可能不同。写文案的时候这叫"创意多样性"，写代码的时候这叫"随机翻车"。

尤其在Coding场景，"文无第一，武无第二"------代码是"武"，要的就是确定性和可复现性。一个每次重构都改风格的AI，你不太敢让它上生产。

缺陷四：上下文窗口有限

即便DeepSeek-V4宣称1M tokens超长上下文，它也不是无限的。而且上下文越长，成本越高、响应越慢、注意力越分散。

真实项目的代码库动辄几十万行，你不可能每次都把全部代码塞进去。

这四个缺陷不是模型的"bug"，而是它的"feature"------Transformer架构天生如此。

Harness要做的事情，就是在这四条基本性质之上，搭建一套工程系统，让模型完成它原本无法独立完成的任务。

三、Harness是什么？一个比喻帮你秒懂

想象你有一匹血统纯正的骏马（LLM），它爆发力惊人（生成能力），智商在线（推理能力），但你直接骑上去，它可能把你甩下来------因为它没有经过"驾驭系统"的改造。

真正让马"work"的，是给它配上马鞍、缰绳、马镫、嚼子 ------这些东西统称为Harness（挽具）。

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

Harness Engineering不是某一个具体的框架或工具，而是围绕模型构建的一整套基础设施的总称 ，目的是让模型的能力可以被稳定、可控、可重复地驾驭。

四、Harness的四层架构（核心内容）

业内对Harness的划分还没有统一标准，基于我的实践和观察，我把它总结为四层架构：

复制代码

┌─────────────────────────────────────────────┐
│           ④ 协同层（Multi-Agent）            │
│       ------ 多个Agent各司其职，分工协作          │
├─────────────────────────────────────────────┤
│           ③ 工具层（Tools / MCP）            │
│       ------ 读写文件、执行命令、调用API          │
├─────────────────────────────────────────────┤
│           ② 记忆层（Memory）                 │
│       ------ 项目规范、技术决策、历史上下文        │
├─────────────────────────────────────────────┤
│           ① 基础层（Model Gateway）          │
│       ------ 模型路由、负载均衡、降级切换          │
└─────────────────────────────────────────────┘

今天这一篇，我们先重点聊记忆层（Memory）------因为它是所有Harness架构的基石，也是社区里"最接地气、最快能见效"的一层。后面三层我会在后续文章中展开。

五、记忆层：Stateless模型的"长期记忆体"

5.1 记忆层解决什么问题？

模型Stateless的特性导致了一个很尴尬的局面：每次对话都是"初见"。

假设你在维护一个前端项目，技术栈是Vue 3 + TypeScript + Vite，代码规范用ESLint + Prettier，组件库用Ant Design Vue。

你第一次跟AI说这些，它能听懂。但第二天新开一个会话，它全忘了。你又要重新说一遍："用Vue 3，别给我生成React代码，TypeScript严格模式......"

这不叫"智能助理"，这叫"金鱼记忆助理"。

5.2 最简单的记忆方案：项目根目录放个"说明书"

社区里最早流行起来的方案其实特别朴素------在项目根目录放一个CLAUDE.md或AGENTS.md文件。

这个文件的核心作用就是：每次对话时，自动把这份文件的内容作为System Prompt的一部分带上。

说白了就是给AI发一张"入职卡片"：你是谁、你在什么项目里、有什么规矩、有什么禁忌。

拿我之前做的一个极简项目举例------一个Node.js加法工具，CLAUDE.md长这样：

复制代码

<!-- 项目规则 - 极简Node加法工具 -->

## 1. 技术栈
- 语言：Node.js 原生JavaScript，仅使用内置模块
- 禁止引入任何第三方npm包

## 2. 目录规范
- 入口文件：index.js
- 所有代码写在index.js中，不拆分文件

## 3. 代码要求
1. 函数必须加单行注释
2. 代码极简，拒绝冗余
3. 输出结果用console.log清晰打印
4. 必须提供调用示例
5. 全面使用ES6+语法，如发现非ES6+代码直接修改

## 4. 输出约定
- 写完代码后附带运行命令：node index.js

有了这个文件，每次AI生成的代码都会自动遵循"不加第三方包、不拆分文件、ES6+、带注释、附运行命令"这一套约束。

实测效果：之前需要反复在对话里强调的规则，现在一次定义、永久生效。不是说AI每一次都会完美遵守，但它至少拥有了"知道该怎么做的上下文"。

5.3 进阶操作：/init 初始化命令

很多AI Coding工具（如Cursor、Claude Code）现在都支持自定义Slash Command。社区里一个非常流行的实践是 /init命令：

当你在一个新项目里执行/init时，AI会：

扫描项目目录结构
识别技术栈（读package.json、requirements.txt等）
分析现有代码风格
自动生成一份CLAUDE.md（或更新已有文件）
把项目的核心约束、目录结构、技术决策全部记录进去

这样一来，记忆的建立不再是纯手工活儿，而是半自动化的。

每当CLAUDE.md发生变更（比如新增了技术栈、调整了目录结构），再次执行/init就能让记忆"保鲜"。

5.4 记忆层还可以更丰富

除了项目规则，记忆层可以承载更多结构化的信息：

记忆类型	示例内容	作用
约束规则	"禁止使用any类型"	告诉AI什么不能做
技术决策	"状态管理用Zustand而不是Redux"	保持决策一致性
架构约定	"API层统一放在services/目录"	保持代码组织一致
已知问题	"登录模块有遗留bug，暂不修改"	避免AI踩坑
团队成员	"前端负责人是张三，后端是李四"	方便AI@相关人员
常用命令	"npm run dev启动，npm run build构建"	方便AI给出可执行指令

记忆层的本质，是把"只存在于开发者脑子里的隐性知识"转化成"AI可读取的显性规则"。

六、一个完整的记忆层实践流程

假设你从零开始一个新项目，我建议按这个流程建立记忆层：

Step 1：项目初始化时，先写一份"骨架级"CLAUDE.md

不用太细，先把技术栈、目录结构、基本约束定下来。如果连这些都不确定，用/init让AI帮你生成初稿。

Step 2：每次关键决策后，更新记忆

比如你决定用Prisma作为ORM、决定用JWT做鉴权、决定用Docker部署------这些决策一定要写进记忆文件。否则第二天AI可能给你推荐TypeORM + Session + K8s，驴唇不对马嘴。

Step 3：遇到AI"翻车"时，反向更新记忆

如果AI某次生成了一段不符合规范的代码，修复完之后，把"为什么会翻车"抽象成一条新规则加进去。

比如AI经常在Vue 3项目里写Vue 2的Options API，你可以加一条规则：

复制代码

"本项目使用Vue 3 Composition API，禁止使用Options API写法"

记忆不是一次写完就结束的，它是随着项目演进动态生长的"活文档"。

Step 4：定期审视记忆质量

如果发现AI开始"无视"某些规则，可能不是AI的问题，而是记忆文件太长、AI注意力分散了。这时候需要精简和重组记忆内容，把最关键的规则放在最前面。

七、记忆层之后，还有三层

讲完记忆层，简单预告一下另外三层：

工具层（Tools / MCP）：解决"模型无法操作外部世界"的问题。文件读写、命令执行、浏览器操作、API调用......如何让AI在合适的时机调用合适的工具？MCP（Model Context Protocol）正在成为这一层的标准化方案。
协同层（Multi-Agent）：解决"一个模型干所有事"的问题。代码生成、代码审查、测试编写、部署运维------让不同的Agent各司其职，就像一支工程团队那样协同工作。
基础层（Model Gateway）：解决"模型依赖"问题。不同的任务用不同的模型，A模型写代码、B模型做审查、C模型做总结，同时做好降级和容灾。

这些我会在后续文章里逐一展开，感兴趣的朋友可以先点个关注，不迷路。

八、写在最后：Harness不是银弹，但它是方向

说实话，Harness Engineering目前还处于"社区共识形成中"的阶段------没有权威教科书，也没有大厂官宣的标准架构。它更像是一线开发者们"用脚投票"总结出来的经验合集。

但有一点是确定的：当LLM的能力进入"够用但不够稳"的阶段，工程化就是唯一的出路。

2023年大家都在研究"怎么写Prompt"，2024年大家都在研究"怎么做RAG"，2025年开始，你会发现真正能落地的团队都在研究"怎么给AI建Harness"。

你可以从最简单的开始------明天到你项目根目录创建一个CLAUDE.md，把你最常对AI重复的那些话写进去。就这一个动作，就能让你的AI协作效率提升肉眼可见的一个档次。