1. 项目概述从“ax”这个极简标题出发我们到底在谈什么刚看到“ax”这两个字母时我第一反应是——这不像一个完整项目名倒像某个系统缩写、命令别名或是内部代号。但结合热搜词里反复出现的agentic、orchestration、Kubernetes再叠加上近期社区高频讨论的Karmada正式毕业、Agentic Cloud底座、Agentic RAG等关键词我立刻意识到这不是拼写错误也不是随手打的占位符而是一个高度凝练的技术信号——它指向当前云原生与AI工程交汇处最前沿的实践范式以智能体Agent为单元、以编排Orchestration为骨架、以Kubernetes为运行基座的新型系统架构。“ax”正是Agentic eXecution或Agentic orchestration eXecution的极简代称类似“git”之于“global information tracker”短小却承载整套设计哲学。这种架构不是纸上谈兵。华为云联合社区推动的“Agentic Cloud坚实底座”仲景开源的Agentic框架Karmada从CNCF沙箱毕业成为正式项目全部指向同一个事实单体AI应用正在瓦解取而代之的是由多个可调度、可观察、可恢复的智能体组成的协作网络。这些智能体不是传统微服务——它们自带决策逻辑、状态记忆、工具调用能力能自主判断下一步该调用哪个API、查哪份知识库、生成何种中间结果而Kubernetes也不再只是容器调度器它正被深度改造为智能体生命周期管理平台Pod不再是静态进程容器而是Agent实例的运行时封装Service不再只做流量转发而是Agent间语义化通信的注册中心CustomResourceDefinitionCRD则成了定义Agent类型、能力契约、SLA策略的“智能体宪法”。所以“ax”项目本质是一套轻量级但生产就绪的Agentic Orchestration落地方案它不追求大而全的AI平台而是聚焦三个核心问题如何让Agent真正“跑在K8s上”而不是“跑在K8s旁边”如何用声明式方式定义Agent协作流程而非硬编码状态机如何复用K8s生态已有能力如HPA自动扩缩、Prometheus指标采集、Velero备份恢复避免重复造轮子。适合两类人一是正在将RAG、Tool Calling等AI能力产品化的工程师需要稳定、可观测、可运维的部署载体二是云平台团队希望在现有K8s集群上平滑演进AI基础设施而非另起一套调度体系。它不是替代LangChain或LlamaIndex而是给它们装上K8s的“底盘”和“变速箱”。2. 架构设计与核心思路拆解为什么必须用Kubernetes承载Agentic工作流2.1 传统AI服务部署的三大硬伤K8s恰好对症下药我做过不下二十个AI项目交付从早期用Flask裸跑模型到后来用FastAPIDocker Compose再到如今全面拥抱K8s。每次迁移都源于前一种方式在真实业务场景中暴露出的不可持续性。而Agentic系统把这些痛点放大到了极致状态漂移问题一个典型的Agentic RAG流程可能包含用户Query → 意图识别Agent → 多路检索Agent → 结果融合Agent → 格式化输出Agent。每个Agent都需要维护自己的上下文缓存、临时文件、会话ID。用Flask全局变量并发一上来就乱套用Redis集中存网络延迟叠加序列化开销端到端延迟翻倍。K8s的StatefulSet PVC提供了天然的、隔离的、可声明的状态存储能力——每个Agent Pod挂载专属PV状态随Pod生命周期绑定重启后自动恢复无需额外协调。弹性伸缩失灵传统AI服务按QPS扩容但Agentic系统负载是“脉冲式”的。比如一个客服Agent处理简单咨询可能100ms完成但遇到复杂多跳查询可能耗时3秒且占用大量GPU显存。按平均QPS扩缩要么资源浪费90%时间闲置要么雪崩高峰时OOM。K8s的HorizontalPodAutoscalerHPA支持自定义指标我们可以直接采集每个Agent Pod的agent_queue_length待处理任务数、gpu_memory_used_percentGPU显存占用率作为扩缩依据实现毫秒级响应——当某类检索Agent队列堆积超过5个立即触发扩容比基于CPU的粗粒度扩缩精准十倍。故障隔离失效在单体服务里一个Agent出错比如调用外部API超时未设重试整个请求链就卡死。用微服务拆分又面临服务发现、熔断、链路追踪的复杂配置。K8s的Pod天然就是故障隔离边界一个Agent Pod崩溃K8s自动拉起新Pod其他Agent完全无感配合Service Mesh如Istio还能实现细粒度的重试策略对HTTP 5xx重试3次对404不重试、超时控制检索Agent最长等待800ms否则降级返回空结果把容错逻辑从代码里剥离交给基础设施。提示不要把K8s当成“高级Docker Compose”。它的核心价值不是“能跑容器”而是提供了一套标准化的、可编程的、带状态管理的分布式系统抽象层。Agentic系统本质上就是一个分布式状态机K8s的API Server、etcd、Scheduler、Controller Manager恰好构成了这个状态机的“操作系统内核”。2.2 “ax”架构的三层分层设计从Agent定义到集群治理“ax”项目没有发明新概念而是把K8s原生能力与Agentic需求做了精准映射形成清晰的三层结构第一层Agent CRDCustom Resource Definition这是整个架构的基石。我们定义了一个名为Agent的CRD其Schema包含spec.type: Agent类型标识如retriever,llm_router,validator用于分类调度spec.image: 镜像地址必须包含标准入口点如/app/agent-entrypoint.shspec.resources: 显式声明所需资源requests.cpu: 500m,limits.nvidia.com/gpu: 1K8s Scheduler据此分配节点spec.lifecycle: 定义启动/停止钩子比如启动时自动注册到中央Agent Registry一个ConfigMap停止前优雅保存最后状态spec.metrics: 指定暴露的Prometheus指标路径如/metrics及关键标签agent_type,task_status。这样一个Agent的完整“数字身份”就通过YAML声明了运维只需kubectl apply -f agent-retriever.yaml即可上线无需登录服务器改配置。第二层Orchestration Engine编排引擎它不是独立服务而是K8s Controller的延伸。我们开发了一个名为AxController的Operator它监听Agent资源的创建/更新事件并执行动态Pod模板生成根据CRD中的spec.resources自动注入GPU设备插件、NVIDIA Container Toolkit等必需initContainer依赖拓扑构建解析Agent间的调用关系通过Annotation或独立的WorkflowCRD自动生成Service和NetworkPolicy确保retriever只能访问vector-dbService不能直连llm-api健康检查闭环定期调用每个Agent Pod的/healthz端点若连续3次失败触发Pod驱逐并记录事件到K8s Event供SRE快速定位。关键在于这个Controller不处理业务逻辑只做“基础设施翻译”把Agentic语义翻译成K8s原语。第三层Observability Stack可观测性栈Agentic系统的调试难点在于“黑盒链路”。我们复用K8s生态成熟组件MetricsPrometheus抓取每个Agent Pod的agent_task_duration_seconds_bucket直方图Grafana看板实时显示各类型Agent的P95延迟、错误率LogsFluentd收集Pod日志按agent_type和request_id打标Kibana中输入agent_typeretriever AND request_idreq-abc123即可追溯完整调用链TracesJaeger接入Agent SDK在每次调用外部服务如调用Elasticsearch时自动埋点生成跨Pod的分布式Trace清晰展示“一个用户Query如何触发5个Agent协同”。这套栈不是新增组件而是K8s集群已有的“标配”降低了学习成本。2.3 为什么不用Serverless或专用AI平台一次真实的选型复盘去年我们曾对比过三种方案K8s原生、Knative Serverless、以及某商业AI平台。最终选择K8s不是因为“更酷”而是基于三次压测的真实数据场景K8s原生ax方案Knative商业AI平台冷启动延迟平均280msWarm Pod复用1.2s容器冷启函数加载850ms平台代理层GPU资源利用率92%StatefulSet固定分配65%按需分配导致碎片78%平台抽象层开销故障恢复时间12sPod重建 readinessProbe通过3.8s但仅限HTTP触发异步任务不适用45s平台级故障转移运维复杂度中需懂K8s基础高需理解Knative事件驱动模型低但被厂商锁定最关键的是可调试性。Knative的Revision机制让版本回滚变得困难——你无法精确知道某个Revision对应的Agent代码版本商业平台则完全屏蔽底层出了问题只能提工单等回复。而K8s里kubectl get pods -o wide一眼看到Pod运行在哪个Nodekubectl logs -f实时查看日志kubectl exec -it进去调试工程师的掌控感是无可替代的。Agentic系统本就复杂基础设施绝不能成为新的黑盒。3. 核心细节解析与实操要点从零搭建一个可运行的“ax”环境3.1 环境准备K8s集群版本与必要插件的硬性要求“ax”项目对K8s版本有明确要求不是“越高越好”而是精准匹配。我们实测验证过v1.24到v1.27最终锁定v1.26.0作为基准线原因如下v1.26.0是最后一个支持Legacy Docker Runtime的版本虽然Docker已非默认Runtime但大量AI镜像尤其含CUDA的仍依赖Docker Buildx构建v1.26兼容性最好。升级到v1.27需全面切换到containerd涉及NVIDIA Container Toolkit重配风险陡增。CRD v1 API全面稳定v1.26中apiextensions.k8s.io/v1已GA而v1.24仍需beta版后者在某些云厂商托管集群中存在兼容性问题。HPA v2支持完善v1.26的HPA支持基于自定义指标如Prometheus的扩缩这是Agentic系统弹性核心v1.24的HPA v1仅支持CPU/Memory。安装步骤必须严格遵循官方kubeadm流程跳过任何“一键脚本”。我见过太多因跳过preflight check导致后续故障的案例# 1. 执行预检关键 sudo kubeadm init --kubernetes-versionv1.26.0 \ --pod-network-cidr10.244.0.0/16 \ --cri-socket/var/run/containerd/containerd.sock # 预检会校验 # - CPU核数 ≥2Agentic Agent常需多线程 # - 内存 ≥2GBetcdcontroller-manager内存敏感 # - swap是否关闭K8s强制要求否则init失败 # - 系统时间是否同步证书有效期依赖NTP注意[preflight] running pre-flight checks这行日志不是装饰是K8s安全底线。曾有个客户跳过此步在swap开启的机器上强行init集群运行一周后etcd因OOM频繁崩溃恢复耗时17小时。务必让它跑完所有检查项再继续。必要插件清单按安装顺序CNI网络插件Calico v3.25.0Agentic系统常需跨Node通信Calico的BGP模式比Flannel更稳定且支持NetworkPolicy精细控制Agent间访问Metrics Server v0.6.3HPA依赖它获取Pod CPU/Memory指标必须安装否则kubectl top pods报错NVIDIA Device Plugin v0.13.0GPU资源调度核心安装后kubectl get nodes -o wide应显示nvidia.com/gpu: 1等CapacityCert-Manager v1.12.0为Agent Service自动生成TLS证书避免HTTP明文通信风险。每个插件安装后必须验证其Ready状态# Calico验证 kubectl get pods -n kube-system | grep calico # 应看到 calico-node-xxx Running 1/1 0 5m # NVIDIA插件验证 kubectl get nodes -o wide | grep nvidia.com/gpu # 应显示类似master Ready none 10h v1.26.0 ... nvidia.com/gpu13.2 Agent CRD定义与YAML编写规范让Agent真正“活”在K8s里CRD不是简单的JSON Schema它是Agent与K8s对话的“语法”。我们定义的AgentCRD YAML如下精简关键字段# agent-crd.yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: agents.ax.example.com spec: group: ax.example.com versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: type: type: string enum: [retriever, llm_router, validator, formatter] # 强制枚举防拼写错误 image: type: string pattern: ^.*:.*$ # 必须含tag禁止latest resources: type: object properties: requests: type: object properties: cpu: type: string memory: type: string limits: type: object properties: nvidia.com/gpu: type: integer minimum: 0 maximum: 4 lifecycle: type: object properties: postStart: type: object properties: exec: type: object properties: command: type: array items: type: string preStop: type: object properties: exec: type: object properties: command: type: array items: type: string scope: Namespaced names: plural: agents singular: agent kind: Agent shortNames: - ag编写Agent实例YAML时有三个易错点必须规避Image Tag必须指定image: my-registry/retriever:v1.2.0禁用latest。Agentic系统对模型版本极其敏感latest会导致不同Pod运行不同代码调试地狱。Resources Limits必须设GPU上限limits.nvidia.com/gpu: 1否则K8s Scheduler可能将多个GPU Agent调度到同一卡引发CUDA context冲突。我们实测过两个limits.nvidia.com/gpu: 1的Pod在同一GPU上运行第二个Pod的nvidia-smi会显示No running processes found但实际显存已被占用。Liveness/Readiness Probe必须区分livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 60 # Agent启动需加载大模型预留时间 periodSeconds: 30 readinessProbe: httpGet: path: /readyz port: 8080 initialDelaySeconds: 10 # 就绪检查更快避免流量打入未初始化Podhealthz检查Agent进程是否存活readyz检查Agent是否完成模型加载、连接DB等就绪动作。混用会导致Pod反复重启。3.3 AxController Operator开发用Go编写你的第一个Agentic控制器Operator是“ax”的灵魂它让K8s理解Agentic语义。我们用Kubebuilder v3.11开发核心逻辑只有200行Go代码但每行都经过生产验证// controllers/agent_controller.go func (r *AgentReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) { var agent axv1.Agent if err : r.Get(ctx, req.NamespacedName, agent); err ! nil { return ctrl.Result{}, client.IgnoreNotFound(err) } // Step 1: 生成Pod Template pod : r.buildPodTemplate(agent) // Step 2: 创建Deployment非StatefulSet因Agent无强状态依赖 dep : r.buildDeployment(agent, pod) if err : r.Create(ctx, dep); err ! nil !apierrors.IsAlreadyExists(err) { return ctrl.Result{}, err } // Step 3: 创建Service名称固定为agent-{type} svc : r.buildService(agent) if err : r.Create(ctx, svc); err ! nil !apierrors.IsAlreadyExists(err) { return ctrl.Result{}, err } // Step 4: 注册到Central RegistryConfigMap registryCM : r.getRegistryConfigMap() registryCM.Data[fmt.Sprintf(agent-%s, agent.Spec.Type)] fmt.Sprintf(%s.%s.svc.cluster.local:%d, svc.Name, svc.Namespace, 8080) if err : r.Update(ctx, registryCM); err ! nil { return ctrl.Result{}, err } return ctrl.Result{}, nil }关键设计点Deployment而非StatefulSetAgentic Agent的“状态”主要在外部存储如Redis缓存、PostgreSQL会话表Pod本身是无状态的。用Deployment更轻量支持滚动更新StatefulSet的有序部署在此场景是过度设计。Central Registry用ConfigMap不是etcd或独立服务因为ConfigMap更新后所有Agent Pod可通过watch机制实时感知。我们用kubectl get cm agent-registry -o yaml就能看到所有Agent的Endpoint运维一目了然。幂等性保障r.Create()前检查资源是否存在避免重复创建。K8s API的IsAlreadyExists错误是正常流程不是异常。部署Operator只需两步# 1. 构建镜像并推送 make docker-build IMGmy-registry/ax-controller:v0.1.0 docker push my-registry/ax-controller:v0.1.0 # 2. 安装CRD和Operator make install make deploy IMGmy-registry/ax-controller:v0.1.0验证Operator是否生效# 查看Operator Pod kubectl get pods -n ax-system | grep controller # 创建一个测试Agent kubectl apply -f examples/agent-retriever.yaml # 观察是否自动生成Deployment和Service kubectl get deploy,svc -l ax-agent-typeretriever # 应输出deployment.apps/agent-retriever 1/1 1 1 2m # service/agent-retriever ClusterIP 10.96.123.45 none 8080/TCP 2m3.4 Agentic工作流编排用Workflow CRD定义智能体协作图谱Agent单独运行没意义协作才有价值。“ax”用独立的WorkflowCRD定义协作关系而非硬编码在Agent代码里。一个典型RAG Workflow YAML如下# workflow-rag.yaml apiVersion: ax.example.com/v1 kind: Workflow metadata: name: rag-workflow spec: steps: - name: intent-classifier agentType: llm_router input: $.query # JSONPath引用输入 output: $.intent - name: retriever agentType: retriever input: $.intent # 上一步输出作为输入 output: $.chunks conditions: - type: intent technical target: tech-vector-db - type: intent sales target: sales-knowledge-base - name: generator agentType: formatter input: $.chunks $.query output: $.response timeoutSeconds: 30这个YAML被AxController解析后会自动创建3个Deployment分别对应3个Agent类型为retriever生成两个Servicetech-vector-db和sales-knowledge-base并设置NetworkPolicy限制访问在generatorDeployment的Env中注入RETRIEVER_SERVICE_URLhttp://tech-vector-db.default.svc.cluster.local根据条件动态注入。实操心得Workflow的input/output字段必须用JSONPath语法这是为了与K8s原生Event对象兼容。我们曾尝试用自定义表达式结果发现K8s Event的involvedObject字段无法解析导致告警系统失效。坚持用JSONPath虽然写法略啰嗦但保证了与整个生态的无缝集成。4. 实操过程与核心环节实现部署一个端到端的Agentic RAG服务4.1 准备Agent镜像从Python代码到K8s-ready容器Agentic Agent镜像不是简单pip install需满足K8s调度要求。以retrieverAgent为例其Dockerfile关键部分# Dockerfile.retriever FROM nvidia/cuda:11.8.0-devel-ubuntu22.04 # 1. 安装系统依赖必须 RUN apt-get update apt-get install -y \ python3-pip \ libpq-dev \ # PostgreSQL客户端 libsm6 libxext6 \ # OpenCV依赖 rm -rf /var/lib/apt/lists/* # 2. 设置Python环境 ENV PYTHONUNBUFFERED1 ENV PYTHONDONTWRITEBYTECODE1 WORKDIR /app # 3. 复制依赖并安装分离COPY利用Docker layer cache COPY requirements.txt . RUN pip3 install --no-cache-dir -r requirements.txt # 4. 复制代码最后COPY避免缓存失效 COPY . . # 5. 声明K8s必需的Entrypoint ENTRYPOINT [/app/entrypoint.sh]entrypoint.sh是关键它负责K8s生命周期集成#!/bin/bash # /app/entrypoint.sh # Step 1: 启动前注册到Central Registry echo Registering to agent-registry... curl -X POST http://localhost:8000/register \ -H Content-Type: application/json \ -d {\name\:\$AGENT_NAME\,\endpoint\:\http://$(hostname):8080\} # Step 2: 加载模型此处模拟实际为torch.load echo Loading retrieval model... sleep 10 # 模拟加载耗时 # Step 3: 启动HTTP服务 exec $ # 执行传入的CMD如 gunicorn app:app构建并推送镜像docker build -f Dockerfile.retriever -t my-registry/retriever:v1.0.0 . docker push my-registry/retriever:v1.0.0注意镜像大小必须控制。我们实测一个含BERT-base的Retriever镜像基础层依赖模型共1.2GB。K8s拉取1GB镜像平均耗时23秒会拖慢Pod启动。解决方案用multi-stage build构建阶段用python:3.11-slim最终镜像只保留python3.11和必要so库体积压缩至420MB启动提速60%。4.2 部署Workflow从YAML到可调用的API服务部署全流程命令# 1. 部署Workflow CRD首次 kubectl apply -f config/crd/bases/ax.example.com_workflows.yaml # 2. 部署Workflow实例 kubectl apply -f examples/workflow-rag.yaml # 3. 部署Gateway Service对外暴露 kubectl apply -f examples/gateway-service.yaml # gateway-service.yaml内容 # apiVersion: v1 # kind: Service # metadata: # name: ax-gateway # spec: # type: LoadBalancer # ports: # - port: 80 # targetPort: 8080 # selector: # app: ax-gateway验证服务可用性# 获取Gateway外部IP kubectl get service ax-gateway -o jsonpath{.status.loadBalancer.ingress[0].ip} # 发送测试请求模拟用户Query curl -X POST http://GATEWAY_IP/query \ -H Content-Type: application/json \ -d {query: How do I replace the brush in AX series DC motor?} # 预期响应 # {response:To replace the brush in AX series DC motors: 1. Power off and disconnect...}此时K8s集群中实际运行的资源1个ax-gatewayDeployment处理HTTP入口3个Agent Deploymentagent-llm-router、agent-retriever、agent-formatter3个对应Serviceagent-llm-router、agent-retriever、agent-formatter1个ConfigMapagent-registry存储所有Agent Endpoint。整个流程无需修改一行Agent代码纯声明式编排。4.3 监控与调优用PrometheusGrafana观测Agentic链路Agentic系统的监控不能只看CPU要深入业务维度。我们在Agent代码中嵌入Prometheus Client# app/metrics.py from prometheus_client import Counter, Histogram # 定义指标 AGENT_TASK_DURATION Histogram( agent_task_duration_seconds, Agent task duration in seconds, [agent_type, task_status] # 标签Agent类型、任务状态success/fail ) AGENT_TASK_COUNT Counter( agent_task_count_total, Total number of agent tasks, [agent_type, intent] # 标签Agent类型、用户意图 ) # 在Agent处理逻辑中使用 def handle_query(query): start_time time.time() try: result do_retrieval(query) AGENT_TASK_DURATION.labels(agent_typeretriever, task_statussuccess).observe(time.time() - start_time) AGENT_TASK_COUNT.labels(agent_typeretriever, intentget_intent(query)).inc() return result except Exception as e: AGENT_TASK_DURATION.labels(agent_typeretriever, task_statusfail).observe(time.time() - start_time) raise ePrometheus配置抓取这些指标# prometheus-config.yaml scrape_configs: - job_name: ax-agents kubernetes_sd_configs: - role: pod namespaces: names: [default] relabel_configs: - source_labels: [__meta_kubernetes_pod_label_app] regex: agent-(.*) target_label: agent_type replacement: $1 - source_labels: [__address__] regex: (.*):(.*) target_label: __address__ replacement: ${1}:8080 # Agent默认暴露8080端口Grafana看板关键面板P95延迟热力图X轴Agent类型Y轴时间颜色深浅表示延迟一眼看出retriever在下午3点峰值延迟飙升错误率趋势按agent_type和task_statusfail聚合发现llm_router在intenttechnical时错误率高达12%定位到模型阈值设置过低GPU显存占用TOP5100 * (node_gpu_memory_used_bytes{device0} / node_gpu_memory_total_bytes{device0})发现formatterAgent显存泄漏及时修复。实操心得Agentic监控的黄金指标是agent_task_duration_seconds_bucket直方图。我们曾忽略这点只看平均延迟结果发现95%的请求在200ms内完成但5%的长尾请求耗时8秒拖垮整体SLA。直方图能暴露长尾平均值会掩盖真相。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 典型问题速查表问题现象可能原因排查命令解决方案kubectl get agents返回空列表CRD未正确安装或命名空间错误kubectl get crd agents.ax.example.com检查CRD YAML中metadata.name是否与kubectl get命令一致确认kubectl apply在正确的namespaceAgent Pod状态为CrashLoopBackOff镜像启动失败或entrypoint.sh权限问题kubectl logs -p pod-namechmod x entrypoint.sh检查Dockerfile中ENTRYPOINT路径是否正确Workflow创建后无Deployment生成AxController未运行或RBAC权限不足kubectl get events -n ax-system检查Controller Pod日志验证ClusterRoleBinding是否绑定到ax-controllerServiceAccountretrieverAgent调用vector-dbService超时NetworkPolicy阻止访问或Service未就绪kubectl get networkpolicykubectl get endpoints agent-retriever确保NetworkPolicyspec.podSelector匹配Agent Pod标签检查agent-retrieverService的selector是否与Deploymentspec.template.metadata.labels一致GPU资源显示为0NVIDIA Device Plugin未安装或版本不匹配kubectl get nodes -o widekubectl get pods -n kube-system | grep nvidia重新安装匹配K8s版本的Device Plugin检查Node上nvidia-smi是否正常5.2 独家避坑技巧来自23次生产故障的总结技巧1用kubectl wait代替sleep做依赖等待不要在Shell脚本里写sleep 60等Deployment就绪这不可靠。正确做法kubectl wait --forconditionavailable --timeout120s deployment/agent-retriever kubectl wait --forconditionready --timeout60s pod -l appagent-retrieverwait命令会轮询API Server直到条件满足精度达秒级且超时可捕获。技巧2Agent日志必须结构化禁用print()print(Processing query:, query)输出非JSONLog Collector无法解析。必须用结构化日志import json import sys log_entry { level: INFO, time: datetime.now().isoformat(), agent_type: retriever, query_hash: hashlib.md5(query.encode()).hexdigest(), duration_ms: int((end-start)*1000) } print(json.dumps(log_entry))这样Kibana可直接按query_hash聚合分析慢查询。技巧3Workflow超时必须设且小于K8s Pod Tolerationsworkflow.spec.timeoutSeconds: 30但K8s默认Pod Eviction Timeout是300秒。如果Workflow超时Agent仍在运行会浪费GPU资源。解决方案在Agent代码中监听SIGTERM信号收到后立即退出import signal import sys def signal_handler(sig, frame): print(Received SIGTERM, shutting down...) sys.exit(0) signal.signal(signal.SIGTERM, signal_handler)技巧4GPU共享陷阱——永远不要让多个Agent共用一块GPU即使limits.nvidia.com/gpu: 0.5K8s也无法真正隔离GPU显存。实测两个0.5的Pod在同一卡上nvidia-smi显示显存被瓜分但CUDA Context冲突导致随机OOM。唯一可靠方案是limits.nvidia.com/gpu: 1并用nodeSelector确保每个Node至少1块独占GPU。5.3 性能调优实战将Agentic RAG端到端延迟从3.2s降至860ms我们对一个生产RAG服务做了深度调优关键步骤Step 1瓶颈定位用Jaeger Trace发现retrieverAgent中vector-db查询占总耗时72%其中network latencyAgent到DB的网络占45%。原来DB Service用了ClusterIP流量经