在K8s上跑AI Agent？Kubernetes社区搞了个Agent Sandbox，这事终于有正经解法了

前两天升级集群的时候顺手刷了一下Kubernetes官方博客，突然看到一篇标题让我愣了一下——Running Agents on Kubernetes with Agent Sandbox。点进去一看，好家伙，K8s社区居然正儿八经地搞了一个SIG级别的项目，专门解决"怎么在集群里跑AI Agent"这个问题。

说实话这个时间点出这个东西一点都不意外。你想啊，现在AI Agent已经不是实验室里的玩具了。Claude Code跑起来动不动几个小时甚至几天不停，中间还要执行代码、读写文件、调用各种工具链。OpenClaw那个开源项目两周就拿了10万star，现在更是涨到了36万。这些Agent工作负载你用传统的Deployment去跑？副本数设1？不合适。StatefulSet？也不太对味。

我之前就在这个问题上踩过坑，所以看到有官方项目来解决它，还挺激动的。

先说清楚问题出在哪

去年底我在集群里跑过一个内部的代码审查Agent，用的LangChain框架对接Claude。当时的部署方案是经典的土法炼钢：一个StatefulSet副本数设成1，挂一个PVC用来存Agent的上下文状态和代码仓库缓存，前面放个headless Service给它一个稳定的DNS名。旁边再搞个CronJob定时清理过期的session目录。

能跑吗？能跑。但问题一堆一堆的。

第一个头疼的事情是生命周期管理。这Agent空闲的时候也在那占着2C4G的资源，啥也不干就是不能杀。因为它的内存里存着对话上下文和一些中间推理状态，杀了就丢了。你想暂停它？Kubernetes原生不支持Pod暂停。要么自己写个控制器去scale到0然后dump状态到PVC再重新加载，那个恢复时间搞不好比冷启动还慢。要么就这么耗着，一个月下来单这个Agent的机器成本就够喝一壶了。

第二个问题更让人头大——安全隔离。Agent要执行的代码是LLM生成的，你信不信得过它？上周还有人在社区里分享了一个案例，某Coding Agent在修复bug的过程中执行了rm -rf /tmp，结果把同节点其他Pod的临时文件全删了。标准容器的namespace隔离是用的同一个宿主机内核，一个内核漏洞被利用了，整个节点上的容器都得遭殃。我们之前是给这类Pod单独配了gVisor的RuntimeClass做加固，但配置起来一坨yaml，跟主应用的部署逻辑混在一起，维护成本很高。

第三个是冷启动延迟。我们后来为了省成本，搞了个定时扩缩，空闲时把Agent给scale down。结果用户反馈说每次发起审查请求都得等半分钟——等Pod调度、等镜像pull、等Agent加载模型上下文。对于交互式的Agent场景，这个延迟根本不能接受。后来没办法又改回always-on，成本优化白搞。

本质上这些问题都指向一件事：AI Agent这种工作负载，它既不是无状态的微服务，也不是传统有序编号的有状态应用，更不是跑完就走的批处理Job。它是一种全新的负载模式，但Kubernetes原生没有给它准备好合适的原语。

所以当我看到Agent Sandbox的设计文档时，反应就是——终于有人把这些散装的workaround给统一成一个正经的声明式API了。

Agent Sandbox到底是个啥

简单说，它是Kubernetes SIG Apps下面的一个开源项目（github.com/kubernetes-sigs/agent-sandbox），提供了一组CRD和一个控制器，专门用来管理"隔离的、有状态的、单实例的工作负载"。官方给它的定位是：一个Kubernetes原生的平台，提供轻量级的、单容器VM体验，但构建在标准K8s原语之上。

核心资源就是一个Sandbox CRD。一个最简单的Sandbox长这样：

apiVersion: agents.x-k8s.io/v1alpha1
kind: Sandbox
metadata:
  name: my-agent
spec:
  podTemplate:
    spec:
      containers:
      - name: agent-runtime
        image: my-agent-runtime:latest

创建之后，你的Agent就有了一个稳定的hostname my-agent，有可选的持久存储，有完整的生命周期管理（创建、定时删除、暂停、恢复）。控制器帮你搞定底下的Pod创建、存储绑定、DNS注册这些脏活累活。

但精髓不在这个核心CRD，而是它搭配的三个扩展资源：

SandboxTemplate —— 复用模板。平台团队定义好一套标准的Agent运行环境配置（用什么Runtime、分配多少资源、什么隔离级别），开发者创建Sandbox时引用这个模板就行，不用关心底层细节。思路有点像StorageClass——定义一次，到处引用。这对大团队来说太重要了，否则每个业务组都自己拼yaml，配置漂移是迟早的事。

SandboxClaim —— 消费者接口。上层框架比如LangChain、Google的ADK，可以通过SandboxClaim来请求一个沙箱执行环境。它解耦了"我要一个沙箱"和"沙箱底层长什么样"这两个关注点。这意味着你换底层的隔离实现（比如从gVisor切到Kata），上面的Agent框架代码一行不用改。

SandboxWarmPool —— 预热池。这个才是解决冷启动的真正杀手锏。控制器会提前创建一批已经ready的Pod放在那里"热着"，新请求来了直接从池子里分配一个现成的Sandbox，不用走完整的Pod创建流程。Google在GKE上给出的实测数据是每个集群每秒能分配300个Sandbox，90%的分配操作在200毫秒内完成。200毫秒啊，这个延迟对交互式场景来说几乎感知不到了。

隔离这块怎么搞的

安全隔离是Agent场景的硬需求。你让一个LLM生成代码然后直接执行，这事本质上跟跑不可信的第三方代码没区别。Agent Sandbox在隔离上做了一个很聪明的设计决策：它本身不绑定任何特定的隔离技术，而是通过Kubernetes的runtimeClassName来对接。目前主要支持两种方案：

gVisor：Google搞的那个系统调用拦截器。它在用户态实现了一个叫Sentry的组件，拦截workload的所有系统调用，只转发一小部分到真实内核。等于给容器虚拟了一个内核出来，workload看到的和真实宿主机内核是隔离的。好处是开销小、启动快，大部分AI Agent场景够用了。坏处是不是所有系统调用都支持，某些比较底层的操作会失败。

Kata Containers：每个Pod跑在一个独立的轻量级VM里面，真正的硬件虚拟化隔离。每个Sandbox有自己的内核，一个Sandbox里的内核漏洞完全不影响其他Sandbox和宿主机。隔离强度最高，代价是启动延迟会大一些——VM毕竟要boot内核。这也是为什么WarmPool对Kata场景特别关键，你得提前把VM boot好放那等着。

选哪个？我自己的判断是这样的：

• 内部团队的Coding Agent、文档分析Agent这类，运行环境相对可控，gVisor足够了
• 面向外部客户的Code Sandbox，或者SaaS产品里的用户代码执行，选Kata更稳妥
• 如果你的场景已经在用Firecracker做Serverless的函数隔离，那Kata的VM隔离模型会比较亲切

在SandboxTemplate里指定就行，一行的事：

spec:
  sandboxSpec:
    podTemplate:
      spec:
        runtimeClassName: gvisor  # 或者 kata

跟AI Gateway Working Group放在一起看

今年3月9号K8s社区宣布成立了AI Gateway Working Group，11天之后就发了Agent Sandbox这篇博客。这个时间间隔绝对不是巧合，这俩是一套组合拳。

AI Gateway解决的是"推理请求怎么智能路由"的问题。传统的Ingress或者Gateway API做L7路由，本质上就是匹配host、path然后转发给后端。但模型推理的流量不一样——你不能把请求随便丢给一个健康的Pod就完事。你得知道这个Pod的KV-cache还剩多少空间、推理队列排了几个请求、它加载了哪些LoRA适配器。AI Gateway引入了InferencePool的概念，让网关在路由推理请求时能感知这些模型服务器特有的指标。

Agent Sandbox解决的是"Agent运行时怎么安全地跑在集群里"。长时间运行、有状态、需要隔离、需要快速分配和回收。

一个管请求进来的路（north-south流量面），一个管Agent住下来的地方（runtime面）。在一个完整的AI平台里，典型的流程是这样的：用户请求通过AI Gateway路由到推理后端 → 模型做推理、决定要调用工具 → 把工具调用任务发给一个隔离的Agent Sandbox去执行 → 结果返回。

网关不是沙箱。沙箱不是路由器。各管各的，清晰明了。

Google已经把这条路跑通了

说到落地，Google在这事上是最激进的。5月20号他们官宣GKE Agent Sandbox正式GA，同时放了几个让人印象深刻的数字：

• 从去年11月KubeCon NA预览发布到现在不到半年，GKE上的Sandbox使用量暴涨了16倍
• LangChain和Lovable是早期大客户，在上面跑着百万级的Agent实例
• 每集群每秒300个Sandbox分配，P90延迟200毫秒
• 支持Pod Snapshot做热挂起——Agent空闲时暂停到磁盘，有请求时秒级恢复，不用一直占着内存

更值得关注的是他们同时发布了一个叫Agent Substrate的新开源项目。这个项目的目标很疯狂——它认为标准Kubernetes的控制面不够用了。K8s apiserver设计上是为数千个长时间运行的Service优化的，但Agent场景是数百万个亚秒级的工具调用进进出出，这种chatter会把apiserver打崩。Agent Substrate用一个极简的控制面绕过K8s的一些瓶颈，同时保留安全运行时和快照能力。

有点当年containerd从Docker里剥出来的味道——大方向不变，但为了极致性能场景定制一个更薄更快的层。

生产环境跑起来的几个关键点

装Agent Sandbox本身确实简单：

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

之后 kubectl get sandbox 就能看到你的沙箱了。但要在生产环境稳定运行，下面几件事建议提前规划好：

WarmPool的成本需要精细管理。预热池大小直接影响两个指标：冷启动延迟和闲置成本。池子太大，一堆Pod白白占着资源没人用；池子太小，高峰期又不够分配。Google在GKE里做了个很巧的设计——用suspended VM做"冷池"来补充warm pool。warm pool提供即时分配能力，冷池提供弹性储备，suspended状态下只收存储费不收计算费用，需要的时候恢复到warm状态。这个思路自建集群也可以借鉴，用Kubevirt或者节点休眠方案来实现类似的效果。

网络策略是底线。Agent执行的是LLM生成的不可信代码，网络必须做default-deny。我建议的策略是：入站全部拒绝（除了健康检查），出站只开白名单——允许访问LLM API的endpoint、允许访问特定的内部服务，其他一律封死。就算Agent里跑了恶意代码想外联，网络层直接拦住。这个用标准的Kubernetes NetworkPolicy就能做，不需要额外组件。

持久存储还是临时存储，想清楚再选。Coding Agent需要跨session保留已安装的依赖包、git仓库缓存、对话历史，这种就得挂PVC。但一次性的代码执行（比如用户让Agent跑一段数据处理脚本），EmptyDir就够了，跑完即弃。混用两种模式的时候要注意PVC的生命周期管理，设好scheduled deletion避免存储泄漏。

可观测性自己搭。Agent Sandbox项目本身不带metrics和日志聚合方案。生产环境至少要做到：每个Sandbox的CPU/内存/存储使用量可追踪、Sandbox的创建/销毁/暂停/恢复事件可审计、异常终止能告警。Prometheus + 自定义ServiceMonitor + 事件审计日志这一套跑起来，出问题的时候才能快速定位。

SDK体验和编程模型

Agent Sandbox除了kubectl声明式管理之外，还提供了Python和Go两套SDK，这对做Agent平台的团队来说比较关键。你的Agent框架代码里可以直接用SDK来动态创建和管理Sandbox，不用每次都去apply yaml。

比如一个LangChain的Tool需要执行代码，它可以用Python SDK去claim一个Sandbox，把代码丢进去执行，拿到结果后释放。整个过程对Agent的编排逻辑来说就是一次函数调用，底层的Pod创建、隔离、网络配置全被SDK屏蔽掉了。这种编程模型其实很像AWS Lambda的invoke——你不用关心函数跑在哪台机器上，只管调用和拿结果。

跟目前市面上其他方案对比一下：

• 直接用Docker跑：很多团队一开始就是在Agent进程里直接调docker API拉起一个容器执行代码。简单粗暴但没有编排能力，容器挂了没人管，资源也没法统一调度。多节点集群下更是没法玩。
• 用Serverless函数（Lambda / Cloud Functions）：冷启动延迟是老大难问题。而且函数的运行时间有上限，大部分平台限制15分钟。Agent那种跑几个小时的任务直接被掐断。
• 自己造轮子写Controller：不少团队（包括我们之前）就是拿StatefulSet硬凑一个类似的效果。能跑，但维护成本高，功能跟不上需求变化的速度，新来的人看这一坨自定义逻辑直接头大。
• Agent Sandbox：声明式API + 预热池 + 隔离可插拔 + SDK编程接口，四件套一步到位。而且是社区项目，有持续演进的保障。

当然也有它现阶段的短板。API还是alpha，文档虽然清晰但案例还不够丰富，社区生态还在早期。你想找个production-ready的Helm Chart带全套monitoring直接部署，暂时还没有。得自己从manifest开始搭建。

跟Bedrock AgentCore的差异

AWS那边走的是另一条路。Bedrock AgentCore提供的是全托管的Agent执行环境——你不需要关心底层是K8s还是别的什么，把Agent代码交给平台就行。它的好处是运维成本极低，坏处是灵活性受限，而且你的Agent执行环境是个黑盒。

Agent Sandbox走的是基础设施即代码的路线，给你最大的控制力和可定制性，代价是你得自己管集群、自己做运维。两种思路本质上是managed service vs self-hosted的经典权衡，没有绝对的对错。

我觉得比较合理的判断标准是：如果你的业务对数据主权有严格要求（比如金融、政务场景），或者需要对执行环境做深度定制（特殊的网络拓扑、自定义内核参数），Agent Sandbox这种自建方案更合适。如果你就是想快速出活，不想操心底层，用managed service没毛病。

我现在的看法

Agent Sandbox的出现标志着K8s社区正式承认了一件事：AI Agent是一种全新的工作负载类别，它不是微服务，不是有状态副本集，也不是批处理作业。它需要属于自己的Kubernetes原语。这个认知转变比具体的技术实现更重要。

不过我也不建议现在就无脑上。项目目前还是v1alpha1的API，没稳定之前随时可能breaking change。如果你的场景还比较简单——只是跑个模型推理endpoint或者短生命周期的batch job——Deployment和Job就够了，别为了尝鲜引入额外复杂度。

Agent Sandbox适合的典型场景是：需要用户级别或任务级别的隔离、长时间运行的有状态Agent、需要执行不可信代码、对冷启动延迟敏感的交互式应用。如果你正在搭建AI Agent平台或者SaaS产品的代码执行引擎，这个项目值得现在就开始跟踪。

从更大的架构视角看，AI Gateway + Agent Sandbox + 传统K8s负载（Deployment/StatefulSet/Job），三层各司其职，构成了云原生AI平台的基座。这个方向我觉得是对的。接下来就看API什么时候能到beta、以及除了GKE之外的厂商跟进速度了。

如果觉得这篇文章对你有帮助，欢迎点赞、转发、在看三连，让更多人看到。

公众号：耕云躬行录
个人博客：躬行笔记