Agent 沙箱技术核心架构方案（完整版）：七层架构全解 · 证据台账 · 口径校准 · 误判澄清 - AI 资讯

主题：AI Agent 代码执行沙箱（Sandbox）的核心架构设计与工程方案缘起：基于视频《为什么沙箱成了 AI 圈最卷的新基建》（小白debug，https://www.youtube.com/watch?v=iD_2QFur7Q4）的深度延伸调研 报告日期：2026-09-29 ｜ 信息截止时点：2026-09-29 研究方式：视频转录 + 多源联网调研（官方文档 / 学术论文 / 工程博客 / 云厂商文档），证据分级标注 证据分级：A=官方确认｜ B=权威二手/多源一致｜ C=第三方单源｜ D=推测

本文为完整版（含研究方法、逐条证据台账、口径冲突清单、常见误判澄清表、渐进式落地路线与完整参考文献）。精简版见：深度研究｜Agent 沙箱技术核心架构方案：从 microVM 隔离到硬件加速快照的七层设计

执行摘要

Agent 沙箱的本质，是为「不可信的、由大模型即时生成的代码」提供一次性的、可重置的、权限受限的执行环境。它要同时满足四个互相拉扯的约束：强隔离、快启动、高密度、可持久。本方案给出的核心结论：

隔离边界必须落在内核层，而非应用层。 容器共享宿主内核，一旦内核逃逸即影响整机；业界共识路径是 microVM（独立 guest kernel）+ 镜像，典型实现为 Firecracker（约 5 万行 Rust，对比 QEMU 约 140 万行 C）。【A】
"快"的关键不是把启动做快，而是"不启动"。 结构性方案是 快照恢复（snapshot-restore）：冷启动一次（约 3 秒/模板）→ 快照 → 每次请求恢复（数十毫秒）。这是数量级的优化，其余五类技巧都是在此之上的精修。【B】
快照的瓶颈从"启动"转移到"压缩/解压"。 快照动辄数百 MB～数 GB，压缩解压是纯 CPU 计算，会挤占 Agent 执行算力。解法是硬件加速：Intel IAA（存内分析加速器）以硬件 DEFLATE 承担压缩解压，OSDI 2024 论文 Sabre 证明其可将快照压缩 2.5–4 倍、冷启动最高降低 60%。【A】
规模化沙箱平台不是"更好的单机运行时"，而是"弹性执行平台"。 DeepSeek DSec 的公开数据：单生产单元约 160 节点、日均 300 万沙箱、稳态并发 38 万+、创建速率 5000+/秒。支撑它的是四件事：后端分级、分层镜像 + 按需加载、高密度超卖、与 RL 训练协同。【A】
安全不能只靠"隔离计算"，必须叠加"隔离网络与数据"。 NVIDIA AI 红队把 默认拒绝出网、禁止工作区外写文件、禁止写配置文件列为强制性控制；仅做计算隔离而不控出网，等于"关住了进程，关不住进程的后果"。【A】
沙箱正在从"产品能力"沉淀为"基础设施标准"。 2025 年 11 月，Kubernetes SIG Apps 正式立项 Agent Sandbox 子项目，用 Sandbox/SandboxTemplate/SandboxClaim/SandboxWarmPool 四个 CRD 把这一模式标准化，隔离后端可插拔（gVisor / Kata）。【A】

一句话架构总纲：以 microVM 为隔离边界，以快照恢复为启动路径，以分层镜像 + 按需加载为分发方式，以硬件加速为压缩解压引擎，以分级调度为密度手段，以默认拒绝为安全基线，以 K8s CRD 为编排接口。

研究方法与证据分级

本报告采用「官方优先 + 学术论文锚定 + 多源交叉」的取证方式。信源质量警示：

官方一手（A 级）：Firecracker 官方文档与 NSDI'20 论文、Intel IAA 产品页、OSDI'24 Sabre 论文、DeepSeek DSec arXiv 报告、Kubernetes Agent Sandbox 官方文档、E2B 官网、NVIDIA 开发者博客、Google 开源博客。
权威二手 / 工程实践（B 级）：Northflank 技术博客、PandaStack 工程博客、walkinglabs《hands-on-modern-rl》工业训练附录。
需谨慎对待：视频口播中的具体数字（如"22%""55%""38–42%"）与论文口径存在差异，本报告已并列呈现（见"口径冲突清单"）。
本报告未采用任何无法交叉验证的自媒体"独家精确参数"。

1. 问题定义：Agent 为什么必须要有沙箱

1.1 与传统 LLM 推理的本质差异

普通 LLM 推理的产出是 token；Agent 的产出是对真实世界的动作——写文件、改数据库、发网络请求、起进程。这意味着：

维度	普通 LLM rollout	Agentic rollout
产出物	一段文本	文本 + 环境副作用
状态	无状态	有状态（多轮依赖上一步环境）
风险	幻觉、错误答案	删文件、泄密、RCE、逃逸
打分	文本比对	需在真实环境里跑测试验证

【B】walkinglabs 的工业训练附录给出了两个典型案例：Agent 发现"删掉本地测试文件后公开测试仍返回成功"（reward hacking），以及"读取工作目录 .env 并把信息写进答案"（数据外泄）——两条轨迹都能拿高奖励，但都没完成真实任务。

1.2 沙箱要同时满足的四个约束

        强隔离 ←──────冲突──────→ 快启动
          ↑                          ↑
          │        （四角拉扯）       │
      可持久 ←──────冲突──────→ 高密度

强隔离 vs 快启动：传统 VM 隔离强但启动数秒；容器快但共享内核。
高密度 vs 强隔离：每个沙箱独立内核 = 内存开销 × N。
可持久 vs 高密度：多轮任务状态不能丢，但长驻内存吃资源（DSec 中位寿命 17.4 分钟、p99 超 3 小时）。
快启动 vs 安全：每次工具调用都要新隔离环境 → 启动延迟直接进入 Agent 交互关键路径。

架构的全部设计张力，都来自这四个约束的平衡。 后续每一节，本质上都是在回答"如何在某个角上让步、又在另一个角上补回来"。

1.3 沙箱在系统中的位置

┌──────────┐   工具调用   ┌──────────┐   隔离执行   ┌──────────────────┐
│ 策略模型  │ ──────────→ │ 沙箱网关  │ ──────────→ │ 一次性沙箱        │
│ (GPU)    │ ←────────── │ (控制面)  │ ←────────── │ 代码/浏览器/DB    │
└──────────┘  观察/退出码  └──────────┘   结果回传    └──────────────────┘
                              │                          │
                              │                    轨迹与环境快照
                              ↓                          ↓
                        ┌──────────┐              ┌──────────┐
                        │ 调度器    │              │ 轨迹存储  │
                        └──────────┘              └──────────┘

【B】关键洞察："思考靠 GPU，执行靠 CPU"（视频原话）。GPU 决定 Agent 多聪明，CPU 决定能同时承载多少 Agent。沙箱平台是 CPU 密集型基础设施，与 GPU 训练集群是互补而非竞争关系。

2. 隔离层架构：从容器到 microVM 的分级

2.1 四种隔离方案的权衡

【A/B】综合 Firecracker NSDI'20 论文、Kata/gVisor 对比与工业实践，隔离方案可归纳为四级：

方案	隔离机制	启动时间	内存开销	攻击面	适用信任边界
subprocess + rlimit	进程级资源限制	~ms	极小	与宿主共享内核/文件	仅受信任代码、教学原型
容器（runc/Docker）	namespaces + cgroups	50–200ms	极小	共享宿主内核，逃逸影响整机	可信多租户、可复现评测
gVisor	用户态内核（Sentry）拦截 syscall	~ms	小	Sentry + 受限 syscall 集	无嵌套虚拟化环境、I/O 较轻
microVM（Firecracker）	KVM 硬件虚拟化 + 独立 guest kernel	100–200ms	<5 MiB	VMM（约 5 万行 Rust）+ jailer	多租户、不可信代码
完整 VM（QEMU）	完整硬件虚拟化	数秒	~131 MB	大 TCB（QEMU+KVM）	强隔离、低密度场景

2.2 为什么 microVM 成为主流选择

【A】Firecracker 的设计取舍（NSDI'20）：

极简设备模型：只实现 5 类 virtio 设备（net、block、vsock、serial console、最小键盘控制器），无 BIOS/UEFI、无 PCI 总线、无 VGA。
代码量对比：Firecracker ≈ 5 万行 Rust（内存安全）vs QEMU ≈ 140 万行 C。
性能指标：冷启动到 guest init ≤125ms（预配置）、端到端约 160–180ms；每主机创建速率最高 150 microVM/秒；内存开销 3–5 MiB/实例（与 guest 内存大小无关）。
安全纵深：jailer 进程（降权 + cgroups + namespaces）+ 按线程类型的 seccomp 过滤器。
线程模型：每 microVM 一个 Firecracker 进程，含 API 线程、VMM 线程、每 vCPU 一个 vCPU 线程。

2.3 隔离后端的分层选型策略

【A】DeepSeek DSec 的后端分级是规模化平台的关键设计——不是所有任务都上 microVM：

后端	隔离强度	开销	典型任务
FnCall	最低（函数调用级）	极低	单次工具调用（把"工具调用"也纳入平台审计/限流/重试）
容器	中	低	常规代码执行、评测
microVM	高	中	不可信代码、多租户
完整 VM（QEMU）	最高	高	需要完整 OS / 特殊内核

【A】论文明确指出：按威胁模型分后端，成本能差一个量级。这是"隔离分级"的核心工程价值。

2.4 隔离后端对比（工程视角）

【B】Northflank 的对比要点：

Kata Containers = 编排框架（非隔离技术本身），可接 Cloud Hypervisor（默认）/ Firecracker / QEMU，通过 CRI 原生集成 K8s，启动约 150–300ms，运维复杂度低。
Firecracker 直接使用 = 需自建内核镜像、rootfs、网络、jailer、生命周期管理，运维复杂度高，适合自建 serverless 平台。
gVisor = 无需嵌套虚拟化，集成简单，但 I/O 密集负载有 10–30% syscall 开销。

选型建议：多租户不可信代码 → Kata/Firecracker；无嵌套虚拟化 → gVisor；自建极速 serverless → Firecracker 直用。

3. 启动层架构：快照恢复是数量级的胜负手

3.1 核心洞察：最大的冷启动优化是"不启动"

【B】PandaStack 工程博客给出了清晰的排序——冷启动优化的第一优先级不是"让启动更快"，而是"不启动"：

快照恢复是结构性优化（秒级 → 数十毫秒）；其余五种技巧都是在此之上的精修。

冷启动 vs 快照恢复的本质差异：

冷启动：内核初始化 → 驱动探测 → init 拉起用户态 → 应用启动并监听端口。延迟随"内核+应用要做的准备工作量"缩放。
快照恢复：序列化运行中的 microVM 某一瞬间的全部 guest 物理内存（vm.mem）+ VMM 状态（vm.state：vCPU 寄存器、中断控制器、时钟、每个 virtio 设备配置），恢复时映射内存、从指令中间恢复 vCPU。内核已就绪、page cache 已热、进程已在监听。

3.2 快照机制的工程实现

【A】Firecracker 官方快照支持文档确认：快照包含 vm.state（VMM 状态）与 vm.mem（内存文件）两部分；恢复针对速度优化，创建快照需同步写内存页（额外 CPU 周期）。

【B】PandaStack 的实现数据（p50 179ms / p99 203ms）：

冷启动（每模板一次，约 3s）：
  firecracker --api-sock /run/fc.sock &
  PUT /boot-source, /drives/rootfs, /network-interfaces/eth0
  PUT /actions action_type=InstanceStart
  wait_for_app_ready

烘焙快照（一次）：
  PUT /snapshot/create snapshot_path=vm.state mem_file_path=vm.mem

热恢复（每次创建）：
  PUT /snapshot/load snapshot_path=vm.state mem_file_path=vm.mem   # 约数十 ms
  PUT /snapshot/state state=Resumed                                # vCPU 恢复

其中 snapshot-load 步骤本身约 49ms，整个 create（网络+磁盘+VMM 启动+load+resume+就绪探测）落在 179ms p50。

3.3 六项冷启动优化技术（按收益排序）

【B】PandaStack 归纳，越靠前收益越大：

#	技术	机制	收益
1	快照恢复替代冷启动	启动一次→快照→每次恢复	秒级 → 数十毫秒（数量级）
2	CoW rootfs（reflink）	XFS reflink 共享数据块，克隆 O(metadata)	磁盘阶段固定为个位数 ms，与镜像大小无关
3	MAP_PRIVATE 内存 + 惰性 page-in	内存文件私有映射，按需缺页	只付工作集（几百 MB）而非全部 RAM（2 GiB）
4	预热网络命名空间	预先建好 netns+veth+tap+iptables	省去约 100ms 冷建开销
5	极简内核 + 微型设备模型	无固件阶段、精简 virtio	降低冷启动下限，缩小快照工作集
6	userfaultfd / 按需内存流式	缺页时从对象存储按 4MiB 块拉取	新主机无需先下载数 GB vm.mem

关键约束：rootfs 必须保持本地文件（CoW 克隆需要本地块设备）；userfaultfd 流式仅适用于内存，不适用于磁盘。

3.4 快照的瓶颈转移：压缩/解压

【A】当快照规模上来后，瓶颈从"启动"转移到压缩/解压：

快照动辄数百 MB～数 GB，磁盘存储压力大。
存快照/恢复快照本质是磁盘↔内存搬运数 GB 数据，量一大速度就慢。
行业主流用软件压缩（ZSTD、LZ4），但压缩解压是纯 CPU 计算，会挤占 Agent 执行算力。

这正是视频中 Intel IAA 出场的背景。

4. 加速层架构：硬件加速快照压缩（Intel IAA）

4.1 IAA 是什么

【A】Intel IAA（In-Memory Analytics Accelerator，存内分析加速器）：

集成于 Intel 第四代及更新的至强（Xeon）可扩展处理器的片上加速器。
设计目标：卸载 CPU 的内存数据分析类操作（CRC64、expand、extract、scan、压缩/解压）。
内部模块：压缩、解压、过滤，可自由组合。
关键能力：支持多路独立数据源并行送入、按序流入对应硬件模块；支持常见 DEFLATE 算法。
硬件压缩比软件快 6.1–13.5 倍，解压约快一个数量级；多引擎并行可把压缩延迟降 4–7 倍、解压延迟最高降 17 倍。【A，来自 Sabre 论文刻画】

4.2 Sabre：把 IAA 接入 microVM 快照流程

【A】OSDI 2024 论文《Sabre: Hardware-Accelerated Snapshot Compression for Serverless MicroVMs》是首个公开的 IAA 内存页压缩刻画 + 面向 microVM 快照的系统设计：

核心设计：

快照创建（不在恢复关键路径，优先高压缩率）：先用 IAA Statistics 模式统计并生成 Huffman 表，再用 Canned/Static DEFLATE 压缩分散脏页，写入快照文件 + partition 文件（记录偏移、原始大小、压缩后大小）。
恢复时两种预取策略，按快照稀疏度运行时选择：
- single-chunk prefetching：分区视为连续区域，共享 mmap + PRS 读盘，IAA 解压到内存池，再用 userfaultfd 安装到 guest 物理内存（适合连续快照，有拷贝开销）。
- scattered prefetching：IAA 直接 DMA 到 guest 物理内存正确位置（适合稀疏快照，省拷贝但 DMA 管理开销高）。
可跨多个 IAA 引擎并行异步提交解压任务；IAA 流式解压与磁盘 I/O 重叠。

实现：C++17 + Intel QPL v1.3.1，约 3500 行，编译为动态库；仅约 50 行 Rust FFI 接入 Firecracker VMM v1.5.0；运行在 Firecracker 原有快照/恢复线程，不需额外 CPU。

评估结果：

场景	压缩率	性能
Firecracker 默认 Diff 脏页快照	最高 4×、平均 2.5×	解压不增端到端延迟，部分应用冷启动降最高 60%
REAP 工作集快照	最高 4.7×、平均 3.2×	预取提速 25–55%（python-list 达 70%），端到端冷启动最高改善 20%
对比软件 DEFLATE/Snappy/zstd/LZ4	—	软件解压抵消压缩收益；zstd 恢复接近 IAA 但快照创建耗大量 CPU
对比未压缩快照预取	—	Sabre 恢复最高快 1.9×

4.3 为什么"硬件加速"是架构级选择

【B】视频给出了架构层面的因果链：

沙箱开得越快 ──→ 模型训练越高效
    ↑
快照决定沙箱"开箱速度"
    ↑
IAA 决定快照"读写速度"
    ↑
压缩解压从 CPU 卸载到专用硬件 ──→ CPU 算力留给 Agent 执行与沙箱调度

架构含义：把"压缩解压"这类固定、独立、可固化的算法做成硬件单元，是典型的"让专用硬件做专用事"的卸载模式。在 Agent 时代，CPU 的稀缺性不在于"算得多快"，而在于"能同时承载多少个 Agent"。

4.4 备选与演进方向

【A】Sabre 论文指出的演进方向：

当前 IAA PRS 接入磁盘会经过 OS page cache，限制带宽 → 可用用户态缺页处理 + O_DIRECT + block-on-fault，或直连磁盘与 IAA DMA 引擎。
single-chunk 的 userfaultfd 拷贝可用 UFFDIO_CONTINUE 零拷贝改进。
可扩展到 CXL 内存、远程快照、VM live migration。

【B】其他硬件加速路径：AWS Graviton 优化 Agentic RL 沙箱层（基于 Graviton5 的 m9g 实例可将沙盒层成本降低多达 43%）。

5. 分发层架构：分层镜像与按需加载

5.1 问题：镜像语料庞大且复用率低

【A】DSec 论文指出 Agentic 训练负载的第四个反常特征：镜像语料庞大而复用率低——成千上万个任务环境各不相同，传统镜像缓存的命中率假设失效（本地缓存效果差）。

5.2 可组合分层环境

【A】DSec 的解法是把环境拆成独立版本化的层（类似 Nix 思路）：

┌─────────────────────────────┐
│  工具包层（toolkit）          │ ← 独立版本化，overlayfs 可写上层
├─────────────────────────────┤
│  工作区层（workspace）        │ ← 独立版本化
├─────────────────────────────┤
│  基础 OS 层（base image）     │ ← 独立版本化，EROFS 只读层
└─────────────────────────────┘

不同任务环境共享底层依赖层，差异只在顶层。
容器：动态挂载 EROFS lower layer + overlayfs 可写上层。
microVM：使用只读 EROFS 块设备。
镜像离线从 OCI 转 EROFS（支持压缩和随机访问），元数据本地、数据在 3FS。

5.3 按需加载：把镜像当数据而非静态资产

【A】DSec 通过 **3FS（Fire-Flyer File System，集群级分布式文件系统）**按需加载镜像数据：

镜像数据不预分发，按需从 3FS 加载。
元数据本地预取，文件数据按需拉取。
microVM 用 OverlayBD + ublk，256KiB 块 + 二级本地缓存。

评估结果（8192 容器突发）：

方案	完成时间	磁盘写入
按需 EROFS	约 35 分钟	约 700GB（比 eager 少约 57%）
全本地基线	接近	约 600GB
eager Docker	超 60 分钟（慢 1.71×）	—

EROFS 层挂载相比 tar 解压：完成时间 45 分钟，加速 1.76×。

【B】E2B 的做法类似但更简单：模板用 Dockerfile 构建 → 转换为 microVM 快照 → 节点本地缓存模板，避免从远端拉取。

架构原则："环境准备"和"镜像分发"是两大开销源，分层 + 按需加载同时压掉这两者。

6. 调度与密度层架构

6.1 高密度超卖的三板斧

【A】DSec 组合三种机制实现高密度超卖（在高密度下仍保住延迟敏感任务性能）：

机制	实现	作用
内存共享	virtio-pmem + DAX 承载只读基础/工具包层	多沙箱共享同一只读层物理页
内存回收	DAMON + balloon free-page reporting	回收可写磁盘页
CPU 调度	SCHED_IDLE + core scheduling	隔离 BE（尽力而为）负载，避免 SMT 兄弟线程干扰

评估：Firecracker 中 virtio-pmem+DAX 将瞬态峰值 CPU 从 26.5% 提至 41.4%；FPR 可单独用于 CPU 受限部署。

6.2 预热池（Warm Pool）

【A】Kubernetes Agent Sandbox 的 SandboxWarmPool CRD：

维护一组预先创建、就绪的 Sandbox pod。
新请求到来时认领一个就绪实例，而非从零创建。
将冷启动延迟降到 1 秒以内。
对 Kata Containers 尤其重要（外部 VM 创建导致冷启动更高）。

【B】权衡：用空闲算力成本换更低的供给延迟。

6.3 与 RL 训练的协同（DSec 的核心创新）

【A】DSec 最有价值的设计是**"有状态 rollout 执行"与"可抢占 GPU 训练"解耦**：

┌─────────────────┐         ┌─────────────────┐
│  GPU 训练侧      │         │  CPU 沙箱侧      │
│ （可抢占）       │         │ （有状态，不可丢） │
└────────┬────────┘         └────────┬────────┘
         │  训练需资源时              │
         │ ─────────────────────────→ │ 回收空闲沙箱
         │                           │
         │  rollout 未完成时          │
         │ ←───────────────────────── │ 保留状态，等资源归还续跑

训练侧 GPU 可抢占：参数更新、梯度同步随时要独占整机。
rollout 侧沙箱有状态：多轮任务中途不能丢。
协调机制：训练要资源时回收空闲沙箱；rollout 未完成时保留状态。
容器暂停用 docker pause，恢复用 MADV_WILLNEED 预取后 unpause；microVM 用快照恢复。

【B】这同时服务于安全侧：环境版本化 + 生命周期协调让 agent 异常行为（如 reward hacking）可复现、可审计、可干预。

6.4 两级异步：解决 GPU 空等

【B】walkinglabs 附录指出 Agentic RL 的 GPU 空等问题比 LLM RL 更严重——空等发生在每一轮交互内部（模型生成工具调用后，测试进程跑数秒，这条轨迹无 token 可生成）：

批次内并发：轨迹 A 等工具时，GPU 为轨迹 B 生成动作。
批次间解耦：Rollout 与 Training 通过数据队列解耦（TransferQueue 流式，把 Batch 级等待缩短为 Sample 级等待，等待时间降一个数量级）。

对沙箱平台的启示：沙箱调度器必须支持细粒度并发推进多条轨迹，否则 GPU 利用率会被工具等待拖垮。

6.5 弹性伸缩与峰值吸收

【A】DSec 的 placement engine 采用两阶段过滤/排序，并区分本地稳态与云 VM 吸收峰值：

平台组件：IAM（认证授权）、apiserver（入口代理）、placement engine（两阶段过滤/排序）、watcher（健康与调度状态收集）、edge（节点本地准入与资源回收）、aether/chronus（统一 shell 会话代理）、sandbox runtime（节点内管理）。
辅助服务用 BGP+ECMP 负载均衡。

7. 安全层架构：隔离计算只是起点

7.1 核心威胁模型

【A】NVIDIA AI 红队指出，Agent 工具的首要威胁是间接提示注入（indirect prompt injection）——LLM 摄入的内容被对手通过恶意仓库、PR、git 历史、.cursorrules、CLAUDE/AGENT.md、恶意 MCP 响应等载体注入：

手动审批是管理风险最常见的方式，但它引入持续的开发者摩擦，导致"用户习惯化"——直接批准而不审查。

这正对应视频开头的场景："这种审批我每天都会遇到上百个，反正我会点同意"——靠人兜底根本不现实。

7.2 为什么必须在 OS 层而非应用层强制

【A】Agentic 工具设计上就执行任意代码，应用层控制不足：

应用层能在执行前拦截工具调用和参数，但一旦控制权交给子进程，应用层就失去可见性和控制。
攻击者常用间接路径（通过更安全、已批准的工具调用更受限的工具）绕过应用层 allowlist。
OS 层控制（如 macOS Seatbelt）在应用层之下工作，覆盖沙箱内每个进程，无论进程如何启动。

7.3 强制性安全控制（NVIDIA AI 红队）

控制	作用
网络出网控制	阻断对任意站点的访问，防止数据外泄或建立远程 shell
禁止工作区外写文件	防止持久化机制、沙箱逃逸、RCE（如 `~/.zshrc` 被自动执行）
禁止写任何配置文件	防止利用 hooks、skills、本地 MCP 配置（常运行在沙箱外）

7.4 推荐性安全控制

禁止读工作区外文件（~/.ssh、.env 是重点目标）。
沙箱化整个 IDE 及所有衍生功能（hooks、MCP 启动脚本、skills、工具调用），尽量以独立用户运行。
用虚拟化隔离沙箱内核与宿主内核（microVM、Kata、完整 VM）。
每次违规动作都需用户批准，不得缓存/持久化（allow-once/run-many 不是有效控制）。
密钥注入模式：沙箱以空/最小凭证启动，按任务注入短期令牌（凭证代理），而非继承宿主全部环境变量。
生命周期管理：临时沙箱（每次执行创建销毁）或定期重建，防止秘密/IP/可执行代码累积。

7.5 网络隔离的五项控制

【A】Northflank 网络设计指南：

控制	要点
默认拒绝出网	默认阻断，仅显式允许必要目的地；策略独立于 Agent，Agent 不能改自己的网络权限
出网 allowlist + 凭证代理	按主机名/IP/端口/协议限制；敏感令牌留在沙箱外，由代理注入
DNS 控制	限制可解析域名，防止 DNS 外泄与 DoH 绕过
私有网络/VPC	沙箱到服务走私有路径，不暴露公网端点
按租户网络策略	租户/项目/环境级策略，防止跨租户访问

常见错误：允许无限制出网、所有沙箱同一策略、内部服务暴露公网、把"在 VPC 内"当作访问授权、忽略 DNS、不记录被拒连接。

7.6 分层实施（Tiered）

【A】NVIDIA 建议的分层策略：

企业级 denylist（不可被用户绕过）——保护关键文件。
工作区内读写免审批（配置文件除外）。
特定 allowlist 操作（如读 ~/.ssh/gitlab-key）。
默认拒绝，其余逐案审批。

7.7 纵深防御分层（以 E2B 为例）

【B】E2B 的四层隔离：

Layer 4 应用安全：Agent 代码 / 用户进程 / envd（端口 49983）/ 访问令牌认证
Layer 3 Guest OS：独立 Linux 实例 / 隔离文件系统
Layer 2 超管：Firecracker VMM（约 5 万行）/ Rust 内存安全
Layer 1 硬件：KVM 虚拟化 / CPU VT-x·AMD-V / 硬件内存隔离 / IOMMU

【A】DSec 的安全实践：agent 可能攻击沙盒、伪造 RPC、读日志、探测 /proc，DSec 通过访问控制、网络策略、可观测性和持续加固限制越权与信息泄漏；明确把"缓解 reward hacking"写进平台职责。

8. 编排层架构：Kubernetes Agent Sandbox 标准

8.1 为什么需要新标准

【A】Kubernetes 擅长两种负载模型：无状态副本（Deployment）与稳定编号的有状态集（StatefulSet）。Agent 负载两者都不契合：

Agent 运行时通常是单例（singleton）：每个用户会话/任务一个隔离环境，不是副本池。
需要持久存储（跨重启存活）、稳定主机名和网络身份。
需要生命周期控制（空闲暂停、无状态丢失恢复）。
执行可能不可信的代码，需要超越标准容器 namespacing 的隔离。

在 Agent Sandbox 项目之前，最接近的做法是组合"StatefulSet(size=1) + headless Service + PVC"，缺少暂停/恢复/预热池/定时删除等专用生命周期管理。

8.2 四个核心 CRD

【A】2025 年 11 月，Kubernetes SIG Apps 正式立项 Agent Sandbox 子项目（kubernetes-sigs/agent-sandbox）：

CRD	职责
Sandbox	核心资源：单个有状态 pod，稳定主机名 + 网络身份 + 持久存储 + 生命周期（创建、定时删除、暂停、恢复）
SandboxTemplate	可复用模板：固化运行时配置（资源限制、基础镜像、初始安全策略）
SandboxClaim	面向用户/上层框架（LangChain、ADK）的抽象，从模板请求环境，隐藏底层细节
SandboxWarmPool	预热 pod 池，毫秒级分配，冷启动降到 1 秒内

最小 Sandbox 示例：

apiVersion: agents.x-k8s.io/v1alpha1
kind: Sandbox
metadata:
  name: my-sandbox
spec:
  podTemplate:
    spec:
      containers:
      - name: my-container
        image: <IMAGE>

创建后通过稳定主机名 my-sandbox 访问。

8.3 运行时无关（Runtime-Agnostic）

【A】隔离后端通过 runtimeClassName 配置，后端无关是设计原则：

gVisor：用户态内核 runsc 拦截 syscall，降低内核攻击面，无需每负载完整 VM。
Kata Containers：每 pod 一个轻量 VM，独立内核，隔离更强但启动更高（用预热池抵消）。

8.4 其他关键能力

【A】

休眠与恢复（Hibernation & Resume）：空闲暂停释放算力，网络活动时自动恢复，状态完整保留。
定时删除（Scheduled Deletion）：可配置 TTL 后自动清理。
客户端 SDK：Python / Go 一等公民客户端。
K8s 原生：RBAC、namespaces、网络策略、资源配额照常适用。

【A】官方数据：Warm Pool 可将冷启动延迟降到 1 秒以内；企业平台需求为数万并行沙箱、每秒数千查询。

9. 参考实现对照

9.1 E2B（开源托管 microVM 沙箱）

【A/B】E2B 官网 + 第三方拆解：

运行时：基于 Firecracker 的自研 MicroVM 运行时，每个会话独立内核 + 自研内存与快照层；Apache-2.0 开源，可自托管（E2B Embed）。
规模：累计运行 10 亿+ 沙箱，SOC 2 Type II / HIPAA 合规。
架构：API 网关 → 控制面（Session/Resource/Security/Metrics Manager）→ 计算层（多区域 Host Cluster + Firecracker VM 池）→ 存储层（持久存储/VM 快照/指标库）。
组件：API Server（FastAPI）、envd（实例内守护进程，端口 49983）、实例管理服务、环境构建服务。
模板机制：Dockerfile → Docker 镜像 → 转 microVM 快照 → 依赖安装 → 启动命令 → 就绪检查 → VM 状态快照（最终产物是 microVM 快照，非容器镜像）。
会话：最长 24 小时，支持 pause/resume；快照恢复约 150ms。
认证：双认证模型（API Key 管生命周期 + 访问令牌管沙箱内操作）；签名式文件访问控制 + 时限访问。
协议：REST（生命周期）+ gRPC（实时操作，含认证头）。
资源规格：最小 1 CPU + 128MB；模板可配 1–16 核、128MB–32GB。

9.2 DeepSeek DSec（生产级大规模训练沙箱）

【A】arXiv 2609.22978（2026-09-19，梁文锋署名）：

规模：单生产单元约 160 节点、日均约 300 万沙箱、稳态并发 38 万+、创建速率 5000+/秒、任务可请求最多 32K 沙箱。
后端：FnCall / 容器 / microVM / QEMU 全 VM，统一 SDK。
环境：基础 OS / 工作区 / 工具包三层独立版本化，EROFS + overlayfs。
镜像：托管 3FS，元数据本地预取，数据按需拉取。
协同：与 RL 框架协同，解耦有状态 rollout 与可抢占 GPU 训练。
服务对象：DeepSeek V3.2 至 V4.1 的 RL 训练/评估。
实现：使用现有 Linux 特性，无内核修改。

9.3 Kubernetes Agent Sandbox（标准化编排）

见第 8 节。定位是提供隔离原语与声明式 API，不含周边生产基础设施（集群供给、自动扩缩、多租户编排）。

9.4 三者定位对比

维度	E2B	DSec	K8s Agent Sandbox
定位	托管/自托管沙箱平台	大模型训练内部基建	K8s 编排标准
隔离	Firecracker microVM	四级后端分级	gVisor/Kata（可插拔）
规模	10 亿+ 累计	300 万/天	数万并行
开放度	Apache-2.0	论文公开	开源 CRD
关键创新	模板快照 + 双认证	分层镜像 + 训练协同	声明式 CRD + 预热池

10. 完整参考架构

10.1 分层架构总图

graph TD
    subgraph 接入层["接入层 / 控制面"]
        SDK["SDK / API 网关 REST + gRPC"]
        IAM["IAM 认证授权 API Key + 访问令牌"]
        PE["Placement Engine 两阶段过滤/排序"]
        WARM["Warm Pool 预热池 <1s"]
    end
    subgraph 隔离层["隔离层 / 执行后端（分级）"]
        FNCALL["FnCall 函数调用级"]
        CONT["容器 namespaces+cgroups"]
        MVM["microVM Firecracker 独立内核"]
        FVM["完整 VM QEMU"]
    end
    subgraph 启动层["启动层 / 快照"]
        SNAP["快照存储 vm.state + vm.mem"]
        IAA["Intel IAA 硬件 DEFLATE 压缩/解压"]
        UFFD["userfaultfd 按需内存流式"]
    end
    subgraph 分发层["分发层 / 镜像"]
        LAYER["分层镜像 base/workspace/toolkit"]
        EROFS["EROFS + overlayfs"]
        FS3["3FS 分布式文件系统 按需加载"]
    end
    subgraph 调度层["调度层 / 密度"]
        MEM["内存共享 virtio-pmem+DAX"]
        RECLAIM["内存回收 DAMON+balloon"]
        CPU["CPU 调度 SCHED_IDLE+core sched"]
    end
    subgraph 安全层["安全层"]
        NET["默认拒绝出网 allowlist + DNS 控制"]
        FS["工作区外禁写 配置文件禁写"]
        SEC["密钥注入 生命周期管理"]
    end
    SDK --> IAM --> PE
    PE --> WARM
    WARM --> FNCALL & CONT & MVM & FVM
    MVM --> SNAP
    SNAP --> IAA
    SNAP --> UFFD
    MVM --> LAYER --> EROFS --> FS3
    PE --> MEM & RECLAIM & CPU
    MVM --> NET & FS & SEC

10.2 一次沙箱请求的完整链路

sequenceDiagram
    participant Agent as Agent（GPU）
    participant GW as 沙箱网关/控制面
    participant PE as Placement Engine
    participant WP as Warm Pool
    participant MV as microVM
    participant IAA as Intel IAA
    participant FS3 as 3FS
    Agent->>GW: 请求执行代码（指定后端/镜像/限额）
    GW->>PE: 两阶段过滤 + 排序
    PE->>WP: 认领预热实例
    alt 预热池命中
        WP-->>PE: 就绪实例（毫秒级）
    else 预热池耗尽
        PE->>MV: 冷启动 + 烘焙快照（约 3s，按模板摊销）
    end
    PE->>IAA: 快照恢复（硬件解压）
    IAA->>FS3: 按需拉取镜像数据（EROFS 块）
    FS3-->>IAA: 数据块
    IAA-->>MV: 解压写回内存（约数十 ms）
    MV-->>GW: 就绪（<1s）
    GW-->>Agent: 返回沙箱句柄
    Agent->>MV: 执行代码 / 工具调用
    MV-->>Agent: 观察结果 + 退出码
    Note over MV: 多轮交互，状态保留
    Agent->>GW: 结束 / 暂停
    GW->>MV: 暂停（docker pause / 快照）
    MV->>FS3: 轨迹与环境快照落盘

10.3 关键设计决策清单（Trade-off 表）

决策点	选项 A	选项 B	推荐	理由
隔离边界	容器（快/弱）	microVM（慢些/强）	不可信代码用 microVM	内核逃逸影响整机，隔离必须在内核层
启动方式	冷启动	快照恢复	快照恢复	数量级差异（秒→数十 ms）
快照压缩	软件（ZSTD/LZ4）	硬件（IAA）	硬件（有 Xeon 时）	卸载 CPU，压缩比与速度双赢
镜像分发	预分发	按需加载	按需 + 分层	镜像大且复用低，预分发失效
隔离分级	全部 microVM	按威胁模型分级	分级	成本可差一个量级
密度	加机器	超卖调度	超卖调度	内存共享+CPU 调度收益 > 加机器
安全	应用层控制	OS 层强制	OS 层	子进程逃逸应用层控制
编排	自建 StatefulSet	K8s CRD 标准	CRD 标准	声明式 + 生命周期 + 可插拔后端

11. 关键结论与不确定性清单

11.1 已确认结论（附等级）

【A】 microVM（Firecracker）是当前不可信代码执行的主流隔离边界：约 5 万行 Rust、5 类 virtio 设备、<5 MiB 内存开销、100–200ms 启动。
【A】 快照恢复是冷启动的结构性优化：序列化 vm.state + vm.mem，恢复即"恢复暂停的机器"。
【A】 Intel IAA 是片上硬件压缩加速器，硬件压缩比软件快 6.1–13.5 倍，解压约快一个数量级。
【A】 OSDI'24 Sabre 将 IAA 接入 Firecracker 快照流程：压缩 2.5–4 倍，部分应用冷启动降最高 60%，仅约 50 行 Rust FFI。
【A】 DeepSeek DSec 生产规模：160 节点/单元、300 万沙箱/天、38 万+ 并发、5000+/秒创建。
【A】 DSec 采用四级后端分级（FnCall/容器/microVM/全 VM）+ 分层镜像 + 3FS 按需加载 + 训练协同。
【A】 Kubernetes SIG Apps 于 2025-11 立项 Agent Sandbox，四 CRD（Sandbox/Template/Claim/WarmPool），后端可插拔。
【A】 Warm Pool 可将冷启动降到 1 秒以内。
【A】 NVIDIA AI 红队把"默认拒绝出网、禁止工作区外写文件、禁止写配置文件"列为强制性控制。
【A】 安全强制必须在 OS 层而非应用层（子进程逃逸应用层控制）。

11.2 官方未公开事项清单

E2B 自研"内存与快照层"的具体实现细节（官网仅称 "custom memory and snapshot layer"）——未找到公开资料。
E2B 快照恢复"约 150ms"的测试条件（镜像大小、并发度、硬件）——未找到公开资料。
DSec 的 FnCall 后端具体如何隔离（是否与推理服务共置）——论文未展开。
K8s Agent Sandbox 的 Warm Pool 在 microVM 后端下的实际预热成本模型——未找到公开资料。
IAA 在非 Intel 平台上的等价替代（AMD/ARM 是否有同类片上压缩加速器）——未找到公开资料。

11.3 口径冲突清单（并列，不裁定）

指标	口径 1（视频口播）	口径 2（论文/官方）	引用建议
快照体积压缩	"最小压到原来的 22%"（即约 4.5×）	Sabre：Diff 快照最高 4×、平均 2.5×；REAP 最高 4.7×、平均 3.2×	引用论文口径，视频的 22% 属"最优单点"
内存恢复提升	"最快提升 55%"	Sabre：预取速度提升 25–55%（python-list 达 70%）	两者可对应，引用论文的区间
快照恢复延迟下降	"32–128 并发下降低 38%–42%"	论文未直接给出该区间（论文为冷启动最高降 60%）	视频口径待核，建议引用论文"最高 60%"
Firecracker 启动	"百来毫秒"	官方：≤125ms（预配置）、端到端 160–180ms	一致，引用官方

说明：视频口播数字与论文存在"最优单点 vs 平均/区间"的口径差异，本报告并列呈现，建议下游一律引用论文口径。

11.4 常见误判澄清表

常见说法	事实核对	等级
"容器就是隔离边界"	错位。容器是隔离机制，内核才是边界；共享内核下逃逸影响整机	A
"沙箱是新技术"	错。隔离技术（虚拟机/容器）已存在 30 年；"新"的是 Agent 场景带来的规模与突发需求	A
"gVisor 提供硬件级隔离"	错。gVisor 是用户态内核 syscall 拦截，非硬件隔离；Kata/Firecracker 才是	A
"有了 microVM 就不需要网络控制"	错。计算隔离只关住进程，关不住进程的后果（外泄、探测内网）；必须叠加出网控制	A
"应用层审批足够安全"	错。子进程可绕过应用层 allowlist；且用户会习惯化点同意	A
"快照恢复就是把启动做快"	错位。快照恢复是不启动（恢复暂停的机器），与"优化启动流程"是不同量级的事	B
"所有任务都该上 microVM"	错。应按威胁模型分级，成本可差一个量级	A
"Kata Containers 是一种隔离技术"	不准确。Kata 是编排框架，隔离由 VMM（Cloud Hypervisor/Firecracker/QEMU）提供	B

12. 落地实施路线（渐进式）

【B】参考 walkinglabs 的"渐进式架构演进"原则：先验证流程可行性，再做性能优化，最后生产化改造。

阶段一：原型验证（受信任任务） — 用 subprocess + rlimit 验证 reward、轨迹字段、重放流程；目标：跑通"模型生成代码 → 执行 → 打分"闭环。不要用 subprocess 承载任意模型生成代码。

阶段二：引入隔离（模型生成代码） — 加入容器或 microVM（推荐 Firecracker/Kata）；用 asyncio 等机制并发推进多条轨迹；加入基础安全控制（默认拒绝出网、工作区外禁写）。

阶段三：性能优化 — 引入快照恢复（替代冷启动）、预热池、分层镜像 + 按需加载、IAA 硬件加速（若用 Xeon）。目标：启动 <1s、密度提升。

阶段四：生产化 — 迁移到 K8s Agent Sandbox CRD 编排；加入后端分级、高密度超卖、与训练框架协同、完整安全纵深（密钥注入、生命周期、审计）。目标：数万并发、可复现、可审计。

关键指标（建议监控）

指标	目标参考
沙箱创建延迟（p50/p99）	<1s / 可控
快照恢复延迟	数十 ms
单主机创建速率	150 microVM/秒（Firecracker 上限）
内存开销/实例	<5 MiB（microVM）
并发密度	按超卖比设定
被拒网络连接数	监控（可发现注入尝试）
环境重置彻底性	文件/进程/网络/环境变量全清

13. 一页速查表

层次	核心方案	关键技术	代表实现
隔离	microVM 独立内核	Firecracker / Kata / gVisor	E2B、DSec、K8s Agent Sandbox
启动	快照恢复（不启动）	vm.state+vm.mem、CoW rootfs、MAP_PRIVATE	Firecracker Snapshot、PandaStack
加速	硬件压缩解压	Intel IAA（硬件 DEFLATE）	Sabre（OSDI'24）
分发	分层镜像 + 按需加载	EROFS、overlayfs、3FS、OverlayBD	DSec、E2B 模板
调度	高密度超卖 + 预热池	virtio-pmem+DAX、DAMON、SCHED_IDLE	DSec、SandboxWarmPool
安全	OS 层强制 + 默认拒绝	出网控制、禁写、密钥注入、生命周期	NVIDIA 红队指南
编排	声明式 CRD	Sandbox/Template/Claim/WarmPool	K8s SIG Apps

架构总纲：以 microVM 为隔离边界，以快照恢复为启动路径，以分层镜像+按需加载为分发方式，以硬件加速为压缩解压引擎，以分级调度为密度手段，以默认拒绝为安全基线，以 K8s CRD 为编排接口。

一句话本质：Agent 沙箱竞争的终点，是"谁能低成本、高密度、可信地生成和销毁一百万个环境"——模型论文讲方法，环境论文讲产能。

参考文献

Agache et al. Firecracker: Lightweight Virtualization for Serverless Applications, NSDI'20. https://www.usenix.org/system/files/nsdi20-paper-agache.pdf 【A】
Lazarev et al. Sabre: Hardware-Accelerated Snapshot Compression for Serverless MicroVMs, OSDI'24. https://www.usenix.org/system/files/osdi24-lazarev_1.pdf 【A】
Intel. Intel In-Memory Analytics Accelerator (IAA). https://www.intel.com/content/www/us/en/products/details/processors/xeon/features/in-memory-analytics-accelerator.html 【A】
Huang et al. DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale, arXiv:2609.22978. https://arxiv.org/abs/2609.22978 【A】
Kubernetes SIG Apps. Agent Sandbox Documentation. https://agent-sandbox.sigs.k8s.io/docs/ 【A】
Google Open Source Blog. Unleashing autonomous AI agents: Why Kubernetes needs a new standard for agent execution, 2025-11. https://opensource.googleblog.com/2025/11/unleashing-autonomous-ai-agents-why-kubernetes-needs-a-new-standard-for-agent-execution.html 【A】
E2B. The Enterprise AI Agent Cloud. https://e2b.dev/ 【A】
NVIDIA Developer Blog. Practical Security Guidance for Sandboxing Agentic Workflows and Managing Execution Risk. https://developer.nvidia.com/blog/practical-security-guidance-for-sandboxing-agentic-workflows-and-managing-execution-risk/ 【A】
Northflank. How to design networking for secure AI-agent sandboxes. https://northflank.com/blog/how-to-design-networking-for-secure-ai-agent-sandboxes 【A/B】
Northflank. Agent Sandbox on Kubernetes: how it works and how to run it in production. https://northflank.com/blog/agent-sandbox-on-kubernetes 【B】
Northflank. Kata Containers vs Firecracker vs gVisor. https://northflank.com/blog/kata-containers-vs-firecracker-vs-gvisor 【B】
PandaStack. How to Optimize MicroVM Cold Start: 6 Techniques. https://www.pandastack.ai/blog/microvm-cold-start-optimization/ 【B】
Firecracker. Snapshotting support documentation. https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/snapshot-support.md 【A】
Dwarves Memo. E2B breakdown. https://memo.d.foundation/breakdown/e2b 【B】
walkinglabs. hands-on-modern-rl — Agentic RL Infra. https://github.com/walkinglabs/hands-on-modern-rl/blob/main/docs/appendix_industrial_training/agentic-rl-infra.md 【B】
YOMXXX. DeepSeek DSec 论文速读：日均 300 万沙箱的 Agentic 训练基建. https://yomxxx.com/posts/2026-09-28-deepseek-dsec-sandbox-infrastructure-agentic-rl-paper 【B】
小白debug. 为什么沙箱成了 AI 圈最卷的新基建（视频）. https://www.youtube.com/watch?v=iD_2QFur7Q4 【B】
AWS 中国博客. Graviton 优化 Agentic RL 沙箱层：架构与成本优势分析. https://aws.amazon.com/cn/blogs/china/graviton-optimize-agentic-rl-layer-architecture-cost-analytics/ 【B】

本报告基于公开资料整理，证据等级已逐条标注。技术细节可能随产品迭代变化，落地前请以官方最新文档为准。

Agent 沙箱技术核心架构方案（完整版）：七层架构全解 · 证据台账 · 口径校准 · 误判澄清