Agent 沙箱实现全景：隔离模式、主流程、能力面与资源并发控制

本文综合本站知识库中 13 篇沙箱主题文章写成，文末附全部来源。四个问题对应四个章节：有哪些隔离模式、主流程是什么、实现了哪些能力、资源与并发怎么控制。

先给结论，四句话：

1. 隔离模式是一条五级谱系：进程级 → 容器 → 用户态内核 → microVM → 全量 VM，选型由威胁模型决定，不是越强越好——分级后端之间成本差一个量级。
2. 主流程是一条「请求 → 供给 → 执行 → 回收」的流水线，供给速度是第一杠杆：预热池认领走毫秒级，快照恢复走数十毫秒级，冷启动才是秒级兜底。
3. 能力分六组：隔离围栏、快速供给、生命周期编排、凭据与数据安全、可观测审计、上下文治理。
4. 资源与并发分四层控制：单沙箱限额 → 池化调优 → 高密度超卖 → 空闲回收，外加一条铁律——fail-secure，绝不静默回退到无隔离执行。

〇、一张图：七层架构总览

知识库核心架构方案把 Agent 沙箱拆成七层。这七层不是并列的选项，而是自底向上的依赖关系：底层决定隔离强度，中层决定供给速度，顶层决定规模化能力。后文四个章节分别落在这七层的不同位置。

层	解决什么	代表技术	本文位置
1. microVM 隔离边界	隔离强度	Firecracker、gVisor、Kata	第一节
2. 快照恢复启动路径	供给速度（毫秒级）	vm.state + vm.mem、预热池认领	第二节
3. 硬件加速压缩	快照体积与恢复延迟	Intel IAA、Sabre	第二/四节
4. 分层镜像按需加载	镜像分发瓶颈	EROFS、3FS、OverlayBD	第二/四节
5. 高密度超卖调度	单机密度与成本	virtio-pmem+DAX、DAMON、SCHED_IDLE	第四节
6. 默认拒绝安全基线	出网与写入最小权限	egress allowlist、四档审批	第一节
7. K8s CRD 编排标准	规模化与生态	agent-sandbox 四 CRD、Router、SDK	第二/三节

一、有哪些隔离模式

1.1 隔离技术谱系：五级递进

级别	代表	隔离边界	防得住	防不住	启动延迟	内存开销
进程级	subprocess + rlimit	无（共享一切）	误删、资源耗尽	有意攻击	毫秒	无附加
容器	Docker / runc	namespaces + cgroups，共享宿主内核	资源争抢、文件越界	内核逃逸（runc CVE 类）	50–200ms	镜像量级
用户态内核	gVisor	Sentry 拦截 syscall，非硬件隔离	约 110 个内核高危漏洞中 96% 直接防御（含 Dirty COW）	硬件侧信道	毫秒级	小且基本固定
microVM	Firecracker	KVM + 独立 guest 内核，jailer + seccomp	内核级攻击	VMM 自身漏洞	≤125ms 到 init	VMM ≤5MiB
全量 VM	QEMU	硬件虚拟化	最强	设备仿真面即攻击面	数秒	~131MB

五个关键判断，直接决定选型时少走弯路：

• 容器是机制，内核才是边界。 namespaces/cgroups 从设计上不是安全边界，共享宿主内核意味着一次内核逃逸影响整机。这条是整个谱系的信任边界共识。
• gVisor 不是硬件隔离。 它是跑在用户态的应用内核（Sentry），把攻击面收缩到 226 条 amd64 syscall 的实现子集；代价是 I/O 密集负载 10–30% 开销、syscall 密集 5–15%。
• Kata 是编排框架，不是隔离技术。 它不自研 hypervisor，VM-per-pod，VMM 可插拔（QEMU/Cloud Hypervisor/Firecracker/Dragonball/StratoVirt），隔离强度取决于你选了哪个 VMM。
• microVM 是当前强隔离的事实标准。 Firecracker 用约 5 万行 Rust 做完了 QEMU 约 140 万行 C 才做完的事：无 BIOS/PCI/VGA，只留 5 类 virtio 设备，攻击面和内存开销同时压到最低，单机可每秒启动 150 台。
• 不是所有任务都值得上 microVM。 按威胁模型分级后（函数调用级 FnCall → 容器 → microVM → QEMU），各后端成本差一个量级。

把两个代表实现拆开看。

gVisor 是「三进程模型」：未修改的 Linux 二进制 → Sentry（Go 写的用户态应用内核，代答 syscall、信号、缺页、线程）→ 经 LISAFS 协议访问 Gofer（每容器一个的文件代理，唯一以普通进程身份读宿主文件的组件）。Sentry 自身被 seccomp 允许列表锁死——不能新建 socket、不能开文件，官方称这是防容器逃逸的第二道防线。syscall 拦截平台演进三代：ptrace（PTRACE_SYSEMU，已弃用）→ KVM 平台（裸金属最优）→ systrap（2023 年中起默认：seccomp 触发 SECCOMP_RET_TRAP → SIGSYS → 共享内存交 Sentry 处理）。2023 年的 directfs 让 Gofer 以 SCM_RIGHTS 捐 fd、Sentry 用 openat 直达文件，stat 快 2 倍以上。落地成绩：腾讯生产环境每日数百万 gVisor 沙箱，74,379 组对照里 runsc 通过率 86.91% vs runc 86.78%——兼容性损耗已接近抹平。

microVM 五家对比：

实现	出品方	关键取向
Firecracker	AWS	事实标准；单进程 VMM；jailer 先用 cgroup+namespace+chroot 关自己再降权；Unix socket REST API
Cloud Hypervisor	rust-vmm	热插拔、VFIO 直通、vhost-user、live migration、实验性 TDX，可跑 Windows
QEMU microvm	QEMU	在 QEMU 内做极简机型：无 PCI/ACPI、≤8 个 virtio-mmio、内核直启、无热插拔
Kata Containers	Kata	不自研 hypervisor，VM-per-pod，后端可插拔（QEMU 是唯一支持 GPU/TDX/SEV-SNP 的）
crosvm	Google	ChromeOS/Android 系；每设备独立进程 + Minijail 沙箱

1.2 威胁模型决定选型

先列威胁再选技术，顺序不能反。Agent 场景的五级威胁：

威胁	概率	定性
误删数据	高	工程问题，隔离+快照解决
prompt injection 驱动恶意执行	高	Agent 特有攻击面
资源耗尽 / fork 炸弹	高	必然发生，必须限额
数据外泄	中高	网络出口控制
沙箱逃逸	低	高代价事件，按租户模型分级投入

1.3 生态的三条实现路线

同一套谱系，三条落地路径：

1. 编排标准路线（Kubernetes agent-sandbox）：SIG Apps 把沙箱编排标准化为四个 CRD，但编排器自身不实现任何隔离——隔离强度交给 runtimeClassName（gVisor / kata-qemu / kata-fc / urunc / 裸 runc）。「编排器 vs 运行时」是这条路线的决定性边界：编排层管生命周期与调度，运行时层管隔离。验收方法很朴素：沙箱内 uname -r 必须不等于宿主内核。
2. 平台产品路线（OpenSandbox、E2B）：运行时可切换。OpenSandbox 从 Docker（AppArmor/seccomp/capabilities 加固）到 K8s 自研 Operator 再到 FastSandbox（Firecracker），按 image 还是 templateId 请求自动路由到容器或 microVM；E2B 全面押注 Firecracker，四层纵深（KVM 硬件 → VMM → Guest OS → 应用/令牌），累计已跑 10 亿+ 沙箱。
3. OS 围栏路线（Seatbelt、Landlock + seccomp）：不造新边界，直接用操作系统自带的强制访问控制。AWS Strands Box 用 macOS Seatbelt（SBPL，(deny default) 白名单制），且是双层强制——box.toml 由宿主 OS 直接强制，policy.dw Dogwood 语义策略逐笔裁决；施加沙箱必须走 trampoline 一次性进程（Seatbelt 会永久锁死施加者，所以由替身进程先上锁再拉起 Agent）。NVIDIA OpenShell 用 Linux Landlock（文件围栏，5.13+）+ seccomp user notification（网络请求挂起上报）+ 非 root 零 capability，外层再套关容器网络/MicroVM 无网卡，只留 Supervisor 一条通道——判定权全在边界外的可信 Supervisor，Sandbox 只上报不判权：Sandbox 只持网关公钥，Supervisor 签发绑定「沙箱 + generation」的成对 JWT；Agent 的 TCP/DNS 被 seccomp 挂起后，Sandbox 按 /proc 真实路径识别发起二进制（防伪装进程盗用放行规则），经单条 mTLS HTTP/2 报 Supervisor，放行才在工作负载外代换真凭据。

还有一条变体值得单独说：Context Mode 的「数据流隔离」——不做容器级隔离，只隔离子进程，但把边界画在数据流上：原始数据不出子进程，只有 stdout 回流进模型上下文。这是用数据治理替代执行隔离的思路，成本低，适合防的是上下文爆炸和误用而非恶意代码。

1.4 公认安全基线

不管选哪级谱系，这几条是红队实践沉淀下来的底线：

• 三项强制控制（NVIDIA 红队）：默认拒绝出网、工作区外禁写、配置文件禁写。
• 网络五项控制：egress allowlist + 凭证代理、DNS 控制、VPC 隔离、按租户策略、封死云 metadata 地址（169.254.169.254）。
• 四级权限分级：只读 → 工作区写入 → 系统变更 → 网络与支付；对应自动执行 / 自动可回滚 / 逐次人工 / 白名单+限额+人工。
• 四档分层审批：企业 denylist（硬禁止）→ 工作区内免审批 → allowlist（自动放行）→ 默认拒绝、逐案审批。审批策略与沙箱边界分开演进，互不绑定。
• 最小信任三问（每个工具都问一遍）：必须存在吗？必须这么强吗？必须自动执行吗？三问砍下来的权限，比任何沙箱技术都便宜。
• 时间也是边界：截止时间 + 步数上限，防失控循环。
• fail-secure / 围栏先行：分配失败明示原因，绝不静默回退到无隔离执行。OpenShell 把这条做成时序约束——Sandbox 扣住 Agent 直到 Supervisor 确认边界就位才放行，断连即冻结、仅原 Supervisor 可重连。

二、主流程是什么

2.1 一条主流程：请求 → 供给 → 执行 → 回收

各家实现的流程形状高度一致，可以抽象成一条流水线：

预热池没有就绪实例时，退化为全量冷启动（秒级）。六项冷启动优化按收益排序：快照恢复 > CoW rootfs（reflink）> MAP_PRIVATE 惰性 page-in > 预热 netns（省约 100ms）> 极简内核 > userfaultfd 按块流式。

2.2 最快供给路径：快照恢复

强隔离路线的供给走快照，这是整个主流程里最精华的一段：

1. 冷启动烘焙（每模板一次，约 3s）：启动 Firecracker → 配置 boot-source/rootfs/网络 → InstanceStart → 就绪探测 → snapshot/create 产出 vm.state（VMM 状态）+ vm.mem（guest 内存）。
2. 请求进网关（IAM 认证）→ Placement Engine 两阶段过滤/排序。
3. 认领预热池就绪实例（毫秒级）；池耗尽才走冷启动摊销。
4. 快照恢复：snapshot/load 本身约 49ms；内存经 Intel IAA 硬件解压（Sabre：先 Statistics 模式生成 Huffman 表，再按稀疏度选 single-chunk 走 userfaultfd 安装、或 scattered 走 IAA 直接 DMA）→ vCPU 从指令中间恢复。
5. 镜像按需加载：元数据本地预取，数据块从 3FS 集群拉取（EROFS 只读层 + overlayfs 可写层）。
6. 就绪（<1s），返回句柄；Agent 执行 → 观察/退出码 → 多轮状态保留。
7. 回收：容器 pause（恢复时 MADV_WILLNEED 预取后 unpause）；microVM 回炉快照。

两个反直觉的认知：

• 快照恢复 =「不启动」，不是「启动做快」。 恢复的是完整内存态，跳过的不是启动流程而是整个开机过程。
• userfaultfd 惰性加载让恢复延迟与内存大小解耦——内存多大都行，用到哪页才载入哪页，所以能一次 fork 出上百个沙箱。E2B 的模板就是这个思路：模板 = 预启动 VM 的完整状态（内存+磁盘），创建沙箱即恢复快照，实测恢复约 150ms。

2.3 K8s 编排下的认领数据流

标准化的四 CRD 分工：

CRD	职责	关键字段
Sandbox	核心对象：Pod 模板 + 服务 + 生命周期	podTemplate.spec、operatingMode（Running/Suspended）、shutdownTime、shutdownPolicy（Retain/Delete）
SandboxTemplate	共享蓝图，策略载体	envVarsInjectionPolicy、volumeClaimTemplatesPolicy（默认 Disallowed）
SandboxWarmPool	只管未认领的沙箱	replicas（可交 HPA/KEDA）、updateStrategy
SandboxClaim	认领请求	warmPoolRef、ttlSecondsAfterFinished

认领数据流：创建 Claim → 扩展调和器挑 Ready 预热 Sandbox → 乐观锁绑定（所有权池 → Claim）→ 原地应用 additionalPodMetadata → Claim status 镜像 sandbox.name/podIPs/serviceFQDN → 池缺员按模板补充。整套是「只做采纳」设计：所有权转移 + 元数据修补，不做重建，所以认领是亚秒级的。

两个容易踩的坑：Claim 一旦自己设 env 或 volumeClaimTemplates，必然放弃预热、从模板冷启动；标签键必须带允许列表域名（默认 sandbox.users.io，替换非追加、改后要重启控制器），否则直接 InvalidMetadata。

2.4 执行期：控制面与数据面分离

执行流量不走控制面，直连数据面：

• sandboxd（K8s 标准）：gRPC :9090 ProcessService（Start 流式 / Execute / WriteStdin / SendSignal / ResizeTTY）+ REST :8080 FilesystemService（文件 CRUD + health + metadata），路径清洗防穿越。
• execd（OpenSandbox）：SSE 流式输出、后台命令增量日志、持久 bash 会话、WebSocket PTY、Jupyter 多语言内核；控制面（FastAPI）只管生命周期、鉴权、元数据。
• SDK 四种连接模式：Gateway / Tunnel / In-Cluster / Direct URL；create_sandbox 用 watch 驱动不用轮询——轮询平均多加半个周期延迟。

从 API 视角看同一条流程（OpenSandbox）：POST /v1/sandboxes（image / snapshotId / templateId 三选一）→ 异步创建、轮询就绪 → 执行直连 execd（X-EXECD-ACCESS-TOKEN，不经过控制面）→ SSE 流式回流 → 结局三选一：pause/resume（ID 不变）、snapshot 后起新沙箱、destroy。K8s 部署下按请求参数复合路由：templateId 走微虚机、image 走容器、fsb- 前缀归 FastSandbox。

Router（K8s 路线的数据面入口）值得单独记三条纪律：解析优先级 Pod-IP → UID 缓存 → ns/name 缓存 → DNS，未领取的热池 Pod 被刻意排除出名字索引——UID 即能力凭证；请求头剥离 Host/Authorization（升级请求再剥 Origin），防头注入；仅拨号类失败重试 3 次（200→400→800ms 退避）。默认 authorizer 是 AllowAll，生产必须换自定义实现（支持 tokenreview 或 Ed25519 scoped-token）。还有个部署级细节：Router 上游禁 HTTP/2，承载不了 gRPC——gRPC 流量要么直连要么走 Tunnel。

2.5 休眠与回收：三种终局

沙箱的终点不是只有销毁：

1. 销毁：Pod/Service 拆除，对象按 shutdownPolicy Retain（默认，保留对象置 SandboxExpired）或 Delete。
2. PVC-based 休眠：删 Pod 保对象与卷，恢复重建且 hostname/FQDN/PVC 不变——内存不保留，卷保留。
3. 快照回炉：microVM 回快照，下次从 2.2 的路径秒级恢复。

外加 TTL 到期回收（ttlSecondsAfterFinished / shutdownTime）和空闲延迟回收（连续 N 秒无执行才销毁），在复用与成本之间调平衡。

2.6 一致性：epoch 与 fencing

快照/休眠路径必须处理同一 workspace 的双活问题。两个工程要点：

• 快照一致性：workspace 回写确认成功之后才推进 epoch，否则会出现「内存态指向不存在文件」的幽灵状态。
• fencing：旧实例必须证明自己的 epoch 未过期才可继续执行，防止恢复出的新实例和未死透的旧实例同时写一个 workspace。

三、实现了哪些能力

按六组盘点，每条注明机制：

① 隔离围栏

能力	机制
syscall 拦截	gVisor Sentry 代答 + seccomp 允许列表锁死自身（不能新建 socket、开文件）
网络围栏	用户态 netstack（仅 AF_PACKET 收发原始包）；seccomp user notification 挂起网络请求上报 Supervisor
文件围栏	Landlock；只读根 fs + 唯一 rw workspace；路径解析在服务端（防 ../ 逃逸）
L7 请求级检查	REST 方法路径 / GraphQL 字段 / MCP 工具名 / WebSocket 消息逐笔裁决
时态策略	Dogwood：since/once/count——「1 小时内 cargo test 通过才许 git commit」成为沙箱层确定性约束
形式化证明	Z3/SMT 求 candidate ∧ ¬safe：sat 给出精确到二进制/host/method/path 的反例，unsat 通过，unknown fail closed；毫秒级、零 token、可作 CI 门禁

② 快速供给：预热池（突发约 300 claims/s @ p90≤200ms）、快照恢复（load 约 49ms、E2B 约 150ms、warm 创建 97ms P50）、IAA 硬件加速压缩（比软件快 6.1–13.5 倍，约 50 行 Rust FFI 接入，冷启动最高降 60%）、分层镜像按需加载（base/workspace/toolkit 三层独立版本化，EROFS + overlayfs）、CoW rootfs。

③ 生命周期编排：四 CRD + 控制器、replicas 交 HPA/KEDA、Sandbox Router（无状态、不查询 Sandbox、X-Sandbox-ID 即路由凭证、剥离 Host/Authorization 防头注入）、Python/Go/TypeScript 三语言 SDK + CLI + MCP Server、快照推 OCI 仓库跨机恢复。

④ 凭据与数据安全：凭据保管库（真实密钥不进沙箱工作负载，放行时占位符换真凭据、响应中真值替换为 [REDACTED]）、空凭证 + 短期令牌注入、SigV4 剥签名重签、DNS 占位地址 TTL≤30s（防 IP 直连与 DNS 外带）。

⑤ 可观测与审计：OTel 导出、OCSF 标准审计、生命周期事件、工具调用全量留痕（谁/何时/参数/结果）、git 分支 + 文件快照 + dry-run 回滚；被拒连接数是发现注入尝试的有效信号。

⑥ 上下文治理（Context Mode）：子进程仅 stdout 回流、完整输出索引进 SQLite FTS5（BM25 + Porter 词干 + RRF 融合，零 LLM 调用）、压缩快照 ≤2KB 断点续跑，整会话上下文 315KB → 5.4KB（作者自报，未独立复现）。

五个容易漏掉的细节：

• 凭据保管库是透明代理：按 host 做透明 TLS MITM 注入凭据，沙箱内代码看到的始终是占位符，真实值只存在于边界外的网关。
• 时态策略的记忆跨运行持久：Strands Box 的解释器与出站网关共享持久事件历史，「1 小时内 cargo test 通过才许 git commit」这类规则才成立——策略引擎看得见历史，才能裁决现在。
• 网络出口分两档实现：OpenSandbox 的 egress FQDN 黑白名单有 dns（仅 DNS 层拦截）与 dns+nftables（DNS + 数据面双拦）两档；K8s 托管策略入向仅放 Router、出向仅公网、阻断 RFC1918 与云 metadata——副作用是会挡住 sidecar 端口，探针失败先查这里。
• 权限热更新有边界：OpenShell 的 Advisor 闭环（403 → Agent 读 policy_advisor.md → 经 policy.local 提交窄规则提案 → Z3 Prover 风险检查 → 人工批准 → 热加载）只对 REST/L4 类规则生效；改文件/进程限制必须重建沙箱。Prover 也有容量上限：超 1,024 条规则或 4,096 个端点返回 inconclusive，按 fail-closed 处理。
• 快照恢复有联动细节：Firecracker 恢复后网络/vsock 连接不保证保留，恢复路径要设计重连；回收容器用 pause 时，恢复前先 MADV_WILLNEED 预取再 unpause。

围栏的实战成绩单（OpenShell 对抗实验）：10×30min + 2×120min 会话、1,590 次工具调用、416 次权限决策（196 批准 / 220 拒绝），受保护仓库写入 0 次；期间 AI 评审被骗过 1 次，由 Supervisor 兜住——分层防御的意义就在这。

四、资源与并发怎么控制

四层控制，从内到外：

4.1 第一层：单沙箱限额

cgroup 配额 + rlimit（内存/CPU/进程数）+ cap-drop + no-new-privileges + 只读根文件系统；再叠加时长与步数上限。参考规格：E2B 单沙箱 1–16 核 / 128MB–32GB / 会话最长 24h。

4.2 第二层：供给并发——预热池调优

实测基线：3700 副本池 12 秒内完成 3600 次认领，突发约 300 claims/s @ p90≤200ms；持续认领 + 并发补池单池约 70–85 sandboxes/s；热池采纳稳态调优后 p50 92ms / p99 376ms；PandaStack 全链路 create p50 179ms / p99 203ms；OpenSandbox FastSandbox warm 创建 97ms P50 / 308ms P99（10 并发全链路）。

镜像分发是同一层的隐性并发瓶颈：8192 容器突发拉镜像，按需加载的 EROFS 方案约 35 分钟、写 700GB（eager 拉全量少写 57%，但 eager Docker 整体慢 1.71 倍）；EROFS 直接解压比 tar 快 1.76 倍。结论：预热池规模上去之后，镜像层要么按需流式、要么分层复用，别让「下载」变成「供给」的新瓶颈。

调优旋钮（按性价比排序）：

旋钮	默认	实测结论
--sandbox-warm-pool-max-refill-rate	0（不限速）	唯一「无失败模式」优化，设 ≥ 单池稳态到达率，p50/p90 约 −15%
workers（claim/sync/pool/event）	100/50/1/1	推荐 200/150/2/1；1000 级徒增 API 争用
--sandbox-warm-pool-max-batch-size	300	补池轮次 = ceil(replicas/batch)
--sandbox-write-behind-window	关	双刃剑：409 冲突 −44%、突发 p50 −13%，但稳态 p50 +58%（320→507ms）
--sandbox-warm-pool-replenish-delay	关	别开：有池抽干脆弱性，一次 API 超时可致 p90 74s → 205s

另外三条控制面并发纪律：

• watch 优先于轮询（get_* 平均多加 T/2 延迟）；
• 客户端不限流，交服务端 APF（--kube-api-qps=-1），APF 按三优先级隔离：claim > 批量补池 > events，claim 超 50/s 或共享集群必配；
• 单 HTTP/2 连接约 100 流上限，配 --api-connections=4 + 独立 watch 连接。

4.3 第三层：密度——高密度超卖三板斧

DSec（DeepSeek，160 节点）在 microVM 上跑出日均 300 万沙箱、稳态并发 38 万+、创建 5000+/秒、单任务最高 32K 沙箱（中位寿命仅 17.4 分钟、p99 超 3 小时——负载极度长尾），靠的是：

1. 内存共享：virtio-pmem + DAX 多 VM 共享同一份只读内存（代价：峰值 CPU 26.5% → 41.4%，用 CPU 换密度）；
2. 内存回收：DAMON 访问监测 + balloon 气球回收冷页；
3. CPU 调度：SCHED_IDLE 低优先级 + core scheduling 防 SMT 侧信道干扰。

4.4 第四层：空闲与成本——回收策略

• 三档终局按成本递减：销毁 > 休眠（保卷）> 快照回炉；
• TTL 到期回收 + 空闲延迟回收（连续 N 秒无执行才销毁）；
• KEDA scale-to-zero 兜底，冷启动摊销给预热池；
• GPU 协同类任务：批次内并发 + TransferQueue 流式做批次间解耦，等待降一个数量级；
• 应用层也要限额：并发控制不止基础设施层——Context Mode 对外部抓取限并发 1–8、gh 命令封顶 4、同会话检索 9 次触发节流转批量，都是在沙箱之内再画一层并发预算；
• 反过来提醒：非所有任务都该上 microVM——按威胁分级后成本差一个量级，容器能解决的不上 microVM。

落地后盯四个指标：创建 p50<1s、快照恢复数十 ms、每主机每秒启动 150 microVM（容量基线）、被拒连接数（持续非零通常意味着注入尝试或策略误配）。控制面另有一个隐形水位：watch 事件延迟 10–30s 会卡住 expectations 门，事件积压时先查它。

4.5 贯穿四层的一条铁律：fail-secure

所有失败路径都要明示原因、拒绝服务，绝不静默回退到无隔离执行。配套三条：「有 microVM 仍需出网控制」（隔离越强越要防外泄通道）；「应用层审批可被子进程绕过，且用户会习惯化点同意」（所以分级权限里网络与支付永远留人工）；OpenShell 的围栏建立是 fail-closed 的——Sandbox 扣住 Agent 直到 Supervisor 确认边界就位才放行，断连即冻结。

五、常见误判澄清

写进分享里防杠的几句：

说法	澄清
「容器就是隔离」	容器是机制、内核才是边界；runc 逃逸 CVE 始终是共享内核路线的风险面
「gVisor 是硬件虚拟化」	用户态内核，非硬件隔离；不防硬件侧信道
「上了 microVM 就安全了」	出网控制仍然必须；有 microVM 仍有数据外泄通道
「快照恢复是加速启动」	是「不启动」——恢复内存态，跳过整个开机过程
「Kata 提供隔离」	Kata 是编排框架，隔离强度取决于可插拔的 VMM
「审批 = 安全」	审批可被子进程绕过且会被习惯化，只能作为纵深的一层

另附三条第三方保留意见，引用数字时注意口径：Context Mode 的 98% 压缩率为作者自报未独立复现（许可实为 ELv2，多篇解读误写 MIT）；Strands Box 的「决策 1ms / 冷启动 50ms / 常驻 20MB」官方自注「主张，尚未基准化」；OpenShell 被独立测评指其 Landlock 在部分 RHEL 9.x 静默失效、12.5 万行 Rust 含 314 个 unsafe——围栏依赖的底座本身未经验证。

同主题的口径冲突清单（视频口播 vs 论文原文，引用时优先论文口径）：

指标	口径 A	口径 B	建议引用
Sabre 快照压缩比	视频：22%（约 4.5×）	论文：最高 4×、平均 2.5×（REAP 4.7×/3.2×）	论文口径
内存恢复提升	视频：55%	论文：25–55%（python-list 达 70%）	区间表述
恢复延迟降 38–42%（32–128 并发）	视频引用	论文未给出、待核	改用「冷启动最高降 60%」
Firecracker 启动	≤125ms（到 init）	端到端 160–180ms	两口径不矛盾，注明测的是什么

选型前看一眼：K8s agent-sandbox 尚未实现的事（v1.0.4，API 仍为 v1beta1）：Auto Suspend/Resume 与 Scale to Zero、Startup Actions、突发沙箱 TTL 自动清理；Claim 时动态挂载 L4/L7 网络策略；内存快照仅 GKE + Python SDK（依赖 podsnapshot.gke.io），Go SDK 无；Router 连接级限流与 WebSocket 超时未实现（入口限流要在 Ingress 层做）；多集群（fleet）未提供。这些缺口不挡 P0 落地，但写方案时要绕开。

六、收尾：四条实践建议

1. 先威胁模型，后技术选型。 多数业务 Agent 走「容器 + egress 白名单 + 工作区外禁写」就够了；多租户不可信代码才上 gVisor/Kata；需要快照恢复和确定性回放才值得 Firecracker。
2. 控制面与数据面分离，供给与执行解耦。 预热池 + 认领模型是并发第一杠杆——执行直连数据面（execd/sandboxd），控制面只管生命周期和调度，认领走乐观锁。走 K8s 标准路线时按五层顺序接入（控制面 → 运行时 → 网络 → 运行时接口 → 平台治理），每层可独立验证，别一次性全量上。
3. 资源并发控制要分四层做，别指望一层解决。 单沙箱限额管住个体、预热池旋钮管住供给、超卖三板斧管住密度、空闲回收管住成本——外加 fail-secure 兜住所有失败路径。
4. 把「能确定的」下沉成确定性约束。 模型靠提示词守规矩是概率性的；时态策略（「测试没过不许 commit」）、egress 白名单、四级权限、Z3 形式化证明，都是在把行为约束从「劝」变成「拦」——把权限从提示词搬回操作系统，是这条路线所有项目的共同方向。

---

来源（本站知识库）

• Agent 沙箱技术核心架构方案（完整版）：七层架构全解
• 深度研究｜Agent 沙箱技术核心架构方案：从 microVM 隔离到硬件加速快照的七层设计
• Agent 工程 · 第 6 章｜执行隔离：威胁模型、隔离技术谱系、快照与回放
• gVisor 深度解析：把 Linux 内核搬进用户态，为什么成了 Agent 沙箱的默认候选
• microVM 技术全景与选型
• Kubernetes 官方沙箱项目 agent-sandbox 全解：CRD 模型、预热池、休眠机制与生产接入实施
• Kubernetes 官方 Agent Sandbox 接入架构方案：SIG Apps 沙箱编排标准的五层落地设计
• OpenSandbox 架构原理与接入实施全解
• 给 Agent 上锁：工具权限、沙箱与最小信任设计
• AWS 开源 Strands Box：Seatbelt 隔离加会看历史的 Dogwood 策略
• NVIDIA OpenShell：给自主智能体造一个「内核级」监狱
• OpenShell（NVIDIA/OpenShell）：内核围栏加形式化证明
• Context Mode：把工具输出关进沙箱，用本地索引把编码智能体的上下文压掉 98%