本文作者是LangChain创始人Harrison Chase，文章讨论AI agent沙箱化的两种模式：agent运行在沙箱内（Pattern 1）和沙箱作为工具（Pattern 2），旨在帮助开发者平衡安全与开发效率。
Harrison Chase 是 LangChain 的联合创始人兼 CEO。他于 2022 年底创立了这一开源框架，帮助开发者轻松构建基于大语言模型（LLM）的应用，已成为该领域最广泛采用的工具之一（从 Chains、Agents 到 LangGraph）。哈佛大学统计与计算机科学毕业，曾在 Kensho 领导实体链接团队、在 Robust Intelligence 负责机器学习验证。专注 MLOps、生成式 AI 与体育分析，目前致力于推动 AI 代理的长期自主能力和上下文工程。
太长不看版 (TL;DR)：
-
越来越多的 Agent（智能体）需要一个工作空间：即一台可以运行代码、安装包和访问文件的计算机。沙箱提供了这一功能。
-
将 Agent 与沙箱集成主要有两种架构模式：
-
- 模式 1 (Agent 在沙箱内)： Agent 在沙箱内部运行，你通过网络与其通信。优点：镜像本地开发体验，Agent 与环境紧密耦合。
- 模式 2 (沙箱作为工具)： Agent 在本地/你的服务器上运行，远程调用沙箱进行执行。优点：易于更新 Agent 逻辑，API 密钥保留在沙箱之外，关注点分离更清晰。
-
deepagents支持通过简单的配置实现这两种模式。
正文
感谢 Witan Labs 的 Nuno Campos、E2B 的 Tomas Beran 和 Mikayel Harutyunyan、Runloop 的 Jonathan Wall 以及 Zo Computer 的 Ben Guo 的审阅和评论。
越来越多的 Agent 需要一个工作空间，一台可以运行代码、安装包和访问文件的计算机。该工作空间需要是隔离的，这样 Agent 就无法访问你的凭据、文件或网络。沙箱通过在 Agent 的环境和你的宿主系统之间建立边界来提供这种隔离。构建这些 Agent 的团队面临的问题不是是否使用沙箱，而是如何将其与 Agent 架构集成。
根据 Agent 运行的位置，有两种常见的模式：在沙箱内部或在沙箱外部。每种模式都有不同的优点和权衡。
注意：本文关注的是为 Agent 提供完整"计算机"的沙箱，即像 Docker 容器或虚拟机（VM）那样完整的执行环境。我们不会涵盖进程级沙箱（如 bubblewrap）或语言级沙箱（如 Pyodide）。
模式 1：Agent 在沙箱内运行
在这种模式下，Agent 在沙箱内部运行。你通过网络与其通信。
**实践中的样子：**你构建一个预装了 Agent 框架的 Docker 或 VM 镜像，将其在沙箱中运行，并从外部连接以发送消息。Agent 暴露一个 API 端点（通常是 HTTP 或 WebSocket），你的应用程序跨越沙箱边界与其通信。
优点： 这种模式非常贴近本地开发，如果你在本地终端运行 deepagents，你在沙箱中运行的是相同的命令。Agent 拥有直接的文件系统访问权限，可以修改其环境。当 Agent 与执行环境紧密耦合时（例如 Agent 需要与特定库交互或维护复杂的环境状态），这一点非常有用。
**权衡/缺点：**跨沙箱边界的通信需要基础设施。一些提供商在他们的 SDK 中处理了这一点，例如，像 OpenCode 这样的 Agent 在沙箱内运行服务器，而像 E2B 这样的提供商可以通过干净的 API 暴露这一点。如果你的提供商不提供此功能，你需要自己构建 WebSocket 或 HTTP 层，包括会话管理和错误处理。
API 密钥必须存在于沙箱内，以便 Agent 进行推理调用。如果沙箱被入侵（无论是通过隔离技术的漏洞，还是通过窃取凭证的提示注入攻击），这会产生潜在的安全风险。注意：我们看到像 E2B 和 Runloop 这样的提供商正在开发机密库（secret vault）功能，这解决了这个问题。
更新需要重新构建容器镜像并重新部署，这会减慢开发过程中的迭代周期。
另一个缺点是，在 Agent 激活之前必须先恢复沙箱，这通常需要额外的逻辑。
对于那些担心保护 Agent 知识产权（IP）的人来说，如果你的 Agent 在沙箱中运行，那么窃取 Agent 的全部代码和提示词（prompts）会变得容易得多。
Witan Labs 的 Nuno Campos 还指出了另一个安全风险："我想说 Agent 在沙箱内的另一个缺点是，实际上你 Agent 的任何部分所拥有的权限都不能超过 bash 工具的权限。例如，假设你想要一个拥有 bash 工具和一个可以进行网页搜索或网页抓取工具的 Agent，那么所有 LLM 生成的代码都可以进行无限制的网页抓取（这是一个巨大的安全风险）。如果是'沙箱作为工具'模式，你可以轻松地让工具拥有比 LLM 生成的代码更高的权限（这对许多 Agent 来说听起来非常有用），因为安全边界围绕在 bash 工具周围，而不是整个 Agent。"
模式 2：沙箱作为工具
在这种模式下，Agent 在你的机器或服务器上运行。当它需要执行代码时，它通过 API 调用远程沙箱。
**实践中的样子：**你的 Agent 在本地（或你的服务器上）运行，当它生成需要执行的代码时，它会调用沙箱提供商的 API（如 E2B、Modal、Daytona 或 Runloop）。提供商的 SDK 处理所有通信细节。从你的 Agent 的角度来看，沙箱只是另一个工具。
**优点：**你可以即时更新 Agent 代码而无需重新构建容器镜像，这加快了开发期间的迭代速度。API 密钥保留在沙箱之外，只有执行过程是隔离发生的。这提供了更清晰的关注点分离：Agent 状态（对话历史、推理链、记忆）存在于 Agent 运行的地方，与沙箱分离。这意味着沙箱故障不会丢失你的 Agent 状态，并且你可以切换沙箱后端而不影响 Agent 的核心逻辑。
E2B 的 Tomas Beran 指出了此选项的另外两个好处： 能够选择并行地在多个远程沙箱中运行任务 仅在执行代码时为沙箱付费，而不是为整个进程的运行时付费。
Ben Guo 补充了关于将 Agent 运行时与沙箱运行时分离的最后一点好处："我们选择了模式 2（基于你提到的原因），但也为了准备未来，届时在 GPU 机器上运行 Agent 运行框架（harness）可能是有意义的，总体感觉持久化沙箱和推理框架之间的环境需求将会分化。"
**权衡/缺点：**网络延迟是主要的缺点。每次执行调用都要跨越网络边界。对于包含许多小型执行操作的工作负载，这可能会累积起来。
许多沙箱提供商提供有状态会话，其中变量、文件和已安装的包在同一会话的调用之间持久存在。这可以通过减少所需的往返次数来缓解一些延迟问题。
在模式之间进行选择
在以下情况下选择模式 1：
Agent 与执行环境紧密耦合（例如，Agent 需要持续访问特定库或复杂的环境状态） 你希望生产环境与本地开发非常接近 你的提供商的 SDK 为你处理通信层
在以下情况下选择模式 2： 你需要在开发过程中快速迭代 Agent 逻辑 你想将 API 密钥保留在沙箱之外 你倾向于在 Agent 状态和执行环境之间进行更清晰的分离
实现示例
为了使这些模式具体化，我们将展示使用 deepagents 的示例，这是一个内置沙箱支持的开源 Agent 框架。类似的模式也适用于其他 Agent 框架。
模式 1：Agent 在沙箱内
对于模式 1，首先你构建一个预装了 Agent 的镜像：
go
FROM python:3.11
RUN pip install deepagents-cli然后在沙箱中运行它。完整的实现需要额外的基础设施来处理你的应用程序与沙箱内 Agent 之间的通信（WebSocket 或 HTTP 服务器、会话管理、错误处理）。这超出了本文的范围，但我们会有一些后续文章对此进行更详细的探讨。
模式 2：沙箱作为工具
go
from daytona import Daytona
from langchain_anthropic import ChatAnthropic
from deepagents import create_deep_agent
from langchain_daytona import DaytonaSandbox
# 也可以使用 E2B、Runloop、Modal 来实现
sandbox = Daytona().create()
backend = DaytonaSandbox(sandbox=sandbox)
agent = create_deep_agent(
model=ChatAnthropic(model="claude-sonnet-4-20250514"),
system_prompt="You are a Python coding assistant with sandbox access.",
backend=backend,
)
result = agent.invoke(
{
"messages": [
{
"role": "user",
"content": "Run a small python script",
}
]
})
sandbox.stop()当这段代码运行时，会发生以下情况：
Agent 在你的机器上本地进行规划 它生成 Python 代码来解决问题 它调用 Runloop API，该 API 在远程沙箱中执行代码 沙箱返回结果 Agent 看到输出并在本地继续进行推理
结论
为了安全起见，Agent 需要在隔离环境中执行代码。主要有两种架构模式：在沙箱内运行 Agent（镜像本地开发，紧密耦合）或在外部运行并将沙箱作为工具（易于更新，API 密钥保持安全）。根据你的需求，每种模式都有不同的优点和权衡。
deepagents 支持通过简单的配置实现这两种模式。试用一下，看看哪种模式最适合你的用例。
深度解读与选型总结
这篇文章揭示了构建 AI Agent 时一个经常被忽视但至关重要的架构决策：Agent 的大脑（逻辑/状态）与四肢（执行环境）应该有多紧密的耦合？
- 模式 1 (Agent 在沙箱内) 本质上是一种 "单体架构" 思维。它适合那些需要维持高度复杂状态、模拟人类完整桌面操作的长周期任务。但其代价是牺牲了灵活性和安全性，一旦沙箱被攻破，Agent 的核心凭证（API Keys）和源码逻辑也将一并沦陷。
- 模式 2 (沙箱作为工具) 则代表了现代的 "微服务/云原生" 思维。它通过 API 将代码执行能力外包，实现了完美的关注点分离。这不仅让 Agent 更轻量、更易于迭代，最重要的是建立了严格的安全边界，沙箱即使"炸"了，也仅仅是丢了一个临时容器，Agent 的核心大脑和密钥依然安然无恙。
一句话选型建议： 如果您正在开发一个需要深度依赖特定系统环境（如复杂的 DevOps 运维机器人）的 Agent，模式 1 可能是必经之路；但对于绝大多数面向用户的通用 AI 助手或数据分析 Agent，模式 2 凭借其安全性、低耦合度和开发效率，将是更符合未来趋势的架构首选。
原文：https://x.com/hwchase17/status/2021261552222158955^\[1\]^