做 AI 应用的同学应该都有类似经历：你的 Agent 要跑 Python 代码，但代码是模型现场生成的，也可能是用户上传的，本地不敢跑、线上裸奔更危险，最后选了 E2B 沙箱来兜底。E2B 这类沙箱环境用起来确实顺手，很多前沿 AI 产品在做代码生成与执行时都会用它做隔离层。但用久了你会发现，沙箱不是一台怎么折腾都不会坏的虚拟机——一旦失控，命令迟迟不返回、磁盘被打满、上下文悄悄失联，整个 Agent 链路直接卡死，这时候别说业务保住了，日志里连个像样的报错都没有。

这篇文章就是我把生产环境里踩过的 E2B 沙箱失控坑，以及完整的排查与治理方案，整理成一份可以直接抄的实战笔记。适合已经接入或者准备接入 E2B 的 AI 应用开发者和平台工程师，尤其是正在被“沙箱里跑着跑着就没了响应”折磨的同学。

1. 先弄明白：E2B 沙箱到底在替你扛什么

1.1 一个 AI 应用的代码执行困境

先还原一个典型场景。你的 AI 应用可能在做类似这样的事：用户上传一份 CSV，LLM 分析后生成一段 Python 代码，你的服务端要把这段代码跑起来，拿到结果再喂给模型继续生成报告。

问题来了：这段代码不是预先写好的，而是模型现场生成的，本身就有语法错误、逻辑错误甚至恶意行为的可能。用户上传的数据也可能是精心构造的攻击样本。如果你直接在业务服务器上exec这段代码，等于把整条服务链路的安全命脉交到了一个不可信输入手里——轻则内存被打满，重则服务器被拿下。

传统的做法是自己维护一个代码执行环境：开一台隔离 VM，装好 Python 和依赖，把代码传进去跑。听起来不复杂，但真正做起来全是琐碎活：VM 启动要几十秒、环境镜像要自己维护、并发时要排队、资源回收不及时还会堆积一堆僵尸机器。E2B 本质上就是把这件事做成了托管服务——你通过 SDK 在云端启动一个轻量沙箱，在沙箱里执行代码、读写文件、运行服务，一切都和操作一台 Linux 机器一样，但不用自己去维护底层的隔离设施。

1.2 E2B 的方案：微虚拟机而不是进程容器

E2B 的底层是 Firecracker 这类微虚拟机技术。和 Docker 容器最大的区别在于：容器和宿主机共享一个内核，你的代码、依赖、系统调用都经过这个共享内核兜着；微虚拟机则拥有独立的内核、独立的内存、独立的磁盘视图，相当于给每个 Agent 任务发了一整台微型“物理机”。

这个设计在安全模型上很关键。容器适合“应用内隔离”，比如把 Web 服务和数据库分开；但对于“执行不可信代码”这种高危场景，容器还不足以让人放心。微虚拟机把逃逸攻击面大幅收窄，就算沙箱里面的代码把自己玩炸了，也炸不到宿主机和别的沙箱。

可以用一个生活化的类比：容器像几个人合租一套房，共用承重墙和下水道，一个人半夜蹦迪，全楼都能感觉到；微虚拟机像每人一栋独栋别墅，墙壁是实心的，邻居装修再吵，你在自己屋子里该干嘛干嘛。独栋的缺点是：坏了得自己修，没人帮你扛着。这恰恰引出了本篇文章的主题——沙箱失控。隔离环境保护的是外部系统不受沙箱影响，但如果沙箱内部的进程疯了、资源满了、状态坏了，你的 Agent 依然会被卡死在外面。

2. 沙箱失控的三种典型表现

我见过的 E2B 沙箱失控，基本跑不出下面这三种形态。提前认识它们，遇到的时候就不会一脸懵。

2.1 命令卡死：执行到一半就没人回话

最经典的表现：你的 Agent 调用sbx.commands.run("python train.py")，请求发出去了，然后就没有然后了。十秒、三十秒、一分钟，回调始终不触发。SDK 层可能已经抛了TimeoutExpired，但你以为“超时了就完事了”——并没有，沙箱里那个进程还在跑。它可能进入了死循环、在等待一个锁、或者卡在一个永远不返回的网络请求上。

这种“命令卡死但沙箱活着”的状态最坑人。连接是通的，控制台显示沙箱运行中，但里面已经乱成一锅粥。更麻烦的是，新任务如果复用了这个沙箱，会跟着一起卡住，因为资源都被旧进程霸占着。我在实际中见过一个案例：某个 Agent 服务突然大批量超时，控制台上看沙箱 CPU 使用率飙到 90% 以上，却没有任何活跃任务在跑——就是前面的任务进程没被杀干净，在后台疯狂空转。

2.2 资源被吃光：内存、磁盘、CPU 谁先爆谁说了算

E2B 的沙箱本身有资源配额，但配额上限和“你想让它在什么阈值内优雅运行”是两回事。我遇到过最离谱的一次，是一个数据处理脚本把 20GB 垃圾数据写进了/tmp，直接把沙箱的虚拟磁盘写满。磁盘满之后，文件系统进入一种半死不活的状态：执行命令还能勉强返回，但任何涉及文件读写的操作都开始报错或者长时间卡住。

内存也是一个重灾区。沙箱内跑 Python 脚本时，如果某个list没有上限地append，内存很快就会被吃光。内存耗尽后沙箱不会立刻死掉，而是变得极其迟钝，连files.list这种轻量操作都要几十秒才响应。CPU 则是最隐蔽的：进程跑满了 CPU，但沙箱在控制台上看起来完全正常，只有你仔细看监控才发现 CPU 曲线已经是平的一条直线。

2.3 上下文与连接互相失联

E2B 沙箱是有生命周期的，不是永远挂在云端等你。默认情况下，如果你的服务端和沙箱的 SDK 连接断开，沙箱会按照既定策略被回收；即使你想保留，也需要显式开启持久化并设置好断开容忍时间。

这里有一个非常经典的坑：你的 Agent 在一个长任务流程里创建了沙箱，中间服务重启了或者网络闪断了几分钟，SDK 连接断了，沙箱被回收了。等流程恢复后，你想重新连回那个沙箱继续跑，发现找不回来了。如果这个沙箱里存着重要的中间结果或者状态，数据就跟你一起消失了。

更隐蔽的是多上下文的失联。如果你在同一个沙箱实例里创建了多个执行上下文（Context），它们共享沙箱的资源但又各自维护状态。某个上下文崩溃或者进入死循环，拖累的却是整个沙箱上所有任务的执行效率，而你从外面看只能看到“沙箱变慢了”，很难定位到底是哪个上下文在搞事。

3. 实战：一次失控现场的完整排查过程

说了这么多理论，不如完整复盘一次真实的失控现场。这个案例我印象很深，因为它表面上看起来“什么都没有发生”，但生产环境已经被堵死了。

3.1 问题复盘：从一次“什么都没做”的清任务开始

某团队跑了一个数据分析 Agent 服务。某天上午，线上突然开始大量告警——所有任务都卡在“等待代码执行结果”这个阶段，新任务不断排进队列，但一个都出不来。

第一反应是检查服务日志，结果日志里没有任何异常堆栈，只有一条条 SDK 超时记录。这反而说明问题不在应用层，而在下层：有人怀疑是 E2B API 挂了，有人怀疑是网络问题。排查了半天，最后打开 E2B 控制台一看，沙箱列表里躺着一批仍在“运行中”的沙箱，其中一台的 CPU 使用率一直在 90% 以上。可诡异的是，那个沙箱对应的任务早就应该在半小时前结束了。

这个场景是不是很熟悉？任务不该跑了，但沙箱里还在疯狂运转。控制台显示“运行中”，其实内部已经失控。表面上你什么都没做，但它自己停不下来。

3.2 用日志反推失控链路

排查的第一件事，是确认 SDK 连接本身是不是好的。我在本地用同一套 API Key 连了一下沙箱：

from e2b import Sandbox sbx = Sandbox() # 先确认连接是否正常、沙箱是否活着 print(sbx.files.list("/tmp"))

如果这行代码能正常返回，说明 SDK 到沙箱的链路是通的，问题不在网络，而在沙箱内部。接下来是看一眼沙箱里面到底在跑什么东西：

# 拿回控制权，随便执行一条命令看看回不回应 result = sbx.commands.run("ps aux --sort=-%cpu | head -20", action_timeout=5) print(result.stdout)

执行结果返回了一长串进程列表，排在最前面的那个进程就是罪魁祸首，CPU 使用率 100%，命令行显示它还在跑一个已经过期很久的数据处理脚本。到这一步，失控链路已经清楚了：某个任务的执行体没有被正确终止，在沙箱里面空转了半个多小时，吃光了 CPU，导致同一沙箱上后面所有新任务的执行都得不到资源，全部排队超时。

再说为什么“死循环的进程”没有被杀掉。根本原因是创建任务时没有设置任何超时保护和任务终止机制。SDK 提供的action_timeout默认行为只覆盖了“等待命令返回”的阶段，一旦超时，客户端会放弃等待，但沙箱里的进程本身并没有被自动终止。如果你没有在异常处理逻辑里显式去 kill 那个上下文，它就永远留在那里，直到沙箱被销毁。

3.3 定位根因：三个致命遗漏

复盘整条链路，最后定位到三个被所有人忽略的点：

第一个，所有执行动作都没有显式设置action_timeout，也没有在超时后做进程清理。开发时本地网络好、进程快，感觉不到问题；一到生产环境，某个任务稍微慢一点，超时连接一断，进程就成了漏网之鱼。

第二个，沙箱里的执行上下文没有主动管理。任务执行完没有kill上下文的逻辑，任务异常了也没有兜底清理。多个任务复用同一个沙箱，上下文之间互相干扰，一个任务污染了沙箱状态，后续所有任务都得跟着遭殃。

第三个，沙箱本身没有生命周期守卫。服务端进程崩溃后，已经创建出来的沙箱没有人负责回收。那次事故里，积压的僵尸沙箱占了小一半资源，变相把其他正常沙箱的可用资源挤小了。

这三个问题单独看都是小事，合在一起就是事故。排查的结论也印证了一件事：E2B 给你的只是一台干净好用的微型虚拟机，但把虚拟机管成什么样，完全取决于你自己的工程能力。

4. 破解沙箱失控的四个核心操作

找到根因之后，问题就变成了怎么修。下面这四件事是我认为治理 E2B 沙箱失控必须做到位的核心操作，每一项都有代码可以直接抄。

4.1 给每个执行动作加上超时保险丝

E2B 的 SDK 允许你在创建沙箱和运行命令时都指定超时时间。你要做的不只是把这个参数填上，更重要的是理解它的边界：

from e2b import Sandbox # 创建沙箱时给出默认超时 sbx = Sandbox(action_timeout=10) # 单次执行覆盖超时设置，防止个别长任务卡死 result = sbx.commands.run("python train.py", action_timeout=30)

这里容易有个误解：你设置了 30 秒超时，SDK 在 30 秒后抛了超时异常，你就以为“任务是超时了，已经被系统清理了”。实际上 E2B 侧的执行进程大概率还活着。action_timeout只是客户端侧的等待上限，服务端并不会因为客户端不等了就自动杀掉进程。

所以正确的做法是：把“超时抛异常”当成一个触发信号，异常处理逻辑里紧接着去查杀沙箱里的上下文，而不是直接放弃。类似这样：

from e2b import Sandbox sbx = Sandbox() try: result = sbx.commands.run("python train.py", action_timeout=10) except TimeoutError: # 超时后必须主动清理沙箱内的执行上下文 for ctx in sbx.contexts.list(): ctx.kill() # 然后根据业务决定是重试还是标记失败 raise

我特别强调一点：超时不是用来“等”的，是用来“杀”的。这也是我认为 E2B 沙箱治理中最重要的一个观念转变。

4.2 带上资源限制，别让沙箱变成无底洞

E2B 第二层防线是资源配额。在创建沙箱模板的时候，你应该明确 CPU、内存、磁盘的上限。不要觉得“反正有配额，跑满也没关系”——这个想法在隔离环境里同样危险，因为一个沙箱吃满自己的配额后，会变得完全不可用，你的 Agent 任务照样执行不下去。

除了平台侧配额，更实用的一招是在沙箱内部给具体进程套上resource限制：

import resource import os def limit_resources(): # 把单进程可用内存限制到 512MB memory_limit = 512 * 1024 * 1024 resource.setrlimit(resource.RLIMIT_AS, (memory_limit, memory_limit)) # 打开文件数限制 file_limit = 256 resource.setrlimit(resource.RLIMIT_NOFILE, (file_limit, file_limit)) # 在沙箱内执行任务前先调用这个函数做兜底 sbx.commands.run("python -c 'import resource; ...'", action_timeout=10)

这招相当于给失控进程上了一道“防火墙”：即使某个脚本的while True在疯狂申请内存，到 512MB 就会被系统直接拒绝，进程崩溃退出，而不是把整个沙箱拖垮。同理，磁盘可以做一个定期检查任务，监控/tmp和/home目录的占用，超过阈值就清理或者告警。

4.3 用 SDK 主动管理上下文生命周期

E2B 沙箱内部可以创建多个上下文，每个上下文代表一次独立的执行环境。默认情况下，如果你用sbx.commands.run()直接跑命令，SDK 会返回一个结果对象，但上下文会一直留在沙箱里，直到沙箱销毁。

生产环境我建议的模型是：每个任务一个独立上下文，任务结束立刻杀掉上下文，不让它多活一秒钟。具体做法是用后台模式把控制权拿回来，然后主动查杀：

from e2b import Sandbox sbx = Sandbox() # 后台运行长任务，拿到上下文ID ctx = sbx.commands.run("python long_task.py", background=True) # 业务判断超时或失败后，按ID精确清理 for c in sbx.contexts.list(): if c.id == ctx.id: c.kill() # 或者干脆粗暴一点，清理当前沙箱所有残留上下文 for c in sbx.contexts.list(): c.kill()

用background=True的好处是：长任务不会一直占住 SDK 的连接，你可以同时执行其他操作，比如监控进度、发起另一个任务，或者决定要不要终止这个任务。如果你只用前台模式，一个卡死的命令就会把你的整个 Agent 流程锁死，因为后续代码根本不会继续执行。

上下文生命周期管理这件事，如果你们用的是同一个沙箱跑多个任务，还要考虑并发冲突的问题。最稳妥的做法是“一个任务就开一个全新沙箱”，用完就销毁，不让状态在任务之间交叉污染。

4.4 持久化与非持久化沙箱的职责拆分

E2B 沙箱的默认生命周期是服务端连接断开后自动关闭。如果你需要沙箱在客户端断开后继续存活，必须显式开启持久化，并设置disconnect_timeout：

from e2b import Sandbox # 需要长期保存状态的沙箱，持久化并设置断线保留时间 sbx = Sandbox(persist=True, disconnect_timeout=3600) # 等待持久化生效，避免进程退出后沙箱依然被回收 sbx.wait_for_persistence()

这里的wait_for_persistence()很关键。某些情况下沙箱创建成功不等于持久化完成，如果你不等它确认就继续跑业务，进程一旦退出了，沙箱可能还是会按默认策略被回收。

什么样的场景应该用持久化沙箱？答案是：需要保留安装的依赖、下载的数据、产生的中间结果，并且下一次任务还要继续用这个环境的场景。比如一个数据清洗 Agent，先下载数据、装好依赖，然后等人工确认后再跑下一步——这个时候沙箱必须持久化，否则两步之间网络闪断一下，前面准备的依赖和文件就全没了。

反过来说，临时执行一次代码、跑完就走、结果同步到对象存储的任务，完全不需要持久化。每次新建沙箱、用完销毁，是最省心的方案。有些团队为了省启动时间会复用沙箱，结果省下来的时间全花在排查上下文冲突上了，得不偿失。

5. 常见问题速查与排查技巧

我把实际踩过的坑整理成一张速查表，遇到问题先对号入座，能省下很多排查时间。

5.1 沙箱启动慢或假死

沙箱启动本身一般不会超过两三秒，如果明显变慢，大概率是宿主机资源紧张，或者你请求的模板规格超过了当前可用资源。这时候不要反复创建新沙箱，更不要盲目调大模板配额，先检查控制台上是不是堆了一大堆“运行中”的僵尸沙箱。把这些清理掉，再看启动时间是否恢复正常。

5.2 文件上传失败和挂载丢失

E2B 的沙箱每次新建都是全新环境，不会自动带上你本地的文件。写入之前必须确认目标路径的父目录是存在的：

from e2b import Sandbox sbx = Sandbox() content = open("./report.csv", "rb").read() # 先创建目录再写入，避免路径不存在的报错 sbx.files.write("/home/user/data/report.csv", content)

如果写入失败，优先排查磁盘剩余空间。我见过一个场景是某脚本反复写文件又不清理，磁盘悄悄满了，结果所有新增写入都失败，而读取还能正常返回，导致排查时一度以为只是“权限问题”。

5.3 会话超时的坑

关于断线后的保留时间，核心是理解三个参数的搭配：persist控制沙箱是否在断线后继续存活，disconnect_timeout控制断线后最多保留多久，wait_for_persistence控制创建时是否等到持久化完成。只开persist不给disconnect_timeout，沙箱可能被无限保留，白白占着资源。只给超时不开持久化，那超时时间再长也没用，沙箱照样当断线就回收。生产环境建议根据任务的最大耗时来设置，比如任务最长跑 20 分钟，就设 40 分钟，留一倍余量，既不会过早回收，也不会无限占用。

6. 我的经验总结与实践建议

复盘这几次 E2B 沙箱失控的经历，我最大的体会是：E2B 本身是一个很好用的工具，但它只解决“给你一台干净的隔离环境”这件事，不解决“这台机器在你业务里的生命周期管理”这件事。你把一台虚拟机交给一个粗心的 Agent 去用，又不给它任何护栏，失控是必然的，只是时间问题。

现在我接手相关的沙箱治理项目时，会先检查三条底线，你可以对照自己的项目看一下：

第一条，所有执行动作必须有超时，而且超时后的第一动作必须是清理，不是记日志。

第二条，沙箱的创建和销毁必须是代码里的确定性逻辑，放在try/finally里，不管任务成功还是异常，沙箱最终都会被回收。

第三条，把“状态”搬出沙箱。中间结果落到对象存储，配置依赖固化到模板，让沙箱本身永远是廉价、可再生的。这样就算某个沙箱彻底失控，销毁重建的成本也几乎为零。

最后再分享一个小技巧：我习惯在沙箱模板里预装一个healthcheck.sh脚本，用来快速探测沙箱是否“活着”。检测方法很简单，输出当前时间和可用的磁盘空间，再跑几行内存统计。一旦感觉到沙箱不对劲，先执行这个脚本，三秒钟就能判断是“假死”还是“真卡死”，比打开控制台翻曲线省事得多。