2026 年初，OpenAI 在一篇博客里用了一个词——Harness Engineering。然后这个词就出现在各种技术大会的标题里、招聘 JD 里、投资人的 pitch deck 里。
一个新术语火了，通常有两种可能：要么是换了个包装炒冷饭，要么是确实出现了一种新的实践，需要一个名字来锚定它。Harness Engineering 属于后一种。
但我们不从头开始聊。我们先看一段具体的对话。
一段对话里的秘密
假设你正在用 Claude Code 修一个 bug：支付回调接口偶发超时。
你描述了一下现象。然后事情就自动开始了——
它先翻出了回调接口的源码，找到了处理第三方响应的那段逻辑。接着检查了最近的 git 提交，发现上周有人改过超时配置。它又去读了下游支付网关的 API 文档，发现对方建议在生产环境把连接超时设到 30 秒，而当前配置是 5 秒。它把配置改了，跑了单元测试，又跑了一遍回归，都通过了。最后它把改动 commit 了，commit message 写得还挺像回事。
整个过程，你只做了一件事：描述了问题。
这段经历里藏着 Harness Engineering 的全部要素。我们来把它拆开看看。
· · ·
核心引擎：一个会反思的循环
首先，AI 不是一口气干完所有事的。
它的工作方式是一个循环：推理→动手→看结果→再推理→再动手，直到问题解决或者它觉得自己搞不定了。
读源码（动手）→ 发现超时配置是 5 秒（观察）→ 查文档确认合理值（动手）→ 判断需要改成 30 秒（推理）→ 修改配置（动手）→ 跑测试看有没有副作用（观察）→ 提交（动手）
这个循环在学术界有个名字叫 ReAct（Reasoning + Acting），最早是 Google Brain 在 2022 年提出的。它的核心洞见很简单：把推理和行动交织在一起，比"先想完再干"或者"先干完再想"都靠谱。
ReAct 相关的论文和实现这几年已经很多了，这里不展开。只需要记住一点：循环是 Harness Engineering 的心跳。没有这个循环，大模型就是一个只说不练的参谋；有了这个循环，它就变成了能动手干活的执行者。
推理分析 · 判断 · 决策执行读 · 写 · 改 · 调观察日志 · 结果 · 反馈LLM大脑ReAct 循环：推理 → 执行 → 观察 → 再推理，大模型驱动每一步的走向
但如果你用过早期的 AI 编程工具，你知道光有这个循环是不够的。它们也会读文件、改代码、跑命令，但经常在几步之后就"迷失"了——忘了项目规范、改错了不相关的文件、或者卡在一个地方反复兜圈。
所以 Harness Engineering 要解决的问题，就不只是"让 AI 能动起来"，而是让 AI 动起来之后不至于搞砸。
四层脚手架：让循环跑稳
如果 ReAct 循环是发动机，那 Harness Engineering 就是围绕这台发动机搭建的一整套车辆控制系统。它由四个子系统组成。
1. 给模型植入"项目记忆"
你的项目有一套独特的背景知识：用了什么框架、遵循什么规范、哪些文件是雷区、历史上踩过哪些坑。这些东西不会自动出现在模型的上下文里。
解决办法很朴素：把这些规则写成文件，放在项目根目录。比如 CLAUDE.md 或者 .cursor/rules。每次调用模型时，工具框架自动把这些规则注入到上下文里。
这样一来，无论对话进行到第几轮，模型都"记得"这个项目的基本约定。这解决的是持续性问题——模型不会聊着聊着就忘了你是谁、你在做什么。
2. 让模型看到自己犯的错
模型改完代码之后，怎么知道改对了？
不是靠模型自己判断——模型对自己的输出缺乏可靠的自我评估能力。真正的做法是外部验证：lint 检查、类型校验、单元测试、端到端测试。Model 提交修改，工具框架自动跑这些检查，把报错信息原样送回给模型。
这样做的好处是，纠错信号来自真实的执行环境，而不是模型的主观判断。这解决的是可靠性问题——模型犯了错，能自己发现并修正，不需要你盯着。
3. 把大任务切成小步骤
面对一个复杂需求——比如"给系统加上用户行为埋点"——模型没法一口吃掉。它需要先把任务拆开：选 SDK、设计事件 schema、埋前端、埋后端、搭数据管道、做验证。
这层编排逻辑通常不靠模型自己凭空拆，而是靠外部工具辅助（比如 Spec-Kit 这类规格驱动工具），或者靠框架内置的规划能力。每完成一步，验证一下，再进入下一步。
这解决的是复杂度问题——大任务不会被模型草率地"半成品交付"。
4. 给模型装上一套工具
模型需要能触碰真实世界：操作文件系统、执行命令行、发 HTTP 请求、查数据库、操纵浏览器。每一种能力对应一个具体的工具接口。
2024 年底 Anthropic 推出的 MCP（Model Context Protocol），就是试图把这些工具接口标准化——不同的外部服务只要实现同一个协议，模型就能即插即用。
这解决的是能力边界问题——模型能做的事情，不再受限于它训练数据里的知识，而是受限于它接入的工具数量。
驾驭工程的四层结构围绕 ReAct 循环的四套支撑系统IV执行层文件操作终端命令API 调用数据库查询浏览器操控MCP 插件……III编排层需求拆解子任务调度验收检查流程管理Spec-Kit / SDDII反馈层lint 检查类型校验单元测试错误回传自动修复I记忆层项目规范技术约定禁区声明CLAUDE.md / RulesReAct 循环引擎
这几层不是 Harness Engineering 的"官方定义"——这个概念本身也没有标准化。但它们概括了当下主流 AI 编程工具在模型之外所做的大部分工程工作。你使用 Cursor、Claude Code、GitHub Copilot 时的体验差异，很大程度上就来自这四层实现方式的不同。
回到那条进化线
Harness Engineering 不是凭空跳出来的。它有一个清晰的来路。
最早，人们琢磨的是怎么跟模型说话。 把模糊的指令变成精确的指令，加入角色设定、输出格式、正反示例。这一步后来被叫做 Prompt Engineering。它解决的核心问题是：模型能听懂你在说什么。
然后，人们发现光说话不够，还得喂材料。 模型需要足够的背景信息才能给出靠谱的回答。但模型的"工作台"（上下文窗口）是有限的，于是出现了检索增强、摘要压缩、信息编排等技术。这一步被叫做 Context Engineering。它解决的核心问题是：模型手里有足够的信息来做判断。
现在，人们在做的事情是让模型能持续行动。 不仅听得懂、有信息，还要能动得了手、能检查自己的成果、能按计划推进。这就是 Harness Engineering。它解决的核心问题是：模型能自主地把一件事从头到尾干完。
三层不是替代关系。提示词设计、上下文管理，仍然是驾驭工程的一部分——就像你会开车了，不代表你不需要会看路标。
眼下你能做什么
不用等什么"Harness Engineering 最佳实践"白皮书出来。你现在就可以开始做的，只有一件成本极低但回报极高的事：
认真写项目的规则文件。
把下面这些写进 CLAUDE.md 或 .cursor/rules：
- 项目简介和技术栈（一句话就行）
- 代码规范（缩进、命名、文件组织——三五行足够）
- 红线（哪些模块绝对不能乱动）
- 改完代码要跑什么检查（一条命令）
就这么点。写好之后，你再去用 Claude Code 或 Cursor，会发现它的表现判若两物——因为它终于"知道自己在哪、在干什么"了。
如果你愿意再多花一点时间，可以试试 Spec-Kit 这类工具。它们帮你把一个模糊的想法（"我想加个功能"）解构成一串可追踪的任务，每一步都有明确的验收条件。这背后是一套叫做 SDD（Spec-Driven Development）的方法论，核心理念朴素得很：想清楚再动手——只不过"想清楚"这一步，现在也可以让 AI 参与进来。
最后
Harness Engineering 这个名字，概括的是 AI 工具过去两年最实质性的进化：从"给你一个答案"走向"帮你把事办了"。
大模型提供的是智力。智力本身不产生结果——它需要手脚、需要计划、需要记性、需要检查自己的能力。把这些工程组件搭起来、调通了，智力才能真正落地为产出。
下次有人在讨论里提到这个词，你不需要背定义。你只需要想一件事：
"我的 AI 工具，除了聪明之外，还缺什么？——缺什么，就给它搭什么。"
