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

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

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

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

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

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

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

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

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

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

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

　　首先是账号安全隐患。云手机内的操作数据，包括账号密码、登录状态、支付信息，均存储在服务商的云端服务器中。若服务商安全防护能力不足，上述数据将面临批量泄露的风险。红手指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的封闭生态主动开门。这不是技术问题，而是商业博弈问题，结果高度不确定。

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

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

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

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

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

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

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

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

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