250 个 Agent 复用 8 个 Pod：Google 的 Agent Substrate 如何在 K8s 上做亚秒级挂起恢复

Claude Code、Codex、Gemini CLI 这类 Agent 工具越来越多，写代码、做运维、做数据分析都能用。但一个人本地开终端跑 Claude Code 没问题，如果一个团队要同时跑 100 个实例，或者一个产品要服务 10000 个用户、每人一个专属 Agent，问题就来了。

Agent 不像普通的 Web 服务。它有自己的状态、文件系统、终端会话，不能简单开 10000 个容器——资源扛不住，成本也扛不住。

而且 Agent 有个特点：大部分时间是空闲的，在等输入、等工具返回、等用户确认，真正干活的时间可能只有 10%。剩下 90% 的容器干等着，浪费很大。

Google 遇到了同样的问题，做了一个开源项目来解决：Agent Substrate。

Agent Substrate 是什么

一句话：Agent Substrate 是用来大规模运行 AI Agent 的基础设施。

它不是 Agent SDK，不教你怎么写 Agent。它是跑 Agent 的地方——Agent 的操作系统，Agent 的 Kubernetes。

几个关键数字：

• 250 个 Agent 复用 8 个 Pod：30 倍以上的超售比
• 亚秒级挂起/恢复：Agent 暂停和恢复不到 1 秒
• 状态完整保留：内存 + 文件系统，跨休眠周期不丢失

也就是说，用 8 台机器的资源可以同时跑 250 个 Agent，每个 Agent 有自己的状态、互相隔离，但共享底层资源。

类比共享办公空间：250 个团队共用 8 层楼。忙的时候用大房间，闲的时候退到小工位，但每个团队的文件柜是独立的。

为什么需要 Agent Substrate

在此之前，跑 Agent 大概有几种方式：

直接跑在物理机或 VM 上：一个 Agent 一台机器，简单粗暴，资源利用率极低，Agent 空闲时机器也空转。

跑在容器里：容器可以密集部署，但没有真正的隔离，安全性有问题，状态恢复也不够灵活。

用 Kubernetes 管理：K8s 能管容器，但不懂 Agent。它不知道 Agent 大部分时间空闲，不知道 Agent 需要状态持久化，也不知道 Agent 需要快速恢复。

Agent Substrate 做的事可以概括为：把大量 Agent 密集地塞进少量机器，空闲时挂起，需要时瞬间恢复，状态一点不丢。

核心能力拆解

30 倍超售比是怎么来的

核心思想是多路复用（multiplexing）。

项目里有两个概念：Actor（演员）和 Worker（工人）。Actor 是你的 Agent，Worker 是实际运行的 Pod。关键在于多个 Actor 可以共享同一个 Worker。

Actor 空闲时，Agent Substrate 把它挂起（suspend），把 Worker 让给其他 Actor；需要工作时再**恢复（resume）**到某个可用 Worker 上。整个过程亚秒级，用户基本感觉不到。

t=0s  Actor A 开始工作，占用 Worker 1
t=2s  Actor A 等待用户输入，挂起
t=2s  Actor B 开始工作，复用 Worker 1
t=5s  Actor B 完成任务，挂起
t=6s  Actor A 收到用户输入，恢复，继续用 Worker 1

Worker 1 同时服务了 Actor A 和 Actor B。有 30 个 Actor 时，Worker 1 就能服务 30 个，这就是 30 倍超售比的来源。

挂起和恢复的原理

Agent Substrate 支持两种沙箱技术：gVisor 和 microVM。

以 gVisor 为例，它本身支持 checkpoint/restore，可以把整个进程状态存到磁盘再恢复，类似游戏存档读档。Agent Substrate 在此基础上做了几项优化：

1. 增量快照：只保存变化的部分，不做全量保存
2. 异步恢复：恢复的同时就开始执行，不等全部加载完
3. 预加载：提前把可能用到的数据读进内存

这些优化叠加起来，把挂起和恢复压到了亚秒级。microVM 路线类似，本身轻量、启动快，再加上同样的优化，效果也不错。

状态持久化

普通容器重启后状态就没了，但 Agent 需要保留对话历史、文件和终端会话。

Agent Substrate 的状态持久化分两层：

1. 文件系统状态：Agent 创建的文件、安装的依赖
2. 内存状态：进程状态、打开的文件描述符

两层状态在挂起时保存、恢复时还原，对 Agent 来说就像什么都没发生过。放到 Claude Code 的场景里：正在写代码时被挂起，半小时后恢复，终端还在、文件还在、git 状态还在，继续写就行。

架构设计

┌──────────────────────────────────────────────────┐
│                     控制面                        │
│  ┌──────────┐  ┌──────────────┐  ┌───────────┐  │
│  │ ateapi   │  │ atecontroller│  │  atenet   │  │
│  │ (API)    │  │ (Controller) │  │ (Network) │  │
│  └──────────┘  └──────────────┘  └───────────┘  │
└──────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────┐
│                     数据面                        │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐        │
│  │ Worker 1 │  │ Worker 2 │  │ Worker 3 │ ...    │
│  │ ┌──────┐ │  │ ┌──────┐ │  │ ┌──────┐ │        │
│  │ │Actor │ │  │ │Actor │ │  │ │Actor │ │        │
│  │ │  A   │ │  │ │  B   │ │  │ │  C   │ │        │
│  │ └──────┘ │  │ └──────┘ │  │ └──────┘ │        │
│  └──────────┘  └──────────┘  └──────────┘        │
│       ▲              ▲             ▲             │
│    atelet         atelet        atelet           │
└──────────────────────────────────────────────────┘

ateapi：控制面核心，暴露 gRPC 接口，管理 Actor 和 Worker 的生命周期。创建、挂起、恢复 Actor 都走它。

atecontroller：Kubernetes Controller，负责调谐自定义资源（CRD）。WorkerPool、ActorTemplate 这些资源的实际状态对齐期望状态，是它的活。

atenet：网络控制器，负责 DNS 解析、Envoy 路由、代理 Sidecar。访问某个 Actor 的请求怎么路由过去，由它管。

atelet：跑在每个节点上的 DaemonSet，监督本节点的 Worker Pod，协调快照、管理状态传输。

ateom-gvisor / ateom-microvm：跑在沙箱内部的助手，执行具体的 checkpoint 和 restore 操作。

整体思路：控制面做决策，数据面做执行，网络层做连接。

跟 Kubernetes 的关系

K8s 管的是容器，Agent Substrate 管的是 Agent。

K8s 的调度器不懂 Agent 的特性，不知道 Agent 大部分时间空闲、需要状态持久化、可以秒级恢复。Agent Substrate 不替代 K8s，而是在 K8s 之上加了一层 Agent 专用的调度和管理：用 K8s 的 Pod 跑 Worker，用 K8s 的 Controller 管资源，但调度逻辑、状态管理、网络配置都是自己的。

可以这样理解：K8s 是操作系统，Agent Substrate 是跑在操作系统上的 Agent 专用运行时。就像 Docker 是容器运行时，Agent Substrate 是 Agent 运行时。

兼容主流框架

Agent Substrate 设计上框架无关，不关心 Agent 用什么框架写，只要跑在标准容器里就行。但它对几个主流框架做了优化：

Agent Development Kit (ADK)：Google 的 Agent 开发框架。Agent Substrate 原生支持 ADK 的 Actor 身份和持久化工作记忆。

LangChain：Agent Substrate 适合长时间运行的 LangChain Agent，沙箱隔离和状态持久化都是它需要的。

Claude Code & Codex：比较典型的使用场景。多个 Claude Code 实例可以复用同一台机器，每个都有独立的终端和文件系统状态。

MCP Server：可以把 MCP Server 部署在 Agent Substrate 上，让它成为一个持久、安全的工具服务。

Agent Substrate 不做 Agent 开发的事，只做一件事——把 Agent 跑好。

实际使用场景

大规模 Agent 服务

做一个 AI 编程助手产品，10000 个用户、每人一个专属 Claude Code 实例。传统做法是开 10000 个容器，成本高、资源浪费。用 Agent Substrate，8 台机器就够了：空闲时挂起，需要时瞬间恢复，用户无感。

MCP Server 托管

MCP Server 跑在哪里是个问题。部署在 Agent Substrate 上，它会自动管理生命周期，需要时启动，空闲时挂起，状态持久化。

CI/CD 沙箱

CI/CD 需要跑不可信代码。Agent Substrate 的 microVM 沙箱提供硬件级隔离，比普通容器更安全。状态可以持久化，意味着构建缓存能跨运行保留，CI 速度更快。

多租户 Agent 平台

做 Agent 平台时，每个租户的 Agent 放在自己的 Atespace 里互相隔离，底层资源调度交给 Agent Substrate。

快速开始

Agent Substrate 提供了基于 kind 的本地开发环境，前置条件是 Go、kubectl、Docker。

# 1. 创建 kind 集群
hack/create-kind-cluster.sh

# 2. 安装 Agent Substrate
hack/install-ate-kind.sh --deploy-ate-system

# 3. 安装 Counter Demo
hack/install-ate-kind.sh --deploy-demo-counter

# 4. 安装 CLI 工具
go install ./cmd/kubectl-ate

# 5. 创建 Atespace 和 Actor
kubectl ate create atespace demo
kubectl ate create actor my-counter-1 -a demo --template=ate-demo-counter/counter

# 6. 转发端口
kubectl port-forward -n ate-system svc/atenet-router 8000:80

新开一个终端发请求：

curl -X POST -H "Host: my-counter-1.demo.actors.resources.substrate.ate.dev" \
-i http://localhost:8000/

这个 Counter Demo 演示状态持久化：挂起 Actor 再恢复，计数器的值还在。

局限性

还在早期开发阶段。API 随时可能变，不保证向后兼容，生产环境慎用。

依赖 Kubernetes。没有 K8s 环境的话，上手成本比较高。

学习曲线陡峭。Actor、Atespace、WorkerPool、ActorTemplate 这些概念要花时间搞清楚。

文档还在完善中。有一些 Demo，但很多高级用法还需要看源码。

适合你吗

适合的场景：

• 在做大规模 Agent 服务，成本是问题
• 需要安全隔离的沙箱环境
• 已经在用 Kubernetes，想更高效地跑 Agent
• 在做 Agent 平台，需要多租户隔离

如果只是个人开发者，本地跑几个 Agent，Agent Substrate 偏重，直接用 Docker 或本地运行就够了。

结语

Agent Substrate 解决的是一个真实问题：Agent 大规模运行的成本和效率。思路是利用 Agent 空闲时间多的特点，通过密集复用和快速恢复把资源利用率拉起来。30 倍超售比、亚秒级恢复、状态持久化，背后是实际的成本节省。

项目还在早期，API 不稳定，生产环境慎用。如果正在考虑大规模部署 Agent，值得关注。

参考链接：

• Agent Substrate GitHub:
• Agent Substrate 文档:
• Counter Demo:
• Agent Executor（基于 Agent Substrate 的分布式 Agent 运行时）: