Harness Engineering 是什么？AI 编程工程化的三次进化 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 它不知道往哪跑、什么时候该停。HarnessAI 驾驭工程围绕 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提示词工程20222024让 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。3Harness Engineering2026让 AI 持续靠谱地干完一整件事上下文工程管的是「给 AI 什么信息」Harness 往前走了一步管的是「给了信息之后怎么确保 AI 不乱来」。除了规则和上下文Harness 还关心大任务怎么拆成小步骤、每一步做完怎么验证、出错了怎么自己修、代码质量怎么不随着迭代慢慢下滑。三者是层层包含的关系业界后来总结了一个公式我觉得很贴切Agent 模型 Harness模型只有推理能力Harness 赋予它行动能力、约束条件和反馈机制。没有 Harness 的模型只是一个超级聊天机器人套上 Harness 之后才是一个能干活、能检查、能自我纠错的 AI 工程师。阶段核心问题标志性实践活跃期提示词工程怎么让 AI 听懂需求角色设定、思维链、Few-shot20222024上下文工程怎么给 AI 对的信息AGENTS.md、RAG、上下文分层2025Harness Engineering怎么让 AI 持续靠谱交付工具调用、任务编排、反馈循环、架构护栏2026三、Harness 的五大核心模块Harness 听起来挺大拆开看其实不复杂。它要解决的就是 AI 干活时会遇到的五个经典问题。有项目经验的人会发现这五个模块跟传统软件工程的最佳实践一脉相承——只不过现在你是在给 AI 搭这些东西而不是给人搭。1、上下文架构帮 AI 建立项目认知AI 不是人它的记忆就是上下文窗口里的内容。上下文架构要做的就是系统化管理这些内容。核心思路是分层加载 按需索引。别把几千行规则塞进一个大文件AI 会迷失的。OpenAI 团队分享过他们的做法AGENTS.md 只写大概 100 行的摘要和索引类似一个目录指向docs/目录下的详细设计文档。AI 需要什么自己去读什么。我自己的经验也验证了这一点。我最早写 CLAUDE.md 的时候恨不得把所有细节都塞进去结果 AI 表现反而变差了——它抓不住重点。后来改成一个索引文件加分层文档效果好了一大截。2、工具与执行给 AI 装上手脚模型本身只能输出文本。如果想让 AI 真正干活就得通过工具调用让它能操作环境终端执行命令、文件系统读写代码、浏览器测试页面。在这个基础上MCPModel Context ProtocolAnthropic 发布的模型上下文协议让大模型通过统一接口调用外部工具和数据源。你可以理解为「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 这件事之所以不是一阵风是因为推它的不只是某个公司——从大模型厂商到开源社区到投资机构都在往同一个方向用力。OpenAIHarness 让 3 人团队产出百万行代码前文提过OpenAI 在工程博客中公开了内部实践3 个工程师靠 Harness 体系引导 AI 产出了上百万行代码产品已上线。他们强调的不是模型能力而是「模型外面那层工程体系」决定了最终产出质量。搜索关键词OpenAI engineering blog Harness internal tools 2026。AnthropicHumans steer, Agents executeAnthropic 没有高调喊 “Harness Engineering” 这个术语但 Claude Code 的产品设计本身就是一套完整的 Harness 实践——CLAUDE.md 规则文件、Plan Mode、SubAgents、Skills 技能包。在工程团队的访谈中他们把核心理念概括为一句话“Humans steer, Agents execute”——人类掌舵AI 执行。这句话精准概括了 Harness 的核心哲学人的角色从写代码的人变成了搭体系的人。搜索关键词Anthropic Claude Code engineering blog 2026。Mitchell HashimotoAgent 放大人已有的能力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 不是写代码是搭体系。以下是几条我在实践中反复验证过的原则。维度传统 AI 编程Harness Engineering项目规则靠对话窗口每次重申AGENTS.md 写一次跨会话复用任务执行丢大需求让 AI 一把梭Plan Mode 出方案 → 确认 → 小步执行工具能力只让 AI 输出文本配终端、文件系统、浏览器、MCP 扩展质量验证肉眼检查 AI 的输出Linter 自动化测试 E2E 验证代码防腐写完了事烂了就烂了Pre-commit Hook 定期架构扫描三条核心原则原则一从规则文件开始。这是 Harness 的Hello World。一个几十行的 CLAUDE.md写清楚项目技术栈、代码规范和禁止事项门槛极低但收益立竿见影。我每次开新项目第一件事就是写这个五到十分钟的投入换后续几小时的纠错时间。原则二让 AI 自证它完成了任务。别说你帮我优化一下——AI 没办法验证优化到底算不算完成。要说你改完后跑一遍测试套件全部通过才算完。Harness 的所有机制都是建立在「可验证」三个字上的。原则三把 Harness 当成项目的一部分来维护。AGENTS.md 会过时、Linter 规则需要更新、测试用例会不够覆盖。Harness 不是一次性配置它跟你写的业务代码一样需要持续迭代。在我这边每迭代三个功能就会让 AI 检查一遍规则文件是否需要更新——这是从一次线上事故里学来的教训。结尾Harness Engineering 说到底是把一个朴素的道理系统化了如果你想用好一个强大的工具你的精力不只要花在工具本身上更要花在使用工具的方式和环境上。从提示词工程到上下文工程再到 Harness本质上就是同一个方向的一步步深入——从说清楚到给够信息再到搭好体系。这俩前任没有退休它们一起组成了现在的 Harness。至于 Harness 值不值得你投入时间——我的看法是理解它的思路比学某个具体工具更重要。工具会变、框架会迭代但怎么系统地驾驭 AI这件事在看得见的未来里只会越来越重要。