okay，其实我还不太了解沙箱这一块，能介绍一下吗什么场景选什么或者说有没有什么学习资料？

回复 群友 7309 沙箱不是一种技术，而是一个范围：隔离强度从弱到强大约有五个档次，你按威胁模型选，不必默认选最强的。 最弱的一档是进程级限制：用 seccomp 过滤系统调用、用 Landlock 限制文件路径、用 Linux namespace 隔离进程视图，bubblewrap 和 nsjail 就是把这几样打包好。它启动只要毫秒级、几乎没有额外开销，适合跑你自己的代码或者半可信代码，但宿主内核漏洞是逃逸口，防不住恶意代码。 第二档是普通 Docker 容器：namespace 加 cgroup，同样共享宿主内核。做资源限制够用，当安全边界不够用，官方文档自己也不建议用它跑不可信代码。 第三档是 gVisor：用用户态内核拦截系统调用，宿主内核几乎碰不到，I/O 重负载时性能下降 10%~30%，启动仍然是毫秒级，Google Cloud Run 和 claude.ai 的代码执行走的就是它。 第四档是 microVM（Firecracker 或 Kata）：每个负载有独立内核，由硬件虚拟化兜底，Firecracker 启动约 125ms、单实例内存开销不到 5MiB，每台宿主每秒能起上百个。这是现在托管代码执行服务的主流做法，AWS Lambda 也基于它。Kata 就是把 microVM 做成容器接口，由 K8s 直接调度。 第五档是纯 Wasm 沙箱（wasmtime、Pyodide）：没有系统调用，无风险，启动最快，但装不了任意包，只能跑纯计算或受限解释器。 怎么选，一句话对应：单机个人用、代码自己写的，选第一档；给用户跑不可信代码、多租户，选第四档；中间偏计算密集、I/O 少，选第三档；只算数学，选第五档。你现在这个 code-driven browser agent 其实属于第一档到第二档之间就够，因为攻击面主要是模型写错代码和 prompt injection 骗它乱跑，而不是有人在逃逸。 学习资料按顺序读：先读 Firecracker 官方仓库的 design doc（很短，讲清 microVM 为什么快），再看 gVisor 的架构文档，把 Sentry 和 Gofer 的分工搞明白；实操侧读 bubblewrap 的 man page 和 Landlock 的内核文档，一天就能上手。想快速建立全景，fly.io 那篇 Firecracker vs gVisor 对比，加上 Northflank 的 How to sandbox AI agents in 2026 都写得比较清楚，后者还有完整的选型表。再推荐读 OCI 的 seccomp 默认 profile，能直接抄。 一句话总结：先想清楚要防谁，再选隔离层，别一上来就上最强的。