Harness Engineering：用“确定性“驾驭AI的“不确定性“

上一篇 SDD 系列收尾时留了一句话“如何驾驭 AI 来赋能整个软件开发周期将是另外一个值得深入探讨的话题。” 到现在有将近一个月没更新期间除了偷懒五一跑高速添堵之外主要的原因是这个问题没怎么想透。SDD 解决了怎么让 AI 尽可能准确地完成一个开发任务的问题但整个开发周期呢这个月一直在薅那稀疏的头发也一直在实际项目里摸索着。从今年3月份开始有一个词开始反复出现 —— 不管是在顶级博客、行业文章、集团大会还是内部分享汇报里这个词叫Harness Engineering。有意思的是每个人所说的 Harness Engineering 好像听起来都不太一样。一、不确定性的来源变了SDD 系列解决的是一个相对小的问题怎么让 AI 确定性地完成一个任务——用 Spec 约束意图再由 AI 验证 AI 生成的结果。初步的实践数据看起来还行。但一个任务搞定了整个开发周期呢测试谁来写验证谁来做架构怎样确保代码腐化谁来管如何持续改进这些问题 SDD 没回答因为它们本来就不在单任务的范围内。回头想想这些焦虑的本质可能指向同一个问题软件工程一直在跟不确定性作斗争但这次不确定性的来源变了。•软件工程从来都不是天然确定的—— 需求会变、并发会冲突、网络会抖动、分布式系统会脑裂。软件工程的本质工作恰恰是用工程化手段锁、类型系统、测试、CI/CD、一致性协议把这些不确定性驯服为可预测的确定性结果。说白了就是同样的输入 同样的初始状态 必须得到同样的输出。• 而LLM 的本质是概率性输出——同一个 prompt 跑两次结果可能不同。以前的不确定性在外面需求变化、运行时环境、网络故障你用工具去管它们。但现在不确定性跑到了生产线本身上——写代码的那个家伙AI它自己就是概率性的。AI 不是不靠谱而是“靠谱的概率”还不够高。Harness Engineering 就是想把这个概率逼近 100% 的一整套工程实践。这意味着我们手里那套老工具箱——锁、类型系统、CI/CD、一致性协议——并没有失效但不够用了。因为它们是为管住运行时的不确定性设计的而现在你要管住的是生产过程本身的不确定性。需求的探索、原型的设计、代码的产出、测试的生成执行这些流程的主体从人变成了 AI——你需要为这个新的不确定性来源设计新的工程手段。举个真实的例子我用 AI agent 来做 Code Review。第一次它找到2-3个需要修改的安全问题。可是我重启一个 chat session同样让它对同一个改动做 Code Review这次它没给出安全问题而是给了一些重构优化的意见。这就是缺少 Harness 的代价每一次成功的 AI 输出都感觉是在开盲盒。二、那 Harness 到底是什么对于 Harness 的定义有很多个人觉得比较清晰的是 LangChain 提出的这个广义的公式Agent Model HarnessModel 提供智能推理、理解、生成Harness 是 Model以外的一切——工具、规则、编排、权限、反馈回路。德国的 AI 码农 Philipp Schmid 在1月份的博客上发表了《The importance of Agent Harness in 2026》, 他在文中将 Agent Harness 与计算机做了一个类比计算机AI 编程作用CPULLM提供算力/智力内存Context Window工作记忆、上下文操作系统Harness资源调度、权限管理、错误恢复应用程序Agent面向用户的产品没有操作系统的 CPU 什么也干不了——它能计算但不知道该算什么、结果放哪、出错了怎么办。没有 Harness 的 LLM 也是一样它能生成代码但不知道该遵循什么规范、怎么验证自己的输出、哪些文件不该碰。所以 Harness Engineering 不是“更高级的 Prompt Engineering”Prompt 只是 Harness 的一小块。它也不是“多接几个 MCP 工具”工具只是 Harness 的另一小块。Harness Engineering 是一整套让 AI 的不确定性被系统工程方式“管起来”的实践。三、一张图让工具各就各位如果你跟我一样觉得“Harness 是 Model 以外的一切”这个定义还是太泛了那 Thoughtworks 的 Birgitta Böckeler 在 Martin Fowler 网站上发的《Harness engineering for coding agent users》给了一个非常好用的坐标系。她把 harness 的组成拆成两个维度第一个维度控制的时机•Guides前馈/Feedforward——在 AI 动手之前就缩小它的错误空间。比如 AGENTS 文件、Instructions、MCP 工具、架构文档、设计实现限制。本质是让它尽量别犯错。•Sensors反馈/Feedback——在 AI 产出之后验证结果并触发自我修正。比如 Linter、单元测试、end-to-end 测试、AI Code Review、运行日志。本质是犯了错马上抓住甚至要记下来避免相同的问题再次出现完成一个闭环。第二个维度执行的方式•Computational确定性工具—— CPU 跑的快、便宜、结果可靠。Type checker、structural test、coverage report。跑一千次结果一样。•Inferential推理性工具—— GPU 跑的慢、贵、结果有概率性。LLM-as-judge、AI code review、语义分析。有判断力有创造力但不保证每次一致。把这两个维度组合起来就得到一个 2×2 矩阵这张图的价值在于我们日常做的每一件事——写 instruction、配 linter、跑测试、做 code review——基本都能在这四个格子里找到自己的位置。当我们发现某个象限是空的那有可能就是我们的 Harness 还有缺口的地方。四、为什么每个人讲的 Harness 都不太一样有了以上的定义和坐标系之后再回头看开头那个现象——“人人都在讲 Harness Engineering但听起来像在讲不同的东西”——好像就没那么困惑了因为大家站在矩阵的不同象限里说话。•CEO/CTO关心的是AI 产能能否规模化、如何进行组织的转型——他们在讲 Guides 的战略层面Harness 模板化、组织结构的转型升级。•BA/PM焦虑的是AI 能不能把业务需求写对——他们在讲 Inferential Guidesbusiness context、原型设计、验收标准、业务规则结构化•开发/架构师在意的是怎么让 AI 少犯低级错误别改烂架构——他们在讲如何利用确定性和不确定性的工具来提供前馈和反馈linter、CI、project context、AI Code Review•QA纠结的是AI 生成的测试到底能不能信——他们在讲 Behaviour Sensors端到端验证、行为漂移检测•AI 工具厂商包装的是我们内置了 planning subagents context management——他们在讲产品化的 Harness 组件当把大家的视角放到同一张 2×2 矩阵上大家就能相互 GET 到对方想表达的意思了。Harness Engineering 不是某一个角色的专属领域它是一整个控制系统——每个角色负责其中一个环节。这里还有一个问题值得思考如果 AI 在干活那人干什么Thoughtworks 的 Kief Morris 提出了一个很好的区分人的角色正在从in-the-loop亲自干活变成on-the-loop设计控制系统。以前你是写代码的人现在你是设计“让 AI 正确写代码”的人。你不再检查每一行输出而是设计一套控制系统让问题在你看到之前就被拦截。这就是 Harness Engineering 的本质工作不是替 AI 干活而是设计“让 AI 干对活”的系统。五、Harness 不是一劳永逸的写到这里我想补充一个容易被忽略的点。大多数人听到“Harness”的第一反应是搭好了就可以一直用。把 instruction 写好、把 agent / skill 设计好、把 CI 跑起来 —— 然后坐等 AI 干活。但实际情况恰恰相反。AI 的能力在快速演进AI Coding Agent 的能力也在进化。3个月前你需要用 linter 规则拦住的编译错误今天的模型可能已经不会犯了。半年前你需要在 prompt 里写三段话解释的架构约定今天的 agent 可能从代码结构里就能推断出来。这意味着 Harness 不是一成不变的 ——旧的 Harness 要不断拆除新的 Harness 要不断前移。我把这个过程理解为持续向左 harness• 当模型能力提升某些 Sensors事后检查变得多余 —— 因为 AI 已经不会犯那类错了• 当 agent 框架进化某些 Guides事前指导可以简化 —— 因为 agent 自己能获取上下文了• 但新的风险和新的能力边界会出现你需要在更前面、更高层设置新的控制就像操作系统一样 —— 早期 操作系统 要管内存分配的每一个字节后来有了虚拟内存、有了垃圾回收这些底层 harness 被拆掉了。但 操作系统 并没有消失它在更高层面容器编排、安全沙箱、权限管理继续发挥作用。Harness Engineering 不是搭一次就不动的基建项目而是一个随 AI 能力同步演进的持续实践。Harness 一直都在只是 Harness 的位置在不断左移。写在最后回到开头那个矛盾软件工程需要确定性的输出而AI 天生不确定。Harness Engineering 不是要消灭这个矛盾——概率性输出是目前 LLM 的本质特征消灭不了——而是用工程化的手段把不确定性围起来、管起来、逼退到可接受的范围。有了这个框架之后接下来希望能把几个关键方面逐一展开Context Engineering—— 让 AI 看见你的项目系统地管理 AI 在项目中能获取到的所有上下文。AI 驱动的测试—— 谁来验证 AI 的输出探索能否让 AI 生成的测试验证 AI 生成的代码。反馈闭环—— 让 Harness 越跑越聪明。不是配好了就不动而是每一次 AI 的使用都在改进整个系统。首发于微信公众号 二牛技术参考源清单1. Birgitta Böckeler (Thoughtworks) —— Harness Engineering for Coding Agent Users, 2026.042. Birgitta Böckeler —— Context Engineering for Coding Agents, 2026.023. LangChain —— The Anatomy of an Agent Harness, 2026.034. Kief Morris (Thoughtworks) —— Humans and Agents in Software Engineering Loops, 2026.035. OpenAI —— Harness Engineering: Leveraging Codex, 2026.02