1. 从 Pod 调度到 Agent 调度一个正在成形的抽象层Kubernetes 把容器这个原本散落在各处的概念抽象成了 Pod 这个可被统一调度的最小单元于是才有了声明式、可编排、可观测的云原生生态。现在 Google 开源 AX 想做的事情本质上是把Agent也抽象成类似 Pod 的东西——让一个智能体不再是一段跑在笔记本里的脚本而是一个可以被集群统一调度、扩缩、观测、回收的工作负载。这个方向不是凭空冒出来的。过去一年里Agent 开发从写个 prompt 调 API迅速演化成了多 Agent 协作 工具调用 长任务编排随之而来的问题非常具体一个 Agent 跑长任务时怎么保证不丢状态多个 Agent 抢同一个工具资源怎么办某个 Agent 卡死了谁来重启它这些问题在单机脚本时代根本不存在但一旦 Agent 数量上到几十上百个就变成了彻头彻尾的调度问题。AX 的核心价值就在这里它试图定义一套 Agent 的运行时契约让 Agent 拥有类似 Pod 的生命周期语义——创建、调度、运行、健康检查、重启、销毁。对做 Agent 开发的人来说这意味着你不再需要自己写一套任务队列 状态机 重试逻辑而是把这些交给调度层。对做基础设施的人来说这意味着 Agent 终于可以像普通工作负载一样被纳入现有的集群管理体系。这篇文章会从 AX 的设计动机讲起拆解它到底抽象了什么、和 Pod 的类比边界在哪里、实际落地时会遇到哪些坑以及如果你现在就想在自己的项目里借鉴这套思路应该从哪几个点切入。适合正在做 Agent 平台、多智能体编排、或者单纯被 Agent 状态管理折磨过的开发者。2. AX 到底抽象了什么Agent 作为一等调度单元2.1 为什么Agent 即工作负载是个合理的抽象先想清楚一件事Agent 和普通微服务到底差在哪如果只是接收请求、调用模型、返回结果那它就是个无状态服务用 Deployment 就够了根本不需要新概念。真正让 Agent 变得特殊的是三个特征。第一是长时运行与状态依赖。一个 Agent 处理复杂任务时可能跑几分钟甚至几小时中间要维护对话历史、工具调用结果、中间推理状态。这跟 Pod 里跑一个长时间 Job 很像但 Agent 的状态更软——它不是文件系统里的数据而是内存里的上下文。第二是资源竞争与配额。Agent 调用的模型 API 有速率限制工具比如浏览器、代码执行沙箱是稀缺资源多个 Agent 同时抢一个工具就会互相拖垮。这跟 Pod 抢 CPU、内存、GPU 是同构的问题。第三是生命周期的不确定性。Agent 可能因为模型返回异常、工具超时、上下文溢出而卡住需要外部介入重启或迁移。这正是调度器最擅长处理的事情。AX 的抽象逻辑就是既然 Agent 具备这三类特征那就应该给它一套和 Pod 对等的调度语义而不是让每个 Agent 框架各自造轮子。2.2 AX 与 Pod 的类比边界哪些能照搬哪些不能把 Agent 类比成 Pod 很好理解但不能无脑照搬。下面这张表是我梳理的核心差异理解这些差异比记住 AX 的 API 更重要。维度PodAgentAX 抽象关键差异生命周期创建到终止状态明确可能假活进程在但推理卡住健康检查更难定义状态主要靠 Volume 持久化上下文在内存需快照机制状态迁移成本高资源CPU/内存/GPU 可量化模型 token、工具并发数资源度量不标准调度依据节点资源、亲和性模型配额、工具可用性、上下文长度调度维度更软失败恢复重启容器即可重启后上下文可能丢失需要状态检查点这张表里最关键的一行是健康检查。Pod 的 liveness probe 很简单——进程活着、端口能通就算健康。但 Agent 的健康是个模糊概念它可能进程正常、端口正常但推理已经陷入死循环或者上下文已经溢出导致输出全是垃圾。AX 要解决的核心难题之一就是定义一套 Agent 层面的健康语义。2.3 调度层需要接管的三件事如果让我总结 AX 这类系统真正要接管的能力就是三件事放置、编排、回收。放置Placement决定一个 Agent 应该跑在哪个执行环境上。这个决策要考虑的因素比 Pod 多得多模型配额够不够、需要的工具在不在这个节点、上下文长度是否超过该节点的处理能力、甚至 Agent 之间的通信延迟。编排Orchestration处理 Agent 之间的依赖关系。多 Agent 系统里Agent A 的输出是 Agent B 的输入这种 DAG 依赖需要调度层来保证执行顺序和错误传播。这跟 Kubernetes 里 Job 的依赖管理思路一致但 Agent 的依赖是动态的——运行时才知道下一个要调谁。回收Reclamation是容易被忽视的一环。Agent 跑完任务后它的上下文、占用的工具连接、缓存的模型会话都需要释放。如果回收不干净跑几百个 Agent 之后系统就会被僵尸资源拖垮。这一点在单机脚本时代靠进程退出自动解决但在调度层里必须显式处理。3. 调度器视角下的 Agent放置、编排与回收的完整链路3.1 放置决策Agent 该被调度到哪里放置决策是调度器的第一道关卡。Pod 的放置相对简单看节点剩余资源、亲和性规则、污点容忍就够了。Agent 的放置要复杂一个量级因为它要同时满足硬约束和软约束。硬约束是那些不满足就完全跑不起来的条件。比如某个 Agent 依赖一个特定的代码执行沙箱镜像那它只能被放到预装了该镜像的节点上。再比如 Agent 需要访问一个内部工具服务网络不通的节点直接排除。这些约束和 Pod 的 nodeSelector、taints 是一个思路。软约束是最好满足但不强制的条件。比如某个 Agent 对延迟敏感那优先放到离模型服务近的节点某个 Agent 上下文很长优先放到内存充裕的节点。软约束用打分机制处理每个候选节点算一个分数选最高的。我实际做 Agent 平台时踩过的一个坑是把模型配额当成了硬约束。结果某个节点配额临时用满调度器就把 Agent 判定为无法调度任务直接失败。正确做法是把配额当软约束——配额紧张时降级到排队而不是直接拒绝。这个区别在 Pod 世界里不明显CPU 不够就是不够但在 Agent 世界里配额是可以等一等的。3.2 编排链路多 Agent 依赖怎么表达多 Agent 系统的编排本质上是把一个任务拆成有向无环图DAG每个节点是一个 Agent 执行单元边是数据依赖。调度层要做的是按拓扑顺序触发 Agent把上游输出传给下游处理某个节点失败时的重试或跳过。这里有个和传统工作流引擎比如各种 DAG 调度器的关键区别Agent 的 DAG 往往是动态的。传统工作流在提交时图就固定了但 Agent 经常在运行时才决定下一步调用谁——比如一个研究 Agent根据搜索结果决定要不要再派一个验证 Agent。这就要求调度层支持动态加节点。AX 这类系统的处理方式通常是引入一个控制 Agent的概念它负责在运行时生成子任务并提交给调度器。控制 Agent 本身也是一个被调度的 Agent只是它的输出是新的调度请求而不是最终结果。这种递归结构让系统能表达任意复杂的编排逻辑代价是调度器要处理动态增长的负载。3.3 回收与状态检查点别让 Agent 变成僵尸回收这件事我在两个项目里都吃过亏。第一个项目是 Agent 跑完任务后没释放模型会话跑了一天之后模型服务的连接池被打满新任务全部超时。第二个项目是 Agent 的上下文快照没清理磁盘被写满。AX 的回收机制应该包含三层执行环境回收释放容器/沙箱、资源回收释放模型会话、工具连接、状态回收清理或归档上下文快照。前两层和 Pod 的回收类似第三层是 Agent 特有的。状态检查点Checkpoint是回收的反面——不是删除状态而是把状态存下来以便恢复。一个长任务 Agent 跑到一半被抢占如果没有检查点重启后就得从头再来。检查点的粒度是个权衡太粗比如只在任务边界存恢复后丢失工作多太细每步都存开销大。我的经验是按不可逆操作为边界存检查点——比如调用了一个有副作用的工具之后立刻存因为这一步重放代价高。4. 把 AX 思路落地到自己的 Agent 平台可复现的实践路径4.1 最小可行抽象先定义 Agent 的 Spec如果你现在就想在自己的项目里借鉴 AX 的思路不要一上来就搞完整调度器。第一步是定义一个 Agent 的 Spec——也就是描述一个 Agent 需要哪些字段。这是整个抽象的地基定义错了后面全要返工。一个够用的 Agent Spec 至少包含这几块镜像/运行时Agent 跑在什么环境里、入口怎么启动它、资源需求模型配额、工具、内存、依赖上游 Agent 或数据源、健康检查怎么判断它还活着、检查点策略状态怎么存。# 一个借鉴 AX 思路的 Agent Spec 示例 apiVersion: agent.example.com/v1 kind: Agent metadata: name: research-agent spec: runtime: image: agent-runtime:latest entrypoint: [python, -m, agent.main] resources: modelQuota: provider: internal tokensPerMinute: 100000 tools: - name: web-search concurrency: 2 - name: code-sandbox concurrency: 1 memory: 2Gi dependencies: - agent: planner-agent outputKey: plan healthCheck: type: progress-based stallTimeout: 120s checkpoint: strategy: on-side-effect storage: s3://agent-checkpoints/这个 Spec 里最值得说的是healthCheck的progress-based类型。传统的进程存活检查对 Agent 没用你需要的是进度检查——如果 Agent 在 120 秒内没有任何有意义的进展没有新的工具调用、没有新的输出 token就判定它卡住了。这个stallTimeout的值要根据任务类型调我一般设成正常单步耗时的 3 到 5 倍。4.2 调度循环从队列到执行的完整代码骨架有了 Spec 之后调度循环的核心逻辑其实不复杂。下面是一个简化版的调度器骨架用 Python 写重点是展示放置-执行-回收的完整链路。import time from dataclasses import dataclass from typing import List, Optional dataclass class AgentSpec: name: str model_quota: int tools: List[str] memory_mb: int dataclass class Node: name: str free_quota: int available_tools: List[str] free_memory_mb: int def score_node(node: Node, spec: AgentSpec) - Optional[float]: 返回 None 表示硬约束不满足直接排除 # 硬约束工具必须全部可用 if not set(spec.tools).issubset(set(node.available_tools)): return None # 硬约束内存必须够 if node.free_memory_mb spec.memory_mb: return None # 软约束配额越充裕分数越高 quota_score min(node.free_quota / max(spec.model_quota, 1), 1.0) memory_score min(node.free_memory_mb / max(spec.memory_mb, 1), 1.0) return 0.6 * quota_score 0.4 * memory_score def schedule(spec: AgentSpec, nodes: List[Node]) - Optional[Node]: scored [(score_node(n, spec), n) for n in nodes] valid [(s, n) for s, n in scored if s is not None] if not valid: return None valid.sort(keylambda x: x[0], reverseTrue) return valid[0][1] def run_agent(spec: AgentSpec, node: Node): 执行 Agent带进度健康检查和检查点 node.free_quota - spec.model_quota node.free_memory_mb - spec.memory_mb last_progress time.time() try: while True: # 这里是实际的 Agent 执行逻辑 progress step_agent(spec) if progress: last_progress time.time() if progress.is_side_effect: save_checkpoint(spec, progress) if progress and progress.done: break if time.time() - last_progress 120: raise TimeoutError(fAgent {spec.name} stalled) finally: # 回收无论成功失败都要释放资源 node.free_quota spec.model_quota node.free_memory_mb spec.memory_mb这段代码里有两个设计点值得展开。第一是score_node返回None表示硬约束不满足而不是返回 0 分——这个区别很重要0 分可能被误选None会被明确排除。第二是finally块里的资源回收这是防止僵尸资源的关键无论 Agent 是正常结束还是抛异常资源都会被释放。4.3 健康检查的三种实现方式与选择依据Agent 的健康检查是整个系统里最难做对的部分。我试过三种方式各有适用场景。进程存活检查最简单就是看 Agent 进程还在不在。这种方式对崩溃型失败有效但对卡死型失败完全无效。适合那些执行时间短、逻辑简单的 Agent。进度检查是我最推荐的默认方案。核心思路是让 Agent 在执行过程中定期上报进度信号调度器维护一个last_progress时间戳超过阈值就判定卡死。进度信号可以是完成了一次工具调用产生了新的输出更新了内部状态等。这种方式能抓住绝大多数卡死场景代价是 Agent 需要配合上报。心跳检查介于两者之间Agent 定期发心跳调度器看心跳是否超时。它比进程检查强但比进度检查弱——因为 Agent 可能心跳正常但实际没进展比如在一个循环里空转。适合那些无法方便上报进度的第三方 Agent。选择依据很简单能改 Agent 代码就用进度检查不能改就用心跳检查两者都不行才退回进程检查。我在一个项目里因为用的是第三方 Agent 框架改不了代码只能用心跳检查结果遇到过一个 Agent 心跳正常但推理陷入循环的情况最后是靠加了一个输出重复度检测才兜住。5. 实测中的坑Agent 调度和 Pod 调度不一样的地方5.1 上下文迁移为什么 Agent 不能像 Pod 一样随便漂移Pod 被驱逐后可以在另一个节点重建因为它的状态主要在 Volume 里重建后挂载同一个 Volume 就恢复了。Agent 不行——它的核心状态是内存里的上下文迁移意味着要把整个上下文序列化、传输、反序列化成本极高而且很多上下文比如模型内部的 KV cache根本没法序列化。这个差异导致一个直接后果Agent 调度要尽量避免迁移。Pod 调度器可以激进地做负载均衡把 Pod 到处挪Agent 调度器应该保守优先在原地重启只有节点彻底不可用才迁移。我在实际项目里的做法是给 Agent 加一个粘性标记调度器优先把它放回上次运行的节点。如果那个节点不可用才走迁移流程并且迁移时强制从最近的检查点恢复而不是试图搬运内存状态。5.2 资源度量的模糊性token 配额不是 CPUCPU 是个精确的度量——你需要 2 核就是 2 核调度器算得清清楚楚。但 Agent 的资源需求是模糊的一个 Agent 需要多少 token取决于任务复杂度可能这次用 1 万 token下次用 10 万。你没法在 Spec 里精确声明。这个模糊性带来两个问题。第一是放置决策不准你可能把一个实际需要大量 token 的 Agent 放到了一个配额紧张的节点。第二是配额超卖多个 Agent 声明各需 5 万 token加起来 15 万但节点只有 10 万实际运行时就会互相挤兑。我的应对策略是用历史统计代替静态声明。Agent Spec 里的配额声明只作为初始值调度器维护每个 Agent 类型的历史 token 消耗分布P50、P95放置决策时用 P95 而不是声明值。这样虽然保守一点但能避免大部分超卖问题。同时给配额加一个软上限超过就降速而不是直接杀给 Agent 一个优雅降级的机会。5.3 失败传播一个 Agent 挂了整条链怎么办多 Agent 链路里一个 Agent 失败会沿着依赖边传播。Pod 世界里这个问题相对简单——Job 失败就重试重试次数用完就标记失败。Agent 链路要复杂得多因为失败的类型多样可能是模型返回异常重试有用、可能是工具不可用重试没用要换工具、可能是上下文溢出重试没用要压缩上下文。AX 这类系统通常提供几种失败策略重试原地重试 N 次、降级换一个更简单的模型或工具、跳过标记该节点失败但继续下游、中止整条链停掉。选择哪种取决于业务语义。我的经验是默认用重试 降级组合先原地重试 2 次如果还是失败就降级到更保守的执行方式比如换小模型、减少工具调用再失败才中止。跳过策略要慎用因为下游 Agent 拿到一个空输入可能产生更隐蔽的错误比直接失败更难排查。5.4 观测性Agent 的日志和 Pod 的日志不是一回事Pod 的日志是线性的——进程启动、处理请求、输出结果、退出。Agent 的日志是树状的——它可能派生子 Agent、调用工具、产生中间推理这些都需要被追踪。用传统的日志系统看 Agent 日志你会看到一堆交错的输出根本理不清哪个属于哪个子任务。正确的做法是给每个 Agent 执行分配一个 trace ID所有相关的日志、工具调用、子 Agent 都带上这个 ID。这样你就能在观测系统里看到一棵完整的执行树。我在项目里用的是 OpenTelemetry 的 span 机制每个 Agent 是一个 span工具调用是子 span子 Agent 是嵌套 span。这样排查问题时能一眼看出是哪个环节慢、哪个环节错。6. 从 AX 看 Agent 基础设施的下一步AX 把 Agent 抽象成可调度单元这件事方向是对的但它现在还处在定义概念的阶段离生产可用还有距离。我从自己的实践出发觉得接下来这个领域会往三个方向走。第一个方向是标准化的 Agent 运行时接口。现在每个 Agent 框架都有自己的启动方式、状态管理方式、工具调用协议调度层要为每个框架写适配器。如果有一个类似 CRI容器运行时接口的 Agent 运行时接口调度层就能统一对接。AX 有可能成为这个标准的雏形。第二个方向是Agent 感知的自动扩缩。Pod 的 HPA 基于 CPU、内存这些指标扩缩但 Agent 的负载指标是待处理任务数平均任务时长模型配额利用率。这些指标需要新的采集和扩缩策略。我试过用待处理任务数做扩缩效果比 CPU 指标好得多因为 Agent 的瓶颈通常不在 CPU。第三个方向是跨集群的 Agent 调度。单个集群的 Agent 调度解决后下一个问题就是多个集群之间怎么调度——比如把 Agent 放到离数据近的集群、或者放到配额充裕的集群。这需要一套跨集群的调度协议复杂度比单集群高一个量级。如果你现在正在做 Agent 平台我的建议是不要等标准成熟先用本文第 4 节的思路搭一个最小可用的调度层。核心就是三件事定义 Agent Spec、实现放置打分、做好资源回收。这三件事做扎实了后面无论 AX 怎么演进你的系统都能平滑对接。真正难的不是调度算法本身而是把 Agent 的生命周期语义想清楚——这一点Pod 的设计给了我们足够好的参照。