观测数据只有能关联到一次请求和一次变更时才有用。字段命名、采样和脱敏规则应在接入前确定。一次请求使用同一个请求 ID，日志、指标和 Trace 采用一致的服务与版本字段。日志记录事件上下文，指标看趋势，Trace 还原路径，三者不要混成一项。

检索增强系统的第一版不需要先堆齐缓存、异步队列和多路召回。先确认文档怎么入库、谁负责召回、上下文在哪里拼装、模型调用失败后返回什么；这条窄链路跑清楚，再谈扩展。

用 LangChain 写一个能调用搜索 API 的 Agent，三十行代码就够了。但换成生产环境——需要断点恢复、人工审核节点、并发 Agent 间的状态隔离、以及三个月的可维护性——Demo 和生产的鸿沟立刻显现。LangGraph 从状态机理论出发，把 Agent 拆成图节点和边，天然适合复杂的条件分支和人工介入。CrewAI 以角色分工的隐喻组织多个 Agent 协作，概念上最容易理解。A

多 Agent 协作不是"下一个 LLM 能力升级"能跳过的问题，它是工程架构问题。三个关键的工程方向在 2026-2027 年会持续演进：Agent 间通信协议的标准化（类比 HTTP 对 Web 的意义）、共享记忆与状态管理（类比数据库对 Web 应用的意义）、中断与重规划机制的工程化（类比 Kubernetes Controller 的 reconcile 循环）。对于正在落地的团队，务实的

Agent 的调用链不是单次推理，是多步骤、多类型调用（LLM + 工具 + 逻辑）的串联。可视化这条链路不是为了好看，是为了在延迟飙升时立刻定位瓶颈步骤。按step_type分类：LLM 调用、工具调用、内部逻辑的延迟特征不同，不分类就无法诊断。Token 耗用按步骤拆分：不同步骤可能用不同模型，拆分后才能找到成本优化方向。重试和循环必须标注：反思机制的循环会让调用链变长，标注和才能理解实际逻辑

RAG 链路搬进本地 Kubernetes 时，不必先追求完整平台。先让文档入库、向量检索、上下文拼装和模型调用分别可检查，问题会清楚很多。

云原生 AI 平台最容易出现的误区，是把“有多少张卡”直接等同于“能接多少任务”。调度器真正面对的是显存、执行时间、队列等待和租户配额。任意一项没有边界，扩容都可能只是把积压移到别处。

把智能检索接进 Kubernetes，不等于在控制器里塞一个模型调用。控制循环要求可重复、可恢复，模型输出则可能延迟、失败或不稳定，两者需要隔开。

对于存储与网络层，卷挂载、服务寻址和网络策略比抽象架构更值得先检查。本文把“存量系统迁移的分阶段切换路径”限定为可由配置、代码和测试记录交叉验证的事项。

检索增强链路先要确认文档入库、召回、上下文拼装和模型调用由谁维护、何时算完成。服务边界都没稳定时，先增加编排组件只会多出一层排障成本。