摘要
一句话总结
本文介绍了 AI Agent 连接沙盒的两种主要架构模式——“Agent 运行在沙盒内部”与“沙盒作为工具”，并对比了它们在安全性、迭代速度、系统耦合度等方面的优势与适用场景。
关键要点
- 沙盒的作用：沙盒（如 Docker 容器或虚拟机）为 Agent 提供隔离的执行环境，防止其越权访问宿主系统的凭证、文件或网络。
- 模式一（Agent 运行在沙盒内部）：Agent 预装并运行在沙盒镜像中，通过 HTTP 或 WebSocket 等网络端点与外部应用程序通信。
- 模式一优势：高度还原本地开发环境，Agent 与执行环境紧密耦合，拥有直接的文件系统访问权限，适合维护复杂的环境状态。
- 模式二（沙盒作为工具）：Agent 在本地或服务器运行，仅在生成需要执行的代码时，通过 API 远程调用沙盒提供商（如 E2B、Modal 等）。
- 模式二优势：无需重建镜像即可快速迭代代码，支持多沙盒并行任务，且仅按代码执行时间付费，具备较高的成本效益。
- 架构解耦与前瞻性：模式二实现了 Agent 状态（对话、记忆）与执行环境的分离，沙盒崩溃不会导致状态丢失，且适应未来推理算力与沙盒算力需求分化的趋势。
- 选型建议：若需紧密耦合且 SDK 已处理好通信层，选择模式一；若追求快速迭代、高安全性及状态分离，选择模式二。
- 框架支持：如
deepagents等开源 Agent 框架可通过简单配置同时支持这两种架构模式。
风险/不足
- 模式一的安全与凭证泄露风险：API 密钥必须存放在沙盒内，若沙盒因漏洞或提示词注入被攻破，凭证可能会被窃取。
- 模式一的 IP 泄露风险：Agent 运行在沙盒中，其完整的代码和提示词更容易遭到窃取。
- 模式一的权限控制风险：Agent 拥有与 bash 工具相同的最高权限，若生成的代码可无限制发起网络请求，会带来巨大的安全隐患。
- 模式一的基建与性能成本：若无 SDK 支持，需自行构建跨边界通信基础设施；更新代码需重新构建镜像导致迭代慢，且存在沙盒启动延迟。
- 模式二的网络延迟问题：每次执行调用都需要跨越网络边界，对于包含大量小型执行任务的工作负载，延迟会不断累积（可通过提供商的有状态会话功能缓解）。
正文
越来越多的 AI Agent 需要一个工作空间——一台可以运行代码、安装包和访问文件的计算机。为了防止 Agent 访问宿主系统的凭证、文件或网络，这个工作空间必须是隔离的。沙盒（Sandbox）通过在 Agent 环境和宿主系统之间建立边界来提供这种隔离。对于开发团队来说，面临的问题不在于是否使用沙盒，而在于如何将沙盒与他们的 Agent 架构进行集成。
根据 Agent 运行位置的不同（在沙盒内部或外部），目前有两种常见的架构模式。每种模式都有不同的优势和权衡。
注：本文重点讨论为 Agent 提供完整“计算机”执行环境的沙盒（如 Docker 容器或虚拟机），不涉及进程级（如 bubblewrap）或语言级（如 Pyodide）沙盒。
模式一：Agent 运行在沙盒内部 (Agent IN Sandbox)
在这种模式下，Agent 运行在沙盒内部，你通过网络与其进行通信。
实际应用方式： 你需要构建一个预装了 Agent 框架的 Docker 或 VM 镜像，在沙盒中运行它，并从外部发送消息进行连接。Agent 会暴露一个 API 端点（通常是 HTTP 或 WebSocket），你的应用程序跨越沙盒边界与其进行通信。
优势：
- 高度还原本地开发环境： 如果你在本地终端运行
deepagents，在沙盒中运行的也是相同的命令。 - 紧密耦合： Agent 拥有直接的文件系统访问权限，可以修改其环境。当 Agent 需要与特定库交互或维护复杂的环境状态时，这种模式非常有用。
权衡与劣势：
- 需要通信基础设施： 跨越沙盒边界的通信需要额外的基础设施。如果沙盒提供商（如 E2B）没有在 SDK 中提供干净的 API 封装，你需要自己构建 WebSocket 或 HTTP 层，包括会话管理和错误处理。
- 安全风险： API 密钥必须存放在沙盒内以进行推理调用。如果沙盒因隔离技术漏洞或提示词注入攻击被攻破，凭证可能会被窃取。（注：部分提供商正在开发密钥库功能来解决此问题）。
- 迭代速度慢： 更新代码需要重新构建和部署容器镜像，这会拖慢开发期间的迭代周期。
- 启动延迟： 沙盒必须在 Agent 激活前恢复运行，这通常需要额外的逻辑。
- IP 泄露风险： 如果 Agent 运行在沙盒中，窃取 Agent 的完整代码和提示词会变得容易得多。
- 权限控制风险： Agent 的所有部分都拥有与 bash 工具相同的最高权限。如果 Agent 生成的代码可以无限制地进行网络请求，将带来巨大的安全隐患。相比之下，将沙盒作为工具可以更容易地为不同工具分配不同级别的权限。
模式二：沙盒作为工具 (Sandbox as Tool)
在这种模式下，Agent 运行在你的本地机器或服务器上。当它需要执行代码时，通过 API 远程调用沙盒。
实际应用方式： Agent 在本地（或服务器上）运行，当它生成需要执行的代码时，调用沙盒提供商（如 E2B、Modal、Daytona 或 Runloop）的 API。提供商的 SDK 会处理所有通信细节。从 Agent 的角度来看，沙盒只是另一个工具。
优势：
- 快速迭代： 无需重建容器镜像即可即时更新 Agent 代码，加快开发速度。
- 安全性高： API 密钥保留在沙盒外部，只有代码执行过程在隔离环境中进行。
- 关注点分离： Agent 的状态（对话历史、推理链、记忆）与沙盒分离。沙盒崩溃不会导致 Agent 状态丢失，且可以无缝切换沙盒后端而不影响核心逻辑。
- 支持并行： 可以在多个远程沙盒中并行运行任务。
- 成本效益： 仅在执行代码时为沙盒付费，而不是为整个进程的运行时间付费。
- 面向未来架构： 未来 Agent 的推理环境（如 GPU 机器）与持久化沙盒的硬件需求可能会产生分化，分离运行环境更具前瞻性。
权衡与劣势：
- 网络延迟： 每次执行调用都需要跨越网络边界。对于包含大量小型执行任务的工作负载，延迟会不断累积。
- 缓解方案： 许多沙盒提供商提供有状态会话，变量、文件和安装的包可以在同一会话的多次调用中持久存在，这可以通过减少网络往返次数来缓解延迟问题。
如何选择合适的模式
选择模式一（Agent 运行在沙盒内部）的场景：
- Agent 与执行环境紧密耦合（例如，Agent 需要持久访问特定库或复杂的环境状态）。
- 你希望生产环境尽可能与本地开发环境保持一致。
- 你的沙盒提供商 SDK 已经为你处理好了通信层。
选择模式二（沙盒作为工具）的场景：
- 需要在开发期间快速迭代 Agent 逻辑。
- 希望将 API 密钥保留在沙盒外部以确保安全。
- 倾向于将 Agent 状态与执行环境进行更清晰的分离。
实现示例
为了让这些模式更具体，我们以 deepagents（一个内置沙盒支持的开源 Agent 框架）为例。类似的模式也适用于其他 Agent 框架。
模式一：Agent 运行在沙盒内部 首先，你需要构建一个预装了 Agent 的镜像，然后在沙盒中运行它。完整的实现需要额外的基础设施来处理应用程序与沙盒内 Agent 之间的通信（如 WebSocket/HTTP 服务器、会话管理、错误处理等）。
模式二：沙盒作为工具 当代码运行时，流程如下：
- Agent 在你的本地机器上进行规划。
- 它生成用于解决问题的 Python 代码。
- 它调用 Runloop API，在远程沙盒中执行该代码。
- 沙盒返回执行结果。
- Agent 查看输出并在本地继续进行推理。
结论
出于安全考虑，Agent 需要在隔离的环境中执行代码。目前主要有两种架构模式：在沙盒内部运行 Agent（还原本地开发、紧密耦合），或在外部运行并将沙盒作为工具（易于更新、API 密钥安全）。每种模式都有其优势和权衡，取决于你的具体需求。
deepagents 通过简单的配置即可支持这两种模式，开发者可以根据自己的用例尝试并选择最合适的架构。