原文链接：https://blog.langchain.com/the-two-patterns-by-which-agents-connect-sandboxes/
作者：Harrison Chase
译者：倔强青铜三
越来越多的智能体需要属于自己的“工作空间”——一台可以执行代码、安装依赖包并能读写文件的计算机。为了安全，这个工作空间必须是隔离的，以防智能体访问到你的凭证、主机文件或网络。沙箱（Sandbox）通过在智能体执行环境与宿主系统之间建立一道边界，提供了这种必要的隔离能力。
因此，对于构建智能体的团队来说，核心问题已不再是“是否需要使用沙箱”，而是“如何将沙箱与智能体架构进行有效集成”。
当前业界主要有两种集成模式，其根本区别在于智能体运行的位置：是在沙箱内部，还是在沙箱外部。每种模式都有其独特的优势和需要权衡的方面。
请注意：本文聚焦于为智能体提供完整“计算机”功能的沙箱，即完整的执行环境，例如 Docker 容器或虚拟机。我们不讨论进程级沙箱（如 bubblewrap）或语言级沙箱（如 Pyodide）。
模式 1：智能体在沙箱内运行
在这种模式中，你的智能体直接在沙箱环境内部运行，而你通过网络与之通信。
图中展示了两个独立的客户端分别与两个沙箱环境进行通信，智能体（Agent）位于每个沙箱内部。
实际应用是怎样的？
你需要构建一个预装了智能体框架的 Docker 或虚拟机镜像，在沙箱中启动它，然后从外部连接并发送消息。智能体通常会暴露一个 API 端点（通常是 HTTP 或 WebSocket），你的应用程序通过沙箱边界与这个端点进行通信。
优势
这种模式最贴近本地开发的体验。如果你在本地终端运行一个智能体框架，那么在沙箱中运行的命令与本地几乎相同。智能体可以直接访问沙箱的文件系统，并能修改其运行环境。当智能体需要与特定库进行交互，或者需要维护复杂的环境状态时，这种紧密耦合的方式非常有用。
需要权衡的方面
- 通信开销：跨越沙箱边界的通信需要额外的基础设施支持。部分服务商在其 SDK 中已对此进行了封装，但如果你使用的服务商不提供，你就需要自行构建 WebSocket 或 HTTP 通信层，包括会话管理、错误处理等。
- 安全风险：为了让智能体能够调用大模型进行推理，API 密钥必须存放在沙箱内部。如果沙箱因隔离技术漏洞或通过提示注入攻击导致凭据被盗，就会产生安全风险。
我们注意到像 E2B 和 Runloop 等服务商正在开发密钥保险库功能，有望解决这个问题。
- 更新与迭代：更新智能体逻辑需要重新构建容器镜像并部署，这在开发阶段的迭代周期可能会变慢。
- 启动延迟：必须等待沙箱恢复启动后，智能体才能被激活，这通常需要额外的逻辑来处理。
- 知识产权风险：如果你的智能体代码和提示词在沙箱中运行，那么窃取整个智能体的代码会变得相对容易。
- 权限控制粒度：Witan Labs 的 Nuno Campos 指出了另一个安全风险：当智能体在沙箱内运行时，智能体的任何部分都不能拥有比 bash 工具更高的权限。例如，如果你想构建一个既能执行 bash 命令又能执行网络搜索的智能体，那么所有由大模型生成的代码都可能进行无限的网络请求，这是一个巨大的安全风险。相比之下，如果是模式2，你可以轻松地赋予某些工具（非 bash）比大模型生成代码更高的权限，因为安全边界只围绕 bash 工具，而不是整个智能体。
模式 2：沙箱作为工具
在这种模式中，智能体运行在你的本地机器或服务器上。当它需要执行代码时，通过 API 远程调用沙箱环境。
图中展示了两个客户端连接到一个中心服务器，服务器内的智能体将沙箱作为工具进行远程调用。
实际应用是怎样的？
你的智能体在本地（或某个服务器上）运行，当它生成需要执行的代码时，它会调用沙箱服务商的 API（例如 E2B、Modal、Daytona 或 Runloop）。服务商的 SDK 会处理所有通信细节。从智能体的视角看，沙箱只是一个可用的工具。
优势
- 快速迭代：你可以即时更新智能体代码，而无需重建和重新部署容器镜像，这在开发阶段能显著加快迭代速度。
- 密钥安全：API 密钥保留在沙箱外部，只有代码执行过程在隔离环境中进行，安全性更高。
- 职责清晰：这种模式实现了更清晰的关注点分离。智能体的状态（如对话历史、思维链、记忆模块）驻留在智能体运行的地方，与沙箱环境分开。这意味着即使沙箱崩溃，也不会丢失智能体的状态。你甚至可以在不影响智能体核心逻辑的前提下，切换沙箱的后端服务。
- 并行与成本：E2B 的 Tomas Beran 指出了此模式的两个额外好处：
- 可以在多个远程沙箱中并行运行任务。
- 仅在执行代码时为沙箱付费，而不是为智能体的整个运行过程付费。
- 环境解耦：Zo Computer 的 Ben Guo 补充了关于分离智能体运行时与沙箱运行时好处的一点见解：“我们选择模式2，也是考虑到未来可能在 GPU 机器上运行智能体程序是有意义的——普遍感觉环境需求将在持久沙箱和推理程序之间分道扬镳。”
需要权衡的方面
主要的缺点在于网络延迟。每一次执行调用都需要跨越网络边界。对于那些需要大量、频繁进行小规模执行的工作负载来说，累积的延迟可能会成为一个问题。不过，许多沙箱提供商提供了有状态的会话，允许变量、文件和已安装的包在同一个会话的多次调用之间持久化，这可以在一定程度上通过减少必要的往返次数来缓解延迟问题。
如何在两种模式间做出选择？
什么时候应优先考虑模式 1（智能体在沙箱内）？
- 智能体与执行环境紧密耦合，例如需要持续访问特定库或维护复杂的环境状态。
- 你希望生产环境能够紧密地镜像本地开发流程。
- 你所使用的服务商 SDK 已经为你妥善处理了通信层。
什么时候应优先考虑模式 2（沙箱作为工具）？
- 你需要在开发阶段快速迭代智能体逻辑。
- 你希望将 API 密钥保留在沙箱之外以保证安全。
- 你更倾向于让智能体状态和执行环境之间有更清晰的分离。
实现示例：基于 Deepagents 框架
为了让这两种模式更具体，我们以 Deepagents（一个内置沙箱支持的开源智能体框架）为例进行展示。其他智能体框架也适用类似的模式。
模式 1：智能体在沙箱内
对于模式 1，首先你需要构建一个预装了智能体的 Docker 镜像。基础镜像示例如下：
FROM python:3.11
RUN pip install deepagents-cli
然后在沙箱内运行这个镜像。完整的实现需要额外的基础设施来处理应用程序与沙箱内智能体之间的通信，这超出了本文的范围，但我们后续会有文章深入探讨这一点。
模式 2：沙箱作为工具
以下代码展示了如何使用 Daytona 沙箱作为工具（也可以替换为 E2B、Runloop、Modal）：
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()
运行上述代码时，流程如下：
- 智能体在本地机器上进行规划和推理。
- 生成需要执行的 Python 代码。
- 通过 API 调用（示例中是 Daytona），在远程沙箱中执行生成的代码。
- 沙箱将执行结果返回。
- 智能体接收到输出后，继续在本地进行下一步的推理。
总结
智能体要在隔离环境中安全地执行代码，主要存在两种架构集成模式。模式 1 让智能体在沙箱内运行，模拟本地开发，耦合紧密；模式 2 则将沙箱作为外部工具调用，易于更新且能更好地保护密钥安全。每种模式都有其适用场景和权衡点，开发者应根据项目对迭代速度、安全性、环境耦合度的需求来做出选择。
Deepagents 这样的框架通过配置即可支持这两种模式，你可以根据自己的实际用例进行尝试和选择。对于技术架构的深入讨论和实践分享，欢迎在专业的开发者社区中与同行交流。
发表于 2026-2-12 11:10:59
|
查看: 31|
回复: 0
