Agent Substrate 正在走红，但其赌注取决于闲置算力

在 Google 工程师于 2026 年 5 月 20 日推出这一开源项目三个月后，Agent Substrate 登上 GitHub 热门榜第九位。该 agent substrate 承诺能够运行数量远超普通 Kubernetes 调度所能高效支持的有状态 agent。其核心赌注简单却影响深远：大多数 agent 的闲置时间足够长，基础设施可以回收其所占用的算力。

这一热门表现于 8 月 21 日通过 BettaFish 观察到。该日期对应的是排名快照，而非项目发布时间。Google Cloud 带日期的公告和仓库历史表明，实际发布期是在 2026 年 5 月。

这一差异很重要，因为该排名并非新产品发布的证据。它表明，一个实验性的基础设施理念重新获得了开发者关注。截至 8 月 26 日，该项目仍在频繁提交代码，包括涉及 worker 就绪状态、资源限制、身份、证书、遥测和 API 行为的改动。

Agent Substrate 并不与 LangGraph、Google 的 Agent Development Kit 或 OpenAI Agents SDK 竞争。这些工具帮助开发者定义 agent 行为。相反，Substrate 挑战的是这样一种假设：对于每一个活跃或休眠的 agent，Kubernetes Pod 都应始终是调度的基本单位。

这也使传统 Kubernetes 运维站在了论证的另一端。Kubernetes 仍负责机器、Pod、网络和容量。Substrate 则在这一基础之中插入了一个更快的控制平面，让 actor 在较小的就绪 worker 池中迁移。

这一机制在演示中颇具吸引力。生产就绪性则仍是另一个问题。

5 月的发布，而非 8 月的排名，才是关键事件

Agent Substrate 出现在热门榜上，反映出开发者对 Google Cloud 于 2026 年 5 月 20 日公开推出的项目日益关注。

Google Cloud 在宣布 GKE Agent Sandbox 正式可用时一并发布了该项目。该公司将 Agent Substrate 描述为一项开源工作，旨在提升超大规模 agent 部署的密度和响应速度。

根据 8 月记录的公开仓库元数据，该仓库在公告前不久创建。随后，开发工作持续整个夏季。截至 8 月 26 日，主分支已有 686 次提交，仓库还显示数百个 fork、issue 和 pull request。

这些数字持续变化，因此不应被视为永久性的采用指标。但它们表明，该仓库并非静态概念页面。贡献者正在积极修改其 API、安全组件、资源控制、存储集成和 worker 管理。

该项目的公开来源也需要谨慎表述。其仓库带有 Google 的版权信息，并在贡献者中列出多名 Google 工程师。Google Cloud 也通过官方公司博客介绍了它。

不过，项目仓库 明确表示，Agent Substrate 并非 Google 官方支持的产品。仓库还表示该项目仍处于非常早期的开发阶段。这些免责声明将一项开放工程工作与受支持的 GKE 服务区分开来。

当团队询问 Agent Substrate 在实际层面究竟是什么时，这一区别就变得更重要。它不是托管 agent 服务、模型，也不是用于编写 prompt 的框架。它是一个基于 Go 的控制平面，用于管理 Kubernetes 容量上的有状态容器化工作负载。

Google 将此次发布与一个具体的基础设施问题联系起来。其 5 月公告称，GKE 的 agent sandbox 在不足五个月内增长超过 16 倍。Google 还提到有客户部署了数百万个 agent，但未公布经独立审计的采用数据集。

同一份公告认为，未来的部署可能涉及数千万甚至数亿个实例。该数字描述的是 Google 预计该架构将要应对的规模，并不证实 Substrate 已经管理了这样的部署。

因此，8 月的排名代表第二个时点，而非第二次发布。随着其代码、演示和集成计划愈发具体，开发者似乎正在重新关注这个项目。

这种关注可以理解。许多 agent 系统同时具备长期存在的身份与短暂但昂贵的活动高峰。它们可能等待用户、外部 API、模型响应、审批或预定事件。

让每个等待中的 agent 始终绑定一个完全配置的环境会浪费容量。销毁该环境则可能丢失有用的进程状态，或让下一次交互变慢。Agent Substrate 试图占据这两种结果之间的狭窄空间。

新闻不只是又一个仓库走红。更有意义的变化在于，一个与 Kubernetes 相邻的团队公开了一套面向 agent 型工作负载的独立调度层。该项目将闲置时间视为可复用的基础设施容量。

为什么 Agent Substrate Kubernetes 调度将 Actor 与 Worker 分离

其核心设计选择是，将逻辑 agent 与恰好执行它的物理 Pod 分离。

在常规 Kubernetes 运维中，Pod 将共享网络和其他资源的容器组合在一起。调度器将这些 Pod 放置到节点上，而控制器则努力维持声明状态。

这一模型很适合持续运行的服务。agent 工作负载的行为往往不同。一个编程 agent 在编辑或测试时可能消耗大量 CPU，随后等待用户反馈数分钟。

Substrate 将长期存在的工作负载表示为 actor。actor 是逻辑应用身份，其状态和生命周期可在物理位置变更后继续存在。

Worker 是已就绪的执行环境，通常由 Kubernetes Pod 支撑。worker 可以在 actor 活跃时托管它，随后在暂停后为另一个 actor 腾出可用空间。

控制平面将 actor 分配给 worker、处理生命周期操作并引导流量。因此，agent 无须在每一段闲置时间内都占用专用 worker。

这种安排被称为多路复用，即让更多逻辑工作负载共享更少的物理资源。Substrate 的演示在八个物理 Pod 上部署了大约 250 个有状态 actor。项目将该结果描述为超过 30 倍的超额订阅。

该演示还展示了亚秒级 actor 激活，以及内存和文件系统状态的恢复。这些是项目在受控示例中报告的结果，而非独立的生产基准测试。

技术概览 表示，Substrate 支持 gVisor 和 microVM sandbox 技术。sandbox 可将不受信任的执行环境与主机及相邻工作负载隔离。

gVisor 路径可与标准 OCI 容器协作，后者是遵循 Open Container Initiative 格式的可移植容器镜像。因此，只要运行时需求符合所选 sandbox，Substrate 就能托管基于不同 agent 框架构建的应用。

这也是 Agent Substrate Kubernetes 支持不同于新 agent SDK 的原因。LangGraph 在框架层管理工作流和持久化应用状态。Google ADK 定义 agent、工具、会话和协调机制。OpenAI 的 SDK 则强调 agent、handoff、guardrail 和 tracing。

Substrate 位于这些抽象之下。它管理框架、工具服务器、代码解释器或终端会话运行所在的执行环境。

该架构保留 Kubernetes 负责基础设施配置。Kubernetes 仍会创建 worker Pod、管理节点、扩展容量并支持周边服务。

Substrate 将一些对延迟敏感的 actor 操作移出 Kubernetes 控制平面。其自身组件随后可以将 actor 放置到就绪 worker 上，而无需为每次激活创建新的 Pod。

这种差异类似于剧院预留舞台，而不是建筑公司为每场演出新建一座剧院。actor 保留身份和剧本。可用舞台则会随调度条件改变。

这个类比在状态问题上就不再成立，而状态正是难点所在。一个进程可能持有内存、打开的文件、凭证和网络连接。安全迁移它，远不止复制一个应用目录。

Substrate 使用 checkpoint 和 restore 机制来捕获进程和文件系统状态。快照可以转移到对象存储中，使 actor 休眠时所占算力得以回收。

后续请求会抵达网络路由器。如果目标 actor 已暂停，控制平面会选择一个 worker 并在流量继续前恢复该 actor。

仓库包含请求停放机制：当 worker 暂时饱和时，入站请求会等待，而不是立刻收到 HTTP 503 错误。仓库还提供持久化计数器、sandbox shell 执行、多模板、自动扩缩池和多路复用编程 agent 的示例。

这些部分解释了该项目为何吸引关注。它们将抽象的利用率论点转化为可识别的运行模型。尚未解决的问题是：当状态增大、故障重叠，以及众多租户不再彼此信任时，该模型是否仍能保持高效。

真正的对手是每个等待 Agent 一个 Pod

Agent Substrate 挑战的是静态资源所有权，而不是 Kubernetes 本身。

项目名称可能造成错误印象。Substrate 并非试图用一个完全独立的集群管理器取代 Kubernetes。其架构依赖 Kubernetes 来支撑快速 actor 生命周期周围的基础设施。

其主要对手是每个 agent 一个 Pod 的模式。在这种模式下，每个持久化 agent 即使停止了有用工作，仍会占用一个已调度的环境。

浪费程度取决于工作负载形态。持续运行的后台 agent 可能一直使用其分配资源，几乎没有可回收的闲置容量。面向用户的编程 agent 则可能在其生命周期的大部分时间保持不活跃。

当第二种模式占主导时，Substrate 的效果最佳。休眠 actor 与活跃 actor 的比例越高，共享 worker 池所能吸收的容量就越多。

这使闲置时间成为一类基础设施的一等信号。传统自动扩缩会观察 CPU、内存、队列或请求等指标。Substrate 还将 actor 生命周期状态视为调度输入。

Google 的发布公告称，agent 系统越来越多地等待人、工具和外部触发条件。该公司认为，这种行为既让高密度调度更有价值，也使其更具难度。

这一架构为多个群体带来压力。Kubernetes 平台团队必须决定 Pod 级调度是否仍然足够。agent 框架维护者则必须厘清应用状态止于何处、运行时状态始于何处。

云安全团队同样面临重要边界。多个彼此不信任的 actor 可以共享一个节点，并在较小的 worker 池中轮换。如果未能正确清理、隔离或恢复状态，一个 actor 的数据就可能暴露给另一个。

框架供应商不会从这个系统中消失。它们仍然掌控对话历史、工具选择、重试和业务逻辑。Substrate 处理的是另一种连续性：运行中的进程及其执行环境。

这种拆分可能造成状态重复。框架可能将会话存储在数据库中，而 Substrate 则在快照中保留内存和文件。运营团队需要制定规则，明确故障发生后以哪个版本为准。

设想一个编码智能体：它已克隆代码仓库、安装依赖、打开终端并启动测试。从镜像重建其环境可能耗时较长，也会丢弃尚未完成的进程状态。

当智能体暂停时，Substrate 可以挂起该环境。之后，它能够在另一台兼容的工作节点上恢复该 actor，同时保留终端和文件系统状态。

这一使用场景不同于简短的问答机器人。无状态机器人通常可以根据已存储的消息以较低成本重启。为其内存创建快照带来的复杂性，可能超过其实际价值。

同样的权衡也适用于 Model Context Protocol 服务器；这类服务器通过标准化接口向模型暴露工具和数据。有状态的 MCP 服务器可能受益于快速挂起，而简单的 HTTP 连接器则可能更适合作为常规服务运行。

因此，Agent Substrate 与 Kubernetes 并非一场非此即彼的竞争。该项目是在 Kubernetes 部署内部增加一个专门的控制循环。当智能体激活必须快于普通 Pod 启动，且空闲智能体数量多于活跃智能体时，它的价值就会提升。

当工作负载持续繁忙、易于重建，或已集中于高效的共享服务中时，它的价值则会下降。团队不应将每一次 LLM 请求都等同于有状态 actor。

这种更狭义的解读比将 Substrate 视作通用智能体平台更可信。它指出了一个承压的特定运营模式：将逻辑身份与专用算力绑定过久。

该项目也给托管沙箱提供商带来了压力。如果开放基础设施能够跨共享容量实现快速恢复，专有平台就需要在安全性、运维、开发者体验和服务保障方面给出更清晰的差异化价值。

不过，开源代码本身并不会消除运维成本。运行额外的控制平面会增加组件、API、证书、指标、快照和故障路径。利用率收益必须超过这些复杂性。

250-Actor 演示尚未证明什么

这项演示验证了一种机制，但尚未验证大规模生产环境下的经济性或隔离能力。

该仓库展示了约 250 个有状态 actor 在八个物理 Pod 上进行多路复用。它还宣称挂起和恢复操作可在亚秒级完成，并实现超过 30 倍的超额订阅。

这些结果支持了该项目的核心技术理念：逻辑工作负载可以离开某个工作节点、保留状态，并在之后返回，而无需在整个生命周期内独占一个 Pod。

该演示并未披露广泛的对比测量数据。它没有证明在不同内存规模、状态传输距离、嘈杂邻居、存储故障或持续流量下的性能表现。

仓库中的基准测试指南将其测试套件称为初期阶段。它包含负载生成和遥测相关工作，但项目尚未发布稳定且经过独立评审的基准测试系列。

这一缺口很重要，因为快照并非免费。捕获进程内存会消耗 CPU、存储带宽和时间。将其移至对象存储会带来网络流量和可变延迟。

恢复状态同样有成本。一个小型等待中的智能体可能恢复很快，而一个内存占用较高的编码环境可能需要传输更多数据。本地性决定了所需快照是否靠近被选定的工作节点。

路线图将增量快照、存储分层、数据感知调度和本地快照可见性列为尚未完成的优先事项。这些项目正是为解决可能削弱多路复用优势的成本问题。

突发模式带来了另一项考验。一个系统或许可以支持大量休眠 actor，直到某个共享事件同时唤醒它们。此时，工作节点池必须承接需求、排队请求，或扩展新的 Pod。

请求停放可以减少短暂饱和期间的即时错误，但无法创造容量。长队列仍会转化为用户可感知的延迟。

工作节点自动扩缩容可以增加容量，但这一过程会让 Kubernetes Pod 和节点启动重新进入关键路径。系统的快速路径最适用于已有足够多预热工作节点的情况。

这就形成了容量规划上的权衡。预热工作节点过多会削弱利用率收益；工作节点过少则会增加被停放的请求和唤醒延迟。

状态正确性是另一个悬而未决的问题。完整的进程恢复可以保留有用的上下文，但也会重新激活过时的假设。网络端点可能已经变化，凭证可能已过期，外部任务可能已经完成。

应用程序需要为这些情况设计恢复行为。恢复后的进程不能假定外部世界也随之暂停。

项目路线图称，actor 生命周期仍需进一步明确，包括哪些数据能够在升级后存续。它列出了多种可能的激活模式，从全新启动到完整内存恢复不等。

这是一个异常坦率的信号：最重要的语义仍在快速实现推进的同时持续确定。

路线图还列出了 A/B 发布支持、actor 克隆、更完善的授权、网络策略、审计日志和更广泛的可观测性。这些并非装饰性的企业功能，而是决定运营团队能否控制并解释共享运行时的关键能力。

安全性尤其值得谨慎看待。在许多配置中，gVisor 和 microVMs 比普通容器隔离提供了更强的工作负载边界。但它们的存在并不会自动保障整个系统的安全。

控制平面负责处理身份、路由、快照、凭证和部署位置。这些任一层出现错误，都可能以间接方式跨越沙箱边界。

Substrate 的威胁模型最后更新于 6 月 25 日。它记录了系统假设和信任边界，这是一个建设性的早期步骤。

路线图仍要求在共享同一节点的相互不可信 actor 之间建立两道安全边界。它还列出安全的 actor 间授权、凭证代理、审计日志和额外网络加固。

这些计划中的事项表明，安全方案仍在构建中。团队不应将“支持 gVisor”直接理解为“对所有敌对工作负载都安全”。

仓库免责声明进一步印证了这一解读。Agent Substrate 不是受支持的 Google 产品，其自身文档也将其描述为一个年轻项目。API 和运行假设都可能发生变化。

GitHub 活跃度可能造成一种误导性的成熟感。频繁提交代表的是发展势头，而非稳定性。一个快速演进的项目可以在技术上很严肃，同时仍不适合关键工作负载。

恰当的结论并不是这项演示毫无意义。它确实展示了该项目核心机制。缺失的证据关乎其边界、可重复性和运维成本。

安全性与状态决定 Agent Substrate 能否扩展

该项目只有在恢复后的 actor 仍能保持隔离、正确性，并且成本低于持续预留环境时，才能成功。

性能获得了最醒目的标题，因为亚秒级恢复和 30 倍超额订阅易于传播。更深层的工程工作则关乎身份和状态。

每个 actor 都需要一个能在工作节点间迁移后依旧稳定的身份。路由必须能够找到该 actor，同时不能向调用方暴露其之前或当前的物理位置。

凭证构成另一道边界。智能体通常需要访问代码仓库、数据库、云 API 或内部工具。将长期有效的秘密嵌入可迁移快照会增加风险。

路线图提出通过代理注入凭证，从而让加密密钥和 bearer token 远离 actor 进程。这项工作仍属于项目规划中的安全方向。

网络策略必须随 actor 一同迁移。如果一个 actor 被允许访问某项服务而不能访问另一项服务，更换工作节点不应改变这一授权。

Substrate 正在为入口流量、出口流量以及 actor 间通信构建身份感知控制机制。困难之处在于，必须足够快速地应用这些控制，才能保持低延迟目标。

快照也会成为敏感资产。它们可能包含内存、文件、环境数据、token 以及部分用户工作内容。运营团队需要加密、保留规则、访问日志和删除保障。

一个快照版本必须与恢复它的运行时保持兼容。升级 gVisor、内核或 actor 二进制文件，都可能使内存中记录的假设失效。

公开路线图直接指出了这一生命周期问题。它提出：运行时升级后应保留什么，以及应用程序应恢复内存、文件、两者兼有，还是两者皆不恢复。

这一选择会影响正确性。完整内存恢复可提供最强的连续性；保留工作文件但从干净的二进制进程启动，则提供了更易理解的恢复边界。

不同工作负载需要不同答案。交互式开发环境受益于进程连续性；金融工作流则可能需要根据经过审计的记录进行确定性重放。

Agent Substrate 的低主张设计将很大一部分决定权留给平台构建者。灵活性有助于该项目支持多种框架，但也将策略制定和测试责任转移给了运营团队。

可观测性必须遵循同一逻辑身份。即使 actor 在工作节点间迁移，其日志、指标和追踪信息也应保持关联。

该项目计划提供具有 actor 和工作节点标识符的 actor 感知遥测。这种关联对于调查延迟、恢复失败、意外网络访问和状态分歧至关重要。

对开发者而言，这带来了一个新的调试问题：故障是由智能体推理、框架编排、沙箱、快照恢复、存储、路由，还是工作节点分配造成的？

额外的基础设施层可以提升利用率，同时使故障更难定位。因此，高质量遥测属于基础架构的一部分，而不是可选的监控附加项。

团队还需要将持久的应用知识保存在进程内存之外。检查点可以保留工作会话，但不应成为决策、文档或已完成工作的唯一记录。

这一区分类似于一个可搜索知识库。运行时状态帮助智能体继续工作；持久知识则帮助人员和系统在运行时消失后验证发生过什么。

Substrate 模型最强的版本结合了两者。快速快照保留短期执行连续性；外部记录保存持久事实、权限和审计历史。

这种设计限制了恢复失败或不兼容恢复造成的损害。新进程可以从权威记录重建任务，而不是将易失内存视为永久真相。

该项目的长期意义取决于它能否将这些边界标准化。仅仅实现高效部署还不够。运营团队需要知道状态存放在哪里、谁可以读取它，以及哪个组件负责恢复。

三个信号将揭示关注是否转化为采用

下一阶段应以可复现的基准测试、已完成的安全控制措施，以及核心演示之外的真实集成为评判标准。

第一个信号是稳定的基准测试计划。Substrate 需要公布覆盖不同 actor 规模、空闲比例、激活突发情况、worker 数量、存储层级和故障条件的结果。

一套有说服力的基准测试，应在相同工作负载下，将 Substrate 与常规 Kubernetes 部署模式进行比较。测试应报告延迟分布、资源利用率、快照流量、错误率和运维开销。

平均恢复时间并不够。运维人员还需要了解尾延迟，包括最慢的常规激活情况。当少部分恢复耗时明显更长时，面向交互式 agent 的系统会让人感觉不够可靠。

基准测试还应区分本地恢复与远程快照传输。这一区分能够揭示调度器对数据本地性的依赖程度。

如果可重复的测试表明，随着内存规模和 actor 数量增长，激活延迟仍能保持较低水平，那么该项目的核心主张将更具说服力。如果性能在同步唤醒期间崩溃，其适用工作负载范围就会更窄。

第二个信号是安全性和生命周期语义方面的进展。默认拒绝的 actor 网络访问、凭据隔离、审计日志、授权机制和快照规则，都需要完成实现和测试。

若能针对运行时升级后的进程恢复给出稳定答案，将减少运维不确定性。明确的兼容性保证可帮助团队决定何时锁定版本，何时重建 actor。

安全审查应覆盖完整控制平面，而不只是沙箱机制。身份签发、路由、快照访问、证书轮换和 worker 清理都值得仔细审视。

独立部署报告将增强这一信号的可信度。报告应描述威胁假设、故障测试和修复行为，而不是重复功能声明。

第三个信号是外部集成。该仓库列出了与 Google ADK、LangChain、Agent Executor、MCP servers 和 actor-to-actor 协议之间计划中或开发中的连接。

可信的集成不应只是让 agent 在容器内启动。它还应保留身份、恢复状态、暴露遥测数据、处理取消操作，并在 worker 迁移后持续运行。

框架维护者还需要在应用检查点与基础设施快照之间建立清晰边界。缺少这一边界时，用户可能面临重复重试或相互矛盾的会话状态。

真正的采用将通过持续维护的集成、已记录的升级过程、生产事故经验，以及原始团队之外的贡献者体现出来。单靠 Star 数量无法证明这些结果。

项目活跃的提交历史让人对其执行速度保持审慎乐观。贡献者正在处理资源限制、证书轮换、worker 就绪状态、API 验证、遥测和存储行为等问题。

同样的活跃度也提示我们对稳定性保持谨慎。接口仍在变化，核心安全或生命周期功能仍停留在路线图上。

对于正在评估 Agent Substrate 是什么的开发者而言，其即时价值在于概念上的清晰度。有状态 agent 带来了一个调度问题，它既不同于无状态函数，也不同于持续运行的服务。

对于平台团队而言，该项目提供了这一理念的实验性实现。它展示了 actor、worker、快照和请求触发式唤醒如何构建在 Kubernetes 之上。

对于企业采购方而言，现有证据支持进行测试，而非直接假设其已具备生产就绪性。仓库中的免责声明、不断变化的 API 和未完成的控制措施，都应成为评估的一部分。

对于知识工作者和 AI 产品用户而言，基础设施问题会以间接方式显现。更高的资源利用率可以支持持久化 agent 会话，而无需为每位等待中的用户绑定专用算力。

只有当恢复过程始终快速且正确时，体验才会改善。一个会丢失上下文、暴露数据或延迟请求的低成本后端，并不会带来更好的 agent。

因此，未来一到三个月应回答三个具体问题：已发布的基准测试能否经受更具代表性的工作负载考验？安全控制措施能否从路线图条目变为经过测试的行为？外部项目能否持续维护有意义的集成？

如果这三个信号都得到强化，Agent Substrate 看起来将不再只是一次有趣的调度实验，而会更像一个独立的 agent 运行时层。

如果没有，它仍可能影响 Kubernetes 的设计，而不会成为标准部署选择。其 actor-worker 分离架构，已经为基础设施团队提供了一种描述空闲、有状态 agent 的有用方式。

第九名的趋势排名反映了开发者在某个特定时刻的好奇心。5 月的发布日期记录了实际事件。两者都无法证明最终结果。

agent substrate 的赌注，将在框架层之下决定：内存、身份、隔离和空闲容量在此交汇。开发者应关注这些机制、复现实验演示，并测试故障路径，再将这一趋势视为真正的采用。