Google开源Agent运行时AX：让AI干活前先住进沙箱

AX与Substrate：专为Agent设计的运行时双组件

Google开源了一对专门给AI Agent用的基础设施项目：AX（Agent Executor）和Agent Substrate。AX管上层编排，你写几段YAML，它负责把一个Agent放进隔离沙箱、接好代码仓库和工具、锁死网络出口；Agent Substrate管底层执行，官方给出的数字是挂起恢复不到半秒、每秒可以做500次以上挂起和唤醒，还能把大约250个Agent塞进8个pod里轮流跑。两个项目都在GitHub Trending上，AX单日涨了2300多个star。

为什么需要新抽象：Agent是新型工作负载

Google为什么觉得现有工具不够用？官方博客给的解释是：Agent开始承接一跑就是几个小时甚至几天的任务，这类长任务脆弱、难管理。AX的仓库文档把原因写得更细：Agent这种程序和网站后台不一样，和定时脚本也不一样，它会积累状态，要访问模型接口和外部工具，需要严格隔离，而且没人看管的时候，它会在一个循环里不停地烧API费用。这些特征凑在一起，就是一类全新的工作负载，Kubernetes原生那套抽象（Deployment、Job）没有为它设计。

AX的四类声明式资源

AX的解法是把Agent运行拆成四种声明式资源，全部写成YAML：Task是一个带CPU和内存上限的隔离沙箱；Workspace预先把代码仓库、MCP工具、技能包装进沙箱，让Agent开局就是热的；Gateway把沙箱能访问的外部主机锁进一张允许列表；Model集中管理平台调用哪家模型、密钥放哪。一条 ax apply 命令全部提交，命令行用法刻意做成了kubectl的样子。

解决核心信任问题：沙箱、限流与挂起

对普通人来说，这套东西解决的是"AI干活时我怎么放心"的问题。举一个Gateway的例子：你可以规定一个Agent只准访问模型服务商和你自己的代码仓库，它想去别的地址，流量直接被拦。沙箱里的CPU和内存也有上限，Agent写出死循环代码，烧不掉整台机器。挂起功能则省的是真金白银，Agent等人工确认的时候先挂起，机器让给别人用，确认完半秒内原地满血复活，接着上次的进度干。

省机器的本质：基于等待特性的超卖调度

省机器的原理值得单独说。Google观察到Agent大部分时间在等：等模型返回、等用户点头、等外部接口响应。Agent Substrate于是让大量"actor"（一个Agent就是一个actor）轮流占用少量真正在跑的机器，挂起时把整台沙箱的内存和文件状态拍个快照存起来，唤醒时快照可以在池子里任何一台机器上还原。官方演示里，250个有状态的actor在8个pod上流转，超卖比例超过30倍。这和航空公司的超售逻辑是同一种算账方式：赌所有人不会同时起飞。

上手路径与当前阶段定位

想自己上手，门槛是一套Kubernetes集群加几个命令行工具，装好后写一份task.yaml（声明用什么镜像、跑什么命令、挂哪个workspace、走哪个gateway），ax apply提交，ax watch看进度，ax ssh能直接钻进沙箱里看Agent在干什么。Google和Anthropic的模型配置都有现成样例，密钥走Kubernetes的Secret机制管理。

两个项目现在都处在早期，README里印着警告：核心概念和接口还会大改，不适合生产环境。但方向信号很清楚：Agent的数量往上走之后，"怎么养"会成为一个独立的技术层，Google已经把这一层摆上了货架。对用得上Kubernetes的团队，它是一套可以直接试的开源方案；对其他人，它至少剧透了行业下一步要解决的问题。