项目详情
AX
Google 开源的 agent 编排运行时：像 Kubernetes 管微服务那样，声明式地管 agent 工作负载
更新于 2026-09-23 · 数据来源：GitHub API + README/DESIGN.md/docs（采集于 2026-09-23）
← 返回汇总
项目速览
一句话定位
Agent 是一种新工作负载，需要自己的 Kubernetes
Google 官方的开源高吞吐声明式编排器，目标单集群跑十亿级自主 agent 任务。用 YAML 声明 Task/Workspace/Gateway/Model 四个原语，AX 负责沙箱隔离、环境预热、网络围栏、规模化调度。适合要在集群里批量跑自主 agent（且不敢让它裸奔）的平台工程和 infra 团队。
项目速览
核心数据
5
Releases（v0.2.0 → v0.3.0）
2026-03-30 创建 · v0.3.0 发布于 2026-09-20（3 天前）· 356 forks · 32 open issues · Go 单仓库约 30 个核心源文件 · README 顶部挂着 WARNING：pre-stable，稳定前会有重大破坏性变更
为什么存在
Agent 是工作负载里的四不像
既不是微服务，也不是批处理
无状态微服务：横向扩容即答。Run-to-completion 批处理：跑完即散。Agent 两者都不沾——它累积状态（计划、委托、重试、分叉任务树）、调外部模型 API、没人盯着就在循环里烧钱。现有 K8s 原语（Pod/Job）装不下这个形状。
每个框架都在重造环境准备
agent 干活前要 clone 仓库、挂工具（MCP servers）、装技能包——每个 agent 框架各自发明这套 setup。AX 把它变成声明一次、处处复用的 Workspace 资源，任务启动即「热启动」。
AX 的答案：四个小原语 + 一个控制面。Task 保持刻意的小——agent 要怎么组合成任务树是它自己的事，每个节点都拿到同样的沙箱、生命周期和工具链。
核心抽象 🔥
四个原语：Task / Workspace / Gateway / Model
可独立声明的资源
Task（引用三个资源）
虚线箭头 = Task 对资源的引用
架构 🔥
控制面：Redis 状态 + Streams 工作队列
AX 自有组件
入容器组件
外部执行层（Agent Substrate）
核心机制
为什么状态不放 Kubernetes CRD
- etcd 的舒适区外：数百万短命任务做成 CRD 会顶穿 etcd——单位数 GB 存储上限、写速率瓶颈、控制面劣化。agent 任务天然是海量短生命周期对象，CRD 路线先天不良
- Redis 三件套：Hash 存资源状态、Streams 当 API server → controller 的工作队列（XREADGROUP 消费组，天然分片）、PubSub 推事件
- 无状态 API + 可扩展 worker：ax-server 不落盘随便扩；controller 池加副本即水平扩容——为「十亿任务/集群」的目标留好拓扑
- 不另起炉灶的兼容面：仍部署在 K8s 上（ax-system namespace、ko 构建、Secret 存凭据），但状态走 Redis——「站在 K8s 肩上，不压垮它的 etcd」
- atenet 网络：运行中任务经 atenet router 从集群、笔记本或 gRPC 客户端可达；CLI 自动建隧道（~/.ax/tunnels 管理后台隧道）
- kubectx 联动：CLI 跟随活动 kube context，切集群自动重连对应控制面
核心机制
phase 一词摘要，conditions 携带细节
Pending→
Provisioning→
Running↔
Suspended
·
Failed→
Terminating→
记录移除
| Condition | 何时为 True |
|---|
WorkspaceReady | 每个 workspace 完成装配，之后保持 True |
GatewayReady | gateway 的网络策略已应用到沙箱 |
Ready | 任务在跑且 WorkspaceReady 为 True——等这一个就行 |
- suspend ≠ delete：挂起会 checkpoint actor 状态再暂停（Ready→False，reason=TaskSuspended），resume 从断点继续——为「闲置即冻结」的成本模型设计
- 删除是同步的：Terminating 期间 controller 拆沙箱，ax delete 阻塞到记录彻底移除
- ax watch：server-streaming RPC，phase 和 condition 变化实时推流
上手体验
kubectl 的肌肉记忆直接复用
ax apply -f task.yaml # 多文档 YAML：Task + Workspace + Gateway + Model
ax get tasks
# NAME ATESPACE PHASE ACTOR WORKER-IP AGE
# task123 default Running task123 10.20.3.67 1m
ax watch task task123 # 实时流：phase + condition 转移
ax ssh task123 -- ls -la /workspace # 进沙箱，看 agent 在干什么（需 spec.debug: true）
ax suspend task task123 # checkpoint 挂起
ax resume task task123 # 从断点继续
- apply / get / describe / watch / delete 全套 kubectl 形状，外加 agent 特有动词：ssh（看肩膀后面）、suspend/resume（冻结/续命）
- 安装三步：go install CLI → make deploy（ko 构建控制面进 ax-system，带 Redis）→ ax apply。前提：一个 K8s 集群 + 可达的 Agent Substrate Control API
- demo.sh 一条龙：自定义 workspace → 等就绪 → ax ssh 跑命令 → suspend，完整生命周期端到端
核心能力
Workspace：让每个 agent 热启动
# workspace 一次声明，任意数量 Task 绑定复用
apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
name: golang
spec:
git:
- repo: https://github.com/golang/go.git
branch: "my-fix"
---
kind: Task
spec:
workspaces:
- name: golang
goal: "Ensure that Go tool chain is available and is built from source"
debug: true
- 三类内容：git 仓库（clone 到 workspace 子目录）、MCP servers/注册表（agent 可调用的工具）、skill 注册表（物化到指定路径）
- goal 是点睛之笔：binding 带一句白话描述，首次 boot 时 runner 把 goal 交给一个 agent 去完成环境装配（装工具链、装依赖）——任务自己的命令启动时环境已就绪
- 第一个 workspace = 工作目录，多个 workspace 各挂各的路径
核心能力
Gateway：网络围栏，防 agent 烧钱跑飞
出站 allowlist
声明沙箱可达的 host:port 白名单。典型：只放 LLM 提供商 API + git host。README 的默认 gateway 显示 EGRESS-HOSTS: *（全开）——生产环境第一件事就是收紧它。
入站 listeners
声明任务暴露的监听端口（如 8494/gRPC、8080/HTTP），经 atenet router 可从集群内、笔记本或 gRPC 客户端访问。
- 围栏的执行点在 Agent Substrate：controller 通过 Control API 下发 egress policy，不是每个任务容器里的 sidecar 自己管
- 组合成纵深防御：沙箱（CPU/内存限额）+ 网络围栏 + Model 凭据只在控制面（K8s secret，不进任务环境）——三层都是声明式资源，审计一条 YAML 全看得到
- ax describe gateway 一眼看到当前放行了什么——agent 安全审计的抓手
代码结构
单仓库 Go，边界清晰
| 位置 | 内容 |
|---|
pkg/apis/v1alpha1 | ax.proto + 生成类型：四资源 + gRPC 服务的唯一 API 契约 |
internal/server | ax-server：gRPC API 实现（校验/持久化/发事件） |
internal/store/{redis,memory} | 状态层双实现：Redis 生产版 + 内存版（测试用） |
internal/controller | reconciler + worker：消费 Streams、调和任务向期望态 |
internal/workspace | planner（goal → 环境装配计划）+ setup（物化执行） |
internal/{tunnel,substrate,guest,metadata,model} | 隧道 / Substrate 客户端 / 沙箱内 guest 客户端 / 元数据服务 / LLM 客户端 |
runner/ | task-runner 复用包：自定义镜像直接内嵌替换默认入口 |
cmd/{ax,ax-server,ax-controller,ax-task-runner} | 四个二进制入口 |
测试习惯良好：reconciler/worker/server/planner/setup/tunnel/types 全有对应 _test.go。文档成体系：concepts / manifests / sandbox / runner / networking / DESIGN / development 七篇。
在线体验
亲手管一个 agent 任务的生命周期
Playground 复刻 AX 两套核心判定：① Gateway 网络围栏——勾选出站需求生成 egress allowlist，模拟 agent 的出站请求（LLM API / git / pypi / 可疑域名）实时看放行拦截；② Task 生命周期状态机——按钮驱动 Pending→Running→Suspended 的 phase 与 condition 流转，非法转移（如挂起中直接 Ready）会被拒绝。allowlist 匹配与状态机转移均经真值表验证。
纯前端实现，零网络依赖 · egress 匹配（8 关键 case + 1000 随机）与 6 phase × 11 合法转移全组合验证
适用场景 + 风险
适合谁，警惕什么
适合
- 平台 / infra 团队：要在集群批量跑自主 agent（代码修复机器人、批量研究任务、负载生成），K8s 原语装不下的形状它接得住
- Agent 安全敏感场景：不可信 agent 代码 + 出站白名单 + 凭据不落地，三层围栏全声明式可审计
- 云原生背景的 agent 工程师：kubectl 肌肉记忆直接复用，YAML 多文档声明即上手
风险
- pre-stable 明牌：README WARNING 直接说核心概念/协议/规格还在变，稳定前会有重大破坏性变更——现在深度集成 = 追着 breaking change 跑
- 绑定 Agent Substrate：执行层是独立仓库 agent-substrate/substrate，需先部署其 Control API；整套是 Google 自家协议，社区标准未定
- Redis 状态层运维：控制面状态全押 Redis（Streams/PubSub），持久化与多可用区是自己的责任
- 上手门槛高：K8s 集群 + ko + registry + Substrate API 四件套，个人开发者本地体验成本不低
生态位
「Agent 的 K8s」这一层的竞争格局
| 路线 | 代表 | 与 AX 的差异 |
|---|
| SDK / 框架型 | LangGraph、OpenAI Agents SDK 等 | 库形态，管单 agent 内部的编排逻辑（计划/工具调用）；AX 管的是集群级的工作负载调度——互补层，框架可以作为任务跑在 AX 里 |
| 沙箱即服务型 | E2B、Daytona、Modal 等商业沙箱 | 托管代码执行环境；AX 是自托管控制面，目标十亿任务的声明式调度与生命周期 |
| CRD 扩展型 | 社区 K8s operator 方案 | 把 agent 塞进 CRD 的问题 AX 明确指出：etcd 扛不住海量短命对象——它干脆绕开 CRD 用 Redis |
AX 押注的是位置而非功能：当 agent 成为一种标准工作负载，「谁来当它的调度平面」就是下一个 K8s 级别的空位。Google 用 YAML API + kubectl 心智模型 + Apache-2.0 打标准牌——这套打法它熟。
潜力评估
未来空间
评分 8.0：把「agent 调度平面」这个空位用最正统的云原生姿势占住了——四原语抽象克制（Task 故意做小）、etcd→Redis 的工程决策有真实依据、kubectl 心智模型降低迁移成本，6 个月 7.6k stars + 月度 release 说明 Google 内部有真实负载在驱动。扣分：pre-stable 随时 breaking、Agent Substrate 依赖让整条链路偏重、单仓库贡献者仅 10 人（Google 内部主导，社区参与度待观察）。看点：v1 稳定后能否被第三方平台采用为标准调度层；atespace 多租户和 Gateway 策略表达力（目前 allowlist 较朴素）的演进。