9600 余 star、单日增长 1500+，Google 把 Agent 工作负载装进了声明式编排器。
在 Hacker News 上，一条关于 Google 开源 AX（github.com/google/ax）的讨论拿到了 500+ 分。这不是又一个 Agent 框架。LangGraph、CrewAI 解决的是"怎么写一个 Agent"，AX 解决的是"怎么在一个集群里运行几百万个 Agent"。它的官方定位是：一个高吞吐、声明式的编排器，用来在单个集群中运行数十亿级别的自主 Agent 工作负载。
Google Cloud 在 2026 年 5 月的官方博客中把它作为 Agent Executor 引入，9 月 20 日的 v0.3.0 重构之后，它以 Apache 2.0 协议落在 google org 下，登顶 Hacker News 首位，并在 GitHub Trending 上持续发酵。
Agent 是一种新的工作负载
AX 的 README 有一句核心判断：Agent 既不是无状态微服务，也不是跑完即止的批处理作业。
传统编排器的两类假设在 Agent 面前都不成立。微服务假设请求-响应短生命周期、状态外置；批处理假设确定性执行、跑完释放资源。Agent 的真实运行画像是：推理和执行工具时计算密集，等模型响应、等外部 API、等人工确认时长时间空闲。它有状态、会累积上下文、调用模型 API 会持续烧钱。
在标准 Kubernetes 上直接跑 Agent 会遇到两个具体问题：空闲等待期间沙箱空转，算力利用率低下；而容器冷启动的延迟又会拖慢 Agent 的交互循环。Agent 编排的核心指标换了：挂起与恢复的延迟取代吞吐量，成为第一指标。
四个原语，全是 YAML
AX 提供 ax.io/v1alpha1 API 组下的四种声明式资源，用 ax apply -f 一键应用，操作界面刻意做成 kubectl 的形状。
Task 是最小隔离执行单元：声明容器镜像、启动命令、CPU/内存的 requests 与 limits，环境变量，以及引用的 Gateway 和 Workspace。每个 Task 在 Agent Substrate 上以轻量 actor 形式运行，便宜到可以随意创建、挂起、丢弃。Agent 把问题拆解时可以派生子 Task 树，每个节点都获得同样的沙箱、生命周期和工具链。
Workspace 解决"开工前环境准备"这个每个 Agent 框架都在重复造的轮子。声明一次 Git 仓库（指定分支）、MCP 服务器、skill 注册表，runner 在任务启动前把它们物化到每个沙箱内。它还支持一个相当激进的特性：goal 字段接受自然语言描述，首次启动时由一个初始化 Agent 自动完成环境搭建，比如装好工具链、验证依赖。
Gateway 是网络边界：声明 Task 暴露的监听端口，以及出站流量的显式白名单（主机+端口）。一个典型配置是把 Agent 的出站流量限制到 LLM 提供商和 Git 托管两个目的地，防止提示注入引发的任意外连。
Model 名字有误导性，它其实是模型配置资源：指定 provider（google/anthropic）、模型标识、生成参数，并引用 Kubernetes Secret 里的 API key。配置集中管理后，轮换密钥或固定模型版本就是一次 ax apply，不用翻遍每个 Agent 的环境变量。
一个最小可用的 Task 长这样：
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
name: task123
spec:
image: "ghcr.io/my-org/my-agent-image"
command: ["python", "agent.py"]
resources:
limits:
cpu: "2"
memory: "4Gi"
workspaces:
- name: default-workspace
path: "/workspace"
goal: "Install dependencies and run the test suite"
gateway:
name: default-gateway
debug: true日常操作全是 kubectl 式的：ax apply、ax get tasks、ax watch task task123 实时看状态流转、ax ssh task123 -- ls /workspace 钻进沙箱调试（需开 debug: true）、ax suspend 挂起、ax resume 恢复。
底层：为什么不用 etcd
v0.3.0 重构里最有信息量的决策，是把任务状态从 Kubernetes CRD 迁到了 Redis。
数百万短生命周期任务如果存成 CRD，会把 etcd 推向极限（个位数 GB 的存储上限、写入速率瓶颈、控制面退化）。AX 的架构是：ax-server（无状态 gRPC API，校验 manifest、写入 Redis、发布事件）→ Redis（Task Hash + Streams + PubSub）→ ax-controller（水平扩展的调和 worker，用 XREADGROUP 消费 Streams，在 Agent Substrate 上供应 atespace 和 actor，应用出站策略）→ ax-task-runner（每个任务容器内的入口，引导 Workspace、提供元数据、运行 Agent 命令）。
再往下是 Agent Substrate，Google 同期开源的执行底座（同样 Apache 2.0）。它的设计逻辑是"用大量 actor 复用少量 worker"：Agent 类应用大部分时间在等待，所以把一大组 actor 映射到一小撮就绪 worker 上，靠挂起-恢复实现高密度复用。官方数据：恢复操作 sub-500ms，每秒 500+ 次挂起/恢复激活，10 倍于标准容器运行时的沙箱密度，支持 microVM 和 gVisor 两种沙箱技术。官方 demo 展示了在 8 个物理 Pod 上复用约 250 个有状态 actor，超订率 30 倍以上。
网络层同样不走常规：Task 没有 Kubernetes Service 和 Ingress，所有请求经过 Agent Substrate 的 atenet 路由器，靠一个 ate-target-actor: default/task123 头部寻址，路由器解析 actor 所在 worker，必要时先唤醒挂起的 actor 再转发。
定位与边界
AX 明确不是 LangGraph 或 CrewAI 的替代品。Reddit 上的讨论把它放回正确的层级：它是基础设施层的执行运行时，上面可以跑任何 harness——ADK、LangChain、Claude Code、Codex、Antigravity，以及任何 MCP 服务器。
也有清晰的边界：Hacker News 上有人指出这不是"Google 大 reconna officialled"的项目，仓库标注 not an officially supported Google product（指 Agent Substrate），README 顶部就警告"主动开发中，稳定版之前会有重大破坏性变更"，并且暂停接受外部 PR。运维成本也是实打实的：你需要一个 Kubernetes 集群、ko、容器镜像仓库，以及可达的 Agent Substrate Control API。
对照商业方案，AWS AgentCore 从云内部解决同一个 durable agent 问题；AX 的差异点是把整套东西开源，让你在自己的 Kubernetes 上跑，数据不出自家集群。
对要不要上手的开发者，判断依据看两点：如果你在为大量长时 Agent 会话的算力成本发愁，或者做 RL 训练需要批量可复现的沙箱轨迹，AX 的 actor 复用模型值得认真评估；如果只是跑几个 Agent 的 demo，LangGraph 加一台机器仍然更省事。
项目地址：github.com/google/ax，官网 agentexecutor.io。