大家好，我是拭心。
最近 Harness Engineering 很火，国内外都在谈论它，我们也来简单聊聊。
起因是 OpenAI 的这篇 《Harness engineering: leveraging Codex in an agent-first world》（openai.com/zh-Hans-CN/… Harness Engineering 的概念。
简单来说，OpenAI 花了五个月做了一件事：完全靠 AI 实现了一个大规模（100万行）、可以使用的产品，人类没有编写一行代码。
最终 AI 可以自动开发这些工作：
- 产品代码与测试
- CI 配置和发布工具
- 内部开发者工具
- 文档和设计历史
- 评估框架
- review 评论和回复
- 管理代码仓库本身的脚本
可以看到，基本上做到了能自动完成整个研发流程。
这在之前是无法想象的，通过提示词和上下文优化，我们可以让 AI 多做一些事情，但总是需要人类去 review、测试、指出问题。每次开发需求都是输入提示词开始，人工测试修复结束。
OpenAI 这次的实验，就是秉持着「review 流程，而不是 review 代码」的态度。
遇到问题，不是人为去解决，而是思考「智能体还需要什么样的能力」，比如 AI 无法感知到运行问题，就让应用程序的 UI、日志和应用指标等内容对 Codex 直接可读，从而让智能体可以自测、收集运行情况。
最后，他们把这种 完全靠 AI 完成复杂系统，人类不写一行代码，定义为 Harness Engineering。
Harness 是马具的意思，表达像控制马一样管理大模型。
从目的上来讲，Harness Engineering（Harness 工程） 比提示词工程、上下文工程要宏大。
- 提示词工程的核心是优化问题，让 AI 理解问题细节；
- 上下文工程的核心是优化模型的输入信息，让 AI 有更多决策信息；
- 而 Harness Engineering 的核心，则是完全让 AI 自动实现整个流程。
别的不说，光是这个概念，就让工程师、企业老板有了无限的遐想：如果这个系统真的实现了，那真的吃着火锅唱着歌，就把事干了、钱赚了。
二、如何实现
Harness Engineering 听着很厉害，这要怎么做到呢？
简单来说，就是通过为 AI 构建一个可以独立运行的环境。 让它有更多信息输入、可以按照指定的边界约束进行实现，实现后可以自己进行测试，测试完根据问题自行优化。
也就是开放更多信息、约束、测试、自我迭代。
2.1 开放更多信息
这个意思是说，让智能体能够直接从代码仓库推理出完整的业务信息。
实际业务迭代中，我们很多信息是 AI 感知不到的，比如文档、聊天记录、口头交谈。
要让 AI 完全搞定，就要将云端的文档、聊天记录、录音信息，都放到代码仓库里，进行版本管理。
把 AI 当作一个新员工，当新员工来了我们会怎么做？
会介绍产品原则、工程规范和团队文化等方面，然后再讲项目的历史、现状和需求。
现在要将这些信息也提供给智能体，会带来更一致的输出。
2.2 如何约束
具体来说，为 AI 提供约束就是指为智能体确定任务的边界和输出结构。
OpenAI 做那个项目时，也是用 Plan 和 Spec 限定任务边界，但他们对这些指导性文档进行了更为严格的版本管理。 他们会使用单独的智能体，定时检查、修复过时的文档。
原文这么说：
Plan 被视为最重要的文件。临时轻量 Plan 用于小幅变更，而复杂工作则记录在执行计划（在新窗口中打开）中，并附带进度和决策日志，这些日志会被提交到代码仓库。
活跃计划、已完成计划和已知的技术债务都已进行版本控制并集中存放，使智能体能够在不依赖外部情境的情况下运行。
具体的 Plan 和 Spec 方法，现在有很多，比如 GSD、BMAD、Spec Kit 、OpenSpec、Superpowers 等等，不同的组织有不同的方案。 后两者是我使用后感觉不错的，后面会花些文章进行介绍。
除了边界，也限定不同 Agent、不同模块之间交付的结果结构。这样在执行完成后，可以首先检查结果是否是指定的结构，不是就重新执行。
定义清楚结构，起码先保证了运行方向，避免智能体无方向的开发。
有了约束，大规模的自动开发，质量才不会太跑偏，整体迭代速度才不会随着 Agent 的增加而明显下降。
2.3 测试
这里的测试是说让 AI 可以自己完成测试。
具体实现，OpenAI 是通过自定义的代码检查器和结构测试来强制执行这些规则。
在智能体写代码的流程里，需要认真对待 lint。以前觉得烦的 lint 变得至关重要，另外在报错信息里加上给智能体看的修复指令。
除了 Lint 这种静态测试，还需要有运行期间的测试。
OpenAI 将 Chrome DevTools 协议接入智能体，并创建了用于处理 DOM 快照、屏幕截图和路由的 Skill。这使 Codex 能够复现错误、验证修复，并直接推理 UI 的行为。
2.4 自我迭代
自我迭代，需要有几个必要因素：
- 检测手段
- 对错标准
检测手段就是为智能体提供更多可观测性工具。
OpenAI 把运行时的日志、关键指标和堆栈，通过一个本地可观测性工具提供给智能体，这样 AI 可以更好的了解实现结果如何。
除了结果，还可以将系统的更多过程信息，转化为智能体可以检查、验证并直接修改的形式。
比如 code review 结果、重构的 Pull Request 和自动测试/用户反馈的 Bug，都记录为文档，或者直接用来优化 Skill。
对错标准，则要站在系统运行和智能体角度思考。
人看不看得懂不重要，正确的、可维护的，并且让智能体未来执行任务时清晰易读，就是好的。
这个过程是一个飞轮，开始肯定会遇到问题。
当智能体遇到困难时，将其视为一个系统迭代信号：思考智能体还缺什么，是工具、是约束还是文档？然后将其反馈到代码仓库中，让智能体自己出优化方案。
三、总结
好了，这篇文章到这里就结束了，总结一下。
如果把大模型比做汽车引擎，那 Harness Engineering 就是给这个引擎装上方向盘、刹车和智能驾驶系统，让这辆车在运行的过程中可以自动控制方向和刹车。
肉眼可见的，我们人工写代码的时间越来越少，更多的时候是指挥 AI 去写。
在 Harness Engineering 出现后，以后的趋势是更多的时间花在为 AI 提供运行环境，为 AI 提供可观测工具和运行一致性工具、反馈回路。
目前还没有什么统一的方案，都是在讨论思想和尝试落地。OpenAI 都花了五个月，说明这不是可以快速见效的事情。
但我们可以先思考一下：当机器可以不知疲倦地写代码时，人的核心价值在哪里呢？
或许就是本文所提到的，定义边界、设置约束、修改标准。
更多精彩教程，尽在我的转型 AI 应用开发专栏：《转型 AI 工程师｜提升竞争力》
