Harness Engineering-驾驭者工程-AI编程进行AI治理和大规模工程化阶段

大家好，我是人月聊 IT。

今天准备聊一下 AI 治理和 AI 编程大规模工程化方面的一个话题。起因是前段时间 OpenAI 发表了一个实践案例，谈到由 3 个人经过 5 个月的时间，完全借助 Codex 编程工具，上线了一个上百万行代码的产品级项目。该项目基本上全部采用 Vibe Coding的模式，工程师没有手写一行代码，AI 自己完成了代码的编写、审核审计，包括相关问题的处理并完整上线。

Harness Engineering的基础概念

基于此，OpenAI 提出了一个关键词叫“Harness Engineering”，即“驾驭者工程”。“Harness”这个词如果单纯从英文解释，它有两个含义：

一个是名词，指马具、马鞍；另一个是动词，指驾驭、控制。当我看到“Harness”这么一个概念的时候，第一反应就是：为什么在原来已经有了提示词工程、上下文工程的基础上，又要推出一个“驾驭者工程”？这个东西究竟是一个全新的事物，还是说原来我们对于 AI 编程相关概念的发展和演进？

刚好网上另一篇文章举了一个形象的比喻：

如果我们拿电脑来比喻，对于 AI 大模型，它更多的是你的 CPU；而我们原来谈到的类似于上下文工程、提示词工程，它更多的是内存；现在谈的“Harness”，就是你这个电脑的操作系统。我们要真正地从“用 AI”变到变成“AI 的指挥官”，这就是驾驭者工程谈到的最核心的内容。

讲到这个地方，大家可能还是不容易理解什么叫“Harness”，它究竟跟原有的提示词工程、上下文工程究竟是什么样的区别？

所以我们刚好就用马具、马鞍来做一个形象的比喻。首先来讲什么叫提示词工程，简单来讲就是类似于“喊话模式”，你吆喝一声，这匹马就可以跑了，这就叫提示词工程。那么什么叫上下文工程呢？上下文工程就是在传统提示词工程的基础上，进一步增加了一些规则约束。比如说给了马相关的一些路标，给了它一张地图，那这个时候马就能够按照你的地图到达你规定的目标点，这个叫上下文工程。

那么什么叫“Harness”驾驭者工程呢？

很简单，就是给这匹马装了马鞍，套上了缰绳，相关的道路旁边修建了围栏，这个加起来就是“Harness”。为什么加了这些东西？因为我要防止这匹马乱跑，跑到别人的农田里面去（安全质量控制）；我也要防止这匹马碰到了一个路障以后，自己站不起来了，还得我重新去驱使它（自我反馈闭环）。

理解了刚才的概念以后，就更容易理解驾驭者工程是干什么用的。驾驭者工程其实就是在原有的提示词工程、上下文工程的基础上，进一步让我们操作指挥 AI 的时候，或者说让我们在做 AI 编程开发的时候，让整个 AI 开发软件的过程更加可控、可靠、安全、可观测。

我的理解是，驾驭者工程其实是将 AI 编程上升到组织级编程时的一个叫“后 AI 时代”，它是一个 AI 治理的时代。

Harness Engineering的核心内容

再展开一点，驾驭者工程在传统 AI 编程、上下文工程的基础上，究竟增加了哪一些关键的内容？

第一个，我把它理解为“架构约束、架构可控”。举一个简单的例子，原来我们也会去写一些架构的约束，比如说把它写到 Cursor Rules 或者Claude.md文件里面，这一块其实是跟原有的上下文工程类似的地方。但是我们可以进一步增加相关的架构控制规约，类似于规定“你只能调用逻辑层的方法，不能够直接访问数据库”；或者“两个微服务组件之间，只能通过 API 接口交互，微服务组件 A 不能够去访问微服务组件 B 的数据库”。

这些都叫增加的新的架构约束。但是在驾驭者工程里面有个很重要的点：我不是简单地增加了架构约束，而是要针对这些架构约束，增加自动化检查的相关技能包或者是智能体，让它能够完成基于架构约束的自动化检查，这是架构约束这一块关键的内容。

第二个内容叫“反馈闭环”。在网上的解释里面，把反馈闭环分成两个方面：第一个叫可观测性的反馈，第二个叫自愈循环。简单笼统地来讲，就是在使用 AI 的过程中，AI 编写完程序以后，它可以自己运行这个程序，自己 Debug，自己修复问题，完成一个自动化的完整过程。

包括原来我在讲 SDD 规约驱动开发的时候，大家已经能够看到这个特点了：任何一个程序写完以后，AI 会再生成几个专门用作测试的脚本代码，然后自己去跑。包括当前 AI 的编程工具，已经更好地实现了类似于基于 DOM 的浏览器自动化，它可以模拟人一样登录系统，自己在前端操作去做相应的黑盒测试，发现问题以后自己优化改进。

这就是我们要实现的关键的一个反馈闭环。但是我对反馈闭环的理解比原来更进一步：在驾驭者工程里面的反馈闭环，不仅仅是简单地完成功能性的需求和测试，它更多会去考虑类似于安全、可靠、性能等非功能性的问题。

举一个简单的例子，AI 完成了这么一个程序代码，但是它在运行的过程中可能会发现你的 CPU、内存利用率飙升。那么在这种情况下，AI 应该去发现相关的性能问题，然后自动化地对软件进行调优，让整个软件更大程度地安全可靠，这是驾驭者工程要考虑的事情。

最后一个点叫“全生命周期管理”，或者简单的理解，仍然可以把它理解成上下文管理、会话管理，即整个工程及项目本身的长周期记忆能力、存储能力。对于这个点，其实原来我们已经在考虑，但是我个人的理解，原来的考虑更多是在个体层面的一些考虑。如何将这个能力从个体、从单个项目延展到组织级、多个项目里面去，这也是当 AI 编程变成规模级组织级实践的时候，必须考虑的一个问题。

比如说，你有可能在整个项目设置里面，设置类似于影响所有项目的全局规则，这是一种方式。第二个就是你怎么样更好地去做好会话的管理、相关的记忆存储。

举个简单的例子，我现在做完了这么一个东西，可能只做到了半中间，那么我这个东西能不能够很方便地丢给我的另外一个同事接手，让他能够接着朝下面做？那这个时候，哪些应该是在单个项目存储，哪些应该是在会话级的管理，哪些应该是在整个项目级的长周期记忆，我必须要去规划好。我的理解，这仍然是一个相当重要的能力。

简单总结核心要点

所以说简单总结，Harness 驾驭工程，它不是一个新鲜的事物，而是我们在 AI 编程发展的过程中，从个体走向组织级的时候，必须要考虑的一个 AI 治理问题。你必须考虑这个问题以后，才能够让人在驱使 AI 帮你干活的过程中，让 AI 更加安全、可靠、可控和可观测。

好了，今天关于 Harness 相关的分享就到这里。

希望对大家有所启发，再见。