最近吴恩达那篇 Agent 教程又把这股热度过了一遍圈里到处都在聊 agent 框架、记忆、编排、调度。我自己这几个月一直在折腾 agent 项目说实话最大的体会不是模型能力不够而是 agent 一旦多起来根本管不住实例凭空消失、并发一高就乱套、任务队列直接堵死。所以 Google 放出 AX 这个开源项目的时候我第一时间把文档和代码翻了个底朝天。一句话概括它的野心让 Agent 像 Pod 一样被调度。意思是说把 Kubernetes 管理容器的那套核心方法论——声明式资源描述、统一调度器、生命周期托管、故障自愈——整个搬到 Agent 世界里来。这篇文章我用一个实际做 agent 项目的视角拆一拆 AX 的设计逻辑、接入方式和我在实操中踩过的坑给正在做 agent 工程化或者准备入局的朋友一份可以直接参考的笔记。1. Agent 工程化的最大瓶颈为什么偏偏是“调度”1.1 大多数 Agent 项目跑不起来不是模型不行是资源管理太原始我先说一个特别普遍的现象。很多人把 Agent 做出来之后第一版就是一台服务器上扔几个 Python 进程模型 API 的 key 写在环境变量里token 和显存全靠肉眼估。单机单 Agent 的时候什么问题都没有一旦上到业务场景比如要同时跑 20 个客服 Agent、10 个数据分析 Agent马上崩给你看。我自己第一次遇到这类问题是在一个电商客服项目上。当时团队自己写了个简易的 Agent Runner循环去消息队列里拉任务、创建 session、调模型、攒结果。开始跑得挺好后来活动大促流量进来几百个会话实例同时并发内存直接打满进程被系统 OOM Killer 杀掉被杀掉的 Agent 里还有一堆没保存的对话上下文。最气人的是重试策略没做好任务直接丢了一大批。这个问题表面上是“资源不够”本质上是“没有调度”。传统 Web 服务是无状态的请求来了就处理处理完就结束nginx 负载均衡器在前面把流量一摊后端随便扩容。但 Agent 不一样。它是个有状态的东西有会话上下文、有短期记忆、有正在执行的任务链。你不能把它当成无状态进程随便杀随便拉否则用户聊到一半Agent 失忆了那体验直接归零。所以 Agent 工程化要往前走绕不过去的核心问题就是怎么管理一堆有状态、需要模型算力、还要协作的 Agent 实例这就需要一套专门为 Agent 设计的调度系统。1.2 “像 Pod 一样”到底意味着什么Kubernetes 最大的贡献不是容器本身而是把“要跑什么”和“怎么跑”彻底解耦了。Pod 作为最小的调度单元你有几个关键信息requests 和 limits 描述资源需求标签和亲和性描述位置偏好探针描述健康状况控制器描述期望状态。调度器只需要看这些声明就能决定把 Pod 放到哪台机器上然后持续保证它处于期望状态。对照 Agent 场景你会发现惊人的相似。Agent 实例也有资源需求比如需要多大的显存来放模型、多少个并发会话、多大的记忆存储空间。Agent 实例也有位置偏好比如某些 Agent 需要靠近某个私有数据源某些 Agent 必须和另一个 Agent 在同一台机器上以减少通信延迟。Agent 实例也有生命周期启动、运行、销毁、故障恢复每一步都需要被管理。传统做法里开发者在代码层面手动管理这些逻辑比如自己在代码里写一个 global dict 来存 session手动维护进程池。这就像每家公司在没有 K8s 的时候自己写部署脚本一样重复造轮子还容易出错。AX 做的事就是把 K8s 对容器的那套抽象移植到 Agent 上。Agent 变成“一等公民”被调度器统一管理。开发者只需要写一个 Agent 的描述文件声明它要什么、能干什么、需要多少资源剩下的交给调度器。这是“像 Pod 一样”最精确的含义。1.3 AX 的真实身份Agent 时代的调度控制面按我通读项目文档的理解AX 本质上是一座位于大模型能力之上、Agent 应用之下的调度控制面。它不直接跑模型也不替你写提示词它管的是Agent 实例怎么创建、放到哪、跑在哪、什么时候回收。它有几个核心组成对应 K8s 的那套控制面逻辑Agent API Server接收 Agent 的注册、更新、查询、删除请求维护 Agent 的声明式定义相当于 K8s 的 API Server。调度器Scheduler负责把 Agent 实例分配到可用的执行器上完成筛选、打分、绑定三步操作相当于 K8s Scheduler。执行器Executor真正拉起 Agent 进程的地方可以是物理机、虚拟机也可以是 K8s 里的 Pod相当于 Kubelet。状态存储State Store保存 Agent 的运行状态、记忆索引、任务进度相当于 etcd 加持久化存储。这套结构不难看出AX 不是把 Agent 调度单独做成一个库而是做成一个完整的平台层。你可以在上面做集群调度、任务队列管理、优先级抢占、负载调节——热搜词里那些“集群调度”“调度层”“任务及队列管理”在这套体系里都有对应位置了。2. AX 核心设计拆解Agent 这台“机器”是怎么被装上货架的2.1 从 Agent 注册开始资源声明是调度的前提调度系统要工作第一步是让每个 Agent 把自己描述清楚。这就像物流公司发货之前你得先告诉它包裹有多重、有多大、能不能叠放它才能决定用哪辆车、放在哪个位置。AX 里一个 Agent 的注册信息就承担这个职责。以我设想的典型配置为例一个客服 Agent 的声明大概长这样apiVersion: ax.dev/v1 kind: Agent metadata: name: customer-service-agent labels: team: support tier: production spec: model: provider: openai-compatible name: qwen-plus contextWindow: 128k maxTokensPerMinute: 2000 resources: requests: memory: 2Gi qps: 10 sessions: 50 limits: memory: 4Gi qps: 50 sessions: 200 memory: store: redis index: vector-db snapshotInterval: 300 lifecycle: minIdle: 2 maxInstances: 20 scaleTrigger: latency affinity: prefer: - label:>