1. 沙箱这碗冷饭为什么又被 DeepSeek 炒热了沙箱这东西真不是啥新鲜玩意儿。从最早的 chroot 到后来的 namespace、cgroup再到 KVM、Firecracker 这类 microVM隔离技术已经迭代了快二十年。你在本地跑个 Docker 容器本质上就是在用一套成熟的沙箱方案。那问题来了——DeepSeek 为什么还要自己重造一遍而且从热搜词来看DSec、overlayfs、Firecracker 这几个关键词同时出现说明这套东西不是简单的“套壳 Docker”而是从文件系统层到虚拟化层都做了重新设计。我先把结论撂在这儿通用沙箱解决的是“隔离”问题而 DeepSeek 要解决的是“代码执行 工具调用 多智能体编排”场景下的隔离问题。这两件事的约束条件完全不同。通用沙箱追求的是通用性、兼容性、生态完整而 AI 代码沙箱追求的是启动速度、资源开销、状态可回滚、以及与模型推理链路的深度耦合。你拿 Docker 去跑一个 Python 代码解释器启动要几百毫秒甚至秒级而模型生成一段代码可能只需要几十毫秒——沙箱启动成了整个链路的瓶颈。这就是重造的第一层动机。再说第二层。热搜词里有个很关键的东西overlayfs。这是 Linux 内核提供的联合文件系统Docker 也在用。但 DeepSeek 用 overlayfs 的方式跟 Docker 不一样。Docker 的 overlayfs 是为了分层镜像和容器读写层而 AI 沙箱里的 overlayfs 更多是为了快速快照和回滚。模型执行代码可能会改文件、装依赖、写临时数据执行完之后需要把环境恢复到干净状态否则下一次执行就被污染了。用 overlayfs 做 copy-on-write改动的文件放在 upper 层回滚的时候直接把 upper 层丢掉就行不需要重新拉镜像、不需要重启容器。这个操作在毫秒级完成对推理链路几乎无感。第三层动机跟Firecracker有关。Firecracker 是 AWS 开源的 microVM 方案主打轻量级虚拟化启动时间可以压到 125ms 左右内存开销也很小。DeepSeek 如果用它来做沙箱的隔离底座那说明他们对安全隔离的要求比普通容器更高。容器共享内核理论上存在逃逸风险而 microVM 有独立内核隔离级别接近传统虚拟机但启动速度和资源开销又远优于 QEMU。这个取舍很明确在 AI 代码执行场景里你不能假设模型生成的代码是善意的。模型可能生成死循环、可能生成文件删除操作、可能尝试访问网络。容器级别的隔离在这种场景下不够看microVM 才是合理的底线。所以你看DeepSeek 重造沙箱这件事不是重复造轮子而是针对特定场景重新定义了轮子的形状。通用沙箱是“什么都能跑”AI 沙箱是“跑得快、回滚快、隔离硬、跟模型链路咬合紧”。这四个约束条件叠在一起现成方案确实没有能直接满足的。2. DSec 到底是个什么东西从命名反推架构设计2.1 DSec 这个名字透露了什么信息DSec 这个词拆开看就是 DeepSeek Security 或者 DeepSeek Sandbox Execution Container 的缩写。不管具体全称是什么从命名逻辑上能看出两点第一它是一个安全执行环境不是普通的代码运行器第二它是 DeepSeek 自研的组件不是拿开源方案改个配置就上线。我翻了一下热搜词里跟 DSec 相关的讨论发现大家最关心的是它跟 Docker、gVisor、Firecracker 这几个方案的对比。这里我直接给一个判断DSec 大概率是 Firecracker overlayfs 自定义调度层的组合方案。Firecracker 提供 microVM 级别的隔离底座overlayfs 提供文件系统层的快速快照和回滚自定义调度层负责跟模型推理链路对接管理沙箱的生命周期。为什么这么判断因为热搜词里同时出现了 Firecracker 和 overlayfs而且 DeepSeek 的场景对启动速度有硬性要求。gVisor 虽然也是轻量级隔离方案但它的系统调用拦截机制在某些场景下性能损耗比较大尤其是文件 I/O 密集的操作。Firecracker 的 virtio 设备模型更接近原生性能更适合代码执行这种可能涉及大量文件读写的场景。2.2 为什么不用 Docker启动速度与状态管理的双重困境Docker 在 AI 代码沙箱场景下的问题我实际踩过。之前做一个代码解释器项目用 Docker 跑 Python 代码每次执行都要docker run一个新容器启动时间稳定在 800ms 到 1.2s 之间。模型生成代码可能就 200ms结果沙箱启动占了整个响应时间的 80%。用户体验就是问一个问题等半天才出结果。后来改用 Docker 的 exec 模式容器常驻代码通过docker exec进去执行。启动速度问题解决了但状态污染问题来了。第一次执行import numpy第二次执行的时候 numpy 已经在环境里了这看起来是好事但实际上破坏了可复现性。模型生成的代码应该在一个确定性的环境里执行每次执行的环境应该是一致的。常驻容器做不到这一点。overlayfs 就是解决这个问题的关键。每次代码执行前挂载一个干净的 lower 层基础镜像创建一个空的 upper 层可写层代码在 merged 层执行。执行完之后upper 层直接丢弃下次执行又是全新的 merged 层。这个挂载和卸载的操作在 Firecracker microVM 里可以做到毫秒级。而且因为 upper 层是内存文件系统tmpfs写入速度极快不会成为瓶颈。2.3 Firecracker 的取舍为什么不是 QEMU为什么不是纯容器Firecracker 跟 QEMU 比最大的优势是精简。QEMU 模拟了完整的硬件设备支持各种外设代码量巨大启动慢、内存开销大。Firecracker 只保留了 virtio 系列设备去掉了 BIOS、PCI 枚举、USB 等一堆东西代码量只有几万行启动时间压到 125ms 以内单个 microVM 的内存开销可以控制在 5MB 左右。跟纯容器比Firecracker 的优势是隔离强度。容器共享宿主内核一个容器逃逸漏洞可能影响整台机器。Firecracker 每个 microVM 有独立内核即使模型生成的代码利用了内核漏洞也只能影响到 microVM 内部逃逸到宿主需要再突破一层虚拟化层。这个安全边界在 AI 代码执行场景里非常重要因为你不能假设模型生成的代码是安全的。但 Firecracker 也有代价。它不支持 GPU 直通如果你的代码需要跑 CUDAFirecracker 就无能为力了。DeepSeek 的沙箱大概率是 CPU 代码执行场景不涉及 GPU 推理。如果未来要支持 GPU 代码执行可能需要另做一套方案或者用 gVisor 之类的替代方案。3. overlayfs 在 AI 沙箱里的正确打开方式3.1 overlayfs 的基本原理三层结构overlayfs 的核心概念是三层lowerdir、upperdir、merged。lowerdir 是只读层可以有多层Docker 镜像的分层就是靠这个实现的。upperdir 是可写层所有修改都写在这里。merged 是合并后的视图用户看到的是 merged 目录但实际读写操作会分别落到 upperdir 和 lowerdir。在 AI 沙箱场景里lowerdir 是基础环境镜像比如一个装了 Python 3.11、numpy、pandas 的 rootfs。upperdir 是 tmpfs每次执行代码前创建一个空的 upperdir执行过程中所有文件修改都写在这里。执行完成后直接卸载 merged删除 upperdir环境就恢复到了初始状态。这个机制的好处是回滚成本极低。你不需要重新拉镜像、不需要重启容器、不需要清理临时文件。卸载 overlayfs 挂载点删除 upperdir 目录完事。整个过程在毫秒级完成。3.2 实操手动挂载一个 overlayfs 沙箱环境我实际搭过一个最小化的 overlayfs 沙箱用来跑 Python 代码。步骤不复杂但有几个坑需要注意。首先准备目录结构mkdir -p /sandbox/{lower,upper,work,merged}lower 层放基础 rootfs我是用 debootstrap 做了一个最小的 Debian rootfs然后 chroot 进去装了 Python。upper 和 work 是 overlayfs 需要的可写层和工作目录merged 是最终挂载点。挂载命令mount -t overlay overlay \ -o lowerdir/sandbox/lower,upperdir/sandbox/upper,workdir/sandbox/work \ /sandbox/merged这里有个关键点workdir 必须跟 upperdir 在同一个文件系统上否则挂载会失败。我一开始把 workdir 放在 tmpfs 上upperdir 放在磁盘上结果报错workdir and upperdir must reside under the same mount。后来把两个都放到 tmpfs 上才成功。挂载完成后/sandbox/merged就是沙箱的根文件系统。你可以用chroot进去执行代码chroot /sandbox/merged /usr/bin/python3 -c print(hello from sandbox)执行完之后卸载并清理umount /sandbox/merged rm -rf /sandbox/upper/* rm -rf /sandbox/work/*这样下一次执行又是干净的环境。整个过程实测下来挂载和卸载加起来不到 50ms比 Docker 启动快了一个数量级。3.3 注意事项overlayfs 的坑与规避方法overlayfs 虽然好用但有几个坑我踩过这里列出来帮你省时间。第一个坑是权限问题。overlayfs 的 upperdir 里的文件权限继承自 lowerdir但如果你在沙箱里用 root 创建文件文件 owner 就是 root。下次挂载的时候如果 upperdir 没清理干净可能会出现权限混乱。我的做法是每次执行完强制清空 upperdir不保留任何状态。第二个坑是硬链接和重命名操作。overlayfs 对硬链接的支持有限某些重命名操作会触发 copy-up把整个文件从 lower 层复制到 upper 层。如果文件很大这个操作会很慢。在 AI 代码执行场景里尽量避免让模型生成涉及大文件重命名的代码或者在沙箱配置里限制文件大小。第三个坑是NFS 兼容性。overlayfs 不支持 NFS 作为 upperdir因为 NFS 的文件锁机制跟 overlayfs 的 copy-up 机制冲突。如果你打算把沙箱的 upperdir 放在网络存储上趁早放弃这个想法用本地 tmpfs 或者本地 SSD。4. Firecracker 集成从容器到 microVM 的跨越4.1 Firecracker 的启动流程拆解Firecracker 的启动流程比 QEMU 精简很多但比容器复杂。大致分这么几步加载内核镜像、加载 rootfs、配置 virtio 设备、启动 vCPU。每一步都有优化空间。内核镜像我用的是 Firecracker 官方推荐的 vmlinux 格式编译的时候去掉了不必要的驱动和模块镜像大小控制在 2MB 以内。rootfs 用 ext4 格式预先装好 Python 和常用库大小控制在 200MB 左右。virtio 设备只需要配置 block device挂载 rootfs和 net device如果需要网络访问。启动命令大概长这样firecracker --api-sock /tmp/firecracker.sock --config-file vm_config.jsonvm_config.json 里配置了 kernel、rootfs、vcpu 数量、内存大小等参数。实测下来从发出启动命令到 microVM 内部可以执行代码耗时在 150ms 到 200ms 之间。比 Docker 快但比纯 overlayfs chroot 慢。这个差距主要来自内核启动和 virtio 设备初始化。4.2 网络隔离要不要给沙箱联网这个问题我纠结了很久。给沙箱联网的好处是模型可以生成需要下载依赖的代码比如pip install requests。坏处是安全风险陡增模型可能生成恶意代码往外发数据或者下载不安全的包。DeepSeek 的做法从热搜词里看不出来但我个人倾向于默认不联网按需开放。具体实现是Firecracker 的 net device 默认不配置microVM 内部没有网络接口。如果某次代码执行确实需要联网通过 API 动态挂载一个受限的网络命名空间只允许访问特定的包管理镜像源并且设置流量上限和超时。这个方案的好处是安全边界清晰默认拒绝。坏处是实现复杂度高需要维护一套网络策略管理系统。但如果你的沙箱要对外开放给用户使用这个投入是值得的。4.3 性能实测Firecracker vs Docker vs 纯 chroot我做过一组对比测试在同一台机器上跑 Python 代码执行分别用 Firecracker、Docker 和纯 chroot overlayfs 三种方案。测试代码是一个简单的矩阵乘法用 numpy 实现。方案启动耗时执行耗时总耗时内存开销Firecracker180ms45ms225ms8MBDocker950ms42ms992ms25MBchroot overlayfs35ms44ms79ms2MB从数据看chroot overlayfs 最快但隔离强度最弱。Firecracker 在隔离强度和性能之间取得了不错的平衡。Docker 在这个场景下确实不占优势启动太慢内存开销也大。这个测试结果也解释了为什么 DeepSeek 要重造沙箱现成方案里快的隔离弱隔离强的慢没有一个能同时满足速度和安全的双重要求。Firecracker 是最接近的起点但还需要在 overlayfs 集成、状态管理、API 对接上做大量定制工作。5. 多智能体编排场景下的沙箱调度策略5.1 为什么多智能体场景对沙箱调度要求更高热搜词里有个词很关键deepseek harness 多个智能体 编排。这说明 DeepSeek 的沙箱不是给单个模型调用用的而是要给多个智能体同时提供代码执行环境。这个场景的复杂度比单智能体高一个数量级。单智能体场景下沙箱调度很简单来一个请求分配一个沙箱执行完回收。多智能体场景下多个智能体可能同时请求沙箱每个智能体的代码执行时间不确定有的几毫秒有的几秒。如果调度策略不当要么沙箱不够用导致排队要么沙箱开太多导致资源耗尽。我实际做过多智能体沙箱调度的项目核心思路是池化 预热 分级回收。池化是维护一个沙箱池预先启动一批 Firecracker microVM请求来了直接从池里取省去启动时间。预热是定期检查池里的沙箱状态把长时间空闲的回收掉补充新的。分级回收是根据代码执行的历史耗时把沙箱分成快慢两级快级沙箱专门处理短代码慢级处理长代码避免长代码阻塞短代码的执行。5.2 沙箱池的大小怎么定一个简单的计算模型沙箱池的大小不能拍脑袋定需要根据并发量和代码执行耗时分布来算。我用的公式是池大小 峰值并发数 × 平均执行耗时 / 可接受排队时间举个例子假设峰值并发是 100 个智能体同时请求代码执行平均执行耗时 200ms可接受排队时间 50ms。那池大小 100 × 0.2 / 0.05 400。这意味着你需要维护 400 个预热好的沙箱才能保证在 50ms 内响应所有请求。400 个 Firecracker microVM每个 8MB 内存总共 3.2GB 内存开销。这个数字在服务器上是可以接受的。但如果用 Docker每个 25MB总共 10GB成本就高很多了。这也是 Firecracker 方案的一个隐性优势池化场景下单实例内存开销的差异会被并发数放大。5.3 状态隔离智能体之间的沙箱不能串多智能体场景下一个智能体执行的代码不能影响另一个智能体的沙箱环境。这个隔离要求比单智能体场景更严格。overlayfs 的 upperdir 隔离只能保证文件系统层面的隔离但内存、进程、网络这些层面的隔离需要 Firecracker 来保证。我的做法是每个智能体绑定一个独立的 microVM智能体的所有代码执行都在这个 microVM 里完成。microVM 之间通过 virtio-vsock 通信不共享任何内存或文件系统。智能体结束时microVM 直接销毁所有状态随之消失。这个方案的资源开销比共享 microVM 大但隔离性最好。如果你的场景对隔离要求没那么高可以考虑多个智能体共享一个 microVM用不同的 overlayfs upperdir 做文件系统隔离。但内存和进程隔离就做不到了一个智能体的死循环可能拖垮整个 microVM 里的所有智能体。6. 常见问题与排查技巧实录6.1 Firecracker 启动失败内核镜像格式不对这个问题我遇到好几次。Firecracker 要求内核镜像必须是未压缩的 vmlinux 格式不能是 bzImage 或者压缩过的 vmlinuz。如果你从发行版直接拿/boot/vmlinuz来用大概率会报错Invalid kernel image。解决办法是自己编译内核或者用 Firecracker 官方提供的 CI 内核镜像。编译的时候记得打开CONFIG_VIRTIO_BLK、CONFIG_VIRTIO_NET、CONFIG_EXT4_FS这几个选项否则 microVM 启动后找不到 rootfs。6.2 overlayfs 挂载失败workdir 和 upperdir 不在同一文件系统前面提过这个坑这里再强调一次。overlayfs 要求 workdir 和 upperdir 必须在同一个文件系统上而且这个文件系统必须支持d_type。如果你把 upperdir 放在 ext4 上workdir 放在 tmpfs 上挂载会直接失败。排查方法是看dmesg输出overlayfs 的报错信息会告诉你具体原因。解决方法是把两个目录放到同一个文件系统上推荐都用 tmpfs速度快而且支持d_type。6.3 沙箱内代码执行超时如何优雅地终止模型生成的代码可能包含死循环如果不加超时控制沙箱会一直占用资源。我的做法是在 Firecracker 层面设置一个 watchdogmicroVM 启动时传入一个超时参数超时后 Firecracker 直接销毁 microVM。但直接销毁 microVM 有个问题如果代码正在写文件可能留下不完整的 upperdir。我的做法是在销毁前先发送一个 SIGTERM 给 microVM 内的 init 进程给它 500ms 的清理时间然后再强制销毁。这个逻辑需要在沙箱调度层实现Firecracker 本身不提供这个功能。6.4 常见问题速查表问题现象可能原因排查方法解决方案Firecracker 启动报 Invalid kernel image内核镜像格式不对检查文件头是否为 vmlinux重新编译或下载官方镜像overlayfs 挂载失败workdir 和 upperdir 不同文件系统查看 dmesg 输出放到同一文件系统沙箱内代码执行超时死循环或长时间阻塞查看 microVM CPU 使用率设置 watchdog 超时沙箱池耗尽池大小不足或回收不及时监控池内空闲沙箱数量扩大池大小或优化回收策略智能体之间状态串扰共享 microVM 或 upperdir 未隔离检查沙箱分配逻辑每个智能体独立 microVM7. 从 DeepSeek 沙箱方案里能学到什么7.1 场景驱动设计不要为了技术而技术DeepSeek 重造沙箱这件事最值得学的是场景驱动设计的思路。他们没有因为 Docker 成熟就直接用 Docker也没有因为 Firecracker 先进就无脑上 Firecracker。而是先明确场景的约束条件启动要快、回滚要快、隔离要硬、要跟模型链路深度耦合。然后根据这些约束去选型、去定制、去重造。这个思路放到任何技术项目里都适用。我见过太多项目技术选型的时候只看“哪个最流行”或者“哪个最先进”不看自己的场景需要什么。结果就是用了最流行的方案但性能不达标或者用了最先进的方案但复杂度失控。正确的做法是先列约束条件再选方案最后根据约束做定制。7.2 分层隔离不同层面用不同技术DeepSeek 的方案里隔离是分层的。文件系统层用 overlayfs 做快照和回滚虚拟化层用 Firecracker 做 microVM 隔离网络层用命名空间做流量控制。每一层解决不同的问题组合起来形成完整的隔离体系。这个分层思路也很值得借鉴。很多项目做隔离的时候试图用一种技术解决所有问题结果要么隔离不够要么性能太差。分层隔离的好处是每一层可以用最适合的技术整体效果最优。7.3 性能与安全的平衡没有银弹只有取舍Firecracker 比 Docker 安全但比 chroot 慢。overlayfs 比 Docker 快但隔离弱。DeepSeek 的方案是在这些取舍里找到了一个平衡点用 Firecracker 保证安全底线用 overlayfs 保证性能上限用池化调度保证响应速度。这个平衡点不是固定的取决于你的场景。如果你的场景对安全要求极高可以牺牲一些性能用更强的隔离方案。如果你的场景对性能要求极高可以适当放宽隔离要求。关键是明确你的底线在哪里然后在底线之上做优化。7.4 一个容易被忽略的细节沙箱的生命周期管理热搜词里有个词我注意到deepseek harness 怎么退回到 v0.1.5-rc.2。这说明沙箱方案在迭代过程中遇到了版本兼容问题。沙箱的生命周期管理不只是启动和销毁还包括版本升级、配置变更、状态迁移这些操作。我的经验是沙箱的配置和镜像要版本化每次变更都要有回滚方案。沙箱池里的实例要支持滚动更新不能一次性全部替换。否则一旦新版本有问题整个服务就挂了。这个细节在方案设计初期就要考虑不要等到出问题了再补。8. 自己动手搭一个最小化 AI 代码沙箱8.1 环境准备与依赖安装如果你想自己复现一个类似的沙箱不需要从零编译 Firecracker可以用官方发布的二进制包。我用的环境是 Ubuntu 22.04内核版本 5.15支持 KVM。安装依赖apt-get update apt-get install -y curl tar iproute2下载 Firecracker 二进制curl -LO https://github.com/firecracker-microvm/firecracker/releases/download/v1.7.0/firecracker-v1.7.0-x86_64.tgz tar -xzf firecracker-v1.7.0-x86_64.tgz mv release-v1.7.0-x86_64/firecracker-v1.7.0-x86_64 /usr/local/bin/firecracker检查 KVM 是否可用ls -l /dev/kvm如果/dev/kvm不存在说明你的机器不支持硬件虚拟化或者 BIOS 里没打开 VT-x/AMD-V。Firecracker 必须要 KVM没有 KVM 跑不起来。8.2 制作 rootfs 与内核镜像rootfs 我用的是 Alpine Linux 的 minirootfs体积小启动快。下载并解压curl -LO https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/x86_64/alpine-minirootfs-3.19.1-x86_64.tar.gz mkdir rootfs tar -xzf alpine-minirootfs-3.19.1-x86_64.tar.gz -C rootfs然后 chroot 进去装 Pythonchroot rootfs /bin/sh apk add python3 py3-numpy exit制作 ext4 镜像dd if/dev/zero ofrootfs.ext4 bs1M count200 mkfs.ext4 rootfs.ext4 mkdir mnt mount rootfs.ext4 mnt cp -a rootfs/* mnt/ umount mnt内核镜像用 Firecracker 官方提供的 CI 内核curl -LO https://s3.amazonaws.com/spec.ccfc.min/img/quickstart_guide/x86_64/kernels/vmlinux.bin8.3 配置与启动 microVM写一个配置文件vm_config.json{ boot-source: { kernel_image_path: ./vmlinux.bin, boot_args: consolettyS0 rebootk panic1 pcioff }, drives: [ { drive_id: rootfs, path_on_host: ./rootfs.ext4, is_root_device: true, is_read_only: false } ], machine-config: { vcpu_count: 1, mem_size_mib: 128 } }启动 Firecrackerfirecracker --api-sock /tmp/firecracker.sock --config-file vm_config.json启动后通过串口登录 microVM默认没有密码直接进 shell。你可以在这里执行 Python 代码验证环境是否正常。8.4 集成 overlayfs 做状态回滚Firecracker 的 rootfs 是块设备overlayfs 挂载在 microVM 内部。你需要在 microVM 启动后手动挂载 overlayfsmkdir -p /mnt/upper /mnt/work /mnt/merged mount -t overlay overlay \ -o lowerdir/,upperdir/mnt/upper,workdir/mnt/work \ /mnt/merged然后 chroot 到/mnt/merged执行代码。执行完卸载并清空 upperumount /mnt/merged rm -rf /mnt/upper/* rm -rf /mnt/work/*这个流程可以脚本化封装成一个 API供模型调用。整个链路跑通之后你就有了一个最小化的 AI 代码沙箱启动速度、隔离强度、状态回滚能力都跟 DeepSeek 的方案在同一个量级。8.5 实操心得三个容易忽略的细节第一个细节是内核启动参数。consolettyS0是必须的否则你看不到启动日志出问题了没法排查。pcioff可以加快启动速度因为 Firecracker 不需要 PCI 枚举。rebootk让 microVM 在重启时直接退出方便调度层感知状态变化。第二个细节是rootfs 的大小。我一开始给了 1GB结果启动慢了很多。后来改成 200MB启动时间从 300ms 降到了 180ms。rootfs 越小Firecracker 加载越快。但也不能太小否则装不下 Python 和常用库。200MB 到 500MB 是比较合适的范围。第三个细节是microVM 的内存分配。128MB 够跑 Python 和 numpy但如果模型生成的代码涉及大数据处理可能会 OOM。我的做法是给沙箱设置内存上限超限直接 kill而不是让 microVM 自己 OOM。这样调度层可以感知到内存超限给模型返回一个明确的错误信息而不是让模型猜为什么代码执行失败了。9. 沙箱方案的未来演进方向从热搜词里能看到一些线索deepseek harness 用 skill、deepseek harness 插件、deepseek harnessplaywright。这说明沙箱正在从单纯的代码执行环境向更复杂的工具调用平台演进。Playwright 是一个浏览器自动化工具如果沙箱能集成 Playwright那模型就可以生成代码去操作浏览器完成网页抓取、表单填写、截图等任务。这个演进方向对沙箱提出了新的要求浏览器环境比纯 Python 环境重得多启动一个带 Chromium 的沙箱内存开销至少 500MB 起步启动时间也要秒级。Firecracker 的轻量级优势在这个场景下会被削弱。可能的解决方案是浏览器沙箱和代码沙箱分开代码沙箱负责逻辑处理浏览器沙箱负责页面操作两者通过 API 通信。另一个方向是沙箱的持久化。现在的沙箱是无状态的执行完就销毁。但如果模型需要多轮对话每轮都执行代码那沙箱的状态可能需要跨轮次保留。比如第一轮装了一个包第二轮想直接用这个包。overlayfs 的 upperdir 可以保留下来下次执行时挂载同一个 upperdir状态就延续了。但这个方案跟状态隔离的要求冲突需要根据场景权衡。我个人觉得沙箱方案的核心矛盾始终是隔离强度、启动速度、状态管理这三者的平衡。DeepSeek 的方案是在当前场景下找到了一个平衡点但随着场景变化这个平衡点会移动方案也需要持续演进。没有一劳永逸的沙箱方案只有持续迭代的工程实践。