前沿科技洞见 · 2026-07-31

Google Agent Substrate

正在发生的事很多，这件帮你看过了

2026年7月31日

7月30日，Agent Substrate 主仓库合入了一笔看似不起眼的改动：快照不再按 Actor 名称分目录存放，而是进入稳定路径；每个快照的 manifest 同时写入 atespace、Actor 名称、UID 和模板身份。即使控制面持久层不可用，快照也能说明「我是谁、由什么环境生成」。这不是一次产品发布，却碰到了 Agent Substrate 最难的一根神经——当上百万个智能体在不同机器之间睡眠、迁移和苏醒，状态能不能脱离某个控制面记录独立存活。

两个月前，Google Cloud 首次公开 Agent Substrate 时，讲的是一个很大的目标：让 Kubernetes 不再直接调度每个智能体，而只负责准备一批计算容量；另一个更轻、更快的控制面，在这些容量上调度数量远大于 Pod 的 Actor。官方演示把约 250 个有状态 Actor 复用到 8 个 Pod 上，超过 30 倍超额订阅。项目架构文档给出的远期指标更激进：单集群支持 10 亿个 Actor，唤醒延迟 P95 达到 100 毫秒，每秒处理 1000 次唤醒。

但同一份文档开头也写得很直白：大量架构仍是愿景，尚未实现；README 则用全大写提醒项目处于「VERY early development」，不能用于生产，也不是 Google 正式支持的产品。

这两组事实要放在一起看。Agent Substrate 现在还不是一套可以替换 Kubernetes 的成熟系统。它更像 Google 抛给云原生世界的一道命题：如果智能体是长期存在、绝大部分时间休眠、偶尔爆发执行、又必须保留内存和文件状态的计算实体，那么 Pod 还是不是合适的调度单位？

一句话定义

Google Agent Substrate 是一个构建在 Kubernetes 之上的开源 Actor 运行层：它把大量有状态智能体映射到少量预热、隔离的 Worker Pod，在请求到来时恢复快照并路由流量，在空闲时再次挂起，从而绕开 Kubernetes 控制面的关键路径。

它不是模型，不是 Agent SDK，也不是工作流编排框架。更准确地说，它试图成为 Agent Executor、ADK、LangGraph、Claude Code、Codex 或 MCP Server 之下的计算底座。

二、纵向分析：Pod 为什么装不下下一代智能体

1. 起点不是 Agent，而是「不信任容器里的代码」

Agent Substrate 的技术祖先可以追到 2018 年开源的 gVisor。

普通容器依靠 namespace、cgroup、seccomp 等 Linux 机制隔离进程，但容器内程序最终仍在调用宿主机内核。对可信微服务，这种成本与性能的平衡通常够用；对大模型临时生成、可能被提示词注入改变行为的代码，它留下的攻击面太大。gVisor 在应用和宿主内核之间放入一个用 Go 实现的用户态应用内核 Sentry，拦截并自行实现 Linux 系统调用，而不是把调用原样传给宿主机。

这条路线有一个影响至今的取舍。gVisor 比完整虚拟机轻，启动和资源伸缩更灵活；它又比普通容器多了一层隔离。但它并不完整实现所有 Linux 能力，系统调用密集型程序也可能支付性能代价。于是，Google 后来做 Agent 基础设施时没有押注「一种沙箱统治所有场景」，而是把 gVisor 当成默认强项，同时给 Kata Containers、microVM 留出插件接口。

这个早期选择塑造了 Agent Substrate 的性格：它不是另造一个云，而是在 OCI 容器、Kubernetes 和既有安全运行时之间加一层专门调度。

2. Kubernetes 的成功，反过来变成了约束

Kubernetes 把 Pod 定义为最小可部署计算单元。围绕它，Deployment 处理可替换的无状态副本，StatefulSet 处理带稳定身份和存储的有状态副本，Job 处理一次性任务。这个模型的力量来自一致性：声明一个目标状态，控制器、调度器、kubelet 和网络组件经过若干异步过程，最终把 Pod 运行起来。

问题在于，Agent 的时间形态和传统服务不同。

一个客服服务可能连续运行几个月，每秒处理请求。一个编程 Agent 可能存在数天，却在等待模型响应、等待 CI、等待用户确认时长期不动；真正占用 CPU 的片段只有几秒。若每个会话固定对应一个 Pod，空闲进程仍占内存、Pod 配额、IP 和控制面对象。若每次调用都新建 Pod，调度、拉取镜像、挂载存储、配置网络带来的秒级开销，又可能比工具调用本身更长。

规模差距也不是修辞。Kubernetes 当前的大集群设计参考上限包括单集群 15 万个 Pod、每节点 110 个 Pod。Agent Substrate 文档讨论的却是数亿注册 Actor，远期目标甚至是 10 亿。把每个 Actor 表示为 Pod 或 CRD，不只是贵，而是对象数量和高频状态写入都会压到 kube-apiserver、etcd 和控制器的设计边界。

换到云原生的语言里，Kubernetes 擅长管理「数量相对有限、寿命较长、状态变化不太频繁」的对象；Agent Substrate 要管理的是「数量极大、寿命很长、活跃片段极短、位置频繁变化」的对象。它们都叫 workload，时钟却完全不同。

3. 2025 年：Agent Sandbox 先解决「一人一间安全房」

Google 没有直接跳到新的控制面。2025 年 11 月，GKE Agent Sandbox 在 KubeCon North America 进入预览。它后来进入 Kubernetes SIG Apps，形成 kubernetes-sigs/agent-sandbox 项目。

Agent Sandbox 引入 Sandbox CRD：一个沙箱有稳定身份、持久存储和生命周期控制，背后通常还是一个 Pod。SandboxTemplate 负责复用环境定义，SandboxClaim 让用户申领沙箱，SandboxWarmPool 预先启动一批环境，避免每次请求都冷启动。它把以前由平台团队手工拼装的 Pod、PVC、网络策略和回收逻辑，整理成「长时间存在、单实例、有状态、可隔离」的标准对象。

这一步解决的是管理问题。开发者不必把编程 Agent 生硬塞进 Deployment，也不必自己维护一套沙箱控制器。到 2026 年 5 月 GA 时，Google 披露 GKE 上的沙箱使用量在不到五个月里增长超过 16 倍，LangChain、Lovable 等客户已经在部署大量 Agent。7 月发布的 Agent Sandbox v0.5.2 又继续修补 warm pool 申领、冷重启和 WebSocket 路由，并提供 gVisor、Windows、Aider 等示例。

不过，Agent Sandbox 没有消除「一个活跃沙箱对应一个 Pod」这层关系。Warm pool 只是提前把房间准备好，空房仍然存在。若要在一个集群里保存几百万个大部分时间无人的房间，Kubernetes 对象和计算资源都会被拖住。

Agent Sandbox 因而不是 Agent Substrate 的失败前身。前者把安全、有状态的单体工作负载做成 Kubernetes 可以理解的对象；后者从它那里继承安全运行时与快照，再进一步追问：房间能不能保留，楼却不用一直为它占着？

4. 2026 年 5 月：Actor 与 Pod 正式脱钩

2026 年 5 月 13 日，Agent Substrate 代码仓库创建。5 月 20 日，Google Cloud 同时宣布 GKE Agent Sandbox GA、Agent Substrate 和 Agent Executor。

三个项目在发布时被有意放进同一幅图里：

Agent Sandbox 管理隔离环境，是安全执行层。
Agent Substrate 管理 Actor 到计算容量的映射，是计算与调度层。
Agent Executor（AX）管理事件日志、单写者状态、断线重连、轨迹分支和分布式执行，是上层运行时。

这是一次边界划分。AX 知道一个 Agent 正在做什么、进度走到哪里；Substrate 不理解推理语义，只知道某个 Actor 该被唤醒、放到哪个 Worker、从哪份快照恢复；Kubernetes 只负责 Worker Pod、节点、网络与容量。上层可以换模型和框架，下层仍能工作。

Agent Substrate 的核心抽象也由此出现。

ActorTemplate 是不可变环境模板，描述 OCI 镜像、内存、行为参数和快照设置；Actor 是某个具体实例，有自己的身份、状态与最新快照；WorkerPool 定义预热计算池；Worker 对应池内一个可承载 Actor 的 Pod。Actor 可以是 RUNNING 或 SUSPENDED，Worker 可以是 IDLE 或 BUSY。两者不再一一永久绑定。

请求进入时，atenet 路由器先判断目标 Actor 是否已经运行。若它在休眠，专用控制面 ate-api-server 从低延迟状态存储中选择空闲 Worker，节点侧 atelet 拉取最新快照，ateom 通过 gVisor 或 microVM 后端恢复进程，随后流量才被转发进去。Actor 空闲后，系统保存内存与文件系统状态，释放 Worker 给下一个 Actor。

官方演示的 250 个 Actor 对 8 个 Pod，就是这个逻辑最直观的样子。30 倍并不是每个 Actor 同时运行时凭空多出算力，而是利用「绝大多数 Actor 此刻正在等待」进行时间复用。它更像航空公司超售座位：统计上多数旅客不会同时出现；真正难的不是卖出更多票，而是高峰时怎么排队、何时加运力，以及不能把两位旅客的行李拿混。

5. 为什么要自建一个小控制面

如果每次唤醒仍要创建或更新 Kubernetes 对象，Agent Substrate 就只剩一组新名字。它最激进的决定，是把动态 Actor 状态移出 Kubernetes API。

环境配置仍走熟悉的 CRD。WorkerPool 和 ActorTemplate 由 Kubernetes 保存，平台团队可以继续使用 RBAC、审计和声明式配置。高频的实例状态则进入专用数据库，目前是 Valkey/Redis：Actor 在哪台 Worker、当前是运行还是休眠、最新快照指向哪里，都由 ate-api-server 管理。

这是一种双层控制面。Kubernetes 管慢变量——节点、Pod 池、环境模板；Substrate 管快变量——Actor 的位置和生命周期。

好处很清楚。恢复路径不用等待多个 Kubernetes 控制器最终收敛，也不用让 etcd 接收每秒成千上万次 Actor 状态变化。代价同样清楚：Google 得重新实现一套需要高可用、认证授权、原子调度、故障恢复与审计的控制面。Kubernetes 二十年的工程复杂度没有消失，只是从通用系统里切出一段，要求新项目单独偿还。

这也解释了为什么架构文档的目标是 P95 100 毫秒，而 README 演示只承诺「亚秒级」。100 毫秒是北极星，不是已经公开验证的生产成绩；10 亿 Actor 与每秒 1000 次唤醒同理。现有 benchmark 目录仍被项目自己称为 nascent，只提供 Locust 压测框架，尚未给出足以复核这些远期指标的结果。

6. 快照从优化手段变成系统事实

传统容器平台里的快照常用来缩短冷启动：把初始化后的内存保存下来，下次少跑一遍依赖加载。到了 Agent Substrate，快照同时承担四个职责。

一是资源回收。Actor 的内存与文件系统落到对象存储后，Worker 可以让给别人。二是会话连续性。终端进程、工作目录和中间变量在恢复后仍存在。三是迁移。Actor 不必回到原 Worker，可以在另一节点恢复。四是执行分支。路线图提出从一个「State Root」克隆新 Actor，让同一推理轨迹在不同分支上试验。

职责越多，问题越难。快照有多大？每次保存全量还是增量？放本地 SSD、同节点压缩内存、邻近节点，还是对象存储？恢复时是把计算移到数据旁边，还是把数据搬到空闲计算？gVisor 升级后旧内存镜像是否仍兼容？一个 Actor 的恶意快照能否污染下一位租户？

项目路线图已经把本地 zswap、SSD、点对点复制、对象存储分层、增量快照、数据局部性感知调度列为待办。7月30日那笔提交，则先解决更基础的可识别性：稳定路径避免 Actor 名称直接成为存储布局；manifest 携带 Actor 和模板身份，让快照不完全依赖控制面数据库才能解释。

我的判断是，Agent Substrate 真正的壁垒不会是「能 suspend/resume」。E2B、Modal、AWS 和虚拟机技术早已证明这件事可做。壁垒会是快照目录、身份、版本、数据局部性、迁移和恢复协议能否组合成一套跨节点、跨运行时、可审计的状态系统。

7. 7 月的工程变化：开始补「拥堵时怎么办」

早期架构最容易演示的是顺畅路径：Worker 有空位，Actor 恢复，调用成功。生产系统更常见的问题是，流量突然同时唤醒大量 Actor，WorkerPool 暂时没有空位。

Agent Substrate 新增的 request parking 没有立即返回 503，而是在 atenet 里暂存请求，等待其他 Actor 挂起并释放 Worker。默认停车场最多容纳 1024 个请求，预算 5 秒；同一 Actor 的并发唤醒会通过 singleflight 合并成一个控制面调用。停车场满了，系统明确丢弃后续请求，避免无限排队拖垮路由器。监控则区分成功服务、预算耗尽、客户端取消、超时和非重试错误。

这类细节比 10 亿规模口号更能说明项目在向哪里走。超额订阅成立的前提，是活跃率可预测且高峰可以被吸收。Request parking 把偶发容量不足转换成可度量的等待，但没有创造新容量。若大量 Actor 同时苏醒，5 秒后仍然是 503；若把停车预算无限拉长，路由器和客户端连接又会成为新的瓶颈。

同一时期，路线图里仍有不少硬缺口：Worker 自动扩缩、控制面用户授权、Actor 级网络 ACL、mTLS、凭据代理、审计日志、跨运行时兼容、数据局部性、增量快照都在「Coming Soon」。威胁模型更直白地列出共享 Worker 残留状态、凭据泄漏、恶意镜像资源耗尽、通过 suspend/resume 横向移动、节点越权读取全量快照等风险。

所以 Agent Substrate 目前最准确的阶段判断不是「发布期」，而是架构验证期进入可靠性补课期。它已经有可运行的主路径、多个 demo、约 400 次提交和外部贡献；但生产系统所需的身份、安全、扩缩与故障模型还在成形。

三、横向分析：它和谁竞争，又不和谁竞争

Agent Substrate 的直接竞品并不整齐。它既碰到 Kubernetes 的通用调度边界，也碰到云厂商的托管 Agent Runtime，还与 E2B、Modal 这样的沙箱云重叠。把它们放在一张「功能打勾表」里，会掩盖各自真正卖的东西。

1. 原生 Kubernetes：可靠的城市规划，不负责瞬时换房

原生 Kubernetes 的优势不是唤醒一个 Agent 有多快，而是组织已经围绕它建立了权限、网络、镜像、审计、可观测性和运维能力。Agent 若是数量有限、持续运行、资源利用率高，直接使用 Deployment、StatefulSet 或 Job 往往更简单。平台团队能看见每个 Pod，故障模型成熟，工具链也最完整。

短板正是 Agent Substrate 的出发点。Pod 是最小调度单位，每次创建都要经过通用控制面的异步流程；一个 Pod 对一个长期会话，会为大量空闲状态支付资源与对象成本。Kubernetes 官方建议的大集群范围与十亿 Actor 之间相差四个数量级以上。

因此，Agent Substrate 没有替代 Kubernetes。它把 Kubernetes 从「调度每个 Agent」降到「供应一池 Worker」。这能保留云原生资产，也会制造新的运维分界：排查一次请求时，工程师要同时追踪 Actor 身份、Substrate Worker 映射和底层 Pod。可观测性如果跟不上，抽象层越漂亮，事故现场越难看懂。

2. Kubernetes Agent Sandbox：一间房与一张房卡

Agent Sandbox 与 Substrate 最容易被混淆，因为两者都由 Google 推动、都使用 Kubernetes、gVisor 和快照。

Agent Sandbox 的核心价值是为单个有状态沙箱提供稳定身份和声明式生命周期。它保留 Pod 作为主要对象，WarmPool 提前准备实例，API 已进到 v1beta1，GKE 产品也已经 GA。对于几百到几万并发环境、强调 Kubernetes 原生治理的团队，它更接近今天可以采用的方案。

Agent Substrate 的价值是复用。Actor 不是 Pod；空闲 Actor 只留下状态，活跃时才占一个 Worker。它瞄准的是 Sandbox 继续放大后必然遇到的 Pod 数量、内存和唤醒延迟问题。

二者不是二选一。Agent Sandbox 提供隔离和快照能力，Substrate 在其上做密集调度。真正的产品风险在于边界会不会长期稳定：未来 Sandbox 自己加入更强复用，或者 Substrate 为了性能绕过更多 Kubernetes 机制，两套 API 都可能变化。今天就押注的用户，承担的不只是软件 bug，还有概念边界重画带来的迁移成本。

3. AWS Bedrock AgentCore：把控制面复杂度藏起来

Amazon Bedrock AgentCore Runtime 选择了另一条路线：每个用户会话进入独立 microVM，CPU、内存和文件系统隔离；同一个 session ID 会被路由到同一环境。默认空闲 15 分钟后停止，单次计算生命周期最长 8 小时；配置 session storage 后，文件可以跨停止与恢复保留。AgentCore 同时提供 Memory、身份、工具和可观测性，用户按托管服务方式消费。

用户选择 AgentCore 的真实理由，是不想自建 ate-api-server、快照存储、路由器和安全边界。金融机构若已经把身份、审计和网络控制放在 AWS，AgentCore 的一体化比开源自由更有吸引力。它的专用 microVM 也给出了容易解释的租户隔离边界。

代价是控制权和可移植性。会话生命周期、配额、持久目录、运行接口都服从 AWS 产品边界；「一会话一 microVM」强调隔离，并不公开承诺像 Substrate 那样把数十个休眠 Actor 复用到少量 Worker。Substrate 反过来允许自有集群、自选模型、自选 harness 和运行时，但安全与运维责任也一并回到用户。

两者争夺的不是同一种工程团队。AgentCore 卖「替你把复杂度吃掉」，Substrate 卖「复杂度留给你，但标准和控制权也留给你」。

4. Azure Container Apps Dynamic Sessions：预热池优先，状态让位

Azure Dynamic Sessions 同样从预热池解决启动延迟。每个 Session 运行在 Hyper-V 隔离环境里，新请求从 pool 里立即分配一个已经准备好的容器，适合执行模型生成代码、自定义容器和短时 Agent。空闲超过 cooldown 后，Session 被销毁，资源自动清理。

它与 Agent Sandbox 的亲缘关系比与 Substrate更近：先准备安全房间，请求来了就发房卡，用完销毁。优点是产品语义简单、毫秒级分配、与 Entra 和 Azure Container Apps 集成；短板是 Session 被设计成临时环境，跨长时间休眠保存完整内存与文件状态不是主轴。

若任务是「为每次对话安全执行几段 Python」，Azure 的设计更直截了当。若任务是「一个编程 Agent 存在数周，保持终端、进程和工作目录，却每天只活跃几分钟」，Substrate 的 Actor 身份与全状态快照更贴近问题。

E2B 把 Firecracker microVM 包装成面向 Agent 开发者的 Sandbox API。它支持保存文件系统和内存，pause 后可用同一 sandbox ID 恢复，也支持从一个快照创建多个新沙箱。官方文档给出的典型恢复时间约 1 秒，暂停每 1 GiB 内存约 4 秒；Pro 层单次连续运行最长 24 小时，暂停状态可长期保存。2026 年新增 auto-resume 后，请求可以自动唤醒休眠沙箱。

这已经覆盖了 Substrate 很多表面能力。E2B 的优势是开发体验：几行 SDK 就能创建、执行、暂停和恢复，不需要先理解 WorkerPool、ActorTemplate、Valkey、Envoy 与 CRD。Firecracker microVM 的隔离边界也比默认 gVisor 更符合某些安全团队的直觉。它还提供 BYOC 和自托管选项，削弱了「开源才有主权」的简单叙事。

Modal Sandboxes 则把安全容器、镜像、持久 Volume、文件系统快照和按秒计费放进同一个计算平台。内存快照主要优化冷启动，文件系统快照可以生成新 Sandbox；超过 24 小时的任务建议通过快照延续。Modal 的长项是与函数、GPU 和批处理能力共享一套开发与调度体验，而不是专门建立 Actor 控制面。

E2B 和 Modal 的用户通常先问「SDK 好不好用、启动快不快、价格多少」；Substrate 的用户先问「能否运行在我的 Kubernetes、身份和网络策略能否自定义、规模上限由谁控制」。前者已经提供产品化体验，后者试图提供可以被许多产品采用的公共底层。

这也是 Agent Substrate 最危险的竞争面。它如果只做到 suspend/resume，会被成熟沙箱云的 API 和运营经验压住；它必须证明专用 Actor 调度、数据局部性和跨框架开放性，在大规模下能产生普通沙箱服务做不到的数量级优势。

6. 当前生态位：不是「Agent 的 Kubernetes」，而是 Kubernetes 的 Actor 扩展

Google 在发布文章里有意召回 Kubernetes 早期的开放协作故事，外界也很自然地把 Agent Substrate 称为「Agent 的 Kubernetes 时刻」。这个比喻有传播力，却容易把层级说反。

Kubernetes 当年统一的是容器集群的声明式管理接口。Agent Substrate 当前没有统一 Agent 的语义、协议、记忆、工具或评测；它甚至刻意保持低意见，只管理 Actor 的运行状态。它依赖 Kubernetes 提供节点和 Pod，也依赖 gVisor 或 microVM 提供隔离。

所以它更像一个新型 kubelet 加专用调度面：把「Actor」引入 Kubernetes 之上，但不把它变成 Kubernetes 原生对象。若成功，它可能成为 E2B、企业内部 Agent 平台、编程环境甚至 MCP 托管服务的共同组件；若失败，它也可能只是 Google Agent 技术栈里一套过早暴露的实验实现。

四、横纵交汇：Google 真正在赌什么

1. 历史决定了它为什么不另起炉灶

从 gVisor 到 Kubernetes，再到 Agent Sandbox，Google 已经拥有隔离内核、容器编排和有状态沙箱三层积累。Agent Substrate 选择「绕开 Kubernetes 关键路径，但不绕开 Kubernetes」，不是保守，而是历史资产推出来的最自然路线。

它今天的三个优势都能找到来路。

第一，运行时可插拔来自 gVisor 与 OCI 兼容传统。项目默认用 gVisor 做快速快照，也正在支持 microVM，不必把上层框架绑死在某种沙箱。第二，治理兼容来自 Kubernetes。模板和 WorkerPool 继续走 CRD，企业可以保留现有集群能力。第三，开放生态来自 Agent Sandbox 与 Kubernetes SIG 的社区经验。仓库采用 Apache 2.0，Google 同时让 AX 支持 ADK、LangGraph、A2A 与自定义 Agent，试图让底层先于上层框架形成公共接口。

它的劣势也来自同一段历史。

为了兼容 Kubernetes，系统多了一层 Actor—Worker—Pod 映射；为了追求极限延迟，又必须绕开 Kubernetes 控制面，自建另一套状态和授权系统；为了支持 gVisor 的轻量恢复，要承受系统调用兼容性与共享节点风险；为了开放给多种 runtime，快照格式、升级兼容和安全不变量就更难统一。

当初每个「不要重造」的好决定，叠在一起后，都可能变成跨层调试的包袱。

2. 竞争的分水岭不是模型，而是空闲状态归谁

过去两年，Agent 平台竞争常围绕模型选择、工具协议、记忆库和工作流框架展开。Agent Substrate 把问题向下压了一层：Agent 等待人类、模型或外部系统时，它的状态由谁保管，计算资源由谁回收，下一次请求由谁把两者重新拼起来？

原生 Kubernetes 的答案是让 Pod 继续活着，或用外部数据库重建应用状态；Azure Dynamic Sessions 的答案是销毁临时环境；AWS AgentCore 的答案是托管 microVM 会话与独立持久服务；E2B 的答案是保存 microVM 的内存和磁盘；Substrate 的答案是把快照当成可迁移的 Actor 状态，把 Worker 当成随时可替换的座位。

这不是一个小实现差异。谁掌握休眠状态，谁就掌握 Agent 的续跑、迁移、分支、回滚、审计与成本计算。模型调用可以跨供应商，完整执行状态却最容易把用户锁在某个运行时里。

Google 把 Substrate 和 AX 同时开源，就是在提前争夺这一层标准。AX 的事件日志告诉系统「逻辑执行到哪里」，Substrate 的进程快照告诉系统「机器执行到哪里」。两者结合，才可能让一个长程 Agent 在断线、换节点甚至换部署环境后继续工作。

3. 30 倍密度只是演示，数据运动才是经济账

超额订阅把空闲内存释放出来，表面上是明确收益。但每次睡眠和唤醒都会制造存储 I/O、网络传输与 CPU 开销。E2B 公布的暂停速度约为每 1 GiB 4 秒，已经提醒我们：内存越大的 Agent，保存状态越不像一次轻操作。

如果一个 Actor 只睡 500 毫秒，快照再恢复可能比保持运行更贵；如果它睡数小时，释放资源几乎一定划算。系统必须预测空闲时长，决定是否挂起、保存哪些层、放到哪一级存储。若每次都把几 GiB 快照搬过网络，30 倍计算密度可能被对象存储费用和恢复延迟吃掉。

这就是数据局部性会进入调度核心的原因。未来的调度器不只是寻找空闲 CPU，还要计算「哪个节点已经有这份快照」「搬状态还是等原节点」「本地缓存是否可信」「快照是否与当前 runtime 版本兼容」。

我的判断是，Agent Substrate 若能成功，最有价值的成果可能不是 Actor API，而是一套面向休眠计算的状态分层和调度算法。那套能力也不只服务 AI Agent，还能用于云开发环境、交互式 Notebook、游戏会话和任何高数量、低占空比的有状态 Actor。

4. 安全账比资源账更难

同一个 Worker 先后承载互不信任的 Actor，是 Substrate 获得密度的来源，也是风险集中的地方。

项目威胁模型提出「同节点的互不信任 Actor 之间要有两道安全边界」，并计划默认禁止网络、使用 mTLS、让凭据代理代替把 bearer token 暴露给 Agent、在 Actor 切换时清理本地策略和残留状态。这些都还没有完整落地。

快照进一步扩大攻击面。一份内存镜像可能包含 API 密钥、用户数据和模型上下文；节点若能读取整个集群的快照，单机失陷会变成全局泄漏；恶意 Actor 还可能篡改自己的快照，在恢复时获得更高权限。7月30日加入自描述 manifest 有助于追踪身份，却不等于完成签名、加密、授权和防回滚。

因此，金融机构现在不应把 30 倍密度直接代入成本模型。先要证明四件事：快照静态与传输加密是否满足内部标准；节点权限能否限制到当前调度 Actor；Actor 切换后内存、网络和凭据是否彻底清理；生命周期和 API 操作能否进入不可抵赖的审计日志。项目路线图仍把其中多项列为待办。

5. 三个未来剧本

最可能的剧本：成为高阶平台的可选加速层

未来 12 至 24 个月，Agent Substrate 不会取代 Kubernetes，也不会让普通企业直接部署十亿 Actor。更可能的路径是：Agent Sandbox 继续承担稳定、可治理的默认方案；Substrate 在编程 Agent、长时研究 Agent、托管 MCP 和大规模多租户环境中作为实验性高密度后端，被少数有平台工程能力的团队采用。

项目会先把 Worker 自动扩缩、Actor 级身份与网络策略、增量快照和可观测性补齐，再用更可信的 benchmark 证明在哪些占空比、内存规模和调用模式下确实省钱。AWS、Azure、E2B 和 Modal 也会继续加入暂停、恢复和持久状态能力，差异不会消失，但会从「有没有」变成「谁能以多低成本跨多大规模可靠运行」。

这个剧本下，Substrate 类似早期的高级 Kubernetes 扩展：重要、影响标准，却主要由云平台、Agent 云和大型企业平台团队直接操作。

最危险的剧本：控制面与快照复杂度吞掉密度收益

项目可能在 demo 规模表现漂亮，一到生产就遇到三连锁：流量相关性让大量 Actor 同时苏醒，WorkerPool 频繁饱和；大快照跨节点搬运拉高尾延迟；新的控制面、路由和身份层让故障定位变慢。为了安全，企业改用每会话独立 microVM 和更严格的节点隔离，原本的超额订阅率随之下降。

与此同时，托管服务把类似能力做进现有产品。用户通过 E2B 或 AgentCore 几行 API 获得暂停、恢复、持久文件和审计，不愿意维护 Substrate。Google 自己若不能把开源项目转成受支持的 GKE 能力，README 那句「非正式支持产品」会长期阻挡严肃采用。

这个剧本最危险的地方不是项目停止，而是它停在「很好的技术样板」：概念被行业吸收，生产工作负载却流向别人的托管实现。

最乐观的剧本：Actor 成为云原生计算的新一级抽象

若 Google 和社区把快照格式、Actor 身份、路由、数据局部性和安全策略做成可移植接口，Agent Substrate 可能获得真正的 Kubernetes 时刻——不是替代 Kubernetes，而是在 Pod 之上确立一个被多家云、框架和沙箱服务共同采用的 Actor 层。

那时，开发者声明的不是「运行这个 Pod」，而是「这个 Actor 有稳定身份、可休眠、可迁移、可分支，唤醒延迟与状态保留策略如下」。底层可以选择 gVisor、Kata、Firecracker 或其他 microVM；上层可以是 AX、LangGraph、ADK 或尚未出现的框架。云厂商竞争执行效率，用户保留状态和身份的可移植性。

Google 的优势是它同时站在模型、Agent 框架、协议、Kubernetes 和云基础设施几层上。它的约束也在这里：如果开放接口只是引流到 GKE，其他厂商没有动力共建；如果真正保持中立，Google 又要接受价值被上层和其他云分走。

6. 最后的判断

Agent Substrate 最值得关注的，不是「Google 又开源了一个 Agent 项目」，也不是演示里的 30 倍密度。

它把一个被模型进步遮住的问题摆到了桌面上：长程 Agent 不是一次 HTTP 请求，也不是一台永远开机的服务器。它更像一个会睡眠的进程，身份持续存在，计算间歇发生，状态必须迁移。用 Pod 表示它，就像给每位偶尔来办公室的人永久保留一栋独立房子；只保存数据库记录，又会丢掉终端、内存和执行现场。

Google 的答案，是把「人」和「房」拆开：Actor 保留身份与状态，Worker 只在需要时承载计算，Kubernetes 管楼宇，Substrate 管入住与搬家。

7月30日那笔快照提交之所以是一个合适的观察窗口，正在于它把宏大叙事拉回到工程地面。十亿 Actor 的故事最终不会由发布会决定，而会由一份快照在控制面失灵后还能不能说明自己是谁、能不能被正确授权、能不能在另一台机器上安全醒来决定。

现在，这个答案仍在代码里生长。

信息来源

内容由AI辅助生成，请谨慎甄别。资讯分享仅供参考，相关观点不代表主观立场，不构成任何形式的投资建议。