这是道技术面试题，需要把 “容器只是其中一层” 讲清楚。我先核实 2026 年主流 agent sandbox 方案的实现方式，以及它们各自公开的隔离机制。
材料够了：Vercel 的 Firecracker 架构、E2B 的隔离参数，还有一篇 arXiv 论文实测了五款沙箱的 seccomp 白名单和可达内核原语数量 —— 这正好能解释清楚面试官说的 “另一半”。
标题：Agent 的 sandbox 不是 “一个 Docker”：面试官要的另一半，是内核边界与出口治理
面试里那句 “不就是一个 Docker 吗”，对的一半是 “容器化、可丢弃、按任务起环境” 这套思路；错的一半是把 “运行时” 当成了 “隔离边界”。Docker 默认的 runc 容器共享宿主内核，它是打包边界和资源边界，不是安全边界；而 agent sandbox 要挡的是模型刚刚写出来、没人审过的代码，威胁模型完全反过来了。一份 2026 年的引擎级实测给出了很硬的一组对照：E2B 的沙箱进程只放行 55 个系统调用，gVisor 是 84 个，而 Daytona 默认的 runc 容器是 0 个 seccomp 过滤、内核字符串与宿主逐字节一致，/dev 下能看到 268 个设备节点。同样叫 “sandbox”，隔离强度差了一个数量级。
sandbox 在 agent 里承担四件事，缺一件都不算合格。
| 作用 | 具体挡什么 | 没有它会怎样 |
|---|---|---|
| 隔离爆炸半径 | 模型生成的 shell 命令、装包、删文件 | 一条 rm -rf 打到宿主或生产目录 |
| 约束能力 | 文件、网络、凭证、系统调用 | 读到云元数据里的临时凭证并外传 |
| 保证可复现 | 固定镜像、固定依赖、快照 | “我这儿能跑” 变成排查噩梦 |
| 支撑并发与回收 | 每任务一个环境、用完即毁、TTL | 长跑任务互相污染，成本失控 |
第一件事的分量，从一个真实案例就能看出来。安全研究员 Johann Rehberger 在 Claude Computer Use 公测后几天做了 “ZombAIs” 实验：让 agent 正常浏览一个网页，页面里藏着注入指令，agent 读完就把一个二进制下载下来、chmod +x、执行，然后连上了他的命令控制服务器。整条链路里没有任何一步是 “漏洞利用”，全是 agent 被授权做的正常操作 —— 这正是容器挡不住、必须靠沙箱挡的部分。
隔离不是二选一，是一条从 “策略” 到 “硬件” 的阶梯。
| 层级 | 代表实现 | 启动开销 | 边界强度 | 适合什么 |
|---|---|---|---|---|
| OS 级策略 | Landlock + seccomp、nsjail、bubblewrap、macOS Seatbelt | 约 5–30 ms | 中 | 本机 agent、只读任务、MCP 工具 |
| 容器（runc） | Docker /containerd 默认 | 约 300 ms | 低（共享宿主内核） | 已审过的可信代码 |
| 用户态内核 | gVisor（runsc / Sentry） | 约 200 ms | 中高 | 无 KVM、想低成本升级 |
| 微虚机 | Firecracker、Kata Containers | 约 100–125 ms（快照恢复可到 5–30 ms） | 高（独立 guest 内核） | 跑不可信代码的默认选择 |
| 托管沙箱 | E2B、Vercel Sandbox、Modal、Northflank | 按厂商，49–200 ms 级 | 高 | 不想自己运维 |
这张表里最容易被忽略的是第一行。不是所有场景都值得上微虚机：如果 agent 只在开发者机器上跑几条只读命令，一个 5 毫秒启动的无特权进程沙箱就够了。arXiv 上那篇《Sandlock》做的就是这件事 —— 不用 root、不用镜像、不用命名空间，靠 Landlock + seccomp-bpf 编译静态策略，启动开销约 5 到 6 毫秒，跑 Redis 能到裸机吞吐。它把 “策略” 和 “隔离硬件” 分开了：策略决定能碰什么，硬件决定逃出去有多难。
微虚机为什么成了跑不可信代码的默认选择，关键在 “逃逸要付几道门”。Firecracker 是 AWS 为 Lambda 和 Fargate 写的 VMM，用 KVM 起一个只带 virtio-net、virtio-blk、virtio-vsock 的精简虚机，冷启动约 125 毫秒，每个实例内存开销不到 5 MiB，单机每秒能起 150 个milos-mitrovic.online。客体内的代码即使拿到 root，也只拿到 “自己的内核”；要碰宿主，还得再破 KVM 和 Firecracker 那层极小的设备模型。gVisor 走的是另一条路：Sentry 在用户态接管系统调用，不透传宿主，但它只实现了大约 70% 到 80% 的 Linux 系统调用，I/O 密集场景有 10% 到 30% 的额外开销 —— 省了硬件虚拟化，付出的是兼容性和性能。
真正的工程差距，在 “进程能被允许做什么” 这一层，而不是 “用了哪种虚机”。
| 实测项 | E2B（Firecracker） | gVisor | Daytona 默认（runc） |
|---|---|---|---|
| seccomp 过滤 | 有，55 个 syscall 白名单，全部线程生效 | 有，84 个 | 无，全部线程 mode 0 |
| 客体内核 | 独立，6.1.158 | 合成内核 4.19.0-gvisor | 宿主内核原样（6.8.0-100-generic） |
| /dev 可见节点 | 128 | 15 | 268 |
| 14 类内核提权原语可达数 | 7 | 5 | 11 |
这组数字比任何宣传语都说明问题：同样标 “隔离”，可达的攻击面差了近一倍。要补充一句公道话 —— 这是按 “默认部署路径” 测的，厂商另有 VM 档位；而且可达不等于可利用，还要看客体内核版本与补丁。但它足以支撑一个判断：选沙箱时先读隔离模型，别读标签。
构建一个能上生产的 agent sandbox，顺序是五层，跳过任何一层都会留下洞。
| 层 | 要做的事 | 具体参数 / 做法 |
|---|---|---|
| 1 策略 | 先定义 “这个任务允许碰什么” | 可读路径白名单、可写路径、允许的端口与域名、禁止的 syscall |
| 2 边界 | 按代码可信度选隔离档 | 不可信代码 → 微虚机；本机只读 → Landlock/seccomp；无 KVM → gVisor |
| 3 出口 | 默认拒绝出网，按需放行 | 域名 + CIDR 规则，拒 deny 优先；阻断云元数据 169.254.169.254 |
| 4 凭证 | 密钥不进沙箱 | 代理注入（credential brokering），沙箱只拿短期、任务级 token |
| 5 生命周期 | 每任务一个环境，用完即毁 | TTL 兜底、硬超时（单次工具 30s / 单任务 20min）、全量审计 |
落到具体命令上，一个 “够用” 的本地版本大致长这样 —— 注意这里每一个 flag 都是在补 Docker 默认缺的那一块。
| 参数 | 作用 | 不写会怎样 |
|---|---|---|
| --runtime=runsc | 用 gVisor 替掉共享内核 | 内核漏洞直接等于容器逃逸 |
| --network=none | 断网 | 注入的 payload 可以直接外传数据 |
| --read-only | 根文件系统只读 | 代码可以改写镜像、留后门 |
| --tmpfs /tmp:size=64m,noexec | 给小块可写空间且禁止执行 | 下载的二进制能落地并运行 |
| --cap-drop=ALL | 丢掉全部 capability | 挂载、改网络等能力仍在 |
| --security-opt no-new-privileges | 禁止提权 | setuid 程序可提权 |
| --memory 256m --cpus 0.5 | 资源上限 | 死循环或挖矿拖垮宿主 |
| timeout=30 | 硬超时 | 卡住的 agent 无限计费 |
这套组合的启动成本会上升，所以生产上通常再加两个工程手段：预热池（把 “取容器” 从 300 毫秒降到 1 毫秒级）和快照恢复（PandaStack 公布的 create→ready 是 49 毫秒 p50，E2B 的托管沙箱在 200 毫秒内就绪）。省下来的不是钱，是 “每任务一个干净环境” 这件事能不能成为默认值。
买服务还是自己搭，取决于你要不要为 “运维” 付人。
| 选择 | 适合 | 代价 |
|---|---|---|
| 自建 Firecracker | 有 KVM 裸金属、有合规要求、量大 | 快照管理、预热池、网络与磁盘全归你 |
| 买托管（E2B / Vercel / Modal / Northflank） | 想快速上线、按量计费 | 隔离细节不透明，出口与凭证要自己配 |
| 只用加固容器 | 代码可信、内网、非多租户 | 内核逃逸仍在威胁模型里 |
买的时候别只看 “是不是微虚机”，还要看三个落地细节：出口规则谁优先（Vercel 是 deny 优先，E2B 是 allow 优先，语义不同）、凭证怎么进（代理注入还是环境变量，后者沙箱内代码能直接读）、以及能不能按任务维度限流与审计。
最后是一些被问到时最容易答错的点。
| 常见说法 | 更准确的说法 |
|---|---|
| “sandbox 就是一个 Docker 容器” | 容器是打包与资源边界，共享宿主内核；不可信代码要独立内核（微虚机）或用户态内核（gVisor） |
| “用了微虚机就安全了” | KVM 与 VMM 本身也有 CVE；隔离只缩小逃逸面，出口、凭证、权限仍要单独管 |
| “隔离做好了，就不用管权限” | 多数真实事故是 agent 用 “合法权限” 干了坏事，隔离管不住它被授权做的事 |
| “gVisor 和微虚机差不多” | gVisor 只覆盖约 70%–80% 系统调用，I/O 有 10%–30% 开销；微虚机兼容性完整但启动更贵 |
| “厂商说独立内核就一定独立” | 第三方实测显示部分产品默认档是 runc、内核字符串与宿主一致，要按档位核对 |
| “沙箱越多越安全” | 每任务一个、用完即毁才是关键；复用沙箱等于给下一个任务留了攻击面 |
【常见问题】
问题 1：agent 的 sandbox 到底有什么用，不加会怎么样？
回答 1：它把 agent 的动作关进一个 “可丢弃、可限制、可审计” 的环境里，作用有四层：限制爆炸半径（一条 rm -rf 打不到宿主）、约束能力（文件、网络、凭证、系统调用）、保证可复现（固定镜像与快照）、支撑并发与回收（每任务一个环境、TTL 兜底）。不加的后果不是 “可能出错”，而是 “必然出错只是时间问题”：ZombAIs 实验里 agent 被一个网页注入，下载并执行了二进制、连上 C2，全程没有一步是漏洞利用，全是它被允许做的正常操作。
问题 2：为什么说 agent sandbox 不只是一个 Docker？
回答 2：因为 Docker 默认的 runc 容器与宿主共享内核，它解决的是 “打包和资源配额”，不是 “不可信代码的隔离”。引擎级实测里，Daytona 默认档的 seccomp 过滤是 0、内核字符串与宿主逐字节一致、/dev 可见 268 个节点；E2B 的 Firecracker 沙箱是 55 个 syscall 白名单、独立内核、/dev 只看得到 128 个。同样叫 sandbox，14 类内核提权原语的可达数是 7 比 11。所以正确的说法是：Docker 是 sandbox 的一种低成本实现，只在代码可信时成立。
问题 3：构建 agent sandbox 时，微虚机和 gVisor 该怎么选？
回答 3：看两个约束 —— 有没有 KVM、代码有多不可信。有 KVM、跑模型生成的任意代码，选 Firecracker 一类微虚机：独立 guest 内核、冷启动约 125 毫秒、快照恢复可到 5–30 毫秒、内存开销不到 5 MiB。没有 KVM、或者想在现有 Docker 上快速加一层，选 gVisor：Sentry 在用户态接管 syscall，代价是只覆盖约 70%–80% 系统调用、I/O 密集有 10%–30% 开销。如果只是本机只读任务，两者都不必上，Landlock + seccomp 的无特权进程沙箱 5 毫秒就能起。
问题 4：agent sandbox 建好之后，还需要补哪些东西？
回答 4：补三样，缺一样隔离就白做。第一是出口：默认拒绝出网、按域名和 CIDR 放行、阻断云元数据地址，否则沙箱里的代码照样能把数据传出去。第二是凭证：密钥不要放进沙箱环境变量，用代理在边界外注入短期、任务级 token，沙箱内代码读不到明文。第三是生命周期与审计：每任务一个环境、TTL 兜底、单次工具 30 秒、单任务 20 分钟的硬超时，并把 agent 生成的代码和每次出站请求全量落日志。隔离解决 “跑得安全”，这三样解决 “跑得可控”。
【参考资料】
[2026-10-15]（Best Code Execution Sandboxes for AI Agents in 2026）E2B Changelog
[2026-09-23]（Code Execution Sandboxes for AI Agents (2026)：八家平台的隔离、自托管与持久化对比）PandaStack
[2026-06-26]（Docker MicroVM 沙箱：给 AI Agent 代码执行加上安全护栏）YOMXXX
[2026-06-30]（AI Code Sandboxes: A Comparative Security Study, Part 1（arXiv 2606.08433））arXiv 预印本
[2026-03-23]（Sandlock: Confining AI Agent Code with Unprivileged Linux Primitives（arXiv 2605.26298））arXiv 预印本
[2026-03-20]（Vercel Sandbox vs E2B：计算生命周期、安全控制与计费对比）Vercel Knowledge Base
[2026-03-18]（AI Agent Sandbox: How to Safely Run Autonomous Agents in 2026）Firecrawl
[2026-01-30]（Run untrusted code with Vercel Sandbox, now generally available）Vercel
【免责声明】
本文依据各厂商公开文档、Vercel 与 E2B 的产品说明、Firecrawl 的行业综述，以及两篇 arXiv 预印本整理。隔离强度、启动耗时与系统调用数据存在明显的口径差异：厂商公布的 “独立内核 / 毫秒级启动” 多为自家基准或最佳档位，arXiv 2606.08433 的测量针对的是各产品默认部署路径，且 “原语可达” 不等于 “可利用”，实际风险还取决于客体内核版本与补丁节奏；该预印本的具体上传日期以 arXiv 页面为准，本文按编号 2606 归属 2026 年 6 月。启动耗时（Firecracker 约 125 毫秒、gVisor 约 200 毫秒、容器约 300 毫秒）取自公开资料与论文对比表，不同硬件与镜像下会有浮动。文中提到的 docker run 参数为最小加固示例，不构成生产级安全方案；涉及多租户、敏感数据或合规场景，应以专业安全评估与厂商最新文档为准。本文为技术原理解读，不构成对任何产品或服务的推荐。