部署OpenClaw必看安全事项！OpenClaw 与桌面 Agent 沙箱选型报告

sin_陈
0 阅读27分钟

@[TOC](OpenClaw 与桌面 Agent 的真正分水岭：不是“会不会做事”，而是“在什么边界内做事”)

本文基于文章 《OpenClaw彻底带火了沙箱，桌面Agent落地必看》 的议题重新组织，回到一手文档、官方安全模型与工程部署边界，回答一个更核心的问题：当 Agent 获得浏览器、终端、文件系统、消息渠道与账户权限后，我们到底该如何定义它的可信边界？ 原文值得肯定之处，在于它把“沙箱”从一个配角重新拉回到了桌面 Agent 的主舞台，在此基础我补充点，对 身份、执行、持久化、供应链与多租户边界 的理解。

一、写在前面：为什么 OpenClaw 值得讨论，但不值得被神化

OpenClaw 之所以引发广泛讨论，不是因为它只是“又一个 AI 助手”，而是因为它把一个过去常被云端产品掩盖的问题暴露出来：当 AI 不再只是回答，而开始真正执行，它就不再是纯推理系统，而是一个带身份、带状态、带外部依赖的自治执行体。

OpenClaw 官方将其定义为 “运行在你自己设备上的个人 AI 助手”，可接入 WhatsApp、Telegram、Slack、Discord、iMessage(一些聊天与工作软件) 等多种渠道，并通过 Gateway、Control UI、browser、cron、canvas、skills（AI智能体配套工具，供ai调用外部工具，如：绘图、excel表） 等机制形成完整运行时。其官方仓库目前处于高活跃状态，官方文档 也持续围绕安全与沙箱做专门建设。

但也正因为它是一个黑箱，而不是一个单纯聊天界面，OpenClaw 天然引入了更复杂的风险面。 微软安全团队的文章 对这一类自托管 agent runtime 的判断非常到位：它们会执行代码、持有耐久凭据，并持续处理不可信输入；这意味着原本分散的两类风险—— “不可信代码供应链”和“不可信内容指令链”——会在同一个执行循环中叠加，最终把风险直接带到运行它的那台设备和它可使用的身份上。这个结论并不只适用于 OpenClaw，但 OpenClaw 正好把这个问题显性化了。

2026 年 2 月，安全研究人员披露了 OpenClaw 的高危问题“ClawJacked”。攻击不需要用户先安装恶意插件，也不要求机器先被植入木马；只要用户访问恶意网页，网页中的 JavaScript 就可能对本地 localhost 上的 OpenClaw WebSocket 入口发起连接并暴力猜测口令，一旦通过认证，就能把自己伪装成“受信设备”，进而与本地 Agent 交互、读取日志、枚举已连接设备、导出配置与相关数据，泄露银行卡与账号在内得大量个人数据并直接导致财产损失。公开报道指出，OpenClaw 很快修复了该问题，受影响版本为 2026.2.25 及以下，修复版本为 2026.2.26 及以上。这个案例之所以重要，不是因为它“只是一个本地服务漏洞”，而是因为它精准揭示了桌面 Agent 的新风险模型： ==本地运行 ≠ 天然安全== ——很多人会把“数据不出本机”错误等同于“风险更低”，但 ClawJacked 证明，只要本地 Agent 暴露了可被浏览器脚本接触的控制面，而认证机制又不够硬，那么“访问一个恶意网站”就可能变成“把本地高权限执行体交给别人”、==Agent 的威胁面不是单点，而是组合面==——一旦本地 Agent 被接管，攻击者不是只拿到“一次性命令执行”，而是可能沿着 Agent 已有能力继续扩张：读日志、看配置、枚举设备、触发自动化流程，甚至在某些配置下进一步接近文件系统、消息通道和浏览器控制面。也就是说，被拿下的不是“一个端口”，而是整个控制平面入口。这一点与桌面 Agent 的体系结构高度相关。 ClawJacked 证明了：桌面 Agent 最大的误区不是“模型会不会做错事”，而是“我们是否错误地把一个高权限本地控制面，当成了普通桌面软件”。

因此，理解 OpenClaw 的正确姿势，不是讨论它“是不是最强 Agent”，得先回答两个更关键的问题： 1. 它默认假设的安全边界是什么？ 2. 在什么场景下，它必须外接更强的执行隔离层？

二、桌面 Agent 的本质变化：从“模型能力问题”转向“系统边界问题”

过去人们评估 Agent，常常关注任务规划、工具调用、长链推理与多 Agent 协作。但桌面 Agent 的真正难点，并不只在“怎么想”，而在“怎么做”。一旦 Agent 可以读文件、起进程、操作浏览器、执行命令、安装依赖、访问网页登录态，问题就从 智能程度 变成了 执行治理。LangChain 在 Deep Agents 的官方文档中讲得很直接：由于 Agent 会生成代码、操作文件系统并运行 shell 命令，而我们无法预先知道它会做什么，因此它的执行环境 ==必须==与宿主机隔离，避免接触到凭据、文件和网络。

这意味着，桌面 Agent 的核心技术栈至少要拆成三层 参考LangChain文档：

1. 推理层

负责规划、拆解任务、调用工具与生成操作意图。这一层更接近传统 LLM Agent 讨论的核心。

2. 控制层

负责会话、渠道、设备配对、权限策略、工具暴露、审计与状态管理。OpenClaw 的 Gateway、本地 Control UI、channel pairing、tool policy，本质上都属于这一层。

3. 执行层

负责真正与文件系统、浏览器、终端、网络、图形界面和外部服务交互。沙箱真正作用的地方，不是推理层，而是执行层。 OpenClaw 的 Docker sandbox、Anthropic 的 OS 原生 sandbox-runtime、E2B 的 microVM、OpenSandbox 与 Kubernetes Agent Sandbox，都是在这一层给出不同的技术答案。

三、OpenClaw 的官方安全模型：它是“个人助理边界”，不是“敌对多租户边界”

这是讨论 OpenClaw 时最容易被忽略、却也是最关键的事实。（非技术岗的企业与团队用户注意！原生openclaw仅仅为个人设计，实现团队增效需要更复杂的增量设计才能保证安全！）

OpenClaw 官方安全文档明确警告：其安全指导建立在 “one trusted operator boundary per gateway” 的前提上，也就是 单用户 / 单信任边界 / 个人助理模型。官方原文进一步指出，OpenClaw 不是为“多个对抗性用户共享一个 agent/gateway”的 hostile multi-tenant security boundary 而设计；如果存在混合信任或对抗性用户，应拆分为不同 gateway、不同凭据，理想情况下是不同 OS 用户甚至不同主机！

这句话的技术含义非常重。它意味着：

  • OpenClaw 的强项是 单一可信操作者场景下的运行时整合；
  • 它可以提供很多安全收敛机制，但它并没有宣称自己是一个可以承载敌对多租户的执行平台；
  • 如果企业把一个共享 OpenClaw Gateway 当成多人共用、相互隔离的统一执行底座，那实际上已经越过了官方支持的安全模型。==也就是容易出事==

所以，OpenClaw 更准确的位置，不是“企业通用安全沙箱平台”，而是：

个人或单信任边界场景中的 Agent 控制平面与运行时入口。

四、OpenClaw 自身已经提供了哪些“安全收缩机制”

把 OpenClaw简单描述成“本地 Agent，权限很大，所以很危险”，其实是不完整的。它官方已经提供了一整套安全收缩面，虽然这些机制的目标是 “缩小爆炸半径”，而不是“绝对隔离”，仍有风险。

4.1 Docker 工具沙箱：减少 blast radius，而非构建完美边界

OpenClaw 官方的 Sandboxing 文档明确写到：启用 agents.defaults.sandbox 或 agents.list[].sandbox 后，工具可以在 Docker 容器中运行；若关闭沙箱，工具则直接在宿主机执行。同时强调：Gateway 仍在 host 上，只有工具执行被迁入隔离环境；这不是完美安全边界，但能实质性限制文件系统与进程访问范围。

OpenClaw 沙箱还提供三个重要控制维度：

  • mode：决定关闭、仅沙箱非主会话，还是全量沙箱；
  • scope：决定按 session、agent 或 shared 粒度隔离；
  • workspaceAccess：决定是否挂载工作区，以及是 none、ro 还是 rw。

这套设计非常像一个工程化的 risk contraction layer： 不承诺“模型绝不犯错”，直接默认“模型可能犯错，因此先把它放进更小的权限容器里”。

4.2 Tool Policy：安全的关键不只是“在哪里运行”，还包括“能调用什么”

很多人对沙箱的第一反应是：“把命令放进 Docker 里跑，不就安全了吗？”
这个理解只对了一半。因为安全问题从来不只是“进程跑在哪里”，还包括 “它到底能调用哪些工具、接触哪些资源、触发哪些副作用”。

OpenClaw 官方专门把这个问题拆成了三个维度：

  • Sandbox：决定工具在 host 还是在容器中运行；
  • Tool Policy：决定哪些工具可以被模型调用；
  • Elevated：决定是否允许某些执行绕过沙箱，直接回到 host。
    这三者的关系，官方在 Sandbox vs Tool Policy vs Elevated 文档中说得非常清楚。(OpenClaw 官方文档)

这背后有一个很重要的工程结论：

沙箱解决的是“运行位置问题”，Tool Policy 解决的是“能力暴露问题”，Elevated 决定的是“边界能否被打穿”。

如果只开沙箱，不收工具权限，实际风险仍然很高。举个非常具体的例子：

  • 你把 exec 放进容器里了；
  • 但仍然允许模型调用 browser、cron、gateway 或其他高权限工具；
  • 同时又给了宽泛的工作区挂载与网络访问；
  • 甚至还开启了 elevated。

那最终结果并不是“安全的 Agent”，而是“被容器包装过的高权限自动化系统”。

从企业安全治理的角度看，Tool Policy 本质上就是 Agent 时代的最小权限控制表。
你应该像管理一个服务账号那样管理 Agent 的工具面：

  • 哪些工具默认禁用；
  • 哪些工具只在某一类任务中临时启用；
  • 哪些工具必须通过审批或人工确认；
  • 哪些工具绝不能暴露给读取不可信内容的 agent。
    这比“模型够不够聪明”更决定系统是否可上线。

4.3 浏览器隔离：OpenClaw 做对的一点，也是最容易被误解的一点

桌面 Agent 的讨论里，浏览器自动化往往最容易激发想象力，因为这是“AI 真正在替你做事”的最直观界面：打开网页、点击按钮、填写表单、读取内容、导出结果。
但恰恰是这一点，把风险也带到了最前面。

OpenClaw 的浏览器支持并不是单一模式，而是两套不同的路径：

  • OpenClaw-managed browser：由 OpenClaw 管理的专用浏览器实例，使用隔离的 user data dir；
  • Chrome profile / relay：通过浏览器扩展或 relay 机制连接你已有的浏览器 tab。
    官方文档对这两种模式的边界说明得非常直接。(OpenClaw Browser 文档)

很多人看到 “能操作浏览器”，下意识会把它理解成 “已经安全隔离了”，万事大吉！but 其实这两件事完全不是一回事

为什么这是个核心风险点？ 因为浏览器不是普通工具，它往往天然绑定着：

  • 登录态；
  • Cookie；
  • 单点登录状态；
  • 本地保存的账号信息；
  • 正在打开的企业系统标签页；
  • 与个人/企业身份深度耦合的页面上下文。

如果 Agent 操作的是 OpenClaw 管理的独立浏览器实例，风险相对可控；
如果 Agent 接管的是你正在日常使用的浏览器 profile，那么它接触的就不只是网页 DOM，而是 整个活跃身份环境。

所以这里必须反复强调一句：

浏览器可自动化，不等于浏览器已隔离。

对于个人用户，这意味着不要把 Agent 直接接到你的主力浏览器。
对于企业用户，这意味着 浏览器 lane 应被视为独立安全域，最好做到：

  • 独立 profile；
  • 独立凭据；
  • 独立设备信任；
  • 独立日志与审计；
  • 独立失效与回收机制。

一旦这条浏览器 lane 与主办公环境混用，桌面 Agent 的风险模型就会从“自动化代理”升级成“高权限会话接管器”。

4.4 审计与配置自检：安全不在于“写了多少策略”，而在于“能否持续发现误配”

OpenClaw 在这一点上比很多同类项目更成熟的地方，是它没有把安全停留在“文档建议”层面，而是提供了显式的审计与检查工具。官方文档给出了：

  • openclaw security audit
  • openclaw security audit --deep
  • openclaw security audit --fix
  • openclaw secrets audit --check

用于检查常见的安全误配置、secret 使用方式和潜在暴露面。(OpenClaw Security 文档)

这个设计看似只是“多了几个 CLI 命令”，实际上反映了一个很成熟的工程认知：

Agent 系统最大的敌人通常不是“完全没做安全”，而是“做了很多安全配置，但随着版本、插件、工具和使用习惯变化，配置慢慢漂移失效”。

这在企业场景里尤其重要。因为企业环境里的风险往往不是一次性大爆炸，而是：

  • 某个工具默认策略被改宽；
  • 某个 secret 被错误共享；
  • 某个 agent 被临时加了 elevated 后忘记撤回；
  • 某个浏览器 lane 被误接到了正式账号；
  • 某个 skill 升级后扩大了权限。

如果系统没有持续自检能力，这些问题几乎一定会在“长期运行 + 多人协作 + 多版本演化”中出现。

五、为什么“沙箱”不是万能药：真正的风险来自执行循环，而不是单个组件

把 Agent 放进沙箱，并不意味着风险消失。
原因很简单：风险不是静态的，也不是单点的，而是会沿着推理、内容、工具、状态和身份在执行循环中传播。

这也是为什么很多讨论桌面 Agent 的文章，只讲容器、虚拟机、浏览器隔离，却忽略了更本质的问题：
攻击者并不一定需要直接攻破沙箱本身，他只需要让 Agent 在你允许的边界内，做出对攻击者有利的动作。

5.1 Prompt Injection 不是“模型弱智”，而是自治系统的结构性弱点

Prompt Injection 常被误解为“大模型还不够聪明，所以会被骗”。
这个说法太浅了。真正的问题不是模型“智商不够”，而是 Agent 系统天然有一个结构性困难：

  • 它必须读取外部内容；
  • 它必须把内容转化为操作；
  • 它必须在不完全确定内容可信性的情况下继续工作。

也就是说，只要一个系统允许“从外部内容中抽取操作意图”，它就天然存在被诱导的可能。

LangChain 官方在 Deep Agents 的沙箱文档中明确提醒，即便在沙箱中运行，Agent 依旧可能受到 prompt injection 影响，因此仍然需要 human-in-the-loop approval、短期凭据、可信 setup scripts 等外部约束。(LangChain Sandboxes 文档)

OpenClaw 官方安全文档也强调，威胁输入并不只来自直接聊天者，网页、邮件、附件、日志、抓取结果等都可能成为 间接注入载体。(OpenClaw Security 文档)

所以，Prompt Injection 的本质不是“模型不够聪明”，而是：

当一个系统既要理解内容，又要执行动作时，内容本身就会变成潜在控制面。

这和传统软件安全中的“数据与代码边界被混淆”有高度相似性，只不过在 Agent 时代，这个边界混淆发生在自然语言、网页内容和工具调用之间。

5.2 Skills / Plugins：第二条供应链，不要把它当“提示词模版”

OpenClaw 的技能体系与 ClawHub，让扩展能力变得非常自然。
这对可用性来说是好事，但对安全来说也带来了典型的供应链风险。

官方文档已经把技能安装、版本管理、更新、同步等流程产品化；与此同时，官方威胁模型也明确把恶意 skills、被劫持的更新、供应链投毒列为高风险问题。(OpenClaw ClawHub 文档)

这个问题需要非常明确地讲透：

Skill 不是一个“漂亮的 prompt 包装”，而是一个会影响 Agent 能力边界、工具面和行为模式的扩展组件。

这意味着，在安全上它更接近于：

  • 安装一个插件；
  • 引入一个第三方依赖；
  • 为 Agent 增加了一组新的权限或新的执行路径。

因此，无论是个人还是企业，都不应把 skill 安装当成“无害装饰”。
真正成熟的做法是：

  • 审查来源；
  • 审查更新记录；
  • 审查实际暴露的工具与权限；
  • 区分实验性 skill 与生产可用 skill；
  • 保持安装列表最小化。

这与传统供应链安全思路本质一致，只不过对象从 npm/pip 包扩展到了 Agent 时代的“行为扩展件”。

5.3 真正危险的是“身份—执行—持久化”形成闭环

如果只看一次操作，很多行为似乎都不算致命：

  • 读一个网页；
  • 记住一段信息；
  • 安装一个 skill；
  • 执行一条命令；
  • 定一个 cron；
  • 持久化一个 workspace 文件。

但这些动作一旦放进同一个持续运行的自治系统里，就会形成典型的 风险放大闭环：

  1. Agent 读取到恶意内容；
  2. 被诱导触发某个工具或安装某个能力；
  3. 修改 workspace、配置或持久状态；
  4. 后续任务继续继承这些变化；
  5. 风险从单次 run 扩散为长期存在的行为偏移或后门能力。

这正是微软安全团队对自托管 agent runtime 的分析重点：
身份、执行与持久化，不应被当作三个孤立问题，而应被视为 一个统一的 runtime 风险面。(Microsoft Security 文章)

换句话说，桌面 Agent 的安全问题不是“某条命令危不危险”，而是：

一个带身份、带工具、带记忆、能长期运行的系统，是否会在可被攻击者影响的输入下，自行把风险延续下去。

这才是为什么“沙箱很重要，但沙箱不够”。

六、两个典型安全事故：个人与企业各自真正该警惕什么

为了避免前面的讨论停留在抽象层面，这里用两个影响较大的安全事件来说明：
个人用户与企业用户面临的风险虽然表现不同，但本质都和“高权限控制面 + 弱边界治理”有关。

6.1 个人侧案例：OpenClaw “ClawJacked” 本地接管漏洞

之前的案例，2026 年 2 月，安全研究人员披露了 OpenClaw 的高危问题“ClawJacked”。根据公开报道，攻击者可借助恶意网页，通过浏览器脚本访问本地 localhost 上的 OpenClaw WebSocket 入口并尝试认证；一旦成功，攻击者可将自己伪装成受信设备，与本地 Agent 交互、读取日志、枚举已连接设备、导出配置与相关数据。报道指出，受影响版本为 2026.2.25 及以下，修复版本为 2026.2.26 及以上。(TechRadar 报道)

这个案例值得被反复提，因为它精准打破了一个常见幻觉：

本地运行 ≠ 天然安全。

很多人会把“数据留在自己电脑里”错误等同于“风险更低”，但 ClawJacked 说明：
只要本地 Agent 暴露了控制面，而认证与隔离又不够强，那么“访问一个恶意网站”就可能升级为“把本地高权限自动化系统交给别人”。

这个案例对个人用户的启示非常直接：

  • 不要把 Agent 当成普通桌面 App；
  • 它本质上是一个高权限本地控制面；
  • 应使用强随机令牌而不是弱口令；
  • 应第一时间更新版本；
  • 应避免把 Agent 与主力浏览器、主力身份环境混用；
  • 更不要把所有高价值数据和高价值账号都暴露给同一个本地自治系统。

如果要用一句话概括这个事件，可以这样写：

ClawJacked 证明了：个人侧桌面 Agent 最大的误区，不是“模型会不会做错”，而是“我们是否错误地把一个高权限本地控制面，当成了普通桌面软件”。

6.2 企业侧案例：MGM Resorts 2023 网络攻击事件

企业侧最有代表性的案例之一，是 MGM Resorts 在 2023 年遭遇的重大网络攻击事件。
MGM 在提交给美国 SEC 的 8-K 文件中披露，仅 2023 年 9 月，该事件就对其 Las Vegas Strip Resorts 和 Regional Operations 带来了约 1 亿美元的 Adjusted Property EBITDAR 负面影响。这已经不是“某个系统故障”，而是实质影响经营和业务连续性的安全事故。(MGM 提交给 SEC 的 8-K 文件)

从公开威胁情报看，Scattered Spider 一类攻击者非常擅长通过社工攻击 IT 帮助台、重置密码与 MFA、模拟员工身份等方式突破企业身份平面。CISA 与 Microsoft 的分析都强调了这一类攻击者对帮助台流程、身份认证链路和可信设备关系的利用。(CISA 关于 Scattered Spider 的通报)

这个案例对企业理解 Agent 平台安全非常关键，因为它说明企业最危险的情况，往往不是攻击者先拿下你的沙箱，而是先拿下：

  • 帮助台流程；
  • MFA 重置；
  • 账号恢复链路；
  • 受信设备；
  • 管理员会话；
  • 内部审批与协作链路。

一旦这些控制面被攻破，后面的执行层很容易被逐层绕过。
这对企业 Agent 平台有非常明确的映射意义：

如果 Agent 平台接入了企业身份、浏览器、邮件、客服、工单、内部系统，而身份链路又不够强，那么所谓“智能自动化”很快就会变成“高权限风险放大器”。

因此，企业讨论 Agent 安全，不能只谈沙箱，更要谈：

  • 身份分层；
  • 短期凭据；
  • 审批与授权；
  • 工具 allowlist；
  • 网络出口控制；
  • 持久状态可审计；
  • 运行环境可回收、可重建。

一句话概括就是：

MGM 事件说明：真正让企业付出巨大代价的，往往不是单个漏洞，而是身份平面被突破后，对执行面和业务面的级联放大。

七、几类主流沙箱路线，到底分别解决了什么问题

与其简单比较“谁更强”，不如直接看它们试图解决的核心矛盾是什么。
不同方案的价值，并不只来自“隔离强度”，还来自它们分别在 时延、复杂度、执行对象、运维模型与治理目标 上做出的取舍。

7.1 OpenClaw 内建 Docker 沙箱：适合个人或单信任边界场景的风险收缩

在这里插入图片描述

OpenClaw 内建沙箱最大的优势，是它与控制层天然一体化：

  • 会话管理在一起；
  • tool policy 在一起；
  • browser 与 workspace 语义在一起；
  • 审计命令也在一起。
    这对个人用户、独立开发者、小团队 PoC 非常友好。(OpenClaw Sandboxing 文档)

但它的边界也非常明确：
它不是 hostile multi-tenant boundary，也不是绝对意义上的强隔离执行平台。
所以它更适合：

  • 个人助理；
  • 单用户 Agent；
  • 研究和开发环境；
  • 小规模内部实验。

而不应被直接理解为“企业共享执行底座”。

7.2 Anthropic sandbox-runtime：低时延、本机优先的 OS 原生约束层

在这里插入图片描述

Anthropic 的 sandbox-runtime 走的是与 Docker / microVM 不同的路线。
它依赖的是操作系统原生隔离机制：

这类方案的优点是：

  • 本机时延低；
  • 接入轻量；
  • 非常适合本地 coding agent、MCP server 与 shell 安全收敛。

它的不足则在于，它并不天然等于一个完整远程执行平台，更像一个 execution hardening layer。
所以更适合作为本机执行层补强，而不是企业统一沙箱服务。

7.3 E2B / Firecracker 路线：为不可信执行提供更强的硬边界

Firecracker

E2B 一类方案的核心价值，在于它把执行平面放进了 microVM，而不只是普通容器。
Firecracker 官方给出的数据说明了这一路线为何在 Agent 与云执行领域受到青睐：它能以较低资源开销快速启动 microVM，同时提供更接近虚拟机级别的隔离边界。(Firecracker 官方主页)

这类路线更适合：

  • 不可信代码执行；
  • 需要完整浏览器/终端/文件系统环境的 Agent；
  • 对外服务；
  • 较高风险级别的生产系统。

它的典型代价是：

  • 成本更高；
  • 运维更复杂；
  • 与平台基础设施耦合更深。

所以这不是“更复杂的 Docker”，而是完全不同的执行平面设计思路。

7.4 OpenSandbox：企业统一执行 API 的候选底座

OpenSandbox

OpenSandbox 的官方定位是“面向 AI 应用的通用沙箱平台”，支持 Docker/Kubernetes runtime、多语言 SDK 和统一沙箱 API。(OpenSandbox GitHub)

它最重要的价值，并不在于“桌面使用体验”，而在于它帮助企业把执行平面抽象成一个可复用的服务层：

  • 统一接入；
  • 统一审计；
  • 统一运行时调度；
  • 统一资源池管理；
  • 可被多个 Agent 框架复用。

这类方案非常适合企业内部形成“控制层与执行层分离”的架构。

7.5 Kubernetes Agent Sandbox：把执行面标准化、平台化

在这里插入图片描述

Kubernetes Agent Sandbox 面向的是更大规模、更强治理诉求的场景。
其官方定位就是：在 Kubernetes 上为 autonomous AI agents 提供安全、隔离的执行层，用于运行会生成并执行不可信代码的 Agent。(Kubernetes Agent Sandbox 官方站点)

这种路线的价值是：

  • 执行环境生命周期交给集群；
  • 可插拔隔离后端；
  • 更适合多租户治理；
  • 更适合审计、网络、存储和资源策略统一。

代价同样明显：
需要更成熟的 K8s、网络、存储和安全运营能力。
所以它更偏“平台工程”，而非“快速落地的个人工具”。

7.6 LangChain Deep Agents：不要把它误读成“沙箱产品”

LangChain

LangChain Deep Agents 常被和各种沙箱方案放到一起讨论，但这个理解不够准确。
Deep Agents 官方本质上是一个 Agent Harness：提供 planning、subagents、memory、filesystem 等能力；沙箱则是它的 backend 之一。官方还专门区分了：

这个 distinction 非常关键，因为它提醒我们：

Agent 运行时与执行隔离层，应该是可解耦的。

从架构上说，LangChain 更适合被看作上层控制/编排框架，而不是与 E2B、OpenSandbox、OpenClaw Docker sandbox 同层比较的“隔离产品”。

八、个人用户怎么选：核心不是“最强”，而是“能否把风险控制在自己能承受的边界内”

对个人用户来说，技术上最常犯的错误，是盲目追求“功能最多”“最像真人”“能控制最多软件”。
但真正成熟的选择标准不是这些，而是：

  • 你是否清楚它会接触什么身份；
  • 你是否能接受这台机器被它长期影响；
  • 你是否有能力审计它的权限与状态；
  • 你是否愿意为它建立独立浏览器、独立凭据、独立工作区。

如果答案是否定的，那么即便工具再强，也不应该直接放进主力环境里。

对个人用户的现实建议

  • 轻量自动化 / 个人助理：OpenClaw 内建沙箱就已经很有价值；
  • 本机 coding agent / shell agent：可叠加 Anthropic srt 这类 OS 原生约束层；
  • 高风险网页/文件处理：优先放进独立 VM 或专用设备；
  • 大量 skills / 多通道接入 / 浏览器登录态操作：默认按“高风险本地服务”而非“普通软件”防护。

一句话：

个人用户最该追求的不是“AI 能不能帮我做更多”，而是“AI 做错或被利用时，我会损失到什么程度”。

九、企业怎么选：OpenClaw 更适合做控制平面候选，而不是最终执行边界

企业看待这类系统，不能只从“好不好用”出发，而必须从 架构分层 出发。

一个更合理的企业架构往往是：

  • OpenClaw / Agent Runtime 负责控制层
    包括渠道接入、会话管理、工作流编排、人机交互、任务路由；
  • 外部沙箱平台负责执行层
    包括代码执行、浏览器任务、GUI 操作、文件系统与网络隔离；
  • 独立身份与安全治理系统负责授权层
    包括短期凭据、审批、日志、出口控制、配置与 secret 管理。

这套分层背后的核心逻辑只有一句话：

控制平面与执行平面，不应由同一高权限运行时无限制地同时承担。

对企业而言，真正的风险不在于“某个 Agent 是否足够聪明”，而在于：

  • 它是否接入了企业真实身份；
  • 它是否能触发真实业务动作；
  • 它是否会在持久状态中积累风险；
  • 它是否能被快速隔离、回收和重建。

所以企业真正该问的不是“OpenClaw 能不能做平台”，而是：

OpenClaw 应该放在平台的哪一层。

从目前官方安全模型与产品定位看，它更适合：

  • 作为控制平面候选；
  • 作为实验层与入口层；
  • 作为个人或单信任边界下的运行时；
  • 作为企业 Agent 控制层的参考实现。

而不是默认承担所有多租户执行隔离责任。

十、最后的判断：桌面 Agent 的竞争，最终会变成“边界工程”的竞争

很多讨论还停留在“哪个 Agent 更像人”“哪个更会点网页”“哪个更能自动化”。
这些当然重要，但它们决定不了系统能否真正进入长期生产使用。

真正决定成败的，是下面三个问题是否被严肃回答：

10.1 谁可以与 Agent 交互？

这对应：

  • 配对；
  • 设备信任；
  • 渠道权限；
  • 会话范围；
  • 远程访问控制。
    如果第一步没守住，后面一切都是空谈。

10.2 Agent 可以碰什么？

这对应：

  • tool policy；
  • sandbox；
  • workspace access；
  • browser profile；
  • network egress；
  • skill/plugin 权限。
    这决定了错误时的损失范围。（你直接默认它必然会出错就行，不可避免的）

10.3 哪些变化会被持久化？

这对应：

  • memory；
  • workspace；
  • cron；
  • session state；
  • skills 状态；
  • secrets 和配置。
    这决定了风险是“一次性失误”，还是“长期潜伏与持续继承”。

所以，Agent关键不是“让 AI 像人一样操作电脑”，而是：

构建一个带身份、带执行、带持久化的自治系统，并把它限制在清晰、可审计、可收缩、可重建的边界内。

参考资料

原文引用

OpenClaw 官方资料

安全与沙箱相关资料

典型案例

avatar
文章
阅读
粉丝