谷歌推出 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 语言编写的 ax 命令行工具实现。平台运维人员使用 ko 将控制平面部署到 Kubernetes，并将 Redis 部署到 ax-system 命名空间中，通过 kubectx 利用现有的 Kubernetes 上下文进行交互。
开发人员使用一系列命令管理工作负载，包括：使用 ax apply 注册清单、使用 ax watch 实时对任务阶段和状态变化进行流式传输、使用 ax ssh 访问交互式沙箱环境进行调试，以及使用 ax suspend 和 ax resume 手动控制任务执行状态。该项目既适用于生产环境中的智能代理部署，也适用于需要沙箱运行轨迹、强化学习循环以及智能代理基准测试的研究环境。
该项目在 Hacker News 上引发了热烈的讨论，但技术社区的意见并不一致：一方面，基础设施工程师称赞说，该平台消除了代理处于空闲状态时（等待模型 API 或人工输入）产生的高昂云成本；另一方面，开发者则批评其“符合人体工程学的工作流”这一营销宣传，因为通过 ko 等工具维护 Kubernetes 集群、容器注册表和自定义 CRD 会带来沉重的运维开销。与此同时，转发至 Reddit 的讨论则强调，AX 是作为基础执行运行时，而非像 LangGraph 或 CrewAI 那样的高级应用编排器；而来自安全和系统领域的从业者则重点指出，gVisor 隔离沙箱在限制影响范围方面至关重要，同时也提到了诸如出站代理连接中断和基础密钥管理等早期问题。
最终，AX 的定位是：并非面向极客爱好者的快速入门框架， 而是企业管理大规模、长期运行的代理集群所不可或缺的核心计算原语。原文链接： /ai-market-guide/