文 | AI 价值官，作者丨星野，编辑丨美圻

OpenClaw 浪潮席卷以来，AI 智能体的主战场始终在电脑端。手机端的探索并非没有，但进展迟缓——几家头部厂商打出的牌，仔细看都还差着一口气。

小米 3 月初启动 Miclaw 封闭测试，鸿蒙随后上线小艺 Claw，均号称 " 手机版龙虾 "，但从当前可验证的产品能力来看，其实际操控范围仅局限于系统功能与系统级应用——对用户高频使用的微信、抖音、美团等第三方主流 App，二者均缺乏系统级深度操作权限，跨应用全链路自动化仍无法实现。

腾讯推出了微信、QQ 直连 Claw 的服务，但两款超级 App 本质上只是远程监控和操控电脑端龙虾的窗口，智能体并未在手机本地原生运行。

就在这个当口，百度选择了 " 绕道而行 "，通过云端 " 捷径 " 率先抢跑。

全球首款手机龙虾应用，背后是一笔六年前的收购

3 月 12 日，百度智能云联合红手指正式在安卓端上线红手指 Operator，宣称这是全球首款手机龙虾应用——用户无需更换设备、无需本地部署，下载 App 即可 " 养虾 "，覆盖打车、点外卖、跨 App 交互等高频场景。

红手指 Operator 上线后火爆一时，系统后台一度出现资源紧缺提示。然而热度之下，实际体验与官方宣传存在明显落差。

有媒体针对出行、外卖、购物三大官方重点场景逐一测试，三个任务仅完成一项——且是最简单的 " 搜索 iPhone 17e 价格 "。打车、点奶茶两个执行类任务，均因账号验证失败中途中断，任务成功率仅三分之一。

整个操作过程中，用户需多次手动 " 接管手机 "，自行完成账号登录、权限授权与安全验证。有资深互联网从业者直言，从实际使用效果来看，该产品仍处于半成品阶段。

这一体验落差，藏在它的底层架构里。

红手指 Operator 并未在用户本地手机上直接运行 AI 智能体，而是将 OpenClaw 完整预置在云端虚拟手机中——所有操作均发生在远程云安卓设备内，用户的本地手机只是操控入口和画面接收终端。

这套方案的来源，正是百度 2020 年全资收购的云手机厂商红手指。当时百度布局云计算与移动生态，云手机作为兼具云端算力与移动场景的基础设施，被视为重要的战略延伸。

如今，百度将这一资产复用于 AI 智能体方向：将 AI 智能体的运行环境整体迁移至云端，成为其绕开本地应用权限限制的核心手段。

这套逻辑的确能跑通，但代价几何，还需要仔细拆解。

云手机 " 养龙虾 " 这条路并不好走

云手机并非为 AI 智能体而生。

这项技术最初聚焦于手游玩家的 7 × 24 小时挂机需求，此后延伸至企业批量账号管理、App 兼容性测试等 B 端场景。其本质是运行在云端服务器上的虚拟安卓设备，拥有独立的系统环境、IP 地址与存储空间。

将这套架构嫁接至 AI 智能体，绕开了本地权限的问题，却带来了另外两重风险。

首先是账号安全隐患。云手机内的操作数据，包括账号密码、登录状态、支付信息，均存储在服务商的云端服务器中。若服务商安全防护能力不足，上述数据将面临批量泄露的风险。红手指 Operator 将账号登录、支付等高敏操作强制设计为用户手动接管，是对这一风险边界的间接确认——换言之，它自己也不敢让 AI 全程代劳。

其次是应用封禁风险。云手机方案依赖模拟点击操控应用，与同样通过模拟人类操作来控制界面的 GUI 方案本质相近——两者面对的是同一道关卡：平台的反作弊与风控机制。这正是红手指 Operator 在外卖、打车场景中频繁遭遇账号验证失败的原因。

两重风险叠加，意味着云手机路线解决了权限问题，却在安全和封禁这两道新的关卡上撞了墙。它是一种绕行，而非突破。

事实上，百度并非第一个探索这条路的玩家。

2025 年 8 月，智谱在 AutoGLM 中正式推出智能体手机，宣称 " 全球首个手机通用 Agent"，主打 " 云端操作，不占屏幕空间 " ——为用户在云端数据中心配备一台虚拟手机和一台虚拟电脑，拥有完整的操作系统与应用生态，支持在多个 App 间协同操作。覆盖小红书、淘宝、美团等 40 余款高频应用，且完全免费，一度被戏称为 " 国产版 Manus"。

但实测结果浇了一盆冷水——速度是第一道坎，有用户吐槽 " 还不如自己点来得快 "；稳定性同样存疑，操作时常 " 迷糊 "；云端虚拟手机无法自行安装新 App，只能调用预装应用；微信等涉及隐私的敏感应用则直接不予支持。概念足够超前，体验却始终跟不上—— AutoGLM 上线至今在 App Store 仅积累了 86 个评分，长期鲜为人知。

这恰恰印证了云手机路线的结构性困境：绕开了本地权限的问题，却在稳定性、封禁风险和应用覆盖上同时碰壁。

在这一轮 OpenClaw 浪潮中，智谱也没有选择力推 AutoGLM，而是推出了主打本地一键部署的 AutoClaw，将重心回归电脑端。手机智能体这道题，智谱选择了暂时搁置。

3 月 13 日，阿里也宣布上线 " 手机版龙虾 "。但细看产品形态会发现，这不过是阿里旗下 JVS Claw 的手机客户端——作为首款可视化进程 IM，其功能仅为让用户通过手机跟踪电脑端 JVS Claw 的执行进程、远程下达指令，并未实现智能体在手机本地的原生运行。与腾讯微信、QQ 的方案性质相近，是一个远程操控界面，而非真正意义上的手机龙虾。

各方打出的牌，其实都没有真正落在 " 手机龙虾 " 这个命题上。

" 手机龙虾 " 的正途在哪里？

要判断手机龙虾的出路，需要先把三条现有路线的逻辑各自厘清。

第一条是系统级原生路线，以 Miclaw、小艺 Claw 为代表。核心逻辑是将 AI 智能体能力集成至操作系统，通过系统级 API 在官方框架内调用应用功能。合规、稳定、低延迟、不触发账号风控，是这条路线的天然优势。

但它有一个前提条件无法自行解决：第三方应用必须主动适配。小米的 AppTool SDK 和鸿蒙的 A2A 协议，本质上都是在等待超级 App 的封闭生态主动开门。这不是技术问题，而是商业博弈问题，结果高度不确定。

第二条是云手机绕行路线，即百度的选择。它的优势在于无需任何一方配合，可以快速跑通基本能力演示。但如前所述，它回避了权限问题，却换来了安全隐患和封禁风险，是一种以新问题置换旧问题的过渡方案。

第三条是直接接管路线。通过视觉模型实时解析屏幕内容，模拟人类操作直接接管界面交互，不依赖任何一方的生态配合，理论上可操控手机上的任意应用。这是三条路线中唯一不需要任何外部配合、也不需要绕道云端的方案——如果跑通，就是真正的 " 手机龙虾 "。

在 OpenClaw 走红之前，字节布局的正是这条路线。但这条路比预想中更难走。豆包手机助手触碰了主流 App 的数据安全与自动化防护红线，上线后遭遇应用层面的集体封锁。这场反弹，某种程度上勾勒出了手机龙虾的边界：从外部强行接管应用，注定会触碰平台的数据主权。

而 OpenClaw 的爆火，恰恰是走了一条反向的路——不做全场景通用执行入口，只做可灵活插拔的工具连接框架，正是这种克制，换来了国内外大厂的普遍接入。

但接入，并不等于开放。从飞书、企业微信到钉钉，各大平台拥抱 OpenClaw 的逻辑，是主动将龙虾圈入自己的数据边界之内，让用户在自家平台内通过龙虾完成任务，从而强化而非削弱自身的流量护城河。

这与手机龙虾的终极愿景——让 AI 智能体自由穿梭于所有应用之间、由用户而非平台掌控数据调度权——在方向上恰好相反。

换言之，超级 App 接纳龙虾，是一次主动的收编，而非开放。它们愿意让龙虾进门，前提是龙虾得在自己家里干活。一旦龙虾试图从外部操控它们的界面，封锁依然会如期而至。

所以，手机龙虾面临的核心矛盾并未因 OpenClaw 的爆火而消解：系统级路线等待超级 App 开门，云手机路线绕道而行却代价高昂，GUI 路线强行破门又遭集体围堵。三条路，各有各的墙。

真正的破局，或许不在于如何绕开超级 App，而在于超级 App 自己选择打开门。腾讯正在研发的微信智能体，是目前最值得观察的一个变量。

微信坐拥数百万小程序，本身就是一个覆盖出行、餐饮、购物、政务的完整生态闭环——一旦微信智能体打通小程序间的跨应用调度能力，用户无需离开微信便能完成绝大多数高频任务，手机龙虾的终极愿景或将在这个封闭生态内率先实现。只是这条路走到最后，掌舵的仍是平台，而非用户。

手机龙虾的故事，才刚刚开始。

参考资料：

[ 1 ] 实测百度龙虾 App" 红手指 "：58 元月费，买不来一杯奶茶，新浪科技

[ 2 ] AutoGLM 正式上线：当 AI 有了自己的手机，智谱

[ 3 ] 阿里上线手机版 OpenClaw" 龙虾 "，财联社