编辑 | 林芯

“我们追求的不是Token 最大化，而是价值最大化。”

“未来根本不应该再存在‘本地任务’和‘云端任务’这种生硬的划分。”

“现在有些人觉得聊天已经过时了，但我认为大家其实低估了它的价值。”

过去几年，“程序员会消失吗？”这个问题不断被提出。Claude Code 创始人Boris Cherny 在播客里直言：“我已经整整半年没有手写过一行代码了。”软件工程师这个头衔活不过今年？

因此很多人认为：未来终将不再需要工程师。

但在这次的 AI Engineer World’s 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取代Codex，Claude急了？而建立在这些模型之上的产品，也正以前所未有的速度不断进步。我想这一点不用我多说，各位都能感受到，如今做工程已经和过去完全不同了。

回顾过去几年，我经历了一连串令人震撼的时刻。

最早，我们只有代码补全；后来发展到了行内预测。接着，我们推出了 Command+K，你可以直接告诉模型需要修改什么，但那时候模型还不会自己验证修改是否正确。后来，模型开始能够自己测试自己的工作成果，而现在，模型已经能够持续执行一个复杂、长期的目标，直到真正完成它。

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 才能持续改进的封闭产品

Raman：Codex 绝不能成为一个只有 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 将根据实际情况选择运行环境

Raman：Agent 会根据实际情况选择最合适的运行环境，充分利用所有可用资源。其实，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 不应该只是一个会话，它应该是真正的 Agent

Peter 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 循环。

让我们一起把它建出来，谢谢大家。

参考链接：https://youtu.be/pMggiOb18tc?si=eIZLnTEg2Ftnbhjy

文章来自：51CTO