最近有个词特别火，叫 Harness Engineering。很多人第一次听到这个词都会懵，这到底是什么意思。
其实这个概念背后藏着一个更大的问题，就是当 AI 已经可以写代码的时候，工程师到底还要做什么。
一匹有力量的马，为什么跑不动
先说个比方。
假设你有一匹马，这匹马力气很大，跑得也快。但光有力气没用，你得给它套上缰绳、马鞍、马蹬，这些东西加在一起才能让马的力量真正为你所用。
这套装备有个专门的词，叫 Harness。
大模型也是一样。
现在的 GPT、Claude 这些模型，能力确实很强，上知天文下知地理。但能力强不代表输出就靠谱。你问它同一个问题，今天给你一个答案，明天可能又是另一个答案。它不记得上次说了什么，也不知道你的项目有什么规矩，更没法主动去操作外部世界。
所以 Harness Engineering 要做的，就是在模型外面套一层系统，让模型的能力可以被稳定地、可重复地使用。
这不是简单地优化提示词那么简单，而是要搭建一整套基础设施。
四层结构，让 AI 从会说变成会做
Harness Engineering 不是一个具体的工具，而是围绕模型构建的几类基础设施的总称。核心有四层。
第一层是记忆层。
模型本身没有记忆，每次对话结束就什么都忘了。记忆层要做的就是把模型需要知道的东西写下来，结构化存放。比如在代码场景里，你会看到 claude.md 或者 agents.md 这样的文档，里面记录着项目的关键约束和规则。
这不是百科全书，而是一张导航地图，只告诉 AI 最关键的信息。
第二层是执行层。
模型只能生成文字，没法真正做事。执行层给它提供了操作外部世界的能力，比如执行代码、运行浏览器、调用 API。同时还会提供沙箱环境保护，让 AI 可以大胆试错，改坏了直接丢掉，不影响主分支。
第三层是反馈层。
这是整个 Harness 框架里最核心的部分。
模型的输出是概率性的，你没法保证它每次都对。但反馈层可以通过测试、Linter、CI 流水线这些工具，对模型的产出进行确定性验证。代码生成出来，测试立刻跑一遍，不通过就自动打回重试，通过了才进入下一步。
这个回路能闭合的根本原因在于，代码虽然生成是概率性的，但验证是确定性的。你不需要模型每次都对，只需要有足够好的验证手段就够了。
第四层是编排层。
复杂任务不可能交给一个模型完成，需要拆成多个子任务，多个 Agent 分工协作。编排层负责协调这些 Agent 的状态，让系统可以处理远超单次对话能力上限的工程任务。
为什么代码领域是突破口
AI 在很多领域都有应用，但 Harness Engineering 在代码场景发展最快、最系统。
原因就在于一个不对称性。
代码生成是概率性的，但验证是确定性的。
编译器不会因为你今天心情好就放过一个语法错误，测试也不会因为你态度端正就假装通过。这种确定性让反馈回路可以完全自动化。
相比之下，写一篇文章好不好、设计一张海报美不美，这些很难用机器自动判断。但这段代码能不能通过 100 个测试用例，30 秒内就能给你答案。
这意味着 Agent 在代码领域犯错了，系统可以立刻打回，Agent 改完以后系统可以再次验证。这个循环可以高速运转，不需要人盯着。
但这里有个容易忽略的前提，就是验证基础设施本身要足够好。
没有测试拿什么验证，没有 Lint 规则、架构约束怎么自动执行。过去这些工程实践被称为最佳实践，大家都觉得重要但可以拖。Agent 时代不一样了，代价完全不同。
一个没有约束的 Agent，会以机器速度、全天候地在每一个 PR 里重复同样的错误。因为没有写下来的规矩，它永远意识不到，也永远学不会。
几个被反复验证的设计模式
落地 Harness Engineering，有几个设计模式已经被反复验证过。
第一个是渐进式信息披露。
不要把所有文档一次性喂给 Agent。好的做法是写一份精准的入口文档，只告诉 Agent 最关键的导航信息，详细规则按模块分类存放，Agent 按需加载。这样既避免了上下文窗口的压力，也迫使你把规范整理得更清晰。
第二个是沙箱隔离。
每个 Agent 任务在独立的工作区执行，互不干扰。改坏了直接丢弃，失败成本接近于零。这让 Agent 可以大胆试错。
第三个是仓库就是真理来源。
架构规范、质量标准、命名约定，全部写进代码仓库。不要靠口头传达，不要靠聊天消息。Agent 读仓库就能获取所需的上下文。
第四个是机械化执行约束。
架构约束不要靠 Code Review 里的文字建议传达，而是编码进 Lint 规则。违反了就自动编译不过，PR 就不让合进去。人是心软的，可以被说服，但规则不会。这是约束真正有效的唯一方式。
核心竞争力的转变
当 Agent 承担了越来越多的代码生成工作，工程师的核心竞争力就要从能写出什么，转向能评估什么，以及更深一层，能设计什么样的系统让正确的代码可以可靠地生成和验证。
这不是说写代码能力不重要了，而是说能清晰定义问题、能建立有效验证机制、能把团队的架构直觉转化成可执行规则的工程师，与不具备这些能力的工程师，将产生越来越大的生产力差距。
Harness Engineering 说到底，就是关于怎么把人的判断力固化成系统，让它不再依赖某一次对话，不再依赖某一个人在场，而是变成一个可以持续运转的基础设施。
这才是 AI 时代工程师真正在做的事。
不是写代码，而是设计一个能让 AI 可靠工作的系统。
