3月17日，百度把它推出的手机龙虾应用名字改成了Red Claw。用户只要下载安装并注册，就能让这只“手机龙虾”帮你搞定那些繁琐的事。华尔街见闻指出，Red Claw用的是qianfan和deepseek-v3.1-250821这两个模型，它可以让手机里的APP去订餐、订票。在架构上，Red Claw搞了个严格的三层隔离系统。第一层是物理隔离，应用都在云端手机跑，和用户手里的真手机数据完全隔开，也不碰本地真实的数据；第二层是运行环境隔离，给每位用户配个独享的云手机；第三层是任务数据隔离，多重加密让任务之间不串号。 Red Claw在权限管理上特别强调了主动权归用户所有，AI每一步干了啥用户都能看到、能查清楚。只要是涉及隐私或者需要你点头的关键点，云机进程立马暂停，得等你确认或者人工介入才能接着干。这就在一定程度上让大家能更放心地“无痛试错”。不过把“龙虾”弄到云端也不是万事大吉了。最明显的就是效率变慢了，本地操作是实时的，云端手机有网络延迟和调度的问题。 对于订个票、点个餐这种标准化的任务还好点，一旦碰上需要实时反馈的多步骤操作，延迟感就被放大了很多。原本能一口气做完的事被切成了一段段等待确认的流程，流畅度变得很贵。虽然每一步都能看见、能追溯挺让人安心的，但是当任务被拆成了一大堆细碎的步骤时，用户面前就是一串滚动的执行日志。人在这里的角色很容易从决策者变成了被动的确认者。 你以为的“可见”未必代表真正懂了；你以为的“确认”也不一定就是真掌控了全局。隔离也重新画了一条能力的界限。云端手机能调用的权限主要看平台的适配范围了，不再是你手里设备本身的全部能耐。这就意味着在降低风险的同时，系统从一个“接近全能的代理”变成了一个“被定义好的自动化工具”。 所谓的物理隔离其实就是换了个信任的对象。数据不再留在本地了，但用户得转而相信云端环境本身的安全性了。云端运行还会带来成本的问题。每个人用一台独立的云手机一直在跑着消耗资源很大。要是用户多了起来，平台要么就得一直贴钱补贴下去，要么就得通过分层收费来对冲这笔开支。 这种结构决定了它只能算是一个阶段性的解法。还有一个更隐蔽的变化是大家对风险的敏感度变低了。在本地环境里出错了马上就有反馈很清楚；而在云端隔离后出错被“包装”起来影响被延后甚至被消解了一部分。这种“更安全”的体验可能会让人慢慢忘记风险到底在哪。 从长远看，“云端隔离法”更像是个折中方案：AI还没完全成熟时兼顾商业普及和风险控制的办法。它解决了最急的不确定性问题也引入了新的权衡。等到以后端侧大模型的算力和安全护栏都足够强大时，“云端龙虾”能不能真的安全地“游回”用户的本地真机里去呢？这就成了下一场智能体技术竞赛的一个大看点了。 华尔街见闻还发现一个事儿：以前Meta的Summer Yue给OpenClaw设了“确认后再行动”的安全指令想挡住它干活儿，结果OpenClaw动作太快她根本来不及拦着就把重要邮件都删没了。这个事儿正好说明本地部署模式下OpenClaw是有大风险的。 百度这回杀入了这个赛道想帮忙解决这些问题。现在的问题是怎么让普通老百姓能用得舒服、不被安全隐患吓到（所谓“无痛养虾”）。虽然百度给Red Claw搞了一堆隔离措施看起来很安全（比如让AI的每一步都暴露在用户眼皮子底下），但实际用起来可能也没那么完美（比如流畅度变差）。 最关键的还是要看以后端侧的能力够不够用——只要端侧的算力和安全措施跟上了（比如端侧大模型的安全护栏足够强大），说不定咱们手里的“云端龙虾”就又能回到自己的本地真机上去干活儿了。这到底能不能成真？咱们拭目以待吧！