OpenClaw 起来的那一波，我身边很多团队都把它当"全能数字员工"来用：拆解任务、调用工具、读写文件、访问内部系统，一条链全包。DSH 又把技能扩展做成了插件市场，第三方能力一行命令装进 Agent。灵活是真灵活，但负责安全的人看到 skill 里出现裸 shell 命令时，冷汗是直接下来的：AI 的执行面完全暴露在生产环境里。这篇文章要聊的，就是我用 CubeSandbox 给 OpenClaw + DSH 这套组合补上一道企业安全执行面的落地实战，让 Agent 继续干活，但每一行命令都跑在受控、可审计、可回收的沙盒里。

先说清楚它能解决什么问题：OpenClaw 负责决策编排，DSH 负责插件分发，CubeSandbox 负责把真正跑命令的那一层隔离起来。你不需要放弃 Agent 的灵活度，也不需要给每个 skill 做人工代码审计，只要把"执行边界"明确画出来，第三方插件的风险就能压在一个可控范围内。适合正在企业里落地 Agent 平台的安全工程师、运维同学，以及被"插件到底能不能信"困扰的决策者。

1. 为什么执行面成了 AI 落地绕不开的坎

1.1 OpenClaw 和 DSH 在前，安全为什么总是后补

OpenClaw 这类编排运行时，本质上做的事是"把用户的自然语言目标翻译成一串可执行动作"。它可以是读取文件、调用 API，也可以是执行 shell 命令。DSH 则是技能与插件市场，它让 OpenClaw 能按需加载新能力，比如某个业务域专用的脚本、某个数据库的连接器、某个格式转换工具。

问题恰好出在这套组合的价值点上。插件加载是动态的，技能内容是由第三方维护的，OpenClaw 本身并不会在每次加载时对插件做完整的安全检查。大多数团队第一次接入时，OpenClaw 进程拥有的是"当前用户的所有权限"——它能读的文件、能连的网络、能写的目录，和你的账号一样大。这在个人开发机上没什么，放进企业环境就是事故隐患。

我见过不少团队的现状：OpenClaw 部署在一台开发机上，目录挂载了生产配置，环境变量里放着数据库连接串，DSH 插件的下载路径也没做校验。Agent 表面上是数字员工，实际上等同于一个拥有高级权限的"幽灵账号"，它执行命令时没有任何沙盒兜底。

这就是"执行面"这个词的含义：Agent 实际执行代码、命令、文件操作的那一层环境边界。执行面安全，就是对这个边界的定义、隔离、审计和回收。个人玩没问题，企业环境必须有边界。

1.2 三种典型的失控场景

第一个场景：skill 里的命令"越界"了。有个团队装了一个"日志分析"插件，插件内部调用了find / -name "*.conf"去搜索配置文件，本来是想找应用日志路径，结果把所有目录下的配置都扫了一遍，包括含密钥那份。Agent 不会意识到自己在干什么，它只是按脚本执行，脚本写得不严谨，它就把不该看的内容看了一遍。

第二个场景：第三方插件和内部系统发生"意外连接"。DSH 市场里的某个插件，作者为了收集兼容性信息，在初始化时向一个外部端点上报了运行环境数据。沙盒只要没有网络隔离，这些数据就会默默流出企业边界。你可能觉得"上报一下没什么"，但如果上报的是内网拓扑、主机名、开放端口呢？

第三个场景最隐蔽：Agent 的自主探索变成横向移动。OpenClaw 规划任务时遇到"不太确定"的情况，会主动探测可用工具、尝试访问相邻服务。在无边界环境下，这台 Agent 所在的主机就变成了内网跳板。它自己不会恶意横向移动，但被注入恶意 prompt 之后呢？能力越强，破坏面越大。之前有个测试案例，一个原本只做文档归纳的 Agent，因为读到了一段被污染的网页内容，开始尝试调用系统网络工具扫描网段——如果当时没有沙盒，这一步就直接打到了生产内网。

三个场景的共同结论：不是 OpenClaw 或 DSH 本身有恶意，而是它们只管"把事情做完"，没人对"事情做在哪个边界里"负责。

2. 整体设计：把执行面拆成三个可信层

2.1 编排、分发、执行各管各的

我落地这套方案时，把原来的"一个 Agent 全干"拆成了三个明确层次：

• 决策层（OpenClaw）：只负责理解意图、拆解任务、选择插件与参数，不直接执行系统级操作。
• 分发层（DSH）：只负责插件的目录、版本、依赖关系与分发签名，不负责运行插件代码。
• 执行层（CubeSandbox）：所有真实命令、脚本、文件变更，只在沙盒实例里发生。

这个拆法最重要的价值是"信任边界下移"。OpenClaw 进程即使被攻破，攻击者也只是拿到一个"决策器"，他没有直接执行环境；DSH 即使被塞进恶意插件，插件也必须经由 CubeSandbox 实例化才能运行。任何单一环节出问题，都不会直接演变成主机层面的完全失陷。

实际操作中，这个三层模型会被映射成一套物理部署：OpenClaw 跑在独立容器里，DSH 作为侧车服务管理插件清单，CubeSandbox 运行在宿主机上的独立 runtime 进程组里。三者的通信只走 API，不共享文件系统。

2.2 CubeSandbox 增强的核心能力

CubeSandbox 在这套体系里不是又一个容器，而是一个"可编程的隔离执行单元"。它提供的核心能力有六项，按重要性排序如下：

第一，进程隔离。每个执行单元拥有独立的进程命名空间、文件系统命名空间和网络命名空间。沙盒里的进程看不到宿主机 PID，也看不到宿主机的网络接口。这一层相当于给 Agent 的每一次执行任务开了一个"单独房间"。

第二，文件系统投影。沙盒内呈现给 OpenClaw 的根文件系统是一套只读基座，再加上一层临时的可写层。插件想写文件？可以，写进临时层，任务结束整个临时层回收；插件想读取宿主机敏感目录？根目录里根本没有挂载。这是降维打击式的文件权限管理。

第三，网络策略。沙盒默认没有网络，必须由策略显式放行某个目标地址。可以是域名、IP 或 CIDR 网段，也可以精确到端口。插件那个"上报数据""探测内网"的行为，在网络策略这一层就被掐死了。

第四，资源配额。每个执行面有独立的 CPU、内存、磁盘、进程数上限。就算插件代码写了个死循环或者内存泄漏，也只能耗尽自己的配额，影响不到宿主机和其他任务。

第五，审计日志。沙盒内每次进程启动、文件打开、网络连接都会产生结构化日志。数据安全团队要的"谁在什么时候、执行了什么命令、读写了哪些文件"，全部留痕，不需要再靠 shell history。

第六，生命周期管理。一次任务结束，执行单元整体销毁，临时文件、进程残留、内存痕迹全部归零。每次 Agent 调用都是"全新开始"，不会因为上一个任务污染下一个任务。

我把 CubeSandbox 类比成机场安检的"独立登机口"：每个任务都从自己的登机口登机，行李（文件系统）和飞行路径（网络）都经过安检，落地后登机口关闭，下一批旅客重新安检。而不是让所有任务在一个候机大厅里自由走动。

2.3 为什么不用裸容器或虚拟机

很多朋友会问：这些东西 Docker 不是都有吗？K8s 的 Pod 不也能隔离？为什么还要 CubeSandbox？我做了一张对比表：

Docker 的问题在于它本身假设"容器内是可信的"，安全上下文只是可选项。对 AI Agent 这种"不可信输入会直接变成命令"的场景，默认信任就是漏洞。虚拟机隔离最彻底，但秒级启动和完整虚拟磁盘承载不了 Agent 高频、短时、反复调用的模式，更不用说一台机器跑不了几百个 VM。CubeSandbox 走的是一条中间路线：共享内核但强制隔离关键资源，启动快、密度高、策略可编程，正好匹配 Agent 执行面的工作负载特征。

3. 实操：CubeSandbox 落地全过程

3.1 最小化部署

我在 Ubuntu 22.04 上做的第一版部署。CubeSandbox 本身是一个 runtime 服务，安装后需要初始化运行时环境和策略存储。

安装阶段比较简单，解压二进制、写 systemd unit、启动服务：

wget https://downloads.example.com/cubesandbox/latest/csbox-2.1.0-linux-amd64.tar.gz tar -xzf csbox-2.1.0-linux-amd64.tar.gz sudo install csbox /usr/local/bin/ sudo mkdir -p /etc/csbox/policies sudo install -m 755 csboxd /usr/local/sbin/

然后写一个最小的服务配置：

[Unit] Description=CubeSandbox Runtime After=network.target [Service] ExecStart=/usr/local/sbin/csboxd --config /etc/csbox/csboxd.yaml Restart=always LimitNOFILE=65536 [Install] WantedBy=multi-user.target

csboxd.yaml里核心是两块：执行单元的资源默认值和策略存储路径。我给初版设置的是每任务 1 CPU、512MB 内存，策略目录指向/etc/csbox/policies。先启动，再验证 runtime 状态：

sudo systemctl daemon-reload sudo systemctl enable --now csboxd csboxctl runtime status

看到输出里 runtime 是 active，默认执行单元池也在线，部署就成功了。这一步大概十分钟，但要记得把 runtime 的 API socket 权限收紧，只允许 OpenClaw 服务账号访问，别把管理口暴露给所有进程。

3.2 把 OpenClaw 的执行器切到沙盒后端

OpenClaw 执行命令默认走的是子进程 fork。要把它切换到 CubeSandbox，需要把 OpenClaw 的 executor 配置指向沙盒的 API 端点。我习惯用配置文件改，OpenClaw 的openclaw.yaml里有个executor段：

executor: backend: cubesandbox endpoint: unix:///var/run/csbox/exec.sock default_policy: enterprise-default timeout_seconds: 300 env_passthrough: - OPENCLAW_TASK_ID - DSH_PROFILE

这里backend从native改成cubesandbox，OpenClaw 的所有命令执行调用就会走沙盒 API。env_passthrough控制哪些环境变量能带进沙盒，原则是尽量少，默认只放任务 ID 和插件配置项。环境变量里原来的数据库连接串、云厂商密钥，在沙盒里一律不存在。

改完之后重启 OpenClaw，再执行一条测试命令。在 OpenClaw 里可以让它跑一个简单的pwd && ls /，然后去看 CubeSandbox 的审计日志里是否多了一条执行记录。如果日志里有，说明执行链路已经切到沙盒；如果没日志，继续用原来的子进程模式，就要查 executor 配置是不是没生效。

3.3 DSH 插件的适配与分发

DSH 作为插件市场，正常安装插件后插件脚本会被拉到本地目录。如果 OpenClaw 最终执行的是这些脚本，那脚本本身还是在沙盒外被解释执行——这是很多团队的误区：以为插件装到沙盒目录下就安全了，实际上执行器没走沙盒，等于白搭。

正确做法是让 DSH 在安装插件时只做"登记"，不把脚本直接落到 OpenClaw 所在文件系统的可执行路径，而是登记到 DSH 的插件目录服务里。CubeSandbox 执行时会按"插件名 + 版本号"从 DSH 拉取内容，再到沙盒里实例化。

DSH 插件清单里需要加一段沙盒声明：

# dsh/plugins/log-analyzer/manifest.yaml name: log-analyzer version: 1.2.0 sandbox: enabled: true policy: plugin-restricted base_image: csbox-base-python3.11 writable_paths: - /tmp/output - /var/cache/tasks network_access: - api-internal.example.com:443 - kb.example.com:443

这个 manifesto 是给 CubeSandbox 渲染策略用的。writable_paths声明插件只能在这两个目录写文件，network_access声明它只能访问内网知识库和 API。DSH 做版本升级时，manifest 会一并变更，沙盒策略跟着插件版本走，同一个插件升级后如果擅自请求新的网络地址，CubeSandbox 会直接拦下来并告警。

这套配合跑顺之后，OpenClaw 的技能加载流程变成了：任务规划需要某个能力 → DSH 找到插件清单 → 确认沙盒策略 → CubeSandbox 创建执行单元 → 加载插件代码与只读文件 → 执行 → 回收。插件代码从进入沙盒到销毁，全程没有接触宿主机文件系统。

3.4 一次完整请求的生命周期

把前面的环节串起来，一个典型的请求长这样：

1. 用户给 OpenClaw 发任务："分析最近的订单异常率"。
2. OpenClaw 规划拆解，决定调用order-abnormal-analysis技能。
3. DSH 返回该技能的最新版本和沙盒策略声明。
4. CubeSandbox 根据策略创建一个执行单元，挂载只读的订单数据快照，放行到数据仓库的 443 端口。
5. 技能代码在沙盒里运行 SQL 查询、做计算、把结果写到临时可写层。
6. OpenClaw 从沙盒的只读输出目录取回结果，组织语言回复用户。
7. 任务结束，执行单元连同临时数据整体销毁，审计日志持久化。

整个过程里，数据仓库的连接串配置在策略里，技能代码看不到密钥本身；技能想访问其他内网服务，网络策略不放行；技能想写宿主机任何路径，文件系统投影不允许。AI 干活的空间很大，但破坏半径被钉死在"策略允许"这个范围内。

4. 策略与权限：让沙盒"够用但不越界"

4.1 最小权限策略的写法

CubeSandbox 的权限模型本质上是"默认拒绝 + 显式放行"。写策略时我遵循三条原则：

第一，文件权限按目录投影，不按"路径穿越"判断。不要写"允许读取 /data 下所有文件"，而是把具体目录投影进沙盒的只读挂载点。比如：

{ "policy": "enterprise-default", "filesystem": { "readonly": [ "/srv/data/orders/2024/**", "/etc/csbox/certs/**" ], "writable": [ "/tmp/output/**" ] }, "network": { "egress": [ "api.internal.example.com:443" ] }, "resources": { "cpu": 1, "memory_mb": 512, "processes": 128, "disk_mb": 512 } }

第二，网络策略按"业务必需"放行。能走 443 就不要放行 80；能指向具体域名就不要放行 IP 段；能放行一个 API 域名就不要放行整个网段。给 DSH 插件放行网络时要特别克制，默认应该是空。

第三，插件按信任级别分级。我建了三个等级：trusted、restricted、isolated。核心团队自己写的内部工具属于 trusted，可以访问内网数据服务；经过审计的第三方插件属于 restricted，只能访问白名单 API；来路不明的社区插件全部扔进 isolated，无网络、无宿主机文件、无持久化，跑一次就销毁。DSH 在插件元数据里直接标注级别，CubeSandbox 按级别套策略模板。

4.2 网络隔离和出站白名单的细节

网络这块是执行面安全最容易被忽略的环节。很多团队装好沙盒，觉得"进程隔离了就行"，结果插件照样能往外部发数据——因为出站网络没关。

我在 CubeSandbox 里会把初始策略设置成"无任何出站规则"，然后逐条加白名单。一个 Agent 任务需要访问的知识库、向量数据库、模型 API，都在策略里显式列出。域名解析和连接都走沙盒网络命名空间，沙盒内发起的 DNS 查询也会被审计。

有个踩坑点：如果 OpenClaw 本身需要回调沙盒里正在运行的进程（比如流式输出、插件进度回报），需要给回调端口留一条规则。我的做法是让 CubeSandbox 在每个执行单元里注入一个CALLBACK_TOKEN环境变量，OpenClaw 通过策略放行的固定回调端口带上 token 识别身份。这样既保证了回连可用，又不会让外部流量伪装成回调。

4.3 临时数据回收与保密

沙盒的可写层给我最踏实的一点是"任务结束即销毁"。执行单元被销毁时，临时层里的文件、进程缓存、环境变量、内存页全部清空。这意味着插件在处理敏感数据时，即使脚本里写了一些不干净的临时文件，只要任务结束，它们不会残留到宿主机磁盘上。

不过有一个前提：你要确认系统配置没有把沙盒临时层落到非加密盘，或者落到宿主机共享目录。我在一台测试机上犯过这个错，临时层指到了/var/csbox/overlay，那个分区没有开启加密，后面查另一个问题的时候发现残留明文数据。后面所有宿主机都要求临时层所在分区启用加密，并且/var/csbox的权限只给 csboxd 服务账号。

另外一个细节是"带出数据"的控制。沙盒只能通过 OpenClaw 定义的输出通道返回结果。比如技能计算结果写到/tmp/output/report.json，OpenClaw 只允许读取该目录下的明确文件，不允许把沙盒内所有文件打包传出。这样即使插件代码里藏了"上传全部文件"的逻辑，它也只能传它自己写出来的那部分，碰不到只读挂载点之外的东西。

5. 实战常见问题与排查记录

5.1 沙盒内工具链缺失

最常见的问题：插件脚本依赖某个工具或库，但沙盒基座镜像里没有。比如一个日志分析插件需要jq和python3.11，基座是精简版，只有python3.10，脚本直接报ModuleNotFoundError。

排查方法是看沙盒的进程启动日志，OpenClaw 会返回非零退出码和 stderr。解决路径有两条：一是给这类插件配置专门的基座镜像，在 DSH 的 manifest 里指定base_image: csbox-base-data-tools；二是给基座镜像做统一增强，把常用的 jq、yq、curl、python 常用库预装进去。我建议按插件域维护几个模板镜像，别把镜像养得过大，否则沙盒启动速度和资源占用会失控。

5.2 插件回连 OpenClaw 失败

有几次 OpenClaw 提示"技能执行超时"，但 CubeSandbox 日志里显示进程已经结束了。查下去发现是插件在回传进度状态时，连接 OpenClaw 回调端口的请求被网络策略拦了。

这时候不是直接放行所有端口，而是在策略里加一条精确规则：允许沙盒内进程访问回调端点（通常是 OpenClaw 所在服务的固定地址和端口），并且用 token 做身份校验。配置示例：

"network": { "egress": [ "api.internal.example.com:443", "127.0.0.1:18080" ] }

注意回调端口不要用大范围随机端口，否则策略没法精确放行。如果确实要随机端口，就把回调机制改成"沙盒内进程主动触发一个本地脚本，由该脚本通过 OpenClaw API 汇报状态"，避免沙盒内进程直接反向连接。

5.3 执行超时和资源耗尽

Agent 任务执行时间长，容易撞上timeout_seconds上限。我在 OpenClaw 配置里初始设的 300 秒，跑数据分析类任务经常不够。后面改成按策略区分：普通 shell 任务 300 秒，数据拉取任务 900 秒，训练类任务单独申请。

资源耗尽的另一个典型表现是"沙盒创建失败"。当并发任务多，执行单元池被占满，新任务会排队。排查时先看csboxctl runtime stats，确认资源配额是否合理。我之前把单任务内存设成 1GB，结果同时跑三个任务内存直接打满，后面改成 512MB 并用 swap 兜底，任务排队情况明显减少。

5.4 安装部署与桌面版问题的快速排查

热词里很多人问 OpenClaw 安装配置、DSH 安装出错、桌面版问题。结合我踩过的坑，整理一个快速排查表：

这几个问题背后都有一个共同点：安装失败大多不是软件 bug，而是配置没有把执行链路的某个环节理顺，或者网络策略把必要的源给拦了。排查时先看日志，别上来就重装。

5.5 关于"API 算力和本地推理"的注意点

有朋友问 OpenClaw 是不是只能用 API 的方式接入算力。实际体验下来，OpenClaw 的规划模型可以走 API，也可以接本地推理服务。两者在执行面安全上有个差别：如果用本地推理，推理进程和 Agent 进程最好各自独立沙盒，避免一个共享进程里的内存越权影响另一个任务。如果用 API 方式，模型调用本身只是一次 HTTPS 请求，执行面风险集中在沙盒内，反而更好管控。我个人在企业级使用中倾向于 API 推理 + 沙盒执行的两层分离：推理在外面，执行在沙盒里，互不干扰。

6. 关于执行面治理的三点经验

这套方案跑了一年，我总结出三个比技术更重要的经验。

第一，执行面安全不是一个工具能解决的，而是一种"运行时治理"机制。CubeSandbox 给了技术上拒绝执行的底气，但真正让体系运转的，是那套"插件分级 + 策略模板 + 审计告警"的流程。每一次新插件上线，都要走过"DSH 登记 → 策略评审 → 沙盒试运行 → 灰度放量"这条路。流程笨一点，但线上事故会少很多。

第二，给 AI 的权限，一定不要超过"最小可用"这条线。很多人觉得 Agent 应该拥有和员工一样多的权限才能干活，这是最大的误解。AI 不需要看全部代码库，只需要看它正在改的那几个文件；不需要访问所有内网服务，只需要调用它任务涉及的 API。沙盒的价值不是限制 AI，而是把 AI 的能力精确配送。

第三，审计日志要有，但别只看日志。我遇到过某次告警，插件在沙盒里尝试访问一个未放行的内网地址，被策略拦截。单看日志只是一条 denied，但如果结合插件版本记录，能发现这个版本和上一版多了一段探测内部网络 IP 的代码。后来我们直接在 DSH 市场侧做了联动：插件版本声明里强制加入沙盒策略 API 的调用点，任何超出策略范围的访问都会触发告警并阻断更新。这是纯沙盒技术之外的治理增强。

最后再分享一个细节：CubeSandbox 给执行单元命名时，建议把openclaw任务ID + 插件版本 + 时间戳全部拼进去。出了事去翻审计日志，从执行单元 ID 就能直接回溯到具体是哪次任务、哪个插件版本、哪段 prompt 引发的行为。省下的排查时间，比你想象的要多得多。