智能体如何用 E2B Code Interpreter 隔离执行不安全代码 #

做智能体时，最诱人的能力之一是让模型自己写代码、自己跑结果：清洗数据、试算公式、画图验证。麻烦也在这里——一旦「生成」和「执行」接在同一条链上，你等于把一段默认不可信的代码放进了自己的运行环境。

一种直觉是：干脆把整个智能体都塞进沙箱。隔离是更彻底了，但成本往往不划算。智能体项目通常很大——依赖、模型客户端、编排框架、业务代码一起进镜像，冷启动与加载会明显变慢；若工作目录还要挂对象存储做读写，每次文件访问又叠一层网络延迟。真正需要隔离的，常常只是那一小段「模型生成、即将执行」的代码，而不是整条 Agent 进程。

因此更常见的切法是：Agent 仍跑在你的服务侧，只把不安全的执行交给 Code Interpreter 沙箱。本文从智能体的执行面出发，说明为什么宿主直跑不安全，以及如何用 E2B 的 Code Interpreter（e2b-code-interpreter / @e2b/code-interpreter）做这层隔离，并划清它能挡住什么、不能代替什么。

核心问题：智能体为什么不能在宿主上直接跑代码？ #

智能体（Agent）和「只会聊天的模型」差在一步：它往往会把生成结果接到工具上——算表、画图、调库、拼一段脚本，写完就跑。方便的同时，执行权落在哪就成了硬问题。

这里的代码默认应视为不安全：不一定出自攻击者，但模型可能 hallucinate 出危险命令；用户输入可能被拼进 prompt；工具链也可能被间接投毒。若解释器与宿主同权——同一台机器、同一用户、同一文件系统与网络——一次 os.system、一次随意写盘、一次外联，影响面就不再是会话里的变量，而是密钥、仓库、内网。

所以对智能体而言，正确问法不是「这段代码看起来能不能跑」，而是：执行必须落在边界清晰、可销毁、与宿主隔离的环境里。没有这层隔离，「Code Interpreter」只是把攻击面从对话扩成了任意代码执行。数据分析 Agent、带 function calling 的应用、IDE 里的 AI 助手，都在把「生成 + 执行」做成默认路径——隔离因此是能力前提，不是事后补丁。

E2B：给智能体一块可销毁的执行环境 #

E2B 做的事很聚焦：在云端提供安全隔离的沙箱，专门用来跑 AI 生成的代码。你通过 SDK 创建、控制沙箱；代码在沙箱里执行，宿主进程只负责下发代码、收回结果。对智能体来说，这等于把「执行面」从本机挪到一块用完可丢的远程环境——Agent 本体仍留在服务侧，沙箱只承接那一段危险代码，正是开篇说的切法。

和常见做法比一下边界：

本机容器当然也能隔离，但 Agent 往往是「短生命周期、高并发、要快速销毁」的工作负载；把沙箱运维外包给专用基础设施，通常比在业务进程旁再挂一套容器编排更省事。E2B 的定位就是这条路径上的开源基础设施，而不是又一个嵌在应用里的本地解释器。

落到智能体链路里，位置通常是：

模型决策 → 工具调用（把代码当参数）→ E2B 沙箱执行 → stdout / 返回值回传 → 模型继续推理

Agent 框架（LangChain、自研 function calling 等）只负责「何时调工具、传什么代码」；真正危险的那一步——解释执行——发生在沙箱内。下一节看 Code Interpreter SDK 怎样把这一步接进工具函数。

用 e2b-code-interpreter 让智能体跑代码 #

e2b-dev/code-interpreter 提供面向「在沙箱里解释执行代码」的 SDK：Python 包 e2b-code-interpreter，JS/TS 包 @e2b/code-interpreter。（SDK 源码现已迁到 E2B monorepo；该仓库仍保留沙箱 template 等资源。）对智能体而言，它通常被包成一个工具：入参是一段代码字符串，出参是执行文本或结构化结果。

安装与鉴权很直接：

pip install e2b-code-interpreter
# 或: npm i @e2b/code-interpreter
export E2B_API_KEY=e2b_***

最小闭环是：创建沙箱 → run_code / runCode → 读返回值。Python 示例如下（与官方 README 一致）：

from e2b_code_interpreter import Sandbox

with Sandbox.create() as sandbox:
    sandbox.run_code("x = 1")
    execution = sandbox.run_code("x += 1; x")
    print(execution.text)  # 2

JS/TS 同理：Sandbox.create() 后两次 runCode，第二次能读到第一次留下的 x。接进 Agent 时，工具函数往往长这样：收到模型给出的 code → 在已有（或临时创建的）Sandbox 上执行 → 把 execution.text（以及错误信息）作为 tool result 回给模型。宿主进程里不要 exec / eval 这段代码。

同一沙箱内多次调用会共享解释器状态（变量、已 import 的模块等），这很适合多步 Agent：先加载数据、再变换、再画图或汇总，而不必把全部逻辑塞进一次 tool call。任务结束应关闭沙箱，避免会话与计费悬空；需要额外依赖时，则走自定义 sandbox template，而不是在宿主上 pip install。

隔离边界与能力边界 #

把执行丢进 E2B，解决的是宿主侧风险：模型或用户给出的代码，默认碰不到你机器上的密钥文件、源码树、本机进程，也不会自动继承 Agent 主机的本地权限与网络身份。沙箱可创建、可销毁，一次任务的脏状态不必留在业务服务器上。对智能体来说，这是「敢让它跑代码」的基础隔离；也正因为只隔离执行面，才不必把整颗 Agent（连同大镜像与对象存储挂载）都推进沙箱里。

但隔离不是万能盾，至少要分清这几层：

• 沙箱内仍是完整执行环境。 代码可以在沙箱里读写其可见文件系统、消耗 CPU/内存、按产品策略访问网络。你传进去的临时数据、中间结果，对沙箱内进程是可读可改的；隔离的是「出沙箱打宿主」，不是「沙箱里绝对老实」。
• 业务信任假设不会自动消失。 若 Agent 把沙箱输出当真理写进数据库、或把高权限 API Key 塞进沙箱环境变量，问题就从「宿主机被攻陷」变成「被工具结果骗了 / 密钥进了执行面」。沙箱不替你做输出校验，也不替你做最小权限。
• 配额与滥用是另一条线。 恶意或失控的循环、大批量创建沙箱，打的是账单与可用性，不是传统意义的本机提权。限流、超时、每会话沙箱数，属于产品层控制，要单独设计。

默认 Code Interpreter 模板够用多数「算一下、画个图」的场景；当 Agent 需要特定版本的库、系统依赖或定制运行时，应按官方方式做自定义 sandbox template（仓库里的 template 指南），把依赖打进镜像，而不是在每次 run_code 里临时乱装、或退回宿主安装。模板定制的是能力面，隔离边界仍然由「远端沙箱 vs 宿主」这条线决定。

实践注意点 #

API Key 只放在 Agent 服务侧。 E2B_API_KEY 用于创建和控制沙箱，属于基础设施凭证，应放在后端环境变量或密钥管理里，不要写进前端、Prompt、日志，更不要随 tool 参数传给模型。用户浏览器直连 E2B 等于把账单与沙箱创建权交出去。

管好沙箱生命周期。 按会话或按任务创建沙箱，设超时，用完关闭（Python 的 with Sandbox.create() 就是一种自然收口）。多步 Agent 可复用同一沙箱以保留变量；跨用户、跨会话则不要共用，以免状态串扰。长期挂起的沙箱既费钱，也扩大窗口期。

把结果当成不可信输入再喂回模型。 execution.text、stdout、沙箱里生成的文件，都应经工具层整理后再作为 tool result 返回——截断过长输出、区分成功与报错、必要时只回摘要。需要图表或文件时，按 SDK / 文档提供的方式取回，再决定是否落盘到你自己的对象存储；默认不要假设「跑完就安全可写库」。

常见坑可以记三条：密钥进仓库或进沙箱环境变量；只 create 不关闭；以及把「上了 E2B」理解成「输出可信、权限不用收」。前两者是工程失误，第三者是威胁模型画错了。

小结 #

1. 智能体要跑代码，执行面就该外置。 与宿主同权的解释器，把「生成」放大成任意代码执行；隔离是能力前提，不是锦上添花。
2. E2B + Code Interpreter 是一条可落地的实现。 用 e2b-code-interpreter / @e2b/code-interpreter 把 tool call 接到远端沙箱，宿主只下发代码、收回结果。
3. 分清隔离边界。 挡的是对宿主的直接伤害；沙箱内行为、输出信任、密钥与配额，仍要你自己收口。

延伸阅读：E2B 文档、code-interpreter 仓库、E2B Cookbook。