传统服务报错，值班同学通常先看接口、实例和依赖。Agent 出问题时，表面症状更混乱：用户说“一直转圈”，可能是模型仍在生成、工具卡住、SSE 丢了终态，也可能任务已经完成但结果没有持久化。

运行手册不能按团队组件来写成“模型篇、向量库篇、MCP 篇”。值班者首先拿到的是用户症状和一个时间点。我更愿意从结果状态出发，先确认影响与副作用，再沿 Run 的证据链定位归属。

RAG 团队常用一张端到端准确率报表：问题发进去，答案对就记 1，错就记 0。这个数适合看整体趋势，却不能告诉我们该改 embedding、chunking、reranker、Prompt 还是知识源。

我会把评测拆成三层。第一层只测检索是否拿到充分证据；第二层固定正确证据，只测模型能否组织出正确、受引用支持的答案；第三层才跑真实端到端链路，验证两者组合后的延迟、成本和失败分布。

模型网关第一版通常很像反向代理：统一鉴权，替换 endpoint，把 messages 转给不同供应商。真正接入多个模型后，会发现最难的不是请求字段，而是每家对流式增量、结束原因、工具调用、错误和用量的表达都不同。

如果网关只输出一套“看起来统一”的 JSON，却不保存转换前证据，线上出现空回答、工具参数残缺或 HTTP 200 后中途断流时，无法判断问题来自供应商、适配器还是客户端。我会同时保留原生协议轨和统一语义轨，两者用同一个 request ID 关联。

数据平台接入 Spark、Flink 和 YARN 指标后，通常很快会建出一张“统一监控大盘”。最常见的统一方式，是把包含 CPU 的字段都改名为 cpu_usage，包含 records 的都改成 throughput。图表变整齐了，数值却失去原义：一个是累计 CPU 时间，一个是滑动窗口忙碌时长，另一个甚至只是调度器分配的 vcore-seconds。

我做跨引擎可观测时，不追求让所有指标长得一样。先保存原始指标和完整语义，再挑出真正可比较的业务事实。统一名字只能解决查询方便，统一口径才可能支撑诊断。

数据任务失败后，排查过程经常是这样的：先在调度平台找到实例，再去 YARN 搜 application，进入引擎页面找 stage，最后 SSH 到某个节点翻 container 日志。中间任何一层 ID 没记住，就只能靠任务名和时间范围碰运气。

这不是日志数量不够，而是缺少关联键。调度器、提交服务、资源管理器和计算引擎各自都有状态，却没有一条稳定标识把它们连成同一次运行。平台最后只能截取“最近 100 行”放在失败弹窗里，看起来集中，实际上丢掉了大量上下文。

我做数据任务可观测性时，第一步不会先搭新的日志检索页面，而是把 schedule_instance_id 从创建实例开始传到执行端，并在每次外部资源分配后立即保存映射。只要关联关系可靠，日志、指标、trace 和配置才有机会组成证据链。