Google开源AX：多智能体有了运行时

Google正在把多智能体竞争从模型和Prompt层，推进到基础设施层。

2026年5月20日，Google正式开源了Agent Executor，简称AX。这是一套面向长时间运行智能体的分布式执行与编排运行时，负责处理智能体的隔离、状态保存、暂停恢复、网络访问和大规模调度。Google在GitHub仓库中将它描述为“Google's open agentic orchestrator”，但需要先澄清：Open Agentic Orchestrator更像是项目定位语，正式项目名称是Agent Executor，仓库名为google/ax。(cloud.google.com)

截至2026年9月21日，AX的最新公开版本是v0.2.3，于2026年8月13日发布。项目仍处于Preview和active early development阶段，官方明确提示核心概念、协议和规格可能继续发生重大变化。因此，AX现在更像一块正在快速成形的开源底座，而不是可以直接采购、稳定交付的成熟平台。(github.com)

AX到底是什么

Agent Executor（AX）是一个为长时间运行、可恢复、需要隔离环境的AI智能体设计的分布式执行运行时。

AI智能体编排是指由一个调度层拆解任务、选择合适的子智能体或工具，并管理它们之间的执行顺序、状态和结果。过去，开发者通常把这部分逻辑写在LangGraph、ADK、CrewAI或自研工作流里：一个Agent负责规划，几个子Agent负责搜索、写代码、分析数据，最后再由主Agent汇总结果。

但当系统进入生产环境，真正麻烦的往往不是“怎么让一个Agent调用另一个Agent”，而是下面这些问题：

• 子Agent运行了几个小时，中途遇到人工审批，容器要不要一直占着；
• 外部模型或工具服务断线后，如何从上一次执行位置继续；
• 多个Agent同时修改共享状态，如何避免结果互相覆盖；
• Agent生成的代码可能不可信，如何限制文件、网络和凭证访问；
• 同一套系统需要同时运行数千、数百万甚至更多任务时，传统容器调度是否扛得住。

AX针对的正是这层基础问题。它不负责让模型变得更聪明，也不是一个新的大模型，更不是一个单纯的多Agent Prompt模板。它更接近“Agent世界里的操作系统和调度平面”：上层可以使用不同的Agent框架、模型和工具，AX负责让这些任务真正跑起来、停得住、恢复得了，也能被审计。

四个核心原语

AX把Agent运行环境抽象成四个核心对象：Task、Workspace、Gateway和Model。这个设计看起来朴素，但它的价值在于把过去散落在脚本、容器配置和云平台控制台里的基础设施逻辑，统一成可声明的资源。

| 核心对象 | AX中的作用 | 对开发者意味着什么 | |---|---|---| | Task | 表示一次具体的Agent任务或执行会话 | 可以独立创建、观察、暂停、恢复和删除任务 | | Workspace | 准备代码仓库、工具、MCP服务、技能包和工作目录 | Agent启动前就拥有可复现的工作环境 | | Gateway | 管理Agent的网络访问和出口策略 | 可以把网络访问限制在明确的主机和端口范围内 | | Model | 统一配置模型、参数和凭证 | 模型切换、密钥管理和版本固定不再散落在业务代码中 |

Google官方给出的典型流程是：开发者用声明式配置定义一个Workspace和一个Task，AX为任务准备代码仓库和运行环境，然后在隔离沙箱中启动Agent。任务运行期间，可以查看执行状态，也可以在Agent等待外部响应时将其挂起，之后再恢复到原来的执行位置。(agentexecutor.io)

这套设计的关键不在于资源名字，而在于它改变了Agent的生命周期。传统服务通常是启动、处理请求、返回结果；传统批处理通常是提交、运行、结束。Agent则介于两者之间：它可能连续工作数小时，也可能因为等模型、等工具或等人类批准而闲置数天。AX把这类任务当作有状态Actor来管理，而不是简单的无状态HTTP服务。

AX的技术重点，不是“编排流程”而是“保住执行状态”

AX最值得关注的能力，是它把持久化执行和恢复机制放到了运行时层。

Google官方介绍了几项核心能力：事件日志和快照用于保存执行状态；单写入者架构用于降低共享会话状态被并发修改的风险；客户端断线后可以重新连接，并从上一次看到的序列继续接收结果；检查点还可以用于分叉Agent轨迹，让开发者从某个中间节点复制出多条执行路径进行测试和评估。(cloud.google.com)

这和普通的“失败后重试”不是一回事。

重试通常意味着重新发起一次调用，开发者需要自己判断哪些步骤已经完成、哪些工具调用不能重复、哪些副作用必须回滚。AX的目标则是记录更完整的执行过程，让任务可以从已保存的状态继续向前走。对于代码修改、浏览器操作、数据库写入和长链路研究任务来说，这种差别很重要。

举个更实际的例子：一个研究Agent已经完成资料检索，正在等待人工确认是否继续抓取更多数据。如果按照普通容器服务的方式运行，系统要么让整个容器持续占用资源，要么销毁容器后重新构造上下文。AX的设计是把任务状态检查点保存下来，暂停不活跃的执行环境，等审批完成后再恢复。

官方页面还宣称，AX可以在单个集群中运行数十亿级任务，并支持亚秒级恢复，同时通过让多个任务共享Worker资源来提高密度。这里需要特别区分：这些数字是项目的设计目标和官方定位，不是独立第三方基准测试结果，也不代表普通开发者部署后可以直接获得这样的吞吐量。(agentexecutor.io)

它和Kubernetes、Agent框架是什么关系

AX不是Kubernetes的替代品，也不是要取代现有Agent框架，而是试图填补两者之间的空白。

| 层次 | 主要解决的问题 | AX的关系 | |---|---|---| | Agent框架 | Agent如何思考、规划、调用工具和交接任务 | AX负责承载和运行这些Agent，不强制指定框架 | | 通用工作流引擎 | 如何编排步骤、重试、等待和触发流程 | AX进一步加入Agent沙箱、模型、MCP和运行时生命周期管理 | | Kubernetes | 如何调度容器、扩展服务和管理集群 | AX运行在Kubernetes生态之上，并针对Agent的状态和暂停恢复做了专门抽象 | | AX | 如何让长时间运行的Agent安全、可恢复、可观测地执行 | 处于Agent应用和底层计算基础设施之间 |

AX的核心判断是，Agent工作负载和普通微服务并不一样。普通微服务往往持续处理稳定流量，而Agent会在短时间内集中消耗CPU、内存和模型调用，然后长时间等待工具或人工输入。Google称，这类工作负载具有明显的突发性和状态性，标准Kubernetes更擅长管理长期运行的服务和可预测的批处理任务，未必适合直接管理大量需要暂停和恢复的Agent会话。(cloud.google.com)

因此，AX还配套了Agent Substrate。Agent Substrate可以理解为面向Agent的计算层，负责在准备好的计算资源之间快速放置、迁移和恢复Agent任务；AX则提供更接近应用侧的Task、Workspace、Gateway和Model抽象。Google希望通过两层配合，把Agent从“一个跑在容器里的脚本”升级成“可以被统一调度的有状态执行单元”。

这也是AX和很多多Agent框架最大的区别：后者关注任务图，AX关注任务图之外的运行时现实。

对开发者最有价值的三个场景

1. 多Agent软件工程

多Agent编码是AX最容易被理解的使用场景。

一个复杂项目可以拆成代码调查、依赖升级、测试修复、文档生成和安全扫描等多个任务。每个Agent拥有独立的沙箱、工作目录甚至Git分支，互相之间不会直接覆盖文件。主任务可以等待某个子任务完成，也可以在出现冲突时暂停并人工介入。

AX的价值不在于让每个编码Agent写出更好的代码，而在于让多个Agent可以稳定地同时工作。对于需要长时间运行的代码迁移、跨仓库升级和大规模测试任务，这比单纯增加一个更强的模型更接近实际瓶颈。

2. Agent评测与研究

Agent评测是另一个容易被忽视、但可能非常适合AX的方向。

研究人员经常需要批量运行大量任务，收集完整轨迹，再比较不同模型、工具配置或Prompt策略的效果。AX支持检查点和轨迹分叉，意味着同一个任务可以从相同中间状态出发，测试不同的后续策略，而不需要每次都从头开始。

这对于强化学习、工具使用评测和长程任务研究尤其重要。真正有价值的不是“最终答案对不对”，而是Agent在第几步做错、错误是否可恢复、工具调用是否产生了副作用，以及换一套策略后能否从同一状态继续。

3. 企业内部的长流程自动化

企业Agent通常不会只回答一次问题，它们会查询内部系统、调用多个工具、等待审批，再执行后续动作。Google官方表示，AX可以承载自研Agent、Google提供的Agent，也可以连接使用ADK、LangChain、LangGraph和A2A协议构建的Agent。(cloud.google.com)

这意味着企业可以把不同来源的Agent放进同一套执行和治理体系里。例如，财务Agent负责读取报表，合规Agent检查风险，业务Agent生成方案，最后由人工审批Agent决定是否执行。AX不负责替企业决定这些Agent应该如何协作，但可以负责把它们放进隔离环境，管理状态、网络和凭证。

AX现在还不适合谁

AX目前最大的限制，不是功能少，而是成熟度还不够。

第一，它仍然是预览项目。GitHub仓库明确提示，核心架构、恢复协议和运行时规格仍在调整，稳定版本之前可能出现重大不兼容变更。最新版本v0.2.3只是当前公开版本，并不意味着API和配置已经冻结。(github.com)

第二，它不是开箱即用的托管服务。AX定位为自托管项目，推荐部署在Kubernetes和Agent Substrate之上。开发者需要准备Kubernetes集群、容器镜像仓库、部署工具以及可访问的Agent Substrate控制接口。对于只想快速做一个客服Agent或个人自动化脚本的开发者来说，这套基础设施明显偏重。(github.com)

第三，沙箱并不等于完整安全治理。AX提供隔离执行和网络出口控制，但企业仍然需要自行设计资源配额、凭证轮换、人工审批、提示注入防护、数据脱敏、审计日志和供应链安全。一个Agent即使不能突破容器，也可能通过合法的工具调用做出错误决策。

第四，官方的“数十亿任务”和“亚秒级恢复”仍需要在真实环境中验证。Agent规模、模型延迟、工具调用频率、快照大小、网络策略和底层存储都会改变实际效果。把项目宣传口径直接当成生产SLA，是现在最不应该做的事情。

我对AX的判断

AX真正押注的不是“多Agent会取代单Agent”，而是Agent应用迟早会遇到运行时瓶颈。

当Agent只是在聊天窗口里调用一次搜索工具时，编排层并不难；当Agent开始拥有文件、浏览器、数据库、代码执行和长期记忆，系统就必须处理状态、权限、恢复和资源利用率。模型负责决定下一步做什么，运行时负责保证这一步可以安全、可重复、可追踪地完成。

从这个角度看，AX的产品价值很清楚：它把开发者从“自己拼一个Agent执行平台”这件事里解放出来。Task、Workspace、Gateway和Model四个原语并不花哨，但覆盖了多Agent系统从创建到销毁的大部分基础需求。

不过，AX短期内不太可能取代现有Agent框架。对于低并发、短流程、单租户应用，LangGraph、ADK或自研工作流已经足够；AX更适合那些已经遇到长任务、状态恢复、沙箱隔离和大规模调度问题的团队。

更准确的说法是：AX不是让多智能体更聪明的工具，而是让多智能体更像生产软件的运行时底座。

结语

Google在2026年5月发布AX，说明AI基础设施的竞争焦点正在变化。过去大家主要比较模型能力、上下文长度和工具调用效果；接下来，能否让成千上万甚至更多Agent稳定运行，可能同样决定一个Agent平台能不能进入企业生产环境。

截至2026年9月21日，AX仍然处于早期预览阶段，最适合开发者和研究团队拿来做架构验证、Agent评测和高并发实验。它还不是成熟的通用产品，但方向值得关注：当Agent从一次性回答变成长期运行的数字员工，真正需要被重新设计的，可能不是Prompt，而是运行它们的整个计算层。

参考来源

• Google/AX GitHub仓库：Google官方开源代码仓库，包含AX的架构说明、安装方式、资源定义和当前开发状态。
• AX v0.2.3发布页：AX截至2026年9月21日可查到的最新公开版本，发布于2026年8月13日。