今天的嘉宾是 OpenAI Codeex 团队的 Tibo Sotio。Tibo 一直与旧金山的研究和工程团队并肩工作，致力于解决科技领域最棘手的难题之一——真正的 agent 自主性。Tibo，很高兴你能来到 Dev Interrupted。
Tibo：嘿，很高兴来这里做客。非常期待聊这些话题。主持人：太好了。那么，今天我们要探讨 AI 发展的 bitter lesson。关于你们正在构建的东西，关于为什么那些巧妙技巧和领域专业知识有时会失效，以及为什么可扩展的 primitives 正在取胜，我们有很多可以深入挖掘的内容。我们将探讨 Codeex 团队如何平衡研究与严苛的生产环境需求，并打造一款好用且让开发者满意的工具。不过，我想先从 Codeex 开始——用你自己的话来说，就是了解 OpenAI 的旗舰 coding agent。你能介绍一下它是什么，以及为什么你将其描述为 agent first，而不是一个产品吗？
Tibo：是的，我们的思路可以分成两部分。首先，我们正在构建一个能够行动并在 coding 方面承担大量工作的 coding agent，为全世界的软件工程师提供帮助。这个 agent 具有相当的通用性，你可以把它部署到很多地方，而产品层面的工作也就由此产生。也就是说，我们要找出利用这个 agent 的接口的最佳方式，而这个 agent 的能力还会不断增强。当你把思维转变为先构建 agent，再去思考把它部署到哪里时，你会发现非常有趣的一点：这个 agent 能在大量场景中派上用场，真正创造经济价值。我们也在思考，除了 coding 之外，这意味着什么，对吧？即使对软件工程师来说，关键也不只是代码生成，而是解决日常工作中许多其他真正的瓶颈。所以，我们的目标就是构建这样一个通用的 agent。主持人：是的。我们接下来会深入聊聊那些其他的瓶颈是什么。过去一年里，我们在 Dev Interrupted 上经常讨论 agentic development 如何将所有那些深深影响团队的人与沟通问题暴露无遗。你刚才提到，不要把它仅仅看作一个产品，这让我想到一种产品与平台的类比。借助平台，你可以把许多产品、许多生态系统中的东西整合在一起。而一个 agent 似乎也正在以类似的方式运作。你可以先构建一个 agent，然后再去明确有哪些用例，如何将其向前或向后调整，打造成对人们有意义的产品。
Tibo：没错。所以，如果你考虑构建一个自主的、能力不断增强的实体，同时对它的最佳形态、最佳产品形态保持灵活心态——也许我们把它应用在自己的产品中，也许我们也与其他公司合作，把它应用到他们的产品中——这就为许多绝妙的想法打开了大门，而这些想法我们未必能提前想到。也就是说，我们可以专注于构建这个 agent，然后再去考虑把它部署到哪里。主持人：在一个你正在构建 coding agent、且立足于 frontier model 之上的环境中工作是什么感觉？你们拥有整个流程的 vertical integration，这是一种独特的优势。那是一种怎样的体验？
Tibo：没错。这非常有趣，因为我们可以把工程领域的一些最佳想法引入研究，反过来也是如此，研究会影响我们构建 agent 的整个工程路线图。当你实现 vertical integration 时，你可以决定在哪里解决问题，这样就不必在 harness 中解决所有问题。有些东西我们选择在下游通过训练新模型来解决，而且我们知道，通过训练模型，我们将在三个月后、六个月后获得所需的能力跃升。这让我们能够做出一些没有 vertical integration 就无法做到的 trade-offs。另外还有一个叫做 no free lunch theorem 的东西，它基本上说的是，如果你试图适应所有可能的 distribution 并保持智能，那么这严格来说不如你针对某个非常特定的 distribution 来构建东西来得最优。因此，通过将 harness 和 model 耦合在一起——也就是我们所称的 agent——我们能够获得能力上的提升，这显然非常有意思，对于 coding 这样重要的领域来说尤其如此。主持人：是的，你提到研究和工程相互促进，这一点很吸引人。这是一个大循环，里面还有许多小循环。我认为这正是过去一年里我们所有人的发现，尤其是那些在用 agent 方面取得很大成功的人——就是找到那些循环，找到那些完美运转的 workflow，让输入和输出相互反哺，从而使整个系统变得更好。所以这是 vertical integration 带来的一种独特优势。我想，在这个充满 green field 的领域，你拥有 model，拥有 coding agent，你可以朝任何方向构建它，采取这种几乎像是 agentic first 的方式，然后朝着个人和组织的具体需求去打磨。但作为身处其中的人，你如何防止复杂性困住自己的架构，并保持简单，让它对所有人都好用呢？
Tibo：是的。所以我们努力让自己扎根于那些经受了时间考验、在过去被证明有效的东西。简单性往往会带来更好的 scaling，以及你所构建的系统长期更好的整体表现。我们真正关注的是这个 agent——也就是 harness 和 model 组成的这个系统——随着时间推移不断提升能力，因为我们的模型能力也在不断提升。如果我们在 harness 或解决方案中引入了 bias，那就非常糟糕了，因为这意味着当模型出现能力跃升时，我们实际上无法将其表达出来，因为我们以某种方式约束了它，阻碍了它展现真正的能力。这就是我们所说的 capability overhang。通过保持简单，你就能减少可能出错的地方。关键在于选择那些已被证明能随模型能力同步 scaling 的 primitives。这其实也和一个研究问题密切相关——我们可以就此开展研究：这个 harness 是否能随不同的 model size 和不同的模型能力一起 scaling？比如我们观察最小的模型、中档模型，再到 frontier model，我们是否能获得预期的 scaling？所以你可以把 scaling laws 推广到整个系统的 scaling laws 上。没错。而要应用 scaling laws，最终你必须保持简洁性，因为这些定律所利用和驱动的正是这一点，否则各种东西就会互相冲突，无法运转，而且就像你说的，你也无法获得即时收益。我认为这套系统最大的收获在于，当你做得足够轻量时，就很容易把它拿起来放到下一个新事物上，而这一点在你与模型紧密耦合时尤为重要。所以这真的非常吸引人。不过，这种简洁性不容低估。它来之不易，对吧？是靠研究和工程实践换来的。就像你肯定得先攀登复杂性的顶峰。一度，一切都非常复杂。然后你得从那座顶峰走下来，就像你说的，去寻找 primitives，那些变得更清晰的东西，对吧？所以这就是你所描述的旅程。是的。这是一个对正确 primitives 的持续不断的寻找。而且你知道，一旦发现这些 primitives，它们往往显得极其简单。它们常常看起来简单得令人愉悦，但寻找这些 primitives 的过程却是一件复杂的事。你可能不会立刻找到它们。所以你的系统中会存在各种复杂性，你审视这些复杂性，会想：嗯，我们觉得这里引入了不少偏见，而且我们以某种方式约束了模型，这会在某种程度上妨碍它的产出。但这也是一种微妙的平衡，关乎 harness——你知道，我把这叫 harness，是因为你实际上是在搭建脚手架，而你想随着时间推移拆除这些脚手架，因为模型能够独立站稳了。关键在于弄清楚什么时候该拆除哪些脚手架，并且要以一种能够拆除它们的方式来构建。而将两者紧密结合的优势在于，我们只需要关心我们自己的模型系列，仅此而已。所以每当我们改进某些东西时，就可以拆掉一些脚手架，而不用担心弄坏什么我们无法掌控的东西。这是一个非常敏锐的洞察，我想再强调一下，因为你指出最终你构建的这个 harness、这个脚手架应该倾向于那种简洁性，因为就像你说的，它应该只是暂时存在，直到 agent 能够完全自立，去做这个 harness 原本引导它做的事。当然，有些人采取相反的做法，他们把那个 harness 当成喷气背包来用，走的不是简洁路线，而是想着怎么往这个箱子里塞尽可能多的工具和东西。所以我认为这是人们对待这个问题的两种不同方式，它们显然会带来不同程度的成功。它的 scaling 效果不如你所说的那种轻量 harness 那么好。而且我觉得这也是你们多年研究积累下来的一部分。另外还有 Richard Sutton 的 bitter lesson，它指出相比这些 primitives，clever tricks 和 domain expertise 是不具备 scaling 能力的。而当我们谈到这些 primitives 时，指的就是 compute、power 和 time。你们的使命就是找到如何最好地利用它们，让每个人都能受益。但在这条路上，你提到你们开源了 repo，开源了人们构建这些 agent 的流程。那是一种什么样的体验？是什么促使你们做出那个决定的？所以在我们决定开源 repo 的时候，我觉得当时外界对 agent 存在很多神秘主义看法，比如它们是如何运作的，你需要在模型之上构建什么，才能让它安全地作用于现实世界，并为你执行有经济价值的任务。所以我们想展示这实际上可以多么简单而美好，并展示一些必须把握正确的 primitives。而且我们也想展示，如果你做好了这些事，就能从我们的模型中获得惊人的性能。所以它扮演了这种双重角色。除此之外，我们当时还有一个想法：如果你要解决代码生成问题，开源将会发生改变，而我们想通过自身至少部分技术的开源，来深刻理解开源将如何改变。另外还有一个想法和原因，我觉得这可能会很有趣，其他人也同意，那就是我们将会看到 agent 领域出现大量的 tinkering，以及很多有趣的产品在其之上被构建出来。拥有一个开源核心，可以让世界上的人们获得灵感，去 tinkering，去构建一些我们可能从未想象过的东西。所以这就能够激发开源社区的创造力，让人们去创新和发明新事物。总之，让 agent 开源是完全合理的，这也是我一直感到非常自豪的事。是的。作为建设社区的一部分，为人们提供一个可以参与开发的地方。这当中有没有让你感到惊讶或印象深刻的事？比如来自社区的那种来之不易的成果，证明开源这条路走对了的成功案例。有的。一开始我们在某些方面做得不太好，比如我们接受了太多贡献，结果对 repo 有些失控。后来我们进行了方向修正，比如在某个时间点迁移到了 Rust。我们当时确信自己需要构建哪些 primitives，并且想把它们构建正确。我们也确信未来某个时刻会看到数百万甚至数十亿个 agent 同时运行，所以我们想用一门高效的语言来编写。所以迁移到 Rust 对社区来说是一个比较艰难的时刻，因为我们之前在 TypeScript 开源 repo 里接受了很多 PR，然后我们就用 Rust 重写了。不过随着时间推移，我们与 Rust 核心的一些优秀贡献者建立了非常好的合作关系，所以与社区的关系也在不断演进。还有一点就是，把所有东西公开出来真的太棒了。我们会收到很多 bug 报告，人们会指出：问题就在这里，你应该这么修，或者这里有一个修复尝试。而且我们也从各种 fork 中获得很多灵感。我想这个 repo 大概有一千多个 fork 吧，我不太确定具体数字。其中一些其实相当受欢迎。他们会想出各种新点子，我们会与这些 fork 的作者合作，把一些改动移植回 Codex 开源 repo 中。通过观察人们如何修改和调整你的代码，你能学到很多东西，而且也能窥见 agent 如何被适配到其他场景。你将获得一个绝佳的近距离观察视角，看看这些早期采用者开发者如何接纳这些系统，并将其塑造成适合他们特定领域问题的工具。这是一种非常棒的合作伙伴关系，我认为人们绝对应该去关注，因为这相当罕见，而且这种合作关系甚至深入到模型层面，对吧？这就是这类技术所能产生的深远渗透力。每周我都会听到有公司说，他们的整个公司都是围绕 Codex 开源 agent 建立的，我们会感叹，哇，它不仅在编程方面表现出色，在非编码场景下也同样好用。他们把它改造成这样或那样的方式，现在它就能完成其他具有经济价值的任务了，比如编辑电子表格，或者把它嵌入到浏览器中。然后我就能看到这些 demo，总是很酷地意识到，某种程度上我们也在为这些成果做出贡献。是的，完全同意。我也很好奇，你提到了如何获得这种简洁性，回归到基础原语，而且现在我们刚进入新的一年。去年一整年都在用这些新工具做实验。那么在 2025 年你采用过的一些做法，到 2026 年可能就不会再沿用了。你思考 agent 的方式以及你的工作流今年是如何变得更简单的？是的。去年我们面临的一个重大问题和挑战是运行时间非常长的 session，agent 会经历一个叫做 compaction 的过程。也就是说，我们允许 agent 在超出模型实际可用的 context window 的情况下继续执行工作。当时很多反馈都说这不太好用，而这其实属于当时 scaffolding 的一部分，基本上只是一种 heuristic，你需要总结目前为止完成的工作，然后重置 context window，以便在获得全新上下文后让工作得以继续。而模型会丢失此前执行的不少工作的上下文。要把这种 heuristic 调对真的非常困难。你可以尝试去 prompt 模型，也可以尝试搭建 scaffolding 来解决。但对市面上很多 agent 来说，这是复杂性和困难度的核心来源之一。所以我们决定直接在模型层面解决这个问题，我们对此进行了端到端的训练，现在几乎不再收到这方面的投诉了。模型——agent——能够跨越 20 个、20 个 context window，在非常长的时间跨度内工作，而不会丢失此前正在做什么的线索。这就是我们利用自身独特优势解决的问题，从而一举消除了大量复杂性。而这正是这种“三要素”——简单原语的简洁性——的精妙之处：当其中一项取得重大突破，你再回头看另一项时，会意识到因为有了这些联动效应，你可以把它推进得更远。它们的耦合是如此紧密。那么今年你们在 Codex 本身上还有其他哪些做法会特别突出，或者会与你们明年的做法不同？今年年初的愿景是什么，要怎样让它成为世界上最受欢迎的代码 agent？是的，有几个方向我们正在大力推进。我们认为去年单 agent 已经变得足够可靠，能够执行任务了。而今年我们将看到可靠的多 agent 网络（multi-agent networks）去完成数量显著更多的工作。这意味着什么呢？当用户在同样长的时间内获得一个数量级甚至两个数量级的经济价值更高的产出时，这意味着你能在同样时间内消耗更多的 token，但这也意味着你可能需要审查多得多的代码，或者具体该怎么做？这是我们正在寻求解决的问题，我们正在努力让这方面显著提速。此外，我们觉得我们的模型在智能层面已经处于前沿，但在速度方面还没有达到前沿。我们预计这些模型今年会变得显著更快。这里几乎有一个 sweet spot，你要达到一种智力水平，同时速度也足够快，让用户在产品中使用时感到愉悦。这也是我们努力的方向之一。最后一点我想说的是，打造极具协作性的个性。我们的模型，在我们的 agent 中，Codex 有时候会显得有点——有点固执，就像一个直率务实的工程师。这不是适合所有人的形象。就我个人而言，我喜欢自己的想法能得到更多认可。不是说在我错的时候告诉我没错，而是希望模型能承认我也存在，就在笔记本电脑后面，我在努力做某件事，并一路陪伴着我。所以解决这个问题也很重要。我明白你的意思。我觉得这是我们所有前沿基础模型（frontier foundation models）都经历过的事情，它们各自都有不同的礼貌程度和简洁程度。就像你说的，有时候太过礼貌只是浪费所有人的时间，而且也不准确。但这里有一个平衡点。就像你说的，什么性格适合所有人？没有。谁被所有人喜欢？没有人。所以你怎么能打造一个被所有人喜欢的 agent 呢？你做不到。但你必须让它易于被调整成人们喜欢的样子。没错。所以这实际上是让它对你而言足够个性化，按照你喜欢的方式工作。如果你极具创造力，喜欢头脑风暴，不想在代码质量上被挑剔细枝末节，那这应该可以实现。如果你正在处理一个极其关键的代码库，希望每一个可能出错的地方都被标记出来，那你同样也应该能获得这种体验，而这正是我们的模型非常擅长的。Codex 去年参与发现了一些最令人印象深刻的 exploits，比如一些 React exploits，这个我们可以展开说，但在那种场景下，你不需要一个超级友好的个性。你只需要 Codex 去弄清楚潜在的 exploit 是什么，或者帮你修复一个非常棘手的 bug，然后带回解决方案，而且你要对结果的正确性非常有信心。而对另一些人来说，他们可能真的想要一种活泼、极具协作性的风格。而且它必须是个性化的。说到能够定制和组合各种能力，你们所处的环境拥有一种独特优势，就像我们说过的，从基础模型一路贯通到 agent 的实现，以及中间所有的研究环节。所以是全栈，但对于其他正在使用 agentic 工具、并正在构建这类 agentic 系统的团队，他们应该如何看待与基础模型紧密耦合，还是在构建时保持更高的可移植性？我很好奇这会如何影响我们一直在谈论的简单性或是 primitives。是的，我认为 primitives 大致应该是相似的，尽管形式上可能略有差异。我认为其中一个挑战在于，如果你正在为多个基础模型构建，并且完全不在意模型提供商，你就必须找到所有这些模型的共同点。而且，如果你至少不做一些调整，你必然会看到性能损失，也就是你能获得的整体表现会打折扣。所以我们看到的是，我们正在与生态系统中的一些参与者合作，建议他们如何让系统运转得很好，这也是我们的代码开源的原因——一切都公开在那里。这是一个例子，展示如何充分利用 GPT 模型的性能，我们与之合作来进行调整。所以我确实认为，你需要在一定程度上进行调整，才能在某个时间点从这些模型中获益。如果你想对市面上成千上万的模型都这样做，那成本会变得非常高昂。我预计主要玩家只会对少数模型这样做。我们一直在讨论 agent，但我想让我们退一步，谈谈开发者、工程师，坐在电脑前使用 agent 的人，他们的新常态是什么样的。过去一年里，我们都在探索这种 agentic coding 如何影响开发团队和个体工程师。不同的人以不同的速度适应，对吧？而那些体验到超高生产力的人，他们确实打破了所有的代码瓶颈，但新的瓶颈也随之出现，往往围绕规划与集成，以及真正花时间坐下来与人交流。所以，让开发者成功所需的是一套新的技能。在某种程度上，每个开发者几乎都成了自己的迷你团队，可以按照最适合自己的方式进行定制，他们几乎成了这个团队的代表，或者说决策管理者。这对你的工程团队来说是什么样的？在这种新世界里，他们的日常工作发生了怎样的转变？大家是不是花在 IDE 里的时间更少了，而把大量时间用于规划和审阅？是的。有趣的是，它实际上让人们更紧密地联系在一起，我们有更多面对面交流的时间，有更多创造性的共同构思和规划，因为每个人的效率都大幅提升，一旦你们决定做某件事，几乎可以立即执行。共同达成一致、共同组织协调，哪怕是一个20人左右的小团队，这也非常重要，因为你们能够在一周内完成传统上同样规模的团队可能需要一个月才能完成的工作量。所以有趣的是，它确实让工程师们比以前更多地交流，也许在前期就对齐得更多。我们显然也在思考，如何才能帮助并加速规划阶段、建立共识，以及如何将事物扎根于用户反馈和寻找 PMF 的现实之中。随之而来的下游瓶颈之一是 code review。这是我们去年就主动思考过的事情。我们构建了一个定制的 code review 模型，据我所知它至今仍是 SOTA，并在 OpenAI 内部全面部署。令我惊讶的是，这成为了 OpenAI 内部 Codex 最成功的应用之一，现在它基本上默认对所有人启用。很多团队干脆强制要求用 Codex 来审阅 PR，因为它能发现大量 bug。不可避免地，如果你生成了这么多代码，你也会产生一定量随后想要拦截的代码，而找出这些正在形成的瓶颈并逐一解决，我认为这是2026年的巨大挑战。是的，我也这么想。这些瓶颈就像地鼠一样，不断从地里冒出来，对吧？这些团队需要去解决的问题，因为他们已经在彼此协作运转了。但现在还有另一波人，他们刚刚完成 CS 学位，在学习期间就在实验这些工具，如今作为工程师开始他们的第一份工作，他们没有那么多包袱。真的没有。所以他们进入职场的方式非常不同。就我个人经验而言，与处于这个技能层级的人打交道，当他们使用这些工具、全身心投入时，绝对是无往不利，他们有一种天生的直觉，因为他们不像你我这样在职场中浸淫多年，被各种东西拖累和束缚。那么在 OpenAI 你看到了什么？我知道你们和很多年轻开发者以及工程师合作。这些 agent-first 的开发者登场时有什么不同？他们又是如何解决问题的？在 Codex 团队里，我们什么类型的人都有。有行业老兵，已经工作了35年以上，我想那是最高纪录，比我出生还早；然后我们也有应届毕业生。团队里我最信任的人之一，这位新人 Ahmed，他有着极具创意的想法，几乎可以说是被这套全新的东西塑造出来的，从未真正建立过那种“几十年软件工程经验告诉我这就是做事方法”的习惯。他对新方式极其开放，每天都在不断适应，还教会团队里很多其他人如何真正高效工作，这真的很了不起。我们团队里还有几位类似的人，这对我们至关重要。可以说，如果没有他们，我们整个团队的推进速度会慢得多。是的，我同意。我认为你要从这些人开始，每个组织里都有这种推动变革的个体，而且每个组织都有责任去识别出他们。他们就在那里，正在做着什么。如果你还不知道他们，我向你保证，他们就在表面之下潜伏着。而且如果你找到了这些人，他们能教会组织其他部门很多东西，也能为其他人赋能，因为在推广 AI 和人们试用这些工具的过程中，经验往往被困在团队内部，无法进一步扩散；或者会出现一个能力超强的人，能大规模交付所有东西，但其他人根本不清楚他是怎么做到的，对吧？说到这个，这让我想到正在出现的所谓“超级 bus factor”问题，对吧？就是说，如果最大的瓶颈仅仅在于我们做决策，然后某人启动一个 agent，事情就办成了。如果一名工程师就能独立交付整个产品——我们已经看到人们用这类工具做到了——那在这样的世界里，你如何让协作保持活力？为什么还要费事把东西交给别人？我和我的 agent 大军，随时可以调遣，自己就能搞定。是的，也许极限情况下，你确实可以独自运营一家公司。这可能大概还需要 5 到 10 年。在我心里，也许我们会更快达到那个阶段，那将是一个有趣的时期。但就现在而言，我看到的是传播计划很重要。传播信息、意图，以及记录变更的意图都很重要，而 agent 也能帮你做到这一点。比如，当你在会话中完成一段对话后，你可以总结自己的意图，随后把它附在 PR 上，这样其他人就能理解。我已经开始为自己和团队里的其他人搭建工具，用来追踪整个团队、整个组织中正在发生的变化，在不同抽象层次上都是如此，因为当下发生的变化更多了，你需要通过让每个人获得一种超能力来平衡这一点——让他们更快地理解事物，理解什么在变，理解事物是如何实现的，以及为什么以某种方式实现。所以这不仅仅是让代码生成速度快上一百倍，更是要加速你找到正确解决思路的过程，以及加速你作为一个人去理解整体状态的速度。所以这正是我们当下最关注、努力解决的方向。你提到了这样一个世界：把计划公开出来，让人们看到并理解，我认为这非常重要。我见过很多工具、很多公司试图解决这个问题，大家都在 spec 问题、制定计划这件事上尝试过一遍。我好奇的是，这解决了很多问题，它不仅涉及人到 agent 的交接，还包括 agent 到 agent、agent 到人的交接。你怎么看这件事？它是否像其他东西一样，是一种基础单元？如果它必须存在，那我们怎么让它尽可能简单？是的。所以只依赖计划，或者随着时间推移为产品或实现构建一份庞大的 spec，坏处在于它会变得有点失控，你会发现里面存在矛盾，而且到了某个节点，它会变得如此庞大，以至于难以理解。而且计划和实现之间可能存在错位。但我非常坚信，即使在这些工具出现之前，像设计文档这样的东西，把你的想法整理清楚，明确产品的发展方向，写下你的愿景和战略，我认为这些现在比以往任何时候都更重要。与此同时，迭代新想法从未如此简单，获取做产品决策所需的信号和信息也从未如此简单。这确实是一个正在大幅加速的趋势。所以有时候你可能并不知道你真正需要做什么，但你知道你需要构建哪些东西来获取信号，从而知道你需要构建什么。因此，有时候计划就是：我们需要获取信号。以下是我们打算做的五件事。没错。我们需要建一根避雷针，让闪电劈上去，这样我们才能弄清楚发生了什么，对吧？而这正是现在成本为零的东西，对吧？就像你说的，你可以快速转动它，调查产品的某些方面、人们如何使用它，以及产品周边的各种元信息，这些都比以往任何时候都更容易，对吧？以前需要深度数据分析、大量时间和一个非常明确的前期假设才能解决的事情，现在可以通过工程手段解决。现在你可以自由探索，有时甚至能并行尝试不同想法，对吧？那么，如果这就是开发者构建产品的新范式，你认为 senior IC 或晋升 staff engineer 的职业路径会是什么样子？这种资历是否取决于你调度这些 agent 和计划的能力，以及大规模地与同事分享？我认为这与以前并没有本质不同。通往 senior、staff 及更高级别的路径，在于你在团队内、在组织里产生的影响力。我一直这么认为：你构建出有影响力的产品模块，并让它在组织里落地、为公司创造价值，你的效率有多高？所以，是的，有一个方面确实在变化：你必须越来越能放大自己。你一个人就能做更多事情：你可以去看用户反馈，可以看日志，可以在后台跑几个查询，从而理解哪种数据库 schema 最合适，让你生产环境的查询真正高性能地运行。你基本上可以凭一己之力运转一整个小型工程团队。因此，作为工程师，你需要培养的有意思的技能，正越来越朝着每个人都向着 tech lead 或 tech lead manager（TLM）的方向发展，同时也要戴上越来越大的产品帽子，建立对用户的同理心。而模型和 agent 随着时间的推移也能帮助你做到这一点，因为你应该也能派 agent 去访谈用户，或者总结互联网上对你的产品的看法，以及你可能需要尝试的方向。所以，也许这只是加速了一条通往 TLM 类角色的道路。我想说，很多人一直以来都在努力往这个方向发展。所以，我认为这非常契合。是的，我认为这是很棒的提议，这也与我们听到的很多声音一致，尤其是过去一年节目里人们一直在讨论的，现在最重要的那些技能。在访谈即将结束之际，我们聊了很多精彩的内容，也深入了解了你对 Codex 的看法以及你如何解决编程 agent 的问题。但以你的独特视角，对于听众们如何让自己具备未来竞争力，或者在新年伊始如何开展工作，你有什么最后的建议吗？我相信我们还能挖掘出很多新的想法。有的。一个建议是，我和我 OpenAI 团队里的很多人都从 skills 中获得了很多乐趣。这现在已经成为一种开放标准，你可以教模型去做一些小任务，用你认为最有效的方式。比如查看日志、运行性能测试，或者我有一个 QA skill，让 Codex 能够自我 QA。每当我开发一个新功能时，我就让 Codex 在终端里与一个它自己的版本交互，确保实现符合规范，并且没有回归问题。发现这些 skills，并真正将其个性化，这是我的建议——你需要持续构建 agent 所需的 skills，使其适应你的工作流。前几天我想到一个类比：这感觉最像训练一只小 Pokemon。每次我与它互动，教它新东西，它下次就会做得好一点。这种感觉逐渐变得非常可靠，你几乎与它建立起了一种默契，因为它变得越来越值得信赖。而且你的工作也会变得更加愉悦，因为你在把那些确实想自动化的、不想做的部分自动化掉。这里也有一个误区——这正是我推荐这样做原因——那就是只自动化代码生成。但如果你使用 skills，并思考其他所有你想自动化的事情，实际上你就能让一天中最有乐趣的部分保持完整。某种程度上，这是保留编程的乐趣。我喜欢这个建议。这就像打造你自己的工具箱，思考你携带的那些工具。我也有很多类似的体会。我也在用 skills，有很多定制化的小工具，会为我做一些古怪的小事情，或者按我喜欢的方式完成，我很喜欢它们。每次开始新任务时，第一件事就是调出这些工具。我非常认同这个建议。我喜欢 Pokemon 的类比。我甚至想进一步说，这更像厨房里的厨师。你有自己的刀，你带着刀去工作，磨刀，保养刀，这些刀就是你的工具。开发者也可以这样看待他们的 skills，以及他们与 agent 协作的方式。这就是你的刀具包，你可以折叠起来随身携带，把它磨得更锋利、更好，带到下一个项目中。每个人都应该这样思考：构建能够接入这些系统的 primitives。这个建议真的很棒。
Tibo，这次让我们得以一窥 OpenAI 的幕后，非常精彩。很高兴你能来节目。在结束之前，你想把听众导向哪里，让他们了解更多关于 Codex 的信息，或者关注你和你正在做的工作？你可以在 Twitter 上关注我，我在那里相当活跃，几乎每天都会分享技巧。我团队里的很多人也很活跃。此外，我们有越来越出色的开发者文档，正在快速完善中。当然还有开源仓库，你可以在那里提交 issue、参与讨论，成为社区的一员。我真的想感谢你今天邀请我上节目，能聊这些事情我非常开心。太棒了。我们也很高兴你能来，我们会在节目备注中附上所有这些链接，大家可以去查看。听众们，本周的 Dev Interrupted 就到这里。但如果你想深入了解 Agentic AI 如何具体重塑工程领导力，一定要查看我们的 LinkedIn，随后只需在任何地方搜索 Dev Interrupted。如果你在听这期节目，也务必查看随附的 newsletter。我们每周都会分享像 Tibo 这样的工程领导者的分析和见解，我们将继续关注这个话题。Tibo，再次感谢你的加入。很高兴能有 OpenAI 的人上节目，我相信很快会再请你回来。保重。当然。再见。