Sandbox沙箱概念详解

Sandbox（沙箱）是一个受严格限制的隔离执行环境：程序可以在其中自由运行，但它能访问的文件、网络、内存等资源都被预先限定，即使程序出错或携带恶意行为，破坏效果也被封闭在沙箱内部，不会波及宿主系统。在 AI Agent 时代，Agent 的每一个动作都由大语言模型在运行时动态生成，行为不可完全预测，沙箱因此从传统软件的"幕后安全机制"升级为 Agent 基础设施的核心组成部分。

本教程将系统讲解 Sandbox 的概念定义、核心隔离机制、主流实现技术，以及它在 AI Agent 执行链路中的位置与实际应用，帮助你理解为什么说沙箱是 Agent 安全的"最后一道防线"。

前置教程

如想快速开始学习本教程，你可能需要先完成以下前置教程：

• Agent概念详解，Agent 是沙箱的核心服务对象，沙箱为 Agent 的自主行动划定安全边界。
• Harness概念详解，沙箱是 Harness 安全基础设施的关键组成部分，理解 Harness 有助于定位沙箱在执行链路中的位置。
• ToolCalling工具调用技术分析与应用教程，工具调用（尤其是执行命令、读写文件）是沙箱管控的主要对象。
• Docker的安装、配置与基本使用教程，Docker 容器是实现沙箱环境的主流技术之一，理解容器是理解沙箱实现方案的基础。

1. 什么是 Sandbox

1.1 概念定义

Sandbox（沙箱，也称"沙盒"）是指一个受严格限制的隔离执行环境：进程可以在其中运行和计算，但它能访问的文件系统、网络、内存和外部设备都被预先限定；即使程序出错、崩溃或携带恶意行为，其影响也被封闭在沙箱内部，宿主系统不会受到波及。

沙箱并不是 AI 领域的新发明——你每天其实都在使用它：浏览器里打开的每一个网页、手机上受限权限的每一个 App、PDF 阅读器里渲染的每一份文档，都运行在各自的沙箱中。到了 AI Agent 时代，沙箱的角色从"防外部内容伤害用户"转变为"防 Agent 自主行动伤害宿主环境"。

可以把沙箱想象成实验室里的生物安全柜：研究人员可以在柜内做有风险的实验，柜体的负压、气流和过滤系统确保危险物质不会泄漏到实验室其他区域。沙箱对 AI Agent 的意义与此完全相同。

1.2 沙箱的四个核心属性

一个设计良好的沙箱通常具备以下四个属性：

其中最小权限是理解沙箱配置的关键：沙箱默认拒绝一切访问，只为任务放行必需的权限——例如让 Agent 修改代码时，只开放当前项目目录的写权限，其余文件系统一律只读或不可见。

1.3 为什么 AI Agent 时代需要沙箱

传统软件的行为是开发者编写并在发布前测试过的，而 Agent 的每一个动作都由 LLM 在运行时动态生成，这带来了本质性的安全差异：

最后一条尤其值得注意：Prompt Injection（提示词注入） 是 Agent 特有的攻击方式——攻击者把恶意指令藏进网页、文档甚至代码注释里，Agent 读取这些内容后，可能把恶意指令当成正常任务去执行。行为动态生成叠加攻击面扩大，使得"仅靠用户逐条审批"不再足够，必须有一层环境级的兜底防护。

沙箱是 Agent 安全体系的最后一道防线。

2. Sandbox 的核心隔离机制

一个完整的沙箱通常从四个维度实施隔离：文件系统、进程与系统调用、网络、资源配额。

2.1 文件系统隔离

沙箱内的进程看到的是一个"虚拟视图"：系统目录以只读方式映射，只有指定的工作目录可写。以 Agent 工具常见的工作区写入模式为例，Agent 只能修改当前项目目录下的文件，用户主目录、系统配置等其他内容全部只读或不可见——即使模型"决定"删除系统文件，这个操作在沙箱内根本无法生效。

2.2 进程与系统调用隔离

操作系统通过 Namespace（命名空间） 让沙箱内进程拥有独立的进程编号与挂载视图，与宿主机上的其他进程互不可见；Seccomp（系统调用过滤器） 进一步限制进程能发起的系统调用类型，例如禁止挂载文件系统、禁止加载内核模块。这样即便沙箱内的代码尝试提权，也会被内核直接拒绝。

在不同操作系统上，这一层的具体技术不同：Linux 上是 Namespace、Seccomp 加上文件访问控制（如 Landlock）；macOS 上是 Seatbelt 沙箱机制，通过 profile 文件声明"允许什么、拒绝什么"；Windows 上则是 AppContainer 应用容器与受限令牌。

2.3 网络隔离

网络是沙箱中"最危险的出口"——数据外泄、下载恶意程序都依赖网络。常见策略由严到宽分为三档：

2.4 资源配额与超时限制

即使代码本身无害，死循环或内存泄漏也会拖垮宿主机。沙箱通过 cgroups 等机制限制 CPU 时间、内存上限和磁盘用量，并设置执行超时，超时后强制终止进程并回收资源。

2.5 隔离机制总览

3. Sandbox 的主流实现技术

3.1 技术全景

3.2 操作系统级沙箱

直接利用操作系统内核提供的隔离原语构建沙箱，是本地 Agent 工具最常用的方案：

• Linux：Namespace（隔离视图）+ cgroups（资源限制）+ Seccomp（系统调用过滤）+ Landlock（文件访问控制）组合使用。
• macOS：Seatbelt 沙箱，通过声明式 profile 描述允许的操作清单，命令执行前先被包裹进沙箱进程。
• Windows：AppContainer 应用容器与受限令牌机制；Windows 10/11 专业版及以上版本还提供独立的 Windows Sandbox（家庭版与 Windows Server 不提供），即基于虚拟化的一次性桌面环境。

这一路线的优点是启动快（毫秒级）、开销极低、与本地开发工作流无缝衔接；局限是隔离强度依赖操作系统内核的正确性，属于中等强度边界。

3.3 容器沙箱（Docker）

容器通过镜像打包一个完整的最小 Linux 环境，Agent 在容器内执行命令、安装依赖，宿主机上只看到一个受控的容器进程。开发者可以基于 Docker的安装、配置与基本使用教程 中介绍的技术，为 Agent 构建可复现、可丢弃的执行环境，这也是开发容器（Dev Container）与 CI 执行环境的主流做法。

容器的优点是环境标准化、销毁重建方便；局限在于容器与宿主机共享内核，严格来说不是最强安全边界，对高风险场景常与 gVisor 或 microVM 叠加使用。

3.4 轻量级虚拟机（microVM）

以 Firecracker（AWS 开源，支撑其 Lambda 与 Fargate 服务）为代表：每个沙箱是一个裁剪到极致的虚拟机，约 125 毫秒即可启动，每个实例仅增加约 5MB 内存开销，兼得虚拟机的强隔离与容器的轻量。云端代码执行服务（如 ChatGPT 的代码解释器、各类云沙箱平台）普遍采用这一路线——每个用户会话一个 microVM，会话结束即销毁。

3.5 用户态内核（gVisor）

Google 开源的 gVisor 在用户态重新实现了一个 Linux 内核，拦截并检查容器内的所有系统调用，确认无害后再转发给真实内核，相当于给容器加了一层"翻译兼安检"。它显著缩小了内核攻击面，代价是系统调用密集型任务会有明显的性能损耗。

3.6 技术对比与选型

选型没有绝对优劣：本地单人开发，操作系统级沙箱已够用；对外提供多租户代码执行服务，microVM 或 gVisor 是更稳妥的选择。

4. Sandbox 在 AI Agent 中的应用

4.1 沙箱在 Agent 执行链路中的位置

结合 Harness概念详解 中讲过的执行链路，沙箱位于"工具执行"环节——它是 Harness 安全基础设施的一部分，所有落地的危险操作都必须经过它：

4.2 主流 Agent 工具的沙箱实践

以 Codex 的三档模式为例，可以直观看到沙箱如何用"档位"表达风险边界：

4.3 沙箱与权限审批：纵深防御

沙箱并不取代权限审批，两者共同构成 纵深防御（Defense in Depth）：权限审批是"事前把关"，由用户逐条决定敏感操作是否放行（见 ToolCalling工具调用技术分析与应用教程 中的审批机制）；沙箱是"环境兜底"，即使某个操作被放行或模型判断失误，破坏也被限制在沙箱内。通过 MCP概念详解与应用完整教程 接入的外部工具，同样应纳入这一审批与沙箱管控体系。

此外，Workflow概念详解 中提到的并行 Agent 通过工作树（worktree）实现文件系统隔离，其思想与沙箱一脉相承——多个 Agent 各自持有独立的可写空间，互不干扰。

4.4 沙箱的局限性

沙箱显著降低了风险，但并非万能，使用时需要清楚它的边界：

1. 沙箱逃逸：操作系统或虚拟化层的漏洞可能被利用突破隔离，因此高强度场景会用 microVM 再叠加一层硬件虚拟化边界。
2. 合法渠道外泄：白名单里放行的域名仍可能成为数据流出通道，网络策略需要谨慎配置。
3. 兼容性损耗：部分依赖深层系统权限的工具（如调试器、容器嵌套）在沙箱内无法正常工作。
4. 体验开销：沙箱环境启动、文件同步会带来额外的等待时间。

沙箱、权限审批与审计日志三者组合，才能构成 Agent 安全的完整闭环；任何单一机制都不足以应对所有风险。

5. 总结

5.1 核心内容回顾

• Sandbox（沙箱） 是受严格限制的隔离执行环境，核心属性为隔离性、最小权限、可丢弃性和可审计性。
• 沙箱从文件系统、进程与系统调用、网络、资源配额四个维度实施隔离，确保 Agent 出错时损失有上限。
• 主流实现技术包括操作系统级沙箱、容器、microVM、用户态内核和 WebAssembly，隔离强度与轻便性各有取舍。
• Agent 行为由 LLM 动态生成，还可能被 Prompt Injection 劫持，因此沙箱是 Agent 安全的最后一道防线。
• 沙箱与权限审批构成纵深防御：审批做事前把关，沙箱做环境兜底。
• Codex 的 read-only、workspace-write、danger-full-access 三档模式是理解沙箱配置的直观样本。

5.2 常见问题与解答

问：沙箱和虚拟机有什么区别？

答：虚拟机通过硬件虚拟化模拟一台完整计算机，隔离最强但资源开销大；沙箱是一个更轻量的受限执行环境，可以基于操作系统原语、容器或轻量虚拟机构建。microVM（如 Firecracker）介于两者之间，用极小的开销获得接近虚拟机的隔离强度。

问：Docker 容器算不算安全的沙箱？

答：容器提供了不错的隔离效果（独立文件系统、进程视图和资源限制），但与宿主机共享内核，历史上出现过容器逃逸漏洞。日常开发场景足够安全；面向不可信代码的多租户服务，建议叠加 gVisor 或改用 microVM。

问：Agent 在沙箱里还能联网吗？

答：取决于网络策略。多数 Agent 沙箱默认禁网；需要安装依赖时，可以配置代理白名单，仅放行 npm、PyPI 等包管理源，在功能与安全之间取得平衡。

问：使用 Codex 或 Claude Code 时，一定要开沙箱吗？

答：日常项目开发建议保持默认的沙箱与审批机制；只有在明确理解风险的前提下（例如在本机执行系统级运维命令），才考虑切换到完全放开模式。