约束越多AI 越自由Harness Engineering先说一件让我有点尴尬的事前段时间我在用一个 AI 编程工具做一个功能迭代任务不算复杂就是把几个模块串联起来做一个数据处理的流程。我把需求描述得详细觉得这次 AI 肯定能一把搞定然后它就开始写了写得相对流畅代码一行一行往外蹦我坐在旁边看着还挺爽的感觉效率起飞了大概二十分钟后它停下来跟我说任务完成我点开一看好家伙前半部分写得挺好后半部分接口对不上有个核心函数根本没实现测试一个都没跑然后它就这么宣布完成了我当时第一反应是这个模型不行得换个更好的这个想法现在回头看是完全错误的其实这不是模型的问题这个认知转变对我来说花了挺长时间因为”换更好的模型”这个直觉实在太根深蒂固了我用 AI 工具形成了一个固定的思维模式效果不好就是模型不够强等下一代模型出来就好了。逻辑在早期是有一定道理的模型能力确实是最主要的变量2026 年这个情况就不一样了有个团队拿同一个模型以Terminal Bench 2.0 的基准测试上跑了两次唯一的区别是第二次改了模型外面那套系统——约束、验证流程、反馈机制这些。结果分数从 52.8% 跳到了 66.5%全球排名从三十名开外直接进了前五这个实验数据让我印象巨深。模型一个参数都没变这件事让我重新思考了一个问题花了这么多时间盯着模型本身是不是搞错了方向我踩过的典型错误在讲 Harness Engineering 具体怎么做之前先说说我自己踩过的坑因为这几个错误真的很典型相信不少人都有过第一个错误把所有指令塞进一个大文件我之前的习惯是维护一个长篇的 AI 指令文档把所有规范、注意事项、约定全部写进去觉得这样 AI 就能”记住”所有东西了结果是这个文档越来越长越来越难维护AI 开始不知道哪条是真正重要的而且这个大文件会占掉大量上下文窗口把真正有用的任务信息挤出去当所有事情都被标注为“重要”的时候就等于什么都不重要实际上就是把那个大文件改成一张地图只有一百行左右每行都是指向更深层文档的指针。AI 从地图出发按需深入而不是被一本百科全书淹没第二个错误觉得约束会限制 AI 的创造力我们担心给 AI 套太多规则会让它变成一个只会按图索骥的执行机器失去灵活性但实际情况是反过来的。当 AI 面对一个完全开放的解空间Solution Space它会浪费大量计算资源在死胡同里徘徊每个方向、可能性都试一试最后给你一个看起来很全面但“范”的结果当你给它明确的边界它反而能更快收敛到正确的解决方案。边界不是笼子边界是跑道第三个错误AI 说完成了就以为真的完成了这个我已经吃过亏了。AI 有一个很根深蒂固的倾向就是在任务看起来差不多完成的时候就停下来然后报告完成AI不会主动去跑测试、验证功能、检查边界情况。因为没有人告诉它必须这样做我在做 OpenClaw 的时候就是围绕这个问题专门设计了一套执行逻辑先框定边界再进行执行。也就是说在 AI 开始干活之前先把”什么叫完成”定义清楚把验证条件写进去靠系统强制后来我的做法是需要在系统里强制规定在 AI 宣告任务完成之前必须跑完整的验证流程。不验证不允许退出什么是 Harness Engineering我第一次听说 Harness Engineering 的时候大概是今年二月朋友发给我一篇文章 Harness engineering: leveraging Codex in an agent-first world 说有个团队用 AI 写了一百万行代码全程零人工吹牛吧这是我的第一反应然后我把文章仔细看了一遍发现不是吹牛是真的。三个工程师五个月一百万行代码交付了一个真实产品有真实用户在用能正常发布、部署、出 bug、被修复全部由 AI 在那套系统里完成效率大概是传统人工的十倍但我注意到一个细节文章里说工程师不写代码之后80% 的时间花在了什么上不是写 Prompt不是审代码是构建那套围绕 AI 的约束系统这个细节让我停下来想了一段时间这套系统就叫 Harness它不是一个工具不是一个框架更不是一个 Prompt 模板。它是一套围绕 AI Agent 运行的系统包括约束、反馈、验证和持续清理这几个部分。2026 年初这套做法有了一个正式的名字Harness Engineering。“Harness”这个词来自马具——缰绳、马鞍、嚼子那一整套用来驾驭马的装备。AI 模型就像一匹蛮力十足但方向感不太行的马跑得快但容易跑偏。Harness 的作用就是把它的力气引到正确方向上。Harness Engineering 的核心部分这套系统大概有四个核心部分。第一是知识系统AI 要在一个复杂项目里干活它得知道整体架构是什么、各模块的职责是什么、API 约定是什么。这些信息不是靠一个大文件给它而是靠一套分层的文档结构。一个简短的入口文件作为地图指向各个领域的详细文档AI 按需取用。更关键的是这套文档要跟代码保持同步代码变了文档跟着变甚至可以专门跑一个”文档维护 Agent”来做这件事。第二是架构约束你要把架构规则写成机器可执行的检查而不是靠人记、靠 Code Review 来维护。比如你规定模块之间的依赖方向是单向的这条规则不是写在文档里的是写成了自动检查规则任何违反的代码都过不了流程无论是人写的还是 AI 写的。更聪明的做法是把错误信息写得很详细不只说”你违反了规则 X”而是解释”为什么这个规则存在、正确的做法是什么”。这样 AI 遇到错误的时候能自己理解为什么错了然后自己修正。第三是强制验证循环在 AI 准备说”完成”之前系统拦截它要求它跑完整的验证——测试要跑应用要启动如果有界面变化要截图检查。就是这一个改动让前面提到的那个团队基准测试分数从 52.8% 跳到了 66.5%。第四是熵管理AI 生成代码的时候有一个很坏的习惯就是复现代码库里已有的模式包括坏的模式。如果你的代码库里有一段写得很烂的代码AI 在旁边写新功能的时候可能会模仿那种写法然后坏的模式就扩散了。解法是建立一套定期运行的清理机制后台有专门的 Agent 周期性扫描代码库找到偏离规范的地方自动提交修复。技术债务不要等积累到崩溃才还小额高频持续偿还效果比一次性大清理好得多。Harness Engineering 是不是终极解法不是。做了对比实验没有 Harness 的情况下AI 写得很快但大概每隔几个功能就会出现一次架构偏移模块之间的依赖开始乱文档和代码开始脱节测试覆盖率开始下降工程师每周五要花 20% 的时间专门清理这些问题。有了 Harness 之后AI 的单次任务速度稍微慢一点因为要跑验证但架构偏移几乎消失了文档保持同步测试覆盖率稳定工程师不再需要专门的清理时间。但 Harness 也有它的边界。它对”可验证的任务”效果最好——代码能跑、测试能过、结果能量化。对于那些需要主观判断的任务比如内容质量、用户体验Harness 能给你结构但给不了你答案。所以更准确的说法是Harness Engineering 是一个让 AI 在复杂系统里长期可靠运行的前提条件而不是让 AI 变得更聪明的方法。它解决的是”怎么让 AI 不乱跑”不是”怎么让 AI 跑得更快”。回到最开始的问题回到最开始那件让我尴尬的事如果当时我有一套 Harness那件事会怎么发生AI 还是会开始写代码。但在它准备说”任务完成”之前系统会拦截它要求它跑测试、检查接口、验证核心函数是否实现。它会发现后半部分的问题然后自己去修。它不会在任务没完成的时候宣布完成因为系统不允许。这就是”约束越多AI 越自由”的意思。不是说约束让 AI 变得更聪明而是约束让 AI 的聪明用在了正确的地方不会浪费在无效的徘徊和虚假的完成上。如何开始实践如果你现在想开始做点什么不需要一上来就搭一套完整的 Harness可以从两件小事开始最小可行的起点就是两件事给你的项目写一个 AGENTS.md 把你希望 AI 遵守的规则写进去不用长一百行以内每一行对应一个你希望 AI 不要再犯的错误在你的工作流里加一个验证步骤任何任务在宣告完成之前必须跑验证哪怕只是最基本的冒烟测试。从这两件事开始每次 AI 犯一个新类型的错误就回头加一条规则。Harness 不是一次性设计好的它是一点一点长出来的。不需要多复杂但会让你用 AI 做事情的效果明显不一样AI 已经是千里马了这一点毋庸置疑。但千里马没有缰绳跑得再快也到不了目的地