Agent沙箱为何重造？overlayfs分层与写时复制实战

1. 当"沙箱"这个词被重新提起时，我们到底在聊什么

沙箱这个词在工程圈里确实不算新鲜。从浏览器里的 iframe 隔离，到支付系统里的模拟环境，再到操作系统层面的容器与虚拟机，隔离这件事已经被反复打磨了十几年。所以当有人提出"DeepSeek 为什么还要重造一遍沙箱"的时候，第一反应往往是：这不是早就有的东西吗，直接拿来用不就行了？

但如果你真正做过 AI Agent 相关的开发，就会知道这个问题的答案没那么简单。传统沙箱解决的核心问题是"别让不可信的代码搞坏我的系统"，而 Agent 场景下要解决的问题变成了"让一个会自己写代码、自己执行、自己看结果、再自己改代码的智能体，在一个可控、可观测、可回滚的环境里跑起来"。这两件事听起来像，实际上差得很远。

我接触过不少做 Agent 项目的团队，早期几乎都踩过同一个坑：直接拿现成的容器方案套上去，结果发现 Agent 生成的代码五花八门，依赖装了一堆，文件改得到处都是，跑完一轮之后环境已经面目全非，想复现上一次的结果都做不到。这时候你才会意识到，Agent 需要的不是一个"关起来"的笼子，而是一个"可以随时推倒重来"的工作台。

这篇内容想聊的就是这件事。我会从 Agent 执行环境的真实需求出发，拆解为什么通用沙箱方案在 Agent 场景下会水土不服，overlayfs 这类分层文件系统在其中扮演什么角色，以及一个面向 Agent 的沙箱在设计上要考虑哪些普通沙箱不会考虑的细节。不管你是刚开始接触 Agent 开发，还是已经在做相关项目，希望这些内容能帮你少走一些弯路。

2. Agent 执行环境的需求，和传统沙箱根本不在一个频道上

2.1 传统沙箱的假设：代码是"敌人"

先说说我们熟悉的沙箱是怎么设计的。无论是浏览器沙箱、移动端的应用沙箱，还是服务端的容器隔离，它们的底层假设都高度一致：运行在里面的东西是不可信的，我要防止它对外部造成破坏。

这个假设决定了传统沙箱的设计重心。它关心的是权限收窄、系统调用过滤、网络访问限制、资源配额这些事。你给它一段代码，它的任务是确保这段代码就算使坏，也只能在划定的圈子里折腾，出不去。

在这个模型下，沙箱是"防御性"的。它不需要理解代码在干什么，不需要知道代码跑完之后留下了什么，更不需要支持代码反复修改自己的运行环境。跑完就销毁，干净利落，这是最理想的状态。

2.2 Agent 场景的假设：代码是"工具"

Agent 场景完全反过来。Agent 生成代码不是为了攻击你，而是为了完成任务。它写一段 Python 脚本去处理数据，写一个 shell 命令去装依赖，写一个配置文件去调整参数，这些都是正常的、预期内的行为。

问题在于，Agent 的工作方式是迭代式的。它不会一次就写出完美代码，而是写一版、跑一下、看报错、改一改、再跑。这个循环可能重复几次甚至几十次。每一次执行都会对环境产生副作用：装了新包、生成了中间文件、改了配置、留下了缓存。

如果每次执行都从一个干净环境开始，那 Agent 每次都要重新装一遍依赖，效率低到没法用。如果每次执行都在同一个环境里累积，那环境会越来越乱，最后连 Agent 自己都搞不清楚当前状态是什么。

这就是 Agent 沙箱要解决的核心矛盾：既要让环境状态在迭代中保持连续，又要保证任何时候都能干净地回退到某个已知状态。

2.3 三个传统沙箱不会管、但 Agent 必须管的问题

我把 Agent 场景下特有的需求归纳成三条，这三条基本决定了为什么不能直接套用现成方案。

第一条是可回溯性。Agent 跑到第五轮的时候发现前面某一步改错了，它需要能回到第三轮结束时的状态重新来。传统沙箱要么全保留要么全销毁，没有中间态。而 Agent 需要的是类似 Git 那样的快照能力，每一步都能打点，随时能回退。

第二条是可观测性。Agent 需要知道自己上一步到底改了什么。是新增了文件，还是修改了已有文件，还是删除了什么？这些信息要能结构化地反馈给 Agent，它才能做出正确判断。传统沙箱只告诉你"执行成功或失败"，不告诉你"环境发生了什么变化"。

第三条是执行与环境的解耦。Agent 可能同时跑多个任务，每个任务需要不同的环境。如果每个任务都起一个完整容器，资源开销大得离谱。理想情况是底层共享同一份基础环境，上层各自有独立的工作空间，互不干扰。

这三条需求叠加起来，就指向了一个明确的技术方向：分层文件系统 + 写时复制。而这正是 overlayfs 的拿手好戏。

3. overlayfs 为什么成了 Agent 沙箱的天然底座

3.1 用一句话说清 overlayfs 在干什么

overlayfs 是 Linux 内核提供的一种联合文件系统。它的核心能力是把多个目录"叠"在一起，对外呈现为一个统一的目录视图。读文件的时候从上往下找，写文件的时候写到最上面那一层，下面几层保持只读不动。

打个比方，你可以把它想象成一沓透明胶片。最底下那张是印好的底图，上面每张都是空白的。你在最上面那张写字，写的内容会盖住底图对应位置，但底图本身没被破坏。想看原始底图，把上面几张抽掉就行。

这个特性放到 Agent 场景里，简直是量身定做。基础环境（操作系统、运行时、常用依赖）放在底层只读，Agent 的每一次执行都在一个新的可写层里进行。执行完了，这一层要么合并进去成为新的基础，要么直接丢掉回到之前的状态。

3.2 分层结构如何对应 Agent 的执行模型

一个典型的 Agent 沙箱分层大概是这样设计的：

这个结构的好处在于，基础层和任务层是复用的，只有工作层是每次执行新建的。一个任务跑一百轮，前两层只构建一次，工作层每轮换一个，开销极小。

3.3 写时复制带来的"零成本回退"

写时复制的意思是，只有当某个文件真的被修改时，才会把它从只读层复制到可写层。没被碰过的文件，读的时候直接穿透到下层，不占额外空间。

这个机制对 Agent 来说意味着什么？意味着回退是免费的。Agent 想回到上一轮的状态，只需要把当前的工作层丢掉，重新挂载一个新的空工作层就行。不需要做任何数据恢复操作，因为原始数据从来没被改过。

我实测过一个场景：一个 Agent 任务跑了三十多轮，每轮都装不同的依赖、生成不同的中间文件，累计写入数据大概两个 G。但因为每轮的工作层是独立的，回退到任意一轮的耗时都在毫秒级，因为本质上只是换了个挂载点。

这里有个容易踩的坑：如果 Agent 在可写层里删除了一个下层存在的文件，overlayfs 会生成一个 whiteout 标记文件来记录"这个文件被删了"。如果工作层里 whiteout 积累太多，合并视图的读取性能会下降。所以工作层不能无限期保留，该合并的时候要合并，该丢弃的时候要丢弃。

3.4 和容器方案的对比：不是替代，是互补

有人会问，那直接用容器不就行了，容器底层不也是 overlayfs 吗？

这话对了一半。容器确实用 overlayfs 做镜像分层，但容器把 overlayfs 包在了一层很重的抽象里。你要起一个容器，得走完整的容器运行时流程，涉及命名空间、cgroups、网络配置等等。对于 Agent 这种"频繁起停、轻量执行"的场景，这套流程太重了。

更关键的是，容器暴露给上层的接口是"容器"这个粒度，而 Agent 需要的是"文件系统层"这个粒度。Agent 想精确控制哪一层可写、哪一层只读、什么时候合并、什么时候丢弃，容器运行时不会给你这个灵活性。

所以面向 Agent 的沙箱，更合理的做法是直接操作 overlayfs 挂载点，把容器运行时那套东西剥掉，只保留文件系统分层这一核心能力。需要网络隔离的时候再单独加，需要资源限制的时候再单独加，按需组合，而不是一股脑全塞进去。

4. 一个 Agent 沙箱真正难的地方，在文件系统之外

4.1 执行结果的语义化：不只是"成功"或"失败"

Agent 执行一段代码，返回的不应该只是一个退出码。它需要知道：标准输出是什么，标准错误是什么，产生了哪些文件变更，有没有网络请求，耗时多少，峰值内存多少。

这些信息里，文件变更列表是最难拿的。传统做法是执行前后各做一次目录快照，然后 diff。但目录大了之后，这个 diff 操作本身就很耗时。

更聪明的做法是利用 overlayfs 的特性：执行完之后，直接看 upperdir 里多了哪些文件、少了哪些文件（whiteout）、哪些文件被修改了。因为 upperdir 只记录变更，不需要全量扫描，速度极快。

我见过一个实现，它在每次执行后遍历 upperdir，把变更整理成一个结构化的 JSON 返回给 Agent。Agent 拿到这个 JSON 之后，能清楚知道自己上一步干了什么，下一步该怎么调整。这个反馈闭环一旦建立起来，Agent 的自我修正能力会明显提升。

4.2 依赖安装的缓存策略：别让 Agent 反复装同一个包

Agent 写代码经常需要装依赖。如果每轮执行都重新 pip install 一遍，时间全浪费在下载上了。

合理的做法是在基础层预装一批常用依赖，然后在任务层做一层缓存。具体来说，可以维护一个"依赖缓存层"，Agent 第一次装某个包的时候，把它装到缓存层里；后续再有任务需要同一个包，直接从缓存层读，不用重新下载。

这里有个细节要注意：不同任务对同一个包的版本要求可能冲突。所以缓存层不能简单按包名缓存，得按"包名+版本"缓存，或者干脆给每个任务独立的缓存层，任务之间不共享。共享能省空间但可能冲突，独立更安全但占空间，这个取舍要看具体场景。

4.3 并发执行时的隔离边界

Agent 经常需要并发跑多个子任务。这时候隔离边界画在哪里就很关键。

如果每个子任务一个独立的工作层，那它们之间完全隔离，互不影响，但也没法共享中间结果。如果共享一个工作层，那并发写入会互相干扰，结果不可预测。

比较务实的方案是：读共享，写隔离。所有子任务共享同一套只读层，各自有独立的工作层。需要传递中间结果的时候，通过一个显式的"交换目录"来传递，这个目录挂载在所有工作层都能访问的位置。这样既保证了隔离性，又提供了受控的共享通道。

4.4 资源回收：工作层不能只增不减

跑得久了，工作层会越积越多。每个工作层都占磁盘空间，不回收的话很快就会把盘撑满。

回收策略一般有两种。一种是按时间，超过一定时长的工作层自动清理。一种是按引用计数，没有任何任务引用的工作层才清理。实际用下来，两种结合比较稳妥：活跃任务的工作层保留，非活跃的按时间淘汰，同时给每个任务设一个工作层数量上限，超了就淘汰最老的。

有个坑我踩过：清理工作层的时候如果直接 rm -rf，正在使用该层的进程可能会报错。正确做法是先卸载挂载点，确认没有进程占用之后再删目录。卸载和删除之间最好加个短暂延迟，避免竞态。

5. 从零搭一个最小可用的 Agent 沙箱：关键步骤和取舍

5.1 环境准备：内核版本和挂载权限

overlayfs 从 Linux 3.18 开始进入主线，但早期版本有不少 bug。生产环境建议用 4.0 以上的内核，最好是 5.x。可以用uname -r确认当前内核版本。

挂载 overlayfs 需要 CAP_SYS_ADMIN 权限。如果是在容器里跑，需要给容器加--privileged或者更细粒度的--cap-add SYS_ADMIN。不过给特权要谨慎，能不用就不用，可以考虑用用户命名空间来绕过。

# 确认内核支持 overlayfs grep overlay /proc/filesystems # 如果输出里有 overlay，说明支持

5.2 目录结构设计：三层还是四层

最小可用方案三层就够了：base、task、work。但如果要做依赖缓存，建议加一层 cache，变成四层。

# 目录结构示例 /sandbox/ base/ # 基础层，只读 cache/ # 依赖缓存层，只读（可选） task/ # 任务层，只读 work/ # 工作层，可读写 merged/ # 合并挂载点

挂载命令大概长这样：

mount -t overlay overlay \ -o lowerdir=/sandbox/task:/sandbox/cache:/sandbox/base \ -o upperdir=/sandbox/work \ -o workdir=/sandbox/workdir \ /sandbox/merged

注意 lowerdir 的顺序是从上到下，越靠前的优先级越高。task 层要放在 cache 和 base 前面，这样任务特有的文件才能覆盖掉基础层的同名文件。

5.3 执行封装：怎么把命令跑进去

挂载好之后，执行命令的时候需要让进程的根目录指向 merged 目录。可以用 chroot，也可以用 pivot_root，还可以用命名空间。

chroot 最简单，但隔离性弱，进程还是能看到宿主机的进程和网络。pivot_root 更彻底，但实现复杂一些。如果只是做文件系统隔离，chroot 够用；如果要完整隔离，得上命名空间。

# 用 chroot 执行命令的简化示例 chroot /sandbox/merged /bin/bash -c "python script.py"

实际实现里，一般会用一个轻量的执行器进程，它负责挂载、chroot、执行、收集结果、卸载这一整套流程。执行器本身要跑在宿主机上，不能跑在沙箱里，否则没法管理挂载点。

5.4 结果收集：怎么知道 Agent 改了什么

执行完之后，遍历 upperdir 收集变更。核心逻辑是：upperdir 里存在的文件就是新增或修改的，带 whiteout 标记的就是删除的。

import os def collect_changes(upperdir): changes = {'added': [], 'modified': [], 'deleted': []} for root, dirs, files in os.walk(upperdir): for f in files: path = os.path.join(root, f) rel = os.path.relpath(path, upperdir) # whiteout 文件以 .wh. 开头 if f.startswith('.wh.'): changes['deleted'].append(rel[4:]) else: changes['added'].append(rel) return changes

这个逻辑不复杂，但要注意 whiteout 文件的命名规则，不同内核版本可能略有差异，实测确认一下比较稳妥。

5.5 回退与提交：两个操作，两种语义

回退就是丢弃当前工作层，重新挂载一个空的工作层。提交就是把工作层的内容合并到任务层，成为新的基础。

回退简单，卸载再挂载就行。提交麻烦一些，需要把工作层的内容复制到任务层，然后清空工作层。复制的时候要注意权限和符号链接，直接 cp -a 一般够用，但如果有特殊文件类型（比如设备文件），得特殊处理。

提交操作建议做成原子性的：先复制到一个临时目录，复制完成后再原子性地替换任务层。这样即使中途失败，任务层也不会处于半损坏状态。

6. 那些文档里不会写、但实际会遇到的坑

6.1 挂载点泄漏：进程没退干净，挂载卸不掉

最常见的问题。执行器崩了，或者进程被 kill 了，挂载点还挂着，下次再挂同一个点就报 "device or resource busy"。

排查方法是cat /proc/mounts | grep overlay看有没有残留挂载。清理的时候先umount -l（懒卸载），再删目录。懒卸载会等所有引用释放后再真正卸载，比强制卸载安全。

预防措施是给执行器加超时，超时后强制清理挂载点。同时记录每次挂载的状态，启动时先做一次残留清理。

6.2 硬链接和符号链接的处理

overlayfs 对硬链接的支持有历史遗留问题。如果基础层里有硬链接，复制到工作层的时候可能会变成两个独立文件，破坏链接关系。符号链接一般没问题，但指向绝对路径的符号链接在 chroot 之后可能失效。

如果 Agent 生成的代码涉及这些，得提前测试。实在不行就在基础层构建阶段避免使用硬链接，用符号链接或者直接复制代替。

6.3 文件权限和属主映射

chroot 之后，进程看到的用户和宿主机是同一套。如果 Agent 以 root 身份跑，生成的文件属主就是 root，后续非 root 进程可能读不了。

更安全的做法是用用户命名空间做映射，让沙箱内的 root 映射到宿主机的一个普通用户。这样即使 Agent 在沙箱里是 root，对宿主机也没有实际权限。不过这需要内核开启用户命名空间支持，配置起来稍微麻烦一点。

6.4 磁盘配额：别让一个任务把盘写满

Agent 如果陷入死循环，可能会疯狂写文件。没有配额限制的话，整个宿主机都可能被拖垮。

overlayfs 本身不直接支持配额，但可以给 upperdir 所在的文件系统设配额，或者用 loop 设备挂一个固定大小的文件作为 upperdir。后者更灵活，每个任务一个 loop 设备，大小固定，写满就报错，不会影响别人。

6.5 性能调优：什么时候该合并，什么时候该丢弃

工作层积累太多小文件之后，合并视图的读取会变慢。因为每次读文件都要从上往下逐层查找，层数越多越慢。

经验值是工作层里的文件数超过一万，或者层数超过五层，就该考虑合并了。合并的时机一般选在任务空闲的时候，避免影响正在执行的任务。

另外，如果某个任务已经确定不会再回退到早期状态，可以主动触发一次合并，把工作层压扁，减少层数。

7. 回到最初的问题：为什么值得重造一遍

聊到这里，最初那个问题的答案应该比较清楚了。不是现成的沙箱不能用，而是现成沙箱的设计目标和使用场景，和 Agent 的需求对不上。

传统沙箱是"防御性"的，核心诉求是隔离和限制。Agent 沙箱是"生产性"的，核心诉求是可回溯、可观测、可迭代。这两个目标虽然都涉及隔离，但侧重点完全不同。硬把 Agent 塞进传统沙箱，就像用保险柜当工作台，安全是安全了，但干活极其别扭。

overlayfs 提供的分层和写时复制能力，恰好匹配了 Agent 迭代执行的工作模式。基于它构建的沙箱，能让 Agent 在一个连续但又可控的环境里反复试错，每次执行都有清晰的边界和完整的记录。这种"既连续又隔离"的特性，是通用沙箱方案给不了的。

我在实际项目里的体会是，Agent 沙箱这件事，难点从来不在文件系统本身，overlayfs 的用法就那么些。真正花时间的是那些边角情况：挂载点泄漏怎么防，并发怎么隔离，结果怎么收集，资源怎么回收。这些东西没有标准答案，得根据自己项目的实际负载慢慢调。

如果你正准备给自己的 Agent 项目搭一套执行环境，我的建议是先用最小方案跑起来，三层结构加一个简单的执行器，能跑通就行。然后根据实际遇到的问题逐步加东西，需要缓存加缓存，需要配额加配额，需要并发隔离加隔离。别一上来就设计一个大而全的架构，Agent 这个领域变化太快，过度设计的东西很可能还没用上就过时了。

最后分享一个小技巧：给每个工作层起名的时候带上时间戳和任务 ID，这样出问题的时候一眼就能看出是哪个任务哪一轮的残留，清理起来心里有数。这个习惯帮我省了不少排查时间。