Baidu's Isolation Method for "Shrimp Farming" Explained

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

此前 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 尚未完全成熟时，兼顾商业普及与风险控制的一种折中路径。它解决了最迫切的不确定性，但也引入了新的权衡。

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