OpenAI Harness Engineering：利用 Codex 实现零手写代码开发

OpenAI 成功构建并发布了一个内部软件产品，代码量约为一百万行，且没有任何一行是由人手动编写的。通过使用 Codex 代理，团队将开发时间缩短至传统手动编码所需时间的约十分之一，将人类的角色从编写代码转变为设计环境、规范以及使代理能够自主的反馈循环。

“零手写代码”实验

2025 年 8 月起，一个小型工程师团队使用 Codex（在 GPT-5 的指导下）生成了从最初的仓库脚手架和 CI 配置到应用逻辑、文档以及内部工具的所有内容。五个月内，团队规模从三人扩大到七人，管理了约 1,500 个已合并的拉取请求（PR）。

该方法的关键成果包括：

高吞吐量： 每位工程师平均每天 3.5 个 PR。
全面生成： 代理不仅生成产品代码和测试，还生成生产仪表盘定义、评估工具以及用于管理仓库本身的脚本。
人机协同引导： 人员仍然参与工作优先级排序、将用户反馈转化为验收标准以及验证结果，但从未直接编写代码。

重新定义工程角色：从编码到脚手架

在以代理为先的工作流中，主要的工程瓶颈不是代理的能力，而是环境的规范。OpenAI 发现，当环境规格不足时，进展会停滞，导致人类专注于“深度优先”工作：将高层目标拆解为更小的构件，并创建使代理工作可读且可强制执行的工具。

代理间工作流

人类主要通过提示与系统交互。为了推动 PR 完成，Codex 被指示：

在本地审查自身的更改。
在本地和云端请求额外的代理审查。
根据反馈迭代，直至所有代理审查者满意。

随着时间推移，团队将几乎所有审查工作转向代理间交互，最大限度地减少了人类对 PR 的审查需求。

提高应用对代理的可读性

为减轻人类 QA 的负担，OpenAI 专注于让应用的内部状态直接对 Codex 可读。这使得代理能够在无需人工干预的情况下推理系统。

运行时访问： 该应用可通过 git worktree 启动，使 Codex 能为每一次更改启动独立实例。
UI 验证： 通过将 Chrome DevTools Protocol 接入代理运行时，Codex 可以使用 DOM 快照和截图来复现 bug 并验证 UI 行为。
可观测性： 代理可以访问本地可观测性栈，使用 LogQL 查询日志，使用 PromQL 查询指标，以满足特定性能目标（例如，确保服务启动在 800 毫秒以内完成）。

将仓库知识作为记录系统

OpenAI 发现，单体说明手册对代理无效，因为它们会淹没任务上下文且很快失效。于是他们采用了“映射”方法：

AGENTS.md 作为目录： 一个约 100 行的短文件提供指向更深层真相的指针。
结构化文档： docs/ 目录作为记录系统，包含索引化的设计文档、架构图以及产品领域的质量等级。
执行计划： 将复杂工作记录在带有决策日志的版本化执行计划中，并检入仓库。
机械强制执行： 专用的 linter 和 “doc-gardening” 代理确保文档与实际代码行为保持同步。

强制架构与“品味”

为防止完全由代理生成的代码库出现架构漂移，OpenAI 采用严格的机械约束，而不是对实现细节进行微观管理。

刚性架构模型

每个业务域遵循固定的分层系统，严格验证依赖方向：Types $\rightarrow$ Config $\rightarrow$ Repo $\rightarrow$ Service $\rightarrow$ Runtime $\rightarrow$ UI。横切关注点（例如认证、遥测）只能通过显式的 “Providers” 进入。

品味不变式

自定义 linter 强制执行“品味”和可靠性要求，例如：

对 schema/类型的结构化日志和命名约定。
文件大小限制。
边界解析（例如使用 Zod）以避免 “YOLO 风格” 的数据探测。

管理熵与“AI 松弛”

完全自治可能导致次优模式的复制。OpenAI 通过持续的“垃圾回收”过程来管理此问题：

黄金原则： 主观的机械规则被编码进仓库。
自动清理： 后台 Codex 任务定期扫描偏离这些原则的情况并打开重构 PR，这些 PR 通常在简短的人类审查后自动合并。

当前能力与未来未知

系统已达到一个阈值，Codex 能够端到端驱动新特性。从单一提示开始，代理可以验证代码库、复现 bug（记录失败视频）、实现并验证修复（记录解决视频），并在响应反馈后合并更改。

OpenAI 指出，虽然此方式已在内部发布中奏效，但仍未知架构一致性在数年后的演变以及系统在模型更强大时的适应方式。