把 Agent 当集群负载：拆解 Google AX 与 Substrate

先分清两个东西

2026 年 5 月 20 日，Google 开源了两个 Apache 2.0 项目：Agent Substrate 和构建在其上的 Agent Executor（AX）。9 月 16 日 Agent Substrate 正式登陆 GKE；9 月 21 日 AX 冲上 Hacker News 榜首（664 分、299 条评论）。

共同作者 Jaana Dogan 在 HN 上的澄清最能概括定位：「AX 是更接近作业编排的一层，跑在 Agent Substrate 之上。它不是 Agent 框架。」

翻译成工程语言——AX 管的是「任务怎么声明、怎么调度、怎么挂起恢复、怎么审计」；Substrate 管的是「计算资源怎么在上万个 Agent 之间复用」。两者都不碰 Prompt、Memory、Tool 抽象，那是 ADK、LangChain、Claude Code 这些 harness 的活。这条分层是理解整个项目的钥匙：Google 卖的不是又一个 SDK，而是 Agent 的运行底座。

为什么 Agent 不能按微服务或批处理部署

这是全文最重要的前提。把 Agent 塞进现有 K8s 模型会连撞三堵墙：

• 算力经济性：标准微服务全天占资源是合理的；Agent 却是突发式的，90% 以上时间在等模型推理、等工具返回、等人回复。给每个会话常驻 1 CPU / 1G，百万并发就是百万核加 PB 级内存。
• 冷启动延迟：Pod 冷启动是秒级到十秒级（拉镜像 → 内核 → 应用初始化）。一次对话中途冷启动几秒，交互体验直接报废。一个 Python ADK Agent 初始化常常要 10 秒以上，因为要启动解释器、导入依赖、构建内存对象图。
• 控制面吞吐：K8s 的 etcd 基于 Raft 串行提交，官方建议库容量约 8GB，为「万级对象、低频更新」设计。百万级 Actor 的高频状态变更会把 Watch 机制和 API Server 压垮。

所以 Agent 既不是无状态微服务，也不是跑完即走的批处理，而是有状态、突发、长生命周期的新负载类型。

Agent Substrate：Actor 与 Worker 的解耦

核心抽象只有几个词：

• Actor：Agent 的长期逻辑实例，拥有身份、生命周期状态和自己的快照。
• Worker：一个预热好的 K8s Pod，同一时刻只跑一个 Actor。
• ActorTemplate：实例化 Actor 的蓝图（镜像、命令、环境变量、资源、沙箱类型、健康检查、快照策略），不可变——换版本要建新模板。
• WorkerPool：一组预启动的空闲 Worker。
• Atespace：Actor 身份的一部分，充当隔离边界（注意它不是 K8s namespace）。

关键点在于：Actor 不与任何特定 Worker 绑定。空闲时系统对它做一次全量快照（进程内存 + 文件系统），写进本地磁盘和 Google Cloud Storage，然后释放 Worker 回池；下一个请求到达时，快照被恢复到任意一个空闲且兼容的 Worker 上。逻辑生命周期与物理资源彻底分离，多路复用才成立。

路由唤醒由 atenet 承担：每个 Actor 有一个稳定地址 <actor>.<atespace>.actors.resources.substrate.ate.dev，请求进来时按 Host 识别目标 Actor；若它处于挂起态就触发恢复流程。池子满了不是返回 503，而是把请求 park 住，等有 Worker 空出来再重试——这是它宣称「亚秒激活」之外的另一个体验设计。

快照分两级也很巧妙：创建 ActorTemplate 时，Substrate 会临时把工作负载跑起来、等就绪、打一次全量检查点，得到 golden snapshot。新 Actor 从这个共享检查点起步，省掉整个冷启动路径；之后每次挂起则写入该 Actor 专属的 last snapshot，下次恢复的是它自己那一份。这就是「有状态」的来源。

为什么要旁路 K8s 控制面：Actor 的运行时状态（位置、快照指针）放在 Redis/Valkey 而不是 etcd，因为前者靠内存读写和异步复制换取十万级单机写 QPS，可水平分片；K8s CRD（WorkerPool、ActorTemplate 这类配置对象）仍走 etcd。代价是放弃了存储层的强一致性保证，一致性控制要在应用层自己做。

官方给的数字，和不是数字的地方

Google Cloud 在 9 月 16 日的发布博客里给的指标是：比标准容器运行时密度高 10 倍，沙箱恢复低于 500ms，每秒 500 次以上挂起/恢复，单主机可承载 1000 个以上休眠 Agent。Substrate 仓库的演示更直观：250 个有状态会话挤在 8 个物理 Pod 上，也就是 30 倍以上超售。

需要特别提醒的是，仓库里「单集群十亿级 Actor」这类说法是设计目标，不是可复现的公开 Benchmark；项目 README 自己写着「尚不适合生产使用，API 几乎必然会变」。把目标当实测是读这类项目最容易犯的错。

AX：四个声明式原语，Kubernetes 手感

AX 是个 Go 写的 CLI + gRPC 控制面，部署进 ax-system namespace（用 ko 构建镜像，配 Redis）。它的抽象只有四个，都在 ax.io/v1alpha1：

一份清单就能把三者一起声明：

apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
  name: golang
spec:
  repos:
    - repo: https://github.com/golang/go.git
      branch: "my-fix"
---
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
  name: test
spec:
  workspace: golang
  goal: "Ensure that Go tool chain is available and is built from source"
  debug: true   # 允许 ax ssh 进沙箱

操作流程和 kubectl 几乎一一对应：

go install github.com/google/ax/cmd/ax@latest
make deploy AX_IMAGE_REPO=<your-registry>   # 部署控制面，先要有 Substrate
ax apply -f task.yaml
ax get tasks
ax watch task task123          # 实时看 phase / condition 变化
ax ssh task123 -- ls -la /workspace
ax suspend task task123        # 空闲挂起
ax resume  task task123        # 原地续跑

Substrate 那一侧则用自己的 CLI：

kubectl ate create atespace demo
kubectl ate create actor my-counter-1 -a demo --template-ref counter
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/

AX 内置 Antigravity harness，支持 Google AI Studio 和 Vertex AI；同时是 harness 无关的，官方明确列举了 LangChain、LangGraph、ADK、Claude Code、MCP server 等都能跑上去。

和已有方案的取舍

更本质的差别在状态：Knative 卖的是无状态函数的零缩放，Substrate 卖的是有状态挂起——内存、打开的文件、终端状态原样保留。它填的正是这个空白。

谁适合用，谁该再等等

适合：已经是 GKE/自建 K8s 重度用户、且有「大量并发会话但单次调用很短」形态的平台团队——编码助手、后台长驻助理、RL rollout、一次性沙箱、压测/基准评测。对这类团队，Substrate 的思路（Actor/Worker 解耦 + 快照恢复 + 数据本地性感知调度）值得直接搬进基础设施规划。

该等等：想快速起步的独立开发者。社区反馈相当一致——赞扬它解决了空闲 Agent 的云成本，同时批评「开发者体验友好」的营销口径与「你得自己维护 K8s 集群、镜像仓库和用 ko 管 CRD」的现实不符。此外还有几个硬约束值得记在本子上：

• 挂起后已打开的网络连接不会保留，数据库会话、MCP 长连接都需要 Agent 代码自己重连；
• GKE 版本目前不支持 EgressPolicy（默认拒绝、按主机名规则、凭据注入都还没上）；
• 不支持 GPU 直通到 Actor 容器，gVisor 也无法对活跃 CUDA 上下文做快照；
• gVisor 的 Checkpoint/Restore 对 WebSocket、gRPC 流式这类长连接有已知问题，依赖流式推理的框架要提前验证；
• 项目非 Google 官方支持产品，长期路线与治理仍在变动。

Google 自己的定位是：Substrate 与 Kubernetes 不是竞争关系——沙箱负责跑不可信代码，Substrate 负责处理大量空闲会话，Kubernetes 负责机器供给，生产里三者通常一起用。它想复刻的是 Knative 之于函数计算的位置，而不是 Kubernetes 本身。至于 Agent 基础设施会不会像容器编排一样收敛到单一项目，还是各大厂各搞一套再次碎片化，现在还没有答案。

参考链接

1. https://github.com/google/ax
2. https://github.com/agent-substrate/substrate/blob/main/README.md
3. https://cloud.google.com/blog/products/containers-kubernetes/agent-substrate-available-on-gke
4. https://cloud.google.com/blog/products/containers-kubernetes/bringing-you-agent-sandbox-on-gke-and-agent-substrate
5. https://docs.cloud.google.com/kubernetes-engine/ai-ml/about-agent-substrate
6. https://www.infoq.com/news/2026/09/google-ax-orchestrator/
7. https://wdenniss.com/agents/agent-substrate/
8. https://pkg.go.dev/github.com/google/ax