企业官网建设流程全解析

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 变成沙箱 Actor

Agent 负载的三个特征，恰好都是 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 类应用大部分时间空闲"这一事实。它的做法是：

1. 预启动 Worker：先拉起一批长期存活的 worker Pod，它们就是"等待工作的沙箱"，绕开了 Kubernetes 调度延迟；
2. 挂起 Actor：Actor 空闲时对其实施 suspend，释放它占用的全部资源；
3. 流量唤醒：事件到来时，由网络层拦下请求，把 Actor 指派给某个空闲 worker，从其最新快照恢复，然后转发流量；
4. 跨 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）：

• 声明式、低频：WorkerPool（Kubernetes CRD，定义"温暖"算力池，由atecontroller调和成 Deployment）、SandboxConfig（集群级 CRD，钉住沙箱运行时二进制与 pause 镜像）、ActorTemplate（ate 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 Hypervisor，suspend/resume 抓取纯内存快照，并用userfaultfd做按需内存换页；容器 rootfs 写入是宿主机后端的（只读 OCI 镜像 lower + 每 Actor 可写 upper），Full快照会把 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 Executor（ax，分布式 agent 运行时）、kagent（CNCF 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 贯穿指标、日志与 trace；peer-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