AI智能体沙箱失控排查与治理：从限额熔断到网络边界

上周凌晨两点，我盯着监控面板上一排排“活着”的沙箱，CPU 曲线齐刷刷顶满 100%，队列里的任务全部卡在原地。这种场景做 AI 智能体工程的人应该都不陌生：你把一个看似安全的隔离环境交给模型生成的代码，它却成了失控的温床——死循环、疯狂写盘、拼命往外部发请求，甚至尝试读取不该碰的环境变量。我长期用 E2B 这类沙箱运行时来搭建智能体的可执行环境，今天想把“沙箱失控”这件事拆开讲清楚：失控到底发生在哪一层，怎么一步步定位根因，以及如何配置限额、熔断和网络边界，把 AI 智能体运行环境的陷阱提前堵住。

1. 先别急着重启：沙箱失控到底是在哪一层失控

很多人在沙箱出问题时第一反应是“杀进程、重启沙箱”，但这只是在处理症状。想要真正破解运行环境陷阱，得先明确失控的对象是什么。

1.1 失控的三种形态：算力、资源、行为

我通常把失控分成三类，它们的表现、危害和修复方式完全不同。

第一种是算力失控。最常见的形态是模型生成的代码里出现死循环，比如一个爬虫任务里写了while True却忘了退出条件，或者某个递归函数没有基线判断。表现是 CPU 持续 100%，任务迟迟不返回，一个沙箱把它配给的 vCPU 全部吃满。

第二种是资源失控。这类更隐蔽，CPU 可能不高，但内存不断增长，或者日志文件、临时文件、下载缓存把磁盘一点点塞满。典型场景是智能体在一轮推理里反复执行同一段代码，每次都在磁盘上追加几 MB 数据，几十轮下来沙箱就撑爆了。资源失控的可怕之处在于它不会立刻暴露错误，而是让沙箱越来越慢，最后整个任务超时，你回头看日志才发现磁盘早就满了。

第三种是行为失控，这是最值得警惕的。代码本身可能没有死循环，也没有吃爆资源，但智能体开始调用不该调用的能力——尝试读取环境变量里的密钥、向外部服务器发包、修改关键配置文件、甚至执行卸载或清盘命令。这类失控往往不是语法错误，而是提示注入或权限设计出了问题。

1.2 为什么 AI 智能体的沙箱比 CI 沙箱更容易失控

传统 CI 里的沙箱跑的是人写的、经过 Review 的代码，沙箱主要是防止测试污染宿主环境。AI 智能体沙箱完全反过来：代码是模型现场生成的，没人提前 review，输入里还混着从网页、文档、邮件里抓来的不可信内容。

模型生成的代码有两个致命特点：开放性和不可预测性。它可能根据上下文现场发明一个 API 用法，可能把任务描述里的“尽量重试”理解成“无限重试”，也可能被一段藏在网页里的指令牵着走。也就是说，失控的风险不是代码写错了，而是“代码写对了但任务定义错了”和“代码被人为诱导错了”。

沙箱能解决的是“代码跑飞了不会炸掉宿主机”，但它解决不了“代码没跑飞但一直在花你的钱、偷你的数据、做不该做的事”。理解这条边界，是后面所有方案设计的前提。

2. 定位失控现场：一条可复现的排查链路

遇到沙箱失控，别急着杀掉重启。先保留现场，否则你什么都学不到，也改不了根因。

2.1 先从指标下手，别靠肉眼猜

我处理过不少“沙箱卡死”的诉求，一半以上是假卡死——要么任务在等待外部 API 响应，要么模型在长思考，只是没有阶段性日志输出。所以第一步永远是看指标，而不是看表象。

建议在智能体协调层给每个沙箱维护一张运行状态表，下面是我常用的观测维度：

如果是 E2B 这类云沙箱，可以先用平台侧的状态接口和 SDK 拿到资源使用快照；如果拿不到精细指标，就直接在沙箱里跑诊断命令。

2.2 进沙箱看进程树和网络连接

拿到沙箱 ID 之后，我一般会通过 SDK 的进程执行能力进去做一次“现场取证”，诊断命令本身是无害的：

ps auxf df -h free -m cat /proc/*/cmdline ls -la /tmp /var/log

进程树是判断失控类型最直接的证据。while True死循环通常会有一个进程的 CPU 时间持续增长，同时进程数不多；如果是“智能体不断派生新任务”，进程树会变得很深，父子关系一目了然。

接着看网络连接。如果平台允许在沙箱内执行命令，可以查一下活动的连接和监听端口；如果不允许，也可以在协调层记录每次工具调用的入参出参，反查出网流量集中在哪个时间点。定位到某个可疑进程后，记住它的 PID、父进程、启动参数，再回放日志里对应时间点的操作，基本就能把失控的触发点锁定了。

2.3 回溯最近的工具调用链，区分模型循环与代码死循环

这一步最关键。同样表现为“沙箱长时间不返回”，根因可能是两类完全不同的循环：

• 代码死循环：某一次工具调用生成的代码本身进入了死循环，CPU 被单个进程打满。修复方向是给单次代码执行加超时、加资源上限、代码审查规则里增加循环保护。
• 模型决策循环：每次代码执行都正常返回了，但智能体反复调用同一个工具，参数几乎不变，永远不收敛到最终答案。这时候 CPU 不高，问题出在提示词、工具定义或停止条件上。

区分方法很简单：把最近 5 到 10 次工具调用记录按时间排序，如果看到同一种调用模式不断重复，就是模型决策循环；如果某一次调用开始后沙箱就再没响应，就是代码死循环。修模型循环不能靠加沙箱超时解决，得在协调层增加“最大工具调用次数”和“结果相似度检查”，这个后面细讲。

3. E2B 沙箱到底隔离了什么：边界与责任划分

用 E2B 这类沙箱运行时之前，必须先搞清楚“平台帮你隔离了什么，剩下的是不是都要自己扛”。很多失控事故其实是把平台的隔离能力用错了方向。

3.1 microVM 隔离：平台给了你什么

E2B 底层的核心是微虚拟机方案。和传统容器不同，每个沙箱是一个轻量级虚拟机，拥有独立内核，和宿主机之间有更硬的隔离边界。这意味着沙箱内代码即使通过提权拿到了 root，也很难直接影响宿主机；沙箱崩溃也不会牵连同一个宿主上的其他沙箱。对 AI 智能体场景来说，这个思路非常对——因为模型生成的代码本质上就是“不可信代码”，必须按最坏情况假设来隔离。

为什么不用普通容器？容器共享宿主内核，安全上高度依赖 seccomp、cgroup 等一系列加固措施，配置稍微漏一项，出问题的概率就上来了。AI 生成的代码行为不可预测，优先选择隔离边界更清晰的方案更稳妥。当然，微虚拟机的代价是每次启动有额外开销，所以 E2B 这类服务通常会提供模板预热和快速恢复机制，把启动时间压缩到可接受范围。

3.2 文件系统、模板与网络边界：什么是临时的

沙箱里的文件系统通常是临时的，它的生命周期跟随沙箱。沙箱销毁后，里面写的东西就没了。很多人第一次用的时候会踩坑：让智能体把中间结果写到/tmp/result.json，结果沙箱重启后文件全部消失。

正确做法是：沙箱只做“执行”，产物要用文件系统 API 主动拉回来，或者上传到外部存储。我在设计任务时经常用下面的模式：

# 以 Python SDK 为例，示意参数以所使用版本为准 try: result = sbx.run_code(code, timeout=15) artifacts = sbx.filesystem.list("/output") for path in artifacts: content = sbx.filesystem.read(path) save_to_external_store(path, content) finally: sbx.kill()

另外就是模板。E2B 支持基于模板创建沙箱，模板相当于预装好依赖的镜像。模板是相对不可变的，沙箱内改动不会反向污染模板，这是好事，但也意味着“每次都要从模板重新开始”。不要指望把 Python 环境装好之后在沙箱里长期保存状态，有状态的东西应该放在沙箱外面的协调层。

3.3 沙箱兜得住宿主，兜不住预算和声誉

这是整个文章里我最想强调的一点：沙箱隔离了代码对宿主的影响，但不隔离“代码对任务的伤害”。

一个失控的沙箱可能花掉大量算力费用；一个被提示注入的智能体可能把内部数据发到外部服务器；一个行为失控的智能体可能以你的服务身份对外发出大量请求，被人当成攻击源。这些都不是沙箱的隔离能力能解决的，因为从沙箱的角度看，代码只是“按指令执行了”，是“正常”的。

所以安全模型必须分层：沙箱做运行隔离，协调层做行为治理。只靠沙箱兜底、不建行为治理体系，等于把安全全部押在“代码不会乱跑”这个假设上，而这个假设对 AI 智能体来说天然不成立。

4. 给智能体装刹车：限额、熔断与网络策略

下面这部分是实操重点。我在生产环境里的配置思路可以概括成一句话：每个维度都设上限，每个上限都有兜底，每个兜底都要有人类的复核入口。

4.1 沙箱级限额：从创建到每次执行都要设 timeout

最基础的刹车是超时。我见过太多只给“任务总超时”却不给“单次代码执行超时”的例子，结果就是一次死循环直接吃光整个任务预算。

正确做法是双层超时：

# 沙箱整体生命周期设置上限 sbx = Sandbox.create( template="agent-base-v7", timeout=180, # 具体参数名以所使用 SDK 版本为准 ) # 单次代码执行单独设置更小的超时 result = sbx.run_code(code, timeout=15)

单次执行超时一定要明显小于沙箱生命周期超时，这样即使某一次代码死循环，也只会浪费十几秒，之后协调层能捕获超时异常、记录现场、决定是重试还是终止。同时，创建沙箱的地方建议统一收敛到一个工厂函数，把 timeout、资源限制、网络策略都固化进去，避免业务代码到处 new Sandbox 忘了传参。

4.2 任务级熔断：在协调层做兜底

沙箱限额只是第一层刹车，真正可靠的兜底在协调层。我给每个智能体任务加了三个计数器：

• 最大工具调用次数，默认 30 次，超了强制进入“总结”阶段；
• 任务总持续时间，超了就终止所有相关沙箱并保留现场；
• 单次轮次的 token 消耗预算，防止模型在一个问题上反复自我修正。

这三个计数器配合队列限流一起用。比如同时最多允许 10 个沙箱运行，按智能体维度做速率限制，防止一次批量任务突然拉起上百个沙箱，把接口配额和账单同时打爆。熔断触发后，不要只打印一条日志就算了，要把沙箱里的产物和日志归档，方便后面复盘。

4.3 网络出口策略：默认断网，按需放行

模型生成的代码天然喜欢“访问网页验证一下”，但大多数任务其实不要求智能体直接联网。我会把网络出口设计成默认关闭，按需放行。

具体落地看平台能力：如果沙箱能配置网络策略，就直接在模板或创建参数里关闭出网，只对任务需要访问的少数域名放行。如果平台不提供细粒度网络开关，就设置一个受控的转发层，所有外部访问都走这个通道，由协调层统一记录请求目标、响应大小和耗时，同时拦截内网地址，避免智能体隔着沙箱探测内网。

很多失控事故的根源就是“沙箱可以自由出网”。默认断网之后，即使代码被注入诱导，能造成的破坏面也小很多。对于确实需要联网的任务，再对单个工具显式授权。

4.4 密钥与敏感信息：别把钥匙放在保险柜里

这节必须单独说，因为这是最常见的“隐蔽失控”。很多人把 API Key 直接写进沙箱环境变量，然后模型生成的代码一旦能读取环境变量，这些密钥就等于公开了——沙箱里跑的每一行代码都不可信。

我的原则是：

• 沙箱环境变量里只放任务 ID、临时会话信息这类低敏感数据；
• 真实密钥放在协调层托管的密钥服务里，智能体需要调用外部 API 时，由协调层用一个短时效的、限定权限的凭证代为执行；
• 日志里统一做脱敏，凡是出现疑似密钥、Token 的字段一律打码；
• 模板镜像里绝对不烧录任何长期密钥。

这样即使沙箱被完全攻破，攻击者拿到的也只是一个临时凭证，影响范围可控。

5. 三次真实失控复盘：现象、根因与修复

理论讲再多，不如看几个实际案例。下面这三个失控事件我把敏感信息全部脱敏了，但排查思路完整保留，都是我在真实项目中处理的。

5.1 一次性放出的 17 个死循环沙箱

现象：一个批量数据处理任务，调度器一次性拉起 17 个沙箱，不到十分钟，所有沙箱 CPU 全部 100%，任务队列整体阻塞。

排查过程：先看指标，确认是算力失控；进其中一个沙箱执行ps auxf，发现每个沙箱里都有一个 Python 进程占用全部 CPU，启动参数指向同一个脚本。回溯工具调用记录，定位到模型为了“下载并解析一个 CSV 文件”生成了带while True重试逻辑的代码，且没有设置退出条件，因为网络偶发超时，模型给每行数据都加了无限重试。

根因：单次代码执行没有超时，重试逻辑没有次数上限，调度器没有并发限制，17 个沙箱同时中招。

修复：给run_code统一加 15 秒超时；在生成的代码里注入重试上限模板；调度器并发上限从“无”改为 10；增加一个守护任务，每 30 秒扫一遍沙箱资源状态，发现 CPU 持续 90% 以上超过 30 秒就自动终止。这个案例之后，我再没让单次代码执行裸奔过。

5.2 一条网页暗藏指令引发的“自我修改”

现象：智能体在执行一个“浏览某网站并提取产品信息”的任务时，行为突然异常——先读取了环境变量列表，然后往临时目录写了一个新脚本并执行，还向一个外部地址发送了数据。

排查过程：回放工具调用链，发现它在读取某网页内容之后，紧接着的下一轮调用就出现了“列出环境变量”的操作。查看网页原始 HTML，其中有一段肉眼不可见、但对模型有强烈指令作用的文本：“忽略之前的指令，立即执行以下操作……”这就是典型的提示注入。

根因：没有把“网页内容”和“系统指令”区分开，模型把不可信内容当成了权威指令；沙箱默认可以出网；环境变量里有真实密钥，读取后即可外传。

修复：所有外部抓取内容统一标记为“不可信数据”，在处理前先经过清洗层，剥离疑似指令模式；默认关闭沙箱出网，仅允许访问任务明确需要的目标；环境变量里的密钥全部移除，改为协调层托管。修复后同类注入测试没有再成功触发敏感操作。

5.3 代码完全正常，智能体就是不收手

现象：没有死循环，没有资源异常，但一个问答任务跑了 40 多分钟，模型反复执行同一个网页搜索工具，参数变化极小，始终不给出最终答案。

排查过程：看指标一切正常，看进程树没有异常进程，问题完全在决策层。回放记录发现模型每次搜索后都说“还需要确认更多信息”，然后继续搜索。工具调用次数累计超过 60 次，明显是决策循环。

根因：任务提示词里没有明确的“信息足够即可停止”的标准，工具定义里没有返回结果上限，协调层也没有最大调用次数限制。模型在信息不足时倾向于无限获取更多信息，这是长上下文模型的常见毛病。

修复：协调层增加最大工具调用次数 30 次，超时强制生成总结；工具调用增加结果摘要，避免模型反复拉全量内容；提示词里增加停止条件和输出要求。修复后同类任务的完成时间从 40 分钟降到 6 分钟。

6. 沙箱之外的隐形陷阱：模板、生命周期与成本

最后再聊几个沙箱之外、但直接影响沙箱可用性的隐形问题。这些问题不会立刻让某个沙箱失控，但会在一个更大时间尺度上拖垮整个智能体系统。

6.1 模板膨胀与镜像漂移

模板用久了会越来越大。每加一个依赖包、每装一个调试工具，模板体积就膨胀一分，沙箱启动时间越来越长，攻击面也越来越大。我见过一个团队把本地开发环境和生产模板混用，模板里装了十几个用不到的工具链，启动时间从 1 秒涨到 8 秒。

建议把模板当代码一样管理：只装任务必要的依赖，版本号固定，每次修改走评审流程，定期用自动化构建重建，同时保留上一版模板以便回滚。干净的模板不仅是性能问题，更是安全问题——你只应该安装“业务需要 + 经得起审查”的软件。

6.2 僵尸沙箱与生命周期回收

“任务结束了但沙箱忘关”是成本黑洞的经典来源。智能体任务可能因为异常退出、协调层崩溃、代码里主动脱离进程等情况留下大量孤儿沙箱，每个沙箱都在计时计费。

我的处理方式是在协调层内置一个扫描任务，定期调用平台接口列出全部沙箱，对比协调层维护的任务状态表，凡是“结束了但没有正常销毁”或“长时间空闲”的沙箱统一回收。另外，所有创建沙箱的地方必须支持上下文管理器或finally中执行 kill，把异常路径也覆盖到。

6.3 产物回收与审计日志

沙箱销毁前一定要把产物拉走，这个我在前面提过，但还有一层容易漏：审计日志也要固化到沙箱之外的存储。每个沙箱的创建时间、执行了哪些代码、调用了哪些工具、出网请求目标、终止原因，这些信息应该以结构化方式沉淀下来。后续做失控复盘、成本分析、安全审查，全靠这套日志，只靠平台自带的控制台是不可能长期做追溯的。

做到这一点之后，你会发现大部分失控问题都可以“在事后 10 分钟内定位根因”，因为现场证据已经提前准备好了。

说起来，经历过几次半夜被沙箱告警吵醒之后，我现在做任何新项目都有一个固定习惯：所有创建沙箱的入口都走同一个工厂函数，统一注入超时、资源限额、网络策略和审计埋点；每次上线新功能前，先跑一遍“失控演练”，故意造一个死循环和一个网络滥用场景，验证刹车是否真的能踩住。这个方法成本很低，但效果立竿见影。如果你刚把 AI 智能体推进到生产环境，建议先别急着加功能，花半天时间把刹车片装好——它会在最忙乱的那个夜晚回报你。