工程技术：在智能体优先的世界中利用 Codex

OpenAI Engineering / Ryan Lopopolo · 2026-03-11 · Original

来源: OpenAI Engineering / Ryan Lopopolo | 日期: 2026-02-11 原文: 工程技术：在智能体优先的世界中利用 Codex 精读日期: 2026-03-11

一句话总结

OpenAI 内部团队用 Codex 从零构建了一个百万行代码的产品（人类零行代码），核心发现是：工程师的价值从”写代码”转移到了”设计让 agent 能成功的环境”。

核心内容

实验设定与成果

3 名工程师，5 个月，从空 Git 仓库开始，所有代码由 Codex 生成——包括应用逻辑、测试、CI、文档、内部工具、可观测性配置。核心纪律：不手动编写代码。

指标	数据
代码量	~100 万行
PR 数量	~1,500 个
团队规模	3→7 人
人均日 PR	3.5 个（扩到 7 人后更高）
效率估算	手写的 ~1/10 时间
用户	数百名内测用户，含日活高级用户

工程师角色重定义

人类不写代码后，工作重心转向系统、架构和杠杆。早期进展慢不是 agent 不行，而是环境规范不够明确——agent 缺乏完成高级目标所需的工具和抽象层。

工作模式变为深度优先：拆解目标 → 提示 agent 构建模块 → 用模块解锁更复杂任务。当事情不顺，解法不再是”再努力一点”，而是”还缺什么能力，怎么让它对 agent 清晰可读？”

AGENTS.md：地图而非百科全书

一个大型 AGENTS.md 失败的四个原因：

情境是稀缺资源 — 巨大指令文件挤掉了任务和代码的空间
过多指导反而无效 — 当一切都”重要”时，一切都不重要
立即腐烂 — 庞杂手册变成陈旧规则的坟场
难以核实 — 单个 blob 无法机械检查覆盖率和新鲜度

正确做法：~100 行的 AGENTS.md 当目录，指向 docs/ 下的结构化知识库。包括设计文档（带索引和验证状态）、执行计划（活跃/已完成/技术债）、架构文档、产品规格等。实现渐进式披露：agent 从小而稳定的切入点开始，被指导下一步去哪看。

用 linter 和 CI 严格验证知识库的更新状况。一个定期运行的”doc-gardening” agent 扫描过时文档并发修复 PR。

Agent 看不到的就不存在

存在 Google Docs、Slack 聊天、人脑中的知识对 agent 不可见。那次让团队在架构上达成一致的 Slack 讨论？如果 agent 发现不了，就像迟了三个月入职的新员工。解法：所有重要信息必须以 Markdown 形式编码到仓库中。

让应用对 agent 可读

应用可按 git worktree 启动，每次改动起一个独立实例
接入 Chrome DevTools 协议，agent 能截图、操作 DOM、验证 UI
接入完整可观测性栈（Victoria Logs/Metrics/Traces），agent 用 LogQL/PromQL/TraceQL 查询
每个 worktree 的可观测性数据是临时的，任务完成即删除
单次 Codex 运行经常持续 6+ 小时（通常在人睡觉时）

用约束而非微观管理

通过强制执行不变量保持连贯性，而非管具体实现。例如要求”在边界处解析数据形状”，但不规定用什么库（agent 偏好 Zod）。

严格的分层架构：Types → Config → Repo → Service → Runtime → UI。横切关注点通过单一 Providers 接口进入。自定义 linter（Codex 生成）和结构测试机械化执行，错误信息里嵌入修复指令。

关键洞察：“对人类觉得迂腐的规则，对 agent 是乘法器——一旦编码，立即应用于所有地方。”

同时明确不限制的地方：在边界内允许 agent 自主选择解决方案。生成的代码不总符合人类风格偏好，但只要正确、可维护、对未来 agent 可读，就算达标。

吞吐量改变合并理念

PR 生命周期短，尽量减少阻塞合并门。偶发测试失败通过后续重跑解决而非无限期阻碍。在 agent 吞吐量远超人类注意力的系统中，纠错成本低，等待成本高。

Agent 已能端到端工作

给定一个提示，agent 可以：验证现状 → 复现 bug → 录视频 → 实施修复 → 验证修复 → 录第二个视频 → 开 PR → 响应反馈 → 修构建 → 合并。仅需要人类判断时才上报。

熵与垃圾回收

Agent 会复现仓库中已有的模式——包括不好的。最初每周五人工清理”AI 残渣”——不可扩展。改为将”黄金原则”编码到仓库，定期跑后台 Codex 任务扫描偏差、更新质量评分、发重构 PR。大多数一分钟内审完自动合并。

类比：技术债是高息贷款，小额持续偿还比积累后痛苦清算好得多。

金句摘录

“人类掌舵，智能体执行。”
“要给 Codex 的是一张地图，而不是一本 1,000 页的说明书。”
“智能体在运行时无法在情境中访问的任何内容都是不存在的。”
“在以人为本的工作流程中，这些规则可能会让人感到迂腐或束缚。有了智能体，它们就成了倍增器。”
“纠错成本低，而等待成本高。”
“构建软件仍然需要纪律，但纪律更多地体现在支撑结构上，而不是代码上。”

Justin 视角

对投资判断的参考价值

“Agent-native 工程”正在形成新范式 — 这不是用 AI 辅助写代码，而是从零重建软件工程方法论。投 AI infra/devtool 赛道时，要看项目是在”增强人类写代码”还是在”构建 agent 能成功的环境”，后者是更大的范式转移。
开发者工具市场将重塑 — 文中提到 agent 偏好”枯燥技术”（API 稳定、训练集表现好），甚至宁可自己重写也不用不透明的上游库。这意味着 npm 生态里大量”方便人类”的包可能被 agent-native 替代品取代。新的 devtool 投资逻辑：对 agent 可读性 > 对人类易用性。
可观测性赛道利好 — agent 需要比人类更丰富的运行时反馈（日志、指标、追踪），而且是程序化消费而非看 dashboard。Datadog/Grafana 类产品需要 agent-first 的 API 层。

与当前工作的关联

直接映射到 CC 系统设计 — 文中的 AGENTS.md 地图模式 ≈ Justin 的 CLAUDE.md 入口 + memory/ 路由。“看不到就不存在”原则 = 所有决策必须落到仓库。已经在正确方向上。
可改进点：文中强调用 linter/CI 机械化执行约束，而非靠 prompt 叮嘱。CC 系统目前更多靠文字指令，可以考虑更多自动化检查（如 memory 文件格式校验、日记完整性检查）。
“垃圾回收”模式 — 定期跑 agent 清理技术债，可以应用到 memory 系统：定期扫描过时记忆、矛盾记忆、冗余记忆。

可行动的 takeaway

评估 portfolio 中的 devtool 公司是否在做 agent-native 适配
OPC 知识库设计可参考”渐进式披露”模式
考虑给 CC 系统加一个定期”记忆清理” agent 任务