AI智能体需要执行代码、安装软件包、访问文件，这些操作必须在与主机系统隔离的工作空间中进行，以防止访问敏感凭证、文件或网络资源。沙盒提供了这种必要的隔离。

LangChain创始人Harrison Chase近期分析了AI智能体与沙盒集成的架构问题，指出目前存在两种核心架构模式：智能体在沙盒内运行，或者智能体在外部运行、将沙盒作为工具调用。

模式一：智能体在沙盒内运行

在此模式下，智能体完全运行在沙盒环境中，外部通过网络与之通信。

实现方式：构建预装了智能体框架的Docker或虚拟机镜像，在沙盒内运行，并从外部连接发送消息。智能体暴露API端点（通常是HTTP或WebSocket），应用程序跨沙盒边界与之通信。

优势：
* 镜像本地开发环境：如果本地运行智能体，沙盒中可以运行相同的命令。
* 直接访问环境：智能体可以直接访问文件系统并修改环境。
* 紧密耦合：当智能体需要与特定库交互或维护复杂环境状态时非常有用。

挑战：
* 通信基础设施：跨沙盒边界通信需要额外支持。部分提供商（如E2B）在SDK中处理了此问题，否则需要自行构建WebSocket或HTTP层，包括会话管理和错误处理。
* API密钥安全：API密钥必须存储在沙盒内以允许智能体进行推理调用，这在沙盒被攻破时会产生安全风险。E2B和Runloop等提供商正在开发密钥保险库功能来解决此问题。
* 更新迭代慢：更新需要重建容器镜像并重新部署，这会减慢开发迭代周期。
* 状态恢复：沙盒必须在智能体激活前恢复，通常需要额外逻辑。
* 知识产权风险：对于担心保护智能体知识产权的团队，智能体在沙盒内运行时，其代码和提示更容易被泄露。

Witan Labs的Nuno Campos指出了另一个安全问题：“智能体的任何部分都不能拥有比bash工具更多的权限。例如，如果你想要一个既有bash工具又有网络搜索工具的智能体，那么所有LLM生成的代码都可以进行无限制的网络访问，这是很大的安全风险。如果是模式二，你可以让工具拥有比LLM生成代码更多的权限，因为安全边界围绕bash工具，而不是整个智能体。”

模式二：沙盒作为工具

在此模式下，智能体运行在本地或服务器上，需要执行代码时通过API调用远程沙盒。

实现方式：智能体在本地或服务器上运行，当生成需要执行的代码时，调用沙盒提供商的API（如E2B、Modal、Daytona或Runloop）。提供商的SDK处理所有通信细节，从智能体角度看，沙盒就是另一个工具。

优势：
* 快速迭代：可以即时更新智能体代码而无需重建容器镜像，加快了开发期间的迭代速度。
* 密钥外置：API密钥保留在沙盒外，只有代码执行发生在隔离环境中。
* 关注点分离：智能体状态（对话历史、推理链、内存）存在于智能体运行的地方，与沙盒分离。这意味着沙盒故障不会丢失智能体状态，可以切换沙盒后端而不影响智能体的核心逻辑。

E2B的Tomas Beran指出的其他优势：
1. 可以在多个远程沙盒中并行运行任务。
2. 只在执行代码时为沙盒付费，而不是为整个进程的运行时间付费。

Zo Computer的Ben Guo补充道：“我们选择模式二还考虑到未来可能需要在GPU机器上运行智能体工具——通常持久沙盒和推理工具的环境需求会发生分化。”

挑战：
* 网络延迟：每次执行调用都要跨网络边界。对于有许多小执行的工作负载，延迟会累积。
* 状态管理：许多沙盒提供商提供有状态会话，其中变量、文件和已安装的包在同一会话的调用之间持续存在。这可以通过减少所需的往返次数来缓解部分延迟问题。

选择建议

选择模式一的情况：
* 智能体与执行环境紧密耦合（例如，需要对特定库或复杂环境状态的持续访问）。
* 希望生产环境密切镜像本地开发环境。
* 提供商的SDK为你处理了通信层。

选择模式二的情况：
* 需要在开发期间快速迭代智能体逻辑。
* 希望将API密钥保留在沙盒外。
* 更喜欢智能体状态和执行环境之间有更清晰的分离。

实现示例

使用deepagents框架的具体示例：

模式一：智能体在沙盒内
首先构建一个预安装智能体的镜像：
dockerfile
FROM python:3.11
RUN pip install deepagents-cli
然后在沙盒内运行。完整的实现需要额外的基础设施来处理应用程序和沙盒内智能体之间的通信（WebSocket或HTTP服务器、会话管理、错误处理）。

模式二：沙盒作为工具
“`python
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()
“`
这段代码运行时的流程：
1. 智能体在你的机器上本地规划。
2. 生成Python代码来解决问题。
3. 调用Daytona API，在远程沙盒中执行代码。
4. 沙盒返回结果。
5. 智能体看到输出并在本地继续推理。

社区讨论

这个话题在社区引发了讨论。

有开发者质疑模式一在生产环境中的可行性，认为存在“巨大的安全漏洞和各种极具挑战性的基础设施约束（沙盒可观察性、正常运行时间、扩展等）”。

Nico Ritschel对一些缺点提出不同观点，认为有简单实用的解决方案：
* API密钥问题可以通过代理推理调用和在沙盒外注入密钥来解决。
* 对于知识产权保护，可以将IP保存在智能体可访问的工具中。

Harrison Chase回应说密钥代理还不是标准做法，虽然一些提供商正在添加这些功能。

InvariumAI的Adish Jain指出，无论采用哪种模式，真正的问题是如何验证智能体在沙盒内实际执行的操作，强调了智能体行为测试的重要性。

开发者Ale Alonso表示沙盒化是使用deepagents时遇到的最大困难之一。

Nathan Flurry介绍了他们开发的Sandbox Agent SDK，这是一个专门解决“智能体在沙盒内”模式复杂性的工具。该SDK支持Claude Code、Codex、OpenCode、Cursor、Amp和Pi等多种智能体，提供统一的HTTP API来远程控制沙盒内的智能体。

小结

智能体需要在隔离环境中执行代码以确保安全。两种架构模式各有优势：在沙盒内运行智能体（镜像本地开发，紧密耦合）或在外部运行并将沙盒作为工具（易于更新，API密钥保持安全）。每种模式根据具体需求都有不同的好处和权衡。

https://x.com/hwchase17/status/2021261552222158955?s=46

http://github.com/rivet-dev/sandbox-agent

关注“鲸栖”小程序，掌握最新AI资讯