Google 开源的 AX，试图把 AI Agent 从零散的 Python 脚本、后台进程和临时容器，提升为可以统一提交、观察和调试的集群工作负载。它采用开发者熟悉的声明式方式：任务与工作区写成 ax.io/v1alpha1 YAML，通过 ax apply 提交，用 ax watch 观察状态，必要时再通过 ax ssh 进入沙箱排查问题。
AX 提到可在一个集群中运行“几十亿个”自主 Agent 任务。这个数字更适合看作架构目标，而不是无需条件即可复现的吞吐量承诺；真正决定容量的仍然是模型调用配额、任务持续时间、存储、调度成本以及外部服务限流。
Agent 为什么需要声明式编排
传统 Agent 项目通常从一个循环开始：读取目标、调用模型、执行工具、保存结果，然后继续下一步。单任务并不复杂，但一旦扩展到成千上万个并发任务，工程问题会迅速超过 Prompt 本身：
- 每个 Agent 使用哪个镜像、模型和工具集？
- 中途失败后应该重试、恢复还是重新开始？
- 文件、浏览器状态和执行产物存放在哪里？
- 如何查看某个 Agent 当前卡在哪一步？
- 谁能进入运行沙箱，谁能读取密钥？
- 如何限制 CPU、内存、网络访问和模型预算？
AX 的价值不只是“启动更多 Agent”，而是尝试给这些任务提供统一的控制面。对于 Kubernetes 用户，这套思路并不陌生：开发者提交期望状态，系统负责把任务放到合适的执行环境中，并持续暴露任务状态。
这里也需要区分 AX 与 Kubernetes。AX 借用了声明式对象和命令行操作体验，但不能仅凭相似的 YAML 就假设它完整复刻了 Kubernetes 的调度、控制器、网络和安全模型。评估时应以 AX 当前版本的资源定义与运行语义为准。
一套熟悉的操作路径：apply、watch、ssh
AX 把日常操作压缩成了接近集群管理工具的工作流：
# 先确认当前版本支持的参数，避免照搬其他版本的示例
ax apply --help
ax watch --help
ax ssh --help
# 提交声明式资源
ax apply -f ax-demo.yaml
# 查看任务状态
ax watch
# 进入指定 Agent 的沙箱；请将名称替换为真实任务名
ax ssh demo-research-agent
这三个动作分别覆盖了 Agent 运维中最常见的场景：
apply让任务定义进入版本控制，而不是散落在启动脚本和人工操作中。watch提供运行状态入口，适合观察排队、执行、失败或完成等生命周期变化。ssh允许工程师进入沙箱，检查文件、进程和中间产物，而不必仅靠模型输出猜测错误原因。
ssh 同时也是高风险能力。生产环境至少应记录进入者、进入时间和执行命令，并限制沙箱可读取的凭据。否则，方便的调试入口很容易变成绕过任务隔离与审计的通道。
可以怎样组织一个 Agent 任务
来源摘要没有给出 AX 的完整资源字段，因此下面是一个概念性模板：仅 apiVersion: ax.io/v1alpha1 来自已知信息，kind 和 spec 字段是假设性设计，用来展示如何组织配置。实际使用前，请根据当前 AX 文档或资源 schema 替换字段名。
# ax-demo.yaml
# 概念性示例：kind 和 spec 字段需要按实际 AX schema 调整
apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
name: research-workspace
spec:
storage:
size: 10Gi
---
apiVersion: ax.io/v1alpha1
kind: AgentTask
metadata:
name: demo-research-agent
labels:
team: platform
workload: research
spec:
workspace: research-workspace
image: ghcr.io/example/research-agent:1.0.0
command:
- python
- /app/agent.py
- --topic
- "declarative agent orchestration"
resources:
cpu: "1"
memory: 2Gi
retry:
maxAttempts: 3
timeout: 30m
可以把它保存为 ax-demo.yaml，先用帮助命令确认 CLI 参数，再按实际 schema 修改并提交：
ax apply --help
ax apply -f ax-demo.yaml
ax watch
即使最终字段不同，这种拆分仍然值得保留：
- Workspace 承载输入文件、中间状态和最终产物。
- Task 描述镜像、入口命令、资源与执行边界。
- 标签 用于按团队、项目或成本中心聚合任务。
- 超时与重试 应由平台明确控制，不能无限依赖 Agent 自己退出。
如果 Agent 会调用付费模型，还应把令牌预算作为一等约束。CPU 和内存限制只能控制本地资源，无法阻止一个错误循环持续消耗模型 API 配额。
上生产前，重点验证这几件事
AX 提供的是很有吸引力的操作模型，但 v1alpha1 也意味着接口和行为仍可能变化。与其一开始就迁移关键工作流，不如选择可重放、低风险的批处理任务做试点，例如资料分类、离线代码检查或内部文档整理。
落地时可以按下面的清单检查：
- 幂等性：同一个任务因重试执行两次，是否会重复发邮件、提交代码或写入数据？
- 状态恢复：Agent 中断后，是从工作区检查点恢复，还是从头消耗一次模型预算？
- 权限隔离：每个任务是否只拿到完成工作所需的最小密钥与网络权限？
- 可观测性：除了最终文本，是否保留工具调用、错误、延迟、Token 消耗和退出原因？
- 成本控制：是否设置并发上限、单任务预算、超时以及外部 API 限流？
- 版本固定：是否固定 Agent 镜像、模型版本、Prompt 和工具版本，以便复现结果？
- 人工审批：涉及付款、删除数据、发布内容或修改生产系统时，是否设置人工确认点？
AX 最值得关注的地方，不是一个夸张的任务数量，而是它把 Agent 当成了可以声明、调度、观察和进入调试的正式工作负载。对已经习惯 GitOps 和集群运维的团队，这降低了管理大量 Agent 的认知门槛；但 Agent 的非确定性、外部副作用和模型成本不会因为换成 YAML 自动消失。正确的采用方式，是先把执行边界、权限、预算和恢复策略设计清楚，再逐步扩大并发规模。