跳转至

智能体沙箱隔离

概述

沙箱隔离（Sandboxing）是指将智能体调用的代码或工具运行在受限的隔离执行环境中，从而约束进程可访问的资源。随着智能体越来越多地执行任意代码、调用第三方 MCP 服务器并运行多步骤工具链，沙箱隔离已成为一项基础性安全控制手段——它能限制被攻破的工具、恶意提示词注入载荷或意外副作用所造成的爆炸半径。

沙箱的核心保证：在沙箱内运行的进程，无论运行时收到何种指令，均无法访问沙箱策略未明确允许的文件系统路径、网络端点或系统调用。

隔离层级分类

智能体沙箱分为四个层级，在隔离强度与启动速度、运维复杂度之间进行权衡：

层级 机制 隔离强度 启动速度 示例
操作系统级策略 内核系统调用过滤、seccomp、Seatbelt、命名空间 jail 中 <10 ms srt、nsjail、bubblewrap
容器 Linux 命名空间 + cgroups；共享宿主机内核 中 <100 ms Docker、gVisor（用户态内核覆盖层）
微虚拟机 硬件虚拟化（KVM）；精简 Guest 内核 高 100–500 ms Firecracker、Kata Containers
云托管沙箱 托管型沙箱即服务；隔离由提供商负责 高（不透明） <1 s（预热） E2B、Daytona、Modal

层级选择主要取决于两个因素的权衡：被执行代码的信任级别，以及智能体工作流的延迟预算。

解决方案全景

云托管沙箱

通过 API 按需提供隔离执行环境的托管服务。隔离层由提供商负责，团队将沙箱作为基础原语使用。

E2B

E2B 是一个开源基础设施平台，用于在安全的隔离云沙箱中运行 AI 生成的代码。智能体启动沙箱、通过 SDK 执行命令或代码，完成后销毁沙箱——所有隔离工作均由提供商处理。

属性 详情
部署模式 云端（AWS、GCP）；可通过 Terraform 自托管
SDK 语言 Python、TypeScript/JavaScript
主要用途 AI 代码解释器；执行不可信的 LLM 生成代码
GitHub Stars ~12.4k
许可证 开源（Apache-2.0 核心）
  • 优势：API 简洁；无需基础设施知识；专为 AI 智能体代码执行而构建
  • 局限：依赖云端；对底层隔离机制的控制有限；可能存在冷启动延迟

Daytona

Daytona 提供"面向 AI 生成代码执行与智能体工作流的安全弹性基础设施运行时"。每个沙箱都是完全隔离的计算环境，拥有独立的内核、文件系统、网络栈以及分配的 vCPU/RAM/磁盘。

属性 详情
部署模式 云端；开源可自托管
SDK 语言 Python、TypeScript、Ruby、Go、Java
启动时间 < 90 ms
隔离方式 每个沙箱独享内核与文件系统；支持有状态快照
主要用途 需要在多步骤之间保持持久状态的智能体工作流
  • 优势：真正的内核隔离；支持有状态环境快照以服务多步骤智能体；SDK 覆盖面广；兼容 OCI/Docker
  • 局限：比操作系统级沙箱更重；自托管会增加运维负担

Modal 是一个面向 ML/AI 工作负载的云执行平台。它在隔离容器中运行 Python 函数，支持 GPU 访问，常用于在沙箱环境中为智能体提供计算密集型工具（模型推理、批处理任务）。

属性 详情
部署模式 全托管云
主要语言 Python
隔离方式 基于容器；每个任务硬件隔离
核心差异化 GPU 支持；快速冷启动；按用量计费
主要用途 计算密集型智能体工具；模型推理沙箱化
  • 优势：GPU 访问；运维开销低；按调用次数计费
  • 局限：以 Python 为中心；与低级别工具相比，网络策略控制粒度较粗

LangSmith Sandboxes

LangSmith Sandboxes（以私有预览形式发布）是由 LangChain 打造的、用于运行不可信智能体生成代码的安全、临时性环境。每个沙箱都运行在一个硬件虚拟化的 microVM 中，沙箱之间实现内核级隔离——这比共享命名空间的容器提供了更强的保证。

属性 详情
部署模型 全托管云（LangSmith）
隔离机制 每个沙箱一个硬件虚拟化 microVM
SDK 语言 Python、TypeScript（LangSmith SDK）
框架耦合 框架无关——可与任意智能体框架或不用框架配合；与 Deep Agents 原生集成
凭证处理 认证代理（Authentication Proxy）——沙箱通过代理访问外部服务，因此密钥永不进入沙箱运行时
主要用例 不可信智能体代码执行；横向扩展的评测——每次试验都获得一个全新、状态隔离的沙箱
状态 私有预览
  • 优势：对已在使用 LangSmith SDK（链路追踪或部署）的团队，一行代码即可接入；每次评测试验都在自己的沙箱中运行，试验间从不共享状态，从而支持数百个并行运行；得益于认证代理，凭证永不接触沙箱
  • 局限：私有预览——尚未正式可用；在预置与计费上绑定 LangSmith 平台
  • 智能体相关性：被用作 Harbor 评测运行框架背后的可插拔沙箱提供方之一，用于分布式、并行的智能体基准执行

AWS Lambda MicroVMs

AWS Lambda 将每次函数调用都运行在专属的 Firecracker 微虚拟机中（详见下文 Firecracker），让智能体工具调用获得硬件虚拟化级别的隔离，同时无需直接管理虚拟机。作为托管云沙箱，它与 E2B、Daytona 和 Modal 并列——隔离机制与原生 Firecracker 的微虚拟机层相同，但以全托管、按调用计费的方式提供，而非自运营基础设施。

属性 详情
部署模式 全托管云（AWS）
隔离机制 每次调用独享 Firecracker 微虚拟机
最大运行时长 每次调用最长 8 小时
最大内存 最高 10 GB（与标准 Lambda 限制对齐）
冷启动开销 相较标准 Lambda 冷启动额外增加约 100–200 ms
突发扩展 最高 4 倍垂直突发扩展
生命周期控制 可配置的自动暂停与自动恢复
  • 优势：无需运维任何基础设施；与 AWS 智能体技术栈（Bedrock AgentCore、Step Functions）直接集成；自动暂停/恢复可降低长时间运行智能体会话的闲置成本
  • 局限：仅限 AWS；相较标准 Lambda，额外的冷启动开销对延迟敏感的单工具调用智能体循环有影响
  • 智能体相关性：适合需要在每次工具调用时获得硬件隔离、但不想自行搭建 Firecracker 的 AWS 原生智能体平台

Docker Sandboxes

Docker Sandboxes 是 Docker 面向本地 AI 编程智能体的产品，用于在开发者机器上运行一次性的隔离 microVM。它不同于普通 Docker 容器：每个沙箱都是与宿主机之间具有硬安全边界的完整 microVM，而不只是使用命名空间隔离的容器。

属性 详情
部署模式 本地（开发者机器）；macOS 与 Windows
隔离机制 每个智能体会话一个 microVM
支持的智能体 Claude Code、Gemini CLI、Copilot CLI、Codex、OpenCode、Kiro 等
macOS 安装 brew trust docker/tap && brew install docker/tap/sbx
Windows 安装 winget install Docker.sbx
是否需要 Docker Desktop 否
许可证 专有（可免费开始使用；团队 / 企业管理控制需联系 Docker）

核心能力：

  • 安全启用 YOLO 模式：即使启用 --dangerously-skip-permissions（跳过审批提示），智能体也运行在 microVM 中，不会直接影响宿主机
  • 沙箱内可使用 Docker：智能体可在沙箱内部启动自己的容器
  • 真实开发环境：智能体可以安装软件包、修改配置并无人值守地运行服务，仅挂载项目工作区
  • 可定制控制：支持细粒度网络、文件系统与资源限制；企业版增加团队级集中管理配置

  • 默认一次性：启动速度快于完整虚拟机，可通过一条命令销毁

  • 优势：本地零摩擦接入；无需 Kubernetes；兼容主流编程智能体；microVM 隔离强于普通 Docker 容器；专为智能体编程工作流设计

  • 局限：仅限本地，不是云端执行平台；团队级网络 / 文件系统策略需联系 Docker 销售；仅支持 macOS 与 Windows（未提及 Linux 客户端）
  • 智能体相关性：主要用于让 Claude Code、Gemini CLI、Kiro 等 AI 编程智能体在无人值守时运行，同时避免危及开发者宿主机

Kubernetes Agent Sandbox（kubernetes-sigs）

Agent Sandbox 是 Kubernetes 原生平台，用于管理隔离、有状态、单例工作负载，面向 AI 智能体运行时、开发环境及需要长时间运行容器和稳定身份的场景。它是 Kubernetes SIG Apps 的正式子项目（kubernetes-sigs/agent-sandbox）。

属性 详情
部署模式 在任意 Kubernetes 集群上自托管
隔离后端 标准容器、gVisor（用户态内核）、Kata Containers（虚拟机级硬件虚拟化）
供给速度 通过 SandboxWarmPool 预热池实现亚毫秒级沙箱分配
SDK 语言 Python、Go
许可证 Apache-2.0
状态 活跃（最近更新于 2026 年 4 月）

相比普通 Pod 的核心能力：

  • SandboxWarmPool：预热 Pod 池消除冷启动延迟，沙箱可在毫秒级分配，无需等待 Pod 调度
  • 休眠与恢复：沙箱空闲时暂停，收到网络连接后自动恢复；状态得以保留，空闲期间的计算成本接近于零
  • 稳定身份：每个 Sandbox 具有稳定 DNS 主机名，可选用 PVC 持久化存储，重启后仍保留；智能体无需在应用层重新初始化即可重连
  • 定时删除：控制器按 TTL 自动清理

  • 文件系统与卷 API：Python / Go SDK 直接暴露沙箱内的读写、列表和文件传输操作；卷可挂载以保存持久数据

  • 优势：Kubernetes 原生（RBAC、命名空间、网络策略均可复用）；隔离运行时无关；WarmPool 解决交互式智能体工作负载的冷启动；提供 Python 与 Go SDK；无厂商锁定

  • 局限：需要已有 Kubernetes 集群；集群管理带来运维复杂度；隔离强度取决于后端（需要 gVisor 或 Kata 才能提供强保证）
  • 智能体相关性：适合作为 Kubernetes 多租户智能体平台、CI/CD 智能体流水线、编程智能体、计算机操控智能体和长时间运行智能体环境的执行层（OpenClaw on Agent Sandbox 是已记录的用例）

完整架构（包括 GKE 产品化与 Agent Substrate）参见 Kubernetes Agent Sandbox。

基础设施原语

通过操作系统或 Hypervisor 机制实现隔离的底层工具。这些工具是云托管服务的底层基础，也可在需要细粒度策略控制时直接使用。

Anthropic 沙箱运行时（srt）

srt 在操作系统层面强制执行文件系统和网络限制，无需容器。其主要用途是将单个 MCP 服务器进程包裹在最小权限策略封装中。

属性 详情
层级 操作系统级策略
macOS 机制 sandbox-exec，搭配动态生成的 Seatbelt 配置文件
Linux 机制 bubblewrap，搭配网络命名空间隔离
网络过滤 HTTP 与 SOCKS5 代理；仅允许白名单
安装方式 npm install -g @anthropic-ai/sandbox-runtime
许可证 Apache-2.0

详细内容参见 Anthropic 沙箱运行时。

Firecracker（AWS）

Firecracker 是一款使用 KVM 创建微虚拟机的虚拟机监控器（VMM），是 AWS Lambda 和 AWS Fargate 的底层驱动。每台微虚拟机可在毫秒级内启动，攻击面极小（无多余设备），并在硬件虚拟化边界处实现隔离。

属性 详情
层级 微虚拟机
隔离机制 KVM 硬件虚拟化 + seccomp 过滤器 + Jailer（cgroup/命名空间）
启动时间 ~125 ms（冷启动），< 5 ms（恢复快照）
默认资源 1 vCPU，128 MiB RAM（可配置）
许可证 Apache-2.0
采用情况 驱动 AWS Lambda 和 AWS Fargate
  • 优势：以接近容器的启动速度实现接近虚拟机的隔离强度；大规模生产验证；支持快照/恢复
  • 局限：需要 Linux KVM 宿主机；不能直接替代容器；运维复杂度较高
  • 智能体相关性：适用于需要强多租户安全隔离的每次智能体运行微虚拟机场景

gVisor（Google）

gVisor 是一个用 Go 编写的应用内核，运行在用户态，在系统调用到达宿主机内核之前对其进行拦截。其 OCI 运行时（runsc）与 Docker 和 Kubernetes 集成，可作为 runc 的直接替代品。

属性 详情
层级 容器（用户态内核覆盖层）
隔离机制 系统调用拦截并在 Go 中重新实现（Sentry + Gofer 进程）
容器集成 兼容 OCI；为 Docker/Kubernetes 提供 runsc 运行时
性能开销 系统调用密集型工作负载下约 10–30%
许可证 Apache-2.0
采用情况 用于 Google Cloud Run、GKE Sandbox
  • 优势：与标准容器相比，大幅减少宿主机内核攻击面；兼容 OCI；无需硬件虚拟化
  • 局限：系统调用拦截带来性能损耗；部分 Linux 系统调用尚未实现
  • 智能体相关性：可作为 Kubernetes 集群中容器化智能体工具的即插即用加固方案；用于 Cloud Run 上的智能体部署

Kata Containers

Kata Containers 使用硬件虚拟化（Intel VT-x、AMD SVM、ARM Hyp）将每个容器包裹在轻量级虚拟机中，将虚拟机级别的隔离与类容器的操作体验相结合。它实现了 containerd shimv2 API，对容器编排器透明。

属性 详情
层级 微虚拟机（容器封装）
隔离机制 基于 Hypervisor（支持 QEMU、Cloud Hypervisor、Firecracker 作为 VMM）
容器集成 containerd shimv2；兼容 OCI
多架构支持 x86_64、aarch64、ppc64le、s390x
许可证 Apache-2.0
  • 优势：虚拟机级别隔离，原生支持 Kubernetes 操作；支持 Firecracker 作为底层 VMM 以实现超快启动
  • 局限：需要硬件虚拟化支持；资源开销高于 gVisor
  • 智能体相关性：适用于以 Kubernetes 为编排层、需要强工作负载隔离的多租户智能体平台

nsjail（Google）

nsjail 是一款轻量级进程隔离工具，使用 Linux 命名空间、cgroup 和 seccomp-bpf。Google 基础设施使用它对任意进程进行沙箱化，并提供细粒度策略控制。

属性 详情
层级 操作系统级策略
隔离机制 Linux 命名空间（PID、网络、挂载、UTS、IPC）+ cgroups + seccomp-bpf
部署 仅限 Linux；二进制文件或基于 Docker
许可证 Apache-2.0
  • 优势：开销极低；系统调用策略粒度细；无需守护进程
  • 局限：仅限 Linux；需要熟悉 seccomp 策略编写；不如 srt 针对 MCP 有专项工具支持
  • 智能体相关性：适用于在 Linux 宿主机上对智能体调用的 Shell 脚本或 CLI 工具进行沙箱化，且不可接受容器开销的场景

方案对比总结

方案 类型 启动时间 隔离级别 智能体原生 操作系统支持 许可证
E2B 云 SaaS < 1 s（预热） 高（提供商托管） 是——以代码解释器为核心 云 Apache-2.0
Daytona 云 / 开源 < 90 ms 高（独立内核） 是——以智能体工作流为核心 云 Apache-2.0
Modal 云 SaaS < 1 s（预热） 中高（容器） 部分——以计算为核心 云 专有
LangSmith Sandboxes 云 SaaS（私有预览） 未公布 高（microVM） 是——不可信智能体代码与评测扩展 云 专有
AWS Lambda MicroVMs 云（托管） 冷启动额外约 100–200 ms 极高（Firecracker 微虚拟机） 部分——通用无服务器，AWS 原生智能体技术栈 云（AWS） 专有（托管服务）
Docker Sandboxes 本地（开发者机器） 快速（子虚拟机） 高（microVM） 是——本地 AI 编程智能体（Claude Code、Kiro、Gemini CLI 等） macOS、Windows 专有
Kubernetes Agent Sandbox 自托管（Kubernetes） < 1 ms（预热池） 可配置：低→极高 是——多租户 Kubernetes 智能体平台 任意 Kubernetes 集群 Apache-2.0
Anthropic srt 操作系统级 < 10 ms 中（基于策略） 是——以 MCP 服务器为核心 macOS、Linux Apache-2.0
Firecracker 微虚拟机 ~125 ms 极高（KVM） 否——基础设施原语 Linux（KVM） Apache-2.0
gVisor 容器（用户态内核） < 100 ms 高（系统调用拦截） 否——基础设施原语 Linux Apache-2.0
Kata Containers 微虚拟机 + 容器 ~200–500 ms 极高（Hypervisor） 否——基础设施原语 Linux Apache-2.0
nsjail 操作系统级 < 10 ms 中（命名空间 + seccomp） 否——通用型 Linux Apache-2.0
Docker（标准容器） 容器 < 100 ms 低中（命名空间） 否——通用型 Linux、macOS、Windows Apache-2.0

选型指南

需求 推荐方案
在开发机上对单个 MCP 服务器进程进行沙箱化 Anthropic srt（npm install -g @anthropic-ai/sandbox-runtime）
让 AI 编程智能体（Claude Code、Kiro、Gemini CLI）在本地无人值守运行 Docker Sandboxes（brew install docker/tap/sbx）——microVM 隔离，无需 Docker Desktop
以最简配置在云端执行 AI 生成代码 E2B（SDK 优先，云原生）
需要在多步骤之间保持持久状态的智能体工作流 Daytona（有状态快照，独立内核）
计算密集型智能体工具（GPU、ML 推理） Modal
需要按试验隔离状态、横向扩展智能体评测 LangSmith Sandboxes（每次试验全新沙箱，凭证走认证代理）
需要可配置隔离的多租户 Kubernetes 智能体平台 Kubernetes Agent Sandbox（WarmPool + gVisor 或 Kata 后端）
需要虚拟机级隔离的多租户 Kubernetes 智能体平台（非 Kubernetes） gVisor（即插即用）或 Kata Containers（更强隔离）
在自有 AWS 基础设施上大规模运行无服务器智能体 Firecracker 微虚拟机
在 AWS 上运行无服务器智能体且不想自行运维 Firecracker AWS Lambda（每次调用独享托管微虚拟机，支持可配置的自动暂停/恢复）
在 Linux 上以零开销对 CLI 工具/Shell 命令进行沙箱化 nsjail
快速原型验证；已在使用 Docker Docker 标准容器 + 资源限制（最低门槛；不适用于高信任场景）

最佳实践

挑战 描述 解决方案
选择隔离层级 威胁模型与沙箱强度不匹配 按代码信任级别映射隔离层级：开发工具 → 操作系统级；不可信用户代码 → 微虚拟机或云托管
沙箱通过网络逃逸 沙箱内进程回连外部或外泄数据 在每个层级都应用白名单网络策略；使用基于代理的过滤（srt、Daytona）
智能体循环中的冷启动延迟 每次工具调用都启动新沙箱会增加数百毫秒 使用预热沙箱池（E2B、Daytona）或快照/恢复（Firecracker）来分摊启动成本
跨智能体步骤的状态持久化 智能体需要在第 1 步写入文件并在第 2 步读取 使用有状态沙箱会话（Daytona 快照、E2B 持久文件系统），而非无状态的每次调用沙箱
可观测性缺口 沙箱违规与资源使用情况在智能体链路追踪中不可见 将沙箱违规日志和资源指标与智能体链路追踪一同接入可观测性平台
资源耗尽（CPU/RAM） 失控的沙箱进程消耗宿主机资源 在沙箱层设置硬性 cgroup 限制（CPU、内存、磁盘 I/O）；云托管服务会自动处理
凭证泄漏至沙箱 注入沙箱环境变量中的密钥可能被外泄 绝不注入长期凭证；使用基于 IAM 角色的短期令牌；限制沙箱出站网络以防外泄
过度信任容器 标准 Docker 容器共享宿主机内核，内核漏洞会破坏隔离 对不可信代码升级使用 gVisor 或 Kata Containers；仅对完全可信的内部工具保留普通 Docker

与其他安全控制的关系

沙箱隔离解决的是执行隔离问题——约束运行中进程的能力。它是纵深防御体系中的一个层次，无法替代以下控制手段：

  • 输入过滤——在代码进入沙箱之前进行提示词注入防御
  • 输出过滤——在将工具响应返回给智能体之前，筛查其中的个人隐私信息或外泄内容
  • 身份认证与最小权限访问——无论沙箱如何配置，智能体凭证都应有范围限制
  • 策略引擎——在操作系统层之上执行的确定性预执行策略检查（如 Microsoft AGT）
  • 审计日志——每次沙箱调用都应与智能体链路追踪一同记录

参见

参考资料