kubernetes-sigs/agent-sandbox

如果你已经在用 Kubernetes，并且需要给每个智能体或训练任务一个可重复创建、有固定地址、重启后数据还在的容器，agent-sandbox 值得看一眼。如果你想找的是现成的智能体编排器或开箱即用的隔离产品，它不是。

解决什么问题

以前，团队想让每个 AI 智能体或 RL worker 拥有独立环境：固定主机名、重启后仍在、存储不随 Pod 消失。Deployment 面向无状态副本，StatefulSet 的序号身份模型也不适合“长期运行的单例”。于是大家只能自己写控制器，或在裸 Pod 外面包一层胶水。现在，一个 Sandbox 资源就能声明式描述这个有状态 Pod，由控制器负责调和。最终得到的是稳定主机名和可选持久化存储，而且都通过团队本来就在用的 Kubernetes API 管理。

有什么不同

核心是一个只针对单例有状态工作负载的 CRD，而不是副本集或按序号管理的集合。README 把它定位为用 Kubernetes 原语搭出的、类似轻量单容器虚拟机的体验，具备稳定网络身份和重启后仍存在的存储。这个抽象比通用工作负载控制器窄，而窄正是它的价值：它和“每个智能体会话一个沙箱”能直接对应。

扩展层补上了复用和池化。SandboxTemplate 用来定义大量相似沙箱的模板；SandboxWarmPool 配合 SandboxClaim，让调用方从预热池里申请沙箱而不必关心底层配置，并且 Claim 的名称和 UID 会作为 Pod 元数据暴露给外部服务。代价是 API 面积变大：采用扩展意味着要理解几种互相作用的资源类型，核心与扩展分开安装也要求你先决定装哪个组合。隔离本身不是这个项目创造的；发布讨论中一位评论者指出，RuntimeClass 早已能提供 gVisor/Kata Pod，他认为有意思的是让这类工作负载变得容易部署（评论，2026-07-31）。这个说法是合理的：控制器统一了生命周期和身份，隔离强度仍取决于你配置的运行时。

谁值得试

适合：运行 Kubernetes 的平台团队，已经或计划接入 gVisor、Kata 之类的隔离运行时，并且需要大量生命周期短但有状态、名字和存储可预期的智能体环境。智能体会话启动频繁、冷启动延迟敏感时，池化扩展最有用。

不适合：只想在本机跑一个智能体的个人开发者，或者没有集群可以安装 CRD 的人。如果你期待项目顺便提供沙箱运行时、模型服务或智能体逻辑，也不合适；README 描述的是 API 和控制器，不是这些组件。那位评论者真正的痛点是快速、可交互地验证不可信代码，持久沙箱比批量 CI 更适合承载这种循环，但项目本身并不提供验证服务。

使用条件与边界

你需要一个现成的 Kubernetes 集群，以及安装集群级 CRD 和控制器的权限。安装就是应用清单，可以选择核心加扩展的合并包，也可以分开装组件，Helm 也有文档说明（快速开始、项目说明）。文档建议生产环境和 GitOps 固定版本号，而不是用 latest。

卸载路径要在开始前就想清楚：删除这些 CRD 会级联删除所有命名空间下对应类型的自定义资源，所以 README 要求先盘点沙箱、Claim、池和模板（项目说明）。长期维护意味着跟踪控制器版本和你选择的运行时类；安全模型另有文档，隔离保证取决于该运行时，而不只取决于 CRD 本身（威胁模型）。

HotRepo 点评

HotRepo 只有 2026-10-28 这一天的新项目榜观察记录：当时 4,429 星，当天增加 19 星。只有单个日期，无法判断关注度是否持续；仓库本身创建于 2025-08-12。投入之前，可以先看路线图和安全威胁模型，确认计划范围和隔离模型符合你运行不可信智能体代码的方式。