正在加载，请稍候
谷歌 2026 年 9 月开源的 AX，把智能体编排拆成 Task、Workspace、Gateway、Model 四个声明式原语，靠亚秒级检查点解决空闲空转与冷启动。
跑不稳的智能体，问题多半不在模型，而在底座放错了位置：当无状态服务部署会丢状态，当批处理作业跑又让隔离环境白白空转。谷歌在 2026 年 9 月底开源的这套编排器，正是冲这个错位来的。
Kubernetes 的两个原生抽象——无状态 Deployment 和 Job——都假设了一个并不成立的形状。当成无状态服务跑，Pod 围绕「随时可被杀掉重建」设计，可上下文、中间产物、工具调用记录本身就是智能体工作的一部分，重启即失忆，要补齐就得再搭一层外部状态存储，编排责任又背回应用侧。当成批处理作业跑，则假设「启动—跑完—退出」，而真实负载是密集算一分钟、然后等模型响应、等工具返回、等人工审批，一停几十秒到几分钟；这段等待里资源照占，缩容回收后下次拉起又得付冷启动代价，交互循环被拖慢，用户侧的感觉就一个字：卡。
官方对这类负载的定义很直接：有状态的、突发的、长跑的执行单元——compute intensely for a minute and then wait。它没在容器编排器上打补丁，而是把「任务」「环境」「网络」「模型」四件事抽成声明式原语，交给一层专门的控制面。官网管这层叫 declarative control plane，它跑在谷歌另一套运行时 Agent Substrate（下称底座运行时）之上。
所有资源都是 ax.io/v1alpha1 的 manifest，一条 ax apply 落地。官方仓库与核心概念文档把它们拆成四个。需要点明：早期 README 只列了三个（Task、Workspace、Model），Gateway 是官网上（更新）补进的第四个，可见项目仍在快速迭代。
隔离执行的最小单位：声明容器镜像与命令、CPU/内存的上限、环境变量，以及挂载哪些工作区。它被刻意做小——不建模「一个智能体从规划到交付」的完整形态，只给一个「创建、隔离、挂起、丢弃都便宜」的原子，由上层按需组合成任意多份：一次可以是整件事，也可以是一棵树的根。状态写在 status.phase（Running、Suspended、Failed、Terminating），细节在 condition：WorkspaceReady 表示环境就绪且此后保持 True，Ready 表示在跑且环境就绪——这才是该等的信号。
解决「每份工作都要重复搭环境」。声明式列出要 clone 的 Git 仓库（含分支）、可调用的 MCP 服务器与注册表、技能包及其落盘路径；声明一次、绑给任意多份，runner 会在每个隔离环境里、命令启动前物化好。更省事的是 goal 字段：用自然语言描述「就绪环境长什么样」（如「装好 Python 3 开发环境」），首启时交给一个智能体去装工具链、验依赖，官方叫 generative workspace。
管出站网络策略：把流量锁到一份显式的主机 + 端口 allowlist，并把凭证注入到出站请求上。对跑不可信代码的场景，这是把「能连哪里、用什么身份连」从代码收回平台层。
模型提供商及其参数的配置：调哪家、模型标识、生成参数（如 max_tokens），以及指向 Kubernetes secret 的凭证引用。做成集群资源后，换 key、固定新版本、调参都是一次 ax apply，不必去每份定义里翻找。
| 原语 | 管什么 | 关键点 |
|---|---|---|
| Task | 隔离执行 + 生命周期 | 镜像/命令、CPU·内存限额、挂载工作区；phase/condition 表达状态 |
| Workspace | 执行前环境组装 | Git 仓库、MCP 服务器、技能包；goal 自然语言描述环境 |
| Gateway | 出站网络治理 | 主机+端口 allowlist、凭证注入 |
| Model | 模型配置 | provider、模型标识、采样参数、secret 引用 |
这是它相对通用编排器最值钱的一点。等模型、等工具、等人工的空闲实例会被检查点后挂起，恢复不到一秒，且无冷启动——官网原话是 under a second with zero cold-start delay。
账很好算：若每轮「思考 + 执行」15 秒、等待 45 秒，利用率只有 25%。批处理模型下那 75% 的等待也要占住 CPU 和内存；它则把空闲实例检查点、挂起，工作节点资源立刻释放给别的作业——几十份工作密集复用同一批算力（dense multiplexing），只有真正在「想」和「跑代码」时才付钱。
恢复为何能压到亚秒级？网络文档给了答案：作业不单独拿 Service 或 Ingress，请求统一走底座运行时的 atenet 路由，只带一个 ate-target-actor 头（值 atespace/task）；路由器定位到目标所在的工作节点，若它挂起就先唤醒再代理。唤醒被合进路由这一跳，调用方无感知，也就没有传统意义上的冷启动。
路线图里有两个动作值得跟：一是空闲检测 + 自动挂起（看进程、I/O、网络与 gRPC/SSH 会话，自动回收资源），二是有状态分叉（把运行中或挂起中的工作连同检查点内存与文件系统，fork 成多条并行分支做投机执行）。后者意味着「恢复」会从「续跑」扩到「分叉探索」。
三者常被混讲，其实正交互补。MCP 管「怎么接工具和上下文」，是调用侧接口；A2A 管「智能体之间怎么协作」，定义同行协议；AX 管「在什么隔离环境里跑、能并发多少、怎么挂起恢复」，属于执行与编排层。一句话概括：前两者决定「说什么话」，AX 决定「在哪儿说、一次能说多少轮」。协议分工的细节，站内MCP vs A2A 协议选型实战讲得更透。
网关原语是把出站治理收回平台层的那块。落地可用三条判据自查：
第三点最容易被忽略：把「拉代码」与「跑代码」塞进同一容器、用同一套凭证，等于把源码仓库的钥匙递给不可信代码。路线图已把这两类身份拆开，并规划用 SPIFFE 做零信任 mTLS——这属于治理层的范畴，站内《为什么治理层必须与模型解耦》有专门讨论。
两条路：官方托管的 agentexecutor.io，或在自己集群自建（控制面落 ax-system，依赖一个底座运行时与 Redis）。对大陆团队，取舍更多在合规与运维，而不在功能。
| 维度 | 自建 | 托管 agentexecutor.io |
|---|---|---|
| 部署成本 | 需 K8s + 底座运行时 + 控制面（含 Redis），自己运维 | 免运维，开箱即用 |
| 版本跟进 | 需专人跟 pre-1.0 的破坏性变更 | 平台侧负责升级 |
| 数据与合规 | 数据不出境，出站策略完全可控 | 需评估跨境访问延迟与数据出境合规 |
| 适配场景 | 已有 K8s 团队、强合规、要接内网工具 | 快速验证、无运维资源 |
选自建，先确认四条前提都满足：
api.ate-system.svc.cluster.local:443 暴露控制 API；部署前先 kubectl get svc api -n ate-system 确认它活着。make deploy 走 ko 构建部署，过程会一并拉起 Redis。最后提醒：它解决的是执行与编排层——跑得稳、恢复快、隔离得住。它不解决工具调用的治理与审计（那是Dogwood 给工具调用立规矩要回答的），也不设计隔离边界（从沙箱到产线的 4 个工程门槛更细）。蓝曜炬辉（www.lanyaoai.com）在做 AI Agent 平台选型时的做法是：先把层切开再选底座，比先买底座再补层便宜得多；站内《执行边界的五类矛盾与分层清单》给了一张可对照的分层表。
不同层。LangGraph 这类是应用侧编排框架，管单个智能体内部的推理步骤与状态机；AX 是集群侧执行层，管工作落在哪个隔离环境里跑、能并发多少、怎么挂起恢复。前者决定怎么想，后者决定跑在哪。
是。每份工作都被调度为它上面的隔离实例，底座必须先跑起来并暴露 Control API，AX 才能部署。两者分工：底座管隔离与实例生命周期，AX 提供面向智能体的抽象。
不稳定。官方标注 heavy development，稳定版之前会做破坏性变更；适合技术验证和早期试点，不适合压上核心生产链路又不留回退方案。
空闲实例被检查点后挂起，工作节点资源释放；请求到达时 atenet 路由器读取 ate-target-actor 头定位目标，若已挂起则先唤醒再代理。唤醒合进路由这一跳，调用方无感知，也就没有传统意义上的冷启动。
NetworkPolicy 管 Pod 之间的 L3/L4 连通性；AX 的网关面向出站场景，除主机+端口 allowlist 外，还负责把凭证注入出站请求，两者互补而非替代。