发布全景：四个月走完的三步
AX 是 Google 开源的智能体编排运行时，定位为「高吞吐、声明式的编排器，用于在单个集群内运行数十亿个自主智能体工作负载」。仓库位于官方 google 组织下，采用 Apache-2.0 许可证，主体语言为 Go，文档站为 agentexecutor.io。从公开时间线看，项目推进速度相当快：
| 时间 | 节点 | 说明 |
|---|---|---|
| 2026-03-30 | 仓库创建 | github.com/google/ax 上线，Apache-2.0 |
| 2026-05-26 | 公开宣布 | README 即警示「稳定版之前可能出现重大破坏性变更」 |
| 2026-07-23 / 08-13 | v0.2.2 / v0.2.3 | 旧 Python harness 架构的最后两个版本 |
| 2026-09-20 | v0.3.0 | 提交标题「Restructure AX into a general-purpose orchestration layer for agentic tasks」，任务状态迁出 Kubernetes CRD，新增 Gateway |
| 2026-09-20 前后 | 社区热度 | 登上 Hacker News 头条（533 至 600 余分，不同快照口径不一），截至 9 月 22 日约 5,635 stars / 236 forks |
需要提醒的是，上述 star 数与 HN 分数来自第三方技术博客的不同时间快照，仅作热度参考；真正有信息量的是版本演进本身——v0.2 系到 v0.3.0 不是增量修补，而是一次运行时重构。
设计命题：智能体为什么是新型工作负载
AX 的 README 把整个项目建立在一个判断上，值得完整引用：
「智能体是一种新型的计算工作负载。它们既不是无状态微服务，也不是一次性批处理任务。它们会累积状态，需要严格隔离，要调用模型 API 和工具服务器，而且如果没人盯着，会在循环里把钱烧掉。」
这个判断解释了 AX 的每一个设计取舍：
- 「累积状态」——传统 K8s 假设 Pod 尽量无状态，而长程智能体任务的中间产物、会话上下文、文件系统变更都必须可恢复；
- 「严格隔离」——智能体运行的是不可信代码，每个任务需要独立沙箱，而不是共享容器池；
- 「调用模型 API 和工具服务器」——出网策略、密钥注入、网关管控需要成为一等能力，而不是事后加固；
- 「在循环里烧钱」——可观测性、暂停/恢复、成本上限必须内建，否则一个失控的智能体就是一台印钞机的反向版本。
Google 的隐含判断是：智能体时代的稀缺资源不是模型，而是控制平面。动态调度、断点恢复、自动故障恢复、审计，这些能力被 AX 视为一等公民，而不是智能体平台出事之后再补的胶水代码。
四个原语与 kubectl 式交互
AX 的 API 设计刻意向 Kubernetes 靠拢：所有配置写成 ax.io/v1alpha1 清单，用一条 ax apply 提交。官方 README 列出的核心原语与操作如下：
| 原语 / 命令 | 职责 | 官方描述 |
|---|---|---|
| Task | 隔离沙箱中的执行单元 | 在带 CPU/内存限制的隔离沙箱中运行不可信智能体代码 |
| Workspace | 预置执行环境 | 预先挂载 Git 仓库、MCP 服务器与技能包，让智能体「热启动」 |
| Model | 平台自身所用模型的配置 | 指定控制平面使用哪个 LLM，凭据来自 Kubernetes Secret |
| Gateway | 网络围栏（v0.3.0 新增） | 第三方报道将其描述为「围住网络的网关」，管理任务出网 |
| ax suspend / ax resume | 暂停与恢复 | 暂停空闲智能体，并从断点处精确恢复 |
| ax ssh / ax watch | 观测与介入 | 钻进运行中的智能体查看它正在做什么；流式跟踪任务阶段 |
一个典型的任务清单长这样（源自官方 README）：先声明一个挂载 Go 仓库的 Workspace，再声明一个引用该 Workspace 的 Task，然后 apply、watch，需要时直接 ssh 进沙箱检查文件系统。CLI 只提供 apply、get、describe、watch、delete 加少量智能体专用动词——任何用过 Kubernetes 的工程师，官方的说法是「大约十分钟就能上手」，这显然是有意为之的迁移策略。
值得注意的是 suspend/resume 的语义：暂停一个「在等模型响应或等工具回调」的空闲智能体，恢复时从内核快照断点继续。这把「按秒计费但大部分时间在等 IO」的智能体工作负载的利用率问题，变成了调度器问题。
Agent Substrate：底层的执行运行时
AX 并不亲自执行任务。它把每个 Task 调度为 Agent Substrate 上的一个轻量级 actor——这是 Google 拆出来的独立项目（agent-substrate/substrate），v0.3.0 同期已发布 v0.1.0。两者的分工：
- AX 层：管意图与状态——任务清单、阶段与条件、网关与模型配置，通过 gRPC 与 CLI 通信；
- Substrate 层：管隔离与执行——workspace 置备、actor 激活、节点分配、出网策略过滤。Substrate 落在集群的 ate-system 命名空间，暴露 Control API 供 AX 对接。
第三方技术分析普遍把 Substrate 的三个特性视为这套方案真正的护城河：其一，actor 密度——为智能体而非容器设计的运行时，把数十个任务复用到共享 worker 资源上；其二，亚秒级 checkpoint/suspend/resume——空闲智能体不再空烧算力；其三，基于内核快照的轨迹分叉——把一个运行中智能体的完整状态复制出两份、从同一节点探索两条未来路径。第三点被评论者认为不是调度功能，而是调试与搜索功能：它让「对同一任务做两次不同决策的 A/B 对照」变成一次 fork 操作。
AX 依赖 Kubernetes 集群 + Agent Substrate 先行安装，还需要 ko 与容器镜像仓库来完成构建。这意味着它今天的适用面是有平台工程团队的组织——个人开发者想跑一个 Agent，这条技术栈明显过重。
v0.3.0 的关键改动：状态搬出 etcd
v0.3.0 最重要的架构动作，是把任务状态从 Kubernetes 自定义资源（CRD）迁入 Redis Streams。官方重构提交的标题本身就说明了定位变化——AX 从「Kubernetes 上的一个 CRD 扩展」变成「通用的智能体任务编排层」。
为什么要搬？etcd 是 Kubernetes 集群的一致性基石，它擅长存「少量、强一致、生命周期长」的对象；而大规模智能体平台面对的是「海量、高频变更、生命周期以分钟计」的任务状态。按第三方报道的表述，Google 在这里撞上了「etcd 不再是存放数百万可变智能体状态的合理位置」这堵墙，于是把状态层路由到为高吞吐写入设计的 Redis Streams，同时把 AX 拆成三个服务：API 前端、reconciler（调谐器）与沙箱化任务运行器。
这个改动值得所有自建智能体平台的团队记住：当你的任务状态量级从「千」走向「百万」，编排层的数据面选型就要跟着换。这是只有真正运行过大规模智能体集群才会积累的「伤疤组织」（scar tissue）——评论者普遍认为这类工程细节比功能列表更有信息量。
与现有编排方案的对照
| 维度 | AX + Agent Substrate | Kubernetes + 自建 CRD | 队列 + Worker 自拼方案 |
|---|---|---|---|
| 状态存储 | Redis Streams（v0.3.0 起） | etcd（CRD 对象） | 数据库或消息队列，各自为政 |
| 沙箱隔离 | Substrate actor，按任务隔离 | 容器/Pod，需自行加固 | 自行封装 |
| 空闲暂停/恢复 | 内核快照级 suspend/resume | 无原生支持 | 通常直接杀死重跑 |
| 出网管控 | Gateway 原语 | NetworkPolicy，粒度粗 | 代理脚本，脆弱 |
| 轨迹分叉调试 | 内核快照 fork | 无 | 无 |
| 成熟度 | v0.3.0，官方明示破坏性变更 | 成熟稳定 | 取决于团队 |
这张表的公允读法是：AX 用成熟度换能力密度。Kubernetes 加自建 CRD 的路线更稳，但智能体特有的状态、隔离与成本控制都要自己补；自拼方案灵活，但把最难的分布式一致性工作留给了团队自己。
局限与冷思考
- API 尚未稳定：README 至今保留「稳定版之前可能出现重大破坏性变更」的警示，ax.io/v1alpha1 的 v1alpha1 后缀本身就是承诺等级的声明。现在深度绑定的团队要预留迁移成本。
- 技术栈门槛高：Kubernetes + Substrate + ko + 镜像仓库的组合，决定了它的目标用户是平台团队。单一智能体应用开发者用框架层的编排（工作流引擎、Agent 框架内置调度）通常已经够用。
- 基准数据缺失：截至目前，官方与第三方均未给出「数十亿任务」这一目标的公开基准测试数据，actor 密度与恢复延迟等关键指标暂无法独立验证。
- 治理问题没有因编排而消失：权限分级、审计合规、成本告警有了挂载点，但策略内容仍要组织自己写——控制平面解决的是「机制」，不是「政策」。
- 生态位仍在争夺中：OpenAI Agents API 的托管沙箱伙伴路线、Anthropic 的 Managed Agents 路线走的是厂商托管路线，AX 走的是自托管开源路线。两条路线的胜负未分，选择本质上是「控制权与运维成本的交换」。
目前官方及行业暂未披露更多细节（如 v0.3.0 之后的稳定版时间表、Substrate 的商业化策略、与 Google Cloud 托管服务的关系），后续将持续跟进迭代动态。