substrate
agent-substrate/substrate加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
你是否曾经想象过：在一个平台上同时运行上百万个 AI Agent，它们按需被唤醒、闲置时自动休眠，共享底层计算资源，就像一个超高效的「Agent 超市」？这正是 Google 正在做的事，而这个系统的名字就叫 Agent Substrate——一个专为 AI Agent 时代设计的开源基础设施项目。 Agent Substrate 架构图（图片源已失效）
想象一下传统 Kubernetes 的调度方式：你有一个 Web 服务，它会一直运行，直到你手动停止。但在 AI Agent 的世界里，情况完全不同。一个 Agent 可能 99% 的时间在等待用户输入或外部 API 响应，只有 1% 的时间在真正工作。如果每个 Agent 都占用一个独立的容器实例，那计算资源的浪费将是触目惊心的。
Agent Substrate 正是为解决这个问题而生。它构建在 Kubernetes 之上，但做了一件关键改造：把 Kubernetes 的控制平面从关键路径中移除。这意味着：Agent 的启动和切换不再需要等待 K8s API Server 的调度决策，而是由 Substrate 自己来完成——亚毫秒级的响应速度，可以同时管理数百万个 Agent 实例。
Agent Substrate 是 Google 开源的安全默认（secure-by-default）Agent 执行运行时，其核心目标是：以 10 倍于标准容器运行时的密度，在 Kubernetes 集群上运行数百万个沙箱化的 AI Agent 实例。
它最震撼的性能指标包括：
简单来说，Agent Substrate 的本质是一个高性能 Agent 调度层。它负责管理 Agent 的创建、销毁、挂起、恢复，以及在 Worker 节点间的路由，同时将 Kubernetes 的控制平面排除在关键路径之外，从而实现极低的延迟和极高的吞吐量。 Agent Substrate 扩展性架构（图片源已失效）
Substrate 的设计围绕两个核心概念展开：
Actor（角色）：即你运行的每一个 Agent 实例。它由一个 Actor 模板定义——包含镜像、命令和资源配额。每次创建新的 Actor 时，Substrate 会从模板构建一个快照，使 Actor 实例处于「已预热」状态，可以立即响应请求。
Worker Pool（工作池）：即 Substrate 管理的 Kubernetes Pod 集合。这些 Pod 是常驻的「热」节点，已经运行起来并等待任务。当 Actor 需要执行时，Substrate 实时将 Actor 打包到可用的 Worker 上；当 Actor 空闲时，将其挂起（snapshot）并释放 Worker。
这种设计的精妙之处在于：大量占用资源的 Agent 被压缩成快照状态存放在内存中，而 Worker Pod 始终保持活跃但只运行真正需要计算的部分。据 Demo 展示，一个约 250 个状态化 Actor 的注册表可以被「杂耍」般地复用到仅 8 个物理 Pod 上——30 倍的资源超售比。
Agent Substrate 由 Go 语言实现，这是 Google 内部项目的标准选择。Go 的并发模型（goroutine + channel）与 Substrate 需要处理大量并发挂起/恢复操作的场景高度契合。
从仓库结构可以看出项目的模块化设计：
cmd/：各二进制文件的入口（ateapi、atelet、atenet 等核心组件）pkg/：对外暴露的公共 API，供外部生态集成使用internal/：内部共享包，包括控制面 gRPC API（pkg/proto/）manifests/：Kubernetes YAML 部署清单demos/：完整的示例应用（counter、jupyter、sandbox 等）核心依赖栈：
构建系统使用 ko（Google 出品的容器镜像构建工具）和 Makefile，可通过 make build 一键构建所有镜像。
Substrate 不是一个孤立的项目，它已经成为了多个重要开源 AI Agent 项目的基础设施：
Agent Executor：Google Cloud 官方推出的分布式 Agent 运行时，直接构建在 Agent Substrate 之上，用于演示大规模 Agent 编排能力。官方博客指出，Agent Executor + Substrate 可以为当今最大规模的 Agent 部署提供基础。
kagent：CNCF Sandbox 项目，Kubernetes 原生的 AI Agent 框架，用于构建、部署和管理 AI Agent。kagent 使用 Agent Substrate 来运行沙箱化、有状态的 Agent 工作负载。
Nous Research Hermes：根据 Google Cloud 官方博客，Nous Research 的 Hermes Agent（OpenRouter 上排名第一的 AI Agent）正在基于 Agent Substrate 构建。这是对 Substrate 能力的最有力背书。
Agent Substrate 目前没有提供 Dockerfile 和 docker-compose 支持，部署主要依赖 Kubernetes manifests（YAML）和 Makefile。
官方推荐的部署路径是 Google Kubernetes Engine（GKE），Google 为 GKE 用户提供了专门的 substrate-gke 仓库，包含优化过的部署脚本和工具。对于非 GKE 环境，需要自行适配 manifests。
典型部署流程：
ko 工具构建容器镜像硬件要求方面，虽然 Agent Substrate 本身不需要 GPU，但需要足够规模的 K8s 节点来承载 Worker Pod。官方 Demo 中 8 个 Pod 运行 250 个 Actor，建议生产环境至少配置 8 核 CPU、16GB+ 内存的节点。
值得注意的是，Substrate 于 2026 年 9 月（数据采集时）处于 limited-GA 阶段，仅对部分 Google Cloud 客户开放生产支持，非 GKE 环境属于社区支持范畴。 Agent Substrate Demo 效果（图片源已失效）
Agent Substrate 并非万能药，它存在几个值得关注的局限：
运维复杂度高：作为 Kubernetes 原生的基础设施层，部署和维护需要专业的 K8s 运维能力。没有容器化和 docker-compose 支持意味着本地开发和测试门槛较高。
云厂商绑定：虽然 Substrate 支持多云（AWS S3 等依赖已集成），但官方工具链以 GKE 为最优路径，其他云厂商的 K8s 发行版需要额外适配工作。
生产支持受限：截至数据采集时（2026 年 9 月），Substrate 的生产级支持仍处于 allowlist 限定的 limited-GA 阶段，开源社区版本可能在文档和稳定性方面存在差距。
冷启动延迟：虽然 sub-500ms 的恢复速度已经非常出色，但对于需要极低延迟响应的交互式场景（如实时对话），Actor 的冷启动时间仍是需要考量的因素。
随着 AI Agent 从概念走向生产，一个核心矛盾正在浮现：如何在有限算力上运行海量 Agent 实例？
传统方式是将每个 Agent 部署为一个独立的容器或 Pod，但这意味着大量资源浪费在等待状态的 Agent 上。Agent Substrate 代表的「虚拟化 + 快照 + 池化」思路，正在成为这个问题的标准答案之一。
Google 的入局意义重大。作为 Kubernetes 的维护者，Google 比任何人都更了解 K8s 的能力边界和优化空间。Agent Substrate 展示了如何在对 K8s 核心改动最小的前提下，通过构建 Agent 专属的调度层来实现数量级的效率提升。
从更宏观的视角看，Agent Substrate 的出现标志着 AI Agent 基础设施赛道的竞争进入新阶段。在这个赛道上，我们已经看到了 Mesop（Google）、Dify、AutoGen（Microsoft）、CrewAI 等应用层项目，而 Agent Substrate 则在更深一层——它不是用来构建 Agent 的 SDK，而是用来运行 Agent 的操作系统。
如果你正在构建大规模 AI Agent 系统，或者对 Agent 基础设施的技术演进感兴趣，Agent Substrate 绝对值得密切关注。