一切的起点

今天要聊的这个实验，起点很特别。

2025年8月，OpenAI内部一个小团队做了一个堪称疯狂的尝试：从零开始构建一款软件产品，但规则是——一行代码都不能由人来写。

所有代码，包括应用逻辑、测试、CI配置、文档、监控、内部工具，全都交给Codex——OpenAI自家的AI编码智能体来生成。

五个月后，结果出炉。这份实验报告的数字，看起来震撼得有点不真实：

• 生成约100万行代码
• 提交约1500个Pull Request
• 最初只有3名工程师（后来扩充到7名）推动这一切
• 人均每天处理3.5个PR，而且速度还在加快
• 整体完成时间大约是传统手工编写的十分之一

这可不是什么实验室里的概念验证。这个产品有内部日常活跃用户，有外部Alpha测试者，经历过完整的上线、故障、修bug的生命周期。

OpenAI把这次实验总结出的工程范式，命名为：Harness Engineering（驭缰工程）。

一个令人震惊的数据

LangChain在分析中引用了Terminal Bench 2.0的基准测试数据。这个数据简单直接，却极具冲击力：

纯harness优化，就能把模型的整体排名从Top 30直接拉到Top 5。

这意味着什么？你不一定需要一个更强的模型。很多时候，你只是需要一个更好的harness。

这就好比同一匹马，换上一副更合适的缰绳、换一个经验更丰富的骑手，最终的成绩可能天差地别。

核心转变：从写代码到设计约束

传统软件工程的流程，一条线就能概括：

人类写代码 → 机器执行代码

而Harness Engineering的流程，变成了两条线：

人类设计约束 → 智能体写代码 → 机器执行代码

工程师的产出，不再是代码本身。它变成了——约束系统。

那么，这个约束系统具体包含什么？

• AGENTS.md —— 一份导航文件，告诉智能体“这个仓库长什么样、怎么工作”
• 架构规则 —— 依赖方向、分层约束、边界定义
• 自定义Linter —— 把编码规范变成可被机械执行的检查
• 反馈回路 —— 让智能体能自己验证它的工作成果
• 结构化文档 —— 设计决策、执行计划、技术债追踪

核心一句话：人类掌舵，智能体执行。

Copilot时代是“用AI辅助写代码”。而Harness Engineering直接翻篇：让AI完全写代码，人类负责让AI写对。

六大核心概念

OpenAI在这次实践中总结了六条关键经验。每一条都碘伏了传统认知。

1. 仓库即记录系统

Slack讨论里形成的决策？不存在。Google Docs里的设计文档？不存在。你脑子里的经验？那更不存在。

对于智能体来说，它唯一能看见的，就是仓库里的文件。所以一切决策、规范、计划，都必须以版本化工件的形式提交到仓库。

这就像团队来了一个超级聪明但每次都“失忆”的新同事——他看不到你脑子里在想什么，只能看你写在文件里的东西。区别在于，这个同事每次对话都是全新的，没有记忆延续。

2. 地图而非手册

OpenAI一开始尝试了“一个超大号的AGENTS.md”，结果惨败。原因很典型：

• 挤占上下文 —— 巨大的指令文件，把任务相关的代码和文档挤出视野
• 等于没说 —— 当一切都标注“重要”，一切就都不重要了
• 立即腐烂 —— 庞杂的手册很快变成陈旧规则的坟场
• 无法验证 —— 单个大blob不适合做机械检查

解决方案是什么？让AGENTS.md保持在约100行，就像博物馆入口的导览图。它只做方向指引，指向更深层、更具体的文档。

这个策略叫“渐进式披露”——智能体从小入口进入，被引导着下一步该看什么，而不是一次性把所有信息砸给它。

3. 机械化执行

OpenAI把编码规范直接写成了自定义linter。更妙的是，他们在linter的错误信息里嵌入了修复指令。智能体看到报错提示，同时也知道了该怎么修复。

Martin Fowler在文章中也提到，有团队已经开始用AI来生成自定义linter——让智能体来写约束智能体的规则。

核心原则很简单：能用代码表达的约束，绝不只写在文档里。

4. 智能体可读性

一个反直觉的观点：为智能体优化代码的可读性，有时候优先级要高于为人类优化。

具体做法包括：选择“无聊”的技术——API稳定、训练集覆盖好、行为可预测。有时候，重新实现一个子集，比包装一个复杂的第三方库更划算。目标是让应用可以按git worktree的方式启动运行，这样智能体每次任务都能在一个独立实例上工作。甚至把Chrome DevTools协议接入智能体，让它能直接看到UI、复现bug、验证修复。

5. 吞吐量改变合并理念

传统工程里，PR审查是件严肃的事。测试失败？那必须老老实实修好了才能合并。

但在这个新世界里，智能体的吞吐量已经远超人类的注意力能覆盖的范围。PR生命周期极短。对于偶发的测试失败，靠后续重跑来解决。纠错成本很低，但等待成本很高。

在低吞吐量的环境里，这种做法确实显得不负责任。但在智能体高速运转的系统里，这反而是正确的策略。

6. 熵管理 = 垃圾回收

智能体会不自觉地复现仓库里已有的模式——包括坏的模式。如果不主动清理，代码质量会像滚雪球一样越来越差。

OpenAI的做法很务实：把“黄金原则”编码到仓库中；定期运行后台Codex任务，扫描偏差、更新质量评分、发起重构PR。这些重构PR大多可以在一分钟内审查并自动合并。

对待技术债，就应该像对待信用卡——每天小额还款，别让它滚雪球。

精确定义：Agent = Model + Harness

来自LangChain、Martin Fowler和HumanLayer的综合定义，给出了一个清晰的公式：

Harness（缰绳/驾驭系统）= 模型之外的一切代码、配置和执行逻辑。

Martin Fowler用了一个2×2矩阵来描述这些组件如何协同工作：

前馈在智能体行动之前引导它，反馈在行动之后观察和纠正它。两者缺一不可。

工程师的角色变了

在Harness Engineering的世界里，工程师的工作清单发生了根本性的变化。

不再做这些：

• ❌ 手写代码
• ❌ 逐行code review
• ❌ 手动调试
• ❌ 维护文档

转而做这些：

• ✅ 设计环境和架构约束
• ✅ 编写和维护AGENTS.md
• ✅ 把规范转化为可执行的linter规则
• ✅ 构建反馈回路（测试、CI、自动化验证）
• ✅ 管理智能体的上下文和工具
• ✅ 在智能体卡住时识别“缺了什么”，并补充进去

一句话概括：工程师的工作重心，从“执行”真正变成了“设计让执行可靠的系统”。

Ralph Wiggum 循环：Harness Engineering 的核心实现

OpenAI在实践过程中采用的是“Ralph Wiggum循环”模式，这个名字来自LangChain。这个循环的核心特征很鲜明：

• Fresh Context —— 每次迭代重新读取上下文，不会积累错误
• Backpressure —— 不规定具体怎么做，但用门控机制拒绝坏结果
• The Plan Is Disposable —— 计划随时可以重来，成本很低
• Disk Is State, Git Is Memory —— 文件是交接的机制，git是记忆的载体
• Let Ralph Ralph —— 坐在循环上观察，而不是陷在循环里执行

单次运行经常持续6小时以上。大多数时候，是在人类睡觉的时候跑，第二天早上起来看结果。

这场范式转移已经在发生

OpenAI的这个实验可不是实验室里的演示。它是一个正在为真实用户交付真实产品的生产系统。

更重要的是，这个范式正在以惊人的速度扩散：

• Martin Fowler（ThoughtWorks）发布了专题文章，用控制论框架分析Harness Engineering
• LangChain从Agent架构角度，重新定义了Harness
• Anthropic分享了Scaling Managed Agents的实践经验
• 张汉东写了《驾驭工程》（别名《马书》），从Claude Code源码中提炼AI编码最佳实践，共30章7篇
• deusyu建了harness-engineering学习指南，包含19篇文章的深度摘要，以及12篇专业翻译

它已经从一个公司的内部实践，快速扩散成软件工程范式的一次根本性转变。

写在最后

如果你是一位工程师，读到这篇文章，第一反应可能是焦虑—— “AI要取代我了”。

但OpenAI的实验恰恰说明了一个相反的事实：工程师变得更重要了，只是做的事情变得不一样了。

100万行代码，3个人，不写一行代码。他们做的事比写代码更高级——设计一个能让AI可靠工作的系统。

这就是Harness Engineering。

人类掌舵，智能体执行。

这个实验完成于2026年初，产品已经在运行。这不是预言，这是正在发生的事实。

这是Harness Engineering系列的第一篇。下一篇我们聊：AGENTS.md到底怎么写——给智能体的“入职手册”该怎么设计。