Kubernetes 统治容器十年后，谷歌的 Agent Substrate 想接管 agent 时代的执行层

Kubernetes 统治容器十年后谷歌的 Agent Substrate 想接管 agent 时代的执行层【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrate十年前Kubernetes 用Pod 控制器 声明式 API重新定义了服务器的使用方式把一个又一个容器编排问题标准化最终成为整个云计算行业的基础设施层。但当 AI Agent 从 Demo 走向规模化部署时一个尴尬的事实浮现出来Agent 这种负载天生就不是为 Pod 设计的。Agent 大部分时间在等待——等 LLM 返回、等工具调用结果、等用户输入——真正干活的窗口可能只有几毫秒到几秒而等一个 Pod 被调度、拉镜像、启动完成常常就要几十秒。更麻烦的是Agent 运行的是不可信代码必须在沙箱里单租户运行于是成千上万个长期占坑、偶尔醒一下的沙箱变成了纯资源黑洞。谷歌开源的 Agent Substrate本仓库即其核心系统给出的解法很直接承认 Pod 不再适合当 agent 的执行单元用可挂起/恢复的沙箱 Actor把它替换掉同时继续让 Kubernetes 管底层基建。本文结合仓库源码拆解这套执行层重构背后的设计逻辑、组件拼图与代价。从容器到 agent执行单元为什么从 Pod 变成沙箱 ActorAgent 负载的三个特征恰好都是 Pod 模型的短板docs/architecture.md把 agent 类负载的问题描述得很直白它们非常突发bursty大部分时间在等输入或事件处理完又回到等待且由于经常运行不可信逻辑通常运行在沙箱中因此大多是单租户实例而且数量极其庞大。把这三个特征叠加到 Kubernetes 上每一处都是错配空闲 Pod 依然占资源。Kubernetes 很能伸缩但 CPU、内存、单节点 Pod 数量都是实打实的成本。Agent 应用恰恰是效率最差的负载类型——为偶尔几秒的干活长期占着一整份 Pod 资源。API Server 不是为百万资源设计的。它擅长异步协调大量控制器却不擅长存储海量离散资源、承接超高写入流量。百万级 Agent 意味着每秒上千次状态变更etcd 支撑不了这种写放大。调度延迟不可接受。在 Kubernetes 上拉起一个 Pod需要多个异步流程收敛、若干网络跳转、镜像拉取加起来动辄数秒。Pod 跑几小时时这个开销无所谓但一个只运行毫秒到个位数秒的负载这个延迟是致命的。状态管理是另一个量级的难题。PersistentVolume 模型不是为百万个、数据量差异极大、需要高速挂载/卸载的卷设计的。docs/architecture.md的结论是需要一个专门的 Agent Substrate 控制面来处理 Actor 的高频、低延迟控制而把worker Pod 的供应与工作负载隔离这些 Kubernetes 擅长的事继续留给它。Actor/Worker 分离用挂起换密度Substrate 的核心抽象是把更多 Actor应用比如 agent映射到更少的就绪 Worker 上依据正是agent 类应用大部分时间空闲这一事实。它的做法是预启动 Worker先拉起一批长期存活的 worker Pod它们就是等待工作的沙箱绕开了 Kubernetes 调度延迟挂起 ActorActor 空闲时对其实施 suspend释放它占用的全部资源流量唤醒事件到来时由网络层拦下请求把 Actor 指派给某个空闲 worker从其最新快照恢复然后转发流量跨 worker 迁移下次再唤醒时Actor 可能落在另一个 worker 上状态通过快照完整迁移。仓库里把这套能力沉淀为三个可复现的 demo 要点Actor Teleport亚秒级挂起/恢复、State Persistence内存与文件系统状态跨休眠周期完整保留、以及30 倍以上超分复用——一个 demo 就能在 8 个物理 Pod 上托举约 250 个有状态 Actor见 README.md 与 demos/counter/README.md。这套设计的北极星指标同样写在 docs/architecture.md 里激活延迟目标 p95 100ms单集群支撑 10 亿 Actor每秒处理 1000 次唤醒。注意这里的激活不是冷启动——它是从快照恢复进程而不是重新跑一遍容器启动流程。谷歌的棋专用控制面 双沙箱 agent 感知路由一个小而专注的控制面配一个熟悉的后端Substrate 把资源分成两层见 docs/glossary.md 与 docs/api-guide.md声明式、低频WorkerPoolKubernetes CRD定义温暖算力池由atecontroller调和成 Deployment、SandboxConfig集群级 CRD钉住沙箱运行时二进制与 pause 镜像、ActorTemplateate API 资源定义镜像与快照配置创建即触发 golden snapshot。高频、动态Actor 与 Worker 记录存放在 PostgreSQL 状态存储里因为它们变化太快不适合 etcd。整个控制面由ate-api-server承担负责 Actor 生命周期、把 Actor 调度到 Worker、协调快照。节点侧是atelet每个节点的 DaemonSet牧羊人每个物理 worker Pod 里再放一个ateom沙箱管理者容器对 gVisor 走runsc对 microVM 走 Kata Cloud Hypervisor。分层意图很清晰物理 Pod 的生命周期与沙箱内的 agent 进程彻底解耦——挂起/恢复的是进程级快照而不是 Pod 本身见 docs/architecture.md 的 System Components 一节。这套架构在 docs/assets/threat-model-diagram.svg 中有完整图示两种沙箱一条统一的挂起/恢复语义Substrate 原生支持两条沙箱路线但对外暴露一致的 Actor 生命周期操作gVisor默认用runsc做用户态内核隔离suspend/resume 依赖 gVisor 原生的 checkpoint/restore。cmd/ateom-gvisor/runsc.go负责把 OCI spec 塑造成 gVisor 形态架构文档还特别注明当前需要一个带--allow-connected-on-save的 runsc 版本来规避网络恢复时的已知缺陷。microVM基于 Kata Containers Cloud Hypervisorsuspend/resume 抓取纯内存快照并用userfaultfd做按需内存换页容器 rootfs 写入是宿主机后端的只读 OCI 镜像 lower 每 Actor 可写 upperFull快照会把 upper 打成 tar 一并落盘。cmd/ateom-microvm/checkpoint.go的注释写得很清楚FULL范围连 guest 内存一起快照DATA范围只保留持久卷下次恢复时冷启动见 cmd/ateom-microvm/checkpoint.go。沙箱二进制本身不烘焙进 worker 镜像而是运行时从SandboxConfig获取并把版本钉进每个快照的 manifest——这样恢复结果不会随运行时升级漂移见 docs/api-guide.md 的 SandboxConfig 一节。这解决了社区里反复讨论的gVisor 升级导致内存快照失效痛点。路由层流量就是唤醒信号为了让挂起的 Actor 能按需复活网络栈必须能拦截并识别流量。atenet-router跑 Envoy ext_proc外部处理器请求通过ate-target-actor: atespace/actor头指定目标ext_proc 调用控制面把 Actor 唤醒并解析出当前 worker 指派然后以 mTLS 打开到 worker 上atunnel监听器443的隧道再经 Actor 的私有 veth 网卡送达。worker Pod 的 80 端口根本不是 Actor 的直连入口见 docs/architecture.md 的 Networking Stack 一节。安全基线默认拒绝 威胁模型先行因为 Agent 跑的是不可信代码Substrate 把安全当成一等公民。仓库的 docs/threat-model.md 按 T-01 到 T-10 的优先级系统梳理了这类系统的威胁外部直连 Actor、节点暴露、控制面/数据库被公网访问均为 Critical到内网组件互信、快照窃取、凭据泄露等。给出的缓解不变量包括所有组件 mTLS 默认拒绝、控制面与数据面物理隔离、基于 Actor 身份的凭据注入避免密钥直接暴露给 Actor、快照存储最小权限。README 的 Quickstart 也强调默认部署的是default-deny 的凭据提供方——在授权 atespace 之前任何 Actor 都读不到 Secret。十年窗口期的押注K8s 生态会怎么回应低意见系统不取代 Kubernetes而是接管它之上的执行层Substrate 在 README.md 里反复强调自己是个low-opinion低意见系统管理的负载不一定是字面意义的 AI Agent它不是构建 Agent 的 SDK而是把 Agent 规模化跑起来的系统。Kubernetes 的角色被明确为基础设施供应、worker 生命周期管理、以及端到端 agent 部署所需的各类负载推理、训练、agent 循环的统一底座。这其实是一步相当聪明的棋谷歌没有另起炉灶再造一套编排而是承认 K8s 在管 Pod 生命周期上赢了把创新押在它上面的执行层——快照、唤醒、状态迁移、agent 感知路由。配套的生态拼图也在成型Agent Executorax分布式 agent 运行时、kagentCNCF Sandbox 项目、ADK/LangChain/Claude Code/Codex 支持、以及把 MCP Server 作为持久化 Actor 托管见 README.md 与 docs/roadmap.md。docs/integration-repos.md甚至立了规矩正式集成一个仓库一个命名且核心缺口必须在 core 修绝不在下游打补丁。代价与未解之谜docs/architecture.md很诚实没有免费午餐。百万级 Actor 的快照数据管理是全新难题——状态每秒可能更新多次调度必须把数据局部性当一等公民要么把事件路由到状态所在地要么把状态搬过来跨 worker 频繁迁移让可观测性变得更难需要按 Actor 贯穿指标、日志与 tracepeer-to-peer 状态共享、控制面鉴权、身份与策略都还在 roadmap 上未动工。docs/roadmap.md里也不避讳gVisor 快照优化、S3 支持经插件、数据局部性调度、actor 级网络策略、Disk-Only Resume 策略只保留文件系统、跳过 RAM 恢复的省钱休眠都排在待办里。项目的 pre-1.0 状态README 明言不承诺向后兼容、API 不稳定、对对象存储GCS/S3的强依赖都意味着这套执行层重构还处于早期赌注阶段。十年窗口期的真正悬念不是Substrate 会不会取代 Kubernetes——它明确不想这么做——而是当 agent 负载成为云上主流工作负载时K8s 生态会不会把可挂起/恢复的沙箱 Actor当作新的执行单元标准。Substrate 用源码把这条技术路线完整地摆了出来接下来要看社区与竞品如何接招了。关键参考执行模型设计见 docs/architecture.md资源模型与 API 见 docs/api-guide.md 与 docs/glossary.md安全基线见 docs/threat-model.md可运行的 30× 超分示例见 demos/counter/README.md 与 demos/counter/counter.go两条沙箱路线实现见 cmd/ateom-gvisor/runsc.go 与 cmd/ateom-microvm/checkpoint.go。【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考