Agent代码执行安全：从E2B到Docker的沙箱隔离实践

先说一个现象这两年但凡做 Agent 应用的团队几乎都会遇到同一个尴尬——Agent 会写 Python 代码了但没人敢让它直接在你电脑上或者服务器上跑。原因太直白了。大模型生成代码的风格是“看着对跑起来炸”它可能因为一个类型转换报错也可能因为某个库的副作用把环境搞得一团糟。更麻烦的是如果你在做数据分析、爬虫、自动化办公这类任务Agent 会按照需求捏出一段 Python 代码这段代码本身是“不可信”的。你没法预判它会访问什么文件、占用多少内存、会不会把系统目录里的东西删了。这时候如果你只是开个 virtualenv 然后python xxx.py那基本等于把家门钥匙交给一个陌生人。这就是 Sandboxed Node Execution 要解决的问题。它指的是在 Agent 工作流里当一个“执行代码”的节点被触发时这段代码不是直接跑在你的宿主环境里而是被丢进一个隔离环境——沙箱——里运行。沙箱可以是 E2B 这种专门服务也可以是你自己用 Docker 搭的容器。不管是哪种方式核心目标就一个让不信任的代码在受控边界里跑跑完拿结果然后销毁现场。这篇文章我想把两条路都讲透。一个是 E2B 这种专为 AI Agent 设计的沙箱平台另一个是你自己拿 Docker 搭的轻量隔离方案。我会聊清楚底层原理、代码怎么写、有哪些坑以及到底什么时候该用哪种方案。适合正在做 Agent 开发尤其是涉及代码生成、代码执行的读者也适合想给数据分析或自动化工具套一层安全壳的朋友。1. Agent 代码节点的“信任空洞”为什么必须隔离执行1.1 代码节点的真实形态Agent 工作流里的“工具调用”不是白名单函数先统一一下概念。很多人理解 Agent 的“工具调用”脑子里浮现的是这样的场景Agent 决定调用get_stock_price(ticker)然后系统帮忙执行这个白名单函数。这是传统 Copilot 的玩法函数是预先定义好的入参校验过出了问题能兜底。但真实世界的 Agent 应用早就不满足于这个了。用户说“帮我抓取这个网页里的表格数据做一下清洗再画个分布图”你让 Agent 做的是“动态生成代码”不是“从十个预设函数里选”。于是你的工作流中需要一个节点这个节点接收的是模型生成的 Python 字符串需要把它当成真实程序执行。这就是 Sandboxed Node Execution 里“Node”的含义——它是一个执行节点输入是代码文本输出是 stdout、stderr、exit code以及可能落盘的文件。这里就出现了一个信任空洞。模型生成的代码不在你的控制范围内你不能保证它仅仅是“完成任务”。它可能写/tmp/evil.sh可能去扫描内网端口可能while True死循环把 CPU 吃满。普通函数调用和代码执行之间的差距就是隔离层必须存在的原因。1.2 沙箱到底要隔离什么不只是恶意代码还有失控代码做沙箱的时候很多人的第一反应是“防黑客”。但单看 Agent 场景真正的威胁矩阵比“恶意攻击”要广得多。第一层是防 Bug 蔓延。Agent 生成的代码可能今天就能跑通明天换了输入就抛异常异常不可怕可怕的是异常前的部分副作用已经生效了——比如改了某个配置文件、往数据库里插了脏数据。如果直接跑在宿主 Python 环境里这些副作用就会污染你的开发机或者生产服务器。第二层是防资源失控。模型写出的死循环、递归爆栈、加载超大数据集这些都不是恶意代码但同样能把服务器拖垮。如果你的执行节点没有内存和 CPU 上限一个pd.read_csv(all_data.csv)就可能把 32G 内存吃干净然后触发 swap宿主机跟着卡死。第三层才是防恶意行为。模型被提示注入后可能生成偷目录文件、扫端口、反弹 shell 之类的代码。这个概率现阶段不高但作为系统设计者你不能假设它永远是好人。所以一个合格的沙箱执行节点至少要提供四样东西文件系统隔离、进程隔离、资源配额、网络策略。文件系统隔离让代码读不到宿主敏感文件进程隔离让代码崩溃不影响宿主资源配额防止 CPU/内存被打满网络策略决定要不要让它访问外网或内网。这四样恰恰是 Docker 容器和 E2B 沙箱都能覆盖的能力集。1.3 “隔离执行”与“虚拟环境”是两码事很多人误以为 venv 或者 conda 环境也算隔离这里必须把概念掰开。虚拟环境解决的是 Python 包依赖冲突它让你在同一个系统里装不同版本的库但它不限制进程权限不隔离文件系统代码照样能读/etc/shadow只要当前用户有权限照样能rm -rf ~。沙箱隔离的是“系统调用级别”的资源边界。一个真正的沙箱里代码看到的文件系统是虚拟的看到的内存空间是受限的看到的网络接口可能是不存在的。打个不恰当的比方虚拟环境是让你在同一个小区里换房子住虽然邻居换了一批但小区大门是共用的沙箱是给你一栋独立的房子周围拉起警戒线外人进不来你也出不去。理解了这层差异你才能理解 E2B 和 Docker 的价值到底在哪——它们不是帮你管理 Python 包而是帮你管理“代码能在什么范围内造作”这件事。2. E2B为 Agent 而生的沙箱执行平台核心 API 跑通记录2.1 E2B 到底做了什么一个可编程、单次寿命的云沙箱E2BEnglish to Bytes这个名字可能有些人陌生但如果你用过 ChatGPT 的代码解释器可以把它理解为“同款能力的开发者版 API”。E2B 做的事情是你通过 SDK 调一个接口几十毫秒内它在你附近的集群节点上拉起一个轻量虚拟机或容器给你一个隔离的 Linux 环境。你可以往里面传代码、传文件执行命令拿回输出最后销毁整个环境。它跟传统云服务器的区别是沙箱不是长期存在的它是“单次寿命、即用即毁”的。你的 Agent 收到一个代码执行请求调 E2B 建一个沙箱跑完拿到结果主动 kill 掉。这就解决了最头疼的问题——环境残留。代码产生的临时文件、安装的包、改过的配置都随着沙箱销毁一起消失不会污染长期宿主机。E2B 还内置了对 AI 场景的适配。比如它可以直接把 Python 代码字符串塞进去跑文件系统操作都有 API甚至能跑 Jupyter Notebook。这个定位决定了它的上手门槛比裸容器低很多。2.2 最小可用代码用 Python SDK 在沙箱里执行 Python 代码我用 E2B 的时间不算短了版本迭代快但核心调用方式一直比较稳定。以当前 SDK 为例最小可用的执行链路长这样from e2b import Sandbox # 启动一个沙箱实例 sandbox Sandbox(templatebase) # 在沙箱里执行 Python 代码字符串 code import platform print(python version:, platform.python_version()) result sandbox.run_python(code) print(stdout:, result.stdout) print(stderr:, result.stderr) print(exit code:, result.exit_code) # 用完之后摧毁沙箱避免资源泄漏 sandbox.kill()这段代码背后的逻辑很直白。Sandbox(templatebase)是告诉 E2B 用哪个预置镜像来创建环境base是一个带 Python 的最小镜像。run_python则是把代码字符串传给沙箱内的 Python 解释器执行输出会被捕获并封装成结果对象。整段代码跑下来你已经完成了“让 Agent 代码在一个隔离环境里执行”的最小闭环。我想强调的是sandbox.kill()这一步。很多人刚上手时容易漏掉导致沙箱一直挂在那里按秒计费跑一晚上账单很难看。E2B 有自动关闭机制但你自己在代码里显式 kill 永远是最稳的。如果是写进 Agent 工作流建议用try...finally确保无论结果如何都会回收沙箱sandbox Sandbox(templatebase) try: # 你的代码执行逻辑 result sandbox.run_python(code) finally: sandbox.kill()2.3 文件系统双向同步数据怎么进出沙箱大多数 Agent 场景不只是执行一段打印 hello 的代码。它可能需要读取用户上传的 CSV处理后生成一张图表。这个时候你得把数据送进沙箱再把结果文件拿出来。E2B 的文件系统 API 在设计上很贴合这个需求。上传文件用sandbox.filesystem.write读取文件用sandbox.filesystem.read列目录用sandbox.filesystem.list。实际跑通的一段代码如下from e2b import Sandbox sandbox Sandbox(templatebase) try: # 把本地 CSV 推入沙箱的 /home/user/data.csv with open(sales.csv, rb) as f: sandbox.filesystem.write(/home/user/sales.csv, f.read()) code import pandas as pd df pd.read_csv(/home/user/sales.csv) summary df.describe().to_csv() with open(/home/user/summary.csv, w) as f: f.write(summary) print(done) result sandbox.run_python(code) print(result.stdout) # 把生成的结果从沙箱里拉回本地 summary sandbox.filesystem.read(/home/user/summary.csv) with open(summary.csv, wb) as f: f.write(summary) finally: sandbox.kill()这里有个细节值得注意read返回的是 bytes不是字符串。你写回本地时需要按 bytes 模式打开文件。这个坑我踩过——第一次没转编码直接写文件结果中文全乱码了。2.4 沙箱模板把常用依赖固化进镜像如果你每次执行代码都要pip install pandas numpy requests那启动沙箱后光是装依赖就浪费十几秒。E2B 提供了沙箱模板Sandbox Template功能你可以预先把依赖装好拍成一个模板镜像之后每次启动沙箱都用这个模板。E2B 官方有base、python、jupyter这些预设模板但你完全可以自己定制。做法是在 E2B 的平台上创建一个新模板按照官方文档写一个Dockerfile打包时把依赖装好FROM e2bdev/code-interpreter:latest RUN pip install pandas numpy matplotlib requests scikit-learn构建完成后你的代码里可以直接指定模板名sandbox Sandbox(templatedata-science) # 你自定义的模板名这个优化对用户体验影响很大。试想你的 Agent 在执行代码前要等十几秒装包用户在网页前端就会看到长时间的“正在处理”状态体验非常糟糕。用了自定义模板后沙箱启动速度和冷启动一台容器差不多基本可以控制在秒级。2.5 生命周期管理与自动关闭E2B 沙箱的默认生命周期其实比很多人想象的要短但它不会因为你把代码忘在变量里就自动消失。默认情况下沙箱会持续运行直到你主动 kill或者到达平台设定的超时时间。你在工作流里需要特别留意两点。第一点是超时设置。E2B 的Sandbox支持timeout参数单位似乎按分钟计取决于版本。无论如何建议显式传一个较短的时间比如 5 分钟。因为模型生成的代码如果有死循环它自己是不会主动退出的超时机制是你最后一道保险。第二点是并发数量。E2B 对并发沙箱数量有限制免费额度更少。如果你要做批量代码评估最好控制并发上限不然平台会直接拒绝创建新沙箱。我在做批量测试时习惯用信号量限制并发到 5 个跑起来稳定得多。3. Docker 隔离自己搭一套可控的 Sandboxed Node Execution3.1 为什么 Docker 能承担这个角色从容器本质看隔离边界E2B 很方便但毕竟是外部服务。有些团队因为数据合规、内网环境、成本控制等原因更希望在自己的服务器上搭建隔离执行环境。这时候 Docker 就成了最自然的选择。Docker 的容器本质上是一组受约束的 Linux 进程。它通过 Linux 内核的 namespace 给进程提供独立的文件系统视图、进程树、网络栈通过 cgroup 限制资源使用。你容器里看到一个完整的 Ubuntu 环境实际上是内核帮你“虚拟”出来的容器里的 root 并不等同于宿主机的 root这就为运行不可信代码提供了基础的安全边界。不过要说清楚的是Docker 不是强安全沙箱。如果你给容器挂载了宿主机目录、给了 privileged 权限、或者把 Docker socket 传进容器那容器基本就等于宿主机。所以用 Docker 做隔离执行关键不在于用不用容器而在于你怎么配置容器的边界。3.2 最小可用方案用 Python 官方镜像跑“一次性任务容器”用 Docker 实现 Sandboxed Node Execution最经典的模式是“一次性任务容器”每次执行代码拉起一个新容器跑完立刻删除绝不复用。先看直接用 Docker SDK 的版本。下面的代码基于dockerPython 包import docker client docker.from_env() code import sys print(hello from container) print(python version:, sys.version) container client.containers.run( imagepython:3.12-slim, command[python, -c, code], mem_limit256m, nano_cpus500000000, # 0.5 核 network_disabledTrue, detachTrue, ) try: # 等待容器结束最多等 30 秒 result container.wait(timeout30) logs container.logs(stdoutTrue, stderrTrue).decode(utf-8, errorsreplace) print(exit code:, result[StatusCode]) print(logs:, logs) finally: # 不管成功失败删除容器避免残留 container.remove(forceTrue)client.containers.run是 Python SDK 里最常用的快捷方法它会自动创建容器、启动、等待输出。我这里用detachTrue让它异步执行然后手动wait和拿日志这样控制更精细也方便加超时逻辑。这段代码背后有几个关键配置值得展开mem_limit256m限制容器最大内存为 256MB代码如果申请更多内存会直接 OOM进程被杀而不是拖垮宿主机。nano_cpus500000000限制 CPU 为 0.5 核防止while True这种死循环把服务器 CPU 打满。network_disabledTrue直接关闭容器网络。这是一个很多人忽视但很重要的选项。Agent 生成的代码中很多数据加工、图表生成根本不需要联网关掉网络既减少安全风险也避免代码偷偷往外传数据。container.remove(forceTrue)保证容器结束后被清理。不删的话容器会变成 Exited 状态慢慢堆积成僵尸容器占磁盘空间。3.3 代码传入与结果取回挂载卷 vs stdin/stdout用 Docker 执行代码最常见的操作是把代码字符串塞给容器。有三条路径通过-c参数直接传代码、通过 stdin 传给解释器、通过挂载卷传文件。三条路径适合不同场景。python -c code简单直接适合短代码但如果代码太长命令行的长度限制会变成瓶颈而且在进程列表里能看到完整代码有点难看。stdin 方式更适合长代码你可以把代码字符串写入容器的标准输入code # 很长的代码... print(hello) container client.containers.run( imagepython:3.12-slim, command[python], stdin_openTrue, network_disabledTrue, mem_limit256m, detachTrue, ) try: sock container.attach_socket(params{stdin: 1, stdout: 1, stderr: 1}) # 写入代码关闭输入 sock._sock.sendall(code.encode(utf-8)) sock._sock.shutdown(socket.SHUT_WR) # 读取输出... finally: container.remove(forceTrue)这种方式的优点是代码不会被 shell 转义干扰缺点是 attach protocol 有点绕解析输出也需要自己处理。文件方式最接近真实工作流。你先用docker cp或者挂载卷把脚本放进去再执行。遇到需要传入 CSV 数据、传出图片的场景时这种模式最顺手docker run --rm \ -v $PWD:/workspace \ -w /workspace \ -m 256m \ --cpus 0.5 \ --network none \ python:3.12-slim \ python /workspace/script.py--rm参数是一行命令写完 Docker 隔离执行的精髓容器跑完自动删掉不用单独再写清理逻辑。-v把当前目录挂载进容器script.py 和输出文件都能直接读写宿主机文件。但注意挂载卷在安全上是有妥协的——容器里的代码能读写这个目录它不再是完全孤立的。所以挂载目录应该是你特意隔离出来的工作目录不能是整个家目录。3.4 资源配额与控制内存、CPU、超时三件套前面提到了mem_limit和nano_cpus实际生产里这套资源配额要更系统。我的习惯是统一配三件套内存上限、CPU 上限、运行超时。内存方面Docker 的--memory或 SDK 的mem_limit不只限制物理内存它还控制包含 swap 的总用量。如果你想限制得更严可以再加--memory-swap为同样的值这样容器完全没有 swap 可借超过就 OOM。CPU 方面nano_cpus是 Docker 1.13 以后的推荐参数0.5 核就是 500000000 纳核。也可以用老的cpu_quotacpu_period组合效果一样。单核限制是必须的否则你的 Agent 一次执行可能把整台服务器算力都占满其他服务跟着遭殃。超时控制比较关键。Docker 本身没有“执行超过 N 秒自动杀”的内建逻辑你需要在外层自己处理。一个常见做法是给container.wait()传 timeout但要注意这个 timeout 指的是等待容器结束的时长而不是容器内程序运行的绝对时长。更可靠的是在容器启动前给自己一个 deadline到时候还没结束就container.kill()。container client.containers.run(..., detachTrue) try: exit_code container.wait(timeout15) except docker.errors.NotFound: # 容器可能中途被清理了 pass except requests.exceptions.ReadTimeout: print(执行超时强制终止) container.kill() container.remove(forceTrue)一旦触发超时容器还在跑也没用直接kill然后remove。同时把这次执行标记为失败记录错误原因。这比让代码无限跑下去好得多——用户的等待耐心是有限的。3.5 安全加固不给容器完整 root不挂 Docker socket既然用 Docker 做沙箱安全配置就是生死线。几个加固要点都是实打实踩过坑总结的第一默认不要用--privileged。privileged 模式会把所有内核能力交给容器容器里的 root 就是宿主机的 root等于隔离层直接失效。除非极端场景不然一律不加。第二不要挂载 Docker socket/var/run/docker.sock。这是 Docker 著名的安全黑洞。如果一个恶意代码能读写 Docker socket它就能在宿主机上创建特权容器直接逃逸。你的执行节点无论如何都不能把 docker.sock 暴露给不可信代码。第三可以主动丢弃部分 Linux capabilities。Docker 默认给容器一堆 capability但你的代码执行节点只需要CHOWN、DAC_OVERRIDE、SETUID、SETGID、NET_BIND_SERVICE这几样。断开网络并使用--cap-drop ALL --cap-add白名单模式安全边界更硬。单看配置就是加几个参数的问题但实际意义很大。尤其在多租户场景下一个节点可能要执行来自不同用户的代码如果隔离不彻底用户 A 的代码搞乱用户 B 的数据这算是事故了。4. E2B 与 Docker 的硬碰硬选型要看这几个维度4.1 一张表看关键差异选型不是谁好谁坏的问题是哪个更适合你的场景。我整理一张表把最关键的维度摆在一起。对比维度E2BDocker 自建启动速度秒级取决于模板复杂度和地区镜像已拉取时毫秒级首次拉镜像较慢隔离级别轻量虚拟机 容器边界更硬内核 namespace cgroup容器级隔离运维成本几乎为零平台托管需要自己维护 Docker 环境、清理僵尸容器网络控制平台提供网络开关环境内可配置--network none或自定义 bridge 网络文件传输内置 API支持小文件上传下载挂载卷、docker cp、/tmp 中转计费方式按秒计费 网络流量服务器固定成本额外资源按峰值扩容适合场景快速验证、低频调用、不想管基础设施高频批量执行、私有化部署、数据敏感场景风险点外部服务依赖网络延迟数据过境容器逃逸风险需要自己加固这表格看起来信息多但总结起来其实就是一个问题你愿不愿意为省运维时间支付按秒的费用以及你的数据能不能接受放到外部平台。4.2 按场景选型从自动交易到教学代码执行如果做的是高频批量代码评估比如给 Agent 生成的 1000 段代码做测试我倾向于 Docker。因为批量执行必然意味着高并发E2B 的按秒计费再便宜1000 段代码 × 10 秒 × 并发上限费用也会很可观。相比之下在自己服务器上跑容器成本基本是固定的只要机器扛得住边际成本很低。如果做的是低频、交互式的代码执行比如用户在网页对话框里让 Agent “画个图”“算个数据”那 E2B 的体验更好。它的模板机制能让你快速组建带好依赖的环境不用操心镜像仓库、磁盘空间而且按秒计费在低频场景下几乎可以忽略。牵扯到敏感数据就要谨慎了。金融数据、企业内部报表、医疗记录这些内容即使加密传输很多企业合规部门也不会同意放到外部沙箱。这种情况下 Docker 自建几乎是唯一选择。你可以把 Docker 跑在内网数据不出网安全边界可控。另外别忘了教学场景。如果你在做一个“AI 教编程”的产品学生写代码让 Agent 帮忙运行调试这种场景对安全要求极高——因为学生可能有意无意写恶意代码。E2B 这种托管沙箱天然适合即使学生把沙箱搞挂了也是平台的事你只需要关注和 Agent 的联动。4.3 成本模型按秒计费 vs 服务器固定开销聊到成本我建议算一笔细账。E2B 按秒计费假设单次执行平均 10 秒1000 次执行就是 10000 秒约 2.7 小时。按平台价格粗算加上数据传输流量每月花销可能在几十美元量级。对于个人开发者或者刚起步的团队这个成本并不夸张。Docker 自建的成本主要是服务器。一台 4 核 8G 的云服务器一个月一两百块人民币可以支撑不小的并发量。但要注意服务器是需要人管的——Docker 版本升级、磁盘满了清理镜像、容器逃逸漏洞打补丁这些都是隐性成本。如果你是个人开发者时间也是钱把这些时间算进去E2B 的价格反而显得便宜。一个折中方案是混合架构日常小流量交互式执行走 E2B批量离线任务走自建 Docker。这套方案我实践过在成本、体验、安全之间找到了一个比较舒服的平衡点。5. 我踩过的坑沙箱执行在三类真实场景里的教训5.1 代码还没跑完Agent 就先超时了用 E2B 做同步执行的时期我遇到过一个非常尴尬的问题Agent 那边等代码执行结束才返回结果而一套复杂的数据分析代码可能要跑两三分钟。前端 Agent 的 HTTP 请求超时设置往往是 30 秒或 60 秒代码还没跑完请求已经断了。后来我改成异步模式代码执行任务丢进队列前端轮询任务状态。Agent 返回的不是最终结果而是一个任务 ID用户那边靠轮询获取最新进展。这个改动同时解决了“浏览器请求超时”和“用户长时间白屏等待”两个问题。另一个小技巧是执行代码前先给 Agent 一个内部检查环节让模型先判断这段代码是否可能耗时过长。模型对复杂度的感知比想象中好它如果回复“这段代码可能超过 2 分钟”我就先预警用户而不是闷头跑。5.2 容器里的“网络幻觉”有些代码需要联网有些不能给网用network_disabledTrue关掉容器网络后我踩了个隐蔽的坑Agent 生成的代码里很多都会import requests去拉数据但容器里根本没有网代码直接ConnectionError。排查的时候你会以为是代码问题其实是网络配置问题。后来我换成了更精细的网络控制方案保留容器网络但在宿主机用防火墙规则限制容器只允许访问特定域名。比如允许访问api.openai.com如果代码需要调 LLM 接口其他一律切断。这种情况用 Docker 自定义 bridge 网络加 eBPF 或 iptables 规则能实现但配置复杂度上来了。如果是 E2B它的沙箱网络策略配置起来简单得多直接在平台上设置网络规则即可。一个方案一个复杂度差异这个在选择时要考虑清楚。5.3 日志被切割、exit code 丢失结果解析的细节Docker 容器日志有个问题默认的日志驱动是 json-file日志量大了之后会被切割默认单文件上限 100MB。如果你执行的代码疯狂打印日志文件被切割后container.logs()可能拿不全输出甚至拿不到。更麻烦的是日志切割可能导致wait()返回的状态码和日志对不上。解法很简单启动容器时把日志驱动改成local并限制大小container client.containers.run( imagepython:3.12-slim, command[python, -c, code], log_config{ type: local, config: {max-size: 10m, max-file: 3}, }, ... )max-size10m意味着单文件日志超过 10MB 就轮转max-file3表示最多保留 3 个文件。这既能防止日志撑爆磁盘也保证你拿日志的时候不至于丢太多。exit code 的问题则更隐蔽。container.wait(timeout...)返回的StatusCode是整数按理说直接判断是否为 0 即可。但如果你 kill 容器或者容器被 OOMwait()可能抛出异常或者返回的 StatusCode 是 137SIGKILL而不是标准的 1。处理这些状态码时不要想当然地映射到“脚本报错”要区分“代码异常退出”和“被资源限制杀死”两种完全不同的失败。用户看到“OOM killed”和“程序报错”时后续处理策略也应该不一样。5.4 资源泄漏容器僵尸、沙箱未关闭的账单最后说一个我犯过的低级错误也最值得新人注意。用 Docker 时如果你的运行路径里有异常分支执行到container.remove()之前就 return 了容器就会变成 Exited 状态的僵尸容器。它们不占 CPU 但也占磁盘跑多了之后docker ps -a能看到几十个一致名字的前缀容器docker system df一看占了几 GB 磁盘。所以我后来一律用try...finally包装清理逻辑或者在跑完立刻标记并批量清理docker container prune -f定时任务里跑一下僵尸容器全部清掉。这个习惯让我少处理了很多“磁盘满了”的告警。E2B 那边对应的坑是“忘记 kill 沙箱”。你可能在任务正常结束后忘记杀掉沙箱它就会一直挂在云端按秒计费。更麻烦的是沙箱里如果起了一个后台进程即使你调用了kill()有时也不能保证完全关闭。所以我给 E2B 的使用流程加了一步监控每次调用结束后查一下沙箱列表把异常残留的沙箱手动清掉。5.5 实用配置速查一个可以直接抄的 Docker 执行镜像说了这么多坑给一套我目前最常用的 Docker 执行节点配置你可以直接拿去改。import docker client docker.from_env() def run_code_in_sandbox(code: str, timeout: int 30) - dict: container client.containers.run( imagepython:3.12-slim, command[python, -c, code], mem_limit256m, nano_cpus500000000, network_disabledTrue, cap_drop[ALL], cap_add[CHOWN, DAC_OVERRIDE, SETUID, SETGID], log_config{type: local, config: {max-size: 5m, max-file: 1}}, detachTrue, ) try: exit_code container.wait(timeouttimeout) logs container.logs(stdoutTrue, stderrTrue).decode(utf-8, errorsreplace) return {exit_code: exit_code[StatusCode], logs: logs} except Exception as e: container.kill() return {exit_code: -1, logs: f执行超时或异常: {e}} finally: container.remove(forceTrue)这套配置在资源限制、日志清理、安全加固上都做了权衡。cap_drop[ALL] 白名单cap_add让容器几乎没有额外的内核权限安全边界清晰。我个人在实际项目里的体会是Sandboxed Node Execution 这个组件本质上是在给 Agent 的自由度装刹车。刹车装好了你才敢放开油门让模型真正去写代码、跑代码、迭代代码。如果这一步省略了Agent 的能力上限就永远只能停留在“生成代码文本”的层面而无法真正成为一个能闭环干活的系统。踩过几次坑之后我现在搭建任何 Agent 项目第一件事想的不是用什么模型、什么框架而是先把代码执行节点这个沙箱底座打牢。做对这一步后面的路会顺很多。