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

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

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

当 Claude Code 创始人 Boris Cherny 说出“我已经整整半年没有手写过一行代码”时，一个流行了很久的问题再次被推到台前：既然 AI 已经可以独立写代码、跑测试、改 Bug，软件工程师还有存在的必要吗？

在 AI Engineer World's Fair 上，OpenAI 给出了一个看似反直觉的答案。

工程师不仅不会消失，反而将获得前所未有的能力。继“软件吞噬世界”“AI 吞噬软件”之后，下一个阶段是：AI 工程师吞噬世界。

OpenAI 开发者体验负责人 Romain Huet、Codex 产品负责人 Alexander Embiricos，以及被称为“OpenClaw 之父”的 Peter Steinberger，从三个角度描绘了同一幅图景：模型越来越强之后，真正值得争夺的已经不再只是 Token、算力或速度，而是如何把 AI 转化为现实价值，以及人类该把有限的注意力放在哪里。

AI 工程师不是消失，而是回到工程的本质

现场聚集了超过 7,000 名 AI 工程师。Romain Huet 认为，真正重要的并不是数字本身，而是这些人每天都在使用新技术，并不断把模型能力推向边界。

外界常把编程能力的持续抽象，理解为工程师即将退出历史舞台。但在 OpenAI 看来，这恰恰混淆了“写代码”和“做工程”。

工程从来不只等于敲下多少行代码。它的核心始终是发现问题、解决问题，再把科学成果、产品判断、设计审美和想象力组合起来，做出真正有人愿意使用的东西。

代码生成得越快，工程师能够触达的问题反而越多。于是，今天发生的并不是工程时代的终结，而是工程精神重新回到原点：人负责定义方向与价值，AI 负责把越来越多的执行工作变成现实。

这也正是 OpenAI 所说的“AI 工程师正在吞噬世界”。

从 15 个月一代，到平均 6 周一次更新

支撑这场变化的，是模型和产品迭代速度的同步加快。

Alexander 提到，过去 OpenAI 大约每 15 个月推出一个新模型，如今平均约 6 周就会迎来一次新版本。现场还提到了刚刚开放预览的 5.6 系列模型，OpenAI 希望尽快把它交到更多开发者手中。

模型能力的演进，也直接改变了编程产品的形态。

最早的 AI 编程工具只能做代码补全，随后有了行内预测。再往后，用户可以通过 Command+K 描述修改要求，但模型仍然无法判断自己的改动是否正确。之后，模型开始主动运行测试、验证结果。到了今天，Agent 已经可以围绕一个复杂且长期的目标持续工作，直到任务真正完成。

这条演进路径非常清晰：AI 先是帮人写下一段代码，然后开始理解任务，接着学会验证结果，如今则正在接管更完整的开发流程。

AI 不只写代码，而是进入整个工作闭环

在 Alexander 看来，今年的 Codex App、Goal Mode 和 Remote 等能力已经显著改变了团队的工作方式。OpenAI 自己也在用 Codex 开发 Codex，如果没有 Agent 深度参与，这样的迭代速度很难实现。

更关键的变化是，Codex 和其他 Agent 能做的事情已经不再局限于编码。只要是人在电脑上可以完成的任务，它们原则上都能够参与。

这意味着，Agent 可以进入写代码之前的需求研究、原型验证和方案探索，也可以接手写完代码之后的测试、评审与部署。当它不仅知道“要做什么”，也理解“为什么要做”，一个真正的工作闭环才开始形成。

对工程团队而言，直接收益当然是效率。但 Alexander 更看重效率之外的空间：团队可以用更低的成本验证更多想法，把更多时间留给用户沟通，并做出更好的产品判断。

聊天没有过时，它仍是人类与 Agent 协作的入口

当模型在大量中等复杂度任务上已经能够超过普通人，一个新的产品问题随之出现：如此强大的能力，应该以什么方式交到人手里？

OpenAI 的答案包含两种基本交互。

第一种是聊天。

Alexander 并不认同“聊天界面已经过时”的说法。相反，他认为行业低估了聊天的价值。现实中的团队协作，大部分时候也不是一个人站在同事身后，全程盯着对方如何完成每一步。更自然的方式是说明目标、提供必要背景，然后让对方去执行；只有碰到困难或关键决策时，双方才一起深入细节。

人与 Agent 的协作也应该如此。用户先用自然语言交代任务，让 Agent 自主完成大部分工作；需要的时候，再进入文件、代码、日志和运行环境，直接查看或修改底层细节。

这就引出了第二种交互：一个真正可以共同动手的操作界面。

OpenAI 并不希望 Agent 变成一个不可解释的黑箱。无论它代替用户完成了多少工作，用户都应该知道当前发生了什么，保有控制权，并能随时进入细节。

Codex App 是这种思路的第一步。它表面上保持了聊天的低门槛，但用户可以指向某段内容要求 Agent 修改，也能随时接管、亲自动手。聊天负责建立意图，操作界面则负责在必要时承载协作。

为什么 CLI 和 IDE 都不是最终答案

Codex App 启动之初，不少重度开发者明确表示，他们绝不会离开 Terminal、Vim 或 Emacs。OpenAI 团队内部也有人质疑：已经有 CLI 和 IDE，为什么还需要一个新的应用？

Alexander 的判断是，CLI 很适合输入命令或展开对话，却难以容纳真正丰富的协作体验；IDE 则天然把代码放在整个工作流的中心。

但 Agent 时代的默认关系正在变化。未来的工作方式更像在带一名队友：平时围绕目标交流，必要时才下钻到具体代码。代码依然重要，却不再是所有任务唯一的起点和终点。

Codex 不能只由 OpenAI 一家公司改进

作为闭源模型路线的代表，OpenAI 在这场演讲中却反复强调开放生态。

Romain Huet 表示，Codex 不能成为一个只有 OpenAI 才能持续改进的封闭产品。因此，团队从一开始就把它设计成分层架构，让开发者能够在每一层继续构建。

最底层是模型及 Responses API。OpenAI 构建 Codex App 时使用的，也是面向所有开发者开放的同一套 API 和模型。Codex 每当需要一种新的基础能力，团队会尽量先把它沉淀到 API 中，再让整个生态共享。

Context Compaction 就是一个例子。为了让 Codex 能够稳定执行长时间任务，OpenAI 需要压缩和整理超长上下文，于是先把上下文压缩做进 API。其他开发者构建的 Agent 因而也能直接获得同样的能力。

API 之上是已经开源的 Codex Harness。开发者可以查看源码、Fork 项目，也可以按自己的需求替换和扩展。Agents.md 同样遵循这一原则：OpenAI 没有创造一套 Codex 专属的指令文件，而是选择了其他 Agent 也可以采用的格式。

Harness 默认调用 OpenAI 模型，但模型并没有被写死。开发者完全可以接入开源模型，同时保留相同的 Agent 工作方式。

OpenAI 甚至把 Codex Harness 带进了模型后训练流程，让模型在真实环境中学习使用工具和完成导航，而这套训练环境本身同样开放。外部团队可以直接查看参考实现，保留有价值的部分，再替换不符合自身需要的设计。这比逼着开发者逆向工程产品行为和发布流程更有效。

再往上一层，是同样开源的 Apps Server。OpenAI 在开发 VS Code 扩展和 Codex App 时，需要一套统一的 Harness 管理和调用方式，于是做出了 Apps Server。它不是专门为社区准备的简化适配层，而是 OpenAI 自己产品正在使用的正式方案。

开发者 Dimilian 就曾在 Codex App 正式发布前，基于 Apps Server 做出原生应用 Codex Monitor。后来他加入 OpenAI，并参与开发了 Codex iOS。

应用层也延续了同一种策略。应用内浏览器、Browser Use、Computer Use 以及面向数据科学家、设计师等不同角色的专用插件，都建立在开放的扩展接口之上。开发者可以直接阅读实现、获得灵感，再按自己的场景修改。

如今，用户已经可以在 OpenCode、Pi、Droid、OpenClaw、Xcode 和 JetBrains 等越来越多的产品里使用自己的 Codex 订阅。

OpenAI 希望外界记住的核心是：公司没有为自己保留一套更完整的内部系统，再向开发者提供功能缩水的版本。从 API、Harness、Apps Server 到插件，OpenAI 自己使用的，正是对外提供的那套能力。

每一次 Fork、每一种新工作流、每一次对模型能力边界的探索，也会反过来帮助 OpenAI 继续改进 Codex。

不追求 Token 最大化，而是价值最大化

Agent 变得越来越能干之后，问题不再是如何让它消耗更多 Token，而是如何把模型能力转换成更高价值。

Alexander 把 OpenAI 内部经常使用的这个概念称为“价值最大化”。在与工程团队负责人的交流中，讨论最终往往都会回到同一件事：相同预算、相同时间和相同人力投入下，Agent 究竟能带来多少真实成果？

首先需要解决的是成本效率。团队当然希望获得最前沿的智能水平，但也希望每一美元能够购买更多能力。

按照现场展示的 Terminal Bench 结果，GPT-5.6 Sol 处于领先位置；GPT-5.6 Terra 则以一半成本，提供接近 GPT-5.5 的智能水平。Luna 在这项评测中超过了一些知名模型，而价格为每百万输入 Token 1 美元、每百万输出 Token 6 美元。

这些产品定位指向同一个方向：先进模型不能只在演示和排行榜里表现亮眼，还必须在真实工程预算中算得过账。

每秒 750 Token，速度与智能不必再二选一

价值的另一个变量是速度。

GPT-5.3 Codex Spark 已经证明了高速推理可以怎样改变交互体验，但开发者并不愿意为了快而牺牲模型能力。Romain Huet 在现场表示，GPT-5.6 Sol 已经可以运行在 Cerebras 平台上，达到每秒 750 Token，同时维持前沿模型的智能表现。

这意味着，一份规模不小的 Pull Request，大约 10 秒就能完成。

更快拿到一个答案只是表层变化。速度真正解锁的，是并行探索：Agent 可以同时尝试五六种方案，分别完成并验证，再从中挑出最优结果；整个过程甚至可能比过去只生成一个方案更快。

当高智能和高速度同时存在，人与 AI 的关系也会改变。用户不再像是在等待工具返回答案，而更像在与一名同事实时协作，对方一边推进任务，一边持续展示最新结果。

“本地任务”和“云端任务”的边界将消失

今天，不少人为了让 Agent 持续工作，只能让笔记本电脑一直开着。但理想状态应该是，用户可以随时合上电脑，让多个 Agent 在彼此隔离的运行环境中继续并行执行任务。

Codex Cloud 很快将迎来重大升级。不过在 Alexander 看来，下一阶段的目标并不只是把更多任务搬到云端，而是彻底消除“本地任务”和“云端任务”的生硬划分。

用户不该为每项工作手动选择运行位置。真正自然的体验，是每个人只面对一个 Agent。

无论何时何地，用户只需要描述目标。哪些步骤应该在本机运行，哪些适合交给云端，应该调用什么资源、选择哪一种环境，都由 Agent 根据任务特点自行判断。

Romain Huet 认为，Agent 会逐步学会利用所有可用资源，并自动选择最合适的运行环境。当他问这个趋势能否在六个月内实现时，Alexander 的回答甚至更加激进：整体方向可能根本用不了六个月。

OpenClaw 之父：我不再盯着十几个终端

随后登台的 Peter Steinberger，把话题从产品架构带到了个人工作方式的变化。

几个月前，他的桌面上还同时开着十几个 Terminal 窗口。他要不断检查哪项任务已经结束，调整对应 Agent，再安排下一步工作。今年 1 月，这种状态一度被视为高效，但现在回头看，Peter 发现自己其实在充当整个系统的调度器、路由器和记忆模块。

他起初以为自己在与一个 Agent 结对编程，后来才意识到，那更像是同时管理十名直接向自己汇报的员工。

如今，他大多数时间只和一个长期运行的 Manager Agent 交流，再由 Manager 把任务拆给多个 Worker Agent。只有遇到真正复杂的问题，他才会深入底层，与某个 Worker 共同解决。

默认工作方式已经从“亲自调度每个 Agent”，转向“管理一支 Agent 团队”。

Agent Loop 扩展起来，靠的是三个变化

Peter 总结了让这套模式成为现实的三个关键条件。

第一，服务端上下文压缩。长期任务因此能够保留连续、可靠的上下文，不必频繁创建新会话。

第二，协调机制。一个线程可以创建、组织并管理多个项目与任务，把工作委派给合适的 Agent。

第三，自动触发。当外部事件发生时，系统能够重新唤醒同一个 Manager Agent，继续此前的工作。

持续上下文、任务委派和自动触发组合在一起，构成了完整的 Agent Loop。但当这个闭环真正跑起来，新的限制也会立刻出现。

AI 的新瓶颈，不是 Token，而是人类注意力

Peter 的瓶颈一直在移动。

去年，最紧缺的是 Token；加入 OpenAI 后，这个问题对他而言基本得到解决。随后，瓶颈变成了计算资源，大量 Agent 同时运行，让本地电脑不堪重负。后来，他把测试迁移到独立机器，本地算力压力也随之缓解。

现在，最大的限制变成了注意力。

Token 可以购买，计算资源可以扩容，但一个人的注意力很难增加。因此，Agent 时代最重要的能力之一，不再是亲自处理所有细节，而是判断自己的注意力究竟应该投向哪里。

Peter 反问现场观众：你是否还会盯着 Agent 写代码，看着每一行内容在屏幕上滚动？

早期模型确实需要这种监督。用户经常会看到 Agent 走错方向，立刻按下 Escape，再重新修正提示。但新一代模型已经更擅长理解真实意图，继续全程盯着代码生成，很多时候只是在浪费人类最稀缺的资源。

Manager 不该只是一个会话，而应该是真正的 Agent

Peter 用一个开源项目的 Issue 描绘了未来工作流。

当新 Issue 出现，Manager Agent 会被自动唤醒。它结合项目目标、历史笔记和整体规划，先判断这个需求是否符合项目方向。如果答案是肯定的，它就创建一个 Worker Agent，完成问题调查、代码修改和测试；之后，还可以再交给另一个 Agent 做 Code Review。

在这个过程中，人不需要阅读 Agent 之间的每条消息，也不需要实时盯住执行过程。

只有真正需要决策时，Manager 才会回来找人。它可以一次性交付 Pull Request、原始 Issue、建议修改的 Diff、演示视频，甚至一个已经运行起来、能够通过 VNC 访问的构建环境。

人只需集中完成一次审核，给出反馈或批准。随后，自动化闭环继续运行，所有检查通过后再完成合并。

在这套关系中，Agent 负责内部执行循环，人类负责设定方向，并在外部循环中做关键判断。

Paul Salt 已经在使用类似的工作模式。他长期运行着一个相当于“Chief of Staff”的 Agent，每十分钟自动唤醒一次，协调其 GitHub 上的所有工作，并在侧边栏创建不同的话题线程。只有某件事需要人工介入时，Paul 才进入相应线程继续指导。

一旦 Manager Agent 可以长期存在，把它固定在某一台笔记本上就失去了意义。Codex 已经能够在不同主机之间迁移任务，OpenClaw 也具备 Gateway 与 Node 架构，但 Peter 认为，这些仍然不是最终形态。

未来，人们甚至不需要思考自己正在哪台电脑上工作。Agent 应该能够连接个人的任意设备，理解哪些任务适合云端，哪些任务必须调用本地环境。用户则可以通过应用、Slack 或其他渠道，随时与同一个 Agent 对话。

更进一步，用户只需给出目标，Agent 就应该能够自行设计工作闭环，而不是等待人类逐项配置。

真正落后的，开始变成 Agent 周围的系统

模型能力的进步，已经快过 Harness、产品界面和组织协作方式的演化。

今天的问题不再只是“AI 能不能写出这段代码”，而是如何让 Agent 获得可靠的长期上下文，如何在本地和云端之间调度资源，如何组织多个 Agent 协作，又如何只在关键时刻占用人的注意力。

这也解释了为什么 OpenAI 强调“价值最大化”。当 Token、速度和算力逐渐从稀缺能力变成基础设施，真正拉开差距的，将是系统能否围绕人的目标稳定完成整个闭环。

工程师的角色也因此发生迁移：从直接生产每一行代码，转向定义问题、设计系统、管理 Agent，并对最终结果负责。

AI 没有终结工程师。它只是把工程师能解决的问题，放大到了一个新的尺度。