Google 开源的 AX，试图把自治 AI Agent 从“长期运行的进程”变成可声明、可调度、可暂停和可恢复的工作负载。其底层运行时 Agent Substrate 将 Agent 视为有状态 Actor，而控制面则提供类似 Kubernetes 的资源与任务管理原语。
这套设计值得关注的地方，不只是给 Agent 套上一层编排 API，而是正面处理了一个现实问题：Agent 的生命周期往往远长于一次模型调用，但其中大量时间都在等待用户、工具、审批或外部事件。若等待期间仍持续占用计算资源，系统很快就会在成本和并发能力上碰到瓶颈。
Agent 不应等同于一个常驻容器
传统在线服务通常持续监听请求，因此让 Pod 长期运行是合理的。自治 Agent 的执行模式却更接近一段断断续续的工作流：
- 接收目标并规划任务；
- 调用模型或外部工具；
- 等待异步结果、人工批准或下一条消息；
- 基于已有状态继续执行。
第三步可能持续数秒，也可能持续数小时。如果每个 Agent 都绑定一个常驻进程，空闲阶段依旧会占用内存、连接和调度槽位。
AX 的关键思路是依托 Agent Substrate，把 Agent 建模为有身份、有状态的 Actor。控制面可以在 Agent 暂时无事可做时挂起任务，并在事件到达后恢复。这让资源生命周期不必与业务会话生命周期完全重合：会话仍然存在，但承载它的计算资源可以被回收。
这种设计可能带来两方面收益：
- 提高资源利用率：空闲 Agent 不必持续占据完整运行环境；
- 降低恢复延迟：运行时若能保存必要状态，就不必每次都从完整历史重新构造任务上下文。
但“恢复”不能只理解为重新启动一个进程。系统还需要知道 Agent 执行到了哪里、有哪些外部调用已经发生，以及哪些结果可以安全复用。
Kubernetes 风格意味着声明式控制，而不只是 YAML
AX 提供 Kubernetes 风格的控制面原语，用于管理 Agent 任务和资源。这类设计的核心通常是把期望状态提交给控制面，再由控制器持续协调实际状态，而不是让调用方手工管理每个进程。
可以把两类对象分开理解：
- Agent 定义：描述模型、工具、权限、资源预算和运行策略；
- Agent 任务：描述某次目标、输入、当前阶段和恢复信息。
当系统采用这种模型后，扩缩容、失败重试、资源配额、状态查询和生命周期策略就有机会统一进入控制面。开发者管理的是任务意图，运行时负责决定任务此刻应当运行、暂停还是恢复。
不过，Kubernetes 风格并不自动等于 Kubernetes 原生 CRD，也不代表 AX 必然支持下面示例中的字段。实际接口、资源名称和命令应以 AX 项目当前版本为准。
可以怎样设计一份 Agent 任务清单
下面是一份概念性清单，用于展示团队如何把 Agent 任务表达成声明式资源。它不是 AX 官方 API；部署前需要按实际 CRD 或控制面接口修改 apiVersion、kind 和字段名。
apiVersion: ax.example.io/v1alpha1
kind: AgentTask
metadata:
name: investigate-payment-failure
namespace: agent-workloads
spec:
agentRef: support-investigator
input:
ticketId: TICKET-1842
objective: 分析支付失败原因，并生成需要人工确认的处理建议
resources:
cpu: "1"
memory: 2Gi
lifecycle:
suspendWhenIdle: true
idleTimeoutSeconds: 60
resumeOn:
- toolResult
- humanApproval
- userMessage
retryPolicy:
maxAttempts: 3
status:
phase: Pending
如果实际 AX 安装提供了对应资源，可以将清单保存为 agent-task.yaml，再按真实资源定义调整后提交：
kubectl create namespace agent-workloads
kubectl apply -f agent-task.yaml
kubectl get agenttasks -n agent-workloads -w
这里最重要的不是字段拼写，而是生命周期边界：什么情况算空闲、哪些事件可以触发恢复、重试是否会重复执行外部操作，以及任务状态由谁持久化。
为了更直观地理解“有状态 Actor 的暂停与恢复”，还可以运行下面这个不依赖第三方库的 Python 小程序。它不是 AX SDK 示例，而是一个最小化的状态检查点模型：
import json
from pathlib import Path
STATE_FILE = Path("agent-state.json")
def load_state():
if STATE_FILE.exists():
return json.loads(STATE_FILE.read_text(encoding="utf-8"))
return {"task_id": "demo-1", "step": 0, "results": []}
def save_state(state):
STATE_FILE.write_text(
json.dumps(state, ensure_ascii=False, indent=2),
encoding="utf-8",
)
state = load_state()
steps = ["读取工单", "查询支付系统", "等待人工审批", "生成处理建议"]
if state["step"] >= len(steps):
print("任务已经完成")
else:
current = steps[state["step"]]
print(f"恢复任务 {state['task_id']}，执行：{current}")
state["results"].append({"step": state["step"], "output": current})
state["step"] += 1
save_state(state)
print("状态已保存，进程现在可以退出；再次运行将从下一步恢复。")
将代码保存为 actor_checkpoint.py，连续执行几次即可观察恢复行为：
python actor_checkpoint.py
python actor_checkpoint.py
cat agent-state.json
真实系统显然还要处理并发写入、状态版本、租约、超时和外部副作用，但这个例子说明了 AX 这类运行时必须解决的核心问题：恢复的是业务执行位置，而不只是操作系统进程。
暂停与恢复最难的是副作用
Agent 调用支付、发邮件、修改工单或写入数据库时，简单重试可能产生重复副作用。假设任务在外部 API 已成功、但检查点尚未写入时崩溃，恢复后再次调用 API，就可能重复扣款或重复发送消息。
因此，采用这类编排器时应重点检查：
- 工具调用是否支持幂等键；
- 状态写入与任务推进是否有明确顺序；
- 恢复时能否区分“尚未调用”和“已调用但结果未记录”；
- Agent 定义或提示词升级后，旧检查点是否仍然兼容；
- 凭据是否跟随任务长期持久化，暂停期间如何轮换；
- 控制面能否记录挂起、恢复、重试和人工介入事件。
另外，减少空闲资源不代表所有场景都应积极挂起。对低延迟对话 Agent 来说，频繁恢复的初始化成本可能超过节省的资源；而批处理、审批流、长时间等待工具结果的任务，更适合这种生命周期模型。
采用 AX 前的评估清单
AX 把 Kubernetes 式控制面、有状态 Actor 和资源感知的暂停恢复组合到一起，为长期运行的自治 Agent 提供了更明确的运维模型。团队在试用时，不妨先选一个等待时间长、外部副作用可控的任务，而不是立即迁移所有在线 Agent。
建议验证以下几项：
- 暂停后实际释放了哪些 CPU、内存和连接资源；
- 从事件到达至任务恢复的延迟是否满足业务要求；
- 控制面故障后，任务状态能否完整重建；
- 重试和恢复是否会重复执行工具调用；
- 是否能够按租户限制模型额度、并发数和工具权限；
- 日志、指标和追踪能否串联同一个 Agent 的多次运行片段。
如果这些边界能够被清晰定义，Agent 就不再只是一个难以治理的后台进程，而会成为一种可以声明、观察和调度的正式工作负载。