[控场AI]
· 9 分钟阅读· 4,985 字

OpenAI Codex负责人揭秘:AI编程智能体如何重塑研发流程

OpenAI Codex负责人揭秘:AI编程智能体如何重塑研发流程

OpenAI Codex负责人深度揭示:从Rust架构决策、harness与模型的协作哲学,到AI如何重构整个软件研发流程。

本文整理自《The Pragmatic Engineer》播客对OpenAI Codex团队负责人Thibault的深度访谈。Codex从一个针对内部代码库的研究项目(A-SWE)演化为活跃用户破2000万的产品,其背后有多项反直觉的技术决策:核心用Rust构建以获得编译期安全保证和架构隔离,以及全面开源并不绑定自家模型。访谈的核心洞见是「harness永远领先模型一步」——工具层通过「拐杖」机制补足当前模型能力,随着模型变强,harness和系统提示都在收缩。在研发流程层面,代码审查的正确性与安全性正被AI自动化并超越人类水平,人类审查的价值向「意图讨论」转移;重构成本大幅下降,良好的架构抽象能力因此变得对所有工程师都至关重要。Thibault对工程师的建议是:保持对系统运作原理的深度好奇心,以及清晰表达意图的能力。

OpenAI Codex已经成为当下最流行的AI编程工具之一,活跃用户突破2000万大关。但它究竟是如何从一个内部研究项目演变成面向数亿用户的产品?在《The Pragmatic Engineer》播客的一期深度访谈中,Codex团队负责人Thibault分享了这个工具背后的技术决策、团队文化以及AI对软件研发流程的深刻改变。

从内部工具到开源产品:Codex的诞生

Thibault的技术生涯颇具戏剧性。他八岁时因为父母搬到只有200人的比利时小村庄,「别无选择」地迷上了计算机。大学攻读应用数学,创办过做医药供应链优化的初创公司,后来辗转Google Maps、DeepMind,最终加入OpenAI。

一个鲜为人知的故事是:早在ChatGPT发布前一年,Thibault就参与过DeepMind内部一个类似ChatGPT的聊天机器人项目。那个工具在内部「像野火一样」蔓延,大家互相分享对话截图,但DeepMind当时并没有把它推向市场的产品机制。这段经历某种程度上解释了他后来加入OpenAI的动机——他想加入一个研究与产品真正协同设计的团队。

加入一个所有参数被统一考量的团队

Codex的前身是内部代号A-SWE(autonomous software engineer,「自主软件工程师」)的项目。团队最初训练专门针对OpenAI Python代码库的内部模型,目标是让研究人员写代码更快。在Greg Brockman和Sam Altman的支持下,尤其是Greg坚持「不只服务自己,也要造福世界」的理念,这个内部研究项目最终演变成了产品。

为什么用Rust构建,又为什么开源?

Codex的一个反直觉决策是用Rust语言构建核心,尽管当时模型对Rust的支持并不如Python或TypeScript成熟。Thibault解释了背后的第一性原理思考:团队从一开始就把「产品界面」和「智能体核心」当作两个不同的东西来设计。

「早期的决策往往非常重要,只要不过度牺牲开发速度。」他指出,Rust带来编译期的静态验证,这对智能体来说是巨大的优势——很多错误在编译时就能捕获。更关键的是,Rust边界形成了一种天然的架构隔离:如果所有东西都写在同一个代码库、同一种语言里,「不可避免会变得有点草率,把不该纠缠的东西纠缠在一起」,从而阻碍后续创新。

另一个独特决策是开源。Codex的CLI、SDK和app server全部开源,且不绑定OpenAI自家模型,用户可以搭配其他厂商的模型使用。这在各大实验室中相当罕见——竞争对手往往推出闭源的编程工具(harness)。

Thibault坦言开源既有收益也有代价。收益是:新人入职几乎不需要培训,因为他们早就看过代码库和PR;社区贡献带来能量和好点子。代价则同样真实:核心代码与公司其他代码分离,有时要跨多个仓库工作并画出「人为的边界」;更让人「有点心痛」的是,团队在公开构建某个功能时,「有时别人会在我们发布前就抄走」。此外还要处理海量低质量的随机贡献这一「额外税负」。

竞争让工具无法躺平

关于不绑定自家模型,Thibault的逻辑是「靠实力赢得用户,而不是靠锁定」。既然代码开源,任何人都可以fork后加10行代码支持别的模型提供商,那还不如一开始就原生支持。这也倒逼整个公司在模型层和工具层都保持竞争力,无法「躺平」。

Rust语言的核心优势在于其「所有权」(ownership)内存模型——编译器在编译阶段强制检查内存安全和并发安全,消除了悬空指针、数据竞争等一整类运行时错误。对于一个需要长时间自主运行、调用外部工具和系统资源的AI智能体而言,这意味着许多潜在的崩溃和不确定行为能在代码发布前就被拦截。相较之下,Python虽然灵活、模型生态丰富,但其动态类型和GIL(全局解释器锁)的特性更适合快速原型,而非需要高可靠性的智能体核心。「开发者体验换取运行时可靠性」是Rust社区长期倡导的取舍,Codex团队的选择正是这一哲学在AI基础设施层的体现。值得注意的是,这个决策在当时具有一定的前瞻性风险:2021年前后大语言模型对Rust代码的理解和生成质量明显弱于Python,团队相当于用短期的工具链成本换取了长期的架构健康度。

工具(Harness)永远领先模型一步

访谈中最有洞察的观点之一,是Thibault对「harness与模型关系」的描述:harness总是比模型领先一步。

他解释道,模型具备某些能力,但你需要用一些「拐杖」(crutches)来帮它把事情真正做好——达到可靠、高效、符合用户预期的水平。这正是harness的职责:提供护栏、安全保障,让模型更可控、更高效。harness还负责在每个回合开始时注入「开发者消息」(developer message),影响智能体的行为。

举个具体例子:早期Codex改完代码不会自动运行单元测试,用户得手动提醒。后来团队训练出更懂「用户真实意图」的模型,就不再需要提醒了。随着模型能力提升,开发者消息在收缩,harness本身也在收缩。

这带来一个有趣的团队工作方式。当团队想实现某个能力时,会自问:这应该是harness的改动,还是模型的改动?如果是模型改动,多久能实现——一个月?三个月?半年?根据答案决定是否在harness上先做临时方案,或者干脆等模型解决。团队用智能体分析海量用户反馈(不只是编程,还有金融、法务、市场等领域),归纳主题、辅助决策优先级。

「Harness」(工具层或执行框架)这一概念在AI智能体领域有特定含义,值得展开说明。它并非模型本身,而是包裹在模型外部、负责任务调度、环境交互、上下文注入和安全边界执行的整套软件基础设施。具体到编程智能体的场景,harness通常包含以下组件:系统提示(system prompt)或开发者消息的动态生成逻辑、工具调用(tool use)的路由和执行器、沙箱环境的隔离与资源限制,以及多轮交互中的状态管理。「Harness领先模型一步」这一观点揭示了AI产品工程的一个规律性现象:模型能力的提升往往是离散的、以训练周期为节拍的,而用户预期是连续增长的,这中间的gap必须由harness的工程迭代来填补。这也解释了为何许多顶级AI产品公司在模型本身相近的情况下,产品体验差异依然显著——harness的设计深度是真正的差异化所在。

代码审查、维护和架构:研发流程的重构

Thibault曾在以严格代码审查文化著称的Google工作过,他对代码审查角色变化的思考尤其值得关注。

Codex知道公司内部的一切

Codex团队早期就与研究部门合作开发了代码审查模型,能够发现逻辑和推理层面的错误,其深度需要人类「花数小时」深挖依赖关系才能达到。如今这种能力已并入主线模型,团队benchmark显示其代码审查能力「超越人类」。在安全方面,代码审查已成为OpenAI所有pull request的强制环节——被标记有安全漏洞的PR会被阻止合并,全程自动化。

那人类还需要参与什么?Thibault认为,代码审查过去有三重价值:正确性、安全性,以及作为「信息交换的小仪式」的社交属性。前两者正在被自动化,而真正剩下的、需要人类深入讨论的是意图(intent)——「你到底想做什么?这件事该不该做?」他提出,这种讨论其实可以发生在pull request之外,不必围绕代码进行。

他用「盒子」的比喻来阐述未来的协作模式:只要在资源利用、数据访问、安全等方面有严格保证,「盒子里发生什么几乎无所谓」,你真正需要达成一致的是「这个盒子做什么、必须满足哪些不变量(invariants)」。一旦这个契约确定,盒子内部的任何改动都不再需要反复讨论,从而「保护你的注意力」。

维护成本也在急剧下降。Thibault指出,第三方依赖升级、应用安全补丁这类「以前会拖延、但对业务很重要」的维护工作,正走向完全自动化。更大的变化在于重构(re-architecting)变得极其廉价——过去彻底重构架构可能耗时数年,是极其昂贵的工程,现在则被大幅加速。

这也意味着软件的生命周期被极大压缩。过去一个成功项目可能一年才积累到50-100名工程师,现在「一个周末就可能有100个智能体在贡献代码」。因此,良好的抽象、模块化的架构设计变得比以往更重要——这种曾经只有架构师或资深工程师才关注的能力,现在所有工程师都需要具备。

Kata容器是一种结合了虚拟机安全隔离与容器轻量化部署优势的技术方案,由Intel主导开源。与传统Docker容器共享宿主机内核不同,Kata容器中每个工作负载运行在独立的轻量级虚拟机(基于QEMU或Firecracker等hypervisor)中,拥有自己的内核实例。这使得即便容器内代码存在内核级漏洞,也难以影响宿主机或其他用户的工作负载,非常适合运行用户提交的、行为不可预测的AI智能体任务。对于Codex云端版本而言,用户可以让智能体执行任意shell命令、安装软件包乃至训练模型,这类高权限操作在多租户环境中本身就是安全风险点。Kata容器的选择反映了OpenAI在「功能开放性」与「多租户安全隔离」之间做出的工程权衡——牺牲部分启动速度(毫秒级而非微秒级),换取强隔离保证。

Codex与ChatGPT的合并,以及AI自己当「记者」

从外部看,Codex并入ChatGPT只是「多了个入口」,但Thibault透露这背后是巨大的工程挑战。ChatGPT是完全托管的云端架构,而Codex原本完全本地运行。「合并」的本质是:如何让本地编程智能体的全部能力在云端复现,并且高效到能被纳入每月20美元的Plus套餐——要知道「20美元根本不够跑这个项目」。

如今Codex的云端版本运行在一台功能强大的托管虚拟机(Kata容器)中,用户甚至可以创造性地让它安装Blender做3D建模、训练模型,因为它有互联网访问权限。默认情况下,Codex在本地沙箱运行,需要额外权限的命令会请求用户授权;用户也可选择在云端的托管VM中运行。

本地运行不再有「做到一半」的任务

一个耐人寻味的细节:在整个合并过程中,Codex本身充当了「记者」的角色。由于它接入了所有Slack对话和文档,能够完整记录团队关于「如何合并、如何命名、何时引入」的激烈辩论。Thibault称之为OpenAI的「toggle纪元」(work toggle的引入)。主持人也坦承这有一丝「老大哥监视」的意味——AI始终在场旁观,但这或许会成为未来创业公司的新常态。

给工程师的建议:好奇心与清晰的表达

关于如何成为能在Codex团队这样的地方工作的builder,Thibault给出两点建议:

第一是对事物运作原理的深度好奇心,以及快速理解系统的能力。在OpenAI表现出色的人,都能迅速grok一个系统、深入陌生代码库并理清逻辑。他推崇「五个为什么」的追问方式——不断深挖,学习就会飞快。

第二是与社区和用户保持同频,以及清晰的思考与表达能力。「如果你无法解释你想达成什么,无法表达你的意图,没有对社区的纽带,没有品味,那要做出优秀的工作会难得多。」

关于AI会不会让工程师失去乐趣,Thibault坦言偶尔仍会打开编辑器写点代码,享受那种「深夜专注解决问题」的craft感。但他更强调,如果你把「代码视为解决问题的工具」,那么能解决更多问题本身就是巨大的赋能。「我还没遇到过谁说这不好、不好玩。」对于「模型会掌握我擅长的技能」带来的失落感,他的态度是:问题永远不会枯竭,人类还有漫长的道路——数学突破、科学突破,以及以深刻人性化的方式造福人类。

分享:

相关推荐