跳转至

Kubernetes Agent Sandbox

概述

Agent Sandbox 是一项 Kubernetes 原生标准，由 Google 在其开源博客中提出（2025 年 11 月），并在 KubeCon Atlanta（2025 年 11 月）作为 Kubernetes SIG Apps 的正式子项目发布，用于安全、规模化地运行自主 AI 智能体工作负载。其动因在于：Kubernetes 是为无状态微服务设计的，而智能体式工作负载是有状态、长时运行的，行为方式根本不同——它们会进行迭代式的快速工具调用（读取文件、做一次计算、查询 API），出于安全考虑，每一次这样的调用都更适合拥有自己独立的执行沙箱，而非共用一个长生命周期的 Pod。Agent Sandbox 引入了基于控制器的 Sandbox API，作为这类模式的标准化方案，取代各种临时变通做法（例如挪用 Job 或长生命周期 Pod）。

命名说明：这个 Google/Kubernetes SIG Apps 倡议与独立社区项目 KAOS (K8s Agent Orchestration System) 是不同的两者，尽管都处理 Kubernetes 原生的智能体执行。Google 的博文并未使用"KAOS"这一名称；它介绍的是下文所述的"Agent Sandbox" / "Sandbox" API 家族。

核心概念 / 架构

推动此提案的生态变迁：智能体系统正从短时任务转向多个协同智能体——它们持续运行、维护上下文、使用外部工具、编写并执行代码，并在较长时间内相互通信——这些需求（持久化记忆、复杂的智能体间通信、动态资源分配）是普通 Kubernetes Pod 原生无法满足的。

核心 API 资源：

资源 用途
Sandbox 核心资源，定义一个智能体沙箱工作负载——面向单容器、有状态、单例工作负载的、持久且隔离的智能体环境实例
SandboxTemplate 定义某类沙箱原型的安全蓝图：资源限制、基础镜像与初始安全策略
SandboxClaim 一种事务型资源，允许用户或上层智能体框架（如 Google ADK、LangChain）请求一个执行环境，并将供给逻辑抽象隐藏

性能特性——WarmPools：一项扩展，维护一池预热好的 pod，使 Sandbox Controller 能在 claim 时直接分发就绪实例，把冷启动延迟降到一秒以内。

核心 CRD API 参考

官方 kubernetes-sigs/agent-sandbox 版本（截至 2026 年 4 月）暴露以下 CRD：

CRD 用途
Sandbox 单个有状态 Pod 的声明式 API，提供稳定主机名和可选持久化存储
SandboxTemplate 将运行时配置固化为可复用模板，以保持沙箱供给的一致性
SandboxClaim 面向用户的抽象，根据模板创建沙箱而不暴露底层细节
SandboxWarmPool 预热 Pod 池，实现近乎即时的沙箱分配（相较冷 Pod 调度的亚毫秒级分配）

核心特性

  • 通过熟悉的 Kubernetes 构件（控制器、CRD）管理，而非另起一套定制的智能体运行时
  • 设计上让上层智能体框架可经 SandboxClaim 以声明式方式请求执行环境，使智能体框架代码与沙箱供给细节解耦
  • 针对的安全要求是：单次工具调用/代码执行应在隔离环境中运行，而非共用一个长生命周期进程
  • 稳定身份与持久化存储：每个 Sandbox 都有稳定主机名，可由重启后仍保留状态的 PVC 支撑，让智能体跨会话重连而无需应用层协调
  • 休眠与恢复：控制器可暂停沙箱以释放计算资源，并在收到网络连接时自动恢复；睡眠期间保留状态，适合突发型工作负载
  • 定时删除：控制器按 TTL 自动清理，无需手动管理沙箱生命周期
  • 运行时无关的隔离：可插拔后端包括标准容器、gVisor（内核级）和 Kata Containers（虚拟机级），在部署时选择而非写死在 API 中

客户端 SDK

Agent Sandbox 提供用于程序化管理沙箱的一等客户端库：

SDK 语言 能力
Python Client Python 创建、查询和管理沙箱；文件系统读写 / 传输；面向 Python 智能体运行时
Go Client Go 相同 API 范围；面向 Go 服务、控制器和平台工具

两个 SDK 都暴露 Filesystem 操作（读、写、列出以及向沙箱传入 / 传出文件）和用于挂载持久化存储的 Volume 附加能力。

应用场景

项目文档列出了以下典型部署模式：

模式 生命周期 说明
代码执行 短期 在完全隔离的沙箱中运行不可信的 LLM 生成代码，适合代码解释器、分析工具和按需计算
编程智能体 中期 智能体在安全沙箱中使用完整开发工具自主编写、调试和重构代码
计算机操控 中期 AI 智能体在隔离沙箱中操作图形桌面、浏览器和 GUI 应用
CI/CD 集成 短期至中期 在 CI/CD 流水线中执行隔离测试、验证与自动化工作流
常驻智能体环境（OpenClaw） 长期 在 Agent Sandbox 中持久运行 OpenClaw 环境
gVisor 隔离 任意 使用 gVisor 用户态内核加固沙箱，拦截系统调用以保护宿主机
Kata Containers 隔离 任意 通过 Kata Containers + QEMU 为每个沙箱提供独立内核的硬件虚拟化

治理与现状

  • Kubernetes SIG Apps 的正式子项目
  • 于 2025 年 11 月 KubeCon Atlanta 正式发布
  • 代码与文档：GitHub 上的 kubernetes-sigs/agent-sandbox；项目站点 agent-sandbox.sigs.k8s.io
  • GKE Agent Sandbox 已正式发布（GA） (更新说明：此前仅描述为 KubeCon Atlanta 发布；根据 Google Cloud 博客的 GA 公告，GKE Agent Sandbox 现已正式上线)

GKE 产品化：GA 与 Agent Substrate

Google Cloud 针对 Agent Sandbox 标准的 GKE 专属产品化已达到 GA，并给出了若干具体的性能与成本数据：

能力 详情
Pod Snapshots 集成 将空闲的智能体工作负载挂起，并在数秒内恢复——专为智能体工作负载"短暂高爆发、随后较长空闲"的典型模式而设计，避免为空闲智能体浪费算力
沙箱供给延迟 Agent Sandbox API 内置的热池（warm pool）可达每集群每秒供给 300 个沙箱，90% 的分配请求在 200 毫秒内完成
冷池成本效益 待机容量缓冲（挂起的 VM）以远低于保持热池常驻的成本为热池补充容量
安全性 原生支持 gVisor 并默认启用 Kubernetes 网络拒绝策略，容器运行时接口可插拔（支持 Kata Containers）
性价比 在 Axion 处理器上相较同类超大规模云厂商方案最高提升 30% 的性价比
采用情况 自预览版公告发布以来不到 5 个月，GKE 上的沙箱数量增长 16 倍

Agent Substrate（全新独立开源项目）

Agent Substrate 是 Google 独立发布的开源项目——并非 Agent Sandbox 的更名或合并版本——面向超大规模智能体集群的性能与密度需求：

  • 在 Agent Sandbox 核心安全运行时与快照能力的基础上，搭配一套极简控制平面，旨在绕过部分 Kubernetes 控制平面瓶颈，同时不重新发明 Kubernetes 的其余能力
  • 标准 Kubernetes 针对数千个长期运行的服务进行了优化；Agent Substrate 则专为应对数百万次亚秒级工具调用的高频交互而设计——这种量级的流量会压垮标准控制平面
  • 定位为智能体、智能体运行框架（harness）及智能体运行时的基础底座——包括新发布的"Agent Executor"项目
  • 当前的一个重要优化方向：将数据本地性纳入调度器核心，使智能体状态与调度决策协同部署，从而降低开销

参见

参考资料