1. 从“ax”这个标题说起一个被低估的运行时编排命题第一次看到“ax”这个标题很多人会一头雾水。它不像“Kubernetes 集群搭建”那样直白也不像“Agentic RAG 实战”那样自带场景。但把热搜词摊开来看线索就非常清楚了ax、agentic、orchestration、runtime、Kubernetes这五个词放在一起指向的是一个非常具体的工程命题——在 Kubernetes 之上构建一套面向 agentic 应用的运行时编排层。我先把结论摆在前面“ax”在这里不是一个产品名而是一个抽象代号代表“agent execution”这条链路的最小闭环。它要解决的问题是当你的系统里不再只有无状态的 HTTP 服务而是有一堆会自己规划、自己调工具、自己维护中间状态的 agent 时Kubernetes 原生的 Deployment、Service、Job 这套模型就不够用了。你需要一层新的 runtime来管住这些“会思考的进程”。为什么这么说因为传统微服务的假设是请求进来、处理、返回、进程状态可以丢弃。但 agent 不是这样。一个 agent 在执行任务时可能先调用检索、再调用代码解释器、再等待人工确认、再继续下一步。它的生命周期是长时的、有状态的、可中断可恢复的。Kubernetes 的 Pod 重启策略、探针机制、调度模型都是为短生命周期或无状态负载设计的。直接拿 Deployment 跑 agent你会遇到一堆问题Pod 被驱逐后上下文丢了、扩缩容时任务被重复执行、长任务被 liveness probe 误杀。所以“ax”这个标题背后真正要拆的是三层东西agentic 应用的运行时特征、orchestration 的编排模型、以及 Kubernetes 作为底座如何被改造。这三层缺一不可。只谈 agent 不谈 runtime是空中楼阁只谈 Kubernetes 不谈 agent 语义是拿锤子找钉子。这篇文章适合谁看如果你正在做 AI 应用平台、正在把 agent 从 demo 推向生产、或者你是一个 Kubernetes 运维正在被业务方问“能不能跑 agent”那这篇内容就是写给你的。我会从设计思路讲到实操细节再到踩坑记录尽量把这条链路讲透。2. 为什么 agentic 应用需要一层独立的 runtime2.1 传统容器编排模型和 agent 生命周期的根本冲突要理解为什么需要“ax”这样一层 runtime得先看清楚冲突在哪。Kubernetes 的核心抽象是Pod而 Pod 的设计哲学是“可替换的、无状态的、随时可以杀掉的”。它的健康检查分两种liveness probe 判断进程是否活着readiness probe 判断是否能接流量。这套机制对 Web 服务非常合适但对 agent 来说就是灾难。举个例子。你有一个 agent 正在执行一个多步任务第一步检索文档花了 30 秒第二步调用外部 API 花了 2 分钟第三步在等一个异步回调。这时候 liveness probe 如果配置的是 10 秒超时Pod 早就被重启了。你可能会说“那把 probe 调长一点不就行了”——但问题是agent 的任务时长是不确定的有的任务 5 秒有的任务 5 小时。你没法用一个静态阈值去覆盖所有情况。更麻烦的是状态。Agent 在执行过程中会积累上下文对话历史、工具调用结果、中间推理链。这些状态如果只存在进程内存里Pod 一重启就全没了。你可能会想到用 emptyDir 或者 PVC 挂载但 Kubernetes 的存储模型是按 Pod 绑定的Pod 漂移到另一个节点本地卷就跟不过去了。用网络存储可以解决漂移问题但延迟和并发写入又是新问题。所以核心矛盾是Kubernetes 假设负载是“无状态可替换”的而 agent 的本质是“有状态不可随意替换”。这个矛盾不是调参能解决的必须在编排层引入新的抽象。2.2 Agent 运行时的四个核心能力要求基于上面的冲突一个合格的 agent runtime 至少要具备四个能力。我把它们列出来后面讲“ax”的设计时会一一对应。第一是会话亲和性。同一个 agent 会话的多次调用必须路由到同一个执行实例否则上下文就断了。这类似于有状态服务的 sticky session但粒度更细因为一个 agent 可能同时服务多个会话。第二是检查点与恢复。Agent 执行到一半挂了恢复后要能从最近的检查点继续而不是从头再来。这要求 runtime 能定期把 agent 状态持久化并且在调度新实例时能加载回来。第三是长时任务的生命周期管理。任务可能跑几分钟到几小时runtime 要能区分“进程活着但任务卡住”和“进程真的挂了”不能简单用超时判断。第四是工具调用的隔离与限流。Agent 会调用各种外部工具有的贵、有的慢、有的有速率限制。Runtime 要在编排层做统一的配额管理和熔断而不是让每个 agent 自己处理。把这四点想清楚你就明白为什么不能直接用 Kubernetes 原生对象跑 agent 了。你需要一层中间层把 agent 的语义翻译成 Kubernetes 能理解的调度指令同时把 Kubernetes 的故障恢复能力包装成 agent 能用的检查点机制。2.3 “ax”这层抽象到底放在哪里那“ax”这层 runtime 具体放在架构的哪个位置我的实践是把整个链路分成四层最底下是 Kubernetes 集群负责资源调度和容器生命周期往上是 ax runtime负责 agent 会话管理、检查点、工具代理再往上是 agent 框架层比如各种 agent 编排库最上面是业务逻辑。关键点在于ax runtime 不是替代 Kubernetes而是增强 Kubernetes。它通过 Custom Resource Definition 把 agent 定义成一种新的资源类型然后用自己的 controller 去 reconcile。这样你既能复用 Kubernetes 的调度、网络、存储能力又能给 agent 加上会话亲和、检查点这些语义。我试过两种做法。一种是完全在应用层做agent 框架自己管状态Kubernetes 只当容器跑。这种做法上手快但一旦要扩缩容或者做故障转移就得自己造轮子最后代码里全是状态同步逻辑。另一种就是引入 ax runtime 这层把状态管理下沉到编排层。前期投入大一些但后面加功能、做运维会轻松很多。实测下来第二种在超过 20 个 agent 实例的场景下优势非常明显。3. 核心细节拆解ax runtime 的关键设计点3.1 会话模型怎么把“一次对话”映射成可调度的单元设计 ax runtime 的第一个决策是会话和 Pod 的映射关系是什么。有三种常见方案我逐一分析。方案一是一会话一 Pod。每个 agent 会话独占一个 Pod会话结束 Pod 销毁。优点是隔离性好状态简单缺点是资源利用率低会话多了 Pod 数量爆炸冷启动延迟也高。方案二是一 Pod 多会话。一个 Pod 里跑多个会话通过内部路由分发。优点是资源省缺点是隔离性差一个会话把内存吃满会影响其他会话而且故障恢复粒度太粗。方案三是会话组 弹性池。把会话按租户或优先级分组每组对应一个 Pod 池会话在池内调度。这是我在生产环境用得最多的方案。它平衡了隔离性和利用率而且池的扩缩容可以独立于会话生命周期。具体怎么选我的经验是看会话的状态大小和隔离要求。如果每个会话状态就几十 KB方案二完全够用如果状态上 MB 甚至 GB方案一或方案三更合适。另外还要看合规要求如果不同租户的数据不能混跑那方案一是唯一选择。在 ax runtime 里我用一个叫AgentSession的 CRD 来描述会话字段包括会话 ID、租户、状态快照引用、亲和性标签。Controller 监听这个 CRD根据标签把会话调度到合适的 Pod 池。这里的关键是亲和性标签的设计它决定了调度的灵活度。我一般会打三类标签租户标签、优先级标签、状态大小标签。3.2 检查点机制状态持久化的时机与粒度检查点是 agent runtime 最核心也最容易做错的部分。做少了故障恢复丢状态做多了性能开销大。我的原则是在状态变更的边界做检查点而不是按时间做。什么叫状态变更边界就是 agent 完成一个原子步骤的时候。比如检索完成、工具调用返回、推理链生成完毕。这些点之后状态是自洽的可以安全持久化。如果在一个步骤中间做检查点恢复时可能拿到半截状态反而更麻烦。持久化到哪里我试过三种对象存储、关系数据库、分布式 KV。对象存储便宜但延迟高适合大状态关系数据库查询方便但写入有瓶颈分布式 KV 延迟低但运维复杂。最后我的方案是分层存储热状态放 KV冷状态归档到对象存储元数据放关系库。这样恢复时先读 KV读不到再回源对象存储。检查点的粒度也要控制。我一般把单个检查点的大小限制在 1 MB 以内超过就拆分。因为太大的检查点会导致恢复时间过长而且网络传输容易失败。如果 agent 状态确实很大就只持久化增量全量快照定期做一次。注意检查点写入必须是幂等的。因为网络重试可能导致重复写入如果写入逻辑不幂等恢复时状态就乱了。我的做法是给每个检查点带一个单调递增的版本号写入时比较版本号旧的直接丢弃。3.3 工具调用的代理与限流把外部依赖管起来Agent 调工具这件事看起来简单实际上坑很多。工具可能超时、可能限流、可能返回格式不对。如果让每个 agent 自己处理这些代码会非常臃肿。所以 ax runtime 里我加了一层工具代理。工具代理的职责有三个统一鉴权、统一限流、统一重试。Agent 不直接调外部 API而是调代理代理再去调真实工具。这样做的好处是凭证不用下发到每个 agent 实例限流策略可以集中配置重试逻辑只写一遍。限流这块我重点说一下。Agent 调工具的频率是不均匀的可能突然爆发。如果直接用令牌桶突发流量会被削掉agent 任务就卡住了。我的做法是两级限流第一级是粗粒度的并发限制控制同时进行的工具调用数第二级是细粒度的速率限制控制单位时间的调用次数。两级配合既能扛突发又不会打爆下游。重试策略也要小心。不是所有错误都能重试。网络超时可以重试但参数错误重试多少次都没用。我的分类是5xx 和超时重试4xx 不重试限流错误按 Retry-After 头重试。重试次数我一般设 3 次指数退避基数 500ms。3.4 和 Kubernetes 原生对象的边界划分引入 ax runtime 后一个必须回答的问题是哪些事交给 Kubernetes哪些事自己管。我的划分原则是资源层面的事交给 Kubernetes语义层面的事自己管。具体来说Pod 的创建销毁、节点调度、网络配置、存储挂载这些都用 Kubernetes 原生能力。而会话路由、检查点、工具代理、agent 生命周期状态机这些由 ax runtime 的 controller 管理。这个边界很重要划错了会导致重复造轮子或者职责不清。我见过有的团队自己实现了一套容器调度结果稳定性远不如 Kubernetes纯属浪费。也见过有的团队把所有逻辑都塞进 Pod 的 entrypoint 脚本结果运维完全没法介入。在实现上ax runtime 通过Operator 模式和 Kubernetes 交互。它监听自定义资源的变化然后创建或更新 Deployment、Service、ConfigMap 这些原生对象。Agent 的状态机存在 CRD 的 status 字段里通过 watch 机制驱动。4. 实操过程从零搭一个最小可用的 ax runtime4.1 环境准备与基础组件选型动手之前先把环境理清楚。我假设你已经有一个能用的 Kubernetes 集群版本 1.26 以上。为什么强调 1.26因为从 1.24 开始 Dockershim 被移除容器运行时接口有变化一些老的 runtime 配置需要调整。如果你还在用更老的版本建议先升级否则后面会遇到容器运行时相关的报错。基础组件我选这几个controller-runtime作为 Operator 框架etcd或Redis作为热状态存储S3 兼容对象存储作为冷状态归档Prometheus做指标采集。这些都是成熟组件社区资料多出问题好查。Controller-runtime 的好处是它把 informer、workqueue、reconcile 这些模式都封装好了你只需要写业务逻辑。相比自己用 client-go 裸写开发效率高很多。我用的是 v0.16 版本对应 Kubernetes 1.28 的 API。状态存储的选择上如果你集群里已经有 Redis直接用就行。没有的话etcd 也可以但要注意 etcd 的写入性能有限检查点频率高的话会成为瓶颈。对象存储我用的 MinIO本地部署方便S3 接口兼容。4.2 定义 AgentSession 这个 CRD第一步是定义 CRD。我把字段设计成这样apiVersion: ax.example.com/v1alpha1 kind: AgentSession metadata: name: session-abc123 spec: tenant: team-a priority: high stateSize: medium checkpointInterval: 30s tools: - name: search rateLimit: 10/s - name: code-interpreter rateLimit: 2/s status: phase: Running podName: ax-pool-team-a-0 lastCheckpoint: 2026-09-22T09:40:00Z checkpointVersion: 42这里每个字段都有用意。tenant和priority用于调度亲和性stateSize决定调度到哪个池checkpointInterval是检查点间隔tools声明这个会话需要哪些工具以及限流配置。status里的phase是状态机podName记录当前绑定的 PodcheckpointVersion用于幂等写入。CRD 定义好之后用 controller-gen 生成 deepcopy 和 client 代码。这一步别偷懒手写容易出错。生成命令是controller-gen object:headerFilehack/boilerplate.go.txt paths./... controller-gen crd:trivialVersionstrue paths./... output:crd:artifacts:configconfig/crd/bases4.3 Controller 的 reconcile 逻辑怎么写Reconcile 是整个 runtime 的大脑。它的输入是一个 AgentSession 对象输出是“让实际状态向期望状态靠拢”的一系列操作。我把它拆成几个阶段。第一阶段是校验。检查 spec 是否合法比如 tenant 是否存在、工具是否注册过、限流配置是否合理。不合法就直接把 phase 设成 Failed写个 event 说明原因。第二阶段是调度。根据 tenant、priority、stateSize 找到合适的 Pod 池。如果池不存在或者容量不够就触发扩容。扩容逻辑我放在一个单独的 scaler 组件里controller 只发信号。第三阶段是绑定。把会话绑定到具体 Pod更新 status.podName。绑定要考虑负载均衡不能全压到一个 Pod 上。我用的是加权轮询权重是 Pod 的剩余容量。第四阶段是检查点管理。根据 checkpointInterval 触发检查点更新 checkpointVersion。这里要注意检查点是异步的controller 不能阻塞等它完成。第五阶段是故障处理。如果发现 Pod 挂了就把会话重新调度到新 Pod并从最近的检查点恢复。恢复逻辑要处理检查点不存在的情况这时候只能从头开始但要记录事件方便排查。Reconcile 函数必须是幂等的因为 controller-runtime 会重试。我见过有人在这里写了非幂等的逻辑结果重试时创建了重复资源。判断幂等的方法很简单同样的输入执行两次结果应该一样。4.4 工具代理的实现与限流参数计算工具代理我实现成一个独立的 Deployment前面挂一个 Service。Agent 通过环境变量拿到代理地址所有工具调用都走它。限流参数怎么算假设下游工具能承受 100 QPS你有 50 个 agent 实例每个实例平均每秒调 0.5 次峰值 3 次。那总峰值是 150 QPS超过下游能力。这时候要么加下游容量要么限流。我的计算方法是先算总峰值再留 20% 余量反推每个实例的限流值。上面这个例子下游 100 QPS留 20% 余量就是 80 QPS 可用。50 个实例每个实例限 1.6 QPS取整 1 QPS。这样即使所有实例同时打峰值也不会超过下游能力。令牌桶的参数桶容量设为限流值的 2 倍允许短时突发填充速率就是限流值。比如限 1 QPS桶容量 2填充速率 1/s。这样平时攒的令牌能扛住 2 次突发。代理的重试逻辑我用的是指数退避初始 500ms倍数 2最大 8s最多 3 次。超过就返回错误给 agent让 agent 自己决定怎么办。4.5 部署与验证跑通第一个 agent 会话所有组件写完部署顺序是先装 CRD再部署 controller再部署工具代理最后部署 agent 池。kubectl apply -f config/crd/bases/ kubectl apply -f config/controller/ kubectl apply -f config/tool-proxy/ kubectl apply -f config/agent-pool/验证的时候先创建一个测试会话kubectl apply -f - EOF apiVersion: ax.example.com/v1alpha1 kind: AgentSession metadata: name: test-session spec: tenant: default priority: low stateSize: small checkpointInterval: 10s tools: - name: echo rateLimit: 1/s EOF然后看 statuskubectl get agentsession test-session -o yaml正常的话phase 会从 Pending 变成 RunningpodName 会有值。再去看 Pod 日志应该能看到 agent 启动并开始执行。验证检查点等 10 秒以上看 status.lastCheckpoint 是否更新checkpointVersion 是否递增。然后手动删掉 Pod观察会话是否自动恢复恢复后状态是否连续。验证限流写个脚本快速调工具代理超过限流值后应该收到 429。等一会儿再调应该恢复正常。5. 常见问题与排查技巧实录5.1 会话恢复后状态错乱怎么办这是最常见的问题。表现是Pod 挂了之后重新调度agent 恢复后行为异常比如重复执行已经完成的步骤或者丢失了部分上下文。排查思路分三步。第一步确认检查点是否完整。去看存储里的检查点内容对比 agent 实际状态看差在哪。第二步确认恢复逻辑是否正确加载了检查点。有时候是加载了但没应用比如版本号对不上被丢弃了。第三步确认检查点写入是否幂等。如果写入不幂等可能存了错误的状态。我踩过的一个坑是检查点写入用了异步但没等写入完成就更新了 checkpointVersion。结果 Pod 挂了之后恢复时读到的版本号是新的但实际数据还是旧的。修复方法是写入和版本号更新放在一个事务里要么都成功要么都失败。另一个坑是状态序列化用了 JSON但 agent 状态里有循环引用序列化时静默失败了。这种问题很隐蔽因为不报错。后来我加了序列化后的校验反序列化一遍确认能还原才解决。5.2 工具代理成为瓶颈怎么优化工具代理集中式部署很容易成为单点瓶颈。表现是 agent 调工具延迟高代理的 CPU 或网络打满。优化方向有几个。第一是水平扩容代理多副本加负载均衡。但要注意限流是全局的多副本之间要共享限流状态否则每个副本各限各的总量就超了。我用 Redis 存令牌桶状态所有副本共享。第二是连接池优化。代理到下游工具的连接要复用不能每次调用都新建。HTTP 客户端要配置 keep-alive连接池大小根据并发量调。第三是异步化。如果工具调用本身耗时长代理可以改成异步模式agent 提交任务后拿一个 task ID轮询结果。这样代理的线程不会被长时间占用。我实测下来单副本代理大概能扛 500 QPS超过就要扩容。扩容时注意 Redis 的写入压力令牌桶操作很频繁Redis 可能成为新瓶颈。这时候可以用本地缓存加定期同步牺牲一点精度换性能。5.3 Pod 驱逐导致任务中断的预防Kubernetes 会因为资源压力、节点维护等原因驱逐 Pod。对 agent 来说驱逐意味着任务中断。虽然检查点能恢复但恢复有成本频繁驱逐体验很差。预防措施有几个。第一是设置 PodDisruptionBudget保证自愿驱逐时至少有 N 个副本可用。第二是配置优先级和抢占高优先级的 agent 池设置高 priorityClass资源紧张时优先保留。第三是用 descheduler 的反向逻辑主动把 agent Pod 分散到不同节点避免单节点故障影响太多会话。还有一个技巧是优雅终止。Pod 收到 SIGTERM 后不要立即退出而是先做一个检查点再退出。这样恢复时能从最新状态开始。优雅终止的宽限期要设够我一般设 60 秒给检查点留时间。注意优雅终止逻辑要处理超时。如果检查点写入卡住不能无限等要有兜底。我的做法是设一个 30 秒的超时超时就放弃检查点直接退出恢复时用上一个检查点。5.4 常见问题速查表问题现象可能原因排查方法解决方案会话一直 Pending没有可用 Pod 池看 controller 日志和池状态检查池配置触发扩容恢复后状态错乱检查点不完整或版本号错对比存储和实际状态修复写入幂等性加事务工具调用 429限流触发看代理指标调大限流值或扩容下游Pod 频繁重启liveness probe 太严看 Pod 事件放宽 probe 或改用自定义健康检查检查点写入慢存储性能不足看存储指标换存储或减小检查点粒度调度不均衡亲和性标签设计问题看各池负载调整标签和权重算法5.5 几个我踩过的坑和独家技巧第一个坑是CRD 的 status 子资源没开。默认情况下更新 CRD 的 status 会触发 spec 的更新导致 reconcile 循环。必须开启 status 子资源让 status 更新走独立通道。开启方法是在 CRD 定义里加subresources: status: {}。第二个坑是controller 的并发度设置。默认并发是 1会话多了处理不过来。但调太高又会导致资源竞争。我的经验值是并发度设为 CPU 核数的 2 倍再根据实际负载微调。第三个技巧是给检查点加压缩。Agent 状态里有很多重复的文本压缩后能省 70% 以上的空间。我用的是 zstd压缩比和速度平衡得不错。压缩后再存恢复时解压对 agent 透明。第四个技巧是用 finalizer 做清理。会话删除时要清理检查点、释放工具配额、通知下游。这些逻辑放在 finalizer 里保证删除前一定执行。但要注意 finalizer 逻辑不能阻塞太久否则删除会卡住。第五个技巧是指标要打标签。Prometheus 指标如果不打标签排查问题时没法区分是哪个租户、哪个池的问题。我给所有指标都加了 tenant、pool、tool 三个标签排查效率提升很多。6. 从能跑到好用ax runtime 的进阶优化方向6.1 冷启动优化让 agent 秒级就绪Agent 冷启动慢是个普遍问题。慢的原因通常是镜像大、依赖多、初始化逻辑重。优化方向有几个。镜像层面用多阶段构建把编译工具链和运行时分开。基础镜像选 distroless 或 alpine能小很多。我见过一个 agent 镜像从 2GB 压到 200MB启动时间从 30 秒降到 5 秒。初始化层面把能预加载的都预加载。比如模型权重、工具 schema、配置都可以在镜像构建时打包进去启动时直接读。如果这些内容会变就用 init container 提前拉取主容器启动时直接用。还有一个技巧是预热池。保持一定数量的空闲 Pod有新会话时直接绑定不用等启动。预热池的大小根据流量波动调高峰期大一些低谷期小一些。这样冷启动对用户基本无感。6.2 多租户隔离资源、状态、网络三层防护多租户场景下隔离是刚需。我分三层做。资源层用ResourceQuota和LimitRange限制每个租户的 CPU、内存、Pod 数量。这样即使某个租户的 agent 失控也不会影响其他人。状态层用命名空间隔离。每个租户的检查点存在独立的命名空间或前缀下访问凭证也隔离。这样租户 A 的 agent 不可能读到租户 B 的状态。网络层用NetworkPolicy限制 Pod 之间的通信。默认拒绝所有只放行必要的流量。工具代理的访问也要按租户做白名单防止越权调用。这三层做完基本能挡住大部分隔离问题。但要注意隔离是有成本的策略越严调度灵活性越低。要根据实际合规要求平衡。6.3 可观测性指标、日志、追踪一个都不能少Agent 系统出问题时排查比传统服务难因为链路长、状态多。可观测性必须做扎实。指标方面除了常规的 CPU、内存、QPS还要加 agent 特有的会话数、检查点成功率、恢复次数、工具调用延迟分布。这些指标能快速定位问题在哪个环节。日志方面要结构化带 trace ID。Agent 的一次任务可能跨多个 Pod、多个工具没有 trace ID 根本串不起来。我用 OpenTelemetry 做追踪每个会话一个 trace每个步骤一个 span。追踪方面重点是跨进程传播。Agent 调工具代理代理调下游这条链路要能串起来。做法是在请求头里带 traceparent每一跳都透传。6.4 成本控制怎么让 agent 跑得便宜Agent 跑起来后成本是个大问题。主要是三块计算资源、存储、外部工具调用。计算资源方面用弹性池低谷期缩容高峰期扩容。缩容时注意优雅终止别把正在跑的会话杀了。我用的是 KEDA 做弹性根据会话队列长度触发扩缩容。存储方面检查点要定期清理。老会话的检查点如果不再需要及时删掉。我设了一个保留策略活跃会话保留全部检查点结束会话保留最近 3 个超过 7 天的全删。外部工具调用方面缓存是王道。很多工具调用是重复的比如检索同样的关键词。在代理层加缓存命中直接返回能省不少钱。缓存 key 要设计好包含工具名、参数、租户避免串数据。7. 我对这套方案的一些个人体会写到这里ax runtime 这条链路基本讲完了。最后分享几个我在实际项目中的体会不算总结就是一些零散的经验。第一个体会是别一开始就追求完美。我最早做的时候想一次性把检查点、限流、多租户全做进去结果复杂度爆炸三个月没上线。后来砍到只做会话管理和检查点两周就跑通了然后再逐步加功能。迭代比一次性设计靠谱得多。第二个体会是Kubernetes 的能力要用足但别硬套。有些团队为了“云原生”把 agent 的所有逻辑都塞进 Operator结果 Operator 代码几万行维护不动。其实很多逻辑放在应用层更合适Operator 只管调度和状态同步就好。边界划清楚两边都轻松。第三个体会是测试要覆盖故障场景。正常流程的测试好写但 agent 系统的价值恰恰在故障恢复。我专门写了一套 chaos 测试随机杀 Pod、断网、限流验证恢复逻辑。这套测试帮我发现了不少隐藏 bug。第四个体会是文档和工具一样重要。Agent 系统涉及的角色多开发、运维、业务方都要用。没有清晰的文档沟通成本极高。我后来强制要求每个 CRD 字段、每个指标、每个错误码都有文档新人上手时间从两周降到两天。如果你也在做类似的事情我的建议是先跑通最小闭环再逐步加能力。别被“agentic”“orchestration”这些词吓到拆开看都是具体的工程问题一个个解决就好。