AX 管任务，Substrate 管资源。Google 想给 Agent 铺一层底座——但把设计目标当成实测成绩，是读它最容易犯的错。
2026 年 9 月 21 日，Hacker News 的榜首被一个开源项目占住了一整天。664 分，299 条评论。
它叫 AX，仓库地址 github.com/google/ax，Apache 2.0，Google 出品。首页上只有一句话的自我介绍：Declare an agentic task. AX runs it at scale.——声明一个 agentic 任务，AX 帮你把它规模化跑起来。
再往下翻，是三组数字。
翻译成人话：把 Agent 当集群里的负载来管，空闲的挂起，要用的秒级唤醒。这就是"用管 Kubernetes 的方式管 Agent"的字面意思。
这篇不打算再复述一遍发布新闻。它要回答一个问题链：AX 到底是哪一层？它的四个原语各管什么？一份 YAML 怎么变成一次真实运行？它最好的一笔设计藏在哪？"百万 Agent"的密度究竟靠谁撑起来？还有，现在上它要踩哪些坑？
先把最容易搞混的地方说清楚：AX 不写 Agent，它管 Agent。
打开 google/ax 的人，第一反应常常是"Google 又出了一个 Agent SDK"。不是。
AX 不碰 Prompt 模板，不碰 Memory 抽象，不碰 Tool 定义。这些是 ADK、LangChain、LangGraph、Claude Code 这些 harness 的活。AX 站得更低一层。
共同作者 Jaana Dogan 在 Hacker News 上亲自澄清过一句，我觉得是理解整个项目的钥匙：
换成工程语言：AX 管的是"任务怎么声明、怎么调度、怎么挂起恢复、怎么审计"；Substrate 管的是"计算资源怎么在上万个 Agent 之间复用"。两者都不碰 Agent 自己的逻辑怎么写。
为什么中间非要插一层？因为 Agent 既不是无状态微服务，也不是跑完即走的批任务。它是有状态、突发、长生命周期的新负载。硬塞进现有模型，会连撞三堵墙。
第一堵是算力经济性。微服务全天占资源是合理的；Agent 却 90% 以上时间在等模型推理、等工具返回、等人回复。给每个会话常驻 1 CPU / 1G，百万并发就是百万核。
第二堵是冷启动延迟。Pod 冷启动是秒级到十秒级。一个 Python ADK Agent 初始化常常要 10 秒以上，因为要启解释器、导入依赖、构建内存对象图。一次对话中途冷启动几秒，交互体验直接报废。
第三堵是控制面吞吐。K8s 的 etcd 基于 Raft 串行提交，为"万级对象、低频更新"设计。百万级 Actor 的高频状态变更，会把 Watch 机制和 API Server 压垮。
AX 把 Agent 运行需要的所有东西，收敛成四个声明式对象。
AX 的 API 组是 ax.io/v1alpha1。全部抽象只有四个，一个不多。
| 原语 | 管什么 |
|---|---|
| Task | 在隔离沙箱里跑不可信 Agent 代码，带 CPU / 内存上限。创建便宜、挂起便宜、丢弃也便宜 |
| Workspace | 任务开始前把环境备好：Git 仓库、MCP server、技能包。也可以只写一句自然语言的 goal，让初始化 Agent 自己装 |
| Gateway | 出网策略。把流量锁到显式的主机+端口白名单，并把凭据注入到出站请求里 |
| Model | LLM 供应商参数、模型版本、密钥的统一配置点，密钥从 K8s Secret 取 |
看一份真实的清单，四个原语里用了两个：
apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
name: golang
spec:
git:
- repo: https://github.com/golang/go.git
branch: "my-fix"
---
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
读一遍就知道 AX 想干什么：Workspace 先声明"我要一个 golang 环境，代码从哪个仓库哪个分支来"；Task 再声明"在这个环境里跑一个目标——确保 Go 工具链可用、而且是从源码构建的"，debug: true 允许你 ssh 进去看。
四个原语里，最容易被低估的是 Gateway。让 Agent 跑起来不难，难的是让它只能访问该访问的东西。Agent 会自己生成代码、自己发网络请求，出网一旦不受控，一次提示注入就可能把数据发到外面去。Gateway 用一个主机+端口白名单把这条口子收紧，凭据还在沙箱够不到的地方注入——Agent 自己看不到密钥。
而 Model 看着最不起眼，却是运维上最省事的那个：轮换一个密钥、钉一个新模型版本，改一处 apply 一下就行，不用去翻每个 Agent 的代码。
AX 的 CLI 照着 kubectl 的形状做，用惯 K8s 的人十分钟上手。
ax 是个 Go 写的命令行工具，背后是 gRPC 控制面。控制面部署进 ax-system 这个 namespace，用 ko 构建镜像，配一个 Redis。前提是，先有一个 Agent Substrate。
装、部署、提交任务，全流程是这样：
# 装 CLI go install github.com/google/ax/cmd/ax@latest # 部署控制面（需要先有 Substrate） make deploy AX_IMAGE_REPO=<your-registry> # 提交任务 ax apply -f task.yaml # 看状态 ax get tasks ax watch task task123 # 实时看 phase / condition 变化 # 钻进沙箱，看 Agent 到底在干嘛 ax ssh task123 -- ls -la /workspace # 手动挂起 / 续跑 ax suspend task task123 ax resume task task123
基础动词和 kubectl 一一对应：apply、get、describe、watch、delete。在这之上，多了几个 Agent 专属动词：suspend（检查点暂停）、resume（原地续跑）、ssh（进沙箱）。
这些动词里，suspend/resume 是灵魂。它对付的是 Agent 的"空闲成本"——没人等的 Agent 挂起，需要时从断点继续，而不是从头再跑一遍。
还有一个细节说明它想清楚了生产场景：kubectx 集成。你手上有多个集群时，切一下上下文，ax 会自动解析并隧道到对应集群的控制面，不用再手动配一堆 kubeconfig。
AX 内置了 Antigravity harness，直接支持 Google AI Studio 和 Vertex AI。但它是harness 无关的——官方明确列举了 LangChain、LangGraph、ADK、Claude Code、MCP server 都能跑上去。这一步很关键：它没把用户锁在自己的框架里。
四个原语里，Workspace 最能说明设计者真的跑过 Agent。
Agent 的成本大头，不在推理，在冷启动。
每来一个新任务，都要重新拉代码、装依赖、接工具服务器、等环境就绪。一个 Python 环境装完十几个包，几分钟就没了。你花在"等环境"上的钱，经常比花在"跑任务"上的还多。
Workspace 就是冲着这笔账来的。它把要做的事提前声明清楚：要哪几个 Git 仓库、哪个分支；要连哪些 MCP server；要装哪些技能包。
AX 会在每个沙箱启动之前把这些全部备好。Agent 一睁眼，工具链就是热的，不用等。
更有意思的是"生成式 workspace"。你甚至不用列清单，直接用一句自然语言描述"一个就绪的环境长什么样"：
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
name: data-analysis
spec:
workspaces:
- name: python-env
goal: "Set up a Python 3 development environment"
首次启动时，AX 会把这句话丢给一个初始化 Agent，让它去装工具链、验证依赖。同一个机制，也让 demo 里那句 "Ensure that Go tool chain is available and is built from source" 成立——它不只是检查 Go 在不在，而是真的从源码把 Go 构建出来。
回头看，这个设计比"声明式编排"的口号实在得多。它承认了一个常被忽略的事实：Agent 的成本结构和微服务不一样，热环境本身就是要花钱买的资源。与其让每个任务从零冷启动，不如把环境做成可复用的模板，把冷启动成本在模板层摊掉。
AX 管任务，但让任务在百万量级上待得起的，是它脚下的 Substrate。
先说问题的形状。Agent 长时间在等：等模型吐字、等工具返回、等人点确认。这期间它占着的 CPU 和内存如果不能放出去，规模一大，账单就撑不住。
AX 的解法是 suspend/resume：空闲的 Agent 被检查点、挂起，资源释放；下一个请求到达时，从断点亚秒恢复，零冷启动。官方给的目标是恢复低于 500 毫秒。
这条能力来自它脚下的 Agent Substrate。核心抽象几个词就够：
关键是：Actor 不与任何具体 Worker 绑定。空闲时，系统对 Actor 做一次全量快照（进程内存 + 文件系统），写进本地磁盘和 Google Cloud Storage，然后释放 Worker 回池。下一个请求来时，快照被恢复到任意一个空闲且兼容的 Worker 上。逻辑生命周期和物理资源，就这样彻底解耦了。
快照分两级。创建 ActorTemplate 时，Substrate 会临时把负载跑起来、等就绪、打一次全量检查点，得到 golden snapshot。新 Actor 从这个共享检查点起步，省掉整个冷启动路径；之后每次挂起，写入该 Actor 专属的 last snapshot，下次恢复的是它自己那一份。这就是"有状态"的来源。
三个动作串起整个密度故事：挂起时把状态拍成快照，恢复时把快照贴回任意一台空闲 Worker。
官方给的指标是：比标准容器运行时密度高 10 倍，沙箱恢复低于 500ms，每秒 500 次以上挂起/恢复，单主机承载 1000 个以上休眠 Agent。仓库的演示更直观：250 个有状态会话挤在 8 个物理 Pod 上，也就是 30 倍以上超售。
它解决的痛点是真的，但它离"拿来就能上生产"还有距离。
Hacker News 那条帖子下面，社区分成了两派。基础设施工程师感谢它——它正面回答了"空闲 Agent 云成本"这个没人愿意碰的问题。另一边的开发者则吐槽"ergonomic"的营销口径，跟"你得自己维护 K8s 集群、镜像仓库、还要用 ko 管 CRD"的现实对不上。
两派说的都对。它确实解决了真问题，也确实不是给想快速起步的独立开发者准备的。
几条硬约束，值得记在本子上：
把它放进已有方案里比一比，位置会更清楚：
| 方案 | 优势 | 代价 |
|---|---|---|
| 传统 K8s | 1 Agent ≈ 1 Pod，简单、可靠、生态成熟 | 空闲资源浪费；百万对象时 etcd 与控制面撑不住 |
| Knative | 无状态函数冷启动快，scale-to-zero | 不保留进程内存和文件系统，会话必然断裂 |
| CRIU | 容器检查点，Linux 内核原语成熟 | 长期停在 Alpha，延迟不稳定，覆盖不到沙箱级状态 |
| AX + Substrate | 有状态挂起 + 亚秒恢复 + 30× 超售 | 极早期；快照强依赖 GCS；旁路控制面带来一致性自负 |
差别最本质的地方在状态。Knative 卖的是无状态函数的零缩放；Substrate 卖的是有状态挂起——内存、打开的文件、终端状态原样保留。它填的正是这个空白。
那谁该现在上？已经有 K8s 团队、并且工作负载是"大量并发会话、但单次调用很短"的平台团队：编码助手、后台长驻助理、RL rollout、一次性沙箱、评测基准。对这类团队，Substrate 的思路值得直接搬进基础设施规划。
谁该再等等？想快速起步的独立开发者。对你们，一条托管的路线大概率更省事。
把几个落点收一下。
把镜头拉远一点看，Agent 运维层这块已经分出两条路。一条是托管：沙箱、状态、权限全包，你接 API，基础设施交给厂商。一条是自托管：K8s 声明式，在你自己的集群里跑，数据不出域。
没有谁对谁错。真正值得注意的信号是：两条路都承认了同一件事——Agent 的沙箱、状态、网络、调度，是一个独立的基础设施层，不能再塞进应用代码里自建。分歧只在谁运营这一层。
至于 Agent 基础设施最后会像容器编排一样收敛到某一个项目，还是各大厂各搞一套、再次碎片化，现在还没有答案。AX 把问题摆上了桌面，但还没到能给出答案的时候。