OpenAI "Agent First"：当工程师不再写代码，软件团队会变成什么样？

OpenAI 内部博客分享，描述用 Codex + GPT-5 开发产品的实战经验。

核心数据

• 0 行手写代码：第一版从仓库结构到 AGENTS.md 全部由 Codex 生成
• 百万行代码：5 个月后仓库规模（应用逻辑、基础设施、工具链、文档）
• 3 名工程师：完成约 1500 个 PR，平均每人每天 3.5 个
• 数百日活用户：包括每天高频使用的重度用户
• 效率提升 10 倍：如果人工手写，时间要多 10 倍

角色转变：工程师不写代码了，做什么？

重心转移：从写代码 → 系统、脚手架和杠杆

人类的新工作：

• 把大目标拆成小构件（设计、编码、评审、测试）
• 让智能体逐步搭起，再推进复杂任务
• 出了问题追问"缺什么能力"，编码进系统

四大策略：让 Agent 能独立工作

策略一：给 Agent 一个可观测的环境

• UI、日志、指标全部接入 Agent 运行环境
• Agent 能自己查日志、复现 Bug、验证修复
• 单次 Codex 运行 6 小时以上并不罕见

策略二：给 Agent 一张可导航的知识地图

错误做法：把所有规则塞进一个超大的 AGENTS.md（又长又易过时）

正确做法：

• AGENTS.md 只保留约 100 行目录，负责引路到正确位置
• 真正的知识库放进结构化的 docs/ 目录
• 执行计划、进展、决策日志、技术债都版本化留在仓库
• CI 自动检查文档时效性和结构完整性
• 维护智能体持续扫描过时文档，自动发起修复 PR

策略三：给 Agent 透明的代码库

核心原则：对 Agent 来说，运行时上下文里拿不到的信息，基本就等于不存在

具体动作：

• 知识必须进入仓库，不能散落在 Google Docs、聊天记录或人脑里
• 偏好"无聊技术"（更可组合、API 稳定、训练语料充分）
• 关键工具自己写，不依赖外部黑盒库

案例：并发控制工具 p-limit 现成可用，但团队选择自己写——因为 Agent 需要能读源码、跑测试、改逻辑

策略四：给 Agent 不能绕过的规则

三层约束：

1. 边界约束：所有进入系统的数据必须在边界上验证
2. 依赖方向：应用按固定分层组织，业务域只能沿规定方向依赖
3. 品味不变量：结构化日志、类型命名、文件大小上限、平台可靠性要求

两个突破

突破一：Agent 接手整个研发闭环

智能体不只写代码，还产出：

• 产品代码、测试、CI 配置
• 发布工具、设计历史文档
• 仪表盘定义、管理脚本
• 内部工具、评审回复

甚至：修复 Codex 自身 Bug 的补丁也是 Codex 写的

人类在回路中的新角色：

• 排优先级
• 把用户反馈翻译成验收标准
• 验证最终结果
• 智能体卡住时识别缺口、让 Codex 自己补上

突破二：Agent 端到端推动功能落地

给一个 Prompt，智能体能完成：

1. 复现 Bug
2. 修复
3. 录视频验证
4. 发起 PR
5. 处理反馈
6. 合并

中间不换人，只在确实需要人类判断时才升级。

两个新问题

问题一：吞吐量超过人类注意力，流程必须适配

• 传统阻塞式合并策略变得低效
• 采用尽量减少阻塞的合并策略
• PR 生命周期短，测试偶发抖动通过后续运行修复
• 核心原则：修正很便宜，等待很昂贵

问题二：产出越多，熵增越大，必须持续清理

• Codex 会复制仓库里已存在的模式（不管是不是最优）
• 最初每周五花一整天清理 "AI slop"
• 后来把"黄金原则"编码进仓库，建立周期性清理流程

核心原则：

• 复用共享工具
• 在入口处验证数据
• 不允许随意造轮子

自动化清理：

• 后台 Codex 任务定期扫描偏差
• 更新质量评分
• 发起定向重构 PR
• 大多数清理 PR 一分钟内审完合并

开放问题

1. 一个完全由智能体生成的系统，架构一致性能否在多年尺度上维持？
2. 人的判断到底应该放在哪些位置，才能产生最大杠杆？
3. 这些判断又该怎样被编码成会持续积累的资产？

核心洞察

"软件开发仍然需要纪律，只是纪律越来越多地体现在脚手架，而不是具体某一行代码上。"

"真正重要的，是那些维持代码库一致性的工具、抽象和反馈回路。"

---

这是一个关于 AI 编程未来形态的前瞻性实践报告，值得所有软件工程师关注。

#记忆 #小凯 #AI编程 #Codex #OpenAI #AgentFirst #软件工程 #未来工作