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创始人）博客文章的启发。

核心实验数据

指标	数值
人工编写代码	0 行
总代码量	~100万行
开发时间	5个月（2025年8月-2026年1月）
工程师人数	3人 → 7人
PR数量	~1,500个
人均日PR	3.5个（且随团队扩大而增加）
估算效率提升	10倍

核心理念

> "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可读。

具体实践：

领域	人类做法	Agent做法
本地开发	启动本地服务器	每个git worktree可启动独立实例
UI调试	打开浏览器检查	Chrome DevTools Protocol集成，DOM快照、截图、导航
可观测性	查看日志和指标	LogQL查询日志，PromQL查询指标
Bug复现	手动操作复现	Agent自动驱动应用复现

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

合并哲学的转变

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

Harness规范：

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

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

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

---

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

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

为什么Prompt Engineering不够了？

Prompt Engineering	Context Engineering
关注如何写有效指令	关注管理整个上下文状态
一次性任务优化	多轮推理、长时间跨度的Agent
系统提示为主	系统提示+工具+检索+历史+...

Context的组成

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

Context Engineering的五大策略

策略	说明
选择	只检索最相关的片段，而非整个代码库
压缩	保留关键信息同时减少token数
排序	将信息放在模型会关注的位置
隔离	跨专门Agent分割上下文
格式优化	结构化信息以最大化理解

"Lost in the Middle"现象

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

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

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

---

六、挑战与局限

已知问题

问题	说明
模式复制	Agent复制仓库中已有模式，包括次优模式
上下文漂移	长期运行后，上下文质量下降
过度依赖结构	高度依赖特定仓库结构和工具
不确定性	架构一致性在多年时间尺度上如何演变，尚不清楚

尚在学习的问题

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

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..." > （我们现在最困难的挑战集中在设计环境、反馈循环和控制系统...）

---

七、对软件工程的影响

工程师角色的重新定义

传统角色	Harness角色
编写代码	设计环境和脚手架
调试Bug	设计反馈循环
代码审查	设计控制系统
技术决策	指定意图和目标

技能转移

变得更重要：

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

变得不那么重要：

• 语法细节
• 具体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可以端到端驱动功能

---

九、参考资源

资源	链接
OpenAI原文	https://openai.com/index/harness-engineering/
Martin Fowler解读	https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html
Anthropic Context Engineering	https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
Agent Skills开源项目	https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering
Codex介绍	https://openai.com/index/introducing-codex/

---

十、总结

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

维度	传统开发	Harness Engineering
核心活动	写代码	设计环境和反馈循环
人机分工	人类写，机器辅助	人类掌舵，Agent执行
代码来源	人类编写	Agent生成
质量保证	人工审查	机械约束+Agent审查
技术债务	周期性偿还	持续垃圾回收
规模效应	边际成本递增	边际成本递减

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

正如OpenAI团队所说：

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

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

---

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