把 Agent 当集群工作负载管Google AX 的四个原语和一次状态大搬家TL;DR 速览要解决的问题Agent不是无状态微服务、也不是跑完就退的批处理——它攒状态、要隔离、会调外部 API而且没人盯着就会在循环里烧钱四个声明式原语Task隔离沙箱/Workspace预连线 Git、MCP、技能包/Gateway出站锁到显式白名单/Model平台自身用哪个 LLMCLI 刻意做成kubectl的形状ax apply/get/describe/watch/delete外加ax ssh钻进沙箱、ax suspend/ax resume挂起恢复v0.3.02026-09-20拆成三个二进制ax-servergRPC/ax-controllerRedis Streams/ax-task-runner沙箱 worker任务状态从 K8s 自定义资源搬去了 Redis上生产前必须知道API 是v1alpha1README 自带 Warning——核心概念仍在打磨稳定版之前很可能出破坏性变更Google 开源了 AX定位是高吞吐、声明式的编排器用来在集群里跑数十亿自主 Agent 工作负载底层依赖 Agent Substrate 提供沙箱化执行。它刚发布v0.3.02026-09-20仓库 ★4.2k、Apache-2.0、Go 编写。同时ax这个 CLI刻意做成kubectl的形状——如果你用过 K8sax apply那一套不需要重新学。它值得写不是因为又一个 Agent 框架而是因为它把一件被大多数框架绕开的事摆到台面上Agent 在集群里的资源画像和以往任何一种工作负载都不一样硬塞进 K8s 的既有抽象会同时踩三个坑。这篇文章拆它的原语设计、v0.3.0 那次状态搬家以及现在能不能上生产。一、K8s 为什么跑不好 AgentAX 官方文档里有一段判断很直白Agent 既不是无状态微服务也不是跑到结束就退出的批处理作业。把 Agent 硬塞进这两种抽象会撞上三个具体的错配特征Agent 的真实行为与既有抽象的冲突有状态会话中累积上下文、工具结果、中间计划无状态服务假设可以随时被替换、被重建突发 长等待等模型 API、等工具返回、等人审批干一分钟挂十分钟K8s 的调度与健康检查基于一直在干活的假设冷启动敏感沙箱要装工具链、拉 Git 仓库、验依赖容器冷启动 依赖安装的时间可能比真正干活的时间还长第三点是最容易被低估的。一个 Agent 任务如果实际执行 30 秒但环境准备要 90 秒那集群的吞吐就被准备时间锁死了。所以 AX 把预连线环境做成了独立的原语Workspace而不是让每个任务自己装一遍。还有一个 K8s 生态里的隐性成本把每个 Agent 任务都表达成一个自定义资源任务数量一大etcd 会先扛不住。这正是 v0.3.0 那次架构搬家的直接原因下面第四节细讲。二、四个原语一条 YAML 里的四种约束AX 把所有东西都表达为ax.io/v1alpha1的 manifest一条命令 apply 下去。四个原语对应四类约束你想要AX 给的约束类型在隔离沙箱里跑不可信 Agent 代码带 CPU/内存限制Task执行边界预连线 Git 仓库、MCP 服务器、技能包让每个 Agent 一启动就是热的Workspace启动成本把出站流量锁到一份显式主机白名单Gateway网络边界配置平台自己用哪个 LLM凭证从 Kubernetes Secret 取Model平台自身的模型依赖看一条最小的任务定义能直观感受这套设计的取舍# task.yamlapiVersion:ax.io/v1alpha1kind:Workspacemetadata:name:golangspec:git:-repo:https://github.com/golang/go.gitbranch:my-fix---apiVersion:ax.io/v1alpha1kind:Taskmetadata:name:testspec:workspaces:-name:golanggoal:Ensure that Go tool chain is available and is built from sourcedebug:true# 打开后才能 ax ssh 进去两个细节值得单独拎出来第一Workspace的goal是自然语言。上面那句确保 Go 工具链可用且是从源码构建的不是给脚本解析的指令是交给 Agent 在首次启动时自己去装工具链、自己验依赖的目标描述。这是这套设计里最激进的一处取舍环境准备本身也变成一个 Agent 任务。好处是不用为每种技术栈写一份 Dockerfile代价是环境构建变得不确定——同一份 goal 两次跑出来可能不同。第二debug: true是进沙箱的前提。默认状态下你进不去运行中的沙箱必须先显式打开。也就是说**可观测在这里是被设计成一个开关的而不是默认能力**。生产环境下这个默认值是安全的但排查问题时别忘了它。三、CLI刻意做成 kubectl 的形状ax通过 gRPC 与控制平面通信命令集和 kubectl 高度对应。日常动作长这样ax apply-fexamples/task.yaml# 一份文件里可以同时放 Task Workspace Gateway Modelax get tasks# 列表axwatchtask task123# 流式看 phase 与 condition 变化axsshtask123 --ls-la/workspace# 钻进沙箱跑一条命令axsuspendtask task123# 检查点并暂停ax resume task task123# 从断点继续ax watch和ax suspend/ax resume是这套 CLI 里最有信息量的两个。watch输出的是phase 与 condition 的迁移流。这直接对应第一节说的突发 长等待——一个 Agent 大部分时间在等你真正需要看的不是它在不在跑而是它卡在哪个阶段等模型、等工具、等审批三种状态的处置完全不同。suspend/resume官方给的是亚秒级的挂起恢复。它的价值不在省资源而在成本控制一个等人工审批的 Agent 如果一直挂着占沙箱那条沙箱和它预装好的环境就一直在计费能挂起就意味着等待这段时间可以不占执行资源。还有ax ctx和后台 tunnel 这两个小设计值得注意ax跟随当前 kube context切集群之后它会自动解析并在后台建隧道连到那个集群的控制平面状态存在~/.ax/tunnels。这让本地 CLI 不用手配一堆 server 地址代价是多了一个后台常驻进程——排查连不上控制平面的问题时记得先看这个隧道。四、Gateway网络出口才是成本闸门Gateway是四个原语里最容易被略过、但在生产里最该先配的一个出站流量锁定到显式主机白名单凭证注入——Agent 代码不直接持有密钥为什么这条重要因为 Agent 最常见的失控形态不是崩溃而是在循环里调用外部 API。模型调用、搜索 API、第三方工具只要有凭证、只要没有被拦住一个写错的循环就能在几十分钟里产生一张很难解释的账单。把出站限制成白名单等于给失控设了一个物理上限它最多只能打到你在白名单里放行的那些主机上。这在工程上比事后审计有效得多——审计是发现已经花掉的钱白名单是让钱花不出去。判断有没有必要现在就配它用一个简单的问题你的 Agent 需要访问的主机你能不能列清楚能列清就配白名单列不清说明这个 Agent 的边界还没设计完。我给这类平台做接入评估时第一步不是看它的能力清单而是列一份它默认能连到哪、能读到什么、能写回哪里的三栏表再逐条问这一项我需不需要显式关掉。这份表比读文档快也比事后审计便宜。我的表模板和几个平台的实测结果攒在 墨衍 里跟选题素材放一起回头做选型时直接调出来比。五、v0.3.0 那次搬家状态为什么必须离开 etcdv0.3.0 的核心变化是把单体拆成三个二进制二进制职责ax-server对外 gRPC 服务CLI 和客户端连的就是它ax-controllerreconciler基于Redis Streams做横向扩展ax-task-runner沙箱内的 worker负责实际执行最关键的一行信息是任务状态从 K8s 自定义资源搬到了 Redis。官方给的理由也很直白——为了容纳海量短命任务而不压垮 etcd。这条经验值得单独记下来。把每个任务一个自定义资源当成设计起点很自然但它有一个隐含的容量假设任务数量在 etcd 能承受的量级内且任务寿命不会太短。Agent 负载两条都不满足——数量可能极多单个寿命可能只有几十秒。用 K8s 存任务状态等于用一个为稳定配置设计的存储去扛高频短命对象的写入量这不是调参能解决的得换存储。同时这个版本做了减法移除了旧的 Python harness、ATE client、SQL 事件日志和 skill 示例。删掉的东西往往比新增的更能说明项目走向——移除 Python harness 意味着他们认定了runner 只需要一个实现而不是维护多语言并行方案。六、现在能不能上三个明说的风险AX 的 README 里自带一段Warning原文意思是核心概念、协议与规范仍在积极打磨在稳定版之前很可能会引入重大破坏性变更。配套的事实是 API 版本号还处在v1alpha1。具体到落地风险有三层API 会变。ax.io/v1alpha1意味着你写的 manifest 在升级时有很大概率要改。现在接入的正确姿势是当容器编排层用不要把它嵌进自己的产品契约里。依赖一个不算轻的底座。要跑控制平面需要 Kubernetes 集群、ko、一个集群能拉的镜像仓库以及一个可达的 Agent Substrate Control API。这是一套完整的集群依赖不是本地起的单二进制。它是声明跑数十亿任务的项目但公开的稳定能力还在早期。这个规模目标的表述是设计意图不是当前实测结果评估容量时不要按这个数去规划。综合下来的判断如果你的团队已经在用 K8s、并且已经在为Agent 任务怎么编排自己造轮子AX 现在值得进沙箱环境试——它能省掉的是自己设计 Task/Workspace/Gateway 语义这一步以及 v0.3.0 已经替你做掉的状态存哪儿的决策。反过来如果只是想在自己的笔记本上跑几个 Agent 任务这套东西的重量级远超需求一个进程内调度器就够了。它真正的价值可能不在当下能不能用而在于它给出了一组候选答案Agent 的工作负载抽象该叫什么、环境该不该被声明成自然语言目标、网络出口该不该变成一等原语、任务状态该不该离开 etcd。这四个问题每个做 Agent 平台的人迟早都要回答一遍——有人已经把答案开源出来了哪怕还带着 alpha 标签。