文 | 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“ 龙虾”，财联社
更多精彩内容，关注钛媒体微信号 （ID：taimeiti），或者下载钛媒体 App
