OpenAI造Codex的工程决策：Rust选型、开源与全自动代码审查

OpenAI旗下Codex已成为当下最流行的AI编程工具之一，活跃用户突破2000万。在Pragmatic Engineer的这期深度访谈中，Codex团队负责人Thibault详细拆解了这款产品从内部研究项目走向大规模落地的全过程——为什么选用Rust、为何坚持开源、代码审查如何被重构，以及维护成本变得极低后软件工程正在发生的深层变化。

为什么用Rust构建Codex

Codex早期做了一个反直觉的决定：核心Agent用Rust编写。而当时的模型对Rust并不友好——它在Rust上的表现远不如Python或TypeScript。绝大多数其他厂商的编程Harness恰恰是构建在模型更擅长的TypeScript或Python之上。

Thibault解释了背后的工程考量。团队从一开始就把「产品界面」和「Agent核心」视为两个不同的东西。Agent核心需要健壮、安全、为效率和规模而生。他有着多年将「有趣原型」扩展到「最大数据中心规模」的经验，深知早期决策的分量：「早期的决定往往会变得非常重要，只要你不牺牲太多速度。」

Rust的静态类型验证在编译期就能捕获大量问题，这对Agent同样是巨大优势。更关键的是，Rust边界形成了一道天然的架构分隔——如果所有东西都写在同一个代码库、同一种语言里，「你会变得有点草率，会把不该纠缠的东西纠缠在一起，进而阻碍后续的创新」。

他坦言即便用TypeScript或Python起步、日后重写也能成功，但清晰的Agent与产品分离是一条重要原则。这印证了一个观点：在Agent时代虽然重写代码变得更容易，但正确的脚手架和架构基线仍能帮你省下大量返工。

Rust是Mozilla于2010年发布的系统编程语言，其核心设计目标是在不依赖垃圾回收器的前提下同时实现内存安全与高性能。Rust通过「所有权（Ownership）」和「借用检查器（Borrow Checker）」机制，在编译期静态排除空指针解引用、数据竞争、内存泄漏等一整类运行时错误。这使得Rust程序在部署后极少出现因内存问题引发的崩溃或安全漏洞。对于一个需要在生产环境中稳定执行任意代码、同时管理大量并发任务的编程Agent而言，这类编译期保证尤为关键——一旦Agent在沙箱中运行出错，代价远高于普通应用崩溃。此外，Rust没有运行时开销、可精确控制资源分配，便于在数据中心规模下部署时优化延迟和吞吐量。代价是学习曲线陡峭、开发速度初期较慢，这也是绝大多数AI工具团队优先选择Python或TypeScript的原因。

开源的收益与代价

Codex的CLI、SDK和App Server全部开源，这在主流实验室中相当独特——一些竞争对手反而选择闭源的Harness。Thibault给出的理由很直接：你构建的本质是一个编程Agent，那就应该让它指向自己、让社区贡献者用它来改进它。

更深层的判断是：如果Codex会成功，那么开源本身和代码的角色都会改变，与其置身事外，不如成为社区的一部分。「如果你不亲眼见证问题，就很难解决问题。」

一年半后回看，开源带来的收益很实在。仓库小而透明，新人入职前就看过PR，「onboarding基本已经完成了」——你只需用Codex阅读仓库并提问就能立刻上手。此外还有大量优质社区贡献，以及作为社区一员带来的团队能量。

但代价同样真实。开源代码与内部主代码库分离，有时不得不划出人为边界、跨多仓库工作。最扎心的是：当你在公开场合做某个激动人心的功能时，别人可能在你发布之前就抄走并抢先上线。「这有点让人难过，但也是游戏规则的一部分。」再加上海量低质量贡献带来的额外「税负」，需要团队持续投入去应对。

值得一提的是，Codex并未绑定OpenAI自家模型，可以接入其他模型。Thibault认为这是自然而然的选择：既然已经开源，任何人都能轻易fork并加上对其他模型的支持，与其逼用户去用fork版本、还丢失反馈，不如直接原生支持。这也倒逼整家公司必须在模型层和Harness层都靠真本事竞争，而非靠锁定。

云端执行与本地开发的融合

目前Codex默认在本地机器的沙箱中运行，任何需要额外权限的命令都会询问用户。但这一模式正在演进——你可以选择在云端的托管VM(kata容器安全环境)中运行，输出流式传回本地，从而释放本机CPU、实现更大规模的扩展。

Thibault回顾了云开发环境(Cloud Dev Box)的历史：2022-2023年它一度火热，但在大型科技公司之外从未真正普及，因为前期成本和维护成本太高，单个开发者或小团队难以受益。而现在Agent能力足够强，这些配置和同步工作完全可以交给模型自动完成。

他描绘的方向是：模型越强，就能利用越多的计算和资源，远超本地机器所能提供，因此限制在本地执行终将成为约束。团队正在探索本地与云端的混合执行，让开发者摆脱「必须一直开着笔记本」的束缚——就像ChatGPT work已经可以在手机上边喝咖啡边口述任务、访问日历邮件Slack并自动完成一样。

Kata容器（Kata Containers）是一种将轻量级虚拟机（VM）与容器接口相结合的安全沙箱技术，由Intel Clear Containers和hyper runV项目合并演进而来，现为CNCF项目。与传统Docker容器共享宿主机内核不同，Kata容器为每个工作负载启动一个独立的微型VM内核，从而在容器的部署便捷性与虚拟机的强隔离性之间取得平衡。对于执行AI生成的任意代码这一场景，内核级隔离可以有效防止恶意或意外代码逃逸至宿主系统，攻击面显著小于仅靠cgroups和namespace隔离的普通容器。这也解释了为什么Codex在云端托管执行时选用kata容器作为安全边界——当Agent拥有网络访问、文件系统写权限和shell执行能力时，运行时隔离的强度直接决定了平台的安全基线。

Harness总是领先模型一步

关于Harness与模型如何协同进化，Thibault给出了一个精妙的判断：Harness在某种意义上总是领先模型一步。

模型具备某些能力，但你需要给它套上一些「拐杖」，让它能以足够的可靠性和符合用户预期的行为完成任务——这正是Harness的角色：提供护栏、可控性，以及每轮对话开头注入上下文的developer message。

以「运行测试」为例：早期模型不会自动跑测试，你得反复提醒；后来训练出更好的模型，它能更好地反思用户真正想要什么，于是不再需要你提醒。随着模型变强，developer message在缩短，Harness也在缩短。

团队据此制定目标：面对一个需求，先判断「这该是Harness的改动还是模型的改动」，如果是模型改动，评估一个月、三个月还是半年能实现——有时甚至干脆等模型自己解决，不在Harness里做任何事。整个过程「都是Agent」：他们用Agent分析海量用户反馈、归纳主题、辅助决策优先级，覆盖编程、金融、通信、市场营销等所有用户使用Agent的领域。

「Harness」在AI Agent语境中指围绕语言模型构建的执行框架，包括工具调用接口、上下文注入逻辑、错误重试策略、输出解析规则等。它并非模型本身，而是驱动模型完成特定任务的「脚手架」。Developer message（系统提示）是Harness注入给模型的初始指令，用于设定角色、约束行为、提供环境信息。Thibault描述的「Harness领先模型一步」现象揭示了一个产品开发中的重要规律：当模型能力不足时，Harness通过显式指令补偿；当新一代模型将这些指令内化为默认行为后，对应的Harness逻辑就可以删除。这意味着Harness的复杂度是模型能力的反函数——模型越强，Harness越薄。对工程团队而言，这要求在设计功能时始终区分「应由模型学会的」和「需要Harness兜底的」，避免过度工程化导致未来难以删除的技术债。

代码审查的角色正在改变

在Codex团队内部，新人最常听到的一句话是「你问过Codex了吗？」。Codex默认接入了Slack、所有文档和代码，了解项目状态、谁在做什么、某个决策为何做出——它几乎无所不知。团队为此刻意在公开频道工作、开放较宽泛的文档权限，让Agent能够推理。

关于代码审查，Thibault的观点很有冲击力：其角色正在改变。团队早期就开发了代码审查模型，能发现逻辑和推理层面的错误，深挖三四层依赖、识别文档与第三方实现不符导致的不变量破坏——这些问题人类专家可能要花数小时才能捕获。如今这些能力已并入主线模型，在基准测试中「代码审查是超人级的」，不仅是正确性，安全性同样如此。目前OpenAI所有PR的安全检查已强制自动化，发现安全问题会直接阻止合并。

他认为代码审查历来有三重价值：正确性、安全性，以及一种「信息交换的小仪式」——让大家达成共识、引发讨论。前两者正在被自动化，而剩下的核心是围绕「意图」的讨论：你到底想做什么、这么做对不对。而这种讨论不一定非要发生在PR周围。

更进一步的模型是「盒子」抽象：只要在资源使用、数据访问、安全等方面有严格保证，盒子内部可以是任何东西，你无需关心；真正需要达成一致的是「盒子做什么」以及必须满足哪些不变量。一旦确定，盒子内部的任何改动都不再需要讨论，从而保护你的注意力。

「盒子与不变量」是软件工程中模块化设计的核心思想，在形式化方法与契约式编程（Design by Contract）中有严格定义。不变量（Invariant）指一个模块在其生命周期内必须始终满足的条件，例如「队列长度永远非负」或「用户认证令牌在写入数据库前必须经过加密」。「盒子」则是封装了内部实现、仅通过明确接口与外界交互的抽象单元。当盒子的接口和不变量被清晰定义并经团队达成一致后，盒子内部的任何重构（包括AI生成的大规模改写）都无需逐行代码审查，只需验证不变量是否仍然成立。这一思想在AI辅助开发时代变得尤为重要：模型可以快速生成或重写大量代码，但如果没有清晰的不变量作为验证锚点，生成速度越快、引入隐性错误的风险也越高。将人类讨论聚焦于「盒子做什么」而非「每一行怎么写」，是在高速迭代中保持系统可靠性的关键策略。

维护变便宜后，软件工程如何变化

「构建是有趣的部分，维护才是痛苦的」——这是各家公司(Google、Uber乃至创业公司)共同的教训。Thibault认为维护正在发生质变。

维护本质是一种「随时间支付的税」，比如升级第三方依赖版本号——只要有良好的变更日志和文档，模型就能在几小时内推理并横扫整个代码库完成，而过去这类「不好玩但对业务重要」的事往往被搁置。安全补丁的及时应用尤其关键，这部分将被完全自动化，大部分维护「几乎免费」。

更令人兴奋的是重架构成本的骤降。过去因新的权衡、新的负载理解或新功能而彻底重构系统，可能耗时数年、代价高昂；如今这一过程被极大加速。但Thibault强调软件工程的老规矩依然重要：良好的抽象、正确的「盒子与不变量」形状，能让你在盒子内快速迭代而不影响其他服务。

他特别提到一个变化：架构设计、长期可维护性的思考，过去主要是架构师或资深工程师的职责，现在所有工程师都需要具备这种意识，并在构建软件时提前规划。而GPT模型也在越来越擅长思考长期维护——不只是单个文件的代码整洁，而是架构是否正确、能否为未来功能扩展预留空间。

软件的生命周期被极大压缩。过去一个成功项目一年后可能有50到100名工程师，你有时间看着它成长、招人、写文档；现在一个周末就可能有100个Agent同时贡献，你是在极高的速度下推进。

对于「模型学会了我擅长的事会不会有些失落」，Thibault坦言偶尔仍会打开编辑器手写代码、享受那种心流。但他的核心信念是：如果你把代码视为解决问题的工具，那么能解决的问题多得多，这只会让你成为更好的工程师。OpenAI远未耗尽问题，在数学突破、科学突破和服务人类方面还有漫长的路要走。

给工程师的建议

关于如何具备加入Codex这类团队的能力，Thibault给出两点：一是对事物运作方式的深度好奇心，以及快速理解系统的能力——能迅速grok一个系统、钻进陌生代码库并理清它，多问「五个为什么」，越挖越深、学得越快；二是与你要服务的社区保持同频，对品味、需求和要求足够清晰，并能清晰地表达意图。

「如果你无法解释你想实现什么、无法解释你的意图、没有与社区的联系、没有品味，就很难做出优秀的工作。」在AI大幅加速一切的时代，基本功依然至关重要。