Agent Substrate：用 30× 超配比把 AI Agent 运行成本打下来的云原生沙箱调度系统

核心观点

Agent Substrate 是 Google 开源（非官方支持）的一个专为大规模 AI Agent 部署而设计的运行时底座 。它的核心命题很清晰：AI Agent 绝大多数时间处于空闲等待状态，传统 1:1 "一个 Agent 绑一个 Pod" 的做法极度浪费资源，而 Agent Substrate 通过快照式挂起/恢复 + 虚拟 Actor 多路复用，让 8 个物理 Pod 跑起 250 个有状态 Agent（演示中达到 30× 超配比），从而将基础设施成本压缩一个数量级。

这不是 AI Agent 开发 SDK，它不帮你写 Agent 逻辑，而是解决"Agent 怎么高密度地跑起来"这一纯粹的基础设施层问题。

技术阶段定位

这是一次有明确工程先例的整合创新，而非从零突破的范式革命 。快照冷启动（Catalyzer/AWS Lambda SnapStart）、微型虚拟机预热池（Firecracker/SOCK）、虚拟 Actor 模型（Microsoft Orleans/Erlang）、Scale-to-Zero（Knative）------这些技术各自已在生产环境验证。Agent Substrate 的价值在于把这些技术在 AI Agent 场景下首次系统性地组合到一起，并提供了比 K8s 原生更低延迟的控制面。对应的参照系是 Knative 之于函数计算，而不是 Kubernetes 本身。

最核心的机制：N 对 M 的资源映射

Agent Substrate 的真正聪明之处在一个关键假设：Agent 式负载大部分时间是空闲的。基于此，系统将大量逻辑"Actor"映射到少量"Worker Pod"上：

sql 复制代码

Actor（逻辑单元）  ──多路复用──▶  Worker Pod（物理资源）
（可以有百万个）                    （实际运行的 K8s Pod）


Actor 生命周期：
RUNNING（处理请求）
│ 空闲超时
▼
SUSPENDING（触发 gVisor Checkpoint，冻结内存+文件系统）
│
▼
SUSPENDED（快照写入对象存储 GCS）
│ 请求到达，atenet 路由拦截
▼
RESUMING（快照恢复到可用 Worker）
│
▼
RUNNING（亚秒级激活完成）
`Actor 生命周期：
RUNNING（处理请求）
│ 空闲超时
▼
SUSPENDING（触发 gVisor Checkpoint，冻结内存+文件系统）
│
▼
SUSPENDED（快照写入对象存储 GCS）
│ 请求到达，atenet 路由拦截
▼
RESUMING（快照恢复到可用 Worker）
│
▼
RUNNING（亚秒级激活完成）
`

关键细节有两个：

旁路控制面：Actor 的实时状态（位置、快照指针）存在 Redis/Valkey 而非 etcd，因为 etcd 受 Raft 共识串行提交限制，写吞吐无法支撑百万级高频变更；K8s CRD（WorkerPool、ActorTemplate 等配置型对象）仍走 etcd，两者各司其职。
流量驱动唤醒 ：路由组件 atenet 拦截 HTTP 请求头中的 Actor 身份（Host: my-counter-1.demo.actors.resources.substrate.ate.dev），识别目标 Actor 并触发 RESUMING 流程，实现"请求即激活"。

与历史方案的对比

方案	优点	缺陷
传统 K8s（1 Agent ≈ 1 Pod）	简单可靠	空闲资源浪费，百万 Pod 时 etcd 崩溃
Knative Scale-to-Zero	无状态函数冷启动快	不保留内存和文件系统状态，Agent 会话断裂
普通容器 Checkpoint（CRIU）	Linux 内核原语成熟	需进 K8s 核心 API（v1.25 仍是 Alpha），延迟不稳定
Agent Substrate	有状态挂起+亚秒恢复+30×超配	极早期，API 不稳定，快照依赖 GCS，gVisor 对长连接有缺陷

最本质的差异：之前的 Scale-to-Zero 方案（Knative）针对无状态函数，Agent 需要的是有状态的挂起------进程内存、打开的文件、终端状态都必须原样保留，这是 Agent Substrate 真正填补的空白。

系统组件速览

arduino 复制代码

ateapi        ──  控制面 API Server（gRPC，管理 Actor/Worker 生命周期）
atelet        ──  节点级 DaemonSet（协调快照、状态转移）
atecontroller ──  K8s Controller（调谐 WorkerPool 和 ActorTemplate CRD）
atenet        ──  网络层（DNS + Envoy 路由 + 代理 Sidecar，负责流量驱动唤醒）
ateom-gvisor  ──  沙箱内部助手（执行 runsc checkpoint/restore 命令）
ateom-microvm ──  microVM 对等组件（cloud-hypervisor 实现）
kubectl-ate   ──  CLI 工具

支持的沙箱技术：gVisor（轻量级内核隔离）和 microVM（强隔离，基于 cloud-hypervisor），框架无关，LangChain、ADK、Claude Code、MCP Server 均可跑在上面。

快速体验（本地 kind 集群）

bash 复制代码

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

2. 安装 ate 系统组件



hack/install-ate-kind.sh --deploy-ate-system



3. 安装计数器示例



hack/install-ate-kind.sh --deploy-demo-counter
go install ./cmd/kubectl-ate



4. 创建命名空间和 Actor



kubectl ate create atespace demo
kubectl ate create actor my-counter-1 -a demo --template=ate-demo-counter/counter



5. 端口转发后发请求



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/
`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 `https://link.juejin.cn?target=http%3A%2F%2Flocalhost%3A8000%2F`
`

交叉验证

来源 1：掘金技术文章《Google 开源 Agent Substrate：用 8 个 Pod 跑 250 个有状态 Agent》（2026 年）

该文从架构层面深度验证了原文观点，并补充了几个重要细节：设计目标（单集群 10 亿 Actor、P95 激活 < 100ms、唤醒吞吐 1000/秒）当前均为未公开验证的设计指标，不是实测数据，这是原文 README 中有所回避的点。此外该文明确指出 gVisor Checkpoint/Restore 对长链接网络协议存在已知缺陷，原文未正面提及。这条交叉信息对评估生产可用性至关重要。总体上两者高度认同，但掘金文章对技术边界的描述更为诚实。

来源 2：AppScale Blog《Stateful AI Agent Sandbox Sessions: Pause, Resume, Snapshot》（Satyam Kumar，2026 年 6 月）

该文来自独立 AI 架构咨询方，不隶属于 Google，从更广泛的行业视角论证了有状态快照式挂起/恢复是当前 AI Agent 基础设施的通用趋势，与 Firecracker microVM、CRIU 等技术的实践路径一致。该文聚焦成本优化场景（暂停空闲 Agent 直接影响账单），侧面印证了 Agent Substrate 所解决的问题在业界是真实的、普遍的痛点，并非 Google 单方面制造的伪需求。差异在于该文偏重单沙箱生命周期管理，Agent Substrate 的多路复用调度属于更进一步的集群级优化。

综合判断：两个独立信源都认可技术方向的正确性，但也都没有掩盖项目的极早期状态和潜在局限。

边界与局限（不该被忽视的部分）

API 没有任何兼容性保证：README 明确写"almost guaranteed to change"，不适合在此基础上投入生产研发。
设计目标≠实测性能：10 亿 Actor 和 100ms P95 是工程目标，没有公开 benchmark 数据验证。
快照依赖 GCS：状态持久化强绑定 Google Cloud Storage，非 GCP 环境需要额外适配。
gVisor 长连接缺陷：gVisor Checkpoint/Restore 对 WebSocket、gRPC 流式连接等长连接协议有已知问题，基于 streaming 的 Agent 框架需谨慎。
非官方 Google 产品：不参与 Google 漏洞悬赏计划，安全响应机制存在空白。

推演：接下来会怎样

短期（1 年内）：类 Knative 的定位会被社区接受------它不会取代 Kubernetes，而是作为 K8s 之上的 Agent 专属调度层被集成到各云厂商的 AI 平台中（如 GKE Agent Sandbox 已是先导）。阿里云的 AgentRun 已在做类似方向（其 API 中也有 ResumeSandbox 接口），说明这个基础设施层正在被各大厂同时独立建设。

中期（1-3 年）：K8s 上游的 Container Checkpoint（CRIU，v1.25 Alpha）若晋升为稳定特性，会与 Agent Substrate 形成竞争关系，但 K8s 控制面延迟问题不会消失，Substrate 的旁路控制面（Redis + 自定义 API Server）仍有差异化价值。

长期风险：如果大语言模型推理延迟继续下降，Agent 的"空闲时间假设"可能被打破（Agent 不再"大部分时间空闲"），多路复用的收益会边际递减。

个人启发

对基础设施工程师 ：这个项目是一份高质量的"拼图示范"------它没有发明新算法，而是把 gVisor Checkpoint、Envoy 路由、Redis 运行时状态、K8s CRD 这些已有积木组装成了一个有明确业务价值的系统。值得仔细研读的不只是功能，而是为什么 etcd 不够用、为什么要旁路 K8s 调度的具体论证，这是构建任何高密度有状态系统的通用思维框架。

对 AI 产品技术决策者 ：如果你的 Agent 产品存在"大量并发会话但每个会话单次调用很短暂"的模式（比如代码助手、多轮工具调用 Agent），Agent Substrate 的多路复用思路应该进入你的基础设施规划。但当前直接用这个项目会踩坑，更现实的动作是关注它的 API 设计和架构思路，用于指导自建系统，或等待 GKE 官方托管版本稳定后再迁入。

对 Agent 框架开发者（LangChain/ADK/MCP）：框架无关性是 Agent Substrate 刻意做的设计，但你的框架若依赖长连接 gRPC 流式推理，gVisor Checkpoint 的网络协议限制需要提前调研。

延伸思考

"Agent 大部分时间空闲"这个假设还能成立多久？ 随着 AI 推理硬件专用化（NPU/TPU 普及）和推理速度飞速提升，Agent 的执行时间会越来越短、响应越来越快，是否会出现"Agent 变得太快、空闲时间反而被挤压"的反转场景，进而让超配模型的经济性优势收缩？
gVisor vs microVM，在 Agent 场景下谁会成为主流？ gVisor 更轻量（进程级隔离）但兼容性有缺陷；microVM 更重（完整虚拟化）但隔离更彻底。多租户公有云 Agent 平台（需要运行用户不可信代码）和私有部署场景（安全需求不同）可能分别走向不同的技术路线，这个选择会如何影响 Agent 基础设施的生态分裂？
Agent 基础设施层会不会像 Kubernetes 本身一样被商品化？ 目前 Google（Agent Substrate）、阿里云（AgentRun）、AWS（Firecracker 生态）都在独立构建各自的 Agent 沙箱运行时，这种割裂局面下，CNCF 主导的标准化（类似 OCI/CNI/CSI 对容器生态的规范化）是否会出现，还是 AI Agent 基础设施会长期碎片化？

📚 参考来源

GitHub - agent-substrate/substrate: Agent Substrate: the core system · GitHub