百度“养虾”的隔离法拆解

随着养虾热潮从极客圈蔓延至大众，关于数据安全与系统控制权的问题正引发关注。

此前Meta的超级智能实验室AI对齐与安全总监Summer Yue在一次测试中，特意为OpenClaw设置了“确认后再行动”的安全指令。

然而，她却只能眼睁睁地看着OpenClaw以惊人的速度清空了她存放重要邮件的收件箱，完全无法及时切断进程来阻止。

这正是本地部署模式下OpenClaw的潜在风险。

面对“养虾”频发的安全隐患，行业亟需一套全新的安全范式，帮助普通用户能够“无痛养虾”。

百度正式杀入这一赛道，推出了全球首款手机龙虾应用“红手指Operator”。3月17日，“红手指Operator”的应用正式更名为Red Claw，用户只需下载注册，即可直接指挥这只“手机龙虾”代为执行各项繁琐任务。

全天候科技实测发现，Red Claw所使用的运行模型为qianfan、deepseek-v3.1-250821，可以调动手机中的APP用于订餐、订票等一系列任务。

据全天候科技了解，Red Claw在架构设计上引入了严格的“三层隔离体系”：

一是底层物理级隔离。应用全程在云端手机运行，与用户手中的移动端真机数据完全物理隔离。应用本身不获取、也不要求用户授权本地真实存储的数据；

二是运行环境隔离。每位用户分配独享的云端手机，设备之间之间实现绝对隔离；

三是任务数据隔离。多重数据加密，任务之间信息不交叉。

此外，在权限与可见性控制方面，Red Claw在产品设计上强调了“主动权归属”，即AI的每一步操作对用户完全可见、可追溯。当涉及隐私或需要授权的关键节点时，云机进程会被强制挂起，必须等待用户确认或人工介入后才能继续推进。

这在一定程度上为大众级用户提供了极具安全感的“无痛试错”环境。

但把“龙虾”搬进云端之后，问题并没有消失，只是换了一种形态存在。

最直观的变化是效率。

本地执行的逻辑是即时响应，而云端手机不可避免地引入网络往返、虚拟设备调度等额外链路。对于订餐、订票这类标准化任务影响尚可，但一旦进入多步骤、需要实时反馈的场景，延迟会被不断放大。原本一气呵成的操作，被拆成一段段等待确认的过程，流畅性开始变成一种成本。

可见性带来的也未必是控制力的提升。

“每一步都可见、可追溯”在设计上强化了安全感，但当任务被拆解为大量细碎操作时，用户面对的更像是一串不断滚动的执行日志。人在其中的角色，容易从决策者滑向被动确认者。

可见不等于理解；确认也不完全等于真正的掌控。

隔离也在重新划定能力边界。

云端手机能够调用的权限本质取决于平台的适配范围，而不再是用户设备本身的全部能力。

这意味着，在降低风险的同时，系统也从“接近全能的代理”收敛为“被定义好的自动化工具”。

而所谓物理隔离更像是一次信任的转移。

数据不再暴露在本地，但用户需要转而信任云端环境本身的安全性。

云端运行还会带来成本的考验。每个用户一台独立云手机、持续在线运行，对算力和资源的消耗程度并不轻。随着用户规模扩大，平台要么承担持续补贴的压力，要么通过限制与分层收费来对冲成本。这种结构决定了它更像是一种阶段性的解法，而非可以无限外推的终局形态。

还有一个更隐蔽的变化是风险感知的弱化。

在本地环境中，错误往往直接发生在用户设备上，反馈清晰且即时。而在云端隔离下，错误被“包裹”起来，影响被延后甚至被部分消解。这种“更安全”的体验，可能同时也在削弱用户对风险边界的敏感度。

长远来看，“云端隔离法”更像是当前AI尚未完全成熟时，兼顾商业普及与风险控制的一种折中路径。它解决了最迫切的不确定性，但也引入了新的权衡。

当未来端侧大模型的算力与安全护栏足够强大时，“云端龙虾”是否能真正安全地“游回”用户的本地真机，将是下一场智能体技术角逐的一大看点。