1. 沙箱到底在解决什么问题

1.1 Agent 比普通程序更“需要”沙箱

先说一个最近经常被问到的问题：很多人看 Agent 框架的文档，代码执行模块里总写着“在沙箱中运行”，插件系统也说“沙箱隔离”，连平台侧的 API 描述里都强调“运行时沙箱化”。听起来像是个安全盒子，但具体隔离了什么、为什么隔离、不隔离会怎样，很多人其实是懵的。

要理解这件事，得先看 Agent 的工作方式。传统程序执行逻辑是程序员写好的，行为虽然有 bug，但底线可控。Agent 不一样，它的执行路径是由模型输出动态决定的。一个 Agent 收到用户请求后，可能自主决定调用哪个工具、执行哪段代码、读取哪个文件。问题是模型输出本身就不可预测——同一个 Prompt 换个措辞，Agent 可能生成完全不同的操作序列。这个不可预测性，成了风险的源头。

换句话说，Agent 天然要面对三类不可信输入：一是用户给的内容，可能是无害对话，也可能是一段精心构造的提示注入；二是外部工具和插件返回的数据，可能存在恶意内容；三是模型自己生成的执行计划，虽然经过对齐训练，但没人能保证百分百不出格。这三类不可信输入一旦进入执行环境，就需要一个强制隔离层来兜底，这就是沙箱的核心定位：把不可信的操作限制在一个可控范围内，即使出问题，也不波及其他东西。

1.2 没有沙箱的执行环境有多脆弱

举个实际的例子。假设你在本地起了一个 Agent，用户请求里夹带了一段代码：“读取服务器上的密码文件，发到某个地址”。如果 Agent 的程序员图省事，直接把模型生成的代码通过exec()跑在当前进程里——那等于把整台机器的权限交出去了。Python 的exec()和eval()默认可以访问全局命名空间，文件系统、网络、环境变量、子进程全都能碰。一段十几行的代码就能把系统搞坏。

再往深一层看，风险不只是“恶意代码”。你用一个 Agent 帮你写报告，它可能去调用脚本合成图片；你用 Agent 自动化处理数据，它可能要执行 SQL 或者跑一个临时脚本。这些操作如果直接在宿主机上跑，脚本里的一个 bug 就可能误删数据，或者写坏配置文件。这类问题不是“安全攻击”，而是“意外事故”——但事故造成的损失和安全攻击一样严重。

所以沙箱解决的核心问题，是一个很朴素的矛盾：Agent 需要执行能力，但执行能力不能无边界释放。沙箱就是给这个执行能力装上“围栏”，让你能说清楚这个 Agent 能做什么、不能做什么、做了什么。这也是后来很多 Agent 框架把“沙箱能力”当作核心卖点的原因——不是为了显得高大上，而是因为它真的决定了 Agent 能不能在真实环境里放心用。

1.3 沙箱的三个核心维度：隔离、限制、审计

把沙箱拆开看，它其实是在做三件事。

第一是隔离。隔离是物理层面或逻辑层面上的“互不相干”。Agent 代码跑在独立的文件系统里，看不到宿主机的隐私文件；进程跑在独立的进程空间，杀不掉宿主机的关键服务；网络栈如果是独立的，就不能随便扫描内网。隔离做得越彻底，破坏面就越小。

第二是限制。限制是给资源配额度。CPU 用多少、内存用多少、磁盘写多少、能起几个进程、能连哪些网络，都要有上限。一个失控的 Agent 脚本可能是个死循环，如果没限制，能把宿主机 CPU 打满；一个 bug 可能疯狂写日志，把磁盘撑爆。所以限制不只是安全，更是稳定性的基础。

第三是审计。审计回答“刚才到底发生了什么”。沙箱里产生的操作记录、网络请求、文件变更，都应该可以追溯。毕竟 Agent 执行完任务还要复盘，出了问题也要排查。一个只有隔离和限制、没有审计的沙箱，相当于一台没有摄像头的保险柜——丢了东西都不知道怎么丢的。

这三个维度是选型时最重要的衡量标尺。后面聊各种沙箱技术方案，本质都是在三个维度之间做取舍。

2. 沙箱的核心原理：隔离不是玄学

2.1 进程隔离与文件系统隔离：第一层围栏

沙箱技术发展了很多年，不管形态怎么变，底层原理都有脉络可循。最常见的一层是进程级隔离，核心思路是让目标代码跑在一个受限的操作系统视图里。

最朴素的方式是chroot。原理很简单：chroot能改变进程看到的根目录路径，让进程以为某个目录才是系统的根。比如把/srv/sandbox/作为根目录挂给沙箱进程，它就看不到外面的/etc、/home了。但chroot本身有几个著名的弱点：它不能隔离网络、不能隔离进程、不能隔离内核资源。如果一个带 root 权限的进程在chroot环境里获取了文件描述符，还是可能绕出去。所以单独的chroot在现代沙箱里只是辅助手段，不是主力。

真正现代一点的进程隔离，靠的是 Linux 内核的两个机制：namespace和cgroups。namespace 让一组进程拥有独立的视图——独立的主机名、独立的进程 PID 编号、独立的网络栈、独立的挂载点、独立的用户 ID 映射。从进程自己的视角看，它像在一台独立的机器上跑。cgroups 则负责资源限制，限制 CPU 时间、内存上限、磁盘 IO 带宽、进程数量等等。这两个机制配对使用，就是容器落地的基础。

之所成为基础，是因为“独立视图”这个设计很巧妙。它不模拟任何东西，只是把内核的一部分能力按“命名空间”隔离了，性能损耗极小。不过要注意，隔离视图不等于隔离内核——所有 namespace 里的进程共享同一个内核。这意味着如果内核本身有漏洞，沙箱里的进程还是可能穿透到宿主机。所以单靠 namespace 和 cgroups 构建的普通容器，更多是“运维隔离”而不是“安全隔离”。

2.2 系统调用拦截：把“请求”变成“许可”

进程隔离解决的是“看得见”的问题，但看不见的未必碰不到。沙箱里的程序最终要通过系统调用向内核请求资源——打开文件、创建进程、发送网络包，全都要经过系统调用这扇门。如果能在这扇门上做限制，就等于在每个动作发生前先问一句：这个操作允许吗？

这就是系统调用过滤机制的思路。Linux 上的seccomp就是干这个的。你可以构造一个规则集，告诉内核“只允许这几类系统调用”，其他的一律拒绝。这就有点像机场安检——不是等旅客上了飞机再审查，而是过安检门时就筛一遍。结合前面的 namespace，效果就翻倍了：进程看不到外面的世界，即使看到了，也没有对应的系统调用权限去操作。

不过seccomp有个使用门槛：它工作在系统调用这一层，规则写起来很细、很繁琐，而且要跟自家业务匹配。一个跑 Python 的环境，需要哪些系统调用，和跑 Node.js 的环境是完全不一样的。规则写太宽，沙箱形同虚设；写太紧，正常的代码跑不起来。所以很多沙箱产品并不会直接让你面对seccomp，而是封装成几条高级策略，比如“默认拒绝、按白名单放行”。

再往上走，还有一类更彻底的做法，就是用户态内核。这类方案的代表是 gVisor，它在用户态实现了一整套“虚拟内核”，所有来自沙箱内进程的系统调用先被拦截，由这套用户态内核翻译、检查后，再以受限的方式转发给真实内核。相当于给沙箱进程配了一个“翻译官+保安”，不管进程想干什么，都得先过翻译官这一关。这个方案比纯seccomp隔离性更强，也比虚拟机更轻量，很适合需要高隔离强度、又对资源开销敏感的场景。

2.3 硬件辅助虚拟化：最彻底但也最重的隔离

无论 namespace 怎么隔离，共享内核的事实是改变不了的。如果你面对的是一个安全等级要求很高的场景——比如多个互不信任的租户在同一台机器上运行代码——那就需要更强的手段。最彻底的是虚拟化，用虚拟机监控器（hypervisor）创建独立虚拟机，每个虚拟机有自己完整的内核、独立的硬件访问通道。

虚拟机隔离之所以强，是因为它的边界是在硬件层面划定的。沙箱内的代码攻击到宿主机，需要先攻破一层完整的内核和虚拟化层，难度比绕过 namespace 高几个数量级。缺点是资源开销大、启动慢。传统虚拟机启动动辄几十秒，内存也要额外预留，对于高频短时任务完全不可接受。

于是业界做了折中，出现了轻量虚拟机和微虚拟机。这类方案的核心思路是：保留虚拟化的强隔离边界，但精简启动流程和资源占用，启动时间被压缩到毫秒级。有一类技术路线叫 Firecracker，就是为云函数这种高频短时场景设计的，启动快、内存占用低，每个实例的资源开销已经小到可以忽略不计。

这类方案的优劣势都很明显。优势是隔离强度高，适合多租户场景；代价是部署复杂度和运维成本上来了，不像一套 Docker 命令那么顺手。不过对于 Agent 平台来说，如果想让第三方插件、不同用户的代码在同一个集群里安全共存，轻量虚拟机几乎是最稳妥的底线选择。

2.4 WASM：换一条赛道做隔离

前几种方案都在操作系统层面做文章，还有一类思路比较特别：从语言和运行时层面隔离，这就是WASM（WebAssembly）路线。

WASM 本来是为了浏览器里的高性能 Web 应用设计的，后来被挪到服务端和 Agent 环境做沙箱。它的核心特性是：代码在一个定义明确的“抽象机器”上执行，默认没有能力直接访问宿主机的系统调用和内存地址，只能通过语言运行时提供的接口做外部交互。所以 WASM 沙箱天然就是受限的，不需要依赖操作系统的隔离机制。

WASM 沙箱的优点是轻量、快、可移植。一段 WASM 模块启动的时间几乎可以忽略，内存占用也很低。有些 Agent 平台用 WASM 跑插件，插件代码本质上是个纯逻辑函数，需要的外部能力通过 host function 以白名单的方式注入。这种方式非常优雅——插件开发者只写业务逻辑，没有能力碰系统资源，平台通过注入函数给插件“供水供电”。

但 WASM 也有短板。它适合 CPU 计算型负载，对于需要长驻后台、大量文件 IO、频繁调用网络协议栈的任务就不太顺手。另外 WASM 工具的生态和熟悉度都不如容器，能让代码跑起来需要额外的工具链配合。所以 WASM 并不适合取代容器和虚拟机，而是和它们互补，在特定场景里做更好的选择。

2.5 沙箱不是单点技术，而是一套纵深防线

前面讲了四类沙箱底层机制，看起来是递进关系，但实际在生产环境里，它们很少单独使用。更常见的做法是把多层机制叠加，形成纵深防御：用 namespace 和 cgroups 做基础资源隔离，用 seccomp 过滤不安全的系统调用，用只读文件系统防止代码篡改，用 netfilter 策略封禁不必要的网络流量，最后在上层还套一层策略——比如禁止执行某些高危指令、限制访问某些路径。

为什么要叠这么多层？因为任何单层方案都有漏洞的可能。容器逃逸虽然难，每年还是能爆出新的漏洞；seccomp 规则再细，也挡不住通过合法系统调用组合出来的攻击路径；WASM 隔离性再好，如果 host function 暴露太多，一样会被改造利用。每一层都承担一部分防护任务，攻破一层还有下一层等着，这是沙箱设计里最核心的安全观。

3. Agent 场景下的沙箱，到底长什么样

3.1 代码执行沙箱：Agent 跑代码的“隔离房间”

Agent 场景里最常见的沙箱用途，就是执行模型生成的代码。比如一个数据分析 Agent，你让它“统计这个 CSV 文件里每个地区的数据”，它自己写一段 Python，然后在某个环境里跑，把结果拿回来。这段代码如果直接跑在宿主机上，隐患太大，所以标准的做法是丢进沙箱跑。

一个典型的代码执行沙箱，工作流程是这样的：先把代码放进沙箱环境，沙箱有独立的文件目录；代码运行时需要的依赖，要么预先装好，要么在沙箱内按需安装；执行结束后，沙箱把输出结果回传，随后整个环境被销毁。因为环境是临时的，所以即使运行出问题，也不污染宿主机和其他任务。

这类沙箱有一个关键设计点：代码和数据的交互边界。Agent 执行代码通常需要读取用户数据，但沙箱又不能让模型看到所有数据。所以平台会做一个“数据挂载”机制——只把任务相关的数据放进去，其他文件一律不见。这样既满足执行需求，又保护数据隐私。如果需要写回结果，再把结果从沙箱内“导出”，而不是让沙箱直接访问宿主机文件系统。

3.2 插件与工具沙箱：第三方代码的管控闸门

除了一整段临时代码，Agent 还经常要调用工具和插件，比如访问外部 API、操作浏览器、处理文档。这些工具往往由第三方开发，代码质量参差不齐，也存在被恶意构造的可能。如果不做隔离，一个不可信的插件就可能读宿主文件、触发系统命令、跟代理通道里的敏感数据纠缠。

插件沙箱和代码执行沙箱有一点不同：插件通常不是一次性任务，而是长期存在的“服务”，可能要接入 Agent 的主流程，被反复调用。所以插件沙箱更需要稳定的通信机制，常见的做法是从主进程发起请求，插件沙箱监听消息，处理完把结果回传。两边通过明确的、结构化的数据格式交互，不让插件拥有直接访问 Agent 内部状态的路径。

这类沙箱还有一个值得注意的问题：插件运行需要的依赖很复杂，不可能全都打进一个固定镜像。很多 Agent 框架会把插件本身也当成一个“容器化单元”来管理，启动时动态加载。这样插件之间也是互相隔离的，不会出现插件 A 和插件 B 的依赖冲突，也不会因为一个插件崩溃，把整个 Agent 拖挂。

3.3 网络隔离：Agent 访问世界的权限边界

沙箱隔离里，网络是最敏感也最容易被忽视的一块。一个运行代码的沙箱，如果把网络完全放开，等于给了它控制所有外部通信的能力。恶意的或失控的代码可以直接发起外联，把读取到的数据传出去。所以成熟的沙箱方案在网络上普遍是“默认关闭、按需放行”的策略。

具体做法是，在未授权的情况下，沙箱的网络栈处于隔离状态，对外连接被阻断。当 Agent 确实需要访问某个外部 API 时，由调度层专门开通一条通道，并且做域名白名单限制——只允许访问指定的域名和端口。这个白名单可以是一份配置，也可以在运行时动态更新。

这样做的代价是增加了复杂度：你没法简单地说“让 Agent 用网络”，而是要管理一张“允许访问清单”。但这是值得的，因为网络访问是沙箱最容易被突破的路径之一。很多沙箱逃逸或者数据泄露的案例，最终数据分析链路的起始点都是沙箱内被放开的网络连接。保持网络上的“少即是多”，是比较稳妥的底线。

3.4 机密管理与权限收敛：沙箱外的另一道锁

沙箱隔离的是执行环境，但 Agent 运行过程中，往往还需要访问密钥、Token、数据库密码等机密。如果这些机密直接以环境变量的形式塞进沙箱，那沙箱一旦被攻破，机密就会被窃取。所以现代 Agent 基础设施里，沙箱和机密管理是两套东西，但必须配合使用。

常见的做法是“沙箱内只管请求，机密由沙箱外代签”。沙箱内的代码需要访问某个服务时，不直接持有密钥，而是向一个代理服务发请求，由代理完成身份认证和加密签名，再把结果返回。这样一来，沙箱本身成了“无密钥环境”，即使代码被完全控制，也拿不到真正的密钥，只能按代理允许的策略进行有限的调用。整个过程相当于给沙箱装了“水龙头”，但没有直接给“水源钥匙”。

4. 实操：从零搭一个 Agent 代码执行沙箱

4.1 先想清楚边界：哪些事情沙箱必须保证

动手搭沙箱之前，先花点时间把需求列表列清楚。以最典型的场景为例：要给一个 Agent 提供“执行用户/模型提交的 Python 代码”的服务。沙箱至少要做到这几件事：一，代码不能访问宿主机文件系统，只能看到一个临时工作目录；二，代码不能访问内网和未授权的公网地址；三，代码资源使用受限，不能打满 CPU、吃光内存；四，代码运行必须超时可控，执行完或者超时后环境立刻销毁。如果这四个边界都做到了，这个沙箱已经能应付大多数 Agent 任务。

需求清晰之后，再确定技术路线。如果只是内部使用、对隔离强度要求中等、追求启动速度和部署轻量，那容器方案是最合理的起点。但如果准备做成多租户公开服务，不同用户的代码在同一台机器上运行，那单靠容器就不够稳，需要往轻量虚拟机方向考虑。先明确自己的边界，再选型，别一上来就套最复杂的方案。

4.2 最小可用的容器化沙箱配置

容器方案落地不太难，但要配得齐、配得严，细节不少。下面这份配置基于常见实践，可以作为起点。

docker run -d \ --name sandbox-python \ --network none \ --memory 256m \ --cpus 0.5 \ --pids-limit 64 \ --read-only \ --tmpfs /tmp:rw,size=64m \ --cap-drop ALL \ --security-opt no-new-privileges \ -v workdir:/work \ python:3.12-slim \ python /work/script.py

逐项解释一下这些参数的含义。

--network none直接把容器的网络栈掐掉，沙箱内完全无法对外通信。这一条对安全提升明显，但也意味着需要联网的任务没法跑。如果任务确实需要网络，更合理的做法是给容器接一个受限网桥，配合 iptables 做目标地址过滤。

--memory 256m和--cpus 0.5是资源限制的两条硬边界。前者限制内存使用上限，超出会被内核 OOM 杀掉；后者限制 CPU 配额，保证一个沙箱不会把整台主机的算力吸干。

--pids-limit 64限制进程数量。这个参数很多人会忽略，但它很重要。如果一个脚本里出现 fork 炸弹式的进程创建逻辑，有了这个限制，进程数涨到 64 就会被阻断，不至于拖垮宿主。

--read-only把根文件系统挂载为只读，沙箱内不能随便往系统目录写文件。如果有临时文件需求，用--tmpfs /tmp:rw,size=64m单独提供一个内存临时目录。这样既给了代码“能写东西的地方”，又不让它污染镜像内的系统文件。

--cap-drop ALL和--security-opt no-new-privileges是两条权限收敛设置。前者去掉容器内一切非默认的 Linux capabilities，让容器内的进程没有提权能力；后者防止进程通过 setuid 等手段获得更多权限。配合--user nobody把容器内进程身份限制为普通用户，整个容器的权限就压到了很低。

最后用-v workdir:/work只挂载工作目录，宿主机其他路径一概不可见。脚本代码、输入数据都放在 workdir 里，输出结果也在里面，执行完直接取走。这个设计让沙箱的数据交互边界非常清晰。

4.3 执行流程与调度细节

有了容器配置还不够，一个可用的沙箱服务需要完整的调用流程。参考下面这个链路：

1. 接收任务，把代码和输入数据写入工作目录；
2. 根据环境类型，选择对应的基础镜像；
3. 用默认参数启动容器，确保网络和资源限制生效；
4. 监控容器运行状态，设置超时时间，比如 30 秒；
5. 等待容器退出，收集 stdout、stderr 和返回码；
6. 如果超时，强制docker kill并回收容器；
7. 保存执行日志，清理工作目录和容器对象。

这个流程看起来简单，但有几个容易踩坑的细节。第一，docker run本身有启动开销，如果任务非常短频，每次都现起容器会比较浪费，可以预先准备一个容器池，把已起好的容器预热。第二，监控超时不能用“睡 30 秒再判断”这种笨办法，要用事件监听或异步回调，在容器退出时立刻处理。第三，工作目录的清理要及时，否则这些临时文件会越积越多，把磁盘撑爆。

4.4 CPU 和内存限制的数值怎么拍

很多人搭沙箱时最纠结的其实是参数数值怎么定。这个没有标准答案，要结合任务画像。比如一个数据分析 Agent，跑 pandas 脚本处理几万行数据，内存峰值一般在 100MB 到 300MB 之间，给 512MB 是合理的；如果跑机器学习推理，那就要单独规划，可能直接分配 2GB 以上。

CPU 配额同理，如果是 IO 密集型的脚本，0.5 核就够；如果是纯计算型的算法题，1 核或 2 核更合适。关键是要有“分级资源池”的概念——把沙箱按资源档位划分，小任务进小池子，大任务进大池子，而不是所有任务共用同一套配置。分级的好处是既保证绝大部分任务的流畅性，又不会让单个任务占满机器。

有个经验值是，内存上限可以拍到任务预估峰值的 1.5 到 2 倍，太低会导致正常任务被误杀，太高又会让异常任务的破坏范围变大。超时时间也要分级，简单的代码执行给 10 秒，复杂的分析任务可以给到 60 秒甚至更久。

4.5 一层沙箱不够，再加一层策略

容器化的沙箱解决了“执行环境隔离”的问题，但还有两个缺口需要补上。

第一个缺口是代码内容层面的策略。模型生成的代码可能本身包含危险操作，比如尝试打开/etc/passwd、调用subprocess、使用eval执行字符串。容器隔离虽然能限制这些操作的实际影响，但更好的做法是在代码进入沙箱前，先做一次静态扫描，把明显危险的操作拦截掉。当然静态扫描不是万能的，所以它应该作为“辅助过滤”，而不是唯一防线。

第二个缺口是数据面的隔离。如果多个用户的任务在同一个沙箱池里跑，虽然容器之间是隔离的，但工作目录挂载在宿主机上，必须确保不同任务使用不同的目录，并且权限严格限定。更不能把所有任务都挂载到同一个workdir，那等于给所有代码开了一扇共享的窗户。这部分需要在上层调度逻辑里处理好，沙箱本身不管。

5. 常见问题与排查实录

5.1 容器逃逸到底离我们多远

聊沙箱，很多人第一反应就问：容器能逃逸吗？答案跟绝大多数安全问题的答案一样：理论上能。容器和宿主机共享内核，这意味着只要内核存在可利用的漏洞，沙箱内代码就有机会通过系统调用序列实现权限提升甚至逃逸。

不过要纠正一个误区：绝大多数人担心的是“黑客写出逃逸代码”，但 Agent 场景下更常见的风险是“模型输出触发了非预期行为”。比如模型生成了调用某类系统接口的代码，这些接口在沙箱策略里没被明确禁止，于是代码拿到了不应该有的能力。这不算经典意义的逃逸，但同样危险。所以除了关注内核漏洞，更要关注沙箱策略本身的完整度和合法性，以及模型输出内容是否在沙箱安全边界内。

从实操层面讲，如果要做多租户公开服务，别把宝全押在纯容器上。要么叠加用户态内核方案（比如 gVisor 这类），要么直接上轻量虚拟机，让每个用户的代码跑在独立的内核之上。这是成本换安全的经典取舍。

5.2 超时之后，任务真的被清理干净了吗

沙箱最常出问题的点，不是启动慢，而是“清理不干净”。假设一个容器跑了 60 秒超时，你执行了docker kill，容器是停了，但挂在宿主机的工作目录里可能还残留着脚本生成的临时文件。如果里面有敏感数据，那这些数据就躺在宿主机上等着被清理，这本身就是一种泄露风险。

解决思路是让工作目录本身也是一个“临时挂载”而不是固定目录。做法有两个：一是直接用--tmpfs挂载工作目录，容器停止后数据直接消失，这是最彻底的清理；二是用命名约定加定期巡检，把所有超过存活时间的临时目录批量删除。前者更干净，但数据不能持久化；后者需要额外维护一套清理任务。两者权衡下来，只要不是必须保留中间产物，用tmpfs方案更省心。

还有一类隐藏坑：容器日志。如果容器内代码疯狂print，日志文件会迅速变大。一定要配置日志轮转和大小上限，别让日志成为磁盘的新黑洞。

5.3 沙箱内不能联网，但任务需要联网怎么办

前面提到--network none是最安全的选择，但现实中的任务往往需要访问外部服务——调用第三方搜索 API、拉取依赖包、连接数据库。这时候就得在“不联网”和“放开网络”之间找平衡。

我的建议是分级开放。第一级是“完全隔离”，适合纯计算和数据处理任务；第二级是“代理放行”，沙箱内不能直连外部，而是通过宿主机的代理服务转发，代理那边做域名白名单和流量审计；第三级是“受限直连”，通过 iptables 规则允许容器访问特定 IP 和端口，其他的一律拒绝。从安全角度看，代理放行是最值得推荐的，因为所有外联都经过一个唯一出口，审计起来非常清晰，且沙箱本身始终拿不到真实的网络通道。

5.4 冷启动慢，怎么优化沙箱的启动体验

Agent 任务往往要求响应快，如果每个任务都要现拉镜像、现起容器，等待时间会很明显。实测下来，一个 Python 镜像从拉取到容器启动完成，在本地磁盘也要一两秒，如果镜像没有预热，冷启动甚至到几十秒。

优化方向有这么几个：一是镜像尽量小，用精简基础镜像，把不常用的依赖放外面，按需安装；二是预热，启动几个“预完成”的容器放在池子里，接到任务直接复用或者快速复制；三是如果用的是轻量虚拟机方案，保持底层微虚拟机的快照预热，新任务通过快照克隆的方式拉起新的实例。这些优化能不能做，取决于你的资源丰裕程度，但思路是一致的：别等任务来了才准备环境，让环境始终处于“待命中”的状态。

5.5 常见问题速查表

6. 关于沙箱，我最后想说的

聊了这么多原理和方案，回到最初的问题：Agent 挂在嘴边的沙箱，到底是个啥？我的理解是，沙箱本质上是一种“信托机制”——它不解决模型是否聪明、是否听话的问题，而解决“即使模型或工具出去了，伤害也控制在一个预定范围”的问题。这个范围可能是几个 CPU 核心、一个临时目录、一组白名单 API，也可能是完整的独立虚拟机。范围划多大，取决于你要保护什么，愿意付出多少代价。

还有一个观察想分享：很多人把沙箱当成一次性的配置，配好了就再也不管。但沙箱体系其实是要持续维护的——模型在变，Agent 调用工具的路径在变，攻击手段也在变。你需要定期审视沙箱策略，看是不是有新的工具需要纳入、是不是有端口需要关闭、是不是有旧的镜像还在占用资源。把沙箱当成基础设施去运维，而不是当成“写一次就忘”的安全按钮，这才是长期真正放心用 Agent 的前提条件。

最后说一句实操建议：如果这是你做 Agent 服务的起点，不用一上来就追求最强的隔离方案。先用容器化沙箱把流程跑通，把执行、超时、日志、清理这四个基础链路做好，再根据实际场景逐步叠加更强的隔离层。过程中你会踩一些坑，但这些坑会帮你把沙箱边界打磨得越来越清楚。沙箱不是目的，让人能放心地把事情交给 Agent，才是目的。