判断

如果你要让 LLM 真正去执行代码，而不是只吐文本，迟早需要一个隔离环境——否则就是让模型直接在你机器上乱跑。Kubernetes 官方 SIG Apps 给出的答案是 Agent Sandbox：一套声明式的 Sandbox CRD 加控制器，专门管「有状态、单例、隔离」的工作负载。

一、它是做什么的

Agent Sandbox 在 Kubernetes 上定义了一个 Sandbox 自定义资源（CRD） 和对应的控制器。它的定位是「沙箱编排器（sandbox orchestrator）」：本身不造隔离技术，而是把底层强隔离交给 gVisor、Kata Containers 这类「Sandbox Runtime」，通过 RuntimeClass 调度带对应运行时的 Pod。

每个 Sandbox 都有稳定主机名和网络身份、可持久化存储、可被暂停 / 恢复 / 定时销毁的生命周期。官方点名的场景有四个：开发环境、AI Agent 运行时（跑不可信的模型生成代码）、强化学习 / 评测（SWE-bench、R2E-Gym 这类高吞吐隔离执行）、以及笔记本 / 单实例服务。

二、怎么用

前提是你已经有一个 Kubernetes 集群。安装就是一条 kubectl：

kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/latest/download/sandbox-with-extensions.yaml

也可以把版本钉死（生产 / GitOps 推荐）：

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

验证是否装好：

kubectl get crd sandboxes.agents.x-k8s.io
kubectl get deploy agent-sandbox-controller -n agent-sandbox-system

起一个最简单的沙箱，写一个 Sandbox 资源：

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

程序里也能直接调：Go 用 go get sigs.k8s.io/agent-sandbox/clients/go/sandbox@latest，Python 用 pip install k8s-agent-sandbox。需要给 SDK 或外部客户端做流量转发时，再可选装 Sandbox Router 这个反向代理。

三、优点和缺点

优点：

  • 出身正：Kubernetes SIG Apps 官方项目，Apache-2.0，没有商业许可陷阱，也不是「开源但核心闭源」。
  • 声明式、标准化：和 K8s 原生 YAML / GitOps 一致；SandboxTemplate 做模板，SandboxClaim 加 SandboxWarmPool 做预热池，领沙箱像领号一样快。
  • 隔离可插拔：强隔离程度取决于你选的 RuntimeClass（gVisor / Kata），按需取舍性能与安全。
  • 生命周期完整：创建、暂停、恢复、定时销毁，比自己用 StatefulSet 拼一套省心。

缺点与坑（都来自真实 issue，非凭空）：

  • 隔离不是默认就强。README 明确说它只是编排器，底层强隔离靠你配好 gVisor / Kata；用普通 RuntimeClass 时，隔离级别和裸 Pod 没区别。
  • 单例模型：一个 Sandbox 只跑一个工作负载。Agent 要并发，就得开 N 个沙箱——成本与规模跟着 K8s 走。
  • 还年轻、API 在动：当前是 v1beta1，v1.0.0 已移除 v1alpha1，老 YAML 直接不兼容。
  • 真实 bug：Sandbox 名字超过 63 字符又带了 spec.service，控制器会永久卡死并空转（issue #1629）；本地隧道模式下 kubectl port-forward 会无视你指定的集群上下文、改用环境里的 kubeconfig（issue #1531）；异步客户端退出清理会泄漏临时证书 / 密钥文件（issue #1515）。
  • 示例有云厂商绑定：latebind-storage 示例只在 GKE 上能跑，换集群要自己改（issue #1607）。
  • 贡献门槛：需签 Kubernetes CLA，且项目 30 天自动 stale、15 天自动关 PR，外来补丁容易被清掉。

四、最终能达到什么效果

装上之后，你能用一套标准 K8s 资源，给每个 AI Agent（或每个评测任务）分配一台「带稳定身份、能持久化、可随时销毁」的隔离容器，强隔离靠配置 gVisor / Kata 打开。对做 Agent 平台、跑 SWE-bench 这类评测、或给开发同学发临时云环境的人来说，它把「隔离沙箱」这件麻烦事收口成了一个 CRD。

适合谁 / 不适合谁

适合：已经在用 Kubernetes、需要规模化跑不可信代码或评测 loop 的团队。

不适合：只想在本机给 Agent 一个隔离壳的个人开发者——你更需要 #132 讲过的 ArcBox 这类单机运行时，而不是先起一套 K8s。

动手前先想清三件事：① 你有没有现成 K8s 集群；② 强隔离要不要上 gVisor / Kata，上了性能怎么算；③ 并发规模靠「开多个 Sandbox」撑，成本模型先估。

下期预告：Agent 沙箱三条路线横评——本机微虚机（ArcBox）/ K8s 原生（Agent Sandbox）/ 云厂商容器沙箱（腾讯云 CubeSandbox），讲清各自隔离强度、起步成本与适用边界。

数据来源：项目仓库 README、LICENSE 与公开 issue（#1629 / #1531 / #1515 / #1607）；本篇不引用 star 数与下载量。