Google 官方文档点名为什么 google/ax 把执行层押在了 Agent Substrate 上【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrate当 Google 官方开源的 agentic 编排运行时 axAgent Executor仓库主页写着 Googles open agentic orchestration runtime已积累上万 star在其官方 README 的 Prerequisites 一节写下这样一句硬性要求时事情就变得不寻常了AX schedules every task as a sandboxed actor onAgent Substrate, so Substrate must be running in your clusterbeforeyou deploy AX.不是推荐搭配不是可选集成而是先装 Substrate再装我——执行层从可选项变成了前置依赖。本文基于 ax 官方文档与 Agent Substrate 仓库源码拆解三层问题ax 与 Substrate 的分工边界到底画在哪里官方点名的含金量有多重以及这对正在或准备开发 agent 的人意味着什么。ax 是什么集群编排器与沙箱底座的分工ax 给自己的定位是high-throughput, declarative orchestrator——一个在集群里声明式地跑数十亿自治 agent 工作负载的编排器。它给出的心智模型非常小只有三个原语你想做的事ax 给的原语在带 CPU/内存限额的隔离沙箱里跑不可信 agent 代码Task预接 Git 仓库、MCP server、skill 包让每个 agent 一启动就是暖的Workspace配置平台自身用哪个 LLM凭据来自 Kubernetes SecretModel挂起空闲 agent、之后原地续跑ax suspend/ax resume钻进运行中的 agent 看它到底在干嘛ax sshax 的官方文档对 agent 这类工作负载有一句非常准确的判断Agents are a new kind of workload. They are neither stateless microservices nor run-to-completion batch jobs. They accumulate state, need strict isolation, call out to model APIs and tool servers, and can burn money in a loop if nobody is watching.——有状态、要强隔离、要随时叫停又随时续跑。这类工作负载恰恰是 Kubernetes 原生资源模型最不擅长伺候的。而关键的分工在于ax 自己不做沙箱。官方 README 白纸黑字写着 AX ... runs on top of Agent Substrate for sandboxed execution并且每个 Task 都被调度为 a sandboxed actor on Agent Substrate。ax 负责声明式地描述要跑什么执行层则完全交给 Substrate。这正好对应 Agent Substrate 的自我定位README.md——A secure-by-default runtime for running millions of agent sandboxes on Kubernetes以及它在 docs/glossary.md 里反复强调的边界It is not an SDK for building agents, but rather a system for running them at scale. Substrate 不是 agent 框架而是把跑 agent这件事做到百万级的基础设施它把更大集合的 actorsagent 类应用映射到更小集合的预热 workers 上利用 agent 类应用大部分时间在等待的固有特性实现重度复用并提供 actor 生命周期管理create/destroy、suspend/resume、实时 worker 分配与流量路由。一句话概括分工ax 是大脑描述任务与编排Substrate 是肌肉负责沙箱、快照、挂起恢复与高密度调度。官方点名的含金量从可选组件到默认依赖说官方文档点名并非标题党三重证据都指向执行层已被官方文档锁死为默认依赖。第一重Substrate 官方生态列表的第一位就是 ax。在 Substrate 仓库的 README.md Ecosystem Examples 一节google/axAgent Executor被列在首位官方原话是 a distributed agent runtime that demonstrates building a secure, hyper-scalable agent harness on Agent Substrate并附有 Google Cloud 官方公告博客与集成指南紧随其后的是同为官方阵营的 CNCF Sandbox 项目 kagent同样uses Agent Substrate to run sandboxed, stateful agent workloads。第二重ax 官方文档把 Substrate 写成部署前置。除了开篇那句 must be running before you deploy AXax 的 Prerequisites 还给出了一个非常具体的集成契约Substrate 安装后落在ate-system命名空间其 Control API 暴露在api.ate-system.svc.cluster.local:443——which is where AX expects to find it并要求先kubectl get svc api -n ate-system验证它在线才进入make deploy部署 ax 控制面。也就是说ax 的控制面从架构上就假设一个活着的 Substrate 控制面存在于固定地址。第三重ax 的生命周期原语直接映射 Substrate 的 Actor 语义。ax suspend task task123/ax resume task task123在 ax 侧是checkpoint actor state and pause / resume a suspended task而这两个动作正是 Substrate 控制面的核心 RPC——SuspendActor与ResumeActor。ax 的ax get tasks输出里直接暴露ATESPACE、ACTOR、WORKER-IP三列说明 ax 眼中的task在 Substrate 侧就是一个有 atespace 归属、有 worker 分配的 Actor 记录。这种依赖不是文档层面的口头约定而是被 Substrate 的资源模型在 API 层面钉死的。打开 pkg/api/v1alpha1/workerpool_types.goWorkerPool是 Kubernetes CRDspec.sandboxClass枚举gvisor默认与microvm两种沙箱族pkg/api/v1alpha1/sandboxconfig_types.go 里的SandboxConfig是集群级 CRD用 sha256 内容寻址钉住 gVisorrunsc二进制、microVM 内核/固件等运行时资产与 pause 镜像并用 CRDXValidation规则强制gVisor 必须带 pause 镜像、microVM 禁止带而ActorTemplate则通过 ate gRPC API 创建见 cmd/ateapi/internal/controlapi/actor_template.go其中config_name为必填创建时即校验所引用的 SandboxConfig 存在。这套基础设施走 Kubernetes CRD、高频实例状态走专用控制面的双层模型是 ax 能在上面宣称run billions of tasks per cluster的地基。为什么执行层非 Substrate 不可如果把 ax 换成任何其他编排器它仍然绕不开那个根本矛盾agent 工作负载的形态与通用容器编排的假设严重错位。Substrate 的 docs/architecture.md 把这个问题剖析得很直白agent 类工作负载极具突发性绝大多数时间在等待输入或事件干活时间往往极短、等待时间可能无上限它们运行不可信逻辑通常必须跑在沙箱里于是天然是单租户实例且数量巨大空闲 Pod 依然消耗资源Kubernetes API server 不是为百万级离散资源和高频写入设计的调度一个 Pod 需要多个异步过程收敛加多次网络跳转加镜像拉取——对一个运行几毫秒到几秒的工作负载数秒的冷启动延迟不可接受。Substrate 的解法是一套为挂起/恢复而生的执行模型同见 docs/architecture.md预热 Worker 池预先启动常驻的 worker Pod沙箱等活避免唤醒时走 Kubernetes 调度器Golden Snapshot创建ActorTemplate时先临时冷启动一次工作负载并打底金快照之后每次唤醒从快照恢复而非冷启动Actor 状态机SUSPENDED → RESUMING → RUNNING → SUSPENDING → SUSPENDED空闲即快照、事件即恢复且可恢复到任意可用 worker流量驱动唤醒atenet-router用 Envoyext_proc读取ate-target-actor: atespace/actor请求头见 internal/atenet/headers.go 与 cmd/atenet/internal/router/ingress/ingress_test.go命中即调控制面ResumeActor拿到 worker 分配再经 mTLS 隧道atunnel转发实现流量到、actor 醒。这套机制让 Substrate 给出了一组为编排器量身定制的北向指标激活延迟 100msp95、单集群支撑 10 亿 actor、每秒 1000 次唤醒事件。README 中的 demo 则以更直观的形式呈现了它的密度能力——cluster multiplex ~250 stateful actors across just 8 physical pods30 倍以上的超配比。这正是 ax 这类百万任务级编排器最需要从执行层拿到的东西可挂起、可恢复、可迁移、且亚秒级激活的有状态执行单元。Substrate 的威胁模型docs/threat-model.md含 T-01 至 T-43 编号进一步把安全基线写成了工程契约外部默认拒绝T-01~T-03、系统组件间 mTLS 全链路认证、控制面与数据面物理隔离、Actor 网络私有 veth atunnel认证监听、快照存储最小权限。这些 mitigating invariants不是锦上添花而是编排不可信 agent 代码的前提条件。对 agent 开发者的直接影响把执行层押在 Substrate 上对 agent 开发者的体验变化是结构性的1. 框架无关写 agent 与写运行配置彻底分离。Substrate 在 README 中明确支持 ADK会话状态跨调用保持为 actor 状态、LangChain、Claude Code / CodeX / Antigravity高密度有状态编码环境、以及把 MCP server 作为持久工具部署成 Substrate Actor。你在 ax 侧只需要声明式地写一份task.yaml把 Git 仓库、目标和模型说清楚剩下的沙箱、唤醒、挂起、恢复全部交给底层# task.yamlax 官方示例形态 apiVersion: ax.io/v1alpha1 kind: Task metadata: name: test spec: workspaces: - name: golang goal: Ensure that Go tool chain is available and is built from source debug: true # lets you ax ssh into the sandbox2. 状态保持从约定变成默认能力。快照有Full与Data两种 scopeFull同时捕获进程内存与根文件系统增量及挂载的 durable 卷Data只持久化卷内容、内存冷启动。仓库里的 Counter demo 是最直观的验证demos/counter/counter.go demos/counter/counter-template.yaml.tmpl同一个 Go HTTP 服务同时维护一个进程内存计数requestCount.Add(1)和一个 durable 卷文件计数模板snapshotConfig.onCommit设为SNAPSHOT_CONTENT_SCOPE_FULL——于是kubectl ate suspend actor之后再次curl -H ate-target-actor: ate-demo-counter/my-counter-1唤醒两个计数都从原值继续即使 actor 被恢复到了另一台 worker详见 demos/counter/README.md。这就是 agent上次干到一半的活能接着干的底层保障。3. 一条清晰的落地路径。先按 README.md 的 Quickstart 装好 Substrate本地 kind 或 GKE 均可hack/create-kind-cluster.shhack/install-ate-kind.sh验证控制面然后在 ax 侧make deploy、ax apply -f task.yaml、ax watch、ax suspend/ax resume整个编排器 执行层的闭环就串起来了。Substrate 处于 pre-1.0 阶段API 仍可能变动但编排层负责声明、执行层负责沙箱与状态的分层方向已经由 Google 官方文档用前置依赖的方式定调。结语ax 把执行层押在 Agent Substrate 上不是一次随手的依赖选择。编排器真正需要的是一个能给出可挂起、可恢复、可迁移、亚秒级唤醒、高密度复用、默认零信任语义的执行单元而通用容器编排给不了这些——Substrate 正是为此从零构建的。对 agent 开发者而言这意味着执行层的问题沙箱隔离、快照存储、唤醒延迟、密度成本正在被系统性下沉和标准化你可以把注意力收回到 agent 本身写声明、接工具、看它跑然后放心地把它挂起等下一个事件到来。【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/10 11:01:06 · 阅读 1.2k Google 官方文档点名：为什么 google/ax 把执行层押在了 Agent Substrate 上
Google 官方文档点名为什么 google/ax 把执行层押在了 Agent Substrate 上【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrate当 Google 官方开源的 agentic 编排运行时 axAgent Executor仓库主页写着 Googles open agentic orchestration runtime已积累上万 star在其官方 README 的 Prerequisites 一节写下这样一句硬性要求时事情就变得不寻常了AX schedules every task as a sandboxed actor onAgent Substrate, so Substrate must be running in your clusterbeforeyou deploy AX.不是推荐搭配不是可选集成而是先装 Substrate再装我——执行层从可选项变成了前置依赖。本文基于 ax 官方文档与 Agent Substrate 仓库源码拆解三层问题ax 与 Substrate 的分工边界到底画在哪里官方点名的含金量有多重以及这对正在或准备开发 agent 的人意味着什么。ax 是什么集群编排器与沙箱底座的分工ax 给自己的定位是high-throughput, declarative orchestrator——一个在集群里声明式地跑数十亿自治 agent 工作负载的编排器。它给出的心智模型非常小只有三个原语你想做的事ax 给的原语在带 CPU/内存限额的隔离沙箱里跑不可信 agent 代码Task预接 Git 仓库、MCP server、skill 包让每个 agent 一启动就是暖的Workspace配置平台自身用哪个 LLM凭据来自 Kubernetes SecretModel挂起空闲 agent、之后原地续跑ax suspend/ax resume钻进运行中的 agent 看它到底在干嘛ax sshax 的官方文档对 agent 这类工作负载有一句非常准确的判断Agents are a new kind of workload. They are neither stateless microservices nor run-to-completion batch jobs. They accumulate state, need strict isolation, call out to model APIs and tool servers, and can burn money in a loop if nobody is watching.——有状态、要强隔离、要随时叫停又随时续跑。这类工作负载恰恰是 Kubernetes 原生资源模型最不擅长伺候的。而关键的分工在于ax 自己不做沙箱。官方 README 白纸黑字写着 AX ... runs on top of Agent Substrate for sandboxed execution并且每个 Task 都被调度为 a sandboxed actor on Agent Substrate。ax 负责声明式地描述要跑什么执行层则完全交给 Substrate。这正好对应 Agent Substrate 的自我定位README.md——A secure-by-default runtime for running millions of agent sandboxes on Kubernetes以及它在 docs/glossary.md 里反复强调的边界It is not an SDK for building agents, but rather a system for running them at scale. Substrate 不是 agent 框架而是把跑 agent这件事做到百万级的基础设施它把更大集合的 actorsagent 类应用映射到更小集合的预热 workers 上利用 agent 类应用大部分时间在等待的固有特性实现重度复用并提供 actor 生命周期管理create/destroy、suspend/resume、实时 worker 分配与流量路由。一句话概括分工ax 是大脑描述任务与编排Substrate 是肌肉负责沙箱、快照、挂起恢复与高密度调度。官方点名的含金量从可选组件到默认依赖说官方文档点名并非标题党三重证据都指向执行层已被官方文档锁死为默认依赖。第一重Substrate 官方生态列表的第一位就是 ax。在 Substrate 仓库的 README.md Ecosystem Examples 一节google/axAgent Executor被列在首位官方原话是 a distributed agent runtime that demonstrates building a secure, hyper-scalable agent harness on Agent Substrate并附有 Google Cloud 官方公告博客与集成指南紧随其后的是同为官方阵营的 CNCF Sandbox 项目 kagent同样uses Agent Substrate to run sandboxed, stateful agent workloads。第二重ax 官方文档把 Substrate 写成部署前置。除了开篇那句 must be running before you deploy AXax 的 Prerequisites 还给出了一个非常具体的集成契约Substrate 安装后落在ate-system命名空间其 Control API 暴露在api.ate-system.svc.cluster.local:443——which is where AX expects to find it并要求先kubectl get svc api -n ate-system验证它在线才进入make deploy部署 ax 控制面。也就是说ax 的控制面从架构上就假设一个活着的 Substrate 控制面存在于固定地址。第三重ax 的生命周期原语直接映射 Substrate 的 Actor 语义。ax suspend task task123/ax resume task task123在 ax 侧是checkpoint actor state and pause / resume a suspended task而这两个动作正是 Substrate 控制面的核心 RPC——SuspendActor与ResumeActor。ax 的ax get tasks输出里直接暴露ATESPACE、ACTOR、WORKER-IP三列说明 ax 眼中的task在 Substrate 侧就是一个有 atespace 归属、有 worker 分配的 Actor 记录。这种依赖不是文档层面的口头约定而是被 Substrate 的资源模型在 API 层面钉死的。打开 pkg/api/v1alpha1/workerpool_types.goWorkerPool是 Kubernetes CRDspec.sandboxClass枚举gvisor默认与microvm两种沙箱族pkg/api/v1alpha1/sandboxconfig_types.go 里的SandboxConfig是集群级 CRD用 sha256 内容寻址钉住 gVisorrunsc二进制、microVM 内核/固件等运行时资产与 pause 镜像并用 CRDXValidation规则强制gVisor 必须带 pause 镜像、microVM 禁止带而ActorTemplate则通过 ate gRPC API 创建见 cmd/ateapi/internal/controlapi/actor_template.go其中config_name为必填创建时即校验所引用的 SandboxConfig 存在。这套基础设施走 Kubernetes CRD、高频实例状态走专用控制面的双层模型是 ax 能在上面宣称run billions of tasks per cluster的地基。为什么执行层非 Substrate 不可如果把 ax 换成任何其他编排器它仍然绕不开那个根本矛盾agent 工作负载的形态与通用容器编排的假设严重错位。Substrate 的 docs/architecture.md 把这个问题剖析得很直白agent 类工作负载极具突发性绝大多数时间在等待输入或事件干活时间往往极短、等待时间可能无上限它们运行不可信逻辑通常必须跑在沙箱里于是天然是单租户实例且数量巨大空闲 Pod 依然消耗资源Kubernetes API server 不是为百万级离散资源和高频写入设计的调度一个 Pod 需要多个异步过程收敛加多次网络跳转加镜像拉取——对一个运行几毫秒到几秒的工作负载数秒的冷启动延迟不可接受。Substrate 的解法是一套为挂起/恢复而生的执行模型同见 docs/architecture.md预热 Worker 池预先启动常驻的 worker Pod沙箱等活避免唤醒时走 Kubernetes 调度器Golden Snapshot创建ActorTemplate时先临时冷启动一次工作负载并打底金快照之后每次唤醒从快照恢复而非冷启动Actor 状态机SUSPENDED → RESUMING → RUNNING → SUSPENDING → SUSPENDED空闲即快照、事件即恢复且可恢复到任意可用 worker流量驱动唤醒atenet-router用 Envoyext_proc读取ate-target-actor: atespace/actor请求头见 internal/atenet/headers.go 与 cmd/atenet/internal/router/ingress/ingress_test.go命中即调控制面ResumeActor拿到 worker 分配再经 mTLS 隧道atunnel转发实现流量到、actor 醒。这套机制让 Substrate 给出了一组为编排器量身定制的北向指标激活延迟 100msp95、单集群支撑 10 亿 actor、每秒 1000 次唤醒事件。README 中的 demo 则以更直观的形式呈现了它的密度能力——cluster multiplex ~250 stateful actors across just 8 physical pods30 倍以上的超配比。这正是 ax 这类百万任务级编排器最需要从执行层拿到的东西可挂起、可恢复、可迁移、且亚秒级激活的有状态执行单元。Substrate 的威胁模型docs/threat-model.md含 T-01 至 T-43 编号进一步把安全基线写成了工程契约外部默认拒绝T-01~T-03、系统组件间 mTLS 全链路认证、控制面与数据面物理隔离、Actor 网络私有 veth atunnel认证监听、快照存储最小权限。这些 mitigating invariants不是锦上添花而是编排不可信 agent 代码的前提条件。对 agent 开发者的直接影响把执行层押在 Substrate 上对 agent 开发者的体验变化是结构性的1. 框架无关写 agent 与写运行配置彻底分离。Substrate 在 README 中明确支持 ADK会话状态跨调用保持为 actor 状态、LangChain、Claude Code / CodeX / Antigravity高密度有状态编码环境、以及把 MCP server 作为持久工具部署成 Substrate Actor。你在 ax 侧只需要声明式地写一份task.yaml把 Git 仓库、目标和模型说清楚剩下的沙箱、唤醒、挂起、恢复全部交给底层# task.yamlax 官方示例形态 apiVersion: ax.io/v1alpha1 kind: Task metadata: name: test spec: workspaces: - name: golang goal: Ensure that Go tool chain is available and is built from source debug: true # lets you ax ssh into the sandbox2. 状态保持从约定变成默认能力。快照有Full与Data两种 scopeFull同时捕获进程内存与根文件系统增量及挂载的 durable 卷Data只持久化卷内容、内存冷启动。仓库里的 Counter demo 是最直观的验证demos/counter/counter.go demos/counter/counter-template.yaml.tmpl同一个 Go HTTP 服务同时维护一个进程内存计数requestCount.Add(1)和一个 durable 卷文件计数模板snapshotConfig.onCommit设为SNAPSHOT_CONTENT_SCOPE_FULL——于是kubectl ate suspend actor之后再次curl -H ate-target-actor: ate-demo-counter/my-counter-1唤醒两个计数都从原值继续即使 actor 被恢复到了另一台 worker详见 demos/counter/README.md。这就是 agent上次干到一半的活能接着干的底层保障。3. 一条清晰的落地路径。先按 README.md 的 Quickstart 装好 Substrate本地 kind 或 GKE 均可hack/create-kind-cluster.shhack/install-ate-kind.sh验证控制面然后在 ax 侧make deploy、ax apply -f task.yaml、ax watch、ax suspend/ax resume整个编排器 执行层的闭环就串起来了。Substrate 处于 pre-1.0 阶段API 仍可能变动但编排层负责声明、执行层负责沙箱与状态的分层方向已经由 Google 官方文档用前置依赖的方式定调。结语ax 把执行层押在 Agent Substrate 上不是一次随手的依赖选择。编排器真正需要的是一个能给出可挂起、可恢复、可迁移、亚秒级唤醒、高密度复用、默认零信任语义的执行单元而通用容器编排给不了这些——Substrate 正是为此从零构建的。对 agent 开发者而言这意味着执行层的问题沙箱隔离、快照存储、唤醒延迟、密度成本正在被系统性下沉和标准化你可以把注意力收回到 agent 本身写声明、接工具、看它跑然后放心地把它挂起等下一个事件到来。【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考