Harness Engineering 是什么？AI 编程工程化的三次进化

导读：如果你关注 AI 编程，大概率已经被 "Harness Engineering" 刷屏了。这篇文章帮你理清它到底在说什么、跟提示词工程和上下文工程什么关系、以及大厂和社区为什么都在聊它。

2026 年上半年，AI 编程圈冒出来一个词——Harness Engineering。一开始我以为又是哪个团队造的新轮子，结果越看越发现，这事儿还真不是造概念。

先讲个我自己的经历。去年我用 Claude Code 做一个全栈项目，最开始只靠写提示词——把需求说清楚，让 AI 写代码，看起来挺顺畅。但做到第三个功能的时候出问题了：AI 开始"忘记"前面定好的代码规范，同一个组件写了三遍，还都是不同风格的。我花了半个下午修它留下的烂摊子，修完心想：问题不在模型不够聪明，在我没给它搭好干活的环境。

后来我才知道，我踩的这个坑，就是 Harness Engineering 要解决的问题。

这篇文章不讲具体操作——我不会带你一步步搭一个 Harness。我要做的是帮你理清楚：Harness 到底是什么、它从那两任「前任」（提示词工程和上下文工程）那里继承了什么、五大核心模块各自解决什么问题、以及那些大厂和社区大佬们是怎么说的。

一、Harness Engineering 到底是什么？

Harness Engineering 不是什么新发明，它是把成熟软件工程实践系统化地套用到 AI 编程上的一套方法论。

"Harness" 这个词的原意是「马具」——缰绳、马鞍、嚼子，整套装备用来驾驭一匹强壮但不太可控的马。这个比喻很刻意：AI 模型就是那匹烈马，力气大、跑得快，但没有 Harness 它不知道往哪跑、什么时候该停。

Harness（AI 驾驭工程）：围绕 AI 模型搭建的完整工程体系，包括规则文件、工具链配置、任务编排、测试反馈和质量护栏。你可以理解为「给 AI 搭的软件开发工作台」。

为什么 2026 年突然火了？

Harness 这个词的走红有三根引线。

第一根，LangChain 的实验数据。 他们在 2025 年底做了一个对比：同一个模型、同一套基准测试，只优化模型外层的 Harness（规则、工具、检查流程），编码基准排名直接从 30 名开外冲到了前 5。这个结果太直观了——模型没变，环境一变，产出天差地别。搜索关键词：LangChain SWE-bench experiment 2025。

第二根，OpenAI 的内部实践。 OpenAI 在 2026 年初的一篇工程博客里公开了他们用 Harness 做内部工具开发的细节：一个 3 人团队，靠 Harness 体系引导 AI 生成了上百万行代码，最终产品已经在内部上线使用。他们总结的原话大意是：不是模型让你高效，是你围绕模型搭的那套东西让你高效。

第三根，Mitchell Hashimoto 的正式命名。 HashiCorp 联合创始人、Terraform 之父 Mitchell Hashimoto 在 2026 年 2 月的一篇文章里正式提出了 "Harness Engineering" 这个术语并给出了系统化框架。以他在基础设施领域的声量，这篇文章直接把这个概念推到了台前。

随后 Anthropic、Salesforce等公司和机构也陆续发布了相关文章。到了 2026 年中，行业基本形成了一个共识：

决定 AI 编程效率的，早已不是模型强不强——2026 年中的主流模型，推理能力对大多数开发任务来说都够用了。真正拉开差距的，是你给模型配的那套工程环境。

二、三代演进：两任「前任」和一个「现任」

很多人以为 Harness 是 2026 年突然冒出来的。其实从 2022 年 ChatGPT 上线那天起，整个行业就已经在这条路上了——只是每个阶段叫不同的名字。

Harness Engineering 不是替代提示词工程和上下文工程，而是把它们纳入了一个更大的体系。 这俩「前任」并没有退休，它们只是换了个身份继续干活。

1）提示词工程（2022～2024）：让 AI 听懂人话

提示词工程（Prompt Engineering）：通过设计输入文本的结构和内容来引导大模型产生期望输出的技术。你可以理解为「怎么跟 AI 说话它才听得懂」。

这个阶段的典型技巧：设定角色（「你是一个资深前端工程师」）、约束输出格式（「只返回 JSON」）、用思维链让模型一步步推理、给几个示例让它照葫芦画瓢。

提示词工程解决的核心问题是：AI 能说话了，但不太听指挥。 这一阶段，大家发现写好提示词确实能让 AI 的输出质量提升一大截。

但提示词有两个明显的天花板。第一，提示词再长也塞不进项目的全部背景——一个工程项目的上下文远比一个 prompt 框能装的要多；第二，提示词只能管「这一次对话」，没法让 AI 跨会话记住你的项目规范。

于是上下文工程上场了。

2）上下文工程（2025）：在对的时候喂对的信息

上下文工程（Context Engineering）：系统化管理 AI 在推理时可获取的信息——包括项目规则、历史决策、相关代码和外部知识。你可以理解为「AI 的项目背景档案管理」。

提示词工程问的是「怎么跟 AI 说话」，上下文工程问的是「AI 说话之前，它脑子里该装什么」。

这个阶段出现了几个标志性实践：AGENTS.md 和 CLAUDE.md 规则文件（把项目背景写成 AI 能读的文档）、RAG 检索增强生成（让 AI 自己去查资料）、上下文窗口管理（压缩、摘要、分层加载，让 AI 不"断片"）。

上下文工程解决的核心问题是：AI 知道怎么做事了，但它不知道这个项目是什么、前一个人做了什么。

但它也有天花板：即便 AI 有了完整的上下文，它还是可能把任务搞砸——因为信息齐了，不代表执行靠谱。这就引出了 Harness。

3）Harness Engineering（2026）：让 AI 持续靠谱地干完一整件事

上下文工程管的是「给 AI 什么信息」，Harness 往前走了一步，管的是「给了信息之后怎么确保 AI 不乱来」。

除了规则和上下文，Harness 还关心：大任务怎么拆成小步骤、每一步做完怎么验证、出错了怎么自己修、代码质量怎么不随着迭代慢慢下滑。

三者是层层包含的关系：

业界后来总结了一个公式，我觉得很贴切：

Agent = 模型 + Harness

模型只有推理能力，Harness 赋予它行动能力、约束条件和反馈机制。没有 Harness 的模型只是一个"超级聊天机器人"，套上 Harness 之后才是一个能干活、能检查、能自我纠错的 AI 工程师。

三、Harness 的五大核心模块

Harness 听起来挺大，拆开看其实不复杂。它要解决的，就是 AI 干活时会遇到的五个经典问题。有项目经验的人会发现，这五个模块跟传统软件工程的最佳实践一脉相承——只不过现在你是在给 AI 搭这些东西，而不是给人搭。

1、上下文架构：帮 AI 建立项目认知

AI 不是人，它的"记忆"就是上下文窗口里的内容。 上下文架构要做的就是系统化管理这些内容。

核心思路是分层加载 + 按需索引。别把几千行规则塞进一个大文件，AI 会迷失的。OpenAI 团队分享过他们的做法：AGENTS.md 只写大概 100 行的摘要和索引，类似一个目录，指向 docs/ 目录下的详细设计文档。AI 需要什么自己去读什么。

我自己的经验也验证了这一点。我最早写 CLAUDE.md 的时候恨不得把所有细节都塞进去，结果 AI 表现反而变差了——它抓不住重点。后来改成一个索引文件加分层文档，效果好了一大截。

2、工具与执行：给 AI 装上手脚

模型本身只能输出文本。 如果想让 AI 真正干活，就得通过工具调用让它能操作环境：终端执行命令、文件系统读写代码、浏览器测试页面。

在这个基础上，MCP（Model Context Protocol）：Anthropic 发布的模型上下文协议，让大模型通过统一接口调用外部工具和数据源。你可以理解为「AI 的 USB-C 接口」——插什么设备就能干什么活。

3、任务编排：大任务拆小，小任务并行

AI 的上下文空间是有限的——一把梭搞大需求，搞到一半上下文就"脏"了，前面定好的约束慢慢被冲淡。

任务编排的核心就两条：Plan Mode（先出方案确认再动手写代码）和 SubAgents（互不依赖的小任务并行执行）。这跟我们传统开发做需求拆分、前后端并行是一个道理。

每做完一个功能记得沉淀文档。这样哪怕新开一个对话窗口，让 AI 读文档就能快速找回上下文，不用从头来。

4、反馈循环：让 AI 自检自查

AI 写完代码会自信满满地说"完成了"，你一运行全是 Bug。 这是因为模型天然缺乏自我纠错能力——它不知道自己写错了。

反馈机制就是补上这个缺口：Linter 查语法、自动化测试验功能、Browser Use 做端到端测试。测试不通过 → AI 读报错 → 分析原因 → 修复 → 再测。这就是 Harness 最核心的闭环。

可能有人会问：AI 自己检查自己，检查不出来怎么办？

当然不是全靠 AI 自检。Harness 里人的角色不是消失了，而是变了——你不再一行行看代码，而是去看 AI 的测试报告和架构合规性检查结果。AI 搞不定的问题，人再介入纠偏。Harness 不是"无人驾驶"，是"辅助驾驶"——把人的精力从「写代码」转移到「审代码」和「定规则」。

5、架构护栏：防止代码在迭代中腐败

AI 生成代码有个特点——它会模仿仓库里已有的代码风格，包括烂代码。 同样的逻辑写三遍也不懂拆成函数，时间一长技术债越滚越大。

架构护栏的做法跟我们传统项目的 Code Review 和 CI 检查一脉相承：写专门的架构 Linter（比如禁止 UI 层直接调数据库层）、配 Pre-commit Hooks 自动拦截不合规代码。OpenAI 还搞了套"垃圾回收"机制——定期让 AI 扫描代码库，自动提修复 PR 来偿还技术债。

五个模块不是独立运作的——上下文架构告诉 AI "项目是什么"，任务编排决定"怎么一步步做"，工具执行赋予"动手能力"，反馈循环确保"做对了没有"，架构护栏防止"做着做着做歪了"。它们互相咬合，缺一环整个体系都会漏。

四、大厂和社区怎么看？

Harness 这件事之所以不是一阵风，是因为推它的不只是某个公司——从大模型厂商到开源社区到投资机构，都在往同一个方向用力。

OpenAI：Harness 让 3 人团队产出百万行代码

前文提过，OpenAI 在工程博客中公开了内部实践：3 个工程师靠 Harness 体系引导 AI 产出了上百万行代码，产品已上线。他们强调的不是模型能力，而是 「模型外面那层工程体系」决定了最终产出质量。 搜索关键词：OpenAI engineering blog Harness internal tools 2026。

Anthropic：Humans steer, Agents execute

Anthropic 没有高调喊 "Harness Engineering" 这个术语，但 Claude Code 的产品设计本身就是一套完整的 Harness 实践——CLAUDE.md 规则文件、Plan Mode、SubAgents、Skills 技能包。在工程团队的访谈中，他们把核心理念概括为一句话：

"Humans steer, Agents execute"——人类掌舵，AI 执行。

这句话精准概括了 Harness 的核心哲学：人的角色从"写代码的人"变成了"搭体系的人"。 搜索关键词：Anthropic Claude Code engineering blog 2026。

Mitchell Hashimoto：Agent 放大人已有的能力

Mitchell 在提出 Harness Engineering 的那篇文章里有一个观点我很认同——Agent 不会让一个不会编程的人变成工程师，但会让一个会编程的工程师变成 10 个工程师。Harness 的本质是杠杆，杠杆的长度取决于你已有的工程能力。 搜索关键词：Mitchell Hashimoto Harness Engineering blog。

社区共识

到 2026 年中，社区基本达成了几条共识：

• 模型能力已经够用了——以 2026 年中的主流模型水平，大部分开发任务的瓶颈不在推理能力，在工程环境。
• Harness 的差距就是产出的差距——同样的模型给两个团队，Harness 搭得好的那组效率可以差 5 到 10 倍。
• Harness 不是一键魔法——它需要人持续维护和迭代，跟传统工程基础设施一样会腐化，也需要持续投入。

五、Harness 不是什么——常见误解

讲完 Harness 是什么，也得说说它不是什么。新概念往往容易被过度解读。

误解一：Harness 替代了提示词工程

不替代。 好 Harness 的前提是好提示词——你把规则写进 AGENTS.md，本质上就是在写提示词，只不过形式变成了结构化文档。区别是提示词工程关注「单次对话怎么说」，Harness 关注「跨对话持续怎么说」。提示词是地基，Harness 是在地基上盖楼。

误解二：搭好 Harness 就能一键生成产品

不能。 Harness 解决的是可靠性和效率问题，不是创意和需求理解的问题。如果有人跟你说"搭一套 Harness，输入一句话就能出产品"，你可以直接划走。Harness 让 AI 从"能聊天"变成"能干活"，但它不能让 AI 从"能干简单活"变成"能干复杂活"——后者还需要人的技术判断、架构设计和对需求的理解。

误解三：Harness 是另一种低代码

完全不是。 低代码是把工程逻辑藏到拖拽界面后面，给不会写代码的人用的。Harness 是让 AI 理解和遵守工程逻辑，目标用户是会用工程思维搭体系的开发者。两者的受众和目标南辕北辙。

可能有人会问：我一个个人开发者，需要搞 Harness 吗？

需要，但不是全套。 如果你是个人开发者、只做小项目，不需要搞复杂的架构护栏和多 Agent 互审。但至少做好这两件事：第一，写好 AGENTS.md / CLAUDE.md——这是最便宜、回报最高的 Harness 实践，十分钟的投入换后续几小时的纠错；第二，做完功能让 AI 自己跑测试验证——这是最简单、最有效的反馈循环。哪怕只做这两件事，AI 的输出质量也会有可感知的提升。

六、所以到底怎么写好 Harness？

写 Harness 不是写代码，是搭体系。以下是几条我在实践中反复验证过的原则。

三条核心原则

原则一：从规则文件开始。 这是 Harness 的"Hello World"。一个几十行的 CLAUDE.md，写清楚项目技术栈、代码规范和禁止事项，门槛极低但收益立竿见影。我每次开新项目第一件事就是写这个，五到十分钟的投入换后续几小时的纠错时间。

原则二：让 AI 自证它完成了任务。 别说"你帮我优化一下"——AI 没办法验证"优化"到底算不算完成。要说"你改完后跑一遍测试套件，全部通过才算完"。Harness 的所有机制都是建立在「可验证」三个字上的。

原则三：把 Harness 当成项目的一部分来维护。 AGENTS.md 会过时、Linter 规则需要更新、测试用例会不够覆盖。Harness 不是一次性配置，它跟你写的业务代码一样需要持续迭代。在我这边，每迭代三个功能就会让 AI 检查一遍规则文件是否需要更新——这是从一次线上事故里学来的教训。

结尾

Harness Engineering 说到底是把一个朴素的道理系统化了：如果你想用好一个强大的工具，你的精力不只要花在工具本身上，更要花在使用工具的方式和环境上。

从提示词工程到上下文工程再到 Harness，本质上就是同一个方向的一步步深入——从"说清楚"到"给够信息"再到"搭好体系"。这俩前任没有退休，它们一起组成了现在的 Harness。

至于 Harness 值不值得你投入时间——我的看法是：理解它的思路比学某个具体工具更重要。 工具会变、框架会迭代，但"怎么系统地驾驭 AI"这件事，在看得见的未来里只会越来越重要。