Harness Engineering 又是什么新 AI 玩具？

今天我们聊了业内最新提出的 Harness Engineering。可以看到在 AI 智能体优先的世界里软件工程的鲁棒性开始转移到了支撑智能体上。最近 AI 编程可以说是卷上天了不得不说时代的大车轱辘已经碾过来了。GLM 一个月内狂发新模型。我们今天来聊聊 OpenAI 最近公布的一个极其硬核的内部实践——他们花五个月时间完全用内部的 Codex 从零写了一个百万行代码的产品。在这个过程中人类工程师一行代码都没写。为了支撑这种开发模式他们提出了一个非常核心的新概念Harness Engineering (驾驭工程)。我们今天这篇文章来聊聊这是什么新玩具Harness Engineering 是什么简单来说以前我们写代码是 “微观管理”敲击键盘写下每一个函数和业务逻辑。而在 Harness 模式下工程师的主要工作变成了“设计环境”。你不需要亲自下场干活而是去打造一套极其严密的护栏上下文系统和反馈回路用这套 “缰绳”去驾驭 AI 这个生产力怪兽。为了更直观地理解直接看概念图有了这套体系本质上就是人类掌舵智能体执行。AI 就像拉车的马只要缰绳在你手里跑得再快也不会偏离赛道。为什么不用传统的 Prompt 模式很多人的日常体验就是给一段 Prompt复制粘贴报错了再贴回去问。这个方式其实挺常见。我们一直把 AI 当成一个高级的自动智能工具。但是很无奈的是当你的目标是交付一个具备高可用性的大型软件时这种模式根本行不通。根据 OpenAI 团队的真实案例分享他们在项目初期进展非常缓慢。这倒不是因为模型能力不行而是因为 AI 缺乏上下文和工作环境。这引出了 Harness Engineering 的动因我们需要重新定义工程师的角色。你得把 AI 驾驭好而不是跟着它的报错在后面擦屁股。Harness Engineering 核心玩法我们来看下OpenAI 这帮大佬具体是怎么搭建这套驾驭环境的。这里有几个点需要注意。把代码仓库变成记录系统以前我们为了让 AI 懂业务恨不得写个几千行的超大 Prompt。OpenAI 团队也尝试过搞一个巨无霸的AGENTS.md文件。结果显而易见一旦指令过多AI 就会开始漏看关键约束甚至产生幻觉。这就很尴尬当所有东西都“重要”时就等于什么都不重要。现在的解法是给 AI 一张地图而不是一本厚重的说明书。新旧写法对比举个例子我们来看下旧写法和新写法的对比直观感受。旧写法 (灾难现场)试图在一个 Prompt 或大文件中塞入所有架构规范数据库表结构和业务历史。AI 瞬间上下文爆炸开始瞎编乱造。新写法 (Harness 模式)只给一个 100 行左右的短小AGENTS.md作为目录索引配合严格的文档目录结构代码仓库/ ├── AGENTS.md (仅作导航地图告诉 AI 去哪找什么) ├── docs/ │ ├── design-docs/ (核心理念与设计状态) │ ├── exec-plans/ (正在执行的计划与技术债) │ └── generated/ (由 AI 自动生成的 Schema 等) └── src/通过这种渐进式的信息披露机制AI 从一个稳定的小入口开始工作按照指南去查找深层资料。并且他们还会专门跑一个定期任务让另一拨 AI 自己去巡检文档是否过期实现自动化更新。面向智能体的可观测性这是一个非常超前的概念。以往我们写代码讲究“对人友好”现在得讲究“对 AI 友好”。AI 就像是一个永远在线但无法参加你在 Slack 和会议室里讨论的新员工。如果知识只存在于飞书文档或者你的脑子里对 AI 来说就是不存在的。代码仓库里存放的版本化工件就是它能看到的全部世界。为了让 AI 拥有“视觉”和“触觉”OpenAI 团队为 AI 接入了 Chrome DevTools 协议。当前端出现问题时AI 可以直接启动应用实例通过 DOM 快照和页面截图去复现 Bug 并验证修复。他们甚至为本地开发赋予了完整的可观测性堆栈。当任务跑起来后AI 可以直接使用 LogQL 查询日志或者用 PromQL 查询监控指标。这就意味着你可以直接给 AI 下达这样的指令“确保这个接口的冷启动耗时在 800ms 以内。” 剩下的排查工作AI 会自己在半夜跑上六个多小时去死磕。用机制规范架构与代码品味AI 写代码很容易放飞自我如果不加干预百万行代码很快就会变成一座难以维护的屎山。怎么解决呢本质上就是上硬核的架构约束。在 Harness Engineering 中我们不会去微观管理 AI 的每一行代码实现而是通过 Linter 和结构化测试在边界处架起机枪。比如他们设计了一套有着明确界限的分层领域架构。代码的依赖方向必须严格遵守规范Types - Config - Repo - Service - Runtime - UI。对抗熵增AI 代码的垃圾回收频繁使用 AI 会带来新的问题。AI 会模仿代码库里现有的写法甚至包括那些不太优雅的历史包袱导致技术债加速积累。起初工程师们每周五还要苦哈哈地手动清理这些“AI 残渣”。后来发现这根本不符合 Harness Engineering 的精神。最终的终极方案是用魔法打败魔法。他们将“黄金原则”直接编码到代码仓库中然后在后台起一组 AI 智能体定期全盘扫描代码库寻找偏差。这就好比我们熟知的 Go 语言里的垃圾回收机制 (GC)这些 AI 会自动发起重构的 Pull Request把不符合规范的逻辑给替换掉。这种高频微小的还债方式彻底解决了大项目积重难返的问题。社区声音与延伸思考面对这样疯狂的开发范式社区里大家也是谁都不服谁。一方面许多坚守传统的极客认为彻底把底座交给黑盒的 AI 模型风险极高万一出个安全漏洞连排查都无从下手。另一方面前沿的拥抱者觉得只要测试覆盖率和 Linter 护栏足够严密AI 带来的效率提升是碾压级的。五个月搞定平时几十个人的工作量这在商业上的诱惑力太大了。我个人的感觉是核心工程师的职能真的在发生转移。未来的高级开发会越来越像 “环境架构师”或者 “系统平台维护者”。当吞吐量大到一定程度时你连 Code Review 都懒得看了直接让另一个 AI 去做 CR 审查。这听起来有点科幻但已经在不少公司里落地了。总结今天我们聊了业内最新提出的 Harness Engineering。可以看到在 AI 智能体优先的世界里软件工程的鲁棒性开始转移到了支撑智能体上。通过把代码仓库打造成纯粹的记录系统面向智能体优化可读性并利用强约束 Linter 和自动化 GC 机制我们完全可以驾驭 AI 替我们干掉海量的工作。如果大家可以提前掌握这种高维度的 “驾驭” 能力绝对是未来几年的核心竞争力。