OpenClaw 创始人 Peter Steinberger 也发表了演讲他提出瓶颈在不断变化现在开始变成注意力。去年我最大的限制主要还是 Token 数量之后我遇到的新瓶颈变成了计算资源如今我最大的限制已经变成了注意力。“我们追求的不是Token 最大化而是价值最大化。”“未来根本不应该再存在‘本地任务’和‘云端任务’这种生硬的划分。”“现在有些人觉得聊天已经过时了但我认为大家其实低估了它的价值。”过去几年“程序员会消失吗”这个问题不断被提出。Claude Code 创始人BorisCherny 在播客里直言“我已经整整半年没有手写过一行代码了。”软件工程师这个头衔活不过今年因此很多人认为未来终将不再需要工程师。但在这次的 AI Engineer Worlds Fair 里OpenAI 开发者体验负责人Romain Huet 和 Codex产品负责人 Alexander Embiricos 给出了一个完全相反的判断AI 工程师正在吞噬世界。而事实上我们认为情况恰恰相反。曾经有人说“软件吞噬了世界”后来又有人说“AI 吞噬了软件”。但今天我们想说的是AI 工程师正在吞噬世界。在 Alexander 看来未来主要会有两种交互方式第一种是聊天“我知道现在有些人觉得聊天已经过时了但我认为大家其实低估了它的价值。”第二种则是能够真正动手协作的操作界面。“我们希望无论 Agent 帮你完成多少工作你始终能够保持一种掌控感真正知道自己在做什么并且随时能够深入到底层细节。”OpenAI 作为闭源路径的代表但在会议中Romain 和 Alexander 直言Codex 绝不能成为一个只有 OpenAI 才能持续改进的封闭产品。”因此在整个技术栈的每一层OpenAI 自己使用的就是提供给大家使用的那一套能力。每当你们 Fork 一次 Harness每当你们探索出模型能力的边界OpenAI 也都会因此获得新的经验不断改进产品。OpenClaw 创始人 Peter Steinberger 也发表了演讲他提出瓶颈在不断变化现在开始变成注意力。去年我最大的限制主要还是 Token 数量之后我遇到的新瓶颈变成了计算资源如今我最大的限制已经变成了注意力。还给出了Agent 循环真正可扩展的三个关键变化服务端上下文压缩、协调机制、自动触发。当然除了上面的内容还有更多硬核的观点全文就在下面AI 工程师正在吞噬世界Raman今天现场来了超过 7,000 位 AI 工程师。真正令人兴奋的不只是有这么多人在讨论这项技术更重要的是在座的各位正是每天都在使用它、推动它不断突破边界的人。工程的未来并不是从别处降临而是真正由这个房间里的每一个人共同创造而且发展的速度比绝大多数人预想的还要快。也正因如此我一直觉得很奇怪为什么还有那么多人在说工程师会消失他们的理由是编程正在被不断抽象化因此未来终将不再需要工程师。而事实上我们认为情况恰恰相反。曾经有人说“软件吞噬了世界”后来又有人说“AI 吞噬了软件”。但今天我们想说的是AI 工程师正在吞噬世界。AI 工程师就是今天在这里不断推动技术边界的人。正是你们在探索如何把这种全新的能力带给每一个人。而且现在正是成为一名工程师最好的时代。因为工程从来都不仅仅意味着写代码。工程一直都是关于解决问题既解决自己的问题也解决他人的问题。它意味着把最新的科学成果与设计、美感、判断力以及最重要的想象力结合起来创造出真正能够被人们使用的产品。从这个意义上来说这并不是工程时代的终结而是工程精神的一次回归重新回到它最初的本质。现在每 6 周就会推出一个模型新版本Alexander与此同时我们所依托的技术平台也在不断加速发展速度越来越快。举个例子过去我们大约每 15 个月发布一个新模型而现在平均大约每 6 周就会推出一个新版本。我们前些天发布了 5.6 系列模型的预览版我们非常期待尽快把它交到大家手中。GPT5.6正式发布Sol杀穿榜单ChatGPTWork取代CodexClaude急了而建立在这些模型之上的产品也正以前所未有的速度不断进步。我想这一点不用我多说各位都能感受到如今做工程已经和过去完全不同了。回顾过去几年我经历了一连串令人震撼的时刻。最早我们只有代码补全后来发展到了行内预测。接着我们推出了 CommandK你可以直接告诉模型需要修改什么但那时候模型还不会自己验证修改是否正确。后来模型开始能够自己测试自己的工作成果而现在模型已经能够持续执行一个复杂、长期的目标直到真正完成它。AI 不只是会写代码它开始接管整个开发流程Alexander 光是今年的发展就已经令人疯狂。我个人最喜欢的是 Codex App、Goal Mode、Remote 等功能这些产品真正改变了我们的工作方式。当然如果我们自己不用 Codex 来开发 Codex也根本不可能做到这些。但在我看来更令人兴奋的是现在的 Codex以及各种 Agent已经能够完成任何你自己能够在电脑上完成的任务。这意味着它们帮助你的不只是写代码。它们还能参与编码之前发生的事情也能参与编码之后发生的事情这一点至关重要。今天大家一定会反复听到一个词 Loop。如果 Agent 不只是知道你要完成什么工作还知道为什么要完成这项工作那么它就能够主动承担越来越多的任务。如果再进一步让它参与后续的代码评审以及部署它就能真正把更多工作完整地落地。有了这一切我们当然能够更快地推进工作。但对我这个做产品的人来说更令人兴奋的是我们能够做出更好的产品决策。例如我们现在能够快速原型验证更多创意也能够投入更多时间与用户交流。聊天被低估了我们的目标绝不是取代工程师Alexander现在模型已经变得非常强大了。如果给我和模型同样的时间去完成一个中等复杂度的计算机任务至少以我个人的情况来看对于大多数普通任务模型很可能会比我完成得更好。既然模型在某些方面已经比我们更聪明几乎什么事情都能做那么问题就来了我们应该如何塑造这种能力我们每天使用的产品究竟应该是什么样的体验为了回答这个问题我们回到了 OpenAI 的使命。其中最重要的一句话就是让 AGI 惠及全人类。围绕这个目标我现在主要思考两个问题。第一个问题是如何让 Agent 真正能够在现实世界中完成任务也就是说它们究竟能够做些什么随着时间推移Agent 正在连接越来越多的工具和系统。至于它们运行在哪里我们稍后再谈。第二个问题则是我们应该如何使用这些 Agent围绕它们我们真正希望打造一种怎样的产品体验我们的目标绝不是自动化、取代工程师而是尽可能放大工程师的能力。如果要描述这种产品形态其实非常简单。我读过很多科幻小说也看了不少超级英雄电影。我觉得里面很多看似简单的设定其实方向大致都是正确的。我认为未来主要会有两种交互方式第一种是聊天。我知道现在有些人觉得聊天已经过时了但我认为大家其实低估了它的价值。我喜欢用团队协作来打比方。大多数时候你只是和团队成员交流他们就会去把事情做好。你并不希望每完成一项工作都要站在同事背后盯着看或者每一步都跑到他的工位旁边监督。绝大多数时候你只需要告诉他们要做什么然后放手让他们发挥。只有偶尔当某个问题特别复杂时你才会真正深入进去与他们一起研究每一个细节。这也是我们设计产品时始终坚持的理念。我们希望无论 Agent 帮你完成多少工作你始终能够保持一种掌控感真正知道自己在做什么并且随时能够深入到底层细节。我们不希望产品让人觉得一旦想查看底层实现、甚至拆开来看就变得异常困难。而 Codex App就是我们迈出的第一步。它提供了一个非常简单的聊天界面不仅可以用于编程也可以完成各种其他工作。你可以先和它对话再根据需要不断深入。CLI 很难承载真正意义上的协作式工作体验Alexander 比如这里展示的是 Raman 对下一场世界杯比赛的预测比分。在这个界面里你既可以直接指向某一段内容说“帮我修改这里。”当然也可以选择自己动手修改。这里还有一个有趣的小故事。项目刚开始的时候我曾向今天现场的一些朋友介绍过这个想法。当时有人非常坚定地告诉我“我绝对不会用这种工具。我永远不会离开 Terminal也不会离开 Vim 或 Emacs。”但现在他们已经开始使用它了。事实上即使在我们团队内部当初也有很多人质疑我们为什么要做这样一个产品大家已经很喜欢 CLI也很喜欢 IDE。但我们的观点是CLI 很难承载真正意义上的协作式工作体验。CLI 更适合聊天式交互而 IDE 的问题则在于它把代码放在了第一位。但现在是时候转换一种工作方式了。未来更像是与队友合作先交流再在需要的时候深入代码细节。Codex 绝不能成为一个只有 OpenAI 才能持续改进的封闭产品RamanCodex 绝不能成为一个只有 OpenAI 自己才能持续改进的封闭产品。因此我们从一开始就把 Codex 设计成一套分层架构让任何人都可以在它之上继续构建。今天我们也想向大家展示这套技术栈。最底层当然是模型刚才 Alexander 已经介绍过模型的发展速度有多快。而大家现在正是通过 Responses API 来使用这些模型。事实上我们开发 Codex App 的方式和大家完全一样。我们也是通过同一套 API、调用同一批模型来构建产品。也就是说我们使用的正是提供给所有开发者的能力。每当 Codex 需要新的能力时我们都会尽量先把它沉淀到 API 中让所有开发者都能受益。最近一个例子就是 Context Compaction上下文压缩。Codex 需要一种机制在执行长时间运行任务时对超长上下文进行压缩整理。于是我们先把这项能力做进了 API。这意味着你们自己的 Agent也能够直接使用我们为自己打造的这些基础能力。再往上一层就是 Codex Harness。它同样已经开源。因此你可以阅读源码、Fork 项目也可以根据自己的需求进行修改和扩展。对于 Agents.md我们也采取了相同的思路。我们没有重新发明一种只属于 Codex 的指令文件格式而是选择了一个其他 Agent 同样能够采用的标准。Harness 默认使用 OpenAI 的模型但这些模型并不是写死在系统里的。如果你希望替换成开源模型同时保留同样的 Agent 工作流程也完全没有问题。除此之外我们还把 Codex Harness 引入了模型后训练流程。这样一来模型能够学习如何调用工具、如何在真实环境中完成导航而这一整套训练环境本身也是开源的。举个例子OpenCode 团队就能够直接查看我们的参考实现。他们可以保留自己觉得有价值的部分也可以完全替换掉其他实现按照自己的思路重新设计。比如我知道他们当时就在研究 ChatGPT 登录认证相关的实现方式。他们能够直接阅读源码从中学习。我们认为这种开放透明的方式远比让开发者自己去逆向分析我们的实现和发布流程要好得多。OpenAI我们不会做一套自己用、一套给开发者用Raman再往上一层来说如果我们希望把这套 Harness 集成到各种应用里又该怎么做比如如何让用户直接使用自己现有的 Codex 订阅登录不同的应用事实上我们自己也遇到了同样的问题。当时我们既要开发 VS Code 扩展又要开发 Codex App因此需要一种统一的方式来管理和调用这套 Harness。于是我们开发了 Apps Server并且同样将它开源。Apps Server 并不是一个为了社区单独做的适配层它本身就是我们自己的产品所使用的正式方案而你们也可以直接使用它。举个例子X 上的 Dimilian在我们正式发布 Codex App 之前就利用 Apps Server 开发了一款自己的原生应用 Codex Monitor。后来他加入了我们的团队并且亲自开发了 Codex iOS。继续往上在应用层我们同样希望创新不会受限于我们的想法。因此我们提供了一系列可扩展的基础能力例如刚才屏幕上展示的应用内浏览器以及插件。Browser Use 和 Computer Use 都是基于同样的插件扩展接口开发出来的而这些接口也完全向所有开发者开放。除此之外我们最近还针对不同职业角色推出了一系列 Codex 专用插件例如方便数据科学家、设计师等不同人群进行个性化定制。这些插件同样全部开源。你可以查看它们的内部实现从中获得灵感并根据自己的需要进行修改。我们的目标就是尽可能让整个生态保持开放和灵活。更重要的是现在用户已经能够在越来越多的地方使用自己的 Codex 订阅。无论是 OpenCode、Pi、Droid、OpenClaw还是 Xcode、JetBrains 等 IDE都已经开始支持这一生态。可以看到它们正在逐渐成为大家日常工作的重要组成部分。这也是为什么我们如此重视与大家一起建设一个开放生态。如果这一部分内容大家只需要记住一句话那就是我们并没有为 OpenAI 自己构建一套系统再另外为开发者做一套功能缩水的版本。在整个技术栈的每一层我们自己使用的就是提供给大家使用的那一套能力。每当你们 Fork 一次 Harness每当你们探索出模型能力的边界我们也都会因此获得新的经验不断改进产品。今天这里聚集着 7,000 位最优秀的 AI 工程师。我相信你们不仅将定义我们未来如何体验 AI也将共同定义整个世界未来如何体验 AI。我们追求的不是Token 最大化而是价值最大化Alexander 在大家的帮助下我们正让 Agent 变得越来越有价值。接下来的问题就是我们如何真正释放它们的价值这里我们追求的并不是 Token 最大化。我们内部有一个词也许大家也在用价值最大化。当我们与许多工程团队负责人交流时大多数讨论最终都会围绕这个主题展开。接下来我们想分享几个大家最关心的话题。其中有些问题我们已经取得了很大进展还有一些则依然有很大的提升空间。首先就是成本效率。每个人都希望拥有最先进的模型能力无论你采用哪一种评测体系大家都希望使用最优秀的模型。例如在这里展示的 Terminal Bench 测试中目前表现最好的是 GPT-5.6 SOL。正如刚才所说我们已经迫不及待希望大家能够亲自体验它。当然除了智能水平之外大家还希望在相同预算下获得尽可能多的智能能力。这正是成本效率的重要意义。长期以来降低成本一直都是我们的重点方向而现在这些投入也正在不断带来成果。例如GPT-5.6 Terra 已经能够提供接近 GPT-5.5 的智能水平但成本却降低了一半。而 Luna 在这项评测中甚至超过了一些非常知名的模型但价格仅为每百万输入 Token 1 美元每百万输出 Token 6 美元。具体与其他模型相比便宜多少就留给大家自己去比较了。但我们认为这样的性价比已经非常惊人。750 Token/秒意味着什么推理速度和智能终于不再二选一Raman接下来我想聊聊另一个同样重要的话题速度。GPT-5.3 Codex Spark 已经向大家展示了高速度究竟能够带来什么。但我们也知道大家真正想要的是最前沿的智能而不是为了速度去牺牲模型能力。现在我们已经能够让 GPT-5.6 Sol 运行在 Cerebras 平台上实现每秒 750 Token 的推理速度同时依然保持最先进的模型能力。为了帮助大家建立直观感受这样的速度意味着一份规模相当可观的 Pull Request大约 10 秒钟就能完成。而速度带来的意义远远不只是更快得到一个答案。真正重要的是你能够利用这些速度做什么。例如一个 Agent 可以同时尝试五六种不同方案并行完成再从中选择最优结果而完成这些工作的时间甚至比过去生成一个方案还要短。所以当最先进的智能再配合这样的推理速度时我们相信它将释放出全新的可能性。这时候与 AI 的协作体验也会发生变化。它不再像是在等待 AI 回复你而更像是一位真正的同事一边工作一边不断把最新结果展示给你。Codex Cloud将迎来重大升级未来不应存在“本地任务”和“云端任务”的划分Alexander现在很多人都会一直让笔记本电脑保持开着好让 Agent 能够持续工作。虽然这件事挺有意思但真正理想的状态其实应该是我们可以安心合上电脑。与此同时Agent 依然能够在各自独立的运行环境里同时并行完成许多任务。事实上这一直就是我们的目标。Codex 最早的重要发布之一就是 Codex Cloud而它很快也将迎来一次重大升级。更进一步来看我们认为未来根本不应该再存在“本地任务”和“云端任务”这种生硬的划分也不应该让用户自己决定每项工作究竟运行在哪里。真正理想的体验其实就像我前面提到的那样你只需要拥有一个 Agent。无论身处何地、任何时候、面对任何问题你都可以直接与它交流。至于它应该完成哪些工作、应该选择什么样的运行环境、哪些任务适合本地、哪些适合云端都应该由它自己判断和安排。未来六个月Agent 将根据实际情况选择运行环境RamanAgent 会根据实际情况选择最合适的运行环境充分利用所有可用资源。其实Theo 上周末就在 X 上发了一条关于这个话题的推文我觉得他说得非常到位。Alex你怎么看你觉得他说的这些会在六个月内实现还是更久Alexander我不确定具体细节是否完全一致但如果说的是整体趋势我认为甚至不用六个月。Raman是啊以现在的发展速度来看如果真的比六个月更快我一点也不会惊讶。接下来让我们欢迎 “Claw Father”Peter Steinberger从亲自调度 Agent到管理 Agent 团队Peter Steinberger 大家早上好。仅仅几个月时间一切已经发生了多大的变化。那时候我桌面上同时开着十几个 Terminal 窗口。我不断等待其中某一个任务完成然后再去调整 Agent、安排下一项工作。如果是在今年一月份这已经算是效率的巅峰了但今天回头看这种方式多少有点傻。我当时以为自己是在协调整个系统。其实我只是一直在轮询我既是调度器也是路由器还是记忆系统。一开始我只是和一个 Agent 配合但同时打开十个终端。后来我已经不再是在“结对编程”。我更像是在管理十位直接向我汇报工作的员工。而现在我大部分时间只是和一个长期运行的 Manager Agent 对话。它再把任务分配给自己的团队去完成。当然遇到特别复杂的问题时我依然可以深入到底层与某个 Worker Agent 一起协作。但这已经不是默认模式了。现在我更像是在管理一家由多个 Agent 组成的小公司而 Manager 就是团队负责人。Agent 循环真正可扩展的三个关键变化Peter Steinberger 有三个变化让这种工作方式真正成为可能。第一是服务端上下文压缩。它让长期运行任务变得足够可靠我终于不用再频繁创建新的会话来维持上下文。第二是协调机制。一个线程就能够创建、组织并管理多个正确的项目和任务。第三是自动触发。当某件事情发生时系统能够自动唤醒同一个 Manager Agent。于是我们拥有了持续存在的上下文、任务委派、自动触发。这三者组合起来就是完整的 Agent Loop。但当这个闭环真正跑起来之后你很快就会发现新的瓶颈。瓶颈一直在移动。去年我最大的限制主要还是 Token 数量。后来我加入了 OpenAI这个问题基本解决了。当然我知道这种解决办法显然没法规模化推广。之后我遇到的新瓶颈变成了计算资源。所有这些 Agent 同时运行时我的 MacBook 风扇几乎像喷气发动机一样狂转。现在这个问题基本也解决了。我们让 Agent 在独立的测试机器上运行测试而不是占用本地电脑。瓶颈在不断变化现在开始变成人类注意力Peter Steinberger 如今我最大的限制已经变成了注意力和 Token、计算资源不同注意力不是可以简单增加的资源。因此现在最重要的一项能力就是决定自己的注意力应该投入在哪里。我想问大家一个问题你们是不是还会一直盯着 Agent 写代码看着代码一行一行滚动我知道那种感觉确实很酷以前的模型也确实需要这样。因为你会看到 Agent 开始朝错误方向走于是赶紧按下 Escape把它拉回来再重新调整方向。但最新一代模型已经非常擅长理解你的真实意图所以现在一直盯着 Agent 输出代码其实已经有点浪费时间了。Manager 不应该只是一个会话它应该是真正的 AgentPeter Steinberger举个例子。假设有人在我的某个开源项目里提交了一个 Issue。首先Manager Agent 会被自动唤醒。它会结合整个项目的目标、已有笔记以及整体规划判断这个 Issue 是否符合项目方向。如果符合它就会创建一个 Worker Agent。Worker 会负责调查问题、完成代码修改、运行测试。随后还可以由另一个 Agent 对修改结果进行 Code Review。整个过程中我完全不需要盯着这些 Agent 工作也不用阅读它们之间的每一条中间消息。只有当 Manager 真正需要我参与时它才会回来找我。它会把 Pull Request、原始 Issue、建议修改的 Diff甚至一段演示视频或者一个已经运行起来、我可以通过 VNC 远程连接查看的构建环境一起交给我。我只需要审核一次留下意见必要时批准。随后整个闭环继续自动运行。等所有检查通过之后它就会自动完成合并。整个过程中Agent 负责执行内部循环。而我负责设定方向并在外部循环中做出关键决策。其实Paul Salt 已经在使用类似的工作方式。他固定运行着一个相当于“Chief of Staff”的 Agent。它每十分钟自动唤醒一次负责协调他在 GitHub 上的所有工作Agent 会在侧边栏创建不同的话题线程。当某项工作真正需要人工介入时Paul 再进入对应线程继续指导。一旦 Manager Agent 能够长期运行把它绑定在一台笔记本电脑上就开始显得很不合理。Codex 已经能够在不同主机之间迁移任务OpenClaw 也已经拥有 Gateway 和 Node 的架构。但我认为它们都还不是最终形态。未来我甚至不希望再去思考“我到底在哪台电脑上工作”我的 Agent 应该能够连接我的任何设备。它应该知道哪些任务适合放在云端完成哪些任务必须依赖我的本地机器。Manager 不应该只是一个被困在某个应用里的会话它应该是真正的 Agent。无论我身在何处我都能够给它发消息、在 Slack 里控制它或者通过任何渠道与它交流。更进一步说为什么我不能直接告诉 Agent 我的目标然后让它自己设计整个工作闭环呢这个问题我们现在还没有真正解决。目前的发展现状是模型能力的发展速度已经超过了围绕它们构建的 Harness以及整个组织协作方式的发展速度。而如何设计这些系统将成为下一阶段最重要的工程问题。这也正是各位发挥作用的地方。未来不属于二十个 Terminal 窗口未来属于更好的 Agent 循环。让我们一起把它建出来谢谢大家。