模型是千里马，Harness 是挽具；模型是引擎，Harness 是整车。两个比喻，同一个逻辑------蛮力需要驾驭，才能变成生产力。
一、从一匹马说起------Harness 这个词到底在讲什么
Harness，中文翻译叫"挽具"。
在古代，它指的是套在马身上的一整套器具：马鞍让你坐稳，缰绳让你控制方向，马镫让你发力，肚带把这一切固定住。这些东西单独看都不起眼，但合在一起决定了你能不能把这匹马的力量用出来。
现在想象你有一匹千里马。
肌肉发达，日行千里，爆发力惊人。但你直接光背骑上去试试？抓不住，坐不稳，被颠得七荤八素，马也不知道你要往哪跑。结果就是：马强得离谱，你哪也去不了。
这恰好是今天我们面对 LLM（大语言模型）的处境。
模型极其智能------写得了代码，推得了逻辑，翻得了语言，画得了图。但是：
- 每次对话结束，它就失忆了
- 它不知道怎么主动去读你的文件、改你的代码
- 同样的问题问两次，答案可能完全不同
- 信息量一大，它就装不下了
智能和高质量交付之间，隔着一条巨大的鸿沟。
Harness Engineering 要做的，就是在模型外面，给它套上那套"挽具"------用工程化的手段把模型的智能驾驭住，让它从"一次性的惊艳"变成"可重复、可依赖的产出"。
这是 Prompt Engineering → Context Engineering → Harness Engineering 这条演化链上，最新也最关键的一环。
二、两个比喻之间的递进------挽具是附件，还是整车？
上面用马和挽具打了一个比方，到这里你可能觉得：Harness 就是给模型加点辅助工具嘛。
不。这个理解还不够。马的比喻只能讲一半。
为什么？因为给马套挽具，马还是那匹马，你加的是配件 。但 Harness Engineering 的实际体量远不止配件------记忆系统、工具编排、流程控制、上下文管理......这些东西绑在一起，不是在模型身上挂几个小零件，而是围绕模型造了一整辆车。
所以这里引入第二个比喻，把它讲完整：
模型是引擎，Harness 是整车。
V8 引擎很猛。但把一台裸引擎扔在地上，它能干嘛？只会轰鸣、发烫。你得给它配上变速箱（动力输出可控）、刹车（知道什么时候停）、仪表盘（能看到当前状态）、底盘和轮子（能真的跑起来）------这一整套才是车。
两个比喻的关系是这样的：
| 马 + 挽具 | 引擎 + 车 | |
|---|---|---|
| 模型是 | 一匹有灵性的千里马 | 一台没有感情的引擎 |
| Harness 是 | 马鞍、缰绳、马镫------套在身上的器具 | 变速箱、刹车、仪表盘------整辆能上路的车 |
| 它在讲什么 | Harness 的角色：控制和引导原始力量 | Harness 的体量：不是配件，而是一套完整的基础设施 |
| 适合什么时候用 | 第一次跟人解释这个概念 | 讨论具体架构和工程落地 |
两套画面，同一个结构：一个裸的力量，外面包一层工程系统，才能稳定地输出价值。 区别只在于，马的画面强调"关系"，车的画面强调"规模"。Harness Engineering 两者兼有------它既是一种关系（驾驭），也是一套规模（四层架构）。
三、从 Prompt 到 Harness------三代范式的演进
如果把 AI 应用开发的方式排一条时间线，大致是这样：
第一代：Prompt Engineering（提示词工程）
核心动作： 写好提示词，让模型一次输出好结果。
典型场景是早期 ChatGPT------你精心措辞一段 Prompt，告诉它"你是资深前端工程师，请用 React + TypeScript 写一个表格组件"。Prompt 写得好，效果就好；Prompt 写烂了，结果也烂。
本质是什么？你靠一张嘴说，赌模型能听懂。 模型的智能直接暴露在用户面前，没有任何中间层。
第二代：Context Engineering（上下文工程）
核心动作： 从外部检索相关信息，塞进上下文窗口，再让模型生成。
典型代表是 RAG（Retrieval-Augmented Generation，检索增强生成）------三个步骤：先检索（Retrieval），再增强上下文（Augmentation），最后生成（Generation）。 Cursor 这类 AI IDE 本质上也是在做上下文工程：它们自动把相关文件、代码片段、项目结构信息塞进上下文，让模型"看到"更多。
本质是什么？你在马耳边播放环境音，让它多了解一些周边信息。 比第一代强，但本质上还是在"给模型喂信息"。
第三代：Harness Engineering（挽具工程）
核心动作： 在模型周围构建一套完整的工程化基础设施。
2025 年下半年，Claude Code 接棒 Cursor 成为 AI Coding 赛道的焦点------这不是一个偶然的产品替换，而是范式切换的信号。在此之前，行业在比"谁家模型更聪明"；在此之后，行业在比"谁家的 Harness 更成熟"。
同一时间轴上的其他信号：
- OpenClaw / Hermes 在办公自动化赛道发力，本质就是把 Harness 思想从 Coding 延伸到 Office
- 腾讯 CodeBuddy 做 Coding 场景的 Harness，WorkBuddy 做办公场景的 Harness
- 微信 + WorkBuddy 的组合，意味着 Harness 不止在开发工具里，还会渗透到超级 App 的工作流中
所有人的方向高度一致：给模型套挽具，造一辆能上路的车。
四、在造车前，先看清引擎的四个先天局限
模型就是那台引擎。在想怎么造车之前，你得先清楚这台引擎本身有什么"毛病"------不是 bug，是设计特征，就像马天生没有方向盘一样。这些特征是 Harness 存在的根本原因。
局限一：无状态（Stateless）
每次对话结束，模型什么都不记得。
今天你跟它聊了一下午，把项目架构讲清楚了，编码规范对齐了，业务逻辑过了一遍。明天打开新对话，它看着你，一脸茫然："您好，请问有什么可以帮您？"
不是你表述不清，是它根本没有记忆器官。每一次对话都是独立事件。
Harness 的对策 → 记忆层。 在外面给它建一个记忆系统，每次对话启动时自动加载。
局限二：无法行动
模型的本职工作是生成文字和图片。它不会自己打开你的文件系统，不会帮你跑命令，不会发 HTTP 请求，不会触发 CI/CD。
单说"读写文件"这种基础操作，要靠工具调用（Function Calling / Tool Use）来桥接。而一个复杂项目需要的远不止这些------MCP 服务集成、Skill 脚本调度、多工具协同......没有统一的管理层，工具越多越乱。
Harness 的对策 → 工具层。 不只是给它工具，更要管好这些工具。
局限三：输出概率性
同样的 Prompt，两次跑出的结果可能完全不一样。
写文章（文无第一）还能接受，风格差异当作多样性。写代码（武无第二）就麻烦了------这次的实现能跑，下次的跑不通；这次的逻辑和上次不一样，你敢合进主干吗？
工程化的底线是可重复性。概率性是底线上的裂缝。
Harness 的对策 → 控制层。 用流程、校验、约束把不确定性关进笼子里。
局限四：上下文窗口有限
模型能同时"看到"的信息有上限。以 DeepSeek-V4-Flash 为例，上下文窗口是 1M tokens------听起来很大，但实际上一个中型项目轻松就能把它撑满。你不能把整个代码库不加筛选地倒进去。
Harness 的对策 → 上下文层。 有策略地筛选、排序、压缩，把窗口用在刀刃上。
四个局限，四层对策。下面是这四层的逐一拆解。
五、Harness 的四层架构
Harness Engineering 不是一个具体框架，也不是某一个工具。它是围绕模型构建的四类基础设施的总称：
arduino
┌────────────────────────────────────────────┐
│ │
│ 🧭 记忆层 │
│ Memory │
│ 解决无状态------让它"记住"该记住的一切 │
│ ────────────────────────────────────── │
│ 🔧 工具层 │
│ Tools │
│ 解决无法行动------给它手脚，也给它工具箱 │
│ ────────────────────────────────────── │
│ 🎯 控制层 │
│ Control │
│ 解决概率性------约束输出，保证可重复 │
│ ────────────────────────────────────── │
│ 📐 上下文层 │
│ Context │
│ 解决窗口限制------聪明地筛选、排序、压缩 │
│ │
└────────────────────────────────────────────┘回到前面的比喻：这四层就是车的主体。引擎（模型）装在这个底盘上，才能跑。
第一层：记忆层（Memory）------解决"鱼的记忆"
模型没有记忆，我们就从外部给它造记忆。
最简洁也最实用的落地方式是文件系统记忆------CLAUDE.md / AGENTS.md。这个文件像一张导航地图，Agent 每次启动时自动加载。里面放什么？
- 这项目是干什么的
- 技术栈和核心依赖
- 编码规范和约定
- 目录结构的关键约定
- 绝对不能碰的禁区
实操：接手新项目的第一件事
不要上来就让 AI 写代码。先用 /init 命令初始化项目的 CLAUDE.md------这一步决定了 Agent 后续每一次对话的"基础认知水平"。如果是全新项目，手动创建这个文件。
每次你发起对话，Harness 会自动把 CLAUDE.md 的内容带上。你不需要再重复解释项目背景。这就是记忆层在起作用------从外部硬生生给无状态的模型补上了"记忆"这一环。
注意： CLAUDE.md 改了（比如技术栈升级），一定要再跑一次 /init 刷新记忆。过时的地图比没有地图更危险。
第二层：工具层（Tools）------给它装上手和脚
模型只会"想"，不会"做"。工具层让它能读写文件、跑命令、查 API、操作浏览器。
但工具多了才是真正的考验。一个复杂项目的 Agent 可能同时挂着十几个 MCP 服务、多个 Skill 脚本、自己写的自定义工具。没有统一管理机制，就像工具箱翻了个底朝天------知道东西在，就是找不到，找到了也用不顺。
所以工具层要解决两件事：
- 接入：让工具能被模型调用
- 编排：让多个工具协同工作，而不是各跑各的
Harness Engineering 区别于 Prompt Engineering 的关键点之一就在这------不光提供工具，更管理工具。
第三层：控制层（Control）------驯服概率性
Vibe Coding（氛围编程）这个词之所以流行，恰恰暴露了问题：你不停用自然语言描述需求，模型不停生成代码，改到"感觉差不多对了"为止。
感觉对了 = 不稳。
控制层要做的就是把"感觉"替换成"机制"：
- Workflow 编排：把复杂任务拆成确定性的步骤链，每一步有明确的输入和输出
- Pipeline 串联：多个 Agent 按固定流程协作，而不是靠一个人口述驱动
- 验证自动化：代码审查（review）、测试运行、类型检查，在输出侧兜底
- 可重复性：同一套任务定义，跑十次出来的结果偏差可控
第四层：上下文层（Context）------把有限窗口用到极致
上下文窗口再大，也经不住"什么都往里塞"。上下文层的工作是：
- 检索增强：PAG 三步走 ------ 先检索（Retrieval）最相关的信息片段，再增强（Augmentation）到上下文中，最后生成（Generation）
- 优先级排序：让最重要的信息排在最前面，信息密度最大化
- 动态裁剪与压缩：对话长了自动做摘要，老信息压缩保留要点，给新信息腾位置
上下文层是离模型最近的一层------它直接决定模型在每个时刻"看到什么"。看到什么，决定了能输出什么。
六、从"Vibe Coding"到"铁路系统"
Vibe Coding 很快乐。你一个人 + 一个模型，聊着天就把功能做出来了。
但它有天花板。规模一上去就撑不住------当你需要稳定地、重复地、有保障地交付软件时，临场发挥是不够的。
Harness Engineering 的思路是反过来的：
不要每次都靠你的临场发挥。去修一条铁路。
铁轨铺好之后，一列列火车按时刻表到达。具体到 Harness 里：
| 铁路系统 | Harness |
|---|---|
| 轨道图 | 记忆层------Agent 知道怎么走 |
| 信号系统 | 工具层------该做什么操作、什么时候做 |
| 调度中心 | 控制层------任务怎么拆、怎么串、怎么收口 |
| 沿途补给站 | 上下文层------在正确的时间给正确的信息 |
你是那个修铁路的人。修好了，马不用自己认路，引擎不用自己找方向。
七、总结：下一个阶段，拼的是挽具
回头看 AI 编程工具这几年的竞争焦点：
- 2023 年 ，大家在比谁 Prompt 写得好------Prompt Engineering
- 2024 年 ，大家在比谁检索精准、上下文喂得巧------Context Engineering / RAG
- 2025-2026 年 ，大家在比谁的 Harness 更完整------Harness Engineering
模型的智能差距正在缩小，头部模型的 Coding 能力越来越接近。四年前大家还在惊呼"AI 竟然能写代码了"，今天这个已经稀松平常。当引擎之间的马力差异不再悬殊，比的就是谁的车造得更好。
Claude Code 能在这轮竞争中脱颖而出，不是因为它背后的 Claude 模型比 GPT 聪明多少------而是 Anthropic 在 Harness 层面下了不可忽视的功夫：CLAUDE.md 文件记忆、Hook 机制、Skill 系统、Workflow 编排、MCP 协议支持......这些不是模型能力，是 Harness 能力。
所以，如果你现在还在纠结"用哪个模型更好"，可以换个问题问自己：
我为我的引擎，造了一辆什么水平的车？
别光读，试一下。 用
/init给你当前的项目生成 CLAUDE.md，观察 Agent 后续对话的表现差异。记忆层是 Harness 四层里最薄但是见效最快的一层------你会体会到"模型有记忆"和"模型失忆"之间那种质的差别。Harness Engineering 不是看会的，是用出来的。