OpenAI大牛开源自家Harness工程：自我改进RSI模板
内容提要
OpenAI团队采用Harness Engineering方法，从空仓库起步，在五个月内利用Codex智能体生成百万行代码，全程无需人类手写代码。该方法核心在于设计环境、明确意图、构建反馈回路，并通过AGENTS.md作为地图、docs目录存储知识、linter强制约束，使AI能够自主开发、测试和审查，实现自我改进。
延伸解读
环境设计优于模型微调
文章强调Harness Engineering的核心在于通过设计环境来约束AI行为，而非依赖模型微调。微调需要针对特定模型版本，换模型就得重来；而环境规则写在仓库中，可跨模型复用。这种思路降低了模型升级带来的适配成本，也使得便宜模型能在护栏内高效工作。
知识库的渐进式披露
团队最初尝试巨型AGENTS.md文件，但效果不佳，因为情境资源有限，大文件会挤占任务空间。后来改为将AGENTS.md作为地图，docs目录作为记录系统，实现渐进式披露。这种设计让智能体从小而稳的切入点开始，逐步深入，避免信息过载，同时通过linter和CI保证知识库的更新与正确性。
架构约束的强制执行
为了保持AI生成代码库的连贯性，团队通过自定义linter和结构测试机械强制执行架构约束，如依赖方向、边界解析等。这些约束不微观管理实施细节，但确保代码遵循固定模式。文章指出，这种严格架构通常在大规模团队中才需要，但对编码智能体而言是早期先决条件，能防止架构漂移。
AI自主开发的新瓶颈
随着AI吞吐量提升，人工QA成为瓶颈，团队通过让应用对Codex直接可读（如接入DevTools协议、提供日志查询）来解决。此外，完全自主的智能体会复制坏模式，导致技术债务累积，团队通过编码黄金原则和定期后台清理任务来应对。这些实践表明，AI自主开发需要配套的监控和清理机制。
Q&A
OpenAI团队是如何在五个月内生成百万行代码的？
OpenAI团队采用Harness Engineering方法，从空仓库起步，利用Codex智能体自动生成代码，人类不手动写代码。他们通过设计环境、明确意图、构建反馈回路，并使用AGENTS.md作为地图、docs目录存储知识、linter强制约束，使AI能够自主开发、测试和审查，最终在五个月内生成了百万行代码。
Harness Engineering的核心思想是什么？
Harness Engineering的核心思想是不要指望AI自觉，而是把规矩写进环境里。通过塑造环境（上下文和工具）而不是修改模型本身，来成倍提升AI智能体的工作表现。
为什么AGENTS.md文件不应该太长？
因为情境是稀缺资源，大指令文件会挤占任务和代码的空间，导致智能体漏掉关键约束或对着错误约束优化。指导太多反而无效，什么都重要就等于什么都不重要。因此，AGENTS.md应作为地图使用，大约100行，指向更深处的真相来源，实现渐进式披露。
在Harness Engineering中，如何确保代码库的架构约束得到执行？
通过自定义linter和结构测试机械强制执行架构约束。例如，每个业务域分固定层，依赖方向严格验证，只允许有限边。linter出错信息直接注入修复指令，使AI看到报错就知道怎么改。
为什么说Harness Engineering比微调模型更优越？
因为微调是把规矩塞进特定模型脑子里，换新模型版本就得重来。而环境规则写在仓库里，换模型时检查器、规则和历史教训都还在，一次搭好环境，后面所有模型版本通吃。此外，便宜模型也能在护栏内工作，总成本更低。
在完全自主的智能体开发中，如何处理技术债务和代码漂移？
通过将黄金原则编码进仓库，建立循环清理流程。定期运行后台Codex任务扫描偏差、更新质量等级、发起针对性重构PR。这像垃圾回收，不断用小额偿还技术债务，避免累积。
OpenAI团队如何解决人工QA测试跟不上代码生成速度的问题？
他们让应用程序对Codex直接可读，使Codex能启动并驱动应用实例，接入Chrome DevTools协议，创建处理DOM快照、截图和导航的技能。Codex能自己复现错误、验证修复、推理UI行为，并通过本地可观测性堆栈查看日志、指标和追踪记录。
GitHub仓库lopopolo/harness-engineering与OpenAI博客文章的关系是什么？
博客文章提出了Harness Engineering的理念，而GitHub仓库是其实操落地版，提供了具体的工具和模板。仓库中的AGENTS.md、docs/、evals/、playbooks/等目录对应文章中的方法，可以直接喂给AI智能体使用。
