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：地图而非百科全书 **反模式**： ```markdown # AGENTS.md（错误示例） 这里是关于我们代码库的一切... [1000行详尽说明] ... ``` **问题**： - 上下文是稀缺资源，大文件挤占任务空间 - 太多指导 = 无指导，Agent局部模式匹配 - 单体手册瞬间腐烂，Agent无法辨别真伪 - 难以验证，漂移不可避免 **正确做法**： ```markdown # 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是一个快速发展的领域，具体实践可能随时间演变。*