我不止一次被问到同一个问题AI Agent 写出来的代码到底敢不敢让它直接跑尤其当 Agent 开始动文件、起进程、连数据库的时候一个隔离沙箱不是增强项而是刚需。E2B 就是专门解决这个问题的沙箱运行时可以帮 Agent 执行代码、查看文件、跑命令行工具并且环境用完即焚。我也折腾过不少方案最后选择用阿里云计算巢把 E2B 的服务端和沙箱环境一起部署起来稳定性比之前自己拼的临时环境提升了一截。这篇文章从设计思路、部署规划、实际操作到常见坑位全部展开适合正在做 AI Agent 开发、想给 Agent 加安全执行环境、或者在 n8n 这类工作流里接代码执行能力的同学参考。1. 先搞清楚Agent 沙箱到底解决什么问题1.1 没有沙箱时Agent 的杀伤力有多大AI Agent 与传统脚本有个本质区别传统脚本是固定的行为可预期而 Agent 的下一步操作由模型根据上下文动态生成这意味着你无法提前审查每一行代码。我们之前把 Agent 直接跑在开发机上某次模型生成的代码误删了项目目录虽然不是生产环境但恢复数据也花了一整天。还有个更常见的隐患Agent 在做“联网搜索 数据处理”任务时会下载不可信的脚本一旦脚本里藏了读取环境变量、扫描内网端口的逻辑宿主机直接暴露在风险里。另一个容易被忽略的问题是资源管理。不带隔离的 Agent 进程可能因为死循环占满 CPU或者往磁盘里写入大量临时文件把服务器存储撑爆。Docker 容器能解决一部分问题但容器共享宿主机内核遇到需要隔离文件系统、网络栈、内存上限的强约束时容器方案还不够彻底。1.2 E2B 的定位给 Agent 一个用完即焚的微虚拟机E2B 做的事情简单说就是给每个 Agent 会话动态创建一个隔离环境Agent 在里面跑代码、执行命令、读写文件任务结束后整个环境销毁不留下任何残留。这个“用完即焚”的特性非常重要。以前用常规虚拟机一台机器长期开着环境越用越脏依赖互相冲突出了问题很难复现。E2B 的方式是每次会话都是全新环境从镜像拉起用完就销毁天然适合 Agent 这种短生命周期、高并发、行为不可控的场景。从架构上看E2B 包含服务端、沙箱运行时、模板镜像管理、SDK/Toolkit 几个部分。服务端负责任务调度和生命周期管理沙箱运行时负责真正的代码执行模板镜像决定了 Agent 拿到什么样的初始环境。你甚至可以自己做镜像把 Chromium、Composer、FFmpeg 这类重量级工具提前烧进去Agent 启动后直接能用省去每次安装依赖的等待。1.3 自建 E2B 到底适合什么场景E2B 官方有云服务直接用也不是不行但很多团队会选择自建。常见原因有三个一是需要对数据负责代码和数据不出自己的账号体系二是要跟内部的 VPC、数据库、对象存储打通比如 Agent 要读取内网仅允许指定网段访问的数据源三是成本控制自建在长期并发量稳定后通常更划算。如果你只是本地写个 Demo那 Docker 临时套一个环境就够了没有必要上 E2B。但如果你在正经做 Agent 产品、或者在 n8n 这类自动化工具里接入了 AI Agent 并建设了可以反复调用的执行节点那自建一套沙箱基础设施是值得的。尤其是 Agent 的数量一旦上到两位数手工管理环境就是灾难这时候 E2B 这类平台级方案的优势就体现出来了。2. 技术选型拆解为什么是 E2B 阿里云计算巢2.1 E2B 相比裸 Docker 的差异化优势早期我图省事直接在宿主机上装 Docker然后用docker run --rm这种方式给 Agent 跑代码。这种做法能用但有三个问题解决不了。第一个是并发问题每次冷启动一个容器镜像拉取、依赖安装、网络初始化这些步骤都不可控并发一高就容易卡住。第二个是隔离粒度容器之间共享内核Agent 代码里如果写了内核相关的操作可能影响其他容器。第三个是生态集成n8n、LangChain、Claude Code 这些工具有自己的执行器接口直接裸调 Docker 命令需要自己写大量胶水代码。E2B 把这些问题都打包解决了。它有内置的模板机制同一个镜像可以预启动多个沙箱按需分发冷启动速度比现场创建容器快不少。它提供了跨语言的 SDKPython、Node 各有对应的客户端包传入几行初始化参数就能拿到一个沙箱实例。它还提供了统一的观测面板能看到每个沙箱的 CPU、内存、运行状态排查问题比对着 docker ps 舒服多了。2.2 阿里云计算巢在自建方案中承担的角色云巢不是一个简单的“服务器控制台”它解决的是部署和运维抽象层的问题。正常情况下自建 E2B你要自己买 ECS、配安全组、装 Docker、处理存储目录、配置环境变量还要考虑升级时怎么不影响现有 Agent。计算巢把这些基础设施资源编排成服务模板你在模板里定义好想要的机器规格、镜像、数据盘、网络配置之后每次创建服务实例就相当于在云上拉起一套标准化环境。对团队协作来说计算巢也有价值。模板一旦定义好团队成员或者另一个项目组要复制一套同样的环境不需要从头看部署文档直接在计算巢里选择服务并创建实例就能获得完全一致的配置。这解决了“配置漂移”问题——以前每个人手搓的服务器环境千差万别出了问题很难复制。2.3 开发版与生产版怎么选我建议大多数情况先别上 Kubernetes直接用单机 ECS Docker Compose 跑通全流程。E2B 服务端和沙箱运行时本质上是几个常驻服务单机模式完全能支撑小规模团队使用。等 Agent 并发量上来了再切到计算巢的容器服务ACK部署方式利用集群的弹性扩缩容能力来应对高峰。单机版的好处是调试方便日志都在一个节点上出问题能快速定位。生产版的好处是可用性更好某个节点故障了沙箱可以调度到别的节点。我的建议很直接开发环境用单机生产环境至少是两个节点的集群并给沙箱运行节点设置独立的资源配额避免某个 Agent 把整个集群的 CPU 打满。3. 部署前的准备资源和参数规划清单3.1 机器规格与镜像选择E2B 的实际资源消耗取决于你跑什么任务。纯 Python 脚本的沙箱1 核 2GB 内存就够如果 Agent 要跑 Playwright、浏览器自动化那至少准备 2 核 4GB 内存。服务端本身建议 4核8GB 起步因为沙箱的创建、销毁、镜像分发都经过服务端调度并发多的时候服务端就是瓶颈。操作系统我推荐 Ubuntu 22.04 LTS 或 24.04 LTS稳定性好Docker 和系统级依赖安装都很方便。注意 E2B 的沙箱运行时对内核特性有要求在选云服务器规格时尽量选新代次的实例类型老旧的实例类型可能无法完整支持沙箱所需的虚拟化指令。我踩过一次坑在低代次实例上安装后沙箱一直起不来换了带嵌套虚拟化支持的新代次实例就好了。3.2 云产品开通与权限准备在阿里云上最少需要开通三个产品ECS 用于载体VPC 用于内网互联安全组用于端口放行。如果后续要上生产再准备容器服务 ACK 和对象存储 OSS。计算巢本身也是独立产品进入控制台后首次使用会引导你授权其访问你的云资源这个授权动作是用来做资源编排的按提示操作即可。权限方面不建议直接使用主账号。给操作人员开一个 RAM 子账号只授予 ECS、VPC、计算巢相关的操作权限。尤其是沙箱服务端保存着 Agent 的 API Key如果账号权限过大一旦泄密攻击者可以直接控制所有沙箱资源。3.3 网络规划与安全组配置E2B 的沙箱内部访问网络有两种诉求一是沙箱内需要访问公网来做下载和安装二是 Agent 需要访问你 VPC 内网里的数据库和 API。第二种情况需要在网络规划时让沙箱节点与目标服务处于同一 VPC或者在路由层面做打通。安全组是最容易忽略又最容易出错的地方。我的习惯是只放行必要的端口而且来源 IP 尽量限制不要直接对 0.0.0.0/0 开放。下面是一个常见的安全组规则示例协议端口范围授权对象用途TCP22你的办公IP/32SSH 管理TCP8000需要的调用方IP/32E2B 服务端 APITCP443需要的调用方IP/32HTTPS/WSS 接入TCP2377内网网段容器服务通信4. 自建 E2B 的实操过程全记录4.1 在计算巢中创建服务实例登录计算巢控制台后选择“创建服务实例”如果你是从服务商发布的模板列表里选那直接搜索或者按分类进入即可。如果是自己维护的模板那需要先在“服务管理”里上传模板定义。计算巢的模板现在支持两种主流方式一是资源编排模板直接定义 ECS 规格、镜像、安全组等资源二是容器服务模板基于 ACK 集群部署。我用得最多的是第一种人机交互式模板创建时只需要填写几个参数就能拉起整个环境。ROS 模板的核心结构类似这样ROSTemplateFormatVersion: 2015-09-01 Parameters: InstanceType: Type: String Default: ecs.c7.xlarge Description: 服务端 ECS 规格 SystemDiskCategory: Type: String Default: cloud_essd Password: Type: String NoEcho: true Resources: EcsInstance: Type: ALIYUN::ECS::Instance Properties: InstanceType: Ref: InstanceType ImageId: ubuntu_22_04_x64_20G_alibase_20240818.vhd SystemDiskCategory: Ref: SystemDiskCategory SecurityGroupId: Fn::GetAtt: - EcsSecurityGroup - SecurityGroupId DataDisk: Policy: create CatalogName: Ref: InstanceType EcsSecurityGroup: Type: ALIYUN::ECS::SecurityGroup Properties: SecurityGroupName: e2b-sandbox-sg这里模板里的镜像 ID 只是一个示意实际操作时要以你账号下可用的镜像 ID 为准。创建完服务实例后计算巢会自动完成 ECS 的创建、安全组的生成、网络连接的配置等状态变成“已就绪”后就可以 SSH 登录了。4.2 启动 E2B 服务端Docker Compose 版本登录 ECS 后第一步更新系统包和安装 Docker。Ubuntu 上直接用 apt 安装 Docker Engine 就行装完后把当前用户加进 docker 组避免每次都用 sudo。接下来是拉取 E2B infra 项目代码这个过程需要留意版本信息不同版本的目录结构和环境变量含义有差异一定要以当前代码仓库里的 README 为准。我当时的操作大致是这样的git clone https://github.com/e2b-dev/infra.git cd infra cp .env.example .env然后编辑.env把关键配置项改成自己的值。注意共享密钥和访问 token这些一旦泄露等于把沙箱控制权交给了别人务必使用高强度随机字符串。配置文件中一般会涉及以下几个维度的参数服务监听端口我固定用 8000方便后续 n8n 和 SDK 统一配置内置模板镜像可以先用docker.io/library/ubuntu:22.04测试生产建议换成自己构建的业务镜像数据目录沙箱产生的临时文件默认写在宿主机某个目录下要确保磁盘空间足够。改完配置后启动服务docker compose up -d启动后先检查容器状态确认服务端进程和沙箱调度进程都处于运行状态。学习阶段不需要一次性启动太多沙箱先用单节点把流程跑通后面再按需求调整。4.3 验证服务端可用性服务端起来后先在宿主机上做一次本地探测。如果提供健康检查接口直接 curl 一下看返回是否正常curl http://127.0.0.1:8000/healthz这个健康检查通过后还要从外部测试一次。测试源可以是一台同样位于云安全组内的临时机器验证安全组放行规则是否正确。不要在没有任何防护措施的情况下直接把服务端口暴露到公网E2B 服务端一旦暴露在公网任何人都可以创建沙箱这些沙箱可能成为攻击者的跳板。验证通过后在服务端创建第一次访问用的 API Key可以是长期有效的也可以做成短期 token。生产建议用短期 token开发阶段长期 key 方便一点。5. Agent 接入 E2BPython / Node / n8n 三份实测记录5.1 Python SDK 接入跑通第一个 AgentPython 是 Agent 开发里使用最频繁的语言先从它开始。安装官方 SDKpip install e2b-code-interpreter然后用一段非常简单的代码验证连接from e2b_code_interpreter import Sandbox sandbox Sandbox( api_key你的API_KEY, # 自建场景需要把地址指向你的服务端 base_urlhttp://你的服务器IP:8000 ) execution sandbox.run_code(print(Agent sandbox is ready)) print(execution.text) sandbox.close()这里有个非常重要的细节base_url参数必须指向自建服务端不设这个参数 SDK 默认连接官方云服务。我第一次测试时就因为没设 base_url请求全跑到了官方云上虽然也能跑通但显然不是自建的目的。跑通基础调用后把 Agent 的工具函数挂上去就很简单了。定义一个 Python 函数作为工具注册给模型模型在决策需要执行代码时回调这个函数def execute_code_tool(code: str) - str: with Sandbox(api_keyAPI_KEY, base_urlBASE_URL) as sb: result sb.run_code(code) return result.text这样模型生成一笔临时数据需要做格式转换、需要批量处理 CSV、需要调用某个 API 时都能通过这个工具进入沙箱执行宿主机本身不承担任何不可信代码。5.2 Node SDK 接入方案Node 团队用起来同样顺手安装对应的 npm 包后初始化逻辑和 Python 版是对齐的npm install e2b/code-interpreterimport { Sandbox } from e2b/code-interpreter const sandbox await Sandbox.create({ apiKey: process.env.E2B_API_KEY, url: http://你的服务器IP:8000 }) const result await sandbox.runCode(console.log(node agent ok)) console.log(result.text) await sandbox.close()Node SDK 对异步模型支持得比较好尤其在跑多任务并发时不会阻塞事件循环。我在一个批量数据分析的任务里用 Node 版本同时打开了 5 个沙箱分别处理不同文件整体耗时比串行执行缩短了一半多。5.3 n8n 场景用 Agent 节点调用 E2B 执行代码n8n 是现在非常多团队在用的自动化工作流工具它本身有 AI Agent 节点可以通过工具调用让 Agent 接管任务。要让 n8n 里的 Agent 能用上自建 E2B优先推荐两个节点一个官方节点直接配置访问凭证另一个是直接用 HTTP Request 节点手动调用服务端 API。如果使用 HTTP Request 节点调用逻辑相对直接。请求/sandboxes接口创建沙箱拿到沙箱实例参数后再通过执行接口运行代码。整个过程可以把三个节点串联起来形成“创建沙箱 - 执行代码 - 返回结果 - 销毁沙箱”的工作流。销毁这一步很容易漏但正好 E2B 的沙箱有生命周期超时机制超时后会自动回收这也是我比较放心的原因之一。在实际生产里不要让 n8n 工作流里每个节点都创建一个新沙箱那样效率很低。正确做法是工作流开始时创建一个沙箱把沙箱 ID 传给后续多个节点复用最后由收尾节点统一关闭。5.4 沙箱内文件读取与应用往返Agent 在沙箱里跑任务往往不只是执行几行代码还需要读文件、生成文件、再拿结果。这种情况可以用 SDK 内置的文件 APIsandbox.files.write(/data/input.csv, a,b,c\n1,2,3) result sandbox.run_code(open_script) content sandbox.files.read(/data/output.csv) print(content)这个文件读写接口是和沙箱环境绑定的只存在于沙箱生命周期内。宿主机上的文件除非你显式挂载或者通过网络方式访问Agent 是碰不到的。我之前尝试让 Agent 之间通过共享目录交换数据后来发现设计上不适合这样用直接通过服务端 API 或对象存储中转才是常规做法。6. 运维调优与高频问题排查6.1 沙箱一直卡在 Pending 状态这个问题我遇到不止一次。沙箱状态长时间处于 Pending排查顺序一般是这样先看宿主机资源执行free -h和df -h确认内存、磁盘是否充足。沙箱创建时需要分配内存和临时磁盘资源不足时调度无法完成。再看容器日志重点看沙箱调度容器有没有报错比如镜像拉取失败、网络无法连接内部服务。最后看镜像如果使用的是自定义镜像确认镜像在仓库中确实存在且标签拼写无误。镜像很大、网络慢也会导致 Pending时间过长。解决思路是提前把镜像拉取到宿主机不要让创建沙箱时才去仓库拉。把常用镜像预热到本地后沙箱创建速度能快一个数量级。6.2 执行超时和资源耗尽Agent 生成的代码有时候就是会有 bug 或者无限循环这是常态。E2B 对单次执行有时间上限和内存上限但默认值不一定符合你的业务场景。如果你的 Agent 任务普遍需要跑几十秒甚至几分钟就要评估是一次执行时间要调大还是任务应该逻辑拆分。我自己的经验是宁可把任务拆小也不要无脑调大超时上限。超时设置过大的代价是一旦出现死循环这个沙箱实例可能长时间被占用其他有效任务反而没资源。内存也是同理沙箱里跑机器学习和浏览器自动化的时候内存占用很凶必要时给这类任务单独指定高内存模板别把所有任务混在同一个规格里。6.3 沙箱内访问内网资源失败很多 Agent 的实际价值体现在能操作内部系统比如查询内部订单库、调用内部工单接口。这里常遇到的坑是沙箱节点在 VPC 的 A 网段内网资源在 B 网段安全组或路由没有打通。排查时要看几个点确认两个网段是否能互通如果存在网络 ACL 或安全组限制要对沙箱节点所在的实例和目标资源同时放行确认沙箱运行时是否做了 NAT沙箱内部一般有自己的网络命名空间访问内网资源时的源 IP 会被转换成宿主机的 IP所以目标资源的安全组要为“宿主机 IP 所在网段”放行最后一下特别容易绕进去别只放行容器网段。6.4 多租户场景下的安全提示如果你把 E2B 能力开放给多个团队或者多个 Agent 产品共用安全隔离就是第一优先级。不同业务的数据不要放在同一个沙箱里各自使用独立的 API Key并设置不同的资源配额。启用日志审计也很重要。E2B 服务端的访问日志里会记录每次沙箱创建和销毁的元信息把这些日志接入到统一日志中心一旦出问题可以回溯是哪个调用方在什么时间创建了沙箱。有些团队还会在服务端前面再加一层准入网关直接按调用来源做过滤只有携带内部网关签名的请求才能触达 E2B 服务端。6.5 Agent 连接不上服务端的排查速查表现象可能原因处理办法SDK 报连接超时安全组未放行端口控制台检查安全组入方向规则SDK 报 401API Key 无效重新生成 Key 并核对环境变量create 成功但 run code 卡住沙箱实例资源不足查看宿主机资源并限制并发自定义镜像启动失败镜像缺少必要命令用基础镜像先跑通再逐步加依赖浏览器任务闪退沙箱内存不足单独建高内存模板并绑定使用7. 最后分享几点亲身经验7.1 从最小闭环开始不要一步到位如果你正准备动手自建 E2B我的建议是先别想太复杂。第一次跑通用最简单的配置、最小的机器验证“SDK 创建沙箱 - 执行代码 - 获取返回结果”这个闭环。闭环通了再逐步加深比如接文件操作、接 n8n、接自定义镜像。我见过太多人想把架构一步搭完美结果卡在某个环境问题上连最基础的验证都没做。7.2 把镜像模板当成代码来管模板镜像决定了沙箱的初始状态这个东西一定要版本化。每次加依赖、升系统库都打一个新版本的镜像标签并在服务端模板配置里显式指定版本。如果不这么做过一段时间你就不知道当前沙箱环境到底装了什么。镜像模板管理规范了Agent 的行为可预测性会大幅提升排查问题也容易得多。7.3 它已经成了我 Agent 项目的默认基础设施现在团队内部所有涉及代码执行的 Agent 能力包括数据分析、自动化运维脚本、代码生成验证几乎都跑在这套自建 E2B 上。沙箱环境干净、隔离彻底、销毁及时这几点看似基础实际使用中比任何炫酷的功能都重要。如果你做 Agent 开发也已经到了需要认真考虑安全的阶段用类似的思路把沙箱基础设施建起来后续的收益会非常大。