引言“Agent 是一种全新的工作负载它们不是无状态的微服务也不是跑到完成就结束的批处理任务。”这是一天一个开源项目系列的第 228 篇。今天的项目是AX仓库地址google/ax。当团队开始批量运行 AI Agent 时,很快会发现一个尴尬的事实:现有的调度基础设施都不太合身。Kubernetes 的 Pod 模型假设工作负载是无状态服务或跑批任务,但 Agent 会积累状态、需要严格的沙箱隔离、要频繁调用模型 API 和工具服务器,而且一旦没人盯着,很容易在一个循环里把 Token 预算烧穿。传统的 CI/CD 或批处理平台,同样没有为暂停一个 Agent 再原地恢复SSH 进沙箱看它在干什么这类需求设计过。AX 是 Google 开源的一个高吞吐、声明式的 Agent 编排运行时,目标是在单个集群里运行数十亿次自主 Agent 工作负载。如果你用过 Kubernetes,ax的操作体验会非常熟悉——apply、get、describe、watch、delete,一套 kubectl 风格的命令行,只是调度对象换成了 Agent 任务。它构建在 Agent Substrate 之上做沙箱化执行,自己专注于声明式编排这一层。11,600 Stars,560 Forks,Apache-2.0 协议,由 Google 主导开发,目前仍在 Alpha 阶段,核心概念和协议还在快速迭代,项目本身也明确警告稳定版之前可能会有重大breaking change。你将学到什么AX 的三个核心原语:Task、Workspace、Model,分别解决什么问题为什么 Agent 工作负载需要一种既非无状态服务、也非批处理任务的新调度模型AX 与 Agent Substrate 的分层关系:编排层 vs 沙箱执行层控制面架构:为什么用 Redis Streams 而不是直接把 Task 存成 Kubernetes CRDax suspend/ax resume/ax ssh背后的沙箱生命周期设计前置知识熟悉 Kubernetes 的基本概念Pod、CRD、kubectl操作习惯了解容器化部署和沙箱隔离的基本原理可选:了解 MCPModel Context Protocol的基本概念项目背景项目简介AX 的官方定位是Google 的开放 Agent 编排运行时Google’s open agentic orchestration runtime。项目 README 开篇就给出了一个精炼的操作描述:声明一个带工作区和模型规格的 Agent 任务。AX 把它放进沙箱、接好工作区,并帮你大规模运行。这句话点出了整个项目的分工——AX 自己不做沙箱隔离和执行,而是把这部分工作交给底层的 Agent Substrate,自己专注于声明式定义任务、大规模调度、生命周期管理这一层。项目文档里有一段话很直接地解释了为什么现有工具不够用:Agent 是一种新的工作负载。它们既不是无状态的微服务,也不是跑到完成就结束的批处理任务。它们会积累状态,需要严格的隔离,要调用模型 API 和工具服务器,而且如果没人看着,可能在一个循环里烧钱。AX 给出的答案是三个可以声明式描述的小原语,而不是试图用一个大而全的框架去建模 Agent 的全部行为。团队与项目信息所属组织:google协议:Apache License 2.0主语言:Go依赖底座:Agent Substrate沙箱化 Actor 执行环境官网:agentexecutor.io状态:Alpha,核心概念和协议仍在迭代中,明确警告可能有重大 breaking change项目数据⭐ GitHub Stars:11,600 Forks:560 协议:Apache-2.0 Open Issues:48 创建时间:2026-03主要功能解决什么问题在通用调度平台上跑 Agent 工作负载的困境 Kubernetes Pod 模型 → 假设工作负载是无状态服务或跑批任务 ↑ Agent 会积累状态、需要严格隔离、频繁调用外部模型 API ↑ 没有暂停并原地恢复的原生支持 ↑ 没有SSH 进去看 Agent 在干什么的调试通道 ↑ 每次运行都要重新克隆仓库、接工具、配 MCP Server冷启动成本高 AX 的做法 三个声明式原语Task沙箱化执行单元 Workspace预热好的工作环境 Model集群级的模型配置 ↓ 用 ax apply -f task.yaml 一次性声明整套任务 ↓ ax watch / ax ssh / ax suspend / ax resume 提供 K8s 风格的可观测与生命周期管理 ↑ 底层沙箱隔离交给 Agent SubstrateAX 专注编排这一层使用场景大规模运行自主编码/运维 Agent每个 Agent 任务作为一个独立沙箱运行,能声明它需要的 Git 仓库、MCP 服务器、工具集,适合给一堆仓库分别派一个 Agent 去修 Bug这类批量场景需要长时间运行、可暂停恢复的 Agent 工作流通过ax suspend/ax resume,Agent 的状态可以被 checkpoint 并在之后原地续跑,不需要为长任务如何省资源单独设计逻辑需要调试和观察 Agent 实际行为的开发场景ax ssh可以直接进入正在运行的沙箱查看文件系统、跑命令,不用只能干等日志输出需要统一管理模型凭据和配置的多团队场景Model作为集群级资源声明,轮换密钥、切换模型版本只需要一次ax apply,而不是在每个 Agent 的环境变量里挨个改快速开始前置条件# 需要一个已安装 Agent Substrate 的 Kubernetes 集群kubectl get svc api-nate-system# 确认 Substrate 的 Control API 已就绪安装 CLIgoinstallgithub.com/google/ax/cmd/axlatest部署控制面makedeployAX_IMAGE_REPOyour-registry用一份 YAML 声明工作区和任务# task.yamlapiVersion:ax.io/v1alpha1kind:Workspacemetadata:name:golangspec:git:-repo:https://github.com/golang/go.gitbranch:my-fix---apiVersion:ax.io/v1alpha1kind:Taskmetadata:name:testspec:workspaces:-name:golanggoal:Ensure that Go tool chain is available and is built from sourcedebug:true# 允许 ax ssh 进入沙箱应用并观察ax apply-ftask.yaml axwatchtasktestaxsshtest--ls-al/workspace核心特性1. 三个正交的声明式原语原语解决什么Task在隔离沙箱中运行不受信任的 Agent 代码,附带 CPU/内存限制Workspace预先接好 Git 仓库、MCP 服务器、技能包,让每个 Agent热启动Model声明平台自身使用哪个 LLM,凭据来自 Kubernetes Secret2. kubectl 风格的 CLIax apply、ax get、ax describe、ax watch、ax delete,加上 Agent 特有的ax ssh、ax suspend、ax resume。跟着活跃的kubectx上下文走,切集群时ax会自动解析并隧道连接到对应集群的控制面。3. Task 的最小化设计哲学Task 被设计成足够小的单元——一个 Agent 的生命周期里会做计划、委派、重试、拆分任务,AX 不试图对这个行为建模,而是提供一个创建、隔离、暂停、丢弃成本都很低的原语,由 Agent 自己去组合出任意数量的 Task。一个 Task 可以是整个任务本身,也可以是 Agent 拆解问题后生成的一大片任务树的根节点——无论哪种情况,每个节点都拿到同样的沙箱、同样的生命周期、同样的工具链。4. Workspace 的目标驱动引导Workspace 绑定可以带一个goal——一句描述任务需要什么环境的自然语言。首次启动时,Runner 会把这个目标交给一个 Agent 去完成环境搭建比如安装某个工具链或依赖,这样任务自己的命令启动时环境已经是就绪状态。5. 集群级模型资源把模型配置声明成集群资源,而不是散落在每个 Agent 的环境变量里,意味着轮换密钥、锁定新模型版本、调整生成参数只需要一次ax apply。AX 自身的组件比如根据 goal 规划 Workspace 的过程同样读取Model资源。6. 暂停/恢复与 SSH 调试ax suspend会 checkpoint Actor 状态并暂停任务ax resume让它原地续跑。ax ssh需要任务显式声明spec.debug: true才能连接——因为它开放的是任意进程执行和文件访问权限,默认关闭是一个明确的安全设计。项目优势对比项直接用 Kubernetes 跑 Agent自建 Agent 编排逻辑AX状态模型契合度差,Pod 假设无状态或跑批视自建程度而定专为 Agent 的积累状态需要暂停恢复设计大规模调度etcd 存储 CRD,百万级任务会顶到瓶颈需要自己解决用 Redis Streams 支撑十亿级任务目标环境预热需要自己写 initContainer 逻辑需要自己实现Workspace 原语声明式搞定调试通道只能看日志/exec需要自己实现ax ssh内置,权限默认关闭模型配置管理散落在各处需要自己封装Model作为集群资源统一管理为什么选择这个项目Google 主导开发,已经在思考十亿级 Agent 任务这种规模问题,架构决策Redis 而非 etcd是针对这个规模做的操作心智模型直接复用 Kubernetes 经验,kubectl用户几乎零上手成本明确的分层设计——AX 专注编排,沙箱执行交给 Agent Substrate,职责边界清晰项目详细剖析为什么不直接把 Task 存成 Kubernetes CRD这是 AX 架构里一个很值得琢磨的决定。项目文档直接给出了理由:“把数百万个短生命周期任务存成 Kubernetes CRD,会把 etcd 推到它不擅长的区域——个位数 GB 的存储上限、写入速率瓶颈、控制面性能下降。”AX 的解法是把状态存进 Redis,用 Redis Streams 作为 API Server 和一组水平扩展的 Controller 之间的工作队列ax apply -f task.yaml │ ▼ ax-server无状态 gRPC API │ 写入并发布事件 │ ▼ RedisTask Hash Event Streams PubSub │ XREADGROUP消费流 │ ▼ ax-controller水平扩展的 Worker 池 │ gRPC 调用 │ ▼ Agent Substrate沙箱执行这个选择说明 AX 团队从一开始就没打算把自己套进一切皆 CRD的 Kubernetes 心智模型,而是只借用了它的操作体验apply/get/watch,底层存储引擎则换成了更适合高频短生命周期对象的方案。这是一种务实的取舍:用户感知到的交互方式不变,但后端为真实的规模需求重新设计。Task 的小而可组合设计AX 对 Task 的设计哲学值得单独展开。很多编排系统会试图对一个完整的 Agent 工作流建模——比如定义 DAG、定义步骤依赖。AX 反其道而行之:它拒绝对 Agent 的内部行为计划、委派、重试、拆分)建模,只提供一个原子的、廉价的执行单元,让 Agent 自己决定怎么组合。这个设计的好处是灵活性——一个 Task 既可以是全部工作,也可以是一整棵任务树的根节点,AX 不需要理解树的结构,每个节点拿到的都是同样的沙箱和同样的生命周期原语。代价是:任务之间的依赖关系、数据传递,需要 Agent 自己或上层工具去管理,AX 不提供内置的工作流编排语义。Workspace 的目标驱动引导机制Workspace.spec.goal是一个不算常见的设计:它不是直接描述要装什么依赖,而是一句自然语言描述的环境目标比如确保 Go 工具链可用,并且是从源码构建的),交给沙箱启动时的一个 Agent 去解读和执行。这个设计把环境搭建这件本来需要写脚本、写 Dockerfile 的机械工作,变成了一个可以用自然语言描述、由 Agent 完成的动态过程。文档里提到的 Roadmap 显示,这个方向还会继续深化——动态 Agentic 环境策划计划让这个引导过程能自动检查仓库内容、解析工具链、从注册表里发现相关的 MCP Server 和技能,而不只是执行一句写好的目标描述。沙箱生命周期:Runner 作为 PID 1 的常驻角色每个任务容器里,ax-task-runner作为 PID 1 启动,承担的职责比单纯启动命令复杂得多:加载 Task 和 Workspace 规格、在端口 80 启动一个元数据与 Guest 管理守护进程、首次运行时按绑定顺序准备每个 Workspace克隆仓库、配置技能路径,如果有 goal 就交给 Agent 完成)、最后才启动spec.command作为子进程并持续监督。关键的一点是:Runner 在命令退出后仍然作为 PID 1 存活,这意味着即使 Agent 的主命令已经跑完,元数据服务器仍然在响应,ax ssh依然可用。这个设计让调试一个已经结束的任务成为可能,而不是任务一结束容器就整个消失。与 Agent Substrate 的分层关系AX 自己不做沙箱隔离,而是把这部分完全委托给 Agent Substrate——一个专门负责 Atespace 供应、Actor 创建与激活、Worker 分配的底层系统。AX 的 Controller 通过 gRPC 调用 Substrate 的 Control API 来驱动任务朝目标状态演进。这种分层意味着 AX 专注在声明式编排语义和大规模调度这两件事上,把如何安全隔离一个不受信任的进程这个更底层、更难做对的问题留给专门的项目去解决——这也是为什么 AX 的 Roadmap 里花了大量篇幅描述与 Substrate 的 Actor 架构如何演进迁移到新 Actor API、拆分 Workspace 初始化为独立 Actor、最小权限策略、空闲检测自动挂起等)。项目地址与资源官方资源GitHub:https://github.com/google/ax官网:https://agentexecutor.io协议:Apache License 2.0Issue Tracker:GitHub Issues相关资源Agent Substrate —— AX 底层依赖的沙箱化执行环境Agent Substrate Guest Services —— 支撑ax ssh的进程/文件系统服务Model Context Protocol —— Workspace 中集成的工具协议标准总结与展望核心要点回顾三个正交原语覆盖 Agent 编排的核心需求:Task 负责隔离执行,Workspace 负责环境预热,Model 负责集群级模型配置管理复用 Kubernetes 的操作心智模型,但重新设计了存储后端:用 Redis Streams 替代 etcd,是为十亿级短生命周期任务规模量身定制的取舍不对 Agent 行为建模,只提供廉价可组合的执行单元:Task 足够小,由 Agent 自己决定如何拆分、委派、重试明确的分层架构:AX 专注声明式编排,沙箱隔离委托给 Agent Substrate,职责边界清晰仍处于 Alpha 阶段:核心概念和协议还在快速演进,生产落地前需要关注 breaking change适合谁需要大规模运行自主 Agent 工作负载的团队:尤其是任务量级已经超出手写脚本管理范围的场景已经在用 Kubernetes、熟悉其运维心智模型的团队:kubectl式的操作体验几乎零迁移成本需要暂停/恢复长时间运行 Agent、或需要调试通道观察 Agent 实际行为的场景愿意接受 Alpha 阶段项目风险、想提前介入设计和贡献的开发者一句话评价AX 没有试图重新发明 Agent 应该怎么思考,而是先把怎么在集群里安全、大规模地跑这些会积累状态的新工作负载这道基础设施题解好。欢迎访问 PrimeSkills —— 一个精心策划的 AI Agent 与技能市场所有内容均经过真实企业级工作流验证。没有噱头只有真正有效的东西。更多实用知识和有趣产品欢迎访问我的个人主页
引言“Agent 是一种全新的工作负载它们不是无状态的微服务也不是跑到完成就结束的批处理任务。”这是一天一个开源项目系列的第 228 篇。今天的项目是AX仓库地址google/ax。当团队开始批量运行 AI Agent 时,很快会发现一个尴尬的事实:现有的调度基础设施都不太合身。Kubernetes 的 Pod 模型假设工作负载是无状态服务或跑批任务,但 Agent 会积累状态、需要严格的沙箱隔离、要频繁调用模型 API 和工具服务器,而且一旦没人盯着,很容易在一个循环里把 Token 预算烧穿。传统的 CI/CD 或批处理平台,同样没有为暂停一个 Agent 再原地恢复SSH 进沙箱看它在干什么这类需求设计过。AX 是 Google 开源的一个高吞吐、声明式的 Agent 编排运行时,目标是在单个集群里运行数十亿次自主 Agent 工作负载。如果你用过 Kubernetes,ax的操作体验会非常熟悉——apply、get、describe、watch、delete,一套 kubectl 风格的命令行,只是调度对象换成了 Agent 任务。它构建在 Agent Substrate 之上做沙箱化执行,自己专注于声明式编排这一层。11,600 Stars,560 Forks,Apache-2.0 协议,由 Google 主导开发,目前仍在 Alpha 阶段,核心概念和协议还在快速迭代,项目本身也明确警告稳定版之前可能会有重大breaking change。你将学到什么AX 的三个核心原语:Task、Workspace、Model,分别解决什么问题为什么 Agent 工作负载需要一种既非无状态服务、也非批处理任务的新调度模型AX 与 Agent Substrate 的分层关系:编排层 vs 沙箱执行层控制面架构:为什么用 Redis Streams 而不是直接把 Task 存成 Kubernetes CRDax suspend/ax resume/ax ssh背后的沙箱生命周期设计前置知识熟悉 Kubernetes 的基本概念Pod、CRD、kubectl操作习惯了解容器化部署和沙箱隔离的基本原理可选:了解 MCPModel Context Protocol的基本概念项目背景项目简介AX 的官方定位是Google 的开放 Agent 编排运行时Google’s open agentic orchestration runtime。项目 README 开篇就给出了一个精炼的操作描述:声明一个带工作区和模型规格的 Agent 任务。AX 把它放进沙箱、接好工作区,并帮你大规模运行。这句话点出了整个项目的分工——AX 自己不做沙箱隔离和执行,而是把这部分工作交给底层的 Agent Substrate,自己专注于声明式定义任务、大规模调度、生命周期管理这一层。项目文档里有一段话很直接地解释了为什么现有工具不够用:Agent 是一种新的工作负载。它们既不是无状态的微服务,也不是跑到完成就结束的批处理任务。它们会积累状态,需要严格的隔离,要调用模型 API 和工具服务器,而且如果没人看着,可能在一个循环里烧钱。AX 给出的答案是三个可以声明式描述的小原语,而不是试图用一个大而全的框架去建模 Agent 的全部行为。团队与项目信息所属组织:google协议:Apache License 2.0主语言:Go依赖底座:Agent Substrate沙箱化 Actor 执行环境官网:agentexecutor.io状态:Alpha,核心概念和协议仍在迭代中,明确警告可能有重大 breaking change项目数据⭐ GitHub Stars:11,600 Forks:560 协议:Apache-2.0 Open Issues:48 创建时间:2026-03主要功能解决什么问题在通用调度平台上跑 Agent 工作负载的困境 Kubernetes Pod 模型 → 假设工作负载是无状态服务或跑批任务 ↑ Agent 会积累状态、需要严格隔离、频繁调用外部模型 API ↑ 没有暂停并原地恢复的原生支持 ↑ 没有SSH 进去看 Agent 在干什么的调试通道 ↑ 每次运行都要重新克隆仓库、接工具、配 MCP Server冷启动成本高 AX 的做法 三个声明式原语Task沙箱化执行单元 Workspace预热好的工作环境 Model集群级的模型配置 ↓ 用 ax apply -f task.yaml 一次性声明整套任务 ↓ ax watch / ax ssh / ax suspend / ax resume 提供 K8s 风格的可观测与生命周期管理 ↑ 底层沙箱隔离交给 Agent SubstrateAX 专注编排这一层使用场景大规模运行自主编码/运维 Agent每个 Agent 任务作为一个独立沙箱运行,能声明它需要的 Git 仓库、MCP 服务器、工具集,适合给一堆仓库分别派一个 Agent 去修 Bug这类批量场景需要长时间运行、可暂停恢复的 Agent 工作流通过ax suspend/ax resume,Agent 的状态可以被 checkpoint 并在之后原地续跑,不需要为长任务如何省资源单独设计逻辑需要调试和观察 Agent 实际行为的开发场景ax ssh可以直接进入正在运行的沙箱查看文件系统、跑命令,不用只能干等日志输出需要统一管理模型凭据和配置的多团队场景Model作为集群级资源声明,轮换密钥、切换模型版本只需要一次ax apply,而不是在每个 Agent 的环境变量里挨个改快速开始前置条件# 需要一个已安装 Agent Substrate 的 Kubernetes 集群kubectl get svc api-nate-system# 确认 Substrate 的 Control API 已就绪安装 CLIgoinstallgithub.com/google/ax/cmd/axlatest部署控制面makedeployAX_IMAGE_REPOyour-registry用一份 YAML 声明工作区和任务# task.yamlapiVersion:ax.io/v1alpha1kind:Workspacemetadata:name:golangspec:git:-repo:https://github.com/golang/go.gitbranch:my-fix---apiVersion:ax.io/v1alpha1kind:Taskmetadata:name:testspec:workspaces:-name:golanggoal:Ensure that Go tool chain is available and is built from sourcedebug:true# 允许 ax ssh 进入沙箱应用并观察ax apply-ftask.yaml axwatchtasktestaxsshtest--ls-al/workspace核心特性1. 三个正交的声明式原语原语解决什么Task在隔离沙箱中运行不受信任的 Agent 代码,附带 CPU/内存限制Workspace预先接好 Git 仓库、MCP 服务器、技能包,让每个 Agent热启动Model声明平台自身使用哪个 LLM,凭据来自 Kubernetes Secret2. kubectl 风格的 CLIax apply、ax get、ax describe、ax watch、ax delete,加上 Agent 特有的ax ssh、ax suspend、ax resume。跟着活跃的kubectx上下文走,切集群时ax会自动解析并隧道连接到对应集群的控制面。3. Task 的最小化设计哲学Task 被设计成足够小的单元——一个 Agent 的生命周期里会做计划、委派、重试、拆分任务,AX 不试图对这个行为建模,而是提供一个创建、隔离、暂停、丢弃成本都很低的原语,由 Agent 自己去组合出任意数量的 Task。一个 Task 可以是整个任务本身,也可以是 Agent 拆解问题后生成的一大片任务树的根节点——无论哪种情况,每个节点都拿到同样的沙箱、同样的生命周期、同样的工具链。4. Workspace 的目标驱动引导Workspace 绑定可以带一个goal——一句描述任务需要什么环境的自然语言。首次启动时,Runner 会把这个目标交给一个 Agent 去完成环境搭建比如安装某个工具链或依赖,这样任务自己的命令启动时环境已经是就绪状态。5. 集群级模型资源把模型配置声明成集群资源,而不是散落在每个 Agent 的环境变量里,意味着轮换密钥、锁定新模型版本、调整生成参数只需要一次ax apply。AX 自身的组件比如根据 goal 规划 Workspace 的过程同样读取Model资源。6. 暂停/恢复与 SSH 调试ax suspend会 checkpoint Actor 状态并暂停任务ax resume让它原地续跑。ax ssh需要任务显式声明spec.debug: true才能连接——因为它开放的是任意进程执行和文件访问权限,默认关闭是一个明确的安全设计。项目优势对比项直接用 Kubernetes 跑 Agent自建 Agent 编排逻辑AX状态模型契合度差,Pod 假设无状态或跑批视自建程度而定专为 Agent 的积累状态需要暂停恢复设计大规模调度etcd 存储 CRD,百万级任务会顶到瓶颈需要自己解决用 Redis Streams 支撑十亿级任务目标环境预热需要自己写 initContainer 逻辑需要自己实现Workspace 原语声明式搞定调试通道只能看日志/exec需要自己实现ax ssh内置,权限默认关闭模型配置管理散落在各处需要自己封装Model作为集群资源统一管理为什么选择这个项目Google 主导开发,已经在思考十亿级 Agent 任务这种规模问题,架构决策Redis 而非 etcd是针对这个规模做的操作心智模型直接复用 Kubernetes 经验,kubectl用户几乎零上手成本明确的分层设计——AX 专注编排,沙箱执行交给 Agent Substrate,职责边界清晰项目详细剖析为什么不直接把 Task 存成 Kubernetes CRD这是 AX 架构里一个很值得琢磨的决定。项目文档直接给出了理由:“把数百万个短生命周期任务存成 Kubernetes CRD,会把 etcd 推到它不擅长的区域——个位数 GB 的存储上限、写入速率瓶颈、控制面性能下降。”AX 的解法是把状态存进 Redis,用 Redis Streams 作为 API Server 和一组水平扩展的 Controller 之间的工作队列ax apply -f task.yaml │ ▼ ax-server无状态 gRPC API │ 写入并发布事件 │ ▼ RedisTask Hash Event Streams PubSub │ XREADGROUP消费流 │ ▼ ax-controller水平扩展的 Worker 池 │ gRPC 调用 │ ▼ Agent Substrate沙箱执行这个选择说明 AX 团队从一开始就没打算把自己套进一切皆 CRD的 Kubernetes 心智模型,而是只借用了它的操作体验apply/get/watch,底层存储引擎则换成了更适合高频短生命周期对象的方案。这是一种务实的取舍:用户感知到的交互方式不变,但后端为真实的规模需求重新设计。Task 的小而可组合设计AX 对 Task 的设计哲学值得单独展开。很多编排系统会试图对一个完整的 Agent 工作流建模——比如定义 DAG、定义步骤依赖。AX 反其道而行之:它拒绝对 Agent 的内部行为计划、委派、重试、拆分)建模,只提供一个原子的、廉价的执行单元,让 Agent 自己决定怎么组合。这个设计的好处是灵活性——一个 Task 既可以是全部工作,也可以是一整棵任务树的根节点,AX 不需要理解树的结构,每个节点拿到的都是同样的沙箱和同样的生命周期原语。代价是:任务之间的依赖关系、数据传递,需要 Agent 自己或上层工具去管理,AX 不提供内置的工作流编排语义。Workspace 的目标驱动引导机制Workspace.spec.goal是一个不算常见的设计:它不是直接描述要装什么依赖,而是一句自然语言描述的环境目标比如确保 Go 工具链可用,并且是从源码构建的),交给沙箱启动时的一个 Agent 去解读和执行。这个设计把环境搭建这件本来需要写脚本、写 Dockerfile 的机械工作,变成了一个可以用自然语言描述、由 Agent 完成的动态过程。文档里提到的 Roadmap 显示,这个方向还会继续深化——动态 Agentic 环境策划计划让这个引导过程能自动检查仓库内容、解析工具链、从注册表里发现相关的 MCP Server 和技能,而不只是执行一句写好的目标描述。沙箱生命周期:Runner 作为 PID 1 的常驻角色每个任务容器里,ax-task-runner作为 PID 1 启动,承担的职责比单纯启动命令复杂得多:加载 Task 和 Workspace 规格、在端口 80 启动一个元数据与 Guest 管理守护进程、首次运行时按绑定顺序准备每个 Workspace克隆仓库、配置技能路径,如果有 goal 就交给 Agent 完成)、最后才启动spec.command作为子进程并持续监督。关键的一点是:Runner 在命令退出后仍然作为 PID 1 存活,这意味着即使 Agent 的主命令已经跑完,元数据服务器仍然在响应,ax ssh依然可用。这个设计让调试一个已经结束的任务成为可能,而不是任务一结束容器就整个消失。与 Agent Substrate 的分层关系AX 自己不做沙箱隔离,而是把这部分完全委托给 Agent Substrate——一个专门负责 Atespace 供应、Actor 创建与激活、Worker 分配的底层系统。AX 的 Controller 通过 gRPC 调用 Substrate 的 Control API 来驱动任务朝目标状态演进。这种分层意味着 AX 专注在声明式编排语义和大规模调度这两件事上,把如何安全隔离一个不受信任的进程这个更底层、更难做对的问题留给专门的项目去解决——这也是为什么 AX 的 Roadmap 里花了大量篇幅描述与 Substrate 的 Actor 架构如何演进迁移到新 Actor API、拆分 Workspace 初始化为独立 Actor、最小权限策略、空闲检测自动挂起等)。项目地址与资源官方资源GitHub:https://github.com/google/ax官网:https://agentexecutor.io协议:Apache License 2.0Issue Tracker:GitHub Issues相关资源Agent Substrate —— AX 底层依赖的沙箱化执行环境Agent Substrate Guest Services —— 支撑ax ssh的进程/文件系统服务Model Context Protocol —— Workspace 中集成的工具协议标准总结与展望核心要点回顾三个正交原语覆盖 Agent 编排的核心需求:Task 负责隔离执行,Workspace 负责环境预热,Model 负责集群级模型配置管理复用 Kubernetes 的操作心智模型,但重新设计了存储后端:用 Redis Streams 替代 etcd,是为十亿级短生命周期任务规模量身定制的取舍不对 Agent 行为建模,只提供廉价可组合的执行单元:Task 足够小,由 Agent 自己决定如何拆分、委派、重试明确的分层架构:AX 专注声明式编排,沙箱隔离委托给 Agent Substrate,职责边界清晰仍处于 Alpha 阶段:核心概念和协议还在快速演进,生产落地前需要关注 breaking change适合谁需要大规模运行自主 Agent 工作负载的团队:尤其是任务量级已经超出手写脚本管理范围的场景已经在用 Kubernetes、熟悉其运维心智模型的团队:kubectl式的操作体验几乎零迁移成本需要暂停/恢复长时间运行 Agent、或需要调试通道观察 Agent 实际行为的场景愿意接受 Alpha 阶段项目风险、想提前介入设计和贡献的开发者一句话评价AX 没有试图重新发明 Agent 应该怎么思考,而是先把怎么在集群里安全、大规模地跑这些会积累状态的新工作负载这道基础设施题解好。欢迎访问 PrimeSkills —— 一个精心策划的 AI Agent 与技能市场所有内容均经过真实企业级工作流验证。没有噱头只有真正有效的东西。更多实用知识和有趣产品欢迎访问我的个人主页
