长跑型AI智能体的安全舱：Google开源AX运行时架构解析

当AI智能体从“回答一个问题”进化到“独立完成一个项目”，传统的运行基础设施开始显得力不从心。Google近日开源的AX（Agent Executor）与Agent Substrate，正是为解决这一矛盾而生的专用工具链。这两个项目瞄准了AI Agent作为一类全新工作负载的核心特征——长时运行、状态积累、需访问外部模型与工具接口、以及无人值守时可能陷入费用燃烧的循环。AX负责上层编排，将智能体封装进隔离沙箱并锁定网络出口；Agent Substrate负责底层执行，实现了每秒500次以上挂起唤醒、250个智能体共享8个Pod的高密度调度。两个项目在GitHub上线后迅速登榜，AX单日新增超过2300个Star，折射出开发者对这类基础设施的迫切需求。

传统容器编排为何装不下AI Agent

Kubernetes原生抽象（Deployment、Job）诞生于管理无状态Web服务的时代，其核心逻辑是“启动-运行-终止”或“水平扩缩容”。但AI Agent呈现出截然不同的工作模式：它会积累中间状态、需要在等待模型返回或人工确认时保留执行上下文、甚至可能在一个循环中持续消耗API配额。更关键的是，这类任务可能一口气跑上几个小时乃至数天，远超传统批处理作业的时长预期。这些特征组合在一起，形成了一类Kubernetes从未被设计过处理的工作负载类型。官方仓库文档指出，Agent既不像网站后台那样持续接收外部请求，也不像定时脚本那样一次性执行完毕，它是一种“有记忆、会等待、需隔离”的持续运行实体，原有的资源调度模型无法为其提供精确的状态管理和成本控制。

AX的解法是将智能体运行拆解为四类声明式资源，全部通过YAML进行表达。Task定义了带CPU和内存上限的隔离沙箱，确保单个智能体耗尽资源时不会波及其他任务；Workspace预先将代码仓库、MCP工具包和技能脚本装入沙箱，使智能体启动时即处于可用状态而非冷启动；Gateway构建了一张外部主机的白名单，智能体只能访问列表内的地址，任何越界流量都会被直接拦截；Model则实现模型调用的集中管理，统一配置调用哪家模型服务商、密钥如何注入。一条ax apply命令即可提交全部配置，命令行交互刻意对标kubectl风格，降低Kubernetes工程师的学习成本。这种设计让“如何放心让AI干活”这一核心问题，变成了可版本化管理、可审计追踪的工程实践。

资源超售：智能体运行的经济学逻辑

Agent Substrate的效率优化逻辑值得单独拆解。项目团队观察到，AI智能体在运行生命周期中，大部分时间并非在执行计算，而是在等待：等大模型返回结果、等用户给出下一步指令、等外部API响应回调。Agent Substrate基于Actor模型设计，让数百个智能体（即Actor）轮流占用少量真实运行的机器资源。每个智能体被挂起时，其完整内存状态和文件系统快照会被持久化存储；唤醒时，快照可以在资源池中任意一台机器上还原恢复，恢复延迟控制在半秒以内。官方演示显示，250个有状态Actor在8个Pod上流转，超售比例超过30倍。这与航空业的超售策略如出一辙——本质上是在赌“不会所有人同时起飞”。对于企业而言，这意味着同等硬件条件下可承载的智能体数量呈数量级提升，智能体运行的边际成本将大幅下降。

企业落地：从沙箱到生产环境的路径

对于具备Kubernetes集群的团队，AX提供了可直接试用的开源方案。部署门槛仅包含一套标准集群和几个命令行工具，配置一个task.yaml声明任务镜像、启动命令、关联Workspace与Gateway后，ax apply提交、ax watch追踪进度、ax ssh可直接进入沙箱内部观察智能体行为。Google与Anthropic的模型配置均提供现成模板，密钥通过Kubernetes Secret机制管理，安全性有保障。更重要的是，这套基础设施的存在本身就是一个信号：当智能体数量持续增长后，“如何养”将成为独立于“如何造”的技术层。AX与Agent Substrate的出现，意味着基础设施层面已开始为智能体的大规模运营做准备，而企业需要思考的是如何在沙箱边界内最大化智能体的价值产出。

AX与Agent Substrate仍处于早期阶段，README明确标注核心接口可能变更、不建议直接用于生产环境，但其方向已足够清晰。对于正在构建或规划AI Agent能力的企业，这套开源方案既是可直接参考的工程实践，也是预判行业走向的观测窗口。智能体运行的专用基础设施层，正在从概念走向现实。