让Agent走进开发者的工作现场：Codex十三个月四改形态

10月15日，Every刊出对Codex团队的长篇采访，回顾了十三个月里四次调整产品形态的经过。2025年5月上线的Codex Cloud在OpenAI内部“非常成功”，公开发布后却只换来短期兴趣。团队随后把重心转回本地命令行和编辑器插件，2026年2月又发布不内置代码编辑器、集中管理多个Agent任务的桌面任务中心。到6月，Codex整体周活超过500万。这段经历改掉了一种常见预期：编程Agent只要模型写代码的能力足够强，开发者就会持续使用。

四次调整有一个共同方向：让Agent走进开发者已有的工作现场（本机仓库、终端、编辑器和云端环境），而不是让开发者为Agent重建环境。采用问题因此落在三件事上：能否接入已有工程，用户是否仍要频繁手改代码，界面能否管住并行任务。现有证据支持这三道门槛与采用一同改善，但不能把500万周活单独归因于去掉编辑器。

复盘公开时，故事已有后续。OpenAI在6月宣布收购云端开发环境公司Ona，9月底推出带可复用团队环境的Codex Cloud。GitHub的编程Agent Copilot和AI代码编辑器Cursor也在这一年把云端环境做成了产品的常规部分。当年让Codex Cloud受挫的环境问题，正在成为几家编程Agent共同的主线。

四种入口改变了Agent接入工作的方式

十三个月里，运行位置和交互方式反复重排，形成四种主要产品形态。

命令行界面（CLI）其实比Codex Cloud早一个月小规模公开，云端未获持续使用后才被改成主线，所以这不是四个按发布日整齐接替的产品。

Codex Cloud的落差说明，“接入现有工程”排在模型分数之前。按OpenAI发布材料，它要在隔离环境中预装仓库、依赖和工具。复盘记载，内部标准化环境让这套设置近乎自动，研究员交出的任务也更清楚；外部开发者却可能花数小时搬运软件包、权限和凭证，当时还无法在任务中途纠偏。内部成功没有证明形态适合公开用户，反而遮住了外部接入成本。

本地化也没有把Codex锁死在一个界面。OpenAI公开的App Server架构让桌面任务中心、IDE（集成开发环境）、CLI和云端运行时接入同一运行服务，共享Codex Harness，即控制模型如何使用文件、命令、权限和会话的那一层。界面和运行地点可以继续变，读取工程、调用工具、保存线程与处理审批的底层逻辑能够复用。

无内置编辑器成立，要靠模型与任务管理同时补位

桌面任务中心真正改变的是默认纠错方式。

多个任务按项目和线程组织，每个Agent用独立worktree修改同一仓库；用户在线程里查看差异、逐行评论，再让Agent继续改。发布页也允许把代码打开到外部编辑器手调，所以“无编辑器”只是应用不内置编辑器。

这条路径要模型足够可靠才省事。复盘显示，早期团队成员连替换一句话都嫌重新提示麻烦。

• GPT-5.2-Codex改善后，更多人改用行内评论让Agent重做，不再直接编辑；
• 2月5日发布的GPT-5.3-Codex又加入任务中途引导。

去掉编辑器没有独立创造委托习惯，是模型理解反馈、差异审阅和并行隔离一起把“自己改”变成了“说明哪里要改”。

所以桌面任务中心不只是给CLI套一层图形界面。命令行解决本地接入，编辑器插件解决即时查看和手改，桌面任务中心新增的是多任务控制面：用户从盯住一个Agent的每一步，转为在多个线程之间分配工作、查看进度和验收结果。采用条件也从“模型能否完成一次修改”扩展到“一个人能否稳定管理几项委托”。

Copilot借仓库现成配置，Cursor让Agent自己搭环境

到2026年秋，Codex、GitHub Copilot和Cursor的形态已相当接近：云端和本地都能跑，并行任务有专门界面，结果按差异或PR（合并请求）验收。

真正分开的是云端环境由谁准备，以及手工编辑离主流程多近。

Copilot让Agent站进团队已有的工程现场：代码、议题和PR本来就在GitHub上，依赖安装写进团队熟悉的Actions工作流，环境不必另搬一次。Cursor让Agent自己摸索搭好环境，存成快照或配置文件反复用，10月又把单个环境的仓库上限提到300个。两种办法回答的是同一个问题：外部用户不该替Agent临时搬运依赖、权限和凭证。

由此看，Codex当年的受挫不说明开发者不要云端，更接近不愿为Agent重建环境。分歧留在手工编辑的位置：Cursor把编辑器保留在主流程旁，Copilot把纠偏放进PR审阅，Codex以差异评论为中心、编辑器放在应用之外。

公开数据仍无法按同一口径比较三家留存。GitHub 10月28日发布的年度开发者报告Octoverse显示，2026年9月GitHub上超过40%的PR由可识别的编程Agent起草初稿，3月时为17%。这个数字覆盖所有可识别的Agent，拆不到某一家，只说明交给Agent起草的工作量在快速上升。

云端以可复用环境回到Codex主线

500万首先证明的是多项变化共振。

OpenAI在3月19日称Codex周活超过200万，6月2日称整体周活超过500万；后者覆盖应用、CLI、IDE和云端等入口，不是桌面应用的独立周活。同期OpenAI临时向Free和Go用户开放Codex、把付费档位限额翻倍，GPT-5.3-Codex和GPT-5.4先后进入Codex。界面、模型、价格和分发同时改变，周活曲线识别不出任何一项的单独贡献。7月9日Codex应用又并入ChatGPT桌面客户端，产品形态与ChatGPT分发更难分开。

此后OpenAI的三步动作，补的正是2025年Codex Cloud缺的那一块。6月11日宣布收购Ona（交易须经监管批准），称Codex的工作将不再受单一设备或活跃会话限制，智能体可在客户自己的云环境中运行，由企业控制凭据范围、活动记录和审阅流转。9月29日的开发者大会DevDay推出Codex Cloud，用可复用开发环境让任务快速启动，团队共享已批准的设置和权限；同场加入云端自动代码审查，并通过Agents API把Codex的执行Harness托管开放给外部应用。10月6日，Atlassian扩大与OpenAI的合作：超过3000名Atlassian开发者在终端、IDE和代码审查中使用Codex，Codex可经插件读取Jira工作项和Confluence文档。

三步合起来，环境改由团队预先批准、反复使用，不再靠每个用户临时搬运。工程上下文从代码仓库延伸到任务系统和文档，运行也不再绑在一台电脑或一次会话上。运行位置在十三个月里从云端摆到本地又回到云端，没有变的是那三道门槛。

这次回归还没有结果。

• 在本文所列OpenAI公告中，6月2日的500万是最近一次披露的Codex整体周活；
• Ona公告称Codex较年初增长400%，此后没有按入口拆分的数据。

若可复用环境让云端任务的持续使用追平本地入口，Codex 2025年的受挫就应归因于环境而非云端本身；若云端仍明显落后，本地接入就是更持久的采用条件。