Kubernetes 官方出手了：Agent Sandbox 让你在 K8s 上安全运行 AI Agent，30 种场景全覆盖

如果你在做 AI Agent 相关的项目，你一定会遇到一个问题：

Agent 要执行代码，要在沙箱里跑，怎么管？

自己用 Docker 跑？不够安全。Agent 生成的代码是不可信的，容器逃逸怎么办？ 自己搭 gVisor？太复杂了，运维成本高得吓人。 用 E2B、Daytona 这些 SaaS？又贵又不灵活，数据还不在自己手里。

现在，Kubernetes 官方终于出手了。

Agent Sandbox，Kubernetes SIG Apps 下的官方项目，专门为在 K8s 上安全运行 AI Agent 而设计的沙箱编排器。

GitHub 地址：https://github.com/kubernetes-sigs/agent-sandbox 文档站：https://agent-sandbox.sigs.k8s.io

这不是某个公司的商业产品，这是 Kubernetes 社区的官方项目。 这意味着它的设计是 vendor-neutral 的，不绑定任何云厂商，不绑定任何运行时。 你可以用 gVisor，可以用 Kata Containers，可以用 Firecracker，想用什么用什么。

而且它已经非常成熟了，有 30 种完整的实战示例，覆盖了几乎所有你能想到的场景。

今天这篇文章，我就把它从里到外讲清楚：它是什么，怎么装，怎么用，有哪些高级特性，以及什么时候该用它。

---

它到底是什么？一句话说清楚

Agent Sandbox 是一个 Kubernetes CRD 和控制器，让你可以用声明式的方式，管理隔离的、有状态的、单例的沙箱工作负载。

什么意思？拆开来看：

• CRD（自定义资源定义）：它给 Kubernetes 加了一个新的资源类型叫 Sandbox，你像写 Deployment YAML 一样写 Sandbox YAML
• 隔离的：每个沙箱都跑在安全运行时里面（gVisor 或 Kata），和宿主机之间有内核级隔离
• 有状态的：沙箱里的数据可以持久化，重启不丢
• 单例的：每个沙箱就是一个独立的、有稳定身份的 Pod，不是 Deployment 那种无状态副本

这四个特点合在一起，就完美解决了 AI Agent 运行时的核心需求。

---

为什么不用 Deployment 或 StatefulSet？

很多人会问：K8s 已经有 Deployment 和 StatefulSet 了，为什么还要搞一个新的 CRD？

因为它们都不太合适。

Deployment 的问题

Deployment 是为无状态、可水平扩展的应用设计的。 但是 Agent 沙箱是有状态的，每个沙箱都是独立的，不能随意重启和替换。 而且 Deployment 没有休眠、恢复这些沙箱需要的高级生命周期管理。

StatefulSet 的问题

StatefulSet 虽然有状态，但它是为「有序的、编号的副本集」设计的。 一个 Agent 沙箱就一个实例，不需要编号，不需要有序。 而且用 StatefulSet 管理单个 Pod，需要同时维护 StatefulSet + Service + PVC 三件套，非常麻烦。 还缺少休眠、恢复、定时删除这些沙箱特有的生命周期管理能力。

Agent Sandbox 的优势

Agent Sandbox 就是为这个场景量身定做的：

• 一个 YAML 搞定，不需要 Service + PVC 三件套
• 内置休眠和恢复（Deep Hibernation）
• 内置定时删除
• 内置预热池（WarmPool），秒级分配新沙箱
• 内置模板系统，批量管理大量相似沙箱

简单说就是：它把 StatefulSet + Service + PVC + 一堆自定义逻辑，打包成了一个简洁的、专为沙箱场景优化的 API。

---

怎么装？真的非常简单

标准安装（推荐）

一行命令，装核心 + 扩展：

# 替换成具体版本号，比如 v0.1.0
export VERSION="v0.1.0"

kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/${VERSION}/sandbox-with-extensions.yaml

完了。 不需要 Helm，不需要 Operator Lifecycle Manager，不需要任何额外依赖。

选择性安装

如果你只想要核心功能：

kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/${VERSION}/sandbox.yaml

如果你还想要扩展功能（模板、预热池等）：

kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/${VERSION}/extensions.yaml

Go SDK 和 Python SDK

如果你需要用代码来管理沙箱：

# Go SDK
go get sigs.k8s.io/agent-sandbox/clients/go/sandbox@latest

# Python SDK
pip install agentic-sandbox-client

---

怎么用？从最简单的开始

创建一个基础沙箱

apiVersion: agents.x-k8s.io/v1beta1
kind: Sandbox
metadata:
  name: my-sandbox
spec:
  podTemplate:
    spec:
      containers:
      - name: my-container
        image: python:3.12

apply 一下，一个有稳定身份、有持久存储的沙箱就创建好了。 你可以通过 my-sandbox 这个 hostname 来访问它。

使用安全运行时（重要！）

如果你要运行不可信代码（比如 AI Agent 生成的代码），一定要用安全运行时：

apiVersion: agents.x-k8s.io/v1beta1
kind: Sandbox
metadata:
  name: secure-sandbox
spec:
  podTemplate:
    spec:
      runtimeClassName: gvisor  # 或者 kata-containers
      containers:
      - name: agent-runtime
        image: my-agent-image

加一个 runtimeClassName 就行了。

• gVisor：用户态内核，轻量级，性能损耗小，适合大多数场景
• Kata Containers：硬件虚拟化隔离（基于 KVM），最强隔离，适合最高安全要求
• Firecracker：微 VM，AWS 开源的，启动极快，适合高密度场景

使用预热池（秒级分配）

如果你的 Agent 需要快速创建大量沙箱，预热池是必备的：

apiVersion: agents.x-k8s.io/v1beta1
kind: SandboxWarmPool
metadata:
  name: my-pool
spec:
  templateRef:
    name: my-template  # 引用一个 SandboxTemplate
  minSize: 5           # 至少保持 5 个预热好的沙箱
  maxSize: 20          # 最多 20 个

然后用户通过 SandboxClaim 来申请沙箱：

apiVersion: agents.x-k8s.io/v1beta1
kind: SandboxClaim
metadata:
  name: user-alice-sandbox
spec:
  poolRef:
    name: my-pool

申请到的沙箱是已经预热好的，秒级分配，不需要等容器启动。 这在多用户、高并发的 Agent 平台场景下，体验非常好。

---

30 种实战场景，几乎覆盖所有需求

这是这个项目最让我印象深刻的地方。 它不是只有一个 Hello World 示例就完了。 它有 30 种完整的、可运行的实战示例，覆盖了几乎所有你能想到的沙箱使用场景。

开发环境类

示例	说明
vscode-sandbox	在沙箱里跑 VSCode，远程开发
jupyterlab	在沙箱里跑 JupyterLab，数据分析
windows-sandbox	通过 KVM/QEMU 在沙箱里跑 Windows

浏览器自动化类

示例	说明
chrome-sandbox	在沙箱里跑 Chrome 浏览器
playwright-sandbox	用 Playwright 做网页抓取和截图
gemini-cu-sandbox	给 Gemini Computer Use Agent 用的 Python 运行时

AI Agent 运行时类

示例	说明
hermes-agent	跑 Hermes Agent，带持久化和自定义技能
hermes-agents-as-a-service	多用户 Agent 即服务平台模式
langchain	用 LangGraph 的编码 Agent
code-interpreter-agent-on-adk	把沙箱作为 Agent Development Kit 的工具
nullclaw-sandbox	最小化 AI 助手运行时

安全隔离类

示例	说明
openclaw-gvisor-sandbox	gVisor 隔离的生产级沙箱
openclaw-kata-aks-sandbox	Kata Containers 在 AKS 上的硬件隔离
kata-gke-sandbox	Kata Containers 在 GKE 上
firecracker-sandbox	Firecracker 微 VM
composing-sandbox-nw-policies	组合网络策略

运维和扩展类

示例	说明
hpa-swp-scaling	用 HPA 自动扩缩预热池
keda-scale-to-zero	用 KEDA 缩到零再扩回来
gke-swap	GKE 节点内存 swap，Chrome 密度从 120 提到 200
apf-insulation	API 优先级和公平性隔离
manual-pdb	PodDisruptionBudget 配置

其他

示例	说明
mcp-server-sandbox	在沙箱里跑 MCP 服务器
python-runtime-sandbox	Python 运行时沙箱
containarium-ssh-sandbox	通过 SSH 访问的沙箱
agent-sandbox-rl	多集群批量 RL/Eval 编排
aio-sandbox	All-in-One 沙箱
sandbox-ksa	带服务账号的沙箱
policy	不同策略的沙箱

这 30 个示例，每一个都有完整的 YAML 配置和使用说明，直接 clone 下来就能跑。 对于想快速上手的人来说，这简直是宝藏。

---

它的架构设计，非常干净

Agent Sandbox 的架构遵循标准的 Kubernetes 控制器模式：

用户 → Sandbox CR → 控制器 → Pod → 安全运行时（gVisor/Kata）
                ↑
扩展层：SandboxTemplate → SandboxWarmPool → SandboxClaim

核心就是 Sandbox CRD，负责管理单个沙箱的生命周期。 扩展层提供了三个额外的 CRD：

1. SandboxTemplate：定义可复用的沙箱模板，批量管理大量相似沙箱
2. SandboxWarmPool：管理预热好的沙箱池，秒级分配
3. SandboxClaim：用户从预热池中申请沙箱，屏蔽底层配置细节

这个分层设计非常干净：

• 你只需要基础功能？只用核心的 Sandbox CRD 就行
• 你需要批量管理？加上 SandboxTemplate
• 你需要快速分配？加上 SandboxWarmPool 和 SandboxClaim

每个层次都是可选的，按需使用，不会强制你用不需要的东西。

---

跟其他方案比，优势在哪里？

方案	隔离级别	成本	灵活性	运维复杂度	适合场景
纯 Docker	低（共享内核）	低	高	低	开发测试，可信代码
E2B / Daytona SaaS	高	高（按次付费）	低	极低	小团队，不想运维
自建 gVisor	高	中	高	极高	有专职运维的大团队
Agent Sandbox	高（可选运行时）	低（自有 K8s）	高	低（声明式管理）	已有 K8s 的团队

Agent Sandbox 最大的优势是：

1. 你不被任何厂商绑定，用 gVisor 还是 Kata 自己选
2. 你的数据完全在自己手里，不经过任何第三方
3. 运维复杂度极低，一个 YAML 搞定
4. 和现有 K8s 生态无缝集成，监控、日志、网络策略全部复用

如果你已经有 K8s 集群了，这几乎是不二之选。

---

什么时候该用它？

该用的场景

• 你在做 AI Agent 平台，需要给每个用户提供隔离的代码执行环境
• 你在做代码沙箱服务，需要安全地运行用户提交的代码
• 你在跑 AI Agent 的 RL 训练，需要大量并行的隔离环境
• 你在做多租户的 JupyterLab / VSCode 远程开发平台
• 你需要安全地运行浏览器自动化（Chrome、Playwright）

不该用的场景

• 你没有 K8s 集群，而且不打算搭
• 你的沙箱需求非常少（就一两个），直接用 Docker 就够了
• 你需要的是无状态的服务部署，那直接用 Deployment

---

写在最后

Agent Sandbox 的出现，填补了 K8s 生态在 AI Agent 沙箱管理这个领域的一个空白。

以前你要想在 K8s 上安全地运行 AI Agent，需要自己把 StatefulSet + Service + PVC + 安全运行时 + 生命周期管理全部拼起来，工程量巨大。

现在，一个 CRD，一个 YAML，全部搞定。

而且它是 Kubernetes 官方项目，背后有整个社区的支持，不用担心维护者跑路的问题。 30 种实战示例，覆盖了几乎所有场景，拿来就能用。

如果你在做 AI Agent 相关的基础设施，这个项目绝对值得你花时间研究。

---

作者: itech001 来源: 公众号：AI人工智能时代 网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。

本文首发于 AI人工智能时代，转载请注明出处。