正在加载，请稍候
谷歌 9 月 30 日开源 AX：四个声明式原语、亚秒级挂起恢复，把智能体当有状态 Actor 跑。它与 LangGraph 们不在一个层，企业落地还有三道坎。
2026 年 9 月 30 日，谷歌开源了一套把智能体当成「有状态 Actor」来跑的运行时。它要省掉的，是企业同时养一批长跑智能体时最贵的部分——不算、不等、只挂着的空转。
无状态服务的生命周期以毫秒计，一问一答；批作业从头跑到尾，结果确定。自主智能体两者都不沾：它攒状态、突发式吃算力、一跑数小时甚至数天，中间夹着大段空白——等推理返回、等外部接口、等人工审批。
塞进传统容器编排，通常只剩两种浪费：空白期不敢回收专用沙箱，钱照付；或者换成一次性容器，冷启动又把交互延迟顶上去。谷歌在 9 月 30 日发布的 AX 正是冲这道缝隙来的：官方定位是一套声明式执行与编排运行时，Apache 2.0 许可，源码在 google/ax，产品页在 agentexecutor.io。
它的底座叫 Agent Substrate，一个专为高密度 Actor 多路复用设计的计算运行时。挂起的会话先把执行状态存成检查点，再在亚秒内恢复、没有冷启动；数十个任务复用同一批 worker 进程，把「等待时间」变成可出租的余量。官方给出的口径是单集群可扩展到十亿级并发会话。
控制平面提供四个 Kubernetes 风格的声明式元素，统一挂在 ax.io/v1alpha1 这组 API 下。分工比名字更值得记：
| 原语 | 管什么 | 典型内容 |
|---|---|---|
| Task | 执行本身 | 生命周期、CPU 与内存边界、沙箱资源引用 |
| Workspace | 开工前的环境 | 挂 Git 仓库、接工具服务器、装技能包；也可以直接用自然语言写目标，由初始化智能体代劳 |
| Gateway | 出站网络 | 主机名加端口白名单，并向出站请求注入凭据 |
| Model | 模型与密钥 | 模型参数、运行时配置、存在 Kubernetes 里的密钥统一收口 |
落地路径也不绕：ax apply 交清单，ax watch 看阶段与状态流转，ax ssh 钻进沙箱调试，ax suspend 与 ax resume 手动接管生命周期，ax delete 收尾。运维侧用 ko 把控制平面铺到 Kubernetes，Redis 落在 ax-system 命名空间，切上下文仍旧靠 kubectx。命令行本身用 Go 写成。
这是发布后讨论里最容易被混淆的一点。InfoQ 英文原报道转述 Reddit 的讨论时讲得很直接：AX 是基础执行运行时，不是高层应用编排器。差别不在功能多少，而在抽象对象：
| 维度 | 高层应用框架 | 执行层运行时 |
|---|---|---|
| 抽象对象 | 图节点、角色、对话回合 | 有状态 Actor 沙箱 |
| 关心的事 | 流程怎么串、提示词怎么传 | 资源边界、隔离、出站网络、配置 |
| 空白期处理 | 进程内原地等待 | 存盘挂起，用时再拉起 |
| 主要使用方 | 应用开发者 | 平台与基础设施团队 |
换成一句话：高层框架回答「这一步该谁做、下一步做什么」；AX 回答「这一步在哪跑、跑完怎么还回来、能不能上网、密钥从哪来」。两者叠着用不冲突，但别拿其中一个去替另一个的活。
应用层的选型同样有实证可参考：一篇基于 2700 万 token 实验的多智能体编排策略对比指出，编排方式的收益高度依赖任务形状；而Anthropic 多智能体实验里的三个工程警示提醒，框架里跑通与生产可用之间还隔着一层可观测性。
社区里做基础设施的工程师认可它省掉的空白云成本，同一批人也点出：维护 Kubernetes 集群、容器仓库和自定义 CRD 本身就是不小负担。平台团队只有两三人的话，先量一下自己有没有承接控制平面的余力。调度侧看着琐碎、上线后最先炸的往往是它，比如定时任务集中到整点该怎么加抖动这类问题的复盘，就值得提前读一遍。
安全方向的从业者反复强调 gVisor 这类隔离沙箱对控制影响面至关重要；同时被点名的早期问题包括出站代理断连与基础密钥管理。多看一层：白名单式出站策略能收紧攻击面，代价是每接一个新工具都要改清单，这份成本会落进日常迭代。
把空白期变成余量是卖点，前提是你能标出「空闲」与「活跃」的界线。同期行业讨论也在往这个方向收：InfoQ 另有一篇专谈智能体全栈账单，量子位也记录了DeepSeek 首次公开其 V4.1 训练底座 DSec——几个大厂在同一时间点谈的都是「执行与算力怎么算账」。没有埋点，声明式原语再漂亮，成本节省也只是口号。
度量口径可以先从三张账切起：算力、人力与外部调用。跨平台落地的投入产出拆解给出了可直接套用的分法，比笼统的「降本百分比」更有说服力。
还有一个误判值得单拎出来：把 AX 当成 quick start 框架来试。它更像一层计算原语，初期投入集中在集群与策略侧，适合已有平台能力的团队；只想两周内跑通一个内部小工具，桌面级方案更快。
是。Apache 2.0 许可，源码托管在 google/ax，产品与文档在官方项目站。
不构成替代关系。前者是应用层的流程编排，回答「做什么」；AX 是执行层运行时，回答「在哪跑、怎么暂停、能不能联网」。不少团队会两层并存。
从官方给出的部署路径看，控制平面用 ko 部署到 Kubernetes，Redis 部署在 ax-system 命名空间。也就是说，你至少需要一个现成集群和一套上下文管理习惯。
官方口径是单集群可扩展到十亿级并发会话，靠的是把每个任务当成轻量 Actor 并复用 worker。企业侧更稳妥的做法是按自己的并发密度实测恢复延迟与资源占用，而不是把宣传上限当成容量规划。
三件：沙箱隔离等级（gVisor 之类的强隔离）、出站白名单在新增工具时的维护流程、密钥的注入与轮换。社区点名的早期问题恰好集中在这三处。
蓝曜炬辉在做企业级 AI 应用与智能体平台的交付，执行层的选型边界是我们最常被问到的第一个问题。如果你的团队正在评估要不要自建智能体运行时，可以把上面四个原语当作对照清单，逐条问自己「谁维护、谁度量、谁兜底」；需要落地方案，可以到 www.lanyaoai.com 看我们的工程案例与交付口径。