Google Agent Substrate：250个Agent挤8个Pod，30倍超售怎么做到的

Google Agent Substrate：250个Agent挤8个Pod，30倍超售怎么做到的

先收藏。以后做 Agent 集群部署，你大概率会回来抄这个架构。

2026 年 Google I/O 没有 keynote 隆重介绍、没有产品发布会排场，Google 悄悄在云博客放了三篇技术文章，开源了两个 GitHub 仓库：agent-substrate/substrate 和 google/ax。

工程界的反响比一般媒体大得多，因为这不是又一个 LangChain 或者 Agent SDK。Agent Substrate 解决的是一个几乎没人认真讨论过、但迟早会炸掉所有生产 Agent 系统的问题：用传统 Kubernetes 部署百万级并发 Agent 场景，经济上根本跑不起来。

一个处理用户任务的 AI Agent 是怎么运行的？200ms 内爆发式地发一串工具调用，然后完全闲置 30 秒、1 分钟甚至更久 —— 等人类回复、等 API 返回、等外部事件。放大到百万个 Agent 同时在线，你如果每个都起一个 Pod 或容器，钱是按秒烧的，90%+ 的算力是在给空气付账。

Google 的解法是做了一个自底向上的全新三层堆栈，最核心的数据足够扎眼：把 250 个有完整状态的 Agent，在 8 个物理 Pod 上来回「搬家」，超售比例 30 倍以上，恢复延迟不到 1 秒。 仓库上线不到 4 个月拿到 1680 Stars，不是没理由的。

本文提纲

  1. 项目全貌：Agent Substrate 是什么，不是什么（1.68k Star / Go 89% / Apache 2.0）
  2. 为什么传统 Kubernetes 跑不起大规模 Agent？三个物理瓶颈
  3. 架构拆解：三层 Agent 堆栈 + 两个核心抽象 Actor / Worker
  4. 30x 超售的秘密：挂起/恢复、流量拦截、快照存储的工作流程
  5. 生态联动：google/ax（Agent Executor）、GKE Agent Sandbox、ADK 与 MCP
  6. WorkerPool / ActorTemplate / SandboxConfig：三个 K8s CRD 实战

1. 项目全貌：Agent Substrate 是什么，不是什么

仓库：agent-substrate/substrate

指标 数值
Stars 1,680
Forks 283
创建时间 2026-05-13
主语言 Go（89.2%），Python 5.5%，Shell 4.0%
License Apache 2.0
归属声明 非 Google 官方支持产品（Google 开源但非 VRp 项目）

一句话定义：Agent Substrate 不是写 Agent 的 SDK，是大规模运行 Agent 的高密度运行时和调度控制面。

它管的事情非常明确：
- Agent（叫做 Actor）的生命周期：创建/销毁、挂起/恢复
- 把大量 Actor 调度到少量预备好的 Worker（K8s Pod）上
- 流量路由：进来的请求知道该唤醒哪个 Actor
- 多种沙箱后端的一致管理：gVisor 是默认，microVM（Kata Containers）也支持

不管的事情同样明确：
- 不帮你写 Agent 逻辑
- 不提供 Prompt、Memory、Tool 的抽象（那是 AX / ADK / LangChain 的活）
- 不替代 Kubernetes，而是建在它上面，用它擅长的 Pod 管理 + 自动扩缩容

2. 为什么传统 Kubernetes 跑不起大规模 Agent？三个物理瓶颈

先把痛点讲透，否则你看不出 Substrate 设计的巧妙之处。

把一个 Agent 当作普通微服务部署到 K8s，会连续撞到三堵墙。

第一堵墙：算力经济性崩溃。 一个标准微服务是持续跑的，Pod 全天占着资源是合理的。但 Agent 是 bursty 负载，90% 以上时间在 idle。假设一个 Agent Pod 配置 1 CPU / 1G 内存，100 万个并发会话就是 100 万核 / 1 PB 内存 — 这不是工程问题，是账面上就已经不可能的事情。

第二堵墙：冷启动延迟不能忍。 一个 Agent 在 tool call 中间需要被暂停再唤醒，用户能感知的交互延迟大概几百毫秒。标准 Kubernetes Pod 冷启动是秒级到十秒级（拉镜像 → 内核启动 → 应用初始化 → 注入环境变量），对 Agent 来说完全不可用。一次用户会话中途冷启动几秒钟，体验比网站挂了还差。

第三堵墙：控制面被活活冲死。 K8s 的调度器（kube-scheduler）是为「每秒几十个 Pod 创建/销毁」这种量级设计的，它的控制面 etcd 事务、watch 机制、调度打分全部走的是粗粒度低频路线。如果你的 Agent 每秒产生百万次子秒级工具调用，每次都要经过 K8s API Server，整个集群会直接雪崩。

结论非常无情：Agent 不是微服务，用微服务的基础设施硬塞，从根上就是错的范式。 Agent Substrate 的整套设计几乎就是对着这三堵墙一一定制解决方案。

3. 架构拆解：Google 三层 Agent 堆栈 + 两个核心抽象

Google I/O '26 上亮相的其实是一个完整的端到端方案，自底向上分了三层。大多数人看到 Substrate 就止步了，但真正理解它需要把上层也串起来：

MERMAID_BLOCK_0

层级 组件 核心职责 关键技术
L3 运行时层 AX (Agent Executor) 状态一致性、断线恢复、执行审计、分支（Fork） Single-Writer 控制器 + Event Log
L2 调度层 Agent Substrate 高密度并发、超低延迟唤醒、避开 K8s 控制面冲击 亚秒级 Suspend/Resume + 独立控制面调度器
L1 隔离层 GKE Agent Sandbox 不可信代码沙箱隔离 + Standby 算力缓冲池 gVisor 用户态内核 + Pod 快照技术

Substrate 位于中间的 L2 — 往下它不重复造沙箱和 Pod 管理的轮子（交给 K8s + gVisor），往上它不干预业务运行时的状态机逻辑（交给 AX）。它专注做一件事：把很多 Actor 塞到很少的 Worker 上，还能保证来了流量立刻切回来。

3.1 两个核心抽象：Actor vs Worker

架构里第一次看容易混淆的两个术语，Substrate 给了精确的定义：

  • Actor：被调度的「工作负载实例」。可以是一个 AI Agent，可以是一个 MCP Server，可以是一个长期运行的工具进程。大数量、稀疏、随时可以挂起 是它的核心特征。
  • Worker：真正的 Kubernetes Pod，是预先启动好的「warm standby」。里面已经跑了 gVisor / microVM 沙箱进程，随时待命。小数量、常驻、随时能接活 是它的特征。

Substrate 的本质就是一台「Actor ↔ Worker 的映射路由器」。Actor 挂起的时候，它的完整状态（内存 + 文件系统）被序列化出去存好，Worker 就腾出来给下一个 Actor。有事件要处理时，根据路由表找到 Actor 对应的最新快照位置，分配一个空闲 Worker，把状态灌回去，流量切过来，恢复运行。

这里有一个极其关键的工程取舍文档里直接承认了：「Much of this architecture is aspirational, and is not yet implemented!」翻译成人话就是：架构文档野心很大，代码实现了核心路径但还有大量空白。比如 actor 状态数据的分布式存储和数据局部性问题，目前是明确写出来的 New Problems 章节，等着你贡献 PR。

4. 30x 超售的秘密：挂起/恢复、流量拦截、快照存储

现在我们可以讲清楚 Demo 里那个「250 个 Agent 塞到 8 个 Pod」是怎么实现的了。整个流程是一条精密的管道：

MERMAID_BLOCK_1

这个流程有三个不显眼但决定成败的细节：

4.1 流量先被拦截，再决定要不要唤醒

Substrate 自带了一个 substrate-aware network proxy，在所有入流量进 Actor 之前先截一道。它的任务不是转发那么简单，而是判断目标 Actor 现在是不是在运行。 如果是挂起状态，proxy 不会立刻报错丢包，而是通知控制面「这个 Actor 需要被唤醒」，同时把请求 hold 住直到 resume 完成（通常亚秒级），然后无缝转发。

用户端感知到的只是「这次请求多了几百毫秒」，不会看到任何错误页面或重试。这和传统的「Pod 没了 → 503 → 客户端重试 → Pod 起来 → 终于成功」完全是两个体验级别。

4.2 亚秒级恢复不靠 K8s，靠 gVisor 内建的 suspend/resume

冷启动慢的根源是 Pod 从零启动。Substrate 绕过了这个问题 — Worker Pod 一直是活着的，从来没关。真正被开关的是 Pod 里面运行的沙箱（gVisor Sentry）。

gVisor 和 Kata Containers 这两种沙箱技术都原生支持 checkpoint/restore 语义。一个 Actor 挂起的时候，就是把 gVisor 里的整个 guest 内核状态 + 进程地址空间 + overlay 文件系统变化打成一个二进制快照。恢复的时候把快照灌回一个已经在跑的空沙箱，跳过了所有的容器创建、内核初始化、进程启动，这才是亚秒级延迟的真正来源。

换句话说：K8s 的调度粒度是 Pod，Substrate 的调度粒度是 Pod 里面的沙箱快照。 同一个 Worker Pod 一天之内可以承载几十上百个不同 Actor 的运行，而 Pod 本身从来不重启。

4.3 数据局部性：还没完全解决的大问题

Substrate 的文档诚实地把这个 trade-off 单列了出来。Actor 数量一旦上百万，每次挂起要存的快照总量是惊人的，而 Actor 的工作状态可能每秒更新很多次。这会立刻产生一个全新的问题：调度不仅要找空闲 Worker，还要找存了那个 Actor 最新快照的 Worker / 存储节点。

如果一个事件打到了北京机房的 Proxy，而 Actor 的最新快照存在上海的存储节点，那亚秒级恢复就不存在了 — 光拉数据就要好几秒。目前 Substrate 的 architecture.md 里明确把「data locality as first class concern」列为 future work，没有实现。这是下一步真正要啃的硬骨头。

5. 生态联动：AX、GKE Sandbox、ADK、MCP 怎么拼起来

Substrate 不跑单，它的价值完全依赖和上下两层的深度整合。

5.1 上层：google/ax（Agent Executor）做运行时

AX 是 Google 同批开源的另一个项目，定位是 Agent 的应用运行时。核心能力：
- Single-Writer 控制器：杜绝分布式竞态，只有一个实体改状态
- Event Log 持久化：所有动作按序记日志，崩溃了直接从日志序号回放恢复
- --resume 断点续跑：客户端断网重连，从上次 sequence number 接着来，不用从头开始
- ax fork 分支实验：从任意 checkpoint 克隆一条新日志，做 A/B 测试或者回滚

# 快速体验 AX（无需集群）
go install github.com/google/ax/cmd/ax@latest
export GEMINI_API_KEY="..."
ax exec --input "List all files in /tmp"
# 断线之后回来接着跑
ax resume <session-uuid>

AX 是计算面无关的，但它最深度整合的后端就是 Agent Substrate。生产部署的官方推荐路径是：AX Server 部署在 K8s 上，所有的 Agent / Harness / Tool 以 Actor 的形式交给 Substrate 调度。 客户端 → AX Server →（控制）→ Substrate 恢复 Actor →（数据流）→ Actor 实际执行，这是完整的一条通路。

5.2 下层：GKE Agent Sandbox 做安全隔离

GKE Agent Sandbox 是 GA 了的商用产品，不是开源。它在 gVisor 之上做了几个 Substrate 必须的能力：
- Warm pool 预热池：300 sandboxes/秒 的供应速度，<200ms 的延迟
- Pod Snapshots：挂起 idle agent、秒级恢复的底层能力
- Kernel 级攻击面缩减：agent 执行不可信代码（LLM 生成的 Python 脚本）时，gVisor Sentry 在用户态把 syscall 重实现一遍，Sentry 被攻破也拿不到真内核 root

对于不能上 GCP 的团队，Substrate 也支持自建的 gVisor containerd shim 或者 Kata Containers，只是少了 GKE 那边打磨过的 warm pool 和 snapshot 优化。

5.3 框架兼容：ADK / LangChain / Claude Code / MCP 全支持

Substrate 管的是标准 OCI 容器，在 kernel 层通过 gVisor 跑起来，所以理论上装在 OCI 镜像里的任何东西都能当 Actor。文档里专门列了原生合作对象：

框架 Substrate 里的使用方式
ADK (Agent Dev Kit) ActorIdentity 服务直接签发 ADK 兼容 JWT，天然对接 ADK 的工具和内存安全模型
LangChain 作为长时间运行的有状态 Agent 的最佳执行环境，沙箱化 tool call
Claude Code & CodeX 高密度的有状态编码沙箱，跨会话保存终端和文件系统状态
MCP 把 MCP Server 部署成 Substrate Actor，作为所有 LLM 持久可用的安全工具集

MCP 这个场景特别值得展开。你部署一个 PostgreSQL MCP Server，放在普通 K8s Pod 里是 1 Pod / 1 客户，资源浪费严重。放在 Substrate 上，1000 个租户共享 30 个 Worker Pod，每次有 MCP 请求才把那个租户的 MCP Server 状态唤醒接进来，用完立刻挂起腾地方。安全隔离由 gVisor 保底，成本直接砍一个数量级。

6. WorkerPool / ActorTemplate / SandboxConfig：三个 K8s CRD 实战

Substrate 的 API 以 Kubernetes Custom Resource 的形式暴露，三个核心 CRD 构成了你实际部署时的完整配置面。

6.1 WorkerPool：我要多少台待命机器

apiVersion: ate.dev/v1alpha1
kind: WorkerPool
metadata:
  name: agent-pool
  namespace: ate-demo
  labels:
    workload: secret-agent
spec:
  replicas: 10                  # 常驻 10 个 warm standby Pod
  sandboxClass: gvisor          # gvisor 或 microvm
  template:
    resources:
      limits:
        cpu: "4"
        memory: "8Gi"
        nvidia.com/gpu: "1"     # 带 GPU 时自动透传进每个 Actor 沙箱
    nodeSelector:
      cloud.google.com/gke-nodepool: agent-workers

注意 replicas: 10 不是「最多同时跑 10 个 Actor」，而是「随时准备好 10 个位置」。Actor 的并发上限取决于每个 Actor 声明的资源 + 调度器的超售策略。CPU/内存 limits 是 Worker 的容量上限（也就是它里面最多能塞多大个 Actor Sandbox），不是一个 Worker 可以分给多个 Actor 共用的预算。文档里写得很清楚：一个 Worker 同一时刻只承载一个 Actor。

6.2 ActorTemplate：一个 Actor 长什么样

apiVersion: ate.dev/v1alpha1
kind: ActorTemplate
metadata:
  name: code-agent-v1
spec:
  image: mycompany/claude-code-agent:latest
  resources:
    requests:
      cpu: "500m"
      memory: "1Gi"
    limits:
      cpu: "2"
      memory: "4Gi"
  env:
    - name: MODEL
      value: "gemini-pro"
  volumes:
    - name: workdir
      persistentVolumeClaim:
        claimName: actor-work
  actorSelector:
    matchLabels:
      workload: coding

Scheduler 在看到一个 Actor 请求的时候，会找 WorkerPool 里「容量 ≥ limits 的 Worker」放进去。所以 WorkerPool 的 limits 一定要调到你打算放的最大 Actor 的规格。

6.3 SandboxConfig：沙箱本身装在哪里

这是 cluster-scoped 的资源，管沙箱的二进制文件、pause 镜像、运行参数。大多数集群只需要一个默认的就够了。多租户或者需要不同 gVisor 版本的场景才需要自己建。

三个 CRD 的职责边界非常清晰：沙箱运行环境（SandboxConfig）→ 物理算力池（WorkerPool）→ 工作负载模板（ActorTemplate）。这是典型的平台团队 vs 应用团队分离的设计：平台工程师维护 SandboxConfig 和 WorkerPool，开发者只管写 ActorTemplate。

有在生产上大规模跑 Agent 的朋友吗？你们现在是怎么部署的，一个 Pod 跑一个 Agent 吗？评论区聊聊你的成本和痛点。试过 Substrate 的也欢迎说下真实体验。

参考文档与链接

作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

关注公众号，获取更多 AI 技术干货！

posted @ 2026-08-31 22:11  iTech  阅读(17)  评论(0)    收藏  举报