Harness Engineering:给 AI 套上“缰绳“,让大模型真正能干活的工程哲学

📅 2026/7/2 5:05:45
Harness Engineering:给 AI 套上“缰绳“,让大模型真正能干活的工程哲学
文章目录一、AI 数年历史从 Prompt 到 Harness 的演进之路1.1 Prompt Engineering —— 学会和模型说话1.2 Context Engineering —— 不止是一句 Prompt1.3 Harness Engineering —— 比上下文工程更大的格局二、Harness Engineering 是什么2.1 行业背景2.2 两个比喻三、LLM 的四大结构性缺陷3.1 无状态Stateless3.2 无法主动操作外部世界3.3 输出是概率性的3.4 上下文窗口有限3.5 小结缺陷驱动设计四、Harness 的核心四层架构记忆层Memory Layer核心载体CLAUDE.md —— 模型的导航地图五、案例驱动从零构建项目记忆5.1 /init初始化项目记忆5.2 手动创建记忆文件5.3 记忆更新5.4 Vibe Coding 与记忆六、全文总结七、核心知识点复盘八、常见问题 / 避坑指南模型是 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上下文工程模型还是那个模型但给它更充分的上下文让它做出更准确的判断。RAGRetrieval-Augmented Generation先从知识库检索相关内容Retrieval再作为增强信息喂给模型Augmented最后生成结果Generation。这是上下文工程的典型范式。1.3 Harness Engineering —— 比上下文工程更大的格局上下文工程的核心问题仍然是怎么告诉模型更多信息。Harness Engineering 问的是一个更大的问题怎么在模型外面建造一整套系统让模型能力可以被稳定、重复地驾驭阶段核心问题手段Prompt Engineering怎么说模型才听优化提示词Context Engineering给模型什么背景信息上下文注入、RAGHarness Engineering怎么让模型稳定干活记忆 / 工具 / 循环 / 约束Harness 不再是把 Prompt 提升一个档次——它比 Prompt 大一个量级。二、Harness Engineering 是什么2.1 行业背景2025 年下半年AI Coding 进入工程化时代Claude Code接棒 Cursor重新定义 Agent 工作流OpenClaw / Hermes切入办公自动化让 AI 操作桌面软件腾讯 CodeBuddy深耕 CodingWorkBuddy进军办公自动化微信 WorkBuddy意味着 Agent 进入国民级应用这些产品的共同点它们都不是裸调大模型都在模型外面套了一层厚重的工程架构。这层架构就是 Harness。2.2 两个比喻比喻一想象一匹千里马力量惊人。但让它能耕田、拉车、作战的不是马本身——而是挽具Harness缰绳、马鞍、笼头、肚带。LLM 就是那匹马很智能但智能不等于能稳定产出好的输出。比喻二模型是 V8 引擎Harness 就是装着引擎的整车。引擎再牛没有变速箱任务调度、刹车安全约束、仪表盘可观测性这车没法上路。Harness 要做的事很明确研究怎么在模型外面套上好的挽具让模型能力可以被稳定、重复地驾驭。这不是某个具体框架而是围绕模型构建的几类基础设施的总称。三、LLM 的四大结构性缺陷要理解为什么需要 Harness先要理解模型本身缺什么。3.1 无状态StatelessLLM 是基于 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 PrettierVue 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到建系统的范式跃迁。核心逻辑链演进路径Prompt → Context → Harness每一步解决前一步的局限核心比喻模型是引擎 / 马Harness 是整车 / 挽具缺陷驱动设计无状态→记忆层记忆层是基石CLAUDE.md 作为导航地图/init建立记忆持续更新——这是 Harness 的首要切入点七、核心知识点复盘知识点总结Prompt Engineering研究怎么说模型才听——有用但不够Context Engineering给模型更多背景信息——比 Prompt 进了一步Harness Engineering在模型外面建系统——从调参到建工程StatelessLLM 的 HTTP 本质每次请求独立——记忆层来补RAG检索 → 增强 → 生成上下文工程典型范式CLAUDE.md项目级记忆文件Harness 记忆层核心载体/init初始化/更新项目记忆的命令八、常见问题 / 避坑指南Q1CLAUDE.md 应该写多长200~500 行。太短覆盖不全太长吃上下文窗口。原则只写模型不知道但应该知道的关键约束。⚠️ 别在 CLAUDE.md 堆砌教科书规范如驼峰命名模型本来就知道。写的是项目特有的——目录结构、技术选型、禁用手法、团队约定。Q2/init 生成内容不准确/init是起点不是终点。输出是草稿必须人工校对和补充核心部分技术栈、目录结构、约束一定确认准确。Q3记忆层和 RAG 的区别维度记忆层CLAUDE.mdRAG内容项目约束、规范、结构知识库、文档内容更新频率低频项目级高频文档级注入方式每次自动带入按需检索后注入典型场景“这个项目该怎么写”“这个 API 怎么用”两者互补不是替代。Q4是不是过度工程化200 行脚本不需要。多人协作、长期维护的复杂项目没有 Harness 就是裸奔。适度工程化是对团队生产力的投资。Harness Engineering 中Memory 最重要。这是所有上层能力的地基——模型先要知道你是谁、在哪、该怎么做才能开始真正干活。