google/ax 点名依赖之后agent 基建下半场沙箱层开始卷了【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrateagent 生态的竞争重心正在肉眼可见地下移从年初的框架军备竞赛转移到谁能在 Kubernetes 上安全、高密度地跑起百万级有状态 Agent。标志性事件是 google/axAgent Executor在官方文档中把 Agent Substrate 列为分布式 Agent 运行时的底层执行依赖——框架之上套框架的叙事就此终结沙箱运行时、快照调度、状态持久化这些基建件开始成为真正的分水岭。本文结合社区对 Substrate 的讨论30× 超配比、8 个 Pod 跑 250 个有状态 Agent、gVisor 与 microVM 之争与仓库源码拆解这次重心转移的底层逻辑。从框架卷到基建agent 生态竞争重心的转移第一波 agent 浪潮的竞争焦点是编排框架——LangChain、各类 Agent SDK 争夺的是怎么把工具调用、子 Agent、上下文串起来的入口。但框架层很快触及天花板真正贵、真正难的部分不在提示词编排而在执行侧。一个 agent 工作负载绝大多数时间处于等待状态等 LLM 返回、等外部工具响应真正干活的时间极短且不可预测而它跑的又是不可信逻辑必须放进单租户沙箱——于是产生了一个矛盾数量巨大、大部分时间闲置、每个都要隔离。仓库的 docs/architecture.md 对这个问题做了最直白的定义agent-like 工作负载是 bursty 的The time they spend actually doing work is often very short, and the time they spend waiting can be unbounded而they are usually single-tenant instances, and there are a great many of them。传统 Kubernetes 容器模型对这个负载形态是结构性浪费闲置 Pod 依然占用 CPU、内存和节点配额而调度一个 Pod 需要多个异步流程收敛加镜像拉取对运行毫秒到几秒的负载而言延迟不可接受。Substrate 的对策是把 agent 的生命周期从物理 Pod 上解耦把 Kubernetes 降级为纯资源供给层。仓库 README.md 的核心表述是At its core, Agent Substrate maps a larger set of actors onto a smaller set of ready workers, relying on the fact that agent-like applications tend to be idle most of the time to achieve heavy multiplexing。社区里流传的8 个 Pod 跑 250 个有状态 Agent正是这套 N 对 M 映射的量化结果README 的 Demo 章节也给出了官方口径约 250 个有状态 actor 复用 8 个物理 Pod超分复用 30× 以上suspend/resume 激活吞吐超过每秒 500 次、唤醒亚秒级。架构上这不是新东西的堆砌而是对三种成熟机制的融合Serverless 的快照冷启动、Orleans 虚拟 Actor 的激活/停用模型、Knative 的 scale-to-zero——社区讨论对此已有共识。Substrate 的价值在于把它们下沉到了沙箱内核层不是应用层模拟状态而是 gVisor 的 checkpoint/restore 与 microVM 的内存快照原生支持挂起与恢复让任意 OCI 镜像都能获得跨宿主机迁移的有状态执行。README 里那句定位值得反复读It is not an SDK for building agents, but rather a system for running them at scale——这句话同时划清了与框架层的边界也宣布了基建层的入场。ax Substrate 组合对第三方编排器的挤压google/ax 点名的意义不在又多了一个集成而在它完成了 Google 在 agent 执行栈上的闭环。README 的 Ecosystem 章节把 Agent Executor 列为第一个官方集成A distributed agent runtime that demonstrates building a secure, hyper-scalable agent harness on Agent Substrate。ax 解决分布式编排与 harness 问题Substrate 解决沙箱执行与有状态生命周期问题两者合起来等于从agent 怎么调度到agent 在哪跑、怎么复活整条链路都有了官方答案。这个组合对第三方编排器的挤压是结构性的。Substrate 是显式的低观点low-opinion系统它不绑定任何 agent 框架因为它管理的是内核层面的标准 OCI 容器。这带来一个微妙的竞争效应——docs/roadmap.md 的集成清单里除了 ax 的 tight integration还明确规划了 ADKAgent Development Kit原生绑定、LangChain Remote Execution Provider、MCP Server 托管、Actor-to-ActorA2A调用模型。也就是说主流编排框架在 Substrate 的定位里都是可承载的工作负载而非可替代的编排层编排价值被整体下移你不再需要自己实现 worker 池、会话恢复、跨节点状态迁移这些全部由控制面接管。从 docs/architecture.md 的资源模型能看到这层挤压的落地方式。WorkerPool是 Kubernetes CRD由 atecontroller 调和成 Deployment而ActorTemplate是 ate API 资源存在控制面 PostgreSQL 而非 etcd——因为 actor 状态变化频率远超 Kubernetes API server 的设计负载。调度一个 actor 不再走 kube-scheduler而是控制面在 warm worker 池里做原子分配Client - atenet-router - ate-api-server: ResumeActor ate-api-server - atelet: Restore下载快照 atelet - ateom: RestoreWorkload恢复沙箱、激活网络 ate-api-server - atenet-router: worker 分配 atenet-router - atunnel(worker:443): mTLS 隧道转发请求路由依赖一个专门设计的路由头internal/atenet/headers.go 中定义为ate-target-actor: atespace/actorHost 与 URL 一律不参与 actor 选择。流量到达时按需唤醒demos/counter/counter-template.yaml.tmpl里用wakeupProbe的/readyz探测判定沙箱真正就绪避免把请求打进还在恢复过程中的 actor。这套路由器按需唤醒 控制面原子分配 atunnel 隧道注入的链路恰好是第三方编排器此前最有价值的工作——现在它被固化进了基建且以亚秒级延迟为设计目标北向指标是 P95 100ms 激活延迟。集成治理上仓库也早有章法。docs/integration-repos.md 规定琐碎 demo 留在核心仓库非平凡集成各占一个agent-substrate组织下的独立仓库如 capability 命名的execution-sandbox、连接保持型的always-on-agent且核心缺口必须在核心仓库先落地、集成仓库只依赖已发布版本——这意味着所有第三方编排器想在 Substrate 上获得一等公民地位都得把差异化能力上贡给核心控制面而不是自己 fork 打补丁。CNCF Sandbox 项目 kagent 选择以 Substrate 为沙箱底座进一步说明这套栈的吸引力已超出 Google 内部。沙箱层的机会谁在补 gVisor/microVM 之外的空缺基建竞争的下半场必然落到沙箱层而 Substrate 恰好把沙箱做成了可插拔、可版本钉住、可审计的资源而非铁板一块。仓库里最值得研究的样板是SandboxConfig这个集群级 CRD定义见 pkg/api/v1alpha1/sandboxconfig_types.go它用 sha256 内容寻址钉住沙箱运行时二进制与 pause 镜像AssetFile.URLSHA256按 GOARCH 分 amd64/arm64 两套支持多版本并存、Disabled 版本拉黑并把defaultVersion的合法性写进了 CRD 的 CEL 校验规则。ActorTemplate通过configName引用它快照 manifest 里再固化当时的运行时版本——一处升级、全集群生效、快照可复现由此成立。沙箱类目前只有两个gVisor默认cmd/ateom-gvisor与 microVMcmd/ateom-microvmKata guest Cloud Hypervisor VMM。两者代表两种完全不同的隔离哲学与成本结构社区对比文章已经把这层差异讲透gVisor 用户态内核开箱即用、无需 KVMsuspend/resume 走runsc的进程级 checkpoint/restoremicroVM 提供硬件级隔离但依赖/dev/kvm与 vhost 设备快照走userfaultfd内存按需分页rootfs 可写层通过单条 virtio-fs 共享暴露给 guest见 docs/architecture.md 的 micro-VM 小节。WorkerPool的spec.sandboxClasses一次只能声明一种MinItems1, MaxItems1pool 与 config 分离的意图很明确沙箱运行时的选择从 workload 定义里剥离交给平台团队治理。这张牌桌远未到终局gVisor/microVM 之外的空白正在被快速填补。从 docs/roadmap.md 与源码可数出一批明确的机会点快照工程化当前快照只有 MEMORY / ROOTFS / VOLUMES 三种保真度枚举定义在 pkg/proto/ateapipb/ateapi.pb.go且ROOTFS尚无任何沙箱运行时支持、请求即被拒绝roadmap 规划的增量快照、存储分层local zswap → 本地 SSD → 对等节点 → 对象存储 blob、调度感知的数据本地性都是尚未兑现的高价值能力。存储后端快照通过 snapshot-plugin 的 gRPC 接口读写对象存储docs/architecture.md 明确 in-tree 插件支持 GCS 与 S3ATE_STORAGE_BACKEND切换但共享可写存储NFS/CSI 卷、ConfigMap 卷、快照保留策略等仍停留在 roadmap 的 idea 列表。gVisor 的已知短板gVisor 类模板目前只允许一个DurableDir卷见 docs/glossary.mdcheckpoint 恢复联网需要--allow-connected-on-save绕过上游 bugcmd/ateom-gvisor/durable.go中卷快照以 tar 打包、恢复时经os.Root防符号链接逃逸这类补 runtime 缺陷的活本身就是工程红利。安全纵深docs/threat-model.md 给出了 T-01 至 T-43 的完整威胁清单其中快照窃取/篡改T-23/T-24、损坏快照恢复T-25、worker 复用残留T-27、凭据代理注入T-29等 mitigation 大多还未落地docs/egress-traffic.md 展示的默认拒绝型 egress除 DNS 与带策略的 HTTP(S) 外全部拦截则是已经兑现的卖点。这张架构图来自 docs/threat-model.md恰好点出了沙箱层的全部攻防面atelet 节点守护进程、ateom worker 内部协调器、atunnel 认证隧道、快照对象存储、PostgreSQL 控制面——每一个组件之间都是 mTLS 与默认拒绝的信任边界。对后来者而言机会不在重造一个 Substrate而在把上述空白逐个填实可验证的确定性快照格式、跨集群对等的快照分发、无 KVM 节点的轻量隔离方案、以及能端到端串起 agent 身份与快照加密的凭据体系。谁先把这些做成生产级谁就拿到了 agent 基建下半场的门票。竞争从未消失只是换了一个更硬核的赛场上半场卷的是Agent 能做什么下半场卷的是Agent 在哪跑、怎么省着跑、被攻破了怎么办。Substrate 用 30× 超配比证明了省着跑的价值用 SandboxConfig 证明了沙箱可以像软件包一样治理而 google/ax 的依赖声明则宣告了基建层的胜负手已经开牌。接下来的看点是 gVisor/microVM 之外的新沙箱以及围绕快照与状态的那批待填空白会由谁先交付。【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考