企业官网建设流程全解析

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 直通，如果你的代码需要跑 CUDA，Firecracker 就无能为力了。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.json

vm_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 实现。

从数据看，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 层面设置一个 watchdog，microVM 启动时传入一个超时参数，超时后 Firecracker 直接销毁 microVM。

但直接销毁 microVM 有个问题：如果代码正在写文件，可能留下不完整的 upperdir。我的做法是在销毁前先发送一个 SIGTERM 给 microVM 内的 init 进程，给它 500ms 的清理时间，然后再强制销毁。这个逻辑需要在沙箱调度层实现，Firecracker 本身不提供这个功能。

6.4 常见问题速查表

7. 从 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 进去装 Python：

chroot rootfs /bin/sh apk add python3 py3-numpy exit

制作 ext4 镜像：

dd if=/dev/zero of=rootfs.ext4 bs=1M count=200 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.bin

8.3 配置与启动 microVM

写一个配置文件vm_config.json：

{ "boot-source": { "kernel_image_path": "./vmlinux.bin", "boot_args": "console=ttyS0 reboot=k panic=1 pci=off" }, "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 } }

启动 Firecracker：

firecracker --api-sock /tmp/firecracker.sock --config-file vm_config.json

启动后通过串口登录 microVM，默认没有密码，直接进 shell。你可以在这里执行 Python 代码，验证环境是否正常。

8.4 集成 overlayfs 做状态回滚

Firecracker 的 rootfs 是块设备，overlayfs 挂载在 microVM 内部。你需要在 microVM 启动后，手动挂载 overlayfs：

mkdir -p /mnt/upper /mnt/work /mnt/merged mount -t overlay overlay \ -o lowerdir=/,upperdir=/mnt/upper,workdir=/mnt/work \ /mnt/merged

然后 chroot 到/mnt/merged执行代码。执行完卸载并清空 upper：

umount /mnt/merged rm -rf /mnt/upper/* rm -rf /mnt/work/*

这个流程可以脚本化，封装成一个 API，供模型调用。整个链路跑通之后，你就有了一个最小化的 AI 代码沙箱，启动速度、隔离强度、状态回滚能力都跟 DeepSeek 的方案在同一个量级。

8.5 实操心得：三个容易忽略的细节

第一个细节是内核启动参数。console=ttyS0是必须的，否则你看不到启动日志，出问题了没法排查。pci=off可以加快启动速度，因为 Firecracker 不需要 PCI 枚举。reboot=k让 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 harness+playwright。这说明沙箱正在从单纯的代码执行环境，向更复杂的工具调用平台演进。Playwright 是一个浏览器自动化工具，如果沙箱能集成 Playwright，那模型就可以生成代码去操作浏览器，完成网页抓取、表单填写、截图等任务。

这个演进方向对沙箱提出了新的要求：浏览器环境比纯 Python 环境重得多，启动一个带 Chromium 的沙箱，内存开销至少 500MB 起步，启动时间也要秒级。Firecracker 的轻量级优势在这个场景下会被削弱。可能的解决方案是浏览器沙箱和代码沙箱分开，代码沙箱负责逻辑处理，浏览器沙箱负责页面操作，两者通过 API 通信。

另一个方向是沙箱的持久化。现在的沙箱是无状态的，执行完就销毁。但如果模型需要多轮对话，每轮都执行代码，那沙箱的状态可能需要跨轮次保留。比如第一轮装了一个包，第二轮想直接用这个包。overlayfs 的 upperdir 可以保留下来，下次执行时挂载同一个 upperdir，状态就延续了。但这个方案跟状态隔离的要求冲突，需要根据场景权衡。

我个人觉得，沙箱方案的核心矛盾始终是隔离强度、启动速度、状态管理这三者的平衡。DeepSeek 的方案是在当前场景下找到了一个平衡点，但随着场景变化，这个平衡点会移动，方案也需要持续演进。没有一劳永逸的沙箱方案，只有持续迭代的工程实践。