Google 把 Agent 当作一种新的工作负载来设计了一套完整的开源运行时：AX（Agent Executor）负责声明式编排，Agent Substrate 负责底层沙箱执行。两个项目同时出现在 GitHub Trending 上，AX 单日新增 star 超过 2300。
Agent 是一种新工作负载，K8s 的抽象接不住
Google Cloud 官方博客在 2026 年 5 月 21 日发布了 Agent Executor 的公告，作者 Jaana Dogan 和 Ethan Bao 给出的判断是：随着模型和 harness 能力增强，agent 开始承担运行数小时甚至数天的复杂任务，这类长时工作流脆弱且难以在生产环境可靠管理。
AX 的 README 把原因说得更具体：agent 既不是无状态微服务，也不是跑完即退的批处理任务。它会积累状态，需要严格隔离，要调用模型 API 和工具服务器，而且没人盯着的时候会在循环里烧钱。Kubernetes 的核心抽象（Deployment、Job、Service）没有为这种负载形态设计：一个 Job 无法挂起后原样恢复，一个 Deployment 的副本没有"暂停后接着跑"的语义。
AX 的应对方案是四个声明式原语，全部写成 ax.io/v1alpha1 的 YAML 清单：
| 需求 | AX 原语 |
|---|---|
| 在带 CPU/内存限制的隔离沙箱里跑不可信的 agent 代码 | Task |
| 预先接好 Git 仓库、MCP 服务器、技能包，让 agent 热启动 | Workspace |
| 把出站流量锁到显式的主机允许列表 | Gateway |
| 集中配置平台自身使用的 LLM，凭据走 Kubernetes Secret | Model |
一份多文档 YAML 可以同时声明这四种资源，ax apply -f task.yaml 一条命令提交。CLI 刻意做成了 kubectl 的形状：apply、get、describe、watch、delete，另加 ax suspend、ax resume、ax ssh 三个 agent 专属动词。
Task：刻意做小的执行单元
AX 概念文档对 Task 的定位写得很清楚。一个 agent 在生命周期里要规划、委派、重试、把工作扇出，AX 不试图用一个资源去建模这整个形状，而是给一个创建、隔离、挂起、丢弃都足够便宜的最小单元，让 agent 按需自己组合：单个 Task 可以就是全部工作，也可以是一棵 Task 树的根节点，每个节点拿到同样的沙箱、同样的生命周期和同样的工具。
Task 的状态机围绕三个 condition 展开：WorkspaceReady 表示所有 workspace 准备完毕，GatewayReady 表示网络策略已下发到沙箱，Ready 是真正要等的信号，表示任务在跑且 workspace 就绪。挂起时 Ready 置 False（原因 TaskSuspended），恢复时置回；删除时任务先进入 Terminating，控制器拆完沙箱才移除记录。
每个 Task 容器以 ax-task-runner 为 PID 1 启动，按绑定顺序准备 workspace：克隆 Git 仓库、布置技能路径；如果绑定时声明了 goal（一段自然语言描述），runner 会把它交给一个 Antigravity agent 去完成环境搭建，默认限时 10 分钟（AX_BOOTSTRAP_TIMEOUT 可调）。全部就绪后 runner 才以第一个 workspace 为工作目录拉起 spec.command 并监督它。命令退出后 runner 仍常驻，元数据服务器继续应答，ax ssh 依旧可用。
沙箱内的 agent 不需要任何 SDK 就能自省配置：runner 在 80 端口起了一个元数据服务器，GET /metadata/v1alpha1/ax/task 返回当前 Task 的完整 spec 和状态（YAML 格式），/readyz 在 workspace 初始化期间返回 503、就绪后返回 200。spec.debug: true 时同一端口还暴露 Agent Substrate 的 guest services（进程服务和文件系统服务），这是 ax ssh 能进沙箱执行命令的通道；默认关闭，因为它们允许任意进程执行和文件访问。
控制面为什么绕开 etcd
把数百万个短生命周期任务存成 Kubernetes CRD 会把 etcd 推出舒适区：单数字 GB 的存储上限、写速率瓶颈、控制面退化。AX 的做法是状态放 Redis（Task 哈希 + 事件流 + PubSub），用 Redis Streams 做 API server 和横向扩展的控制器池之间的工作队列，控制器通过 XREADGROUP 消费事件。
四个二进制各司其职：ax 是开发者 CLI；ax-server 是 8080 端口的无状态 gRPC API，校验清单、落 Redis、发事件；ax-controller 是对账 worker，消费流、在 Agent Substrate 上开通 atespace 和 actor、下发出站策略，加副本即扩容；ax-task-runner 是任务容器入口。控制面对外暴露 ax.v1alpha1.AX gRPC 服务，Task、Gateway、Workspace、Model 四类资源各有一套 Get/List/Update/Delete RPC，Task 额外有 SuspendTask、ResumeTask 和服务端流式的 WatchTask。
网络路径上，Task 不拥有自己的 Kubernetes Service 或 Ingress。所有流量经过 Agent Substrate 的 atenet 路由器，路由器只读一个 header：ate-target-actor: default/task123，解析 actor 所在 worker，如果目标挂着就先唤醒再转发。gRPC 场景下这个 header 走 outgoing metadata，ax ssh 就是这么找到沙箱里 guest services 的。
Agent Substrate：把 250 个 actor 塞进 8 个 pod
AX 跑在 Agent Substrate 之上，后者是 Google 与 GKE 团队合作的另一个开源项目，同一天公布。它的定位是安全默认的 agent 执行运行时：以比标准容器运行时高 10 倍的密度运行百万级沙箱，挂起/恢复操作的延迟低于 500 毫秒，每秒超过 500 次 suspend/resume 激活，内核与网络隔离原生零信任，沙箱技术同时支持 microVM 和 gVisor。
密度来自一条经验假设：agent 类应用大部分时间在等待外部输入，处于空闲。Substrate 让大量"actor"（agent、harness、技能、工具、沙箱都算）映射到少量就绪的"worker"上重度复用。官方演示视频展示了一个集群把约 250 个有状态 actor 复用到 8 个物理 pod 上，oversubscription 达 30 倍以上。actor 挂起时做全量状态快照（工作内存和文件系统），恢复时可以落到池中任意一台 worker，这也是"actor teleport"名字的由来。
请求到达但 worker 池满时，路由器会把请求"停泊"（parking）而不是返回 503，等有空闲 worker 再投递。WorkerPool 可以按已分配 worker 数量配 HPA 自动扩缩。Substrate 明确说自己是"低主张"系统：不提供构建 agent 的 SDK，只提供大规模运行它们的机制，工作负载甚至不必是 AI agent。
兼容性上，Substrate 在内核层管理标准 OCI 容器（经 gVisor），所以任何技术栈构建的 agent 都能托管：ADK agent 的会话状态、LangChain agent、Claude Code/CodeX/Antigravity 的高密度有状态编码环境、作为 actor 部署的 MCP 服务器。仓库的 demo 目录里有 Claude Code Multiplex 示例，演示把多个 Claude Code agent 复用到有限的 worker 池上。
落地路径与边界
想跑通 AX 全流程需要：一个 Kubernetes 集群、ko（构建并部署控制面镜像）、一个容器镜像仓库，以及一个可达的 Agent Substrate 控制 API。make deploy AX_IMAGE_REPO=<registry> 之后，Redis 和控制面组件落进 ax-system 命名空间，随后 go install github.com/google/ax/cmd/ax@latest 装 CLI，ax apply -f examples/task.yaml 提交第一份清单，ax watch task test 看状态流转，ax ssh test -- ls -al /workspace 进沙箱查看。
两份 README 都印着同样的警告：项目仍在早期，核心概念、协议和规格会继续调整，稳定版之前可能出现大的破坏性变更。Agent Substrate 明确标注不是官方支持产品，不在 Google 开源软件漏洞奖励计划范围内，API 几乎必然会变。当前支持策略是最新稳定版 Kubernetes 加上一个次版本。
模型配置目前给出 Google 和 Anthropic 两个 provider 的样例：API key 存 Kubernetes Secret，Model 资源引用并附带 temperature、maxTokens 等生成参数。一个细节是 Gateway 的出站允许列表默认示例是 host: "*"，文档特别提醒生产环境要收紧，agent 能访问哪些主机应当显式声明，这与 agent 在循环里烧钱的资金风险同属这套系统反复强调的运行边界。
Google 把 Agent Executor 和 Agent Substrate 都放进了 CNCF 生态的轨道里：Substrate 已有 CNCF Slack 频道和每周社区会议，kagent（CNCF Sandbox 项目）已经基于 Substrate 运行沙箱化的有状态 agent 工作负载。对维护自有 K8s 集群的团队来说，这套组合提供的增量是明确的：声明式的 agent 沙箱编排、亚秒级的挂起恢复、以及一个不为长时工作负载 redesign 整个集群的折中路径。
参考：GitHub google/ax 与 agent-substrate/substrate README 及 docs 目录 / Google Cloud Blog《Introducing Agent Executor, Google's distributed Agent Runtime》（2026-05-21）