Kubernetes SIG Apps 官方子项目 agent-sandbox 提供一组 CRD 与控制器，用于管理「隔离、有状态、单例」的工作负载，首批面向场景是 AI Agent 运行时与强化学习训练。项目采用沙箱编排器架构：自身不做容器隔离，而是通过 RuntimeClass 把 Pod 委托给 gVisor、Kata Containers 等安全运行时执行。仓库当前 3.6k stars、466 forks，最新版本 v0.5.6（2026-08-20 发布），采用 Apache-2.0 协议。
为什么需要新的工作负载抽象
Kubernetes 现有两类工作负载抽象覆盖不了「单例有状态」场景。Deployment 面向无状态、可复制的应用，副本之间互相替代；StatefulSet 提供编号稳定的 Pod 组，但配套 Service、PVC 的编排成本不低。AI Agent 运行时、强化学习评估循环这类负载，需要的是「长期运行、有稳定身份、带持久存储、同一时刻只有一个」的容器——README 称之为「基于 Kubernetes 原语的轻量单容器 VM 体验」。
项目最初定义的适用场景：
- AI Agent 运行时：执行不可信、由 LLM 生成的代码，需要强隔离；
- 强化学习训练与评估：SWE-bench、R2E-Gym、Ray/RLlib 等高频吞吐场景，需要低延迟沙箱认领；
- 云端开发环境：隔离、持久、可网络访问；
- Jupyter 笔记本等单容器科研会话；
- 单实例有状态服务（构建代理、小型数据库）：需要稳定身份但不想背 StatefulSet 的编排负担。
Sandbox：单例 Pod 的核心抽象
核心 CRD 名为 Sandbox（API 版本 agents.x-k8s.io/v1beta1），声明式描述一个「有状态单例 Pod」，三个关键特性：
- 稳定身份：每个 Sandbox 拥有固定主机名与网络身份，重启不换；
- 持久存储：可挂载重启后依然保留的存储；
- 生命周期管理：控制器负责 Pod 创建、定时删除、暂停与恢复。
隔离层由底层 Sandbox Runtime 保证：控制器编排使用指定 RuntimeClass 的 Pod，把低层容器隔离委托给 gVisor、Kata Containers 这类安全运行时，实现内核与网络隔离。这也是它被称为「沙箱编排器」而不是「沙箱运行时」的原因。
三个扩展：模板、认领与预热池
extensions 模块在核心之上提供三个配套 CRD：
- SandboxTemplate：定义可复用的 Sandbox 模板，便于批量管理大量同类 Sandbox；
- SandboxClaim：用户通过 Claim 从模板或预热池申请 Sandbox，屏蔽底层配置细节；
- SandboxWarmPool：维护一批预热的 Sandbox，用户认领时直接分配，缩短新沙箱启动等待。
预热池正是为强化学习这类高频认领场景设计的：训练循环反复申请、释放沙箱，池化可以显著降低每次冷启动延迟。
安装与 SDK
安装支持单文件与拆分两种方式：标准安装使用 sandbox-with-extensions.yaml（核心与扩展打包在同一个资源文件），也可分别应用 sandbox.yaml 与 extensions.yaml；Helm chart 与 OLM bundle 同步提供。项目还维护 Go SDK（sigs.k8s.io/agent-sandbox/clients/go/sandbox）与 Python SDK，支持程序化创建与管理沙箱。
当前进展与方向
仓库现有 889 个提交、135 位贡献者、19 个 release。近期提交重点包括：SandboxClaim 暴露绑定沙箱的 serviceFQDN、sandbox-router 用浏览器会话 cookie 驱动 tokenreview 鉴权、RL 场景的沙箱回收（reset-and-reuse）与预热池覆盖。README 列出的后续方向包括深度休眠（保存状态并归档对象）、断网自动恢复、弹性存储、跨沙箱内存共享与双身份路由，均保持运行时无关（vendor-neutral），具体能力的选择交给底层运行时。
agent-sandbox 把「隔离的有状态单例容器」做成了 Kubernetes 的一等公民，AI Agent 与 RL 工作负载从此有了官方口径的声明式管理入口。