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到HarnessAI工程化的三次跃迁回顾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当聊天机器人而是把它当数字员工来管理。而管理一个员工光给KPIPrompt是不够的你得给他配工位、发电脑、开权限、做培训、写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在合适的时机调用合适的工具MCPModel Context Protocol正在成为这一层的标准化方案。协同层Multi-Agent解决一个模型干所有事的问题。代码生成、代码审查、测试编写、部署运维——让不同的Agent各司其职就像一支工程团队那样协同工作。基础层Model Gateway解决模型依赖问题。不同的任务用不同的模型A模型写代码、B模型做审查、C模型做总结同时做好降级和容灾。这些我会在后续文章里逐一展开感兴趣的朋友可以先点个关注不迷路。八、写在最后Harness不是银弹但它是方向说实话Harness Engineering目前还处于社区共识形成中的阶段——没有权威教科书也没有大厂官宣的标准架构。它更像是一线开发者们用脚投票总结出来的经验合集。但有一点是确定的当LLM的能力进入够用但不够稳的阶段工程化就是唯一的出路。2023年大家都在研究怎么写Prompt2024年大家都在研究怎么做RAG2025年开始你会发现真正能落地的团队都在研究怎么给AI建Harness。你可以从最简单的开始——明天到你项目根目录创建一个CLAUDE.md把你最常对AI重复的那些话写进去。就这一个动作就能让你的AI协作效率提升肉眼可见的一个档次。