工程驱动：在以代理为先的世界中利用 Codex

向零手写代码的转变

OpenAI 已成功开发并发布了一款内部软件产品，使用了 零行手写代码。在五个月的时间里，一个小型工程团队使用 Codex 代理生成了应用逻辑、测试、CI 配置、文档以及可观测性工具，最终形成了约一百万行的代码库。团队估计，这种以代理为先的方法将开发时间缩短至手动编码所需时间的约十分之一。

在这种模式下，人类不再是代码的主要作者，而是充当指引者。工程师的角色转向设计系统、明确意图，并构建使代理能够可靠工作的反馈回路。

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

当人类停止编写代码时，主要的工程挑战变为 让代理能够完成有用工作，通过提供必要的工具、抽象和内部结构来实现。

系统优先开发

实验的早期进展缓慢，因为环境描述不足。为了解决此问题，工程师采用了深度优先的方法：将大型目标拆分为小的构建块，提示代理去构建它们，并利用这些块解锁更复杂的任务。当出现失败时，解决方案不是通过提示“更努力”来尝试，而是识别缺失的能力或工具并提供给代理。

代理驱动的工作流

人类主要通过提示与系统交互。典型的工作流包括：

  1. 工程师描述任务。
  2. 代理执行并打开一个 pull request（PR）。
  3. 代理在本地审查自己的更改并请求额外的代理审查。
  4. 代理根据人类或代理的反馈迭代，直至所有审阅者满意。

随着时间推移，团队几乎将所有审查工作转向代理之间的交互，仅在必要时由人类审查 PR。

提高应用对代理的可读性

为防止人工 QA 成为瓶颈，OpenAI 将重点放在使应用及其遥测信息直接对 Codex 代理可读上。

  • UI 可读性: 通过将 Chrome DevTools Protocol 接入代理运行时，并使应用能够按 git worktree 启动，代理可以启动实例、复现 bug、验证修复，并使用 DOM 快照和截图推理 UI 行为。
  • 可观测性可读性: 代理可以访问本地的短暂可观测性栈。他们可以通过 LogQL 查询日志，通过 PromQL 查询指标，从而处理诸如“确保服务启动在 800ms 以下完成”的性能相关提示。

将仓库知识视为唯一可信记录

有效的代理性能依赖于精确的上下文管理。OpenAI 发现，单一的大型说明手册适得其反，因为它们会挤占任务特定的上下文，并且很快变得陈旧。

地图 vs. 手册

团队没有使用巨大的说明文件，而是采用一个约 100 行的简短 AGENTS.md 文件，充当 目录。该地图指引代理前往结构化的 docs/ 目录，后者作为唯一可信记录。此方法实现了 渐进式披露，即代理从一个小入口开始，并被教导去哪里查找更深入的信息。

知识的机械化强制

  • 专用的 linter 和 CI 任务 用于验证知识库是否是最新且交叉链接的。
  • 文档维护代理 扫描过时的文档并打开修复 PR，以使文档与实际代码行为保持一致。

强制架构与风格

为了在百万行、由代理生成的代码库中保持一致性，OpenAI 强制执行严格的架构不变式，而不是对单个实现进行微观管理。

严格的架构层次

每个业务域被划分为固定的一组层次，且依赖方向经过严格验证：Types \rightarrow Config \rightarrow Repo \rightarrow Service \rightarrow Runtime \rightarrow UI。横切关注点（例如 auth、telemetry）只能通过显式的 “Providers” 进入。这些约束通过自定义的、由代理生成的 linter 机械化强制执行。

编码“风格”

人类工程的 “风格”——如命名约定、结构化日志、文件大小限制——被编码进自定义的 lint 中。当规则被违反时，lint 会直接向代理的上下文注入修复指令。这使得人类的判断能够一次捕获并在整个代码库中普遍应用。

自主性与熵问题

随着开发循环被完全编码，Codex 达到了端到端自主的阈值。只需一个提示，代理现在即可复现 bug、录制失败视频、实现修复、通过驱动应用进行验证、录制解决视频，并合并 PR。

管理 “AI 低效”

完全自主会带来代理复制仓库中其他位置的次优模式的风险。为此，OpenAI 实施了 “垃圾回收” 过程：

  1. 黄金原则： 在仓库中定义了有主见的机械规则（例如，倾向使用共享的工具包而非手写助手）。
  2. 定期清理： 背景 Codex 任务扫描偏离这些原则的代码，并打开针对性的重构 PR。

社区观点与批评

虽然 OpenAI 团队将此描述为生产力的飞跃，但 Hacker News 社区提出了若干关键的反驳：

“我仍然不明白的是，为什么生成的大量代码是一种炫耀？……我认为应该尽可能优化生成的代码行数，而次要的优化应是对人类的可读性。”

批评者质疑这百万行代码库是效率的体现还是“臃肿”，并指出人类主导的方式可能以显著更少的代码实现相同结果。还有人对缺乏透明度持怀疑态度，指出具体构建的产品从未命名，且仓库保持私有。

然而，一些开发者报告了类似的代理工作流经验，指出当代理是主要作者时，严格的工程最佳实践（如类型安全和边界解析）的必要性变得 更 为关键，因为这些约束是确保大规模可靠性的唯一途径。

Sources