1. 从"ax"这个标题说起：一个被低估的运行时编排命题

第一次看到"ax"这个标题，配合 agentic、orchestration、runtime、Kubernetes 这几个关键词，我脑子里蹦出来的第一个念头是：这大概率不是一个具体的开源项目名，而是一个缩写或者代号，指向的是"agentic execution"这条线上的一整套运行时编排方案。为什么这么判断？因为最近半年，围绕 agentic 这个词冒出来的工程问题，几乎全部集中在同一个痛点上——单个 agent 好写，多个 agent 一编排就乱，一上生产环境就崩。

我接触过不少团队，他们做 demo 的时候，一个 agent 调几个工具、跑几轮循环，效果惊艳。可一旦要把这套东西塞进 Kubernetes 集群，让它稳定地跑几十上百个并发任务，问题就全来了：状态往哪存、任务怎么调度、失败了怎么重试、多个 agent 之间怎么通信、资源怎么隔离。这些问题的本质，其实不是"AI 能力"的问题，而是**运行时（runtime）和编排（orchestration）**的问题。而"ax"这个标题，恰好把这三个词——agentic、orchestration、runtime——串在了一起，再加上 Kubernetes 这个底座，指向的就是"如何把 agentic 工作负载当成一等公民，跑在云原生基础设施上"。

这篇文章我想聊的，就是这条线。它适合谁看？如果你正在把 agent 应用从"本地脚本"往"生产集群"迁移，如果你被 agent 的状态管理、任务编排、资源调度搞得头大，如果你想知道 Kubernetes 这套东西到底能不能、该怎么承载 agentic 负载，那这篇内容应该能给你一些能直接抄的作业。我不会只讲概念，会把原理、选型理由、实操步骤、踩过的坑都摊开讲。全文基于我对 agentic runtime 和 Kubernetes 编排的常见工程实践来展开，涉及具体参数和配置的地方，我会说明推导逻辑，你可以根据自己的环境调整。

先给一个我自己的核心判断：agentic 负载和传统微服务负载，在运行时特征上有本质区别，直接套用微服务的编排思路会翻车。这个判断贯穿全文，后面每一节其实都在论证它。

2. agentic 负载到底特殊在哪：和传统微服务的运行时差异

2.1 长时运行、状态密集、非确定性：三个绕不开的特征

传统微服务处理一个请求，通常是毫秒到秒级，无状态，输入输出确定。你给它同样的输入，它给你同样的输出，扩容就是加副本，简单粗暴。但 agentic 负载完全是另一回事。

第一，长时运行。一个 agent 任务可能跑几分钟甚至几小时，中间要经历多轮"思考—调工具—观察结果—再思考"的循环。这意味着它不能像 HTTP 请求那样"来了就处理、处理完就释放"，它需要一个能长期存活、能挂起能恢复的执行单元。

第二，状态密集。agent 的每一轮循环都依赖前面的上下文：对话历史、工具调用结果、中间推理链。这些状态如果丢了，任务就得从头再来，成本极高。传统微服务可以做到完全无状态，agent 做不到。

第三，非确定性。同样的输入，agent 可能走不同的工具调用路径，消耗不同的 token，耗时也天差地别。这让基于固定 QPS 的容量规划彻底失效——你没法预测下一秒会有多少个 agent 同时卡在"等大模型返回"这一步。

把这三个特征放在一起，你会发现一个残酷的事实：agentic 负载既像批处理任务（长时、有状态），又像在线服务（要低延迟响应、要弹性伸缩），还是个"薛定谔的资源消耗者"（不确定要多少算力）。这就是为什么它难编排。

2.2 为什么"直接上 K8s Deployment"会踩坑

很多人的第一反应是：既然要上 Kubernetes，那就写个 Deployment，把 agent 打包成容器，副本数设个 10，完事。我见过太多团队这么干，然后被现实教育。

问题出在几个地方。Deployment 假设 Pod 是无状态的、可随意替换的，但 agent Pod 里可能正跑着一个跑了 20 分钟的任务，你一个滚动更新把它干掉，任务就废了。Deployment 也不管任务的生命周期——它只保证"有 N 个 Pod 在跑"，不保证"这 N 个 Pod 各自在正确处理一个独立任务"。更麻烦的是，agent 任务往往需要独占某些资源（比如一个特定的会话上下文、一个独占的模型连接），Deployment 的负载均衡模型根本不支持这种"任务亲和性"。

所以正确的思路是：把 agent 任务建模成 Job 或自定义资源（CRD），而不是 Deployment。Job 天然支持"运行到完成"的语义，配合 Indexed Job 还能给每个 Pod 分配唯一索引，正好对应"每个 agent 处理一个独立任务"。如果要更精细的控制，就得上 CRD + Operator，把 agent 任务的生命周期管理逻辑写进控制器里。这是"ax"这类方案的核心设计取向。

2.3 一个具体的对比：三种编排模型的取舍

为了让你直观感受差异，我列个表对比一下。

我的经验是：原型阶段用 Indexed Job 快速验证，生产阶段一定要上 CRD + Operator。因为 agent 任务的编排需求会随着业务复杂化不断膨胀——今天你只需要"跑完一个任务"，明天你就需要"任务 A 完成后触发任务 B，B 依赖 A 的输出，且 B 要能根据 A 的结果动态决定跑几个实例"。这些用原生 Job 表达会非常别扭，用 CRD 就很自然。

3. 把 agent 任务抽象成 Kubernetes 原生资源：CRD 设计实操

3.1 为什么是 CRD，而不是在应用层自己管

有人会问：我为什么非要用 Kubernetes 的 CRD？我在应用层自己写个任务队列、自己管状态不行吗？行，但你等于把 Kubernetes 已经帮你解决的一大堆问题重新实现一遍：调度、资源配额、健康检查、故障自愈、日志收集、网络策略。这些基础设施能力，Kubernetes 已经打磨了很多年，你没必要重造。

CRD 的价值在于：它让你用 Kubernetes 的原生语言（声明式 API）来描述 agent 任务，从而复用整个云原生生态。你定义一个AgentTask资源，声明"我要跑一个 agent 任务，用哪个模型、给多少资源、超时多久"，剩下的交给控制器去 reconcile。这种声明式模型特别适合 agent 场景，因为 agent 任务本身就是"期望状态"和"实际状态"不断对齐的过程。

3.2 一个可落地的 AgentTask CRD 定义

下面这个 CRD 是我在实际项目中用过的一个简化版本，你可以直接拿去改。它定义了 agent 任务的核心字段。

apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: agenttasks.ax.example.com spec: group: ax.example.com versions: - name: v1alpha1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: model: type: string description: "使用的模型标识" maxRounds: type: integer default: 20 description: "agent 最大循环轮数，防止死循环" timeoutSeconds: type: integer default: 3600 description: "任务超时时间" tools: type: array items: type: string description: "允许调用的工具列表" checkpointEnabled: type: boolean default: true description: "是否开启状态检查点" required: - model scope: Namespaced names: plural: agenttasks singular: agenttask kind: AgentTask shortNames: - at

这里有几个字段的设计意图值得说清楚。maxRounds是我强烈建议加的——agent 最容易出的生产事故就是死循环，模型反复调用同一个工具、反复得到同样的结果，token 哗哗烧。设一个硬上限，到点就终止，这是保命字段。timeoutSeconds同理，防止任务卡死。checkpointEnabled则是为状态恢复准备的，后面会细讲。

3.3 控制器 reconcile 逻辑的关键分支

CRD 定义好只是第一步，真正干活的是控制器。控制器的核心是一个 reconcile 循环：读取 AgentTask 的期望状态，对比实际状态，然后采取行动。这里的关键分支有几个。

第一个分支是任务创建。当控制器发现一个 AgentTask 还没有对应的 Pod 时，它要创建一个 Pod（或 Job）来执行。这里要注意：Pod 的命名要带上 AgentTask 的名字和 UID，方便追踪。

第二个分支是状态同步。agent 执行过程中会不断更新自己的进度，控制器要定期把这些进度写回 AgentTask 的 status 字段。这里有个坑：不要用高频更新 status，Kubernetes 的 etcd 扛不住。我的做法是让 agent 把状态写到外部存储（比如 Redis 或对象存储），AgentTask 的 status 只存一个指针和摘要。

第三个分支是失败处理。任务失败时，控制器要根据重试策略决定是重试还是标记为失败。这里要区分"可重试失败"（比如临时网络抖动）和"不可重试失败"（比如模型返回了非法输出）。我的经验是给 AgentTask 加一个retryPolicy字段，明确指定最大重试次数和退避策略。

第四个分支是清理。任务完成后，相关的 Pod、临时存储、网络资源都要清理掉，避免资源泄漏。这一步最容易被忽略，但生产环境里不清理就是慢性自杀。

4. 状态管理：agentic runtime 最容易被低估的硬骨头

4.1 为什么 agent 的状态不能只放在内存里

我见过最典型的翻车场景是这样的：一个 agent 任务跑了 15 分钟，已经调用了七八个工具，积累了大量的中间结果，结果 Pod 因为节点资源紧张被驱逐了。因为状态全在内存里，任务从头再来，前面 15 分钟白干，token 成本翻倍。

所以 agentic runtime 的第一条铁律是：状态必须外部化，且要能检查点（checkpoint）。所谓检查点，就是在 agent 循环的某些关键节点，把当前完整状态（对话历史、工具调用记录、中间变量）持久化下来。这样即使 Pod 挂了，新的 Pod 也能从最近的检查点恢复，而不是从零开始。

4.2 检查点存储的选型：Redis、对象存储还是数据库

检查点存哪里，是个需要权衡的问题。我列个表对比。

我的实际选择是：短任务（<10 分钟）用 Redis，长任务用对象存储，需要复杂查询的用数据库。更常见的做法是组合使用——热状态放 Redis，冷检查点定期归档到对象存储。这样既保证了恢复速度，又控制了成本。

4.3 检查点的粒度：太粗丢进度，太细拖性能

检查点不是越频繁越好。每存一次状态，都要序列化、网络传输、落盘，这些都是开销。如果 agent 每调用一次工具就存一次，性能会被拖垮；如果只在任务结束时存一次，那检查点就失去了意义。

我的经验值是：按"轮次"存，而不是按"操作"存。agent 的一轮循环（思考 + 工具调用 + 观察）结束后存一次，通常一轮几秒到几十秒，这个频率比较合理。另外，对于特别大的状态（比如 agent 处理了一个大文件），可以采用增量检查点，只存变化的部分。

还有一个技巧：检查点要带版本号。因为你的 agent 逻辑可能会升级，新旧版本的状态结构可能不兼容。带版本号后，恢复时可以先判断版本，必要时做状态迁移。这个细节很多团队一开始不做，等到要升级 agent 逻辑时就痛苦了。

5. 编排层：多 agent 协作时的调度与通信设计

5.1 单 agent 是玩具，多 agent 才是生产

单个 agent 能做的事有限，真正的生产场景往往是多个 agent 协作：一个负责规划，几个负责执行，一个负责审核。这就带来了编排问题——谁先跑、谁等谁、结果怎么传递、失败了怎么办。

在 Kubernetes 里做多 agent 编排，核心是把 agent 之间的依赖关系表达成资源之间的依赖。比如用 CRD 的 ownerReference 表达父子关系，用 finalizer 控制清理顺序，用 label selector 做任务分组。这些是 Kubernetes 原生的机制，用好了比自己造轮子稳得多。

5.2 用 DAG 表达 agent 依赖：比线性流水线更贴近现实

很多团队一开始把 agent 编排做成线性流水线：A 跑完跑 B，B 跑完跑 C。但现实中的 agent 协作更像 DAG（有向无环图）：A 跑完后，B 和 C 可以并行，D 要等 B 和 C 都完成。用线性模型表达这个会很别扭。

我的做法是：在 AgentTask 里加一个dependsOn字段，列出前置任务。控制器在创建 Pod 前先检查所有依赖是否完成，没完成就等待。这样天然支持 DAG。配合 Kubernetes 的 informer 机制，依赖完成时能及时触发下游任务，不用轮询。

这里有个坑要注意：DAG 里如果有环，会导致死锁。所以控制器在创建任务时要做一个环检测，发现环就拒绝创建并报错。这个校验一定要做，否则一个配置错误就能让整个任务图卡死。

5.3 agent 之间的通信：别用共享内存，用消息或 API

多个 agent 之间怎么传递数据？我见过有人用共享的 PersistentVolume，几个 Pod 挂同一个卷读写文件。这个方案在 demo 里能跑，生产里问题很多：并发写冲突、文件锁、卷的性能瓶颈。

更靠谱的方案有两种。一是消息队列：agent 把结果发到队列，下游 agent 订阅。Kubernetes 里可以部署 NATS、RabbitMQ 这类轻量消息中间件。二是内部 API：每个 agent 暴露一个 HTTP 接口，其他 agent 通过 Service 调用。前者适合异步、解耦的场景，后者适合需要同步响应的场景。

我的偏好是消息队列，因为 agent 任务天然是异步的，而且消息队列天然支持重试和死信处理，正好对应 agent 任务可能失败需要重试的需求。

6. 资源调度与弹性：让 agent 任务既跑得动又不浪费

6.1 agent 的资源画像：为什么 request 和 limit 要拉开差距

给 agent Pod 设资源配额是个技术活。设小了，任务跑不动或者被 OOM Kill；设大了，集群资源浪费。agent 的特殊之处在于它的资源消耗是脉冲式的：大部分时间在等模型返回（几乎不耗 CPU），偶尔在解析大结果或做本地计算时飙一下。

所以我的建议是：request 设小，limit 设大，拉开差距。比如 request 给 500m CPU、512Mi 内存，limit 给 2 CPU、4Gi 内存。这样调度器按 request 来安排，能塞下更多 Pod；而实际运行时如果某个 agent 需要爆发，也不会被立刻掐死。当然，limit 设太大也有风险，一个失控的 agent 可能把节点资源吃光，所以要配合 Pod 的优先级和抢占策略。

6.2 用 HPA 还是 KEDA：agent 任务的弹性伸缩选型

传统的 HPA（Horizontal Pod Autoscaler）基于 CPU/内存指标伸缩，但 agent 任务的瓶颈往往不是 CPU，而是队列里积压的任务数。CPU 可能很低（都在等模型），但任务已经堆成山了。这时候 HPA 完全失灵。

正确的工具是KEDA（Kubernetes Event-driven Autoscaling）。KEDA 能基于外部事件源（消息队列长度、数据库记录数、自定义指标）来伸缩。对于 agent 场景，你可以让 KEDA 监听任务队列的长度，队列长了就多起 Pod，队列空了就缩到零。这个"缩到零"的能力特别重要——agent 任务往往是突发性的，没任务的时候不该占着资源。

配置 KEDA 的关键是选对 scaler 和设对阈值。比如用 Redis 队列做 scaler，listLength设成 5，意思是每个 Pod 平均处理 5 个待办任务。这个值要根据单个 agent 的处理能力来调，设太小会频繁伸缩（抖动），设太大响应会慢。

6.3 抢占与优先级：让重要任务先跑

生产环境里，agent 任务往往有优先级之分。比如用户实时触发的任务，优先级要高于后台批量任务。Kubernetes 的 PriorityClass 正好干这个。

我的做法是定义三档优先级：high（实时任务）、normal（常规任务）、low（批量任务）。高优先级 Pod 可以抢占低优先级 Pod 的资源。配合 preemptionPolicy，还能控制抢占行为。这样在资源紧张时，重要任务能优先拿到资源，批量任务被挤到后面，符合业务预期。

7. 可观测性：agent 任务出问题时你怎么查

7.1 agent 的日志不是普通日志：结构化是底线

agent 的日志比普通服务复杂得多，因为它包含推理过程、工具调用、中间结果，信息量巨大。如果日志是非结构化的纯文本，出问题时你根本没法查。

我的要求是：agent 日志必须结构化，至少包含 traceId、taskId、round、eventType、payload 这几个字段。traceId 用来串联一次完整任务的所有日志，taskId 对应 AgentTask，round 是第几轮循环，eventType 区分是思考、工具调用还是观察结果。这样你就能按 traceId 把一次任务的完整链路捞出来，按 round 看它卡在哪一轮。

日志收集用 Fluent Bit 或 Vector 都行，输出到 Elasticsearch 或 Loki。Loki 更轻量，适合日志量大的场景。

7.2 指标埋点：除了 CPU 内存，还要盯这几个 agent 专属指标

普通的 CPU、内存、网络指标当然要监控，但 agent 场景还需要一些专属指标。我列几个我认为必看的。

• 任务成功率：按任务类型分组，看哪类任务容易失败。
• 平均轮数：agent 平均跑几轮完成，轮数异常升高往往意味着模型在"绕圈子"。
• token 消耗速率：这是成本指标，突然飙升要告警。
• 检查点恢复次数：恢复次数多说明 Pod 不稳定，要查节点或资源问题。
• 队列等待时长：任务从提交到开始执行的等待时间，反映调度能力。

这些指标用 Prometheus 采集，Grafana 展示。关键是设好告警阈值，比如 token 消耗速率超过基线 3 倍就告警，能帮你及时发现失控的 agent。

7.3 分布式追踪：把一次 agent 任务的完整链路串起来

agent 任务跨多个 Pod、多个服务，出问题时靠日志拼凑很痛苦。分布式追踪能帮你把整条链路可视化。用 OpenTelemetry 做埋点，每个 agent 循环、每次工具调用都作为一个 span，最后在 Jaeger 或 Tempo 里能看到完整的调用树。

这里有个 agent 特有的挑战：agent 的调用链是动态的，不像微服务那样调用关系固定。所以 span 的父子关系要在运行时动态建立。我的做法是给每个 agent 任务一个根 span，每轮循环一个子 span，工具调用再往下挂。这样即使路径动态，链路也是清晰的。

8. 我踩过的几个坑和对应的解法

8.1 坑一：Pod 驱逐导致任务丢失，检查点救了我

早期我们没做检查点，一个跑了半小时的任务因为节点驱逐丢了，客户投诉。后来加了检查点，同样的驱逐发生后，新 Pod 从最近的检查点恢复，只损失了不到一轮的进度。这个教训让我明白：在 agent 场景下，检查点不是可选项，是必选项。

8.2 坑二：status 高频更新把 etcd 打爆

有一次我们的控制器每秒钟更新好几次 AgentTask 的 status，结果 etcd 的写入延迟飙升，整个集群的 API 响应都变慢了。后来改成状态写外部存储，status 只存摘要，问题解决。Kubernetes 的 etcd 是共享资源，任何高频写入都要警惕。

8.3 坑三：agent 死循环烧掉大量 token

有个 agent 因为工具返回了非预期格式，反复重试同一个调用，一晚上烧掉了预算的一大截。后来加了maxRounds硬上限和 token 消耗速率告警，这类问题就能及时止损。agent 的自主性是把双刃剑，必须有硬约束兜底。

8.4 坑四：DAG 配置成环导致任务永久等待

有次配置依赖时手滑写了个环，A 等 B、B 等 A，两个任务永远卡在等待状态，还占着资源。后来在控制器里加了环检测，创建时就拒绝。任何图结构的编排，环检测都是必须的。

9. 关于"ax"这类方案，我的一些个人判断

聊了这么多，回到"ax"这个标题本身。我的理解是，它代表的是agentic execution 在云原生基础设施上落地的一整套工程范式——用 Kubernetes 的声明式 API 描述 agent 任务，用 CRD + Operator 管理生命周期，用外部化状态和检查点保证可靠性，用 KEDA 做弹性，用结构化日志和分布式追踪做可观测性。

这套范式不是银弹，它有自己的成本：你需要写控制器、需要维护 CRD、需要理解 Kubernetes 的很多细节。但如果你真的要把 agent 应用做成生产级的东西，这些投入是值得的。因为 agent 负载的特殊性决定了，你没法用传统微服务那套简单粗暴的方式糊弄过去。

我个人的体会是，做 agentic runtime 这件事，工程复杂度的大头不在 AI 那一侧，而在编排和状态管理这一侧。模型能力会随着时间提升，但编排和状态管理的坑，得靠工程手段一个个填。谁把这块做扎实了，谁就能把 agent 应用真正跑在生产环境里，而不是停留在 demo 阶段。

最后分享一个我常用的排查思路：当 agent 任务出问题时，先看检查点恢复次数，再看平均轮数，最后看 token 消耗曲线。这三个指标基本能定位 80% 的问题——恢复次数高是基础设施问题，轮数高是模型或工具问题，token 飙升是失控问题。按这个顺序查，效率很高。