OpenClaw新应用不在手机上运行AI，这正是其设计核心

OpenClaw本周正式推出了iOS和Android应用，用户现在可以抛开Telegram和WhatsApp，直接与自己的个人AI智能体对话。但更值得关注的是，这款应用实际上并不在手机上运行AI，它只是连接到用户在其他地方已经运行的智能体。手机充当的是进入该智能体的一扇窗口，支持语音交互、消息通知和摄像头访问。

这是一个颇具亮点的设计思路，也代表了个人AI智能体的发展方向。

手机正在变成OpenClaw的智能遥控器

手机正逐渐演变成OpenClaw的智能遥控终端。开发者没有把功能越来越强大的智能体塞进受电池和内存制约的手机里，而是将手机定位为智能体的又一块显示屏——智能体本身运行在别处。无论手机拿在手中还是在另一个房间充电，智能体都会持续工作。

在这种模式下，手机负责审批操作、接收通知、与智能体对话，并在智能体需要"看"某些东西时调用摄像头。

这并非OpenClaw的首创

OpenClaw并非第一个采用这种架构的公司。Anthropic的Claude Cowork配合Dispatch遵循了极为相似的模式：用户通过手机分配任务，但实际执行发生在持久运行的桌面端。移动应用只是用于发起任务、监控进度和接收结果的辅助工具，而非智能体本身。

OpenAI也在朝着类似方向发展。以Codex为例，开发者越来越多地与长时间运行的编程智能体协作，这些智能体可以独立持续工作，用户可通过多个客户端随时查看进展，而不是把手机当作智能体的运行场所。

不同公司、不同产品，却做出了相同的架构选择：将智能体保持在持久运行环境中，为用户提供轻量级客户端进行交互。当多个团队独立汇聚到同一架构模式时，往往是行业找到了能解决真实工程问题的方案的早期信号。

开发重心正在转移

这一转变改变了开发者的关注焦点。过去开发移动应用，需要操心电池续航、内存限制、离线模式，以及如何榨干手机的每一分性能。如果智能体运行在别处，这些顾虑大多便会退到幕后。

取而代之的是一批新问题：手机如何安全地连接到长期运行的智能体？如何跨多设备管理权限？如果所有客户端都断线，但智能体仍在运行，该如何处理？

身份认证成为关键基础设施

这里还存在一个连锁效应。一旦手机只是与智能体通信的多个可信终端之一，就需要更为完善的身份管理方案。用户登录的不再是某个应用，而是将设备接入与持久智能体之间持续存在的关系中。

随着智能体获得读取文件、发送邮件、调用API、控制外部工具等能力，身份认证将成为承载整个系统的关键基础设施。

个人AI智能体越来越像分布式系统

从更宏观的视角来看，个人AI智能体越来越像分布式系统，而非移动应用。智能能力存在于持久运行环境中，手机只是多个经过认证的终端之一。

对开发者而言，移动应用只是工作的一部分，还需要构建维持智能体运行、将其连接到用户设备、并确保连接安全的各项组件。

综合观察OpenClaw、Anthropic和OpenAI的动向，很难不注意到同一个模式：智能体持续独立运行，手机只是用来签入、审批操作或发起对话的又一个入口。这种架构解决了诸多实际问题，这或许正是多家公司不约而同走向同一方向的原因所在。

Q&A

Q1：OpenClaw的新应用是怎么运行AI智能体的？

A：OpenClaw的移动应用本身不在手机上运行AI，而是通过网络连接到用户在其他地方已经持续运行的AI智能体。手机相当于一个轻量级终端，负责语音交互、消息通知、审批操作和摄像头共享，智能体的实际计算和执行都发生在远端环境中，即使手机离线，智能体也会继续工作。

Q2：除了OpenClaw，还有哪些公司采用了类似的智能体架构？

A：Anthropic的Claude配合Dispatch采用了类似模式，用户通过手机分配任务，但执行发生在持久运行的桌面端。OpenAI的Codex也走向了类似方向，开发者与长时间运行的编程智能体协作，可通过多个客户端查看进展。多家公司独立汇聚到同一架构，说明这种模式正在成为行业共识。

Q3：这种"智能体运行在远端、手机只是终端"的架构会带来哪些安全问题？

A：最核心的挑战在于身份认证。用户不再只是登录一个应用，而是将设备接入与持久智能体之间的持续关系中。随着智能体获得读取文件、发送邮件、调用API等能力，如何跨多设备管理权限、如何在客户端全部断线时保证智能体安全运行，都成为开发者必须面对的关键问题。