OpenAI 工程师披露，团队在5 个月内借助 AI 代理产出约100 万行代码，覆盖应用逻辑、基础设施、工具、文档和内部开发工具，且人类手写代码为 0 行。这套方法被命名为 Harness Engineering，重点不在改模型，而在设计模型周围的运行系统，让代理可以持续、自主地完成编码、测试、提交 PR 乃至修复问题。
OpenAI给出的产出数据
按照公开说法，该项目从2025 年 8 月启动，团队规模由3 人扩展到 7 人，累计合并约1,500 个 Pull Request，平均每位工程师每天产出3.5 个 PR。单个 AI 代理一次可自主工作超过 6 小时，相关产品已经被数百名内部用户每天使用。
OpenAI 将“人类永远不直接写代码”设为一条硬规则。结果是，团队必须把精力放到代理基础设施、上下文管理和工作流设计上，而不是在人类临时补洞时兜底。短句来说，不能手改，就得把系统先搭对。
Harness Engineering到底管什么
文中将 Harness Engineering 定义为一门设计基础设施、约束条件和反馈回路的学科，目标是让 AI 代理能可靠、规模化地运作。OpenAI 用“马具”做比喻：模型像一匹强但不稳定的马，harness 是缰绳和控制装置，人负责定方向，代理负责执行。
其核心包括四项能力：约束、告知、验证、修正。前两项决定代理知道什么、能做什么；后两项决定它出了错后是否能被及时发现并拉回正确轨道。重点很明确，瓶颈不只在模型，更多在模型外部系统。
三根支柱：上下文、架构约束、熵管理
第一根支柱是 Context Engineering。OpenAI 的原则是，代理需要知道的内容都应放进代码仓库，仓库才是唯一真相来源。AGENTS.md 不该写成巨型说明书，而应作为目录，指向 architecture.md、conventions.md、api-reference.md 等结构化文档。静态上下文包括架构规范、API 合约、代码风格；动态上下文则包括日志、指标、追踪记录、CI/CD 状态和测试结果。
第二根支柱是架构约束。OpenAI 认为，减少解题空间反而能提升代理效率。团队会通过自定义 linter、结构测试、LLM 审计员和 pre-commit hooks 强制执行边界，避免代理复制到错误模式。第三根支柱是熵管理，也就是持续清理代理长期生成代码后产生的漂移、命名分叉和死代码。做法很直接：再用清理代理定期扫描仓库，发现问题后自动开 PR 修复。
代理已能走完整条开发链路
按文中描述，AI 代理可以从扫描仓库开始，自行重现 bug、录制展示失败的视频、实现修复、跑测试、检查 UI 渲染、提交 PR，并在 reviewer 给出反馈后继续迭代。如果 CI 构建失败，代理还会继续诊断并修复，只有涉及产品方向或设计判断时才会升级给人类。
OpenAI 还提到一种“最小化阻塞”的合并策略：在自动化测试、监控和快速反馈回路足够成熟时，等待的成本高于修复的成本。另一个被引用的案例来自 LangChain。其 coding agent 在 Terminal Bench 2.0 上的成绩从52.8%升至66.5%，而他们并未更换模型，只调整了 harness，包括自我验证回路、上下文工程、循环检测和“reasoning sandwich”。
这套框架最后指向同一个变化：工程师的角色正从写代码的人，转向设计代理运行环境的人。任务描述、约束制定、反馈闭环和系统维护，成了新工作重心。