Google AX：当 AI Agent 不再是一次性脚本，运行时该长什么样？
本文仅用于学习和了解新项目，正文由 AI 撰写。 写一个能调用大模型和工具的 Agent 并不难，难的是让一万个 Agent 安全、稳定、便宜地跑起来。 本地演示里，Agent 往往只是一个 Python 或 TypeScript 进程：读提示词、调用模型、执行工具、输出结果。但进入生产环境后，问题很快会变成：代码应该在哪运行？它能访问哪些仓库和网站？闲置半小时还要不要占着一整台机器？进程被中断后能不能接着工作？怎样同时管理成千上万个执行中的 Agent？ Google AX 想解决的就是这一层问题。它把自己定义为一个面向 Agent 工作负载的声明式编排器：你提交一份类似 Kubernetes 清单的 YAML，AX 负责准备工作区、建立网络边界、启动隔离环境，并管理任务的暂停、恢复和销毁。 它不是教 Agent 如何推理的框架，也不是封装模型 API 的 SDK。更准确地说，Agent 框架负责“大脑”，AX 负责“工位、门禁和运行制度”。 本文基于 2026 年 9 月 22 日的 AX main 分支与项目官网撰写。项目接口仍是 v1alpha1，官方明确提醒稳定版之前可能有重大变更。 为什么 Agent 不是普通微服务 微服务通常持续监听请求，资源需求相对稳定；批处理任务则从头运行到尾，结束后退出。Agent 同时不太像这两者。 一个 Agent 可能先高强度运行几分钟，然后等待模型、外部工具或人工审批；它会修改文件、积累上下文和中间结果；它可能递归拆出子任务；它还会执行模型生成的代码，并访问网络。换句话说，Agent 往往同时具有四个特点： 有状态：工作区、进程和中间产物都可能影响下一步。 突发式计算：真正消耗 CPU 的时间不连续，大量时间在等待。 长生命周期：一次任务可能跨越数小时甚至数天。 高风险权限：它可能执行不可信代码、读取凭证、访问外部服务并持续花钱。 如果每个等待中的 Agent 都独占一个容器或虚拟机，资源利用率会很差；如果所有 Agent 又都挤在一个进程里，隔离、故障恢复和权限控制会变得非常困难。 AX 的判断是：Agent 需要一种新的调度单位。它应该像容器一样可以隔离，像进程一样轻量，还能在等待时保存状态并暂停。 四个原语：工单、工位、门禁和模型配置 AX 没有试图描述 Agent 的每一次思考，而是只提供四个基础资源。 ...