Linux沙盒隔离实战：命名空间、seccomp与cgroup执行不可信代码

1. 沙盒技术到底在解决什么问题

沙盒技术这个词这两年出现的频率越来越高，但很多人第一次接触它，是在一个很具体的场景里：你要让一段别人写的代码在你的机器上跑起来，而你对这段代码一无所知。它可能死循环、可能疯狂吃内存、可能试图删掉你的文件、也可能悄悄连出去把数据传走。你要的不是"相信它不会干坏事"，而是"即使它干了，也伤不到我"。这就是沙盒技术最朴素的定义——给不受信任的东西划一块地，地里的东西随便折腾，但出不了这块地。

我做后端和基础设施这些年，沙盒这个词在我手上出现过很多次，但每次的含义都不太一样。早期是给在线判题系统做隔离，让用户提交的代码在一个受限环境里编译运行；后来是给数据平台做任务隔离，避免某个跑歪的脚本把整台机器的内存吃光；再后来是给内部工具做插件机制，允许第三方写扩展但不能碰核心数据。这些场景看起来差别很大，底层的思路却高度一致：用最小的权限，跑最不可控的东西。

这篇文章想讲清楚三件事。第一，沙盒的隔离边界到底由哪些东西构成，内核给了我们哪些把手；第二，不同形态的沙盒方案在什么场景下该选谁，选型时的判断依据是什么；第三，怎么从零搭一个能用的沙盒执行环境，包括参数怎么算、坑在哪里、出了问题怎么排查。不管你是刚接触这个概念、只知道"要隔离"的开发，还是已经在做容器平台、想补齐安全细节的同行，应该都能从里面拿到能直接用的东西。

需要先说明一点：沙盒不是某一个具体产品，它是一套思路的组合。同样叫"沙盒"，浏览器里的沙盒、手机上的沙盒、服务器上跑代码的沙盒，实现手段差得很远。所以别指望有一个万能方案，先搞清楚你要防的是什么，再决定用哪一层隔离。

2. 隔离的边界拆解：一个进程到底能被限制住哪些东西

2.1 从一次没做隔离的事故说起

早年间我参与过一个内部的小工具平台，功能很简单：用户在网页上填一段脚本，后台跑一下，把结果返回。当时的实现是直接在主进程里exec执行，理由是"都是内部同事，不会有问题"。上线两周后出事了——有人写了个递归函数没设终止条件，进程把内存吃到 OOM，宿主机上另外几个服务一起被拖垮；还有人不小心写了rm -rf加了个错误的路径变量，删掉了共享目录里的配置。

这两件事让我彻底改变了对"内部可信"的判断。内部用户不是恶意的，但一定是会犯错的，而沙盒的第一价值其实是防手滑，其次才是防攻击。想清楚这一点，你对隔离强度的取舍会理性很多——你不需要防御国家级攻击者，但你必须挡住一个写了死循环的普通同事。

所以后来我总结出一个判断框架：先列出"可能出问题"的清单，再逐条对应隔离手段。常见的破坏面无非四类：文件系统（读写不该碰的路径）、网络（连出去或者被连）、进程（fork 炸弹、信号干扰、看到别的进程）、资源（CPU、内存、磁盘、文件描述符）。这四条边界构成了绝大多数沙盒的基本盘，剩下的都是加固。

2.2 四条边界分别对应什么机制

文件系统边界，最经典的是chroot，把进程的根目录换掉，它眼里的/就是你指定的那个目录。但chroot单独用是不够的，历史上绕过它的手法不少，比如先拿到目录 fd 再chdir("..")逃出去，所以现代做法基本都会配合挂载命名空间，把整个挂载表复制一份再改，外面的挂载点它根本看不见。

进程边界靠 PID 命名空间。新建一个 PID namespace 后，里面的进程会觉得自己是 1 号进程，看不到宿主机上的其他进程，也没法给它们发信号。这里有个细节值得说：PID 命名空间里的 1 号进程有特殊语义，如果它退出了，内核会把整个命名空间里的进程全部杀掉。这个特性非常好用——你在沙盒里跑一个守护进程当"看门人"，只要它退出，里面的残留进程自动清干净，省得你自己去扫。

网络边界靠 network namespace，新建之后只有一块 lo 回环网卡，默认完全不通。需要联网时再往里插虚拟网卡、配地址、做转发。我个人的经验是：默认全断，按需开洞。绝大多数"跑一段代码"的场景根本不需要外网，一旦需要，就说明你要重新审视这个需求了。

资源边界靠 cgroup 和setrlimit，这两者不是替代关系。setrlimit是进程级的自我约束，简单但要靠进程自己不去突破某些限制；cgroup 是内核层面的强制，更硬。我一般两个都用，setrlimit挡第一层快速失败，cgroup 兜底防止漏网。

2.3 沙盒和虚拟机：不是替代而是分层

经常有人问，既然虚拟机隔离得那么彻底，为什么还要费劲搞沙盒？答案是成本和密度。一台虚拟机启动要几百毫秒到几秒，占几百 MB 内存起步，一台物理机上跑几十个就到头了；而一个命名空间隔离的进程启动只要几毫秒，内存开销几乎可以忽略，一台机器上跑几百上千个没问题。

但虚拟机的隔离强度确实是另一个量级——它隔离的是整个内核，而命名空间共享同一个内核。这意味着内核里任何一个提权漏洞，都可能变成沙盒逃逸。所以选型的逻辑很清晰：如果跑的是完全不信任的代码，且量不大，用虚拟机或微虚拟机；如果跑的是半信任的代码，追求密度和启动速度，用进程级隔离。中间还有一层"用户态内核"方案，把系统调用拦下来自己实现一遍，隔离强度接近虚拟机但开销小一些，适合既要不信任又要高密度的场景。

我在实际项目里的做法通常是分池：普通任务走轻量沙盒池，可疑任务或者首次提交的未知代码走强隔离池，跑过一段时间没问题的再"降级"到轻量池。这样既控制了成本，又没有把风险全押在一个篮子里。

3. 内核给了我们哪些把手：隔离原理逐个拆

3.1 命名空间：让进程活在自己的世界里

命名空间是 Linux 上做隔离的地基。目前常用的大致有这么几类：mount（挂载视图）、pid（进程视图）、net（网络视图）、ipc（进程间通信）、uts（主机名）、user（用户和权限映射）、cgroup（资源视图）。每一个都是把某个全局资源"复制一份"，进程在自己的副本里操作，看不到也不影响别人的。

手工创建一个组合命名空间，最直接的办法是用unshare命令。下面这条命令把用户、PID、挂载、网络、主机名、IPC、cgroup 全部拆开，并且把当前用户映射成里面的 root：

unshare --user --map-root-user \ --pid --fork \ --mount --net --uts --ipc \ --cgroup \ /bin/sh

执行完之后你会发现在这个 shell 里ps只能看到自己，ip addr只有一块 lo，hostname随便改也不影响外面。这就是最朴素的沙盒雏形。

--map-root-user这个参数值得单独讲一下。它的作用是把外面的普通用户映射成命名空间里的 uid 0，这样里面的进程有"root 权限"可以做一些需要权限的操作（比如挂载 proc），但一旦它尝试影响宿主机，内核会按外面的真实 uid 来判定，等于给了它一个"假 root"。这个技巧叫用户命名空间映射，是所有无特权沙盒方案的核心。没有它，你建命名空间就必须先有真 root，安全性反而下降。

3.2 系统调用过滤：白名单思维比黑名单可靠得多

命名空间解决的是"看不见"，但没解决"不能做"。一个进程即使在一个干净的命名空间里，依然可以调用reboot、mount、ptrace这些危险系统调用。这时候就需要 seccomp。

seccomp 的机制很直白：给进程挂一个 BPF 过滤器，每次系统调用进来先过一遍，按规则决定放行、返回错误还是直接杀掉。关键在于用白名单而不是黑名单。黑名单的问题是内核一直在加新系统调用，你不知道下一个漏洞会用哪个；白名单则相反，只放行你确认需要的，其余一律拒绝，新调用天然被挡在外面。

实际写起来，用 seccomp 的用户态封装库会舒服很多，不用手撸 BPF 字节码：

#include <seccomp.h> #include <unistd.h> int main(void) { scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_KILL_PROCESS); /* 只放行最小集合 */ seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(read), 0); seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 0); seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit), 0); seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0); seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(brk), 0); seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(mmap), 0); seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(munmap), 0); /* 允许打开只读文件，但不允许写 */ seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(openat), 0); if (seccomp_load(ctx) < 0) { return 1; } seccomp_release(ctx); /* 从这里开始，任何不在白名单里的系统调用都会杀掉进程 */ return 0; }

注意seccomp_init的第一个参数，我用的是SCMP_ACT_KILL_PROCESS，也就是默认动作是杀进程，而不是返回错误码。这个选择不是随便定的：返回EPERM看起来温和，但会给攻击者一个"探测"的机会，他可以通过错误码逐个试探哪些调用可用，进而拼出一条利用链；直接杀掉则干脆利落，代价是调试时会比较痛苦，因为你只看到进程莫名其妙没了。我的建议是开发期用SCMP_ACT_ERRNO方便定位，上线前切回SCMP_ACT_KILL_PROCESS。

白名单的另一个难点是"到底需要哪些调用"。这个不要靠猜，靠工具：在目标程序正常跑一遍的情况下，用strace -f -c统计它实际用到的系统调用，把高频且无害的挑出来放进白名单，然后逐步收紧。我一般会跑三轮——正常用例、边界用例、异常用例，三轮下来漏掉的概率就很低了。

3.3 文件系统视图：chroot 不够，挂载命名空间才稳

单独用chroot的历史坑太多了。最典型的绕过方式是：进程在 chroot 之前先打开一个外部目录的 fd，chroot 之后再fchdir回去，chroot就形同虚设。现代方案基本不会单独用它。

正确姿势是挂载命名空间 +pivot_root。整个过程分几步：新建 mount namespace，把根文件系统挂成私有的（防止挂载事件传回宿主机），准备好新的根目录，然后pivot_root把旧根换出去，最后把旧根卸载掉。这样进程连"旧的根"这个对象都不存在了，无从逃逸。

如果不想写 C，用 shell 也能做出接近的效果。核心思路是先 bind mount 需要的东西，再把整个根换成只读：

ROOT=/srv/sandbox/rootfs # 挂载点设为私有，防止事件传播回宿主机 mount --make-rprivate / # 把只读的基础镜像挂进去 mount --bind "$ROOT" "$ROOT" mount -o remount,ro,bind "$ROOT" # 需要写入的目录单独挂 tmpfs，限制大小 mount -t tmpfs -o size=32m,nosuid,nodev tmpfs "$ROOT/tmp" # 切入新根 exec chroot "$ROOT" /bin/sh

这里有两个细节容易被忽略。第一是nosuid,nodev这两个挂载选项，它们的意义是即使沙盒里面有 setuid 程序或者设备文件，也不会生效，堵掉一整类提权路径。第二是ro,bind的顺序，必须先 bind 再 remount 成只读，反过来的话 bind 操作会失败或者把只读属性覆盖掉。

文件系统这块我还有个习惯：沙盒的根镜像永远做成只读的，唯一可写的地方是 tmpfs。这样哪怕进程把里面炸了，销毁的时候直接把 tmpfs 一卸，什么都不剩，也不用担心残留文件影响下一次执行。

3.4 资源约束：setrlimit 和 cgroup 各管一段

setrlimit是每个进程都能设的，在 fork 子进程之前设好，子进程继承。它管的东西挺全，常用的几个是：

这张表里最容易踩坑的是RLIMIT_CPU。它有两个值，软限和硬限，软限到了会发SIGXCPU给进程，进程可以选择忽略；硬限到了直接SIGKILL。所以我一般设软限比硬限小 1 秒，留个缓冲。另一个坑是RLIMIT_AS对某些语言不友好——比如 Java 或者一些 Go 程序，它们的运行时启动时就会预申请一大片虚拟内存，设太小会导致还没跑起来就崩。这时候要么按语言分开配置，要么改用 cgroup 的memory.max，那个限制的是实际驻留内存而不是虚拟地址空间。

cgroup 这边，现在主流是 v2 统一层级。给一个沙盒实例建一个 cgroup 目录，往里写限制值，再把进程塞进去：

CGROUP=/sys/fs/cgroup/sandbox/$ID mkdir -p "$CGROUP" # 打开父层控制器 echo "+memory +cpu +pids +io" > /sys/fs/cgroup/cgroup.subtree_control # 内存硬限 128MB，关闭 swap echo $((128*1024*1024)) > "$CGROUP/memory.max" echo 0 > "$CGROUP/memory.swap.max" # CPU 配额：每 100ms 周期内最多用 50ms，即 0.5 核 echo "50000 100000" > "$CGROUP/cpu.max" # 进程数上限，防 fork 炸弹 echo 64 > "$CGROUP/pids.max" # 把当前 shell 放进去 echo $$ > "$CGROUP/cgroup.procs"

cpu.max那行值得展开算一下。它有两个数，第一个是配额（单位微秒），第二个是周期。50000 100000的意思是每个 100ms 周期里最多用 50ms 的 CPU 时间，换算过来就是 0.5 个核。为什么要给半核而不是一整核？因为沙盒里的任务通常是短时的，给整核会导致它在多核机器上抢资源不均匀，给半核能让调度器更平滑地把多个任务分摊开。如果你的场景是"跑满一个核直到超时"，那当然给整核，这取决于业务形态。

销毁的时候也很简单，cgroup v2 有个cgroup.kill文件，往里写 1 就能把整个 cgroup 里的所有进程一次性干掉，比自己遍历 PID 靠谱得多：

echo 1 > "$CGROUP/cgroup.kill" sleep 0.1 rmdir "$CGROUP"

4. 完整实操：搭一个能跑不可信代码的沙盒执行环境

4.1 先把容量算清楚，再动手

动手之前先算账，不然写完发现跑不了几个任务就 OOM，白折腾。假设需求是这样的：单机支持 200 个并发沙盒，单个任务内存上限 128MB，CPU 时间 2 秒，任务平均耗时 300ms。

内存这块不能简单乘，因为峰值不会同时出现。经验上，短任务沙盒的并发内存峰值大约是"上限 × 并发数 × 0.4"，因为大部分任务用不满限制。所以 200 × 128MB × 0.4 ≈ 10GB。但这是乐观估计，如果任务里有大数组分配，峰值会跳上去。稳妥做法是看实际分布：跑一周，统计 P99 的内存峰值，用它来定并发数。我一般会在 cgroup 里设memory.max为 128MB，同时在调度层控制并发数，让"极限情况下的总需求"不超过机器内存的 70%——200 × 128MB = 25GB，那这台机器至少要有 40GB 内存才敢这么开。

CPU 时间 2 秒，平均耗时 300ms，意味着单个沙盒占用的时间片很短。200 并发如果平均每个占 0.5 核，就需要 100 核。这个数字通常会把人吓一跳，所以实际做法是把并发数压到跟核数匹配：8 核机器跑 32 个并发（每个核 4 个任务轮流），单任务等待时间在可接受范围内就行。沙盒的吞吐瓶颈通常不是内存而是 CPU，这一点在规划时一定要注意。

4.2 分步骤把最小可用版本搭起来

第一步，准备根文件系统。不用完整的操作系统，只需要程序运行需要的动态库和基础命令。用一个最小化的镜像解压到一个目录，把不需要的东西全删掉——/usr/bin里留几个必要的，/etc里只留必需的配置。目录越小，攻击面越小，启动也越快。

第二步，写启动器。启动器的职责是把前面讲的隔离手段串起来：建命名空间、设 rlimit、挂 seccomp、落 cgroup、限制时间。用 Python 写一版会比较直观：

import os import resource import signal import subprocess import time def apply_limits(): # 地址空间 256MB，防止一些运行时预申请过大 resource.setrlimit(resource.RLIMIT_AS, (256 << 20, 256 << 20)) # CPU 时间：软限 2 秒，硬限 3 秒 resource.setrlimit(resource.RLIMIT_CPU, (2, 3)) # 进程数，防 fork 炸弹 resource.setrlimit(resource.RLIMIT_NPROC, (32, 32)) # 单文件最大 8MB resource.setrlimit(resource.RLIMIT_FSIZE, (8 << 20, 8 << 20)) # 文件描述符 resource.setrlimit(resource.RLIMIT_NOFILE, (64, 64)) # 关闭 core dump，避免写盘 resource.setrlimit(resource.RLIMIT_CORE, (0, 0)) # 独立进程组，方便整组杀 os.setsid() def run_in_sandbox(rootfs, cmd, timeout=3.0): p = subprocess.Popen( ["chroot", rootfs] + cmd, preexec_fn=apply_limits, stdout=subprocess.PIPE, stderr=subprocess.PIPE, stdin=subprocess.DEVNULL, env={"PATH": "/bin", "HOME": "/tmp"}, ) start = time.monotonic() try: out, err = p.communicate(timeout=timeout) return { "code": p.returncode, "out": out[:65536], # 输出截断，防刷屏 "err": err[:8192], "cost": time.monotonic() - start, } except subprocess.TimeoutExpired: # 整组杀掉，包括它 fork 出来的子进程 os.killpg(p.pid, signal.SIGKILL) p.wait() return {"code": -1, "out": b"", "err": b"timeout", "cost": timeout}

这段代码里有几个地方我特意加了注释，但还有两个隐式细节值得说明。os.setsid()的作用是让子进程成为新会话的首进程，脱离父进程的进程组，这样killpg才能一次把整棵进程树干掉。如果没有它，子进程 fork 出来的孙子进程会留在旧的进程组里，杀不干净。第二个是输出的截断，out[:65536]这个限制不是可有可无的——我见过一个任务往 stdout 里死循环打印，几秒钟就把磁盘写满了，加了这个截断后再也没出现过。

第三步，控制超时。subprocess.communicate(timeout=)本身够用，但它依赖父进程活着。如果启动器自己崩了，子进程会变成孤儿。更稳的做法是配合 cgroup 的memory.max和定时扫描，或者在沙盒里放一个"看门人"进程作为 PID 1，父进程一断开它就退出，进而触发 PID 命名空间的连锁清理。

第四步，验证隔离是否真的生效。这一步千万别省。我一般会准备一组"逃逸测试用例"，跑完看结果：

这张表我建议你直接抄进 CI。每次改沙盒配置都跑一遍，防止某次"优化"把隔离搞漏了。

4.3 编排层要做的三件事

单机沙盒搭好只是开始，真要上量，编排层有三件事必须做。

第一件是预热池。每次从零建命名空间、挂文件系统、加载过滤器，加起来大概几十毫秒，对短任务（平均 300ms）来说开销占比太高。做法是提前建好一批"空壳"沙盒进程，挂在队列里等着，任务来了直接往里塞代码执行，跑完销毁重建。预热的数量按 QPS × 平均耗时来算，比如 QPS 100、平均 300ms，那同时在跑的就 30 个左右，预热带 50 个足够，多出来的等待浪费内存。

第二件是回收与资源清理。沙盒跑完必须确保三样东西都清干净：进程（cgroup kill）、文件（tmpfs 卸载）、网络（虚拟网卡删除）。我踩过一次坑，虚拟网卡没删干净，跑了几万次之后宿主机上堆了上万个网卡设备，网络栈直接崩了。所以清理逻辑一定要幂等，并且加监控——泄漏的东西每天扫一遍，发现残留就告警。

第三件是日志与溯源。每个沙盒执行都要记录：谁提交的、什么时间、跑了多久、退出码、被拦截的系统调用（可以从内核审计日志里捞）。这些日志在出问题时极其有用，尤其是"某个任务莫名其妙的失败"这种，看审计日志里有没有被 seccomp 拦下来的调用，一眼就能定位。

5. 落地时踩过的坑和排查思路

5.1 性能损耗到底有多少

很多人担心沙盒会拖慢执行速度。实测下来的结论是：创建开销远大于运行开销。创建一个完整的命名空间组合大约 5-20 毫秒，加载 seccomp 过滤器在 1 毫秒以内，运行时的额外开销主要来自系统调用被拦截的那部分，对于正常程序来说影响在 2%-5% 之间，基本可以忽略。

真正影响性能的是两件事。一是文件系统的挂载方式，如果每次都去挂一个远程文件系统或者做大量 bind mount，创建时间会飙到几百毫秒；用本地 tmpfs 加预制的只读镜像，可以压到 10 毫秒以内。二是调度策略，如果进程被放进 cgroup 后频繁触发 CPU 限流（throttle），任务会出现"跑一下停一下"的抖动，看起来像是性能问题，实际上是配额设太小。排查的时候看cpu.stat里的nr_throttled和throttled_usec两个值，如果每秒都在涨，就把cpu.max放宽。

有个容易被忽略的点是页缓存。沙盒用的根镜像如果每次都从磁盘读，第一次会很慢。做法是预热时把镜像完整读一遍，让内核把它缓存住，后面所有沙盒共享这份缓存，实际内存占用是共享的而不是每个沙盒一份。

5.2 兼容性问题：程序莫名其妙崩溃

这是落地阶段最高频的问题。程序在沙盒里跑，直接段错误或者无声退出，外面跑得好好的。原因十有八九是 seccomp 白名单漏了某个系统调用。

典型例子：某个语言运行时在启动时会调getrandom拿随机数，白名单里没有，直接被杀；某个库用了epoll_wait，没放行，卡死；新版本内核加了clone3，老白名单里只有clone，程序直接起不来。这类问题的排查手段是固定的：先用strace -f在沙盒外跑一遍，记录完整调用序列；再在沙盒里跑一遍，对比差异；最后把缺的调用按需补进白名单。

补的时候要注意粒度。clone3这种调用可以带很多参数，直接全放行风险大。seccomp 支持对参数做过滤，比如限制clone的 flags 只允许特定组合，可以挡掉一部分风险。但参数过滤写起来麻烦，我的经验是：常用的、无害的调用直接放行；高风险的调用（如ptrace、mount、bpf）一律拒绝，宁可让个别程序跑不了，也不留口子。

还有一个隐蔽的坑是时区和语言环境。沙盒镜像里如果没有/etc/localtime或者 locale 数据，程序的行为可能和外面不一致，输出格式错乱，排查半天以为是逻辑问题。所以镜像里该有的基础数据还是要留。

5.3 逃逸风险：别指望单一防线

必须承认一个事实：共享内核的隔离，理论上都有逃逸可能。历史上出过不少容器逃逸的问题，根源基本都是内核漏洞或者配置不当。所以设计时要假设"第一层防线会被突破"，然后加第二层。

第二层通常是这几样：一是沙盒进程用非特权用户跑，即使逃出命名空间，也只是个普通用户；二是用 seccomp 把危险调用拦死，很多提权路径依赖ptrace、keyctl、unshare这些调用，拦掉就断了一大半；三是宿主机的内核参数加固，关掉不需要的功能模块；四是监控异常行为，比如沙盒进程尝试访问/proc/self/mem、频繁调用mmap可执行内存，这些在正常任务里很少见，值得告警。

还有一类容易被忽视的风险是侧信道。两个沙盒共享同一块 CPU 缓存，理论上可以通过缓存时序推测对方的数据。对于跑公开代码的场景这个风险不高，但如果沙盒里跑的是不同用户的敏感数据，就要考虑物理隔离或者关闭超线程。这部分属于比较专业的攻防领域，普通业务场景做到"不跑不信任的代码在敏感机器上"就够了。

5.4 常见问题速查

这张表里最后一条特别值得说。有些任务依赖随机数，如果getrandom被拦导致它退化成用时间戳做种子，同一份输入跑两次结果不同，业务方会以为是沙盒"不稳定"。这种问题排查起来很费劲，因为它表现为业务逻辑错误而不是崩溃。我的做法是：白名单里必须包含随机数相关调用，宁可放行也不能让程序退化。

6. 新场景下的沙盒：从跑代码到跑智能体

这两年沙盒又多了一类新用法——给自动化流程或者模型生成的动作提供执行环境。这类场景和传统的"跑用户代码"有相似之处，但侧重点不太一样。

传统沙盒关注的是"别把我的机器搞坏"，所以重点在资源限制和文件隔离。而智能体场景关注的是"别做我不同意的事"，所以重点在动作审批和可回滚。一个自动化流程可能会去调接口、改文件、发消息，这些动作本身不消耗多少资源，但后果可能是不可逆的。这时候沙盒的设计思路要变：不只是限制资源，还要在动作执行前留一个检查点，把环境状态快照下来，出问题能一键回滚；同时对高危动作（删除、外发、支付类）做拦截，要求人工确认。

实现上，我一般会用一个"影子环境"的思路：给智能体一个完整但隔离的工作目录，所有写操作都落在里面，外部通过一个受控的网关暴露给它，网关记录每一次调用。跑完之后，人看一眼调用日志，确认没问题再把结果合并出去。这个模式其实借鉴了代码评审的思路——让机器的动作经过一次人工或规则审阅，而不是直接生效。

另一个变化是沙盒的生命周期变长了。跑代码的沙盒是秒级的，用完即焚；智能体的沙盒可能要跑几分钟甚至几小时，中途还要保留上下文。这就要求沙盒支持"暂停-恢复"，把内存状态 dump 出来下次接着跑。技术上可以用检查点容器或者用户态内核的机制实现，但开销明显更大，选型时要权衡。

我个人在实际操作中的体会是：沙盒技术最难的部分从来不是"怎么写隔离代码"，而是"怎么定边界"。边界太松，等于没做；边界太紧，业务跑不起来，最后大家会想方设法绕过你。所以每次设计沙盒，我都会先跟使用方确认三件事：这段东西需要访问什么、需要写什么、失败时能接受什么程度的损失。把这三个问题问清楚，配置参数基本就出来了，剩下的都是工程细节。

如果你现在正准备给自己的系统加一层沙盒，我的建议是从最小可用开始：先上命名空间加资源限制，把"手滑炸机器"这类问题挡住，这一步的成本最低、收益最大；等有真实需求了，再逐步加 seccomp 白名单和网络隔离。别一上来就追求最强的隔离，那通常意味着最高的复杂度，最后维护不动反而更危险。