Google AX 的落地页第一句话写得很轻巧：声明一个 agentic 任务，AX 就能规模化运行它。接着往下翻到 Quickstart，画风骤变——你需要一个正在运行的 Kubernetes 集群，需要 ko 来构建镜像，需要一个集群能拉取的容器镜像仓库，还需要一个可达的 Agent Substrate 控制 API。一个标榜更容易的 agent 编排器，先要你有一套生产级容器基础设施。这个落差本身就是 AX 发布当天最真实的注脚：Hacker News 上超过 600 分、285 条评论，讨论最激烈的不是架构设计，而是宣传语和安装要求之间的鸿沟。有评论者半开玩笑地说，这就像宣传一辆即开即走的车，但说明书第一页要求你先建一个加油站。
四个原语把复杂度折叠进了一个 YAML
AX 的抽象设计值得先看清楚。它把 agent 运行所需的一切拆成四个声明式原语，全部写在一个 YAML 文件里：Task、Workspace、Gateway、Model。Task 是隔离沙箱，携带镜像、命令、CPU 和内存限制。Workspace 声明 Git 仓库、MCP 服务器和技能，也接受一段纯英文目标描述。Gateway 定义出站白名单，显式列出主机和端口。Model 集中管理模型选择、参数和密钥。四个原语都在 ax.io/v1alpha1 这个 apiVersion 下，用 ax apply 提交。
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
name: invoice-recon
spec:
image: registry.example.com/ax/agent:v0.3
command: ["python", "-m", "harness.run"]
resources:
cpu: "500m"
memory: "1Gi"
workspaceRef: recon-workspace
gatewayRef: restricted-egress
modelRef: gemini-flash
---
apiVersion: ax.io/v1alpha1
kind: Gateway
metadata:
name: restricted-egress
spec:
egressAllowlist:
hosts:
- host: api.internal.example.com
port: 443
- host: storage.googleapis.com
port: 443
---
apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
name: recon-workspace
spec:
gitRepos:
- url: https://github.com/example/recon-tools
branch: main
mcpServers:
- name: filesystem
endpoint: http://mcp-fs.ax-system.svc.cluster.local:8080
这套设计比写一段 prompt 就等结果重得多，但它解决的是真问题。AX 文档里有一句话暴露了它的定位：agent 的绝大多数生命周期花在等待模型响应、等待工具返回、等待人类批准上。传统工作负载的瓶颈是算力耗尽，agent 的瓶颈是等待。为等待而建的运行时，核心指标不是吞吐量，是挂起与恢复的延迟。
对平台工程团队来说，这四个原语的实际意义在于把散落在 Helm chart、Kustomize overlay、Operator 控制器和 NetworkPolicy 清单里的配置收敛到一份可审计的声明。过去要为一个 agent 任务准备运行环境，需要写 Dockerfile、构建镜像、推送到仓库、写 Deployment、挂载 Secret、配 ServiceAccount、加 NetworkPolicy、再写一个脚本轮询结果。AX 把这一串操作压缩成一份 YAML 和一条 ax apply。这不是语法糖，是责任边界的重新划分：平台团队提供 Kubernetes 集群和 Agent Substrate，研究团队只写业务相关的声明。Workspace 允许纯英文目标作为降级路径，没有 Git 仓库和 MCP 服务器时，agent 在空沙箱里自行探索。这降低了实验门槛，但也意味着可复现性依赖模型行为，生产环境应该回到仓库加工具的确定路径。
Redis 替掉 etcd，因为百万个短命任务会压垮前者
2026 年 9 月 20 日，AX 完成了一次关键重构，把仓库拆成三个二进制：gRPC API 服务器、消费 Redis Streams 的 reconciler、在沙箱 worker 中运行的 task runner。更重要的是，任务状态从 Kubernetes custom resources 移入了 Redis。官方理由写得很直白：etcd 不是为数百万短命 agent 任务的高频创建和销毁设计的。
这个取舍在云原生圈子里是反直觉的。Kubernetes 生态默认状态应该存在 CRD 里，etcd 就是真理来源。但 agent 任务的生死频率和微服务 Pod 完全不在一个量级。传统微服务的 Pod 生命周期以分钟到小时计，状态转换少，etcd 的写入压力可控。Agent 任务以秒计，状态转换频繁：创建、调度、运行、等待模型、等待工具、等待人类批准、恢复、完成。每次转换都写一次 etcd，百万级任务就是千万级写入。etcd 的 Raft 日志和 fsync 会成为瓶颈，而 Kubernetes API Server 的 watch 机制也会被大量短命对象淹没。AX 的应对是让 ax-controller 从 Redis Streams 消费并发事件，绕开 Kubernetes API Server 的单点瓶颈。Task 被刻意设计成最小的隔离执行单元，多个 task 复用到同一个 worker 上，一个 worker 里同时挂着几十个 agent 的等待状态，原本浪费的空闲算力被重新利用。
等待型负载还有一个更根本的问题：挂起时不能一直占着计算资源。一个 agent 发起模型请求后可能等十秒，发起工具调用后可能等三十秒，等待人类批准可能等几小时。如果每次等待都保留完整沙箱的 CPU 和内存，成本会随并发数线性膨胀。Agent Substrate 的 gVisor checkpointing 和 micro-VM 快照让挂起的 agent 可以释放资源，恢复时从检查点继续。这是 AX 必须跑在 Agent Substrate 之上、而不是直接使用 Kubernetes Job 的原因。Job 的重试语义面向计算密集型任务，不理解等待和恢复。checkpoint 恢复把 agent 的生命周期和资源占用解耦，让高并发变得经济可行。
复用的代价：pod 身份不再可信
这个多 task 复用一个 worker 的设计引出了社区争论中最有价值的反对意见。Hacker News 上有评论者指出，当你把几十个 task 塞进同一个 worker pod，就不能再信任 Kubernetes pod 身份来自单一工作负载了，这对需要严格身份边界的团队构成采用障碍。
开发 AX 的人回应了这条批评。Agent Substrate 被描述为一个 OIDC 和 SPIFFE 身份提供者，可以通过 Substrate egress gateway 把携带 actor 身份的凭据注入出站请求。SPIFFE 本身是一套为软件工作负载提供身份的开源标准，定义了 SPIFFE ID 的 URI 格式和 X.509 SVID、JWT SVID 两种身份文档格式。方向是对的，但发言人同时承认这项工作预计几周内落地，属于路线图而非已交付功能。在那之前，共享身份的风险是真实的：一个跑偏的 agent 可能以同一 worker 上所有其他 agent 的权限行事。
传统 Kubernetes 身份模型里，一个 Pod 对应一个 ServiceAccount，投影令牌通过 projected volume 注入，工作负载访问外部服务时用这个身份换取凭据。当 worker 上跑几十个 task，它们共享同一个 Pod 身份，任何 task 都能用这个身份访问外部服务。Substrate egress gateway 的思路是把出站请求拦截下来，根据 actor 身份重新签名，注入对应的凭据。这需要 egress gateway 能识别请求来自哪个 task，也就是需要 task 级别的网络命名空间或进程标识。atenet 是 Substrate 里基于 Envoy 的集中式 L7 代理加 DNS 控制器，出站请求都要经过它，理论上可以在这一层按 actor 身份区分流量，但具体到每个 task 的凭据隔离，还要看 Substrate 的身份提供者如何与沙箱执行器协作，官方也承认这部分仍在路线图上。对安全敏感的团队，这个缺口足以让他们观望。
四原语各自管什么，一张表说清楚
| 原语 | 控制的内容 | 关键字段 | 对应的老问题 |
|---|---|---|---|
| Task | 隔离沙箱与资源边界 | image、command、env、CPU 和内存限制、gatewayRef、workspaceRef | 不用再手动拼容器安全上下文和资源配额 |
| Workspace | 起始运行环境 | Git 仓库及分支、MCP 服务器端点、技能注册表、纯英文目标 | 仓库克隆、工具接线从脚本变成声明 |
| Gateway | 出站网络围栏 | 监听器声明、出站主机和端口白名单 | 默认全放行在 443，显式绑定才收紧 |
| Model | 模型配置集中管理 | provider、model id、生成参数、SecretKeyRef | 密钥轮换从运维操作变成一次 apply |
这张表暴露了一个设计哲学：AX 不替你做决定，但把所有决定收拢到一份可审计的清单里。Task 默认没有 Workspace 时得到一个空的 /workspace 目录，并且允许对所有主机开放 443 端口出站。它失败在开放的那一侧，而不是封闭的那一侧。这是有意为之，对研究者来说，先跑通比先锁死重要。Model 原语集中密钥管理，意味着平台团队可以用 SecretKeyRef 指向 Kubernetes Secret，而不是把 API key 写进环境变量。这对合规审计很重要：密钥轮换从修改部署清单变成一次 apply，审计范围收敛到一处。Workspace 的纯英文目标适合快速实验，但生产环境应该用 Git 仓库和 MCP 服务器保证可复现。Gateway 的白名单不是装饰，一旦声明，所有出站流量都经过 atenet 的 Envoy 控制器，未列出的主机和端口会被拒绝。
它到底给谁用
Google 把 AX 推销给研究者的意图很明确：大规模可复现沙箱、收集训练轨迹、跑强化学习循环、规模化评测 agent。AX 跑在 Agent Substrate 之上，后者是一个独立项目，包含控制平面 API 服务器、节点级守护进程负责快照、基于 Envoy 的网络控制器 atenet，以及两个沙箱执行器，一个基于 gVisor checkpointing，一个基于 micro-VM。Agent Substrate 能把大量有状态 actor 复用到少量 Pod 上，一个 worker 同时挂几十个等待中的 agent，实现亚秒级恢复。这不是给个人开发者周末做 side project 用的东西。
研究者是第一批真正受益者，因为他们的工作模式恰好匹配 AX 的能力。强化学习循环需要大量并行的 agent 实例，每个实例在相同初始条件下探索不同轨迹，然后收集状态、动作、奖励序列。传统做法是手动管理容器和网络，每个实验写一套脚本，复现靠 Docker 镜像和随机种子。AX 把实验配置变成 YAML，可以版本控制、复现、批量提交。Agent Substrate 的高密度复用让研究者用少量节点跑大量并发 agent，这对预算有限的学术团队尤其重要。轨迹收集需要任务状态可查询，Redis Streams 提供的事件流可以导出成训练数据。大规模评测需要可复现的沙箱，Workspace 的 Git 仓库和 MCP 服务器保证每次运行的起始环境一致。
但 AX 自己也非常早期。README 警告核心概念和规范仍在打磨，正式版前可能出现重大破坏性变更，目前约 625 次提交。Agent Substrate 同样在快速迭代，代码仍在高频变动，涉及 worker 就绪、资源限制、身份、证书、遥测和 API 行为。研究者可以接受这种不稳定，因为他们要的是快速迭代，不是长期稳定 API。平台工程团队则要等身份和持久化问题解决。回到开头那个落差。AX 页面第一句承诺的是声明即运行，快速开始要求的是先给我一个集群。这两句话不矛盾，只是它们服务的读者不是同一批人。对已经有 Kubernetes 在手的平台工程团队，AX 提供的是一套比手写 operator 更完整的 agent 生命周期管理抽象。对没有集群的个人开发者，这个快速开始就是一道劝退墙。Google 没有假装这道墙不存在，它只是在页面的第一屏选择了不说。
