深度｜对话OpenAI Codex负责人Tibo：从内部工具杀到顶流，Codex的终极目标不只是Coding Agent

推荐语

过去两年，AI编程最明显的变化，并不是“代码写得更快了”，而是软件开发这件事本身正在被重新定义。

从最早只能补全几行代码的Copilot，到今天能够读懂代码库、调用工具、执行测试、提交修改，甚至持续运行数小时乃至数天的Coding Agent，模型正在从“辅助工程师写代码”，一步步进入软件工程的完整生命周期。对开发者而言，真正变化的已经不只是效率，而是人和代码之间的关系：当正确性检查、安全审查、依赖升级、重构乃至一部分架构工作逐渐自动化，人类还应该把注意力放在哪里？

最初只是OpenAI内部帮助研究人员写Python、搭基础设施的一组小型智能体，后来与“自主软件工程师”项目合并，逐渐成为今天的Codex。更有意思的是，OpenAI在这个过程中做出了一系列看起来并不“封闭”的选择：用Rust重写核心智能体、从一开始开源CLI和SDK、允许接入其他模型，并不断把本地运行的 Coding Agent推向云端，最终与ChatGPT走向统一。

在这篇访谈中，Tibo首次详细讲述了Codex的诞生历程：从DeepMind内部那个比ChatGPT早一年出现的聊天机器人，到加入OpenAI后参与o1推理模型的冲刺，再到ASWE项目如何演变为今天的Codex。他坦诚地分享了那些关键的工程决策——为什么用Rust构建智能体、为什么选择开源、为什么Codex不绑定OpenAI自家的模型——以及这些选择背后关于正确性、效率和开放生态的思考。

The Pragmatic Engineer是由Gergely Orosz创办的科技媒体，通过深度报道与播客访谈，关注软件工程、技术团队及行业变化。Tibo Sottiaux是OpenAI核心产品与平台负责人，也是Codex的创建工程师之一。本次访谈由The Pragmatic Engineer于2026年9月发布，通过与Tibo Sottiaux的深入对话，探讨Codex的诞生、技术与开源选择，以及AI智能体如何改变软件开发和个人工作方式。

Z Highlights

• “我想加入一个真正相信自身使命、并且直接关心如何积极影响世界的团队。”从Google到DeepMind，再到OpenAI，Tibo Sottiaux始终在寻找能够把研究、产品与真实影响结合起来的地方。

• Tibo从Google的一次失败的项目经历中得到的一个教训，一直保留到今天：“要不断质疑，不断深入思考自己实际产生了什么影响，同时也要认真审视自己参与的整个项目究竟有多重要。”

• “代码审查一直关注正确性，但它也承担着信息交换的作用。”未来，正确性和安全性检查将更多自动化，而人类需要把注意力放在产品意图、架构边界和真正值得解决的问题上。

• 当今时代，对软件工程师、AI工程师，以及所有从事软件开发的人来讲，有两个品质是非常重要的：第一，对事物运作方式保持极强的好奇心，以及训练自己快速理解新事物的能力。第二，要真正理解你想解决问题的群体，以及他们所在的社区。

01 2015年加入伦敦Google：竞争程度堪比今天的OpenAI

Gergely Orosz:Tibo，欢迎来到我们的播客节目。很高兴能请到你。

Tibo Sottiaux:谢谢你邀请我。很高兴再次见到你。

Gergely Orosz:很高兴能再和你聊聊。上次我们是面对面交流的，这次则是通过视频。首先，我想问问，你是怎么进入科技行业的，你最早是什么时候意识到，自己想从事与计算机相关的工作？

Tibo Sottiaux:这是个好问题。那是很久很久以前的事了。我出生在布鲁塞尔，后来父母决定搬离那里。他们觉得，买一栋小房子，再翻修一下，应该挺不错的。不过，那栋房子在一个没什么活动的小村庄里。我记得那里大概只有两百名居民，没几个我想聊天的人，也没几个能交上朋友的人，所以我就有点被困住了。那时候我还很小，大概八岁，就整天和电脑打交道，也是在那时开始接触互联网。那成了我了解外面世界的方式，后来的事情也就自然而然地发生了。说起来，这还得归功于我父母把家搬到了那么偏僻的地方，让我除了对电脑产生兴趣，也没什么别的选择了。

Gergely Orosz:高中毕业后，你就上了大学，对吧？开始系统地学习计算机相关知识。

TiboSottiaux:对，我在大学学的是数学，具体来说是应用数学。我上大学比较早，所以毕业也比较早。不过，很长一段时间里，我都觉得自己可能读不完，会中途退学。读书期间，我就经营着一些小公司，还做一些咨询业务，为银行提供服务。我对供应链和应用数学方面的问题很感兴趣，也挺喜欢把这些知识和技能变成服务卖出去，并在这个过程中学到很多东西。后来，我进入了比利时的创业圈。在那里干了一阵子之后，我搬到了伦敦，先在Google工作，后来去了DeepMind，再后来就搬到这里，加入了OpenAI。我现在在加州。我很喜欢这里的天气，我们也可以聊聊这个。在这里过得挺不错的。

Gergely Orosz:大学刚毕业，你就创办了一家公司，对吧？看来你那时候就对创业充满热情，骨子里就有一股创业的冲劲。

Tibo Sottiaux:对，这家初创公司主要做的是医药供应链，具体研究临床试验中的供应链管理：如何优化流程，决定要不要生产更多药品、把药品送到哪里、如何调配和发运，以及怎样减少浪费，从而提高临床试验的效率。当时采用的是传统方法，也就是不依赖机器学习的技术，主要进行优化，处理蒙特卡洛模拟之类的问题，本质上属于随机多阶段优化问题。我们还把这些方法应用到了钢铁行业，以及欧洲的电网系统。凡是具有优化问题特征的领域，我们都会感兴趣。直到今天，这家公司仍然在运营，我认为他们现在做的工作依然非常有意思，只不过现代人工智能的发展，确实正在给这个领域带来很大变化。

Gergely Orosz:不过，这一点很有意思。你刚才说，那时用的不是机器学习，而是传统方法，但接着又提到了蒙特卡洛模拟、优化算法之类的技术。我感觉你当时是一路钻研得很深，对吧？你的思路似乎是：面对一个具体的问题领域，就想办法运用数学——包括自己已经学过的，以及后来补充学习的知识——不断深入研究。我这样理解对吗？

Tibo Sottiaux:对，所以我才会如此着迷于应用数学。核心想法是：一方面有理论数学，或者理论科学、理论物理，人们研究它们，是因为其中有未知的东西等待发现，也因为它们本身很美。那里关注的是规律、模式，以及不断拓展认知边界，只是你未必一开始就知道它将来能应用到哪里。另一方面是现实世界。现实中到处都有各种有意思的问题，而我很想看看自己能不能让这个世界变得更好。所以，我会思考：怎样把复杂而成熟的数学方法应用到现实问题中，尽可能优化我们周围的世界？这也是那家初创公司背后的核心理念。

Gergely Orosz:后来，你离开了创业公司，加入了Google，最开始是在伦敦的Google。那是2015年。我记得，当时Google是一家非常难进的公司，无论是在行业地位还是声望方面，竞争程度可能和今天的OpenAI差不多。你最初参与的是Google地图项目，后来又转到了DeepMind。能不能谈谈你当时主要负责什么？另外，既然那本来就是一个很有意思、而且你显然也很喜欢的领域——比如优化、物流以及相关问题——你为什么会选择离开，转向其他方向？

Tibo Sottiaux:我一开始并不是做Google地图，而是参与了一个旨在提升互联网和网站速度的项目，尤其关注移动端。当时Google正在经历从桌面端向移动端的转变，越来越多的流量转移到了手机上，所以他们希望提前布局，为此资助了不少计划和项目。我参与的就是其中一个。这段经历非常有意思，因为我们是广告部门内部的一个小团队。这个项目的目标，是抵消流量转向移动端后可能造成的广告收入损失。

我们做了大约两年，后来项目被取消了。虽然这是我解决高难度技术问题时最开心的一段经历，但我也从项目缺乏产品市场匹配、没有找到合适的用户、没有建立正确的反馈闭环，以及过于相信产品经理“项目进展顺利”的说法中学到了很多——事实上，项目当时根本进展得一点也不好。有一天，一位副总裁从加州飞过来，然后告诉我们：“这个项目要取消了。”原因是：很遗憾，你们只有几百名用户，这显然达不到Google的规模要求。让人难以置信的是，当时很多人都感到很意外。我从那次经历中得到的一个教训，一直保留到今天：要不断质疑，不断深入思考自己实际产生了什么影响，同时也要认真审视自己参与的整个项目究竟有多重要。

后来我转到了Google地图。那段经历非常有趣，我主要负责用户评价相关的工作。大约一年后，我实在无法忽视DeepMind的吸引力。那是一个非常特别的地方，总部就在伦敦。当时那里正在发生许多令人惊叹的事情，正处于早期发展阶段，已经开始显现出AlphaGo这类项目的迹象。他们似乎一直在做非凡的事情，专门挑战最困难的问题。以我的经历和背景，自然很容易被吸引过去。加入DeepMind后，我主要参与研究基础设施和研究工具的建设。这也成为我近十年来一直延续的一条主线：思考如何打造工具和产品，帮助其他人提高效率，并为他们提供真正有用的能力。起初，我是在为研究人员做这些事情。后来，我逐渐开始以更普遍、更抽象的方式思考这些问题，最终一路走到了现在的位置。

Gergely Orosz:还有一个很有意思的故事。你最近也在X上分享过：你曾参与打造Google内部的一个聊天机器人。可以说，它和ChatGPT有些相似，但比ChatGPT早了一年。能不能聊聊这段经历？这是个新故事，我之前还没听你讲过。

Tibo Sottiaux:这件事发生在DeepMind内部。当时其实有好几条探索路线，Braid也是其中一项相对独立的工作。他们也在研究自己的大语言模型，不过这绝对不是DeepMind当时的主攻方向。那时DeepMind更关注宏大的挑战、各种游戏，以及强化学习——这里说的不是语言领域的强化学习。与此同时，有一个团队在推进大语言模型，思考这样一个问题：如果大规模文本语料包含了我们需要的一切呢？如果把语言能力推到极致，只是不断扩大语言模型的规模，这是否足以实现通用人工智能？这在当时是一个非常热门的争论。后来，其中一个团队决定全力推进这条路线。

对我来说，这一切发生得很自然。因为我当时正和其他人一起为研究工作搭建工具，所以很容易就会开始思考：我们能用这个模型做什么？应该怎样把它呈现给研究人员？怎样让他们调试输入和输出？最后，你很自然地就会做出一个聊天系统。于是，我们在DeepMind内部把它做了出来，大家都玩得非常开心。最开始，那些模型的表现有点荒诞：回答不太连贯，也不是特别有用。不过，和它们反复试验、摸索各种用法还是很有意思。很快，这个应用就在DeepMind内部像野火一样传播开来，大家纷纷分享自己和模型的对话。

它逐渐不再只是一个研究项目，或者只服务于研究人员的工具。后来，大家开始希望把它作为外部产品发布。但DeepMind当时并没有为此做好准备。Google确实有一套成熟的产品发布流程，也有完整的配套机制，以及经过严格验证的正式生产技术栈。多年来，我们已经围绕这些流程做了高度优化，能够把事情稳妥地做好；但与此同时，这样的环境也非常难以真正推动创新。

02 加入OpenAI与Codex：从研究基础设施到自主软件工程师项目

Gergely Orosz:是什么促使你加入OpenAI？如果把自己代入你的处境：在2023年或2024年，你身处Google，不断发表优秀的论文，研究成果也非常出色。你每天都在做很有意思的事情，不断突破已有的边界，而且已经在这家公司内部完成了转岗。究竟是什么促使你仍然愿意继续探索，去想：外面是不是还有别的可能？是不是还有其他值得做的事情？

Tibo Sottiaux:对，我当时确实过得很舒适，Google是个很好的地方。不过，我内心真正渴望的是认识优秀的人，同时加入一个我真心认同的使命。我希望团队成员都真正相信这个使命，真切地关心如何以积极而直接的方式影响世界，而不是觉得：“我们只是在这里完成自己的工作，至于怎样让它真正发挥作用，那是别人的事。”我想加入的是这样一个团队：大家会把所有因素放在一起考虑，研究和产品会真正协同设计。那时OpenAI的发展势头非常强劲，ChatGPT也正在迅速崛起。我和几位OpenAI的人聊过之后，简直不敢相信：ChatGPT只有大约20个人在负责吗？这个团队规模小得惊人，但也一定拥有极大的自主权。它究竟是怎么做到的？只有20名工程师，怎么能维护一个规模这么大、同时又保持这么高自主性的产品？我就这样不断深入了解，最后发现那里有一群非常出色的人，也有一个令人振奋的使命。团队成员能力很强、动力十足，这些都吸引了我.

我加入后，很快就参与了推理模型的早期工作——这也很符合OpenAI一贯的风格。我刚加入时，大家就告诉我：“现在有一件大事正在推进，我们要发布推理模型，这会是一种全新的范式。”于是我们马上开始冲刺。大约一个月后，公司就发布了o1预览版。能参与其中，令人非常振奋。我想加入一个行动迅速、重视实际影响、能够感知外部世界并认真倾听的地方。这也是我后来构建Codex和其他产品时一直坚持的理念：建立一个用户社区，倾听社区的声音，形成高强度的反馈闭环，然后打造真正值得投入、真正能为世界提供实用价值的产品。

Gergely Orosz:然后，当然，你很快就开始参与Codex的工作了。你是在2024年加入OpenAI的。能不能带我们回顾一下，当时你刚加入时，团队对于人工智能、大语言模型以及代码的整体思路是什么？我知道那时候有一个ASWE项目，也就是“自主软件工程师”（Autonomous Software Engineer）。

Tibo Sottiaux:ASWE，对，这就是我们当时在内部的叫法。现在已经没有ASWE这个项目了，统称为Codex。对我来说，加入OpenAI后，我首先开始为研究工作搭建基础设施。和我之前做过的很多事情一样，主要包括大规模数据的存储与分析，以及帮助我们理解训练过程的工具。我这些年做过很多不同的项目，但核心始终是为他人搭建工具，让他们工作得更快，同时真正把这件事做好，并通过工具和基础设施创造新的可能。所以，加入OpenAI时，我的想法也是一样的。随着o1预览版以及后来一些模型的出现，我们很清楚地意识到，必须利用模型本身来帮助我们加快工作速度。于是，我开始着迷于这样一个问题：模型的局限究竟在哪里？我们要怎样把这些模型应用到研究工作本身？

我和研究团队的其他同事一起，开始训练模型，开发一些小型智能体。这些就是Codex真正的前身。当时，我们训练内部模型，让它们非常熟悉OpenAI的Python代码库，也让它们具备良好的架构判断力和代码风格意识。那时模型只处理Python。我们的想法是，利用这些模型快速搭建基础设施，也帮助研究人员更快地编写代码，从而让整个团队的推进速度更快。随着我们不断推动这件事，并把它进一步简化到核心，我们发现自己可以非常迅速地取得进展，也能非常快地从中学习。

Greg和Sam都给予了极大的支持。Greg还非常坚持一点：我们不能只把注意力放在OpenAI自身，也要思考怎样让全世界都能从中受益。他鼓励我们，不要只把它当成OpenAI内部的工具，也要把它发展成真正面向用户的产品。于是，我们把这项研究工作和ASWE项目合并到了一起，开始集中打造同一个产品。后来经过一轮冲刺，我们推出了最初的云端Codex。不过，它当时并没有实现产品市场匹配，因为使用门槛有点高，操作流程也比较繁琐。与此同时，我们还发布了Codex CLI，并继续推进这项工作。但始终贯穿其中的一个核心问题是：怎样才能让模型真正帮助我们完成这些工作？

03 为什么选择Rust与开源：为Codex建立安全、可靠且开放的基础

Gergely Orosz:你刚才提到，最开始你们训练模型，让它们学习Python代码，并实际帮助改进相关代码。但后来你们做了一个很有意思的决定：Codex是用Rust构建的。可是在当时，模型对Rust的掌握并不属于训练分布之内，对Rust的表现也不如Python或TypeScript。你们为什么会做出这样的选择？当时是预期模型最终会追上来，还是认为性能更重要？因为这确实很反直觉。其他大多数智能体运行框架，实际上都不是用Rust构建的，而是采用模型更熟悉、更接近训练分布的TypeScript、Python或其他语言。

Tibo Sottiaux:对。从第一性原理出发，我们很早就开始把产品界面和智能体本身视为两个不同的东西。因此，智能体的核心必须以一种稳健、安全的方式构建，同时还要兼顾效率和规模化能力。我这些年参与过一些项目，最初只是“做个有意思的小东西”，后来却要扩展到最大型数据中心的规模。只要没有过度牺牲开发速度，早期的技术决策最终往往会证明非常重要。这当然是一种权衡。不过，我们当时有很多非常优秀、经验丰富的Rust开发者。我们的内部模型对Rust的表现也不差。而且，Rust能在编译阶段提供大量验证：它是静态检查的，拥有类型安全等特性。这些优势对智能体同样很有帮助。所以，很快我们就清楚地认识到，只要愿意投入一定精力，Rust其实非常适合用来构建智能体。不过，最主要的考虑还是正确性和效率。

Gergely Orosz:有意思。你的意思是，以你们的情况来看，提前设想产品未来要发展到什么程度，是值得的。比如语言的选择。虽然现在有了智能体，重写大量代码比过去容易一些，但如果一开始就选对技术基础，搭好合适的脚手架和底层框架，仍然可以减少后续的返工，对吧？

Tibo Sottiaux:我认为，如果当时使用TypeScript，甚至Python，我们同样可以取得成功，之后再找时间重写也行。但把智能体本身和产品清晰地分离开来，让智能体能够独立于具体产品存在，这是一个非常重要的原则。如果把所有东西都放在同一个代码库、使用同一种语言来编写，最终难免会有些马虎，让各个部分过度交织，超过合理程度。这样一来，后续的创新也会受到限制。所以，这一点非常重要。从某种意义上说，Rust构成的边界正好帮助我们实现了这种分离。

Gergely Orosz:你们做了一个很有意思、而且在各大模型实验室中相当独特的决定：从一开始就采用开源模式，对吧？CLI、SDK以及应用服务器全都开源了。你们是什么时候、为什么做出这个决定的？这并不是理所当然的事。尤其是过去，人们还常拿“OpenAI 的东西其实很封闭”来开玩笑。但这次情况正好相反：你们选择开放源代码，而有些竞争对手则会发布闭源的智能体运行框架。当然，我完全能理解为什么有人会希望把这类东西做成闭源产品。那你们为什么决定采用开源模式？

Tibo Sottiaux:把代码开源这个想法本身就很酷，因为我们构建的本质上是一个coding agent。于是我们就想：既然有了这样的工具，你自然会让它处理自己的代码。也许还能建立一个贡献者社区，让大家用它来改进它本身，而我们也能从中学到很多东西。另外，当时我们很清楚，如果我们做成了这件事，开源本身会发生变化，代码所扮演的角色也会改变。因此，参与这个社区，而不是置身事外，就显得很重要。

我觉得，如果你没有亲自接触这些问题，就很难真正解决它们。还有一点是，这个领域即使现在看来仍处于早期，当时就更是如此。我们觉得自己有一些不错的解决思路，也在结合模型训练和研究工作，共同设计这些方案，目标就是以最灵活、最好的方式发挥模型的能力。但我们也没有所有答案，所以我们愿意公开分享：“这是我们认为好的harness应该有的样子，这是我们的思考方式。”我们做过几次技术性很强的深入解读，也写过相关博客，并进行了很多讨论。我们还觉得，外面的世界发展得很快，有很多极其聪明的人，我们也会从其他开源项目中获得启发。既然如此，不如让大家站在同一个起点上，在这个阶段鼓励更多动手尝试和探索。

Gergely Orosz:现在已经过去了一年，甚至一年半。在人工智能的发展周期里，这其实是相当长的一段时间。回头看，根据这段经历，你认为开源带来了哪些长期收益？对团队来说，有哪些持续存在的好处？坦率地说，开源过程中又有哪些困难？它肯定也有缺点。我想听听你对正反两面的真实看法。

Tibo Sottiaux:当然也有缺点，开源是要付出代价的，对吧？但它的好处也很明显：公开开发真的很棒，而且拥有一个规模不大的代码仓库也很方便。每当我们招聘新人、有人加入Codex团队时，他们通常已经看过这个代码仓库，浏览过里面的PR，于是他们会……

Gergely Orosz:入职培训就已经完成了。

Tibo Sottiaux:对，基本上入职适应就已经完成了。你可以直接用Codex和自己一起查看代码仓库，提出一些问题，因此很快就能进入工作状态，不需要先花很长时间摸索那些不透明的内部信息。我们确实收到了很多高质量的贡献，当然，也会收到大量杂乱、随意的提交和内容。

Gergely Orosz:显然，你和其他所有人都看到了，对吧？开源正在发生变化，我觉得这就是其中一个例子。

Tibo Sottiaux:没错。对我和团队中的许多人来说，参与社区、直接贡献代码，会带来很大的动力。我们不是只口头上说重视社区，而是真正投入时间和精力去做大家看得见的事情。毕竟，这些工作本来完全可以不做。

开源的缺点是，它和我们其他代码是分开的。因此，有时我们不得不人为划分边界，还要同时维护多个代码仓库。当我们在公开环境中开发某些特别令人兴奋的功能时，有时会发现，产品还没来得及发布，别人就已经把它复制出来了。这多少让人有些失落，但这也是开源的一部分。既然你选择公开开发，就等于接受了这样的约定：别人可以复制你的成果。而且我们采用的许可证也非常宽松。不过，当你投入大量时间开发某个东西时，眼看着它还没发布就被别人复制，心里多少还是会有点不是滋味。第三个问题是，和其他开源项目一样，我们也会被大量随机、杂乱的贡献淹没，需要额外投入精力去处理。这相当于增加了一笔维护成本。但这也会促使我们想办法解决这个问题，而我认为这其实是件好事。

Gergely Orosz:除了开源之外，Codex还有一点让我很意外。我也是最近才知道，Codex并不绑定OpenAI的模型。你也可以在Codex中使用其他模型。如果站在模型供应商的角度来看，这一点可能并不明显。因为我接触到的其他供应商，在推出CLI时，通常都会把它设计成只能搭配自家的模型使用。那么，你们为什么会采取这么开放的策略，允许用户把Codex这个智能体运行框架与其他模型结合使用呢？

Tibo Sottiaux:如果你身处这个社区，致力于打造优秀的智能体运行框架，那么为什么要把它绑定到自家的模型上呢？做出这种限制，感觉很令人失望，也不符合我们的理念。总的来说，我会尽量做出自己能够清楚解释、并且认为正确的决定。开源也是出于同样的考虑。对任何人来说，复制一份代码、再加入对其他模型的支持，都很容易。但这样一来，大家就会被迫去使用各自的分支，维护成本也随之增加。如果只是为了支持另一家模型供应商，用户就要单独维护一个分支，只改十几行代码，这就太荒谬了。所以，为什么不一开始就直接支持呢？

另一方面，提供选择空间对我们也很有好处。也许今天你喜欢使用OpenAI的模型，用起来效率很高；但明天有一个新模型发布了，你想试试。为什么要为了测试一个新模型，就彻底改变自己的工作环境和配置？开放支持不同模型，也能让我们获得原本得不到的反馈：你可能会发现自己喜欢那个模型的某些特性，也可能发现它实际效果并不好。对用户和社区保持友好，我认为是正确的做法。我们自己也会尝试其他模型，在同一个智能体运行框架中测试它们，这对大家都有好处。而且，对于与我们合作的企业来说，这种灵活选择往往非常重要，我们也会积极支持这一点。

Gergely Orosz:关于最后这一点，我觉得任何认真经营的公司都希望保留选择空间，也希望使用能提供这种灵活性的工具。但我很欣赏你们的做法，因为这让我觉得它很坦诚：它迫使整个公司在模型层和智能体运行框架层都做到最好，同时还要面对开源生态以及可自由选择的模型所带来的竞争。这样一来，公司就不能停下来想：“好了，我们已经做得够好了，现在可以暂时放松一下。”

Tibo Sottiaux:对，我希望我们能靠最好的模型、最高效的模型和最出色的产品来赢得用户。如果这些方面都做到最好，我们就会拥有一个良性循环，也能享受这个过程。如果我们只是因为某一个限制，强迫用户使用我们的产品，我觉得这也不会吸引最优秀的人来做这款产品。所以，我们正在这里尽最大努力，把产品体验做到最好。我们非常重视使用感受。无论背后驱动它的是哪种模型，用户都应该觉得它好用、愉快，甚至让人乐于使用。

Gergely Orosz:作为一名工程师，我一直觉得，只要不同工具之间存在竞争，对工具使用者来说就是好事。我记得以前Microsoft和JetBrains之间有过IDE大战，后来各家云平台也相互竞争，不断推出各种功能。现在，我们又有了智能体运行框架之间的竞争，以及模型之间的竞争。对用户来说，这很棒，因为我们有了更多选择，产品迭代也会更快。我们的声音可能也更容易被听见。说回智能体运行框架，你能不能介绍一下它现在是怎么工作的？比如，当我启动一个Codex任务时，它总是在我的本地机器上运行吗？还是会根据情况选择云端？它会使用沙箱吗？我该如何控制或确认这些设置？作为一名工程师，我需要了解多少？

Tibo Sottiaux:对。默认情况下，Codex会在沙箱中运行。凡是需要额外权限、必须在沙箱外执行的命令，都会先向用户请求授权。但默认情况下，每一次工具调用都会在沙箱内完成。目前它完全运行在你的本地机器上，这种模式已经持续一年多了。不过，系统正在不断演进。你也可以选择在云端运行任务：这时任务会在一个受管理的虚拟机中执行，使用的虚拟机和ChatGPT Work中提供的是同一种类型。你可以查看这个环境，但实际运行是在Kata容器中进行的，这是一个安全隔离环境。因此，所有操作都会在云端虚拟机内完成，不会占用你的本地机器。你的电脑只负责接收输入，以及流式传回输出。这样显然能大幅减轻本地CPU和设备的负担，也能让任务规模扩展得多得多。

这只是一个阶段。未来，使用云端机器会更加无缝，也许还会采用混合模式：一部分任务在笔记本电脑上执行，另一部分在云端机器上执行。我们正在思考的一件很自然的事情是：随着模型越来越强大、能力越来越高，它们能够利用的计算资源会远远超过本地机器所能提供的资源。因此，如果始终把执行限制在本地机器上，迟早会成为一种约束。

Gergely Orosz:不过，Codex在本地运行有一个很大的优点，这也是我喜欢本地模式的原因。当然，它也确实有些麻烦：如果我同时运行多个智能体，它们会占用CPU；而且如果我想合上笔记本电脑，也不能让任务保持半开状态继续运行。有一次我在一家AI公司的办公室里，把笔记本电脑盖子半合着，有人问我：“你在运行智能体吗？”我说：“对，有一个任务还在运行。”我之所以愿意这样做，是因为本地有我自己的工具和环境：本地PostgreSQL数据库，以及其他各种本地配置。

所以，云端运行当然很棒，但云端没有这些现成的环境，重新配置起来也很麻烦。你们有没有在考虑或尝试，让用户能够更方便地把本地开发环境带到云端？这也让我想起了AI普及之前我们讨论过的一个话题：云端开发环境。大概在2022、2023年，那是个很热门的概念。后来大家更多地讨论AI了。

Tibo Sottiaux:对。我觉得，除了大型科技公司之外，云端开发环境一直没有真正普及，主要是因为前期投入很高，而且还需要持续支付维护成本。但对于个人开发者或小团队来说，随着智能体能力不断提升，配置环境的成本几乎可以降到零。既然智能体能够完成这些工作，那么环境搭建和维护就应该交给它来做。比如，你可能有本地SQLite数据库、本地服务器、MCP，以及其他各种工具。要在云端开发环境中搭建完全相同的配置，并让它持续同步，究竟有多难？如果由模型自动完成，也许并没有想象中那么难。

所以，我认为，完全由云端编排和管理的机器可能会重新兴起，让你不再受笔记本电脑的限制。我们在远程工作方面已经取得了很大成功：它可以直接在手机上使用。我每天早上会一边喝咖啡，一边口述一批任务，它就会自动执行。它可以访问我的日历、电子邮件和Slack。能够随身走动、随时处理事情，而不必一直带着笔记本电脑，真的非常方便。我认为Codex Remote也是同样的思路：目前任务的执行仍然发生在你的笔记本电脑上，但如果以后不需要一直开着笔记本电脑，那就更理想了。

Gergely Orosz:你能不能介绍一下，过去你们是如何改进Codex的？我记得自己第一次使用Codex时，那还是比较早期的版本。你可以和它对话，它也能执行任务。比如我让它完成一项修改，它确实完成了，但我明明有单元测试，它却没有运行。几个月后——具体时间我记不清了——它突然开始自动运行测试。这些改进，是不是来自你们对执行脚本或指令的优化？我不确定你们具体怎么称呼这部分，是启动脚本、引导脚本，还是其他东西。又或者，这是通过改进模型实现的？作为一名开发者，我应该怎样理解你们在不同版本中，分别如何改进智能体运行框架和模型？这两者之间又是怎样相互配合的？

Tibo Sottiaux:对，这是个好问题。可以说，智能体运行框架在某种程度上总是会稍微领先于模型。

Gergely Orosz:真的吗？为什么这么说？

Tibo Sottiaux:我的意思是，模型本身具备一定的能力，但我们还要为它配上一些“辅助工具”，让它能够更可靠、更高效地完成任务，并表现出用户所期待的行为。智能体运行框架的作用就在于此：提供安全护栏，提高效率，让智能体更容易被引导和控制。运行框架通常还负责我们所说的开发者消息。它会在每一轮对话开始时注入上下文，从而影响智能体在这一轮中的整体行为。所以，很多你看到的能力，其实都是运行框架和模型共同作用的结果。最开始，可能会出现“它不会运行测试”的情况，于是你需要明确提醒它运行测试。后来，我们训练出了更好的模型，它更能理解用户真正想要什么。这样一来，你就不必再专门提醒它了。因此，随着时间推移，我们看到的趋势是：开发者消息会逐渐缩短，智能体运行框架本身也会变得更加精简。

04 模型与Harness共同进化：从代码审查、维护自动化到软件开发流程重构

Gergely Orosz:在Codex团队内部，你们会设定一些具体目标吗？比如说：“目前Codex这个由智能体运行框架和模型组成的整体，在某方面表现还不够好，或者在某些地方经常犯一些低级错误。”

我想了解，作为工程团队，你们是怎样规划下一个Codex版本的？作为开发者，我不太容易理解这一点：模型对我来说像一个会不断变强的“黑箱”，我当然知道你们肯定有各种反馈渠道；但与此同时，你们还要开发智能体运行框架，也就是工具层面。这大概就是工程团队主要负责的部分。那么，你们究竟是如何设定目标的？在传统软件开发中，你会说：“我们要实现这个功能”，然后按计划把它做出来，因为你知道具体该怎么实现。但对Codex来说，这个开发过程似乎更加模糊。

Tibo Sottiaux:对，确实如此。这也是为什么我们会对大多数事情进行协同设计。这是一个研究团队与工程团队共同参与的过程，工程团队主要负责构建智能体的核心运行框架。我们会不断问自己：目前我们擅长什么？哪些方面还不够好？有没有一些新的能力，虽然实现起来很有挑战，但会成为非常酷的产品功能？然后我们会进一步判断：这应该通过修改运行框架来解决，还是应该通过改进模型来解决？如果需要改模型，那大概多久能实现？一个月、三个月，还是六个月？我们会据此进行权衡。

如果某个问题很快就能通过下一轮模型训练得到解决，我们可能决定完全不在运行框架中加入额外逻辑，而是直接等待模型解决。毕竟，我们追求的是让智能体自己完成更多工作。我们也会使用智能体来分析大量反馈，从中归纳出主要问题和趋势，帮助我们展开讨论并确定优先级。我们会分析整个软件开发领域的反馈，也会分析其他领域，比如金融、通信、市场营销，以及如今用户使用智能体处理的各种任务。这些领域下面还会细分成许多类别。

我们大致了解系统在各个方面的表现，然后不断推动能力边界。一个有意思的现象是，随着预训练模型越来越强、整体模型不断改进，所有能力通常都会一起提升。当然，有时我们也会对某些特定领域投入更多关注。

Gergely Orosz:你提到，你们会让智能体参与整个流程。那我们能不能聊聊Codex中的软件开发生命周期？比如，一名新工程师加入任何一支团队时，通常都会先了解：“这里是怎么做事的？”在AI普及之前，如果你加入Uber或Google，他们可能会告诉你：流程是这样的——先提出一个想法，或者由产品经理提出需求；然后制定计划、集中讨论、进行工作量评估、拆分任务、编写代码、运行测试、进行代码审查、发布功能、设置功能开关，之后还要轮流值班。过去基本就是这样。现在，如果有人加入Codex团队，他们显然已经为开源项目贡献过代码。但如果对方是完全的新手，你们会怎样向他们介绍：在这里，事情究竟是怎么完成的？

Tibo Sottiaux:我会先把他们介绍给团队里的优秀同事。新成员最常听到的一句话是：遇到问题时，你有没有问过Codex？在OpenAI，Codex默认就接入了几乎所有内部资源：Slack、各种文档以及全部代码。新员工通常会对此感到惊讶，因为你几乎可以问它任何问题，而它往往都能给出非常好的回答。所以，想了解项目进展、某件事由谁负责，或者某个决定为什么会做出，最简单的方法就是直接问Codex。它掌握着内部的大量信息。因此，我们也会尽量在公开频道中开展工作，并让文档拥有相对宽泛的访问权限，让所有人都能接触到这些信息。这样，智能体也能浏览这些内容，进行分析和推理。

此外，我们还在开发一些能够提升团队效率和协作体验的功能，目前还没有全部发布，其中一部分可能会在Dev Day上公布。这些做法能让新成员快速融入团队，了解当前进展，并开始独立产出。总体建议就是：关心用户，关心产品的整体一致性，也要关注模型及其发展方向。如果你为了弥补模型的缺陷，正在构建一套一万行代码的复杂变通方案，那很可能说明你走错了方向。所以，我们确实有一套原则，但目前更多体现为团队文化和工作理念。新人加入后，会通过与其他成员的日常协作，逐渐理解并掌握这里的工作方式。

Gergely Orosz:如果我有了一个想法，觉得它很不错，就会先和Codex讨论，也可能和一些同事交流。比如，我想把一个新功能作为加入Codex后的第一项贡献，或者第一次重要贡献，那具体应该怎么做？显然，我会和Codex一起编写代码，也会进行测试，确认功能确实有效。那接下来是什么流程？你们还会进行代码审查，或者由AI进行代码审查和验证吗？之后是否还要逐步发布、持续验证，再分阶段扩大发布范围？毕竟，Codex本身会面向数百万用户发布。我刚刚看到活跃用户已经突破了2000万。而如果是ChatGPT，覆盖的用户数量还要大得多。

Tibo Sottiaux:对。无论是在Codex还是ChatGPT中发布，流程其实都很相似，尽管ChatGPT面向的是十亿级、还在持续增长的活跃用户。你可以提交一个PR，完成一项改动，甚至当天或第二天就发布出去，然后它就会直接触达十亿用户，而系统依然能够稳定运行。我们真正强调的是责任感和主人翁意识。因此，大家拥有很大的自主权，甚至可以进行幅度很大的改动。通常需要提供一些证据：用户会喜欢这个改动，它确实值得加入产品，而且值得长期维护。同时，维护成本也已经大幅降低。

所以，我们现在看待这些事情的方式，和两三年前相比已经有些不同了。另一方面，我们也会尽可能实现自动化。代码审查、部署、回归问题检测等流程，大部分都已经自动完成。这样一来，大家可以把注意力集中在想法本身，以及它将如何帮助用户，同时也要关注整个产品的一致性，持续提升智能体的整体能力。

当然，我们还有一长串想做但尚未完成的事情。更长远的“北极星方向”，是打造一个令人愉悦、易于使用的个人 AGI：它了解与你相关、且确实需要了解的信息，能够访问合适的资源，有时可以代表你执行具有一定风险的操作；完成后，它会向你发送推送通知，让你确认结果。作为用户，你应该能够清楚理解它在做什么；同时，它也了解你的日程和目标，能够主动提供帮助，并且使用起来极其自然。你应该可以通过自然语言或语音控制它。也许它还应该理解你的情绪；如果它配备摄像头，这种交互也应该自然得像呼吸一样。它不应该是一个拥有十几个按钮和复杂配置项的系统。AGI应该简单、自然、易于使用。

Gergely Orosz:你刚才只是简略提到了代码审查，但我想再深入问一下。你曾经在Google工作过，参与开发Google地图这样拥有数亿用户的产品。Google以严格的代码审查文化闻名。我记得他们大致有两层审查，其中一层是语言规范方面的审查，而且他们多年来一直在整个行业中不断完善这套机制。他们确实相信这套流程有效，也一直在使用。你认为，尤其是人工代码审查正在发生怎样的变化？

在过去很长一段时间里，也许直到一两年前，我都会认为代码审查有很多价值：促进知识共享、提供第二双眼睛、降低“巴士因子”——因为这样会有其他人了解这部分代码，当原负责人不在时，其他人可以接手——同时还能围绕架构展开讨论，而不只是检查代码本身。但现在，代码量大幅增加了。代码审查的价值究竟体现在哪些场景中？在你们团队里，由于你们在这方面走得非常靠前，你认为人工审查，也就是开发者参与审查，在哪些环节仍然很有价值？哪些情况下可以放心交给智能体完成？你们是否已经发现，有些代码审查完全可以交给智能体？

Tibo Sottiaux:对，代码审查的角色正在发生变化。我早期在Codex做过的一个项目，就是和研究团队一起开发代码审查模型。我们的目标是让它能够发现逻辑和推理上的错误，而且达到这样的深度：如果由人来发现同样的问题，可能需要花上几个小时。因为这类问题往往需要深入分析三四层依赖关系，甚至要发现文档本身可能写错了，或者第三方依赖库的实际实现和你的预期不同。这样一来，原本应该成立的不变量就无法保持，最终导致bug。除非你是那个库的专家，否则很难意识到这一点。

后来，我们开发并发布了这类代码审查模型。现在，这些能力已经融入主线模型中，模型可以通过深度验证发现同类问题。根据我们的基准测试，它们在代码审查方面已经达到了超越人类的水平。这不仅适用于正确性，也适用于安全性。比如，模型能够分析非常复杂的交互关系，然后指出：“这里存在一个严重的安全漏洞。”现在，OpenAI的所有Pull Request都必须经过这类检查。如果模型标记出安全问题，Pull Request就无法合并，而且整个流程是自动完成的。

我认为，代码审查一直关注正确性，确保代码能够正常工作。但它也一直承担着信息交换的作用：让团队成员达成共识，推动讨论。理想情况下，这些讨论应该在写代码之前就发生，但有时只有围绕代码审查时才会发生，因为代码一旦合并，就会在生产环境中实际运行，之后还需要长期维护。所以，代码审查也有社会协作层面的作用。

我认为，所有这些方面都在变化。正确性检查和网络安全检查，我觉得最终都会实现自动化。现在真正需要讨论的，是Pull Request背后的意图：你究竟想做什么？这件事是否值得做？我认为，这些问题完全可以在Pull Request之外讨论，不一定非要围绕代码展开。

Gergely Orosz:所以，这或许能帮助我们更清楚地划分：哪些问题确实需要讨论，哪些讨论只是因为过去缺乏我们现在拥有的这类工具，才不得不围绕代码展开。

Tibo Sottiaux:对，我认为这种情况会发生变化。过去，Pull Request像是一种“强制机制”，因为在代码合并、进入生产环境之前，团队必须先围绕它展开讨论。但我认为，现在可以通过其他方式来讨论、共同设计，并确保最初的意图是合理的。这样一来，具体代码本身就不再那么重要了。

Gergely Orosz:有意思的是，回想我参与过的所有代码审查，当然也有一些经历让我印象很好：我们进行了很有价值的讨论，或者我学到了非常有意思的东西。但坦率地说，很多时候代码审查真的让人很头疼。我只是想把自己的事情推进下去，不停催促别人：“能不能帮我看一下代码？”对方可能回答：“不行，我现在很忙。”可我又确实需要这次审查来解除阻塞。于是你不得不不断切换上下文。

所以，我觉得代码审查一直都有好的一面，也有不好的一面。无论我们采用什么方式，都会有利有弊，只是现在这些利弊正在发生变化。对工程师来说，一个好处是，你不必再把注意力花在那些其实不需要你亲自参与的基础性工作上。

Tibo Sottiaux:对，这确实能节省时间。未来我们会逐渐看到这样一种模式：大家先就一个“黑盒”以及它整体上应该遵守的契约达成共识。只要对资源使用、数据访问权限、安全性等方面设定严格保证，那么黑盒内部具体如何实现，实际上可以完全不必关心。真正需要达成一致的是：这个黑盒究竟应该完成什么功能，以及必须满足哪些不变量。我认为，这些问题值得投入时间进行深入讨论，也可以借助你最喜欢的智能体来协助。但一旦达成共识并建立起共同理解，之后对黑盒内部进行任何修改，都不需要重新展开同样的讨论。这样，我们就能更好地保护和集中自己的注意力。

Gergely Orosz:维护成本已经下降了。维护一直是Google、Uber以及各种初创公司在开发产品时经常讨论的话题：构建阶段很有趣，但后续维护却非常痛苦。也正是在维护阶段，我们会意识到：“这个东西当初可能根本不值得做。”那么，在Codex和OpenAI内部，你认为维护正在如何变得更便宜、发生哪些变化？这会怎样影响你们正在构建的东西、产品目标，以及定制化工具之类的工作？

Tibo Sottiaux:维护本质上是一种长期成本，你需要不断付出，才能让系统持续运行，而且一直都是如此。未来维护仍然不可避免，但我认为其中很大一部分会实现自动化。比如，你有一些第三方依赖需要升级版本。如果变更日志完善、代码文档齐全，而且模型能够理解这些内容并进行推理，那么这类工作完全可以自动化。模型可以快速扫描整个代码库，在几小时内完成升级。

过去，人们可能会把这件事搁置，因为它不算有趣。但对于业务和项目来说，它其实非常重要，尤其是涉及安全漏洞时。你需要及时更新，应用各种补丁。我认为，这些工作最终都可以完全自动化，维护中的很大一部分会变成几乎零成本的事情。另外，过去当你需要彻底重构系统、重新设计架构时，往往是因为要适应新的权衡、新的工作负载，或者加入新的功能。你可能突然意识到，现有系统的限制太多，必须从头重构。这种工作过去代价极高，有时甚至需要数年。但现在，这一过程正在大幅加速。可以说，犯错的成本正在下降。

不过，软件工程中一些经久有效的原则依然重要，比如设计良好的抽象。还是回到“黑盒和不变量”这个概念：如果一开始划分出了合理的边界，就能更快地修改黑盒内部的实现，而不会影响其他服务或基础设施。因此，系统设计必须支持快速迭代和快速变化。

Gergely Orosz:我记得曾和Peter Steinberger聊过这件事。当时他还没加入OpenAI，我们讨论的是他如何思考OpenCLAW。他说自己并不阅读所有代码，但我能感觉到，他会把整个架构装在脑子里，并不断思考如何重构。他会考虑怎样让系统模块化，怎样让100名贡献者各自开发自己的部分，同时互不干扰。所以，我理解你的意思是：这种关注、规划和结构设计，可能变得更加重要了。过去，这通常是架构师、资深工程师或经验丰富的人负责的事情，其他工程师则在周围开发相对独立的小模块。但现在听起来，所有工程师在构建软件时，都需要具备这种意识，并提前为未来的发展做好规划，对吧？

Tibo Sottiaux:对，而且GPT模型在这方面也越来越强了，比如考虑长期维护和良好的架构设计。这其实是很自然的下一步：关注的不只是某个文件里的代码是否整洁，还要考虑整体架构是否合理，能否降低长期维护负担，并为未来增加产品功能、扩展能力或进行调整留出空间。这是一种持续进行软件工程建设的能力，而模型现在开始能够很好地思考这些问题了。

我觉得，真正有意思的是，我们构建的软件正在以快得多的速度经历完整生命周期。过去，你可能先以个人开发者或两三名工程师的小团队开始做一个项目，然后逐步扩充团队。也许一年后，如果项目非常成功，团队会扩大到50人甚至100人。你有时间观察项目的发展，也有时间让新成员逐步加入，并完善文档和其他配套工作。但现在，可能一个周末就会突然有100个智能体同时为同一个项目贡献代码。和过去相比，整个软件生命周期正在以极快的速度推进。

Gergely Orosz:那你和OpenAI的同事是怎么应对这种变化的？它不会让你们感到有些不适应吗？我的意思是，你从事这个行业已经很久了，可能有几十年。过去大家已经习惯了一种工作节奏，而现在速度显然快了很多。你们是怎样理解和适应这些变化的？一方面，整个过程变快了；另一方面，你一年前还在做的事情，现在可能已经不再亲自做了，因为模型已经能够胜任。你是如何调适自己的心态的？我相信，一定有一些软件工程方面的工作你过去非常擅长，而现在可以交给智能体完成。这样不会让你有一点失落吗？我们刚才说过，自己开发的功能被别人开源复制时，多少会有些不是滋味。同样，当你发现自己曾经很擅长重构代码，而现在模型已经可以完成这件事，或者未来它甚至会擅长架构设计时，也可能会想：“好吧，这确实很厉害，但原本我也挺想亲自做这件事的。”

Tibo Sottiaux:我觉得，这里面确实有一种手艺感。有时候我还是会打开编辑器，亲手写一写代码，那种感觉很舒服。我仍然怀念以前深夜坐在Vim前写代码的时光，喝着无糖可乐，专心解决眼前的问题，完全不用考虑其他事情。但归根结底，我认为关键在于进入心流状态，以及解决问题本身。我发现，OpenAI的同事，以及我接触到的其他人，都适应得非常快。

如果你把代码看作解决问题的工具，那么现在你就能解决更多问题。以前你可能想做一个基准测试，但不确定最终会得到什么结果。现在，你可以直接启动一个后台任务，通常不到30秒就能拿到可靠数据，从而做出更好的权衡。如果你真正关心的是最终结果，以及系统能否良好运行，那么这些工具应该会让你成为更好的工程师。

对OpenAI来说，这意味着我们能够更高效地运行推理，更有效地利用计算资源，并把这些能力部署给全世界。因此，大家都专注于解决重要问题，而且速度是过去无法想象的。到目前为止，我还没有遇到过谁会说：“这不好，这一点也不好玩。”

Gergely Orosz:我的理解对吗？听起来，如果你面对的是很有ambition的问题，待解决的问题远远多于今天、明天或下周能够处理的数量，这似乎不再是一个真正的障碍。因为只要某个环节的效率提高了，你就可以继续推进，解决更多问题。这其实很像初创公司的情况：初创公司通常总是有远大的目标，而要做的事情远远超过当前团队能够完成的范围。

Tibo Sottiaux:我们肯定不缺需要解决的问题，对吧？而且我认为，很长一段时间内都不会缺。无论是数学突破、科学突破，还是让世界变得更好，我们都还有很长的路要走。真正为人们创造有用的东西，解决大家面临的最重要的问题，并且始终以人为本——这就是我们在这里的意义。

再说回写代码和那些熬夜的经历，我觉得，刚才讲的可能也是经过美化的版本。其实也有很多个深夜，我一直在尝试重构代码，埋头做了三个小时，才发现这条路根本走不通，只能从头再来。那种感觉非常令人沮丧。所以，确实有特别开心的时候，但也有代码怎么都编译不过、让你忍不住想：“到底为什么还编译不过啊？”的时候。

Gergely Orosz:我相信你也经历过这种情况：忙着忙着，已经很晚了，你得上床睡觉，毕竟总得休息。但躺下以后又睡不着，因为还有个任务做到一半，悬在那里，让你心里很不舒服。我记得自己甚至做梦都在想代码。不过，现在我为自己的业务开发软件时，已经很少有这种事情只做了一半、放不下的感觉了。我可以直接告诉智能体：“把这个做完。”然后，等我停下来时，事情已经有了明确的结果：要么完成了、能正常运行，要么有明确的证据表明这次尝试失败了。这很有意思，因为一切都在加速，对吧？

Tibo Sottiaux:对，我也会像很多人一样，有时心里会有一些比较大的问题。它们可能来自白天的某次交流，也可能是我一直还没来得及深入研究的事情。所以，我会把这些问题交给Codex，让它在夜里帮我探索。这样一来，我就会很期待第二天醒来查看结果，每个早晨也因此多了一份期待。

Gergely Orosz:我觉得，让智能体执行长时间运行的任务，也是一门学问。当然，你可以使用/goal命令，让它持续推进任务。这也是几个月前才加入Codex的功能，对吧？就是那个/goal命令。

Tibo Sottiaux:对。这又回到了刚才那个话题：harness在某种程度上就像一根“拐杖”，对吧？当时之所以需要/goal，就是为了让模型能够长时间围绕同一个目标持续推进。如果问题确实很难，它甚至可以让模型连续运行几天、几周。但在新一代模型上，我们看到，你已经不再需要/goal，也不需要额外的harness来维持这种持续执行了。你只要直接告诉模型：“去研究这个问题，花一周时间。”它就真的会这么做。

05 Codex与ChatGPT合并：从本地编程智能体到云端统一产品

Gergely Orosz:说到棘手的问题，以及你们还有很多问题要解决，我想聊聊你们推出的那次“合并”，也就是把Codex整合进ChatGPT。从外部看，作为工程师，我一开始觉得这件事还算有意思，但并没有特别惊讶。因为我们本来就在用Codex，所以看到这个变化，反应大概就是：“哦，现在可以在ChatGPT应用里打开Codex了，挺好的。”我自己打开应用后，也是直接进入Codex，因为我平时并不怎么在这个应用里使用ChatGPT。

但我和OpenAI、以及你团队里的一些人聊过，他们说，这背后做了大量准备，也遇到了很多工程挑战。你能不能介绍一下，这个项目究竟有多大？你们需要完成哪些工作，为什么这么难？Codex和其他工具又是如何帮助你们完成那些过去很难做到的事情的？因为自从这次整合发布之后，你们不断公布的Codex使用人数，增长速度明显比以前快了很多。所以我猜，你们一定解决了一个相当大的规模化挑战。

Tibo Sottiaux:这次整合有很多方面都很具挑战。首先，两个产品使用的是完全不同的技术栈。ChatGPT是完全托管在云端的产品：所有事情都运行在我们的系统上，我们采用传统的云端架构来构建它，重点考虑规模化和效率。而Codex完全运行在本地。因此，整合的核心问题就是：怎样让这个本地编程智能体具备同样的优势和能力，再围绕它构建一个产品，让更广泛的人群都能使用？

这也是我们加入OpenAI的原因：希望服务全世界更广泛的人群。所以，这是一段非常令人兴奋的探索过程——我们需要研究如何构建一个云端版本，让它在本质上具备与本地版本非常接近的能力，同时还要采用合适的架构，使其能够高效地服务数千万乃至数亿用户，并且能够纳入Plus订阅方案。ChatGPT Work本质上是在云端运行完整的Codex智能体运行框架，并配备一台云端计算机——实际上是一台非常强大的机器。用户已经发现，只要提示词足够有创意，就可以让ChatGPT Work在里面训练另一个模型。有些用法甚至非常大胆：你可以让它安装Blender，进行3D建模。它的权限非常宽松，能够访问互联网，本身也是一台性能强大的计算机，而Codex可以直接在上面运行。这就是我们通过ChatGPT Work发布的能力。

因此，这项工作涉及许多系统层面的挑战，但团队完成得非常快。Codex显然也帮助我们提高了效率：它能够协助检查和构建大量基础设施，解决Codex与ChatGPT之间出现的各种细节差异，包括合并插件架构、合并代码库，以及不断推动系统统一。统一系统才是我们的目标。用户不应该感觉到某件事可以在Codex中完成，却不能在ChatGPT中完成，或者反过来。我们想打造的是一个统一的产品，让用户能够使用同一套智能，只是选择自己喜欢的使用方式。

这段整合过程也很有意思，因为Codex在整个过程中还充当了“记者”的角色，记录团队经历的每一步，以及大家进行的各种争论和讨论。团队曾围绕产品应该如何构建、如何命名、何时以什么方式发布，以及哪些功能应该合并到哪里，展开过非常激烈的讨论。我们考虑过很多不同的方案组合。因此，这里面还有一个很有趣的“新闻记录”元素：Codex后来完整记录了这段过程。这段经历也被称为OpenAI的“开关篇章”。当时我们引入了“工作模式”开关，围绕它是否是正确的设计，也有过很多讨论。后来，大家逐渐喜欢上了这种方式。不过，随着时间推移，我们会进一步整合各项功能，朝着完全统一的方向发展。现在的状态只是暂时的：在工作模式下，你能获得更强、更完整的能力；但最终，我们会把这些能力逐步提供给所有ChatGPT用户。

Gergely Orosz:你个人是怎样使用Codex的？你的工作方式是什么样的？比如，你会运行多少个智能体、处理哪些任务、用它管理哪些工作？关于这个问题，我还问过Peter Steinberger应该怎样采访你。他说：“你一定要问问他，平时同时参与这么多项目，究竟是怎么应对的？他的日程表就像在玩俄罗斯方块一样排得满满的，但他通常看起来还是非常开心、精神状态很好。”

Tibo Sottiaux:我的日程安排其实没问题。只是现在有了Codex这样的技术，我能完成的事情比以前多得多。我现在把很多工作转移到了手机上，通过ChatGPT Work处理。每当有什么事情想记下来，我就直接口述发送出去。我经常使用语音输入。每当我有一个问题，以前可能会先记下来，等以后再研究，或者交给别人处理。现在我会直接把问题发给ChatGPT Work，然后让它整理成一份报告。我为它配置了大量自定义技能和自定义指令，所以它现在能够按照非常符合我习惯的方式，生成报告、幻灯片以及代码分析结果，让我可以高效地阅读和使用。因此，每当我在会议之间看到我，我通常都在对着手机口述内容。正如我之前说的，我们大量使用公开频道开展工作，Slack、Notion和Google Docs中也积累了很多信息。

基本上，我没有什么问题是觉得Codex完全无法处理的。至少在第一轮分析上，它都能帮我思考：了解用户对某个功能的反馈和舆情；查看生产日志，分析某项功能的使用量；列出那些缺乏用户采用、应该逐步淘汰的功能；了解某个团队正在做什么。无论我有什么问题，通常都能在30分钟内得到一个答案。这就是我使用Codex的方式：几乎什么事情都用它，把它当作全方位的个人智能体。

周末时，我也经常用它做一些代码探索、开发原型，或者设想产品未来可能的发展方向。我会和团队中的其他人一起做这些事情，而且参与的并不总是同一个团队。有时候，我一天之内就能把脑子里突然冒出的想法做成一个可以展示的东西。比如某天早上，我突然想：“我们应该探索一下这个方向。”于是我就把想法完整表达出来，在当天做出一个原型给大家看，让他们一起思考、提出批评，也希望能从中获得灵感。这并不意味着我们一定要把它发布出去。更多时候，我只是先把想法从脑子里“倒出来”，然后继续处理其他事情。所以，现在确实是一个非常神奇、也非常令人有掌控感的时代。

Gergely Orosz:最后，你想给软件工程师、AI工程师，以及所有从事软件开发的人什么建议？如果他们希望获得相应的技能和经验，将来有机会加入Codex团队、OpenAI，或者一家AI初创公司，应该怎么做？他们是否应该先把自己培养成一名善于使用这些工具的优秀开发者？大家经常会问：我应该从理论开始吗？基础知识有多重要？还是应该先把这些工具用得非常熟练？

Tibo Sottiaux:我认为有两点非常重要：对事物运作方式保持极强的好奇心，以及训练自己快速理解新事物的能力。因为一切都还会持续变化。在OpenAI表现特别出色的人，通常能够迅速理解一个系统，也能快速进入一个新的代码库，理清它的结构和工作方式。当然，如今智能体也能为这一切提供很大帮助。你需要吸收、理解并分析的信息实在太多了，而其中很重要的一点，就是提出高质量的问题，真正弄清楚系统是如何工作的。你可以不断追问“五个为什么”，一层一层深入。通过这种方式，你会学得非常快。

另一点是，要真正理解你想解决问题的群体，以及他们所在的社区。你解决的未必总是一个直接的问题。有时，你是在为人类解决某个问题的过程中，构建一种将来对另一个群体有用的能力。但你必须清楚把握用户偏好、需求和要求，并且能够清晰思考、明确表达。我认为，这一点非常重要。如果你无法解释自己想实现什么，无法说明自己的意图，也不了解相关社区，更没有良好的产品判断力，那么你会很难做出真正优秀的工作。

Gergely Orosz:太棒了，Tibo！非常感谢你参加这次对话，聊得非常愉快。

Tibo Sottiaux:谢谢你的邀请。

原视频：Building Codex with Tibo Sottiaux

https://youtu.be/sLSTM9znQNs?si=xF3SH96usvaLQZUx

编译：Sigrid Ji

文章来自于微信公众号 “Z Potentials”，作者 “Z Potentials”