OpenAI Codex产品哲学：AI工程师如何从写代码转向管理智能体

在AI Engineer大会上，面对7000多名AI工程师，OpenAI的Romain和Alexander带来了一场关于「AI工程未来」的深度演讲。他们抛出了一个反直觉的观点：AI不会终结工程师，反而让「AI工程师」成为吃掉世界的新物种。本文梳理这场演讲的核心思路，以及Codex产品哲学背后的深层逻辑。

工程师不会消失，而是回归本质

业界流行一种说法：随着编码被层层抽象，最终我们将不再需要工程师。OpenAI团队直接反驳了这一论断。

他们的核心论点是：软件吃掉了世界，AI吃掉了软件，而现在AI工程师正在吃掉世界。 这一论断的起点可以追溯到风险投资人Marc Andreessen于2011年在《华尔街日报》发表的著名文章《Why Software Is Eating the World》。他指出，越来越多的行业正被软件公司颠覆和重塑——从零售（亚马逊）、音乐（Spotify）到电影（Netflix），软件正在成为每个行业价值创造的核心基础设施。OpenAI将这一论断延伸：AI使得软件的边际创作成本趋近于零，从而让「能够驾驭AI能力的工程师」成为新一代的价值创造者，正如当年掌握软件工程能力的人颠覆传统行业一样。

工程从来不只是写代码，而是为自己和他人解决问题——把最新的科学、设计、品味、判断力，尤其是想象力结合起来，做出人们真正能用的东西。从这个意义上说，AI并没有终结工程，反而让工程回归了它的根本。当模型接管了繁琐的代码生成，工程师得以将精力投向更高阶的判断与创造。

技术迭代的速度也在印证这一趋势。OpenAI过去大约每15个月发布一个新模型，如今这一周期缩短到约6周——产品进化的节奏堪称「无情」。

从代码补全到长目标智能体

Romain回顾了过去两年间几个「令人震撼」的能力跃迁阶段：

• 代码补全（Completion）
• 内联预测（Inline Prediction）
• Command K：可以让模型做修改，但不会验证结果
• 模型开始测试自己的工作
• 模型接管长期、困难的目标，直到完成

这一演进路径对应的是大语言模型（LLM）底层能力的几次关键跃升。早期的代码补全依赖统计语言模型，只能做局部的token预测。GPT-3之后，模型获得了跨上下文的语义理解能力，使得「Command K」式的指令跟随成为可能。而「构建-测试」循环的出现，则依赖于工具调用（Function Calling/Tool Use）能力的成熟——模型不仅能生成代码，还能调用代码解释器、终端命令等外部工具来验证输出结果。这一能力在OpenAI的o1系列模型中得到显著增强，通过引入思维链（Chain-of-Thought）推理，模型能够进行多步骤规划和自我纠错。

有意思的是，「构建-测试」这个循环在两年前甚至还不是模型能力的一部分。在过去的Dev Day上，Romain用当时的o1预览版从零搭建了一个迷你无人机界面，但模型无法运行代码或验证自己的工作——他只能「祈祷」演示成功。而如今，模型已经能够自主测试，足以现场控制整个摄像与灯光系统。

这背后是一个关键理念：智能体现在能做你在自己电脑上能做的任何任务。 这意味着它们不只帮你写代码，还帮你处理编码之前（理解为什么要做）和编码之后（审查与部署）的环节。把智能体连接到「为什么做」，它能开启更多工作；连接到「之后做什么」，它能落地更多成果。

产品哲学：不是自动化工程师，而是赋能工程师

当模型在许多中等难度任务上已经能比人做得更好时，一个根本问题浮现：产品应该长什么样？

OpenAI的答案非常明确——目标绝不是自动化工程师，而是最大化地赋能工程师。

他们借用科幻和超级英雄电影的直觉，认为理想产品形态其实很简单，包含两种模态：

对话（Chat）

「有人说chat已死，我认为chat被严重低估了。」你需要一个单一实体，随时随地可以就任何事情向它求助。

动手体验（Hands-on）

当你想要检查、引导或亲自塑造时，你需要一个强大的协作式UI，可以深入到细节的最深处。

这个模式的类比是「和团队合作」：大多数时候你只是聊聊、让队友去做，不需要盯着每一个工作单元；偶尔需要深入时，才一起钻到细节里。基于这个理念，团队构建了Codex应用——一个简单的聊天界面，既能用于编码也能用于其他任何事。

值得一提的是，最初内部对这款产品充满质疑，很多人坚称「永远不会离开终端、Vim或Emacs」。但如今，这些人都在使用它。这一转变背后有深刻的工具设计哲学差异：命令行界面（CLI）以文本流为核心，强调精确控制和可脚本化，是Unix哲学「做一件事并做好」的体现；集成开发环境（IDE）则以代码文件为组织中心，提供语法高亮、调试器、版本控制集成等可视化工具。团队的洞察在于：CLI难以承载任意工作的协作界面，而IDE的顺序是「反的」——传统IDE假设工程师已经知道要写什么，然后提供工具辅助编写；而在AI时代，工作的起点变成了「为什么要做这件事」的对话，代码只是最终的产出物之一。这种工作流的反转催生了「对话优先」的产品设计哲学，其灵感可追溯至Alan Kay提出的「用户界面应符合人类思维模型」的经典HCI（人机交互）原则。

开放的Codex技术栈：任何人都能在上面构建

Romain特别强调，Codex不能是一个只有OpenAI才能改进的封闭产品。团队刻意将其设计成任何人都能在其上构建的分层结构：

• 模型层：开发者通过Responses API使用模型，而OpenAI自己也用同样的API和模型构建Codex应用。当Codex需要新能力（如长任务的上下文压缩compaction），会优先做进API，让所有人受益。
• Codex Harness（运行框架）：完全开源，可检查、可fork、可改造。模型是默认但非硬编码，你可以换成开源模型并保留相同的agent loop。
• AgentsMD：没有另造新格式，而是选择了其他智能体也能通用的命名方式。
• AppServer：统一控制harness的开源路径，这正是OpenAI自己构建VS Code扩展和Codex应用所用的路径。开发者Toma基于AppServer在Codex应用发布前就做出了自己的原生应用Codex Monitor，如今他加入了团队并开发了Codex的iOS版本。
• 应用层插件：如浏览器使用、计算机使用，以及面向数据科学、设计等特定角色的插件，均为开源。

Codex Harness中的「agent loop」是现代AI智能体系统的核心架构模式，通常指「感知-规划-行动-观察」的循环迭代过程：模型接收环境状态（如代码库、错误信息），生成行动计划，调用工具执行动作（如运行测试、读写文件），再将执行结果反馈回模型作为下一轮输入。这一模式源自强化学习中的智能体-环境交互框架，并被AutoGPT、LangChain、LlamaIndex等早期开源框架广泛采用和推广。将harness开源的战略意义在于建立技术生态的「护城河」——当社区开发者基于同一套loop框架构建工具时，所产生的边界案例和能力需求会自然流回平台，形成数据飞轮效应。

核心信息只有一个：OpenAI没有为自己建一套系统、再为开发者建一套简化系统。我们用的就是给你们的东西。 每一次社区fork框架、触碰能力边界，都成为OpenAI学习和改进的养分。

Value Maxing：从消耗Token到最大化价值

当智能体变得爆炸性地有用后，真正的问题是如何从中获取价值。团队提出了一个核心概念——Value Maxing（价值最大化），而非token maxing。围绕这一主题，他们分享了三个方向的进展：

成本效率

每个人都想要前沿智能，但也想要尽可能多的智能，这就要靠效率。GPT 5.6 Terra带来了GPT 5.5级别的智能，成本却只有一半。Luna模型在评测中击败了一些知名模型，价格仅为每百万输入token 1美元、每百万输出token 6美元。

速度

GPT 5.6 Solve运行在Cerebras上，实现了每秒750个token的前沿智能推理，大约相当于10秒写出一份相当规模的PR。这一突破有其硬件基础：Cerebras Systems的旗舰产品WSE（Wafer-Scale Engine）采用晶圆级集成方案，将整块硅晶圆制成单一芯片，片上内存带宽远超传统GPU集群架构。传统GPU集群需要在多块芯片间传输KV Cache（键值缓存），而WSE的片上SRAM可以直接访问，消除了跨设备通信瓶颈。更重要的是速度能解锁的可能性——当生成一个答案的时间成本足够低时，智能体可以并行尝试五六种不同方案，然后挑出最佳结果，所花时间甚至不到过去生成单个答案的时长。这让它感觉不再像「等AI回复」，而更像一个「边做边给你看结果」的同事。

运行环境

很多人开着笔记本让智能体持续工作。理想状态应该是：关掉电脑，让多个任务在各自隔离的机器上并行运行。未来不应该有「本地任务」和「云端任务」这种尴尬区分——你只需要和一个智能体对话，由它判断哪个环境适合当前工作。

从操作单个智能体到管理智能体团队

演讲的高潮是特邀嘉宾、被称为「claw father」的Peter Steinberger的分享，他讲述了自己工作方式的根本转变。

几个月前，他还在同时操控10多个终端窗口，等一个完成好抢过来排新活。他自嘲：「我以为自己在编排，其实我只是在轮询——我成了调度器、路由器和内存。」

如今，他主要与一个长期运行的「经理」智能体对话，由它把工作委派给一支团队。遇到棘手问题时，他才下沉去和某个worker直接结对。默认模式变了：他管理的是一家由智能体组成的小公司的经理。

实现这一转变靠三个关键变化：

1. 服务端压缩（compaction）：让长任务足够可靠，无需再围绕新会话做优化。这一技术的核心思路类似于操作系统的内存压缩：在上下文接近上限时，由模型或专用组件对历史信息进行摘要压缩，保留关键决策节点和任务状态，丢弃冗余的中间步骤细节，从而为新的行动留出空间。服务端实现意味着压缩逻辑由平台统一处理，开发者无需在应用层自行管理上下文生命周期。
2. 协调（coordination）：让一个线程创建并引导正确的项目
3. 自动化触发（triggers）：某事发生时能唤醒同一个经理

持久上下文、委派、触发——这就构成了完整的「loop」。

Peter还观察到一个有趣现象：瓶颈在不断移动。早先他受限于token，后来受限于算力，如今主要受限于注意力——这是无法简单扩容的资源。这一洞察与认知科学和信息经济学中的经典命题高度吻合。诺贝尔经济学奖得主Herbert Simon早在1971年就指出：「信息的丰富必然导致注意力的匮乏」——这被后人称为「注意力经济」的理论源头。在AI智能体时代，当AI能够无限生成代码、方案和报告时，人类工程师的核心稀缺资源变成了「决定看什么、相信什么、批准什么」的判断带宽。这与管理学中对「有限理性」（Bounded Rationality）的描述一脉相承——人类决策者的认知资源天然有限，当可处理的信息量超过阈值，决策质量反而会下降。因此，最重要的技能变成了「决定把注意力花在哪里」。

他直言，盯着智能体看代码飞过已是浪费时间，因为最新模型对意图的理解好到无需实时监督。他设想的理想形态是：有人在开源项目提issue，经理智能体醒来、对照项目目标判断是否合适，创建worker去调查、实现、跑测试，再由另一个智能体审查结果，最后返回一个PR、原始issue、提议的diff，甚至一段视频或可VNC进入的运行构建。他只需审查一次、留个备注、批准，循环便继续。这正是「只需审查一次、留个备注、批准」工作流的核心价值所在——智能体系统的设计目标不是最大化信息输出，而是在正确的时间、以正确的粒度，将最关键的决策点呈现给人类。

结语：下一个工程问题是设计更好的Loop

Peter的总结点出了整场演讲的核心：模型进化的速度已经超过了围绕它们的框架和组织。设计这些框架，就是下一个工程问题。

「未来不是20个终端窗口，而是更好的loop。」当模型能力已经足够强大，AI工程师的价值正在从「操作单个智能体」转向「设计智能体协作的循环系统」。这或许正是这场大会想传递给7000名工程师的核心命题——工程的舞台没有缩小，而是升维了。