OpenAI 工程实践：在智能体优先的世界中利用 Codex
OpenAI 工程实践：在智能体优先的世界中利用 Codex
作者：Ryan Lopopolo（OpenAI） | 来源：openai.com
在过去五个月里，OpenAI 的一个团队进行了一项实验：构建并交付一款软件产品的内部 Beta 版，其中没有一行代码是人工编写的。
该产品有内部日常活跃用户和外部 Alpha 测试者。它经历了交付、部署、故障和修复的整个过程。与众不同的是，每一行代码——从应用逻辑、测试、CI 配置、文档、可观测性到内部工具——全都是由 Codex 编写的。据估计，他们只用了手工编写代码所需的大约 1/10 的时间就完成了这项工作。
人类掌舵。智能体执行。
从空 Git 仓库开始
首次提交是在 2025 年 8 月下旬。初始架构——包括仓库结构、CI 配置、格式化规则、包管理器设置和应用框架——是在一小套现有模板的指导下，由 Codex CLI 使用 GPT-5 生成的。就连指导智能体如何在仓库中工作的 AGENTS.md 文件本身也是由 Codex 编写的。
五个月后，该仓库已拥有约一百万行代码，约 1,500 个 Pull Request 被打开与合并，而推动这一切的只是一个由三名工程师组成的小团队。平均每位工程师每天处理 3.5 个 PR——随着团队扩大到七人，吞吐量甚至还在增加。
核心原则只有一条：不手动编写代码。
重新定义工程师的角色
早期进展比预期慢，不是因为 Codex 能力不足，而是因为环境的规范不够明确。智能体缺乏实现高级目标所需的工具、抽象层和内部结构。
工程团队的主要任务变成了：协助智能体完成有用的工作。
- 将大目标拆解为小构建模块（设计、代码、评审、测试）
- 提示智能体去构建这些模块
- 用它们解锁更复杂的任务
当事情不顺利时，解决方案不再是"再努力一点"。人类工程师介入并追问："究竟还需要什么样的能力，我们又该如何让这个能力对智能体来说既清晰可读又可强制执行？"
人类几乎完全通过提示与系统交互：描述任务，运行智能体，允许其打开 PR。Codex 会自行审核自己的更改，请求额外的智能体审查，对反馈做出响应，循环往复直到所有智能体审核者满意为止。Codex 直接使用标准开发工具（gh、本地脚本和嵌入仓库的技能）来收集情境。
提高应用程序的可读性
随着代码吞吐量增加，瓶颈变成了人工 QA 能力。团队一直在努力让应用程序的 UI、日志和应用指标对 Codex 直接可读。
例如：
- 应用程序可以根据
git worktree启动，Codex 可以为每次更改启动并驱动一个实例 - Chrome DevTools 协议被接入智能体运行时，创建了处理 DOM 快照、屏幕截图和导航的技能
- 日志、指标和追踪记录会通过本地可观测性堆栈展示给 Codex
- 智能体可以使用 LogQL 查询日志，使用 PromQL 查询指标
这使得像"确保服务启动在 800ms 内完成"或"这四个关键用户旅程中的任何跨度都不得超过两秒"这样的提示变得可行。单次 Codex 运行在单个任务上持续工作超过六个小时的情况经常出现（通常是在人类睡眠时间）。
将代码仓库设为记录系统
情境管理是最大的挑战之一。团队学到的最早教训：给 Codex 一张地图，而不是一本 1,000 页的说明书。
"一个大型 AGENTS.md" 方法失败了：
- 情境是稀缺资源，巨大指令文件会挤掉任务和代码
- 过多的指导反而变得无效——当一切"重要"时，一切都不重要了
- 它会立即腐烂，变成陈旧规则的坟场
- 很难核实——单个 blob 不适合机械检查（覆盖率、新鲜度、所有权）
正确的做法：AGENTS.md 作为内容目录，约 100 行。真正的知识库在结构化的 docs/ 目录中。AGENTS.md 被注入情境，主要用于导航，指向更深层的真实信息来源。
团队强制执行这一点：专职的 linter 和 CI 作业验证知识库的更新状态，"doc-gardening" 智能体定期扫描过时文档并发起修复 PR。
规范架构与品味
仅靠文档无法保持代码库的连贯性。团队通过强制执行不变量，而非对实施过程进行微观管理来解决问题。
每个业务域划分为一组固定的层，依赖方向经过严格验证：
Types → Config → Repo → Service → Runtime → UI横切关注点（认证、连接器、遥测、功能标志）通过单一显式接口 Providers 进入。其他任何内容都不被允许，并通过自动化方式强制执行。
自定义的代码检查器和结构测试强制执行这些规则，辅以"品味不变量"：结构化日志记录、命名约定、文件大小限制、平台可靠性要求。由于 lint 是自定义的，错误信息中注入了修复指令，直接注入智能体情境。
在以人为主的工作流程中，这些规则可能让人觉得迂腐。有了智能体，它们就成了倍增器——一旦编码，就能立即应用于所有地方。
吞吐量改变了合并的理念
随着 Codex 吞吐量增加，许多传统工程规范取得不再有效。
Pull Request 的生命周期很短。测试偶发失败通常通过后续重跑来解决，而不是无限期阻碍进展。在智能体吞吐量远超人类注意力的系统中，纠错成本低，而等待成本高。
在低吞吐量环境中这样做是不负责任的。而在这里，这通常是正确的选择。
不断提高的自主水平
随着更多开发环节被编码到系统中，仓库最近跨过了一个重要门槛：Codex 能够端到端地驱动一个新功能。
给定一个提示，智能体现在可以：
- 验证代码库的当前状态
- 重现已报告的漏洞
- 录制演示故障的视频
- 实施修复措施
- 通过运行应用程序验证修复
- 录制演示解决方案的视频
- 打开 Pull Request
- 回应智能体和人类反馈
- 检测并修复构建故障
- 仅在需要判断时才交由人工处理
- 合并更改
熵与垃圾收集
完全自主的智能体也引入了新问题。Codex 会复现仓库中已存在的模式——包括不均衡或不够理想的模式——导致漂移。
团队最初每周五花 20% 时间清理"AI 残渣"，但这不可扩展。后来他们将"黄金原则"编码到仓库中，建立了循环清理流程：
- 倾向于使用共享工具包，而非手工辅助工具，以集中管理不变量
- 不使用"YOLO 式"探测数据——验证边界或依赖类型化 SDK
- 定期运行后台 Codex 任务，扫描偏差，更新质量等级，发起重构 PR
这类似于垃圾回收：技术债务像高息贷款，持续以小额度偿还远比累积后一次性解决要好。人类的品味一旦被捕捉，就会持续应用于每一行代码。
核心启示
构建软件仍然需要纪律，但纪律更多地体现在支撑结构上，而不是代码上。保持代码库一致性的工具、抽象和反馈回路变得越发重要。
人类的工作焦点从"编写代砂"转向了：设计环境、明确意图、构建反馈回路——让智能体能够可靠地工作。
当前最棘手的挑战集中在设计环境和控制系统方面，帮助智能体实现大规模构建和维护复杂、可靠软件的目标。
原文：Harness Engineering: Using Codex in an Agent-First World | OpenAI, 2026