北京
为什么AI代理跑起来，云账单比模型调用费还吓人？谷歌给出的答案是一个新项目：AX。它托管在 agentexecutor.io 和 GitHub 的 google/ax 仓库，采用 Apache 2.0 许可证，是一个开源编排器兼声明式运行时，专门用来执行和扩展自主AI代理的工作负载。
AX 跑在 Agent Substrate 之上，核心思路是把智能代理当成有状态的参与者，而不是微服务，也不是批处理任务。它支持亚秒级的任务暂停和恢复，并提供了四种声明式基本组件：Task、Workspace、Gateway 和 Model。
代理和传统负载，根本不是一回事
现代AI代理的运行需求和传统基础设施模型差异明显。无状态微服务处理的是请求-响应，生命周期短暂；批处理任务则以确定性方式执行到完成。自主代理不一样：它有状态、突发性强、长期运行。
它在推理、工具执行和本地代码评估时高强度计算，中间又穿插长时间空闲，等模型响应、等外部API反馈、等人工干预。在传统 Kubernetes 或容器编排环境里，空闲阶段还让专用沙箱保持活动，计算资源利用率就会不足；而传统容器运行时的冷启动又会引入延迟，拖慢交互式代理循环的性能。
空闲就挂起，恢复不用等冷启动
AX 的架构以谷歌及谷歌 DeepMind 各团队的系统研究为基础。它运行在 Agent Substrate 之上，后者是专为密集型 Actor 多路复用设计的执行运行时。
在 AX 中，每个代理会话都作为隔离的 Actor 沙箱运行，有严格的 CPU 和内存资源边界。当代理进入空闲状态，比如等待推理提供程序或工具调用，平台会保存其执行状态检查点并将其挂起。AX 的目标是以亚秒级间隔恢复挂起的 Actor，且无冷启动延迟，同时把数十个任务复用到共享的主机工作进程上，节省计算资源。
控制平面提供四个 Kubernetes 风格的声明式元素，定义在 ax.io/v1alpha1 API 组下：
- Task：定义执行生命周期、沙箱资源约束以及所支持基础设施的引用。
- Workspace：负责执行前的环境组装，可声明式挂载 Git 仓库、配置模型上下文协议（MCP）服务器、安装技能包，或用自然语言说明目标，由初始化代理在任务启动前执行。
- Gateway：管理出站网络安全策略，把沙箱中的代理限制在明确的主机名和网络端口白名单内，同时将凭据注入出站请求。
- Model：为 LLM 提供商参数、运行时配置以及存储在 Kubernetes 中的密钥提供统一控制点。
用 Go 写的命令行，运维和调试都走它
与系统交互通过 Go 语言编写的 ax 命令行工具实现。平台运维人员用 ko 把控制平面部署到 Kubernetes，把 Redis 部署到 ax-system 命名空间，再通过 kubectx 利用现有 Kubernetes 上下文交互。
开发人员则用一组命令管理工作负载：ax apply 注册清单，ax watch 实时流式传输任务阶段和状态变化，ax ssh 进入交互式沙箱环境调试，ax suspend 和 ax resume 手动控制任务执行状态。项目既适用于生产环境的代理部署，也适用于需要沙箱运行轨迹、强化学习循环以及代理基准测试的研究环境。
叫好和质疑，同时出现
AX 在 Hacker News 上引发了热烈讨论，技术社区意见并不一致。基础设施工程师称赞它消除了代理空闲时（等待模型API或人工输入）产生的高昂云成本。
开发者则批评其“符合人体工程学的工作流”这一宣传，因为通过 ko 等工具维护 Kubernetes 集群、容器注册表和自定义 CRD，会带来沉重的运维开销。转发至 Reddit 的讨论强调，AX 是基础执行运行时，而非像 LangGraph 或 CrewAI 那样的高级应用编排器。来自安全和系统领域的从业者重点指出，gVisor 隔离沙箱在限制影响范围方面至关重要，同时也提到了出站代理连接中断和基础密钥管理等早期问题。
AX 的定位很明确：不是面向极客爱好者的快速入门框架，而是企业管理大规模、长期运行的代理集群所不可或缺的核心计算原语。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
