沙盒（Sandbox）是一种受限的执行环境：程序在其中运行，只能访问被明确允许的资源，即使出错或被恶意利用，也难以波及宿主系统和其他程序。沙盒要处理的是“不可信代码”这一前提，即来自第三方、用户输入或模型生成的程序，不能默认它是安全的。

沙盒的思想源头是操作系统的进程隔离。1979 年，Version 7 Unix 引入 chroot 系统调用（1982 年由 Bill Joy 补入 BSD），把进程的根目录锁在某个子树里，让它“看不见”文件系统的其余部分；1993 年，Wahbe 等人在论文 Efficient Software-Based Fault Isolation 中提出软件故障隔离（SFI），用指令改写把不可信模块的内存访问限制在自己的地址段内，不必启动虚拟机就能隔开故障。1990 年代中期，Java applet 把“沙盒”变成通用说法：浏览器里的代码默认只能做有限的事，越权需要显式授权，Dean 等人在论文 Java Security: From HotJava to Netscape and Beyond 中系统分析了这套模型。

现代沙盒的实现是三层叠加：内核原语、虚拟化与语言运行时。内核层用 seccomp 过滤系统调用、用 namespaces 与 cgroups 隔离视图和资源，容器因此能在同一内核上彼此隔开；虚拟化层用轻量微虚拟机换取更强的边界，Firecracker 以精简的设备模型把启动时间和内存开销压到毫秒级（Firecracker: Lightweight Virtualization for Serverless Applications，NSDI 2020）；语言层则把沙盒做进运行时，WebAssembly 的线性内存与导入机制让模块只能碰到显式传入的对象。近年 AI 智能体开始执行模型生成的代码，沙盒又从“安全机制”变成“默认基础设施”。

沙盒的价值是把故障与攻击的影响限制在边界之内，让不可信代码可以被放心运行、反复评测、随时回滚。但它不是绝对安全：内核漏洞、共享缓存带来的侧信道、配置疏漏都可能让隔离失效，“逃逸”因此始终是攻防焦点。另一面是代价——隔离越强，可用的系统能力越少，文件、网络、GPU 往往要逐项放行；沙盒的工程难点，正是按任务在“关得住”和“用得上”之间划出合适的边界。