这段时间，Codex的迭代速度确实令人印象深刻。从桌面端的重大更新，到远程SSH支持，再到Computer Use功能和Chrome插件，其周活跃用户数已突破400万大关。

如今，OpenAI又将Codex整合进了ChatGPT的手机应用。根据官方消息，Codex移动版已以预览形式在iOS和Android版的ChatGPT中上线，支持连接运行Codex的macOS设备，而Windows系统的支持还需稍作等待。

图片来源：OpenAI

不过，更准确地说，Codex移动版更像是桌面端Codex在手机上的一个控制入口。用户可以直接在手机ChatGPT中进入Codex界面，连接至桌面端正在运行的环境，然后通过手机发起新的任务指令，交由桌面端的Codex去执行。

实际上，类似的思路并非首创。Claude Code早在3月就上线了名为Dispatch的功能，允许用户通过手机Claude应用指挥桌面端的Claude Code。而更早之前，OpenClaw等开源项目也已通过接入各类即时通讯平台实现了类似能力。

OpenAI这次算是“虽迟但到”。但关键在于其实际的产品完成度——这家在硅谷“AI御三家”中以产品能力见长的公司，能否凭借后发优势带来更优的体验？

手机成了Codex的第二个入口

需要明确的是，Codex移动版并非一个独立的全新应用。

OpenAI此次并未单独推出Codex的iOS或Android应用，而是选择将入口直接嵌入现有的ChatGPT应用。用户在手机上打开ChatGPT，即可在侧边栏找到“Codex”的入口。

因此，从某种程度上看，这次更新的核心可以理解为：让用户能够通过手机上的ChatGPT，来指挥电脑上的Codex执行任务。

这不仅让全球超过10亿的ChatGPT用户免去了额外安装一个应用的麻烦，更重要的是，OpenAI没有将Codex移动版设计成一个新的独立开发工具，而是将其收纳进ChatGPT这个统一的超级入口。对用户而言，这意味着极短的使用路径——只要桌面端和移动端使用同一账号登录，手机上的ChatGPT就能便捷地连接到安装了Codex的macOS桌面端。

在实际体验中，Codex移动版已经能够直接在手机上发起新需求，并驱动电脑端的桌面版Codex完成任务。此时，手机扮演着一个轻量级的任务控制台角色，用户负责清晰地表述需求，而真正读取项目、执行命令、修改文件、运行测试等重头戏，则依然由桌面端Codex承担。

与此同时，桌面端Codex的实时状态——包括其“思考”过程、具体操作及执行结果——都会同步显示在手机端。这意味着，开发者完全可以在电脑前启动Codex工作后，出门在外时通过手机查看进展，或者直接进行引导操作，推动耗时较长的任务继续执行，而不必被束缚在特定设备前。

甚至，在手机端还能直接调整模型选择、响应速度以及推理深度等参数。

这个分工设计颇为巧妙。手机受限于操作环境、计算性能和屏幕尺寸，本就不适合独立运行编码这类复杂任务，但其便携性使其成为桌面端“随时随地”接入的理想入口。Codex移动版没有生硬地移植全部功能，而是精准提取了最适合移动场景的几项核心：发起需求、查看过程、审批操作、延续对话、检查结果。桌面端Codex完整的思考链、操作步骤和执行结果，在手机上都能同步查看；唯一不同步的是输出的文件本身，它们仍只保存在本地电脑中。

这种处理方式不难理解，毕竟文件和运行环境本就位于本地机器，移动端只需负责同步状态和交互指令，无需将所有产出物再复制一份到手机，这既合理也节省资源。

此外，Codex移动版并非只能连接一台Mac。它可以同时连接多个桌面端环境，例如一台MacBook Pro和一台Mac mini都在运行Codex，那么一部手机就能管理不同电脑上的Codex实例。这相当贴合Codex这类智能体产品的真实工作流。

许多开发者本就使用多台机器协作，例如用随身携带的MacBook处理日常项目，而用Mac mini或远程服务器运行更繁重的任务。过去这些环境往往是割裂的，现在Codex至少开始尝试将它们统一到一个手机入口之下。用户可以在手机上切换不同的主机，查看不同任务的进度，甚至将不同的需求分发给不同的机器处理。

当然，Codex移动版目前仍有一些明显的待完善之处。例如，对话编辑功能尚未支持。这个问题看似不大，但在移动场景下却显得尤为重要。因为手机输入更容易出现错别字、遗漏上下文，或者消息发出后才意识到需求描述不够完整。对于一个能够远程调度桌面端执行任务的入口而言，无法编辑已发送的对话会让人更加谨慎，也在一定程度上降低了从移动端发起任务的流畅感和爽快度。这一点无疑是后续需要补上的。

不过，本次体验中遇到的最大痛点，在于手机端频繁需要重新连接。有时刚在手机上编辑好一段需求，连接却中断了，导致消息无法发出。更令人困扰的是，有时桌面端Codex明明仍在正常运行，手机端却突然进入重连状态，界面出现短暂空白。由于真正的任务执行都发生在桌面端，这种断连通常不会影响最终结果。但从手机端的交互体验来看，这确实有些令人沮丧。

好在，这类问题更像是预览阶段的工程稳定性问题，而非产品设计思路上的根本缺陷。

值得一提的是，Codex移动版并非只服务于本地桌面端。它同样支持连接Codex云端实例，这进一步扩展了手机入口的覆盖范围。甚至像桌面版中自定义宠物这类细节设置也能同步到移动端。后者当然并非核心能力，但它恰恰说明，OpenAI并没有简单地将Codex移动版视为一个临时的远程查看工具，而是真正在围绕Codex构建一套全新的AI工作流和体验。

如果将Codex移动版置于整个智能体产品生态中观察，会更有意思，尤其是在对移动场景下智能体体验的理解上，各家厂商的思路其实存在差异。

上手机，Codex和“龙虾”不一样

目前，主流的智能体产品基本都会支持移动入口，其核心目标是让用户能够随时发起需求，然后由智能体去调用工具、浏览网页、处理文件或完成流程，强调“有事就找智能体”。这在手机端天然成立，因为大量需求本就产生于移动场景。

大体来看，主要有几种实现思路。一种是像OpenClaw、Hermes这类开源智能体工具，它们普遍支持接入即时通讯软件，让用户可以通过微信、飞书、Telegram等常用的聊天应用，随时随地将需求“丢”给智能体处理。年初各种“龙虾”项目的爆火，很大程度上就得益于这种便捷性。

另一种思路，则是将桌面端的智能体工作流延伸到手机，让用户可以在户外继续监控任务、发送指令、做出确认。这也是Claude Code和现在Codex所采取的做法。

然而，即便目标都是实现在手机上“使用智能体”，两者的体验重心差异显著。在使用OpenClaw或Hermes时，用户无需理解一个复杂的新客户端，也无需切换到专门的开发工具，只需像给朋友发消息一样，将需求发送给微信、飞书或Telegram中的机器人。

对于处理通用任务而言，这种体验甚至比打开一个专门的应用更为顺畅。尤其是对于那些强调长期记忆、自动化和多工具调用的智能体来说，即时通讯入口天然适合处理“提醒我”、“帮我查询”、“继续跟进”、“执行某个流程”这类跨越时间和场景的任务。

不过，以IM作为入口也存在其局限性。对话界面可以承载任务需求，却难以清晰呈现复杂的过程状态。智能体正在调用什么工具、执行到哪一步、修改了哪些文件、测试是否通过、某个决策是否合理——这些信息如果全部通过聊天气泡呈现，很快就会变得杂乱拥挤。

对于通用智能体，这可能不是致命问题；但对于AI编程这类场景，过程本身就是产品体验不可或缺的一部分。用户不仅需要知道“完成了”，更希望了解它是“如何完成的”、在哪里失败、下一步是否应该继续。

相比之下，Claude Code和Codex的移动化路径则有所不同。它们没有选择IM机器人模式，而是从Claude或ChatGPT的手机端应用本身出发进行延伸。与Hermes、OpenClaw的纯聊天入口相比，这种以应用为载体的方式，显然更适合呈现和处理复杂的任务状态信息。

但两者之间也有区别。Claude Code的双端连接更多是通过其Dispatch功能页面实现的，它更像是在借鉴OpenClaw或Hermes的IM思路后打造的一个特定功能模块。而Codex移动版则是直接同步桌面版的完整对话，包括桌面端实际运行时的思考过程、操作步骤和结果的实时同步。

简而言之，Codex在桌面与移动场景之间的切换显得更加无缝和自然。可能也正是因为对这种无缝体验的追求，目前时不时出现的重连问题才显得格外令人烦恼。

写在最后

平心而论，Codex移动版目前还谈不上成熟。真正复杂的代码审查、架构决策和高风险变更，仍然需要开发者回到电脑前，在更大的屏幕和更专注的环境下完成。对于普通用户而言，这个入口短期内也不太可能像ChatGPT日常聊天那样高频使用。

但其发展方向已经相当清晰：OpenAI更多地是将手机定位为智能体的调度入口和状态监视器。这个判断至关重要。因为当这些AI编程智能体的核心能力已毋庸置疑时，接下来的竞争焦点，就在于如何让这种强大能力变得更易于获取、更自然地融入工作流。至此，产品的交互与体验设计，成为了新的关键战场。