本文作者：meng shao（@shao__meng）。版权归作者所有，未经授权禁止转载。

深度解读「Building Codex」

The Pragmatic Engineer（@GergelyOrosz）主持的一期深度访谈，嘉宾是 Tibo Sottiaux @thsottiaux，OpenAI Codex 团队的负责人之一，也是 Codex 从内部研究项目成长为最受欢迎 AI 编码工具之一的全过程亲历者，因为负责 Codex 额度重置工作，被戏称为「Codex 掌管 RESET 的神」。整期对话围绕一条主线展开：当 AI 深度介入软件开发，工程团队的决策方式、组织文化和工程师的角色正在发生怎样的变化。

嘉宾其人：从布鲁塞尔乡间到 Codex 负责人

Tibo 的职业轨迹本身就是一个有趣的故事。他在布鲁塞尔出生，8 岁时随父母搬到一个人口约 200 人的小村庄，因为身边缺乏玩伴，电脑成了他认识世界的窗口。他攻读应用数学，读书期间就开办小型咨询公司，为银行做供应链优化、蒙特卡洛模拟这类随机多阶段优化问题，后来还创办了一家专注医药临床试用供应链的初创公司——用传统数学优化而非机器学习来决定药品生产和配送，减少浪费。这家公司至今仍在运营。

之后他去了伦敦，先后在 Google 和 DeepMind 工作近十年。访谈中他讲了一个此前鲜为人知的故事：早在 ChatGPT 发布一年多之前，他就参与在 DeepMind 内部搭建了一个类似的聊天机器人​。当时 DeepMind 的主流方向是强化学习和游戏（AlphaGo 前夜），但有一个小组坚持押注“把语言模型推到极限是否就足以通向通用智能”。Tibo 为研究者构建调试模型的工具，自然而然演化出了内部聊天系统。它像野火一样在 DeepMind 内部传播，人们分享与模型的对话截图，它“感觉已经超出了研究项目的范畴”。但受限于 Google 的产品发布机制和保守的生产技术栈，这个项目最终没有走向外部——这也成了他后来离开的伏笔之一。

他还分享了一个早期教训：在 Google 第一个项目（让移动端网页变快，隶属广告部门）做了两年后被突然砍掉，VP 从加州飞来宣布“你们只有几百个用户，这显然不是 Google 的规模”。他学到的功课是：永远质疑项目的真实影响，不要轻信“一切进展顺利”的汇报。

2024 年他加入 OpenAI。打动他的细节是：当时 ChatGPT 这样规模的产品背后只有约 20 名工程师​。这种极致的精简和自主权，加上研究与产品共同设计的模式，让他下定了决心。入职后立刻赶上 o1 推理模型的冲刺发布。

Codex 的起源：一个“内部工具”的意外转身

Codex 的起点并不是产品，而是一个利己的内部项目。Tibo 加入后专注研究基础设施，他和同事训练内部模型，专门让模型精通 OpenAI 自己的 Python 代码库，具备“好的架构品味和代码风格品味”，目的是用模型帮 OpenAI 自己的开发提速​。

转折点来自 Greg Brockman（Greg）的坚持：这件事不应该只服务于 OpenAI 自己，也应该做成面向世界的产品。于是这个研究项目与内部的 "A3"（autonomous software engineer，自主软件工程师）项目合并，才有了后来对外发布的 Codex。早期的云端版 Codex 因为交互摩擦太大并没有找到产品市场契合点，而 CLI 版本则延续了下来。

三个反直觉的工程决策

1. 用 Rust 写，而模型当时并不擅长 Rust

当时主流 AI 编码工具（Claude Code、Cursor 等）几乎都用 TypeScript 或 Python 构建，因为模型在这些语言上能力最强。Codex 逆势选择 Rust，Tibo 给出的理由是：

  • 从第一性原理出发，把产品界面和 agent 内核当作两个不同的东西来设计。内核必须健壮、安全、面向效率和规模构建——这是他多年做大规模基础设施工程沉淀的判断；
  • Rust 的编译期静态验证对 agent 生成的代码本身就是一种约束和护栏；
  • 团队有很强的 Rust 工程师，内部模型在 Rust 上“不算差”。

他补充了一个关键的架构观点：“Rust 边界”本质上是一条强制性的架构分界线​。如果所有东西用同一种语言写在同一个代码库里，边界 inevitably 会变得含混；一门不同的语言物理上隔离了 agent 内核与产品外壳。同时他也坦承，用 TypeScript 甚至 Python 也可能成功，只是“会在某个时刻重写”。

2. 开源，且接受被抄袭的代价

Codex 的 CLI、SDK 和 app server 全部开源，这在几大实验室中独一无二。Tibo 讲得很坦诚，好处是：

  • 新员工入职即完成大半 onboarding——他们入职前就看过仓库、读过 PR，“用 Codex 把仓库问一遍就能直接上手”；
  • 获得高质量社区贡献，并真正参与“代码与开源的角色正在改变”这一进程，而不是置身事外。

代价同样真实：功能在开发中就被竞争对手抄走、甚至抢在发布前上线，“确实有点疼，但这是你在公开构建时签下的契约”；此外还要应对海量低质量 PR 的“海啸税”。

3. 模型无关：不锁定自家模型

Codex 可以接入其他厂商的模型。Tibo 的解释很直接：如果你在做社区中最好的编码 harness，把它锁死在自家模型上“是一个令人失望的决定”。反正任何人都可以 fork 掉 10 行代码加上其他模型支持——那不如直接官方支持。更深层的态度是：“我想靠模型最好、产品最好来赢得用户，而不是靠锁定。如果靠锁定赢，也吸引不来最优秀的工程师来做这个产品。” 这种可选择性（optionality）在与企业客户合作时也是重要的卖点。

核心洞察之一："Harness 永远领先模型一点"

这是整期访谈中信息密度最高的部分，回答了开发者最困惑的问题：Codex 的迭代到底是在改进工具还是改进模型？

Tibo 的回答是：harness 的作用是给模型提供“拐杖”——沙箱、权限控制、每轮注入的 developer message 等——让当前能力有限的模型达到可接受的可靠性和效率。随着下一代模型经过针对性训练，developer message 会收缩，harness 也会收缩，拐杖被一根根丢掉​。

一个具体例子：早期用户要手动提醒 Codex 跑单元测试，后来模型被训练得能自己反思“用户真正想要什么”，提醒就不需要了。

取舍机制是这样的：团队发现问题后先判断“这是 harness 问题还是模型问题”；如果模型三个月内能解决，harness 可能干脆不动、等模型。整个分析流程本身也是“agents all the way”——用 agent 分析用户反馈、归纳主题、辅助排序优先级。

主持人 Gergely 在结尾点评时提出了一个有意思的保留意见：这个“拐杖理论”对 harness 工程师来说有点令人沮丧（你建的东西下个版本就被模型学会了），而且并非所有 harness 工作都是拐杖——模型不会自己发明 MCP 协议、插件机制这类真正的基础设施。

/goal 命令就是一个例证：它是为了让模型长时间锁定单一目标而设的拐杖，允许任务跑几天甚至几周；而新一代模型已经可以“直接告诉它去干一周，它就真的会干一周”，不再需要这个命令。

核心洞察之二：软件开发生命周期正在被重写

当新工程师加入 Codex 团队，听到最多的回答是：“你问过 Codex 了吗？” 在 OpenAI 内部，Codex 接入了 Slack、所有文档和全部代码。了解一个项目的现状、谁在做什么、某个决策为什么这样定——直接问 agent 就行，30 分钟内几乎任何问题都能得到答案。团队因此刻意在公开频道工作、给文档开宽松权限，让每个人的 agent 都能读到。

在发布流程上，最反常识的事实是：Codex（2000 万活跃用户）和 ChatGPT（十亿级用户）的发布流程几乎一样——一个 PR 当天或次日就能推到十亿用户面前。支撑这一点的是几乎全自动化的代码评审、部署和回归捕获，以及“被显著降低的维护成本”。团队要求的是变更的“证据”：值得做、会被良好接收、值得长期维护。

代码评审的重新定义

Tibo 曾在 Google 亲历过业界最严苛的双层代码评审文化，他的判断是：评审中关于正确性和安全性的部分正在被自动化，而且模型在这些方面已是“超人”级别——模型能钻进三四层依赖深处，发现文档与第三方实现不符导致的不变量破坏，这是人类专家不花数小时也抓不到的问题。OpenAI 现在已强制要求：PR 若被模型标记安全漏洞，自动阻断合并。

人类评审中幸存下来的部分，是关于“意图”的讨论——“你到底想做什么？这件事值不值得做？”只是这种讨论未必要围绕代码进行。Tibo 设想的未来形态是“黑盒契约”：团队就一个模块的对外行为和不变量（资源上限、数据访问边界、安全约束）达成共识，盒子内部是什么则不必关心。这同时保存了工程师最稀缺的资源——注意力。

维护成本的坍塌

维护被 Tibo 定义为“为了维持运转而持续缴纳的税”。他的判断是这部分将大量自动化：升级依赖版本这类过去被无限拖延的事，agent 几小时就能横扫整个代码库完成——这对安全补丁尤其关键。架构重构这个过去动辄以年计的工程，成本也在急剧下降​，因为“犯错的代价在降低”。但经典软件工程的规律并未失效：好的抽象、清晰的边界（“画对盒子的形状”）依然让你改得更快。

Gergely 观察到一个正在压缩的时间维度：过去一个项目从 2 人增长到 100 名工程师需要一年，你有时间消化；而现在“一个周末就能涌进 100 个 agent 贡献者”——软件以远超组织惯性的速度走完生命周期。

团队的北极星

Codex 的长期愿景被描述为：一个用起来愉悦、简单的个人 AGI——了解你、接入你的日历与邮件、能替你执行有风险的动作（事后推送通知让你核验）、主动建议、可用自然语言和语音操控，“而不是一个有 10 个按钮和一堆配置项的东西”。

The Merge：把本地 agent 塞进十亿用户的云产品

Codex 合并进 ChatGPT 这件事，从外部看“只是多了一个入口”，内部却是一次架构级工程：ChatGPT 是完全托管、传统云架构、为规模和效率优化；Codex 则完全本地。合并的实质是把完整的 Codex harness 搬进云端 VM（kata 容器隔离的强力机器，有网络访问），做成能以极低成本服务数亿人的版本——效率要做到能塞进 20 美元/月的 Plus 套餐。用户甚至在里面装过 Blender 做 3D 建模、训练过模型。

Tibo 还提到一个颇有趣味的细节：整个合并过程中，Codex 自己充当了“记者”——因为它接入所有 Slack 讨论和文档，团队让它全程记录了每场争论和决策。这段历史后来被戏称为 OpenAI 的"toggle arc"（ChatGPT 里 work 模式开关的争议）。Gergely 在总结中坦言，这部分让他有点“老大哥在看着你”的不适感，但也承认这可能成为创业公司的新常态。

默认执行环境的演变方向也讲得很清楚：目前本地沙箱执行仍是默认（命令需要沙箱外权限时会询问用户），但随模型能力增长，本地机器的算力终将成为瓶颈，未来会出现笔记本与云端的混合执行。他同时预测云开发环境（CDE）将迎来复兴——过去 CDE 在大厂之外失败是因为高昂的搭建与维护成本，而现在“agent 替你搭建和同步环境，成本近乎为零”；他自己的日常就是早上对着手机用语音给 ChatGPT work 模式布置一堆任务，然后不带电脑到处走。

关于人的部分

面对 Gergely 直接的提问——“你引以为傲的手艺被模型一件件拿走，不难受吗？”——Tibo 的回答有两层：他承认手艺的情怀（深夜、Vim、可乐，只为眼前的问题而活），但随即指出这份记忆被美化了：同样是那些深夜，也有重构三小时后发现死路、被迫推倒重来的挫败。真正让他兴奋的是“代码只是解决问题的工具，而现在能解决的问题多了一个数量级”——想跑个基准测试？30 秒扔给后台，不再纠结。他说在 OpenAI 还没遇到一个人觉得这种变化“不好、不有趣”。

他的个人工作方式已经高度移动化：大量使用语音输入，把问题直接“发射”给 ChatGPT work，拿到按他偏好定制的报告和幻灯片；周末用 Codex 做原型探索，“一天之内把脑子里的想法变成可以拿给团队批评的东西”。

给工程师的建议只有两条，朴素得几乎不像 AI 时代的话术：其一，对事物运作原理的深层好奇心，以及快速 grok 一个新系统的能力；其二，与你所服务的人群保持同频，能清晰地解释你的意图——"如果你解释不清你要达成什么、没有品味、不泡在社区里，就很难做出伟大的工作。"基础功依然重要。