Harness Engineering：OpenAI的Agent-first开发范式——当人类不再写代码

导语：如果整个软件项目没有一行人工编写的代码，全部由AI Agent完成，会发生什么？OpenAI在2025年进行了一项激进实验：3名工程师，5个月，100万行代码，0行人工代码。他们称之为"Harness Engineering"——一种全新的AI原生软件开发范式。

---

一、什么是 Harness Engineering？

术语起源

"Harness"原意为马具/缰绳——用来控制和引导马匹的工具。在软件工程中，它指的是：

一套用于引导、约束和赋能AI Agent的工程化框架和工具集

这个术语由OpenAI在2025年提出，但其思想受到Mitchell Hashimoto（HashiCorp创始人）博客文章的启发。

核心实验数据

核心理念

"Humans steer. Agents execute." （人类掌舵，Agent执行）

工程师的工作从"写代码"转变为：

• 设计环境（Designing environments）
• 指定意图（Specifying intent）
• 构建反馈循环（Building feedback loops）

---

二、Harness 的三大支柱

根据Martin Fowler的总结，Harness Engineering包含三个核心组件：

1. Context Engineering（上下文工程）

问题：Agent的上下文窗口是有限的稀缺资源。

解决方案：

传统做法：把AGENTS.md写成百科全书（1000+行）
    ↓
Harness做法：把AGENTS.md作为目录（~100行），指向结构化知识库

关键原则：

• 渐进式披露：Agent从小入口开始，按需深入
• 地图而非手册：提供导航，而非详尽说明
• 机械验证：用Linter和CI确保知识库最新

知识库结构：

docs/
├── AGENTS.md           # 目录（~100行）
├── architecture/       # 架构文档
├── design/            # 设计文档（带验证状态）
├── quality/           # 质量评分
├── plans/             # 执行计划
└── beliefs/           # 核心原则

2. Architectural Constraints（架构约束）

洞察：Agent在严格边界和可预测结构中最有效。

实践：

• 刚性分层架构：Types → Config → Repo → Service → Runtime → UI
• 机械强制执行：自定义Linter + 结构测试
• 边界集中控制，局部允许自主

示例规则：

✅ 必须在边界解析数据形状（但不指定具体库）
✅ 代码只能"向前"依赖
✅ 跨领域关注点通过Providers单一接口进入
❌ 禁止随意依赖

3. Garbage Collection（垃圾回收）

问题：Agent会复制仓库中已有的模式——包括不均衡或次优的模式。随着时间推移，这必然导致漂移。

初始尝试：团队每周五花20%时间清理"AI slop"——不可扩展。

解决方案：

• 编码"黄金原则"：机械规则保持代码库清晰
• 定期清理Agent：扫描偏差，更新质量评分，打开重构PR
• 技术债务持续偿还：小额高频，而非痛苦的大清理

黄金原则示例：

1. 优先使用共享工具包，而非手写辅助函数
2. 不"YOLO式"探测数据——验证边界或依赖类型化SDK

---

三、从0到100万行：时间线详解

第1阶段：环境构建（最慢）

现象：初期进展比预期慢。

原因：不是Codex能力不足，而是环境 underspecified。Agent缺乏工具、抽象和内部结构。

人类工作：

深度优先：将大目标分解为小块
    ↓
提示Agent构建这些块
    ↓
用它们解锁更复杂任务

失败时的反应：

从不"再试一次"，而是问："缺少什么能力？如何让它对Agent既清晰又可执行？"

第2阶段：Agent可读性优化

洞察：仓库完全由Agent生成，因此首先针对Codex的可读性优化。

关键认识：

• Agent视角：无法访问的上下文 = 不存在
• Google Docs、聊天记录、人脑中的知识 = 不可见
• 仓库本地、版本化的工件 = 全部可见

实践：

• 把Slack讨论中的架构共识写入仓库文档
• 像 onboarding 新同事一样 onboarding Agent
• 偏好可完全内化、在仓库中可推理的依赖

第3阶段：端到端自主

里程碑：Codex可以端到端驱动新功能。

给定单个提示，Agent现在可以：

1. 验证代码库当前状态
2. 复现报告的Bug
3. 录制演示失败的视频
4. 实现修复
5. 通过驱动应用验证修复
6. 录制演示解决的第二个视频
7. 打开Pull Request
8. 响应Agent和人类反馈
9. 检测并修复构建失败
10. 仅在需要判断时升级给人类
11. 合并变更

注意：这高度依赖仓库的特定结构和工具，不能假设普遍适用。

---

四、关键实践详解

AGENTS.md：地图而非百科全书

反模式：

# AGENTS.md（错误示例）

这里是关于我们代码库的一切...
[1000行详尽说明]
...

问题：

• 上下文是稀缺资源，大文件挤占任务空间
• 太多指导 = 无指导，Agent局部模式匹配
• 单体手册瞬间腐烂，Agent无法辨别真伪
• 难以验证，漂移不可避免

正确做法：

# AGENTS.md（正确示例）

## 核心原则
- [信念文档](docs/beliefs/)
- [质量标准](docs/quality/)

## 架构
- [顶层架构](docs/architecture/overview.md)
- [领域分层](docs/architecture/layers.md)

## 工作流程
- [开发流程](docs/processes/development.md)
- [代码审查](docs/processes/review.md)

## 工具
- [可用工具](docs/tools/)
- [调试指南](docs/debugging/)

让应用对Agent可读

瓶颈转移：代码吞吐量增加后，瓶颈变成人类QA能力。

解决方案：让应用UI、日志、指标直接对Agent可读。

具体实践：

效果：经常看到单个Codex运行处理单个任务超过6小时（通常是人类睡觉时）。

合并哲学的转变

传统规范：严格的合并门控，阻塞式审查。

Harness规范：

• 最小化阻塞合并门控
• PR短生命周期
• 测试flaky？跟进运行而非无限期阻塞

逻辑：

在Agent吞吐量远超人类注意力的系统中，修正是廉价的，等待是昂贵的。

前提：这在低吞吐量环境中是不负责任的。在这里，它往往是正确的权衡。

---

五、Context Engineering：从Prompt到Context的演进

Harness Engineering的核心是Context Engineering——从Prompt Engineering的自然演进。

为什么Prompt Engineering不够了？

Context的组成

完整Context栈：
├── 系统提示/指令
├── 代码库上下文（相关文件、架构模式）
├── Git历史/近期变更
├── 依赖和导入库
├── 工具定义（调试器、Linter、测试运行器）
├── 团队标准和模式（AGENTS.md、风格指南）
├── 对话历史
└── 检索的文档（API文档、示例、架构决策记录）

Context Engineering的五大策略

"Lost in the Middle"现象

研究发现：即使模型声称有100万token上下文窗口，正确性在32,000 token后开始下降。

原因：注意力机制——模型关注上下文开头和结尾，中间内容变成噪音。

教训：> 更多上下文 ≠ 更好性能。最优密度获胜。

---

六、挑战与局限

已知问题

尚在学习的问题

• 人类判断在哪里增加最大杠杆？
• 如何编码这种判断使其复利增长？
• 随着模型能力持续提升，系统如何演变？

OpenAI的坦诚

"What’s become clear: building software still demands discipline, but the discipline shows up more in the scaffolding rather than the code." （变得清晰的是：构建软件仍然需要纪律，但纪律更多地体现在脚手架而非代码中。）

"Our most difficult challenges now center on designing environments, feedback loops, and control systems..." （我们现在最困难的挑战集中在设计环境、反馈循环和控制系统...）

---

七、对软件工程的影响

工程师角色的重新定义

技能转移

变得更重要：

• 系统架构设计
• 工具设计
• 流程设计
• 质量控制
• 抽象设计

变得不那么重要：

• 语法细节
• 具体API记忆
• 手写算法
• 样板代码

对行业的潜在影响

Martin Fowler的预测：

1. 技术栈收敛：AI可能推动我们走向更少的技术栈，选择"AI友好"的栈
2. 代码库拓扑标准化：默认选择AI更容易维护的结构
3. Harness成为新服务模板：团队从Harness开始，随时间塑形

---

八、如何开始实践 Harness Engineering

第一步：评估当前状态

问自己：

• 你的"Harness"今天是什么？
• 你有pre-commit hook吗？里面有什么？
• 你想施加什么架构约束？
• 你尝试过结构测试框架（如ArchUnit）吗？

第二步：从小处开始

不要试图一次性构建完整Harness：

第1周：创建简短的AGENTS.md（目录）
第2周：添加一个自定义Linter
第3周：建立文档验证CI任务
第4周：添加一个"清理Agent"
...

第三步：迭代投资

OpenAI团队工作了5个月。这不是能快速见效的事情。

但当它工作时：

• 吞吐量随团队规模增加而增加（而非通常的下降）
• 技术债务持续偿还而非累积
• Agent可以端到端驱动功能

---

九、参考资源

---

十、总结

Harness Engineering代表了软件开发范式的潜在转变：

这不是关于AI取代工程师，而是关于工程师角色的进化——从亲自编写每一行代码，到设计让AI能够可靠工作的系统。

正如OpenAI团队所说：

"The canary is still alive." （金丝雀还活着。）

我们还有时间学习、适应和构建这个未来。

---

本文基于OpenAI 2025-2026年发布的公开资料整理，Harness Engineering是一个快速发展的领域，具体实践可能随时间演变。