最近圈子里突然冒出一个新词，叫 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 在代码领域犯了错，系统可以立刻打回，改完以后再次验证。这个循环可以高速运转，不需要人盯着。

但这里有个容易忽略的前提：验证基础设施本身要足够好。没有测试，拿什么验证？没有 Lint 规则、架构约束，怎么自动执行？过去，这些工程实践被称为“最佳实践”，大家都知道重要但可以拖着。Agent 时代不一样了，代价完全不同。一个没有约束的 Agent，会以机器速度、全天候地在每一个 PR 里重复同样的错误——因为没有被写下来的规矩，它永远意识不到，也永远学不会。

几个被反复验证的设计模式

落地 Harness Engineering，有几个设计模式已经被反复验证过。

第一个是渐进式信息披露。不要把所有文档一次性喂给 Agent。好的做法是写一份精准的入口文档，只告诉 Agent 最关键的导航信息，详细规则按模块分类存放，Agent 按需加载。这样既避免了上下文窗口的压力，也迫使你把规范整理得更清晰。

第二个是沙箱隔离。每个 Agent 任务在独立的工作区执行，互不干扰。改坏了直接丢弃，失败成本接近于零。这让 Agent 可以大胆试错。

第三个是仓库就是真理来源。架构规范、质量标准、命名约定，全部写进代码仓库。不要靠口头传达，不要靠聊天消息。Agent 读仓库就能获取所需的上下文。

第四个是机械化执行约束。架构约束不要靠 Code Review 里的文字建议传达，而是编码进 Lint 规则。违反了就自动编译不过，PR 就不让合进去。人是心软的，可以被说服，但规则不会——这是约束真正有效的唯一方式。

核心竞争力的转变

当 Agent 承担了越来越多的代码生成工作，工程师的核心竞争力就要从“能写出什么”，转向“能评估什么”，以及更深一层——“能设计什么样的系统，让正确的代码可以可靠地生成和验证”。

这不是说写代码能力不重要了。而是说，能清晰定义问题、能建立有效验证机制、能把团队的架构直觉转化成可执行规则的工程师，与不具备这些能力的工程师，将产生越来越大的生产力差距。

Harness Engineering 说到底，就是关于怎么把人的判断力固化成系统，让它不再依赖某一次对话、不再依赖某一个人在场，而是变成一个可以持续运转的基础设施。

这才是 AI 时代工程师真正在做的事——不是写代码，而是设计一个能让 AI 可靠工作的系统。