字节二面被问：agent里的sandbox有啥用以及是如何构建的？我想都没想就说：不就是一个docker吗？面试官说我只说对了一半

前几天我师妹去字节面二面。面试官她："Agent 里的 sandbox 有啥用，你是怎么构建的？"

她想都没想，就脱口而出了："不就是一个 docker 吗？"

面试官笑了笑，然后说："你只说对了一半。"

她后来跟我复盘的时候，还有点懵。她觉docker不对吗？容器化，隔离执行环境。这不就sandbox 该干的事吗？但面试官接下来的追问，让她意识到一个问题。她把"用什么实现"和"为什么这么现"给混为一谈了。Docker 确实是 sandbox 的一种实现方式。但它既不是唯一的答案。甚至在很多生产级的 agent 场景里面，它都不是最优的那个答案。

听完她的这段经历，我把这块知识彻底捋了一遍。今天分享出来，给同样在准备 agent 相关面试的朋友，也给正在做 agent 产品的朋友。希望你们能比她更早搞清楚这"另一半"。

背景

有个开发者分享过他的踩坑经历。他第一次agent 自己在服务器上跑代码，结果 agent 删掉了一个它本来不该看到的目录。还好，那只是个装了半成品脚本的 tmp 文件夹，没造成什么实质损失。但问题的根源其实很简单。他给 agent 的 shell 权限范围，没有做好限定。agent 拿到的那个"shell"，本质上只是一个工作目录不一样的子进程。它没有真正的边界。

这个瞬间让他意识到一件事：sandbox 不是那种"以后再做"的功能。它是任何要执行代码agent 的前提条件。

这不是个例。Agent 被 prompt injection 诱导，写出了窃取环境变量的脚本。装了 typosquat 恶意包。写了个死循环，把机器跑满。甚至因为一条看起来很"友好的"注释，就把 /etc/passwd 的内容给读出来了。这些都不是理论上的风险。它们是已经在真实场景里发生过的事。

Sandbox 到底是什么

简单说，Sandbox 就是一个隔离的计算环境。你可以把它理解成一台按需启动的"虚拟电脑"。agent 可以在里面运行代码，执行 shell 命令，浏览网页，操作文件。任务一结束，就立刻把它销毁掉。它不会碰到你真正在意的那个系统。

你可能没意识到，但你其实已经在用依赖 sandbox 的产品了。Claude Code、Codex、Browser Use，这些能真正"动手干活"的 agent 系统，底层都是靠 sandbox 基础设施撑着的。可以说，sandbox 就是让 agent 从"能聊"走向"能干"的关键一环。

为什么不能直接在本地跑？

有人可能会这么说：我信任我的 agent。提示词是我写的，模型是我选的，生成的代码看起来也挺合理。能出什么问题？

问题清单其实很长：

• ◆Agent 被工具返回结果里藏着的恶意指令给"注入"了，写出外泄密钥的脚本
• ◆安装的依赖包，是个精心伪装过的恶意包（typosquat）
• ◆死循环把 CPU 跑满
• ◆递归 shell 变成 fork bomb，拖垮整台机器
• ◆被诱导去读取系统敏感文件

这些风险的共同点在于：代码是模型生成的，而模型的输出，本质上就是不可信的输入。哪怕你审查过 prompt，你也没法保证每一次生成都符合预期。这正是为什么，"隔离"必须是架构层面的决策。而不是那种"等出了问题再加"的补丁。

Sandbox 的隔离强度分析

这才是面试官真正想听的部分。Docker 只是隔离技术光谱里面的一环，它不是全部。大致可以分成四个层级：

1. 1.进程级隔离（chroot、rlimit）。几乎没有安全边界，只适合完全可信的代码。不建议用在 AI 生成内容上
2. 2.容器隔离（Docker/OCI，基于 namespace + cgroup）。启动快，资源开销也小。但它和宿主是共享内核的，存在逃逸风险
3. 3.microVM 隔离（Firecracker、gVisor）。这是硬件虚拟化级别的隔离，拥有独立的内核。但启动却能做到 200 毫秒以内。这是目前 AI agent sandbox 领域的主流选择
4. 4.完整虚拟机。隔离最强，但启动慢，成本也高。不适合高频、短时的 agent 任务

Firecracker（AWS Lambda 背后的技术）之所以能成为主流，正是因为它在"虚拟机级别的安全边界"和"容器级别的启动速度"之间，找到了一个平衡点。这正是 docker 回答不完整的地方。它解决了"隔离"这个问题，但它没有解决"agent 生成的代码到底需要多强的隔离"这个问题。

自建所需核心模块

假设你决定自建 sandbox 基础设施，核心模块大概就是下面这些：

执行层：选 Docker（快，但隔离一般），还是选 Firecracker/gVisor（更安全，有独立内核）。

调度层：agent 的请求很频繁，每次都冷启动的话，会严重拖慢体验。所以你需要一个预热池（warm pool），去复用那些已经启动的实例。同时还要做好超时回收。

文件系统隔离：只挂载 agent 真正需要的那些目录。前面那个"误删 tmp 文件夹"的教训，根源就是挂载范围没有控制好。

网络策略：出站域名白名单。或者干脆断网，走受控代理。

快照与暂停恢复：支持 pause/resume，或者 copy-on-write 式的快速 fork。这对"让多个 agent 变体并行探索、保留最优解"这类场景特别有用。

资源配额：CPU、内存、磁盘的硬限制。防止一个失控的任务，把整个池子都拖垮。

现成工具

如果不想自建，2026 年这个赛道已经相当成熟了。几个主流的选择，各有各的侧重：

一个简单的选型经验：

• ◆只是想让 agent"跑一段代码、验证一下输出"，这种轻量的瞬时任务，用 E2B 这类托管服务最省心，几行代码就能接入
• ◆需要自托管、持久化环境，或者要接 IDE 的，Daytona 更合适
• ◆团队本身有基础设施能力，规模也够大，追求极致成本和控制力的，直接基于 Firecracker/gVisor 自建

写在最后

回想那个面试，如果她当时能多说一句"docker 只是隔离光谱里比较轻量的一档，生产环境里面，microVM 因为兼顾了安全性和启动速度，是更常见的选择"，可能就不会只拿到"一半"的评价了。

"Sandbox for AI agents" 这个说法，一年前还是个小众词。现在已经变成一个拥挤的赛道了。这本身就说明了一件事：当 agent 从"聊天"走向"真正执行任务"，安全边界就不再是可选项了。它是地基。

如果你也在准备 agent 相关方向的面试 sandbox 这块知识，别只停留在"就是个 docker"。面试官要听的，是你对隔离强度、冷启动优化、资源配额、快照机制这些取舍的理解。