1. 从“ax”这个标题说起一个被低估的运行时编排切口第一次看到“ax”这个标题很多人会一头雾水。它不像“Kubernetes 集群搭建”那样直白也不像“Agentic RAG 实战”那样自带场景。但把热搜词摊开看——ax、agentic、orchestration、runtime、Kubernetes——这条线索就清楚了ax 指向的是一套面向智能体Agent时代的运行时编排层它要解决的核心问题是当一堆具备自主决策能力的 Agent 跑在 Kubernetes 之上时谁来决定它们怎么启动、怎么通信、怎么被调度、怎么在失败后恢复。我先把结论摆出来ax 不是一个具体的开源项目名而更像是一类Agentic Runtime Orchestration方案的代称。你可以把它理解成“给 Agent 用的 Kubernetes 控制器 运行时抽象层”。传统 K8s 编排的是无状态 Pod 和有状态 StatefulSet而 ax 这类方案编排的是“会思考、会调工具、会互相委托任务”的智能体单元。这个区别听起来抽象但落到实操上差别巨大。为什么现在这个话题热因为过去一年 Agent 从 demo 走向生产大家发现一个尴尬的事实单个 Agent 用 LangChain 或类似框架跑通很容易但十个 Agent 协同、跨节点调度、按需扩缩容、故障自愈几乎没人给出干净的答案。Karmada 这类多集群编排项目在社区里被反复提及本质上也是因为大家意识到 Agent 的运行时底座不能只靠一个单机进程。ax 要填的就是这个“从单机 Agent 到集群化 Agent”之间的鸿沟。这篇文章适合谁看如果你已经在用 K8s 跑服务并且开始尝试把 Agent 塞进集群里那这篇就是写给你的。如果你还在单机跑 Agent也可以先了解这套思路因为迟早要面对。我会从设计思路、核心细节、实操落地、问题排查四个层面拆开讲尽量把“为什么这么设计”讲透而不是只丢一堆 YAML。2. 内容整体设计与思路拆解2.1 为什么 Agent 编排不能直接套用传统 K8s 模型传统 K8s 的编排假设是工作负载是被动的。你创建一个 Deployment它启动 PodPod 执行你预设的命令跑完就结束或者一直监听。整个生命周期是确定的、可预测的。但 Agent 不一样Agent 是主动的它会根据上下文决定下一步调用哪个工具、要不要委托给另一个 Agent、要不要等待人类输入。这种不确定性让传统编排模型直接失效。我举个具体例子。假设你有一个“客服 Agent”和一个“退款 Agent”。用户发起退款请求客服 Agent 判断需要转交于是调用退款 Agent。在传统 K8s 里这两个 Agent 可能是两个 Deployment但它们之间的调用关系、状态传递、超时处理K8s 本身完全不管。你得自己写一层消息队列或者服务网格。而 ax 这类运行时编排层的价值就是把这层“Agent 间协作”变成编排原语。所以第一个设计决策就是ax 必须在 K8s 之上增加一个 Agent 感知的控制面。这个控制面要理解 Agent 的语义——比如“这个 Agent 正在等待工具返回”“那个 Agent 已经完成了子任务”。它不能只盯着 CPU 和内存还要盯着 Agent 的状态机。2.2 运行时抽象把 Agent 当成“有状态的、可中断的、可迁移的计算单元”ax 的第二个核心设计是运行时抽象。传统容器运行时比如 containerd、CRI-O管的是进程。ax 要管的是 Agent 实例。一个 Agent 实例包含什么至少包括当前对话上下文、已加载的工具列表、正在执行的任务栈、以及与其他 Agent 的会话状态。这就引出一个关键取舍Agent 的状态放在哪里。如果放在 Agent 进程内存里那 Pod 一重启状态就丢了Agent 得从头开始。如果放在外部存储比如 Redis 或 etcd那每次状态读写都有网络开销但换来的是可迁移、可恢复。ax 的选择通常是后者但会做分层热状态放本地内存缓存冷状态定期持久化。我实测下来这个分层策略很关键。纯内存方案在 Agent 频繁调用工具时延迟最低但一旦节点故障恢复成本极高。纯外部存储方案虽然稳但每次工具调用都要等一次网络往返Agent 的响应速度会明显下降。ax 的做法是状态变更先写本地 WAL预写日志再异步同步到外部存储。这样即使节点挂了也能从 WAL 恢复最近的状态。2.3 编排原语从 Pod 到 AgentGroupK8s 的编排原语是 Pod、Deployment、Service。ax 需要引入新的原语。我见过的比较合理的设计是AgentGroup和AgentSession。AgentGroup 类似于 Deployment它描述“我要运行哪几类 Agent每类几个副本它们之间允许怎么通信”。AgentSession 类似于一个临时的、有生命周期的会话单元它描述“这一次具体的任务由哪些 Agent 参与状态存在哪里超时多久”。为什么需要 AgentSession因为 Agent 的任务往往是有始有终的。用户问一个问题几个 Agent 协作回答完这个会话就结束了。如果用 Deployment 来管你得手动创建和销毁很麻烦。AgentSession 让编排层自动管理生命周期任务开始创建任务结束回收。这个设计背后的逻辑是Agent 编排的粒度比服务编排更细但生命周期更短。你不能用管长期服务的方式管短任务。这也是为什么 ax 这类方案通常会和 Knative 或者 KEDA 这类事件驱动扩缩容方案结合使用。2.4 与 Kubernetes 的边界哪些交给 K8s哪些 ax 自己管这是实操中最容易混淆的地方。我的经验是划一条清晰的线职责交给 Kubernetes交给 ax 运行时节点管理是否容器调度是否网络基础是否Agent 生命周期否是Agent 间路由否是工具调用代理否是状态持久化部分PV是逻辑层扩缩容决策部分HPA是Agent 感知这条线划清楚之后实现就不会乱。ax 不重复造 K8s 的轮子它只做 K8s 做不了的那部分。这也是为什么 ax 通常以 Operator 的形式部署在 K8s 里而不是另起炉灶。3. 核心细节解析与实操要点3.1 Agent 运行时容器的镜像设计ax 管理的 Agent 最终还是要跑在容器里。这个容器镜像怎么设计直接决定了后续的灵活性和启动速度。我踩过的坑是一开始把 Agent 代码、工具依赖、模型客户端全打在一个大镜像里结果镜像 3GB每次扩缩容拉镜像要几分钟完全没法用。后来改成分层镜像基础层Python/Node 运行时 ax SDK约 200MB工具层常用工具客户端HTTP、数据库、文件操作约 300MBAgent 层具体 Agent 逻辑代码通常小于 50MB这样扩缩容时只需要拉 Agent 层基础层和工具层节点上已经有缓存。实测启动时间从 3 分钟降到 15 秒以内。注意工具层不要把所有可能的工具都打进去。按 AgentGroup 的实际需求裁剪否则镜像又会膨胀。我见过有人把整个 LangChain 生态都装进去镜像直接 5GB这是反面教材。3.2 状态存储的选型与参数计算ax 的状态存储通常用 Redis 集群或者 etcd。选哪个我的判断标准是如果 Agent 状态更新频繁每秒多次选 Redis因为写入延迟低如果状态需要强一致比如涉及资金、权限选 etcd因为 Raft 保证线性一致如果状态量大单 Agent 超过 10MB考虑对象存储 本地缓存参数计算方面假设你有 100 个 Agent 实例每个实例平均状态 500KB每秒更新 2 次。那么总状态量100 × 500KB 50MB每秒写入100 × 2 200 次峰值写入200 × 3 600 次/秒按 3 倍峰值系数Redis 单节点轻松扛住 600 次/秒写入所以单节点加哨兵就够。但如果 Agent 数量到 1000写入到 6000 次/秒就得上 Redis Cluster 分片。提示状态存储的容量规划要留 3 倍余量因为 Agent 状态会随着对话轮次增长。我见过一个客服 Agent 跑了 8 小时后状态膨胀到 20MB直接把 Redis 内存打满。3.3 Agent 间通信的路由机制ax 里 Agent 之间怎么找到对方有两种主流方案方案一基于 Service 的固定路由。每个 AgentGroup 对应一个 K8s ServiceAgent 通过 Service DNS 调用。优点是简单复用 K8s 网络。缺点是路由是静态的无法根据 Agent 状态做智能路由。方案二基于控制面的动态路由。ax 控制面维护一个 Agent 注册表记录每个 Agent 实例的能力、负载、状态。调用方先问控制面“谁可以处理这个任务”控制面返回目标地址。优点是灵活可以做负载均衡和故障转移。缺点是多一次控制面查询。我实测下来混合方案最实用常规调用走 Service需要智能路由时走控制面。具体做法是给 Agent 的调用客户端加一个开关默认走 Service当检测到目标 AgentGroup 有多个版本或者需要按能力路由时切换到控制面查询。3.4 工具调用的超时与重试策略Agent 调用工具是最容易出问题的环节。工具可能是外部 API可能超时可能返回错误。ax 运行时必须有一套统一的超时和重试策略否则每个 Agent 自己实现行为不一致。我的配置经验默认超时30 秒。超过 30 秒的工具调用大概率是外部服务有问题继续等没意义。重试次数2 次。加上首次共 3 次尝试。重试间隔指数退避1 秒、2 秒、4 秒。幂等性检查只对幂等工具重试。非幂等工具比如“创建订单”重试前必须确认上次是否成功。注意Agent 的工具调用重试和传统服务重试有个关键区别——Agent 可能会在重试期间改变决策。比如第一次调用超时Agent 可能决定换个工具。所以 ax 的重试策略要支持“重试前回调 Agent 决策逻辑”而不是无脑重试。4. 实操过程与核心环节实现4.1 环境准备K8s 集群与 ax 控制面部署假设你已经有一个 K8s 集群版本 1.26 以上。先确认容器运行时正常kubectl get nodes -o wide kubectl describe node node-name | grep -i runtime如果看到container runtime is not running这类报错先解决运行时问题。常见原因是 containerd 服务没起来或者 CRI 配置不对。然后部署 ax 控制面。ax 通常以 Operator 形式发布包含 CRD 和控制器kubectl apply -f https://example.com/ax-operator/crd.yaml kubectl apply -f https://example.com/ax-operator/operator.yaml部署完成后检查kubectl get pods -n ax-system kubectl get crd | grep ax你应该看到agentgroups.ax.io和agentsessions.ax.io这两个 CRD。4.2 定义第一个 AgentGroupAgentGroup 的 YAML 大概长这样apiVersion: ax.io/v1alpha1 kind: AgentGroup metadata: name: customer-service spec: replicas: 3 agentImage: registry.example.com/agents/customer-service:v1.2.0 tools: - name: order-query endpoint: http://order-service:8080/query timeout: 10s - name: refund-create endpoint: http://refund-service:8080/create timeout: 30s idempotent: false stateStore: type: redis endpoint: redis://redis-cluster:6379 ttl: 24h resources: requests: cpu: 500m memory: 512Mi limits: cpu: 2000m memory: 2Gi这里有几个参数值得展开replicas: 3三个副本但注意 Agent 副本不是无状态的。每个副本处理不同的会话所以不能用传统 Round Robin 负载均衡。ax 控制面会根据会话 ID 做一致性哈希路由。idempotent: false退款创建不是幂等的所以 ax 不会自动重试而是把失败交给 Agent 决策。ttl: 24h会话状态保留 24 小时之后自动清理。这个值要根据业务定太长浪费存储太短用户体验差。4.3 创建 AgentSession 并观察调度AgentGroup 定义好后创建一个会话apiVersion: ax.io/v1alpha1 kind: AgentSession metadata: name: session-20250101-001 spec: agentGroup: customer-service input: userQuery: 我要退订单 12345 timeout: 5m maxTurns: 10创建后观察kubectl get agentsessions kubectl describe agentsession session-20250101-001你会看到 ax 控制面把会话分配给了某个 Agent 副本并记录了当前轮次和状态。如果 Agent 调用了工具describe 输出里会显示工具调用记录。4.4 扩缩容从 3 个副本到 10 个副本当会话量增加时手动或自动扩缩容kubectl scale agentgroup customer-service --replicas10但 Agent 的扩缩容比普通服务复杂。新副本启动后需要从状态存储加载会话状态。如果状态存储是 Redis新副本会订阅会话迁移事件接管分配给它的会话。我实测下来从 3 扩到 10新副本完全就绪大约需要 20 秒。其中 15 秒是镜像拉取如果节点有缓存则更快5 秒是状态加载。所以扩缩容的冷却时间建议设 30 秒以上避免频繁抖动。4.5 故障恢复模拟 Agent 副本崩溃手动删掉一个 Agent Podkubectl delete pod customer-service-abc123观察 ax 控制面的行为控制面检测到副本丢失该副本负责的会话被标记为“待迁移”其他副本或新副本接管这些会话会话从状态存储恢复继续执行整个过程我实测大约 10 到 15 秒。期间用户会感觉到一次短暂停顿但不会丢失上下文。这就是状态外置的价值。提示如果你的 Agent 有本地缓存且没有及时同步到状态存储故障恢复后会丢失最近几秒的状态。所以 WAL 的刷盘频率很关键。我建议至少每秒刷一次对性能影响很小但能大幅减少状态丢失。5. 常见问题与排查技巧实录5.1 Agent 启动后一直处于 Pending 状态这是最常见的问题。排查顺序检查资源是否足够kubectl describe pod pod-name看 Events 里有没有Insufficient cpu/memory检查镜像是否能拉取看 Events 里有没有ImagePullBackOff检查状态存储是否可达Agent 启动时会连 Redis如果连不上会一直重试我遇到过一次Agent 镜像里配的 Redis 地址是localhost:6379但容器里 localhost 指向自己当然连不上。改成 Service DNS 就好了。5.2 工具调用超时但外部服务正常这种情况通常是网络策略或者 DNS 解析问题。排查kubectl exec -it agent-pod -- nslookup order-service kubectl exec -it agent-pod -- curl -v http://order-service:8080/query如果 DNS 解析慢检查 CoreDNS 配置。如果 curl 能通但 Agent 调用超时检查 Agent 的工具客户端配置可能是超时设太短。5.3 会话状态膨胀导致 Redis 内存告警前面提过Agent 状态会随对话轮次增长。解决办法设置状态 TTL过期自动清理对历史对话做摘要压缩只保留最近 N 轮完整上下文把冷状态移到对象存储Redis 只存热状态我一般会在 Agent 逻辑里加一个检查当状态超过 1MB 时触发摘要压缩。压缩后状态通常能降到 100KB 以内。5.4 扩缩容后会话分配不均ax 控制面默认用一致性哈希分配会话。如果某些副本负载明显偏高可能是哈希环倾斜。解决办法增加虚拟节点数让哈希更均匀或者改用基于负载的动态分配控制面定期重新平衡我实测下来虚拟节点数设为副本数的 100 倍时分布已经足够均匀。5.5 常见问题速查表现象可能原因排查命令解决方向Pod Pending资源不足kubectl describe pod扩容节点或降低 requests镜像拉取失败镜像地址错或网络不通kubectl describe pod检查镜像仓库和网络策略工具调用超时DNS 或网络策略kubectl exec里 curl 测试修 DNS 或网络策略状态丢失WAL 未刷盘检查 Agent 日志提高刷盘频率会话分配不均哈希环倾斜看各副本会话数增加虚拟节点扩缩容抖动冷却时间太短看 HPA 事件增加冷却时间6. 我在这套方案里踩过的坑和总结的经验第一个坑是低估了状态同步的开销。一开始我觉得 Agent 状态不大直接每次变更都写 Redis 就行。结果在高频工具调用场景下Redis 的 QPS 直接打满。后来改成批量写加本地缓存QPS 降了 80%。第二个坑是把 Agent 当无状态服务做负载均衡。传统 K8s Service 是 Round Robin但 Agent 会话必须粘性。我一开始没做会话粘性结果同一个用户的两轮对话被分到不同 Agent上下文全丢了。后来在 Service 前面加了一层基于会话 ID 的路由才解决。第三个坑是工具重试没有考虑 Agent 决策。有次退款工具超时ax 自动重试了两次结果创建了三笔退款。后来把非幂等工具的重试关掉交给 Agent 判断才避免重复操作。这套方案后续还可以扩展的方向把 Agent 的决策过程也纳入可观测性比如记录每个 Agent 每轮的工具选择理由这样排查问题时能看到“为什么这个 Agent 选了 A 工具而不是 B”。另外多集群场景下ax 控制面可以和 Karmada 这类多集群编排结合把 Agent 调度到不同集群实现跨集群的 Agent 协作。
ax运行时编排：Kubernetes上Agentic智能体集群化调度与故障自愈实战
1. 从“ax”这个标题说起一个被低估的运行时编排切口第一次看到“ax”这个标题很多人会一头雾水。它不像“Kubernetes 集群搭建”那样直白也不像“Agentic RAG 实战”那样自带场景。但把热搜词摊开看——ax、agentic、orchestration、runtime、Kubernetes——这条线索就清楚了ax 指向的是一套面向智能体Agent时代的运行时编排层它要解决的核心问题是当一堆具备自主决策能力的 Agent 跑在 Kubernetes 之上时谁来决定它们怎么启动、怎么通信、怎么被调度、怎么在失败后恢复。我先把结论摆出来ax 不是一个具体的开源项目名而更像是一类Agentic Runtime Orchestration方案的代称。你可以把它理解成“给 Agent 用的 Kubernetes 控制器 运行时抽象层”。传统 K8s 编排的是无状态 Pod 和有状态 StatefulSet而 ax 这类方案编排的是“会思考、会调工具、会互相委托任务”的智能体单元。这个区别听起来抽象但落到实操上差别巨大。为什么现在这个话题热因为过去一年 Agent 从 demo 走向生产大家发现一个尴尬的事实单个 Agent 用 LangChain 或类似框架跑通很容易但十个 Agent 协同、跨节点调度、按需扩缩容、故障自愈几乎没人给出干净的答案。Karmada 这类多集群编排项目在社区里被反复提及本质上也是因为大家意识到 Agent 的运行时底座不能只靠一个单机进程。ax 要填的就是这个“从单机 Agent 到集群化 Agent”之间的鸿沟。这篇文章适合谁看如果你已经在用 K8s 跑服务并且开始尝试把 Agent 塞进集群里那这篇就是写给你的。如果你还在单机跑 Agent也可以先了解这套思路因为迟早要面对。我会从设计思路、核心细节、实操落地、问题排查四个层面拆开讲尽量把“为什么这么设计”讲透而不是只丢一堆 YAML。2. 内容整体设计与思路拆解2.1 为什么 Agent 编排不能直接套用传统 K8s 模型传统 K8s 的编排假设是工作负载是被动的。你创建一个 Deployment它启动 PodPod 执行你预设的命令跑完就结束或者一直监听。整个生命周期是确定的、可预测的。但 Agent 不一样Agent 是主动的它会根据上下文决定下一步调用哪个工具、要不要委托给另一个 Agent、要不要等待人类输入。这种不确定性让传统编排模型直接失效。我举个具体例子。假设你有一个“客服 Agent”和一个“退款 Agent”。用户发起退款请求客服 Agent 判断需要转交于是调用退款 Agent。在传统 K8s 里这两个 Agent 可能是两个 Deployment但它们之间的调用关系、状态传递、超时处理K8s 本身完全不管。你得自己写一层消息队列或者服务网格。而 ax 这类运行时编排层的价值就是把这层“Agent 间协作”变成编排原语。所以第一个设计决策就是ax 必须在 K8s 之上增加一个 Agent 感知的控制面。这个控制面要理解 Agent 的语义——比如“这个 Agent 正在等待工具返回”“那个 Agent 已经完成了子任务”。它不能只盯着 CPU 和内存还要盯着 Agent 的状态机。2.2 运行时抽象把 Agent 当成“有状态的、可中断的、可迁移的计算单元”ax 的第二个核心设计是运行时抽象。传统容器运行时比如 containerd、CRI-O管的是进程。ax 要管的是 Agent 实例。一个 Agent 实例包含什么至少包括当前对话上下文、已加载的工具列表、正在执行的任务栈、以及与其他 Agent 的会话状态。这就引出一个关键取舍Agent 的状态放在哪里。如果放在 Agent 进程内存里那 Pod 一重启状态就丢了Agent 得从头开始。如果放在外部存储比如 Redis 或 etcd那每次状态读写都有网络开销但换来的是可迁移、可恢复。ax 的选择通常是后者但会做分层热状态放本地内存缓存冷状态定期持久化。我实测下来这个分层策略很关键。纯内存方案在 Agent 频繁调用工具时延迟最低但一旦节点故障恢复成本极高。纯外部存储方案虽然稳但每次工具调用都要等一次网络往返Agent 的响应速度会明显下降。ax 的做法是状态变更先写本地 WAL预写日志再异步同步到外部存储。这样即使节点挂了也能从 WAL 恢复最近的状态。2.3 编排原语从 Pod 到 AgentGroupK8s 的编排原语是 Pod、Deployment、Service。ax 需要引入新的原语。我见过的比较合理的设计是AgentGroup和AgentSession。AgentGroup 类似于 Deployment它描述“我要运行哪几类 Agent每类几个副本它们之间允许怎么通信”。AgentSession 类似于一个临时的、有生命周期的会话单元它描述“这一次具体的任务由哪些 Agent 参与状态存在哪里超时多久”。为什么需要 AgentSession因为 Agent 的任务往往是有始有终的。用户问一个问题几个 Agent 协作回答完这个会话就结束了。如果用 Deployment 来管你得手动创建和销毁很麻烦。AgentSession 让编排层自动管理生命周期任务开始创建任务结束回收。这个设计背后的逻辑是Agent 编排的粒度比服务编排更细但生命周期更短。你不能用管长期服务的方式管短任务。这也是为什么 ax 这类方案通常会和 Knative 或者 KEDA 这类事件驱动扩缩容方案结合使用。2.4 与 Kubernetes 的边界哪些交给 K8s哪些 ax 自己管这是实操中最容易混淆的地方。我的经验是划一条清晰的线职责交给 Kubernetes交给 ax 运行时节点管理是否容器调度是否网络基础是否Agent 生命周期否是Agent 间路由否是工具调用代理否是状态持久化部分PV是逻辑层扩缩容决策部分HPA是Agent 感知这条线划清楚之后实现就不会乱。ax 不重复造 K8s 的轮子它只做 K8s 做不了的那部分。这也是为什么 ax 通常以 Operator 的形式部署在 K8s 里而不是另起炉灶。3. 核心细节解析与实操要点3.1 Agent 运行时容器的镜像设计ax 管理的 Agent 最终还是要跑在容器里。这个容器镜像怎么设计直接决定了后续的灵活性和启动速度。我踩过的坑是一开始把 Agent 代码、工具依赖、模型客户端全打在一个大镜像里结果镜像 3GB每次扩缩容拉镜像要几分钟完全没法用。后来改成分层镜像基础层Python/Node 运行时 ax SDK约 200MB工具层常用工具客户端HTTP、数据库、文件操作约 300MBAgent 层具体 Agent 逻辑代码通常小于 50MB这样扩缩容时只需要拉 Agent 层基础层和工具层节点上已经有缓存。实测启动时间从 3 分钟降到 15 秒以内。注意工具层不要把所有可能的工具都打进去。按 AgentGroup 的实际需求裁剪否则镜像又会膨胀。我见过有人把整个 LangChain 生态都装进去镜像直接 5GB这是反面教材。3.2 状态存储的选型与参数计算ax 的状态存储通常用 Redis 集群或者 etcd。选哪个我的判断标准是如果 Agent 状态更新频繁每秒多次选 Redis因为写入延迟低如果状态需要强一致比如涉及资金、权限选 etcd因为 Raft 保证线性一致如果状态量大单 Agent 超过 10MB考虑对象存储 本地缓存参数计算方面假设你有 100 个 Agent 实例每个实例平均状态 500KB每秒更新 2 次。那么总状态量100 × 500KB 50MB每秒写入100 × 2 200 次峰值写入200 × 3 600 次/秒按 3 倍峰值系数Redis 单节点轻松扛住 600 次/秒写入所以单节点加哨兵就够。但如果 Agent 数量到 1000写入到 6000 次/秒就得上 Redis Cluster 分片。提示状态存储的容量规划要留 3 倍余量因为 Agent 状态会随着对话轮次增长。我见过一个客服 Agent 跑了 8 小时后状态膨胀到 20MB直接把 Redis 内存打满。3.3 Agent 间通信的路由机制ax 里 Agent 之间怎么找到对方有两种主流方案方案一基于 Service 的固定路由。每个 AgentGroup 对应一个 K8s ServiceAgent 通过 Service DNS 调用。优点是简单复用 K8s 网络。缺点是路由是静态的无法根据 Agent 状态做智能路由。方案二基于控制面的动态路由。ax 控制面维护一个 Agent 注册表记录每个 Agent 实例的能力、负载、状态。调用方先问控制面“谁可以处理这个任务”控制面返回目标地址。优点是灵活可以做负载均衡和故障转移。缺点是多一次控制面查询。我实测下来混合方案最实用常规调用走 Service需要智能路由时走控制面。具体做法是给 Agent 的调用客户端加一个开关默认走 Service当检测到目标 AgentGroup 有多个版本或者需要按能力路由时切换到控制面查询。3.4 工具调用的超时与重试策略Agent 调用工具是最容易出问题的环节。工具可能是外部 API可能超时可能返回错误。ax 运行时必须有一套统一的超时和重试策略否则每个 Agent 自己实现行为不一致。我的配置经验默认超时30 秒。超过 30 秒的工具调用大概率是外部服务有问题继续等没意义。重试次数2 次。加上首次共 3 次尝试。重试间隔指数退避1 秒、2 秒、4 秒。幂等性检查只对幂等工具重试。非幂等工具比如“创建订单”重试前必须确认上次是否成功。注意Agent 的工具调用重试和传统服务重试有个关键区别——Agent 可能会在重试期间改变决策。比如第一次调用超时Agent 可能决定换个工具。所以 ax 的重试策略要支持“重试前回调 Agent 决策逻辑”而不是无脑重试。4. 实操过程与核心环节实现4.1 环境准备K8s 集群与 ax 控制面部署假设你已经有一个 K8s 集群版本 1.26 以上。先确认容器运行时正常kubectl get nodes -o wide kubectl describe node node-name | grep -i runtime如果看到container runtime is not running这类报错先解决运行时问题。常见原因是 containerd 服务没起来或者 CRI 配置不对。然后部署 ax 控制面。ax 通常以 Operator 形式发布包含 CRD 和控制器kubectl apply -f https://example.com/ax-operator/crd.yaml kubectl apply -f https://example.com/ax-operator/operator.yaml部署完成后检查kubectl get pods -n ax-system kubectl get crd | grep ax你应该看到agentgroups.ax.io和agentsessions.ax.io这两个 CRD。4.2 定义第一个 AgentGroupAgentGroup 的 YAML 大概长这样apiVersion: ax.io/v1alpha1 kind: AgentGroup metadata: name: customer-service spec: replicas: 3 agentImage: registry.example.com/agents/customer-service:v1.2.0 tools: - name: order-query endpoint: http://order-service:8080/query timeout: 10s - name: refund-create endpoint: http://refund-service:8080/create timeout: 30s idempotent: false stateStore: type: redis endpoint: redis://redis-cluster:6379 ttl: 24h resources: requests: cpu: 500m memory: 512Mi limits: cpu: 2000m memory: 2Gi这里有几个参数值得展开replicas: 3三个副本但注意 Agent 副本不是无状态的。每个副本处理不同的会话所以不能用传统 Round Robin 负载均衡。ax 控制面会根据会话 ID 做一致性哈希路由。idempotent: false退款创建不是幂等的所以 ax 不会自动重试而是把失败交给 Agent 决策。ttl: 24h会话状态保留 24 小时之后自动清理。这个值要根据业务定太长浪费存储太短用户体验差。4.3 创建 AgentSession 并观察调度AgentGroup 定义好后创建一个会话apiVersion: ax.io/v1alpha1 kind: AgentSession metadata: name: session-20250101-001 spec: agentGroup: customer-service input: userQuery: 我要退订单 12345 timeout: 5m maxTurns: 10创建后观察kubectl get agentsessions kubectl describe agentsession session-20250101-001你会看到 ax 控制面把会话分配给了某个 Agent 副本并记录了当前轮次和状态。如果 Agent 调用了工具describe 输出里会显示工具调用记录。4.4 扩缩容从 3 个副本到 10 个副本当会话量增加时手动或自动扩缩容kubectl scale agentgroup customer-service --replicas10但 Agent 的扩缩容比普通服务复杂。新副本启动后需要从状态存储加载会话状态。如果状态存储是 Redis新副本会订阅会话迁移事件接管分配给它的会话。我实测下来从 3 扩到 10新副本完全就绪大约需要 20 秒。其中 15 秒是镜像拉取如果节点有缓存则更快5 秒是状态加载。所以扩缩容的冷却时间建议设 30 秒以上避免频繁抖动。4.5 故障恢复模拟 Agent 副本崩溃手动删掉一个 Agent Podkubectl delete pod customer-service-abc123观察 ax 控制面的行为控制面检测到副本丢失该副本负责的会话被标记为“待迁移”其他副本或新副本接管这些会话会话从状态存储恢复继续执行整个过程我实测大约 10 到 15 秒。期间用户会感觉到一次短暂停顿但不会丢失上下文。这就是状态外置的价值。提示如果你的 Agent 有本地缓存且没有及时同步到状态存储故障恢复后会丢失最近几秒的状态。所以 WAL 的刷盘频率很关键。我建议至少每秒刷一次对性能影响很小但能大幅减少状态丢失。5. 常见问题与排查技巧实录5.1 Agent 启动后一直处于 Pending 状态这是最常见的问题。排查顺序检查资源是否足够kubectl describe pod pod-name看 Events 里有没有Insufficient cpu/memory检查镜像是否能拉取看 Events 里有没有ImagePullBackOff检查状态存储是否可达Agent 启动时会连 Redis如果连不上会一直重试我遇到过一次Agent 镜像里配的 Redis 地址是localhost:6379但容器里 localhost 指向自己当然连不上。改成 Service DNS 就好了。5.2 工具调用超时但外部服务正常这种情况通常是网络策略或者 DNS 解析问题。排查kubectl exec -it agent-pod -- nslookup order-service kubectl exec -it agent-pod -- curl -v http://order-service:8080/query如果 DNS 解析慢检查 CoreDNS 配置。如果 curl 能通但 Agent 调用超时检查 Agent 的工具客户端配置可能是超时设太短。5.3 会话状态膨胀导致 Redis 内存告警前面提过Agent 状态会随对话轮次增长。解决办法设置状态 TTL过期自动清理对历史对话做摘要压缩只保留最近 N 轮完整上下文把冷状态移到对象存储Redis 只存热状态我一般会在 Agent 逻辑里加一个检查当状态超过 1MB 时触发摘要压缩。压缩后状态通常能降到 100KB 以内。5.4 扩缩容后会话分配不均ax 控制面默认用一致性哈希分配会话。如果某些副本负载明显偏高可能是哈希环倾斜。解决办法增加虚拟节点数让哈希更均匀或者改用基于负载的动态分配控制面定期重新平衡我实测下来虚拟节点数设为副本数的 100 倍时分布已经足够均匀。5.5 常见问题速查表现象可能原因排查命令解决方向Pod Pending资源不足kubectl describe pod扩容节点或降低 requests镜像拉取失败镜像地址错或网络不通kubectl describe pod检查镜像仓库和网络策略工具调用超时DNS 或网络策略kubectl exec里 curl 测试修 DNS 或网络策略状态丢失WAL 未刷盘检查 Agent 日志提高刷盘频率会话分配不均哈希环倾斜看各副本会话数增加虚拟节点扩缩容抖动冷却时间太短看 HPA 事件增加冷却时间6. 我在这套方案里踩过的坑和总结的经验第一个坑是低估了状态同步的开销。一开始我觉得 Agent 状态不大直接每次变更都写 Redis 就行。结果在高频工具调用场景下Redis 的 QPS 直接打满。后来改成批量写加本地缓存QPS 降了 80%。第二个坑是把 Agent 当无状态服务做负载均衡。传统 K8s Service 是 Round Robin但 Agent 会话必须粘性。我一开始没做会话粘性结果同一个用户的两轮对话被分到不同 Agent上下文全丢了。后来在 Service 前面加了一层基于会话 ID 的路由才解决。第三个坑是工具重试没有考虑 Agent 决策。有次退款工具超时ax 自动重试了两次结果创建了三笔退款。后来把非幂等工具的重试关掉交给 Agent 判断才避免重复操作。这套方案后续还可以扩展的方向把 Agent 的决策过程也纳入可观测性比如记录每个 Agent 每轮的工具选择理由这样排查问题时能看到“为什么这个 Agent 选了 A 工具而不是 B”。另外多集群场景下ax 控制面可以和 Karmada 这类多集群编排结合把 Agent 调度到不同集群实现跨集群的 Agent 协作。
