场景说明一条真实请求链路的断裂在 2025 年底上线的一个 AI 客服系统中业务方反馈“用户提问后偶尔无响应”但后台日志显示模型已成功返回结果。运维团队检查调用链路发现 LLM 调用、RAG 检索、工具执行均正常唯独前端未展示。进一步排查发现会话状态在“模型响应完成”后未正确流转至“待渲染”状态导致前端轮询接口始终返回“处理中”。更严重的是该问题在监控大盘中完全不可见——所有 SLI 指标如 P99 延迟、成功率均正常因为“服务调用成功”被定义为“模型返回非空响应”而状态流转失败被归类为“前端渲染问题”未纳入核心链路监控。这一现象暴露了 AI 系统后台可观测性设计的典型盲区链路通但体验断。当系统将“模型输出”等同于“用户可感知结果”时中间的状态同步、会话一致性、终态确认等关键治理环节被忽略导致故障无法被及时发现和归因。常见误区可观测性 调用成功率许多团队在构建 AI 系统可观测性时习惯沿用传统微服务的监控范式重点关注模型调用成功率HTTP 200向量检索响应时间MCP 工具执行耗时这种视角忽略了 AI 系统的本质特征输出依赖状态体验依赖终态。例如在 RAG 系统中即使检索和生成均成功若会话上下文未正确更新用户下一次提问仍可能丢失历史在 Agent 系统中工具调用成功但任务状态未推进会导致后续动作无法触发。更隐蔽的问题是AI 系统常引入“静默终态”——即系统未抛出异常但实际未达成用户预期。例如模型返回空数组被判定为“成功”但前端无内容展示会话状态卡在“处理中”前端持续轮询用户体验为“卡死”工具调用因权限失败但未更新任务状态用户无法感知这些场景在传统监控中几乎不可见因为“无异常”被误读为“无问题”。正确做法构建以终态为中心的可观测性体系要解决上述问题必须将可观测性设计从“调用链路”转向“用户终态”。核心思路是定义用户可感知的终态并围绕其构建分层指标与归因机制。1. 终态建模显式定义用户可感知状态在 AI 系统中用户终态不应是“模型返回”而应是“用户可操作或可理解的结果”。例如| 系统类型 | 用户终态示例 | |--------|-------------| | RAG 问答 | 用户收到完整回答且上下文可被后续提问引用 | | Agent 任务 | 任务状态为“已完成”或“已失败”并提供明确反馈 | | 自动发帖 | 内容已发布至目标平台或失败原因明确告知 |每个终态必须满足两个条件可观测可通过 API、数据库状态或日志明确判断可归因能追溯到具体模块如 RAG 检索失败、会话同步丢失2. 分层指标设计从调用到终态的归因链路传统监控只关注“调用层”而 AI 系统需构建三层指标调用层指标模型调用成功率、工具执行耗时等基础状态层指标会话状态流转成功率、终态达成率等核心体验层指标用户感知延迟、无响应率等决策例如在客服系统中定义session_finalized_rate会话在 T2s 内进入终态的比例response_visible_rate模型响应后 1s 内前端展示的比例context_preserved_rate连续提问中上下文未丢失的比例这些指标直接反映用户体验且能定位故障模块。例如若session_finalized_rate下降但模型调用正常则问题在状态同步层。3. 统一 Trace 与状态快照为支持终态归因必须实现跨模块 Trace从用户请求到终态确认的完整链路追踪包含 RAG、Agent、MCP 等子系统的调用与状态变更状态快照在关键节点如模型响应后、工具执行后记录会话状态用于故障回溯例如在模型响应后记录{ trace_id: abc123, step: model_response, session_state: awaiting_render, context_hash: sha256:..., timestamp: 2026-05-26T10:00:00Z }当终态未达成时可通过 Trace ID 回溯状态变更历史判断是哪个环节未触发流转。工程细节落地三层可观测性架构架构分层数据采集层在各模块埋点采集调用日志、状态变更、异常事件指标计算层实时计算终态指标如终态达成率、状态流转延迟归因分析层基于 Trace 和状态快照提供故障根因分析如“80% 的终态失败源于会话同步超时”关键实现终态检测器定时扫描未完成会话若超时未进入终态触发告警并记录上下文状态一致性校验在关键路径如 RAG 检索后校验会话状态是否合法若非法则强制重置体验指标告警当response_visible_rate低于 99% 时触发 P1 告警而非仅依赖调用成功率示例终态指标计算逻辑# 伪代码计算终态达成率 def calculate_finalized_rate(window_minutes5): total_sessions count_sessions_in_window() finalized_sessions count_sessions_with_final_state() return finalized_sessions / total_sessions if total_sessions 0 else 1.0该指标直接用于 SLO 定义如“终态达成率 ≥ 99.5%”并作为告警阈值。风险与边界性能开销状态快照和 Trace 采集可能增加 5-10% 的延迟需通过采样和异步写入优化状态定义模糊终态需与产品对齐避免技术视角与用户感知脱节归因复杂性多模块协同下终态失败可能涉及多个系统需建立跨团队归因机制总结AI 系统的可观测性不能停留在“调用成功”层面必须转向“终态可感知”。通过显式定义用户终态、构建分层指标、实现统一 Trace 与状态快照才能有效治理“链路通但体验断”的静默故障。工程落地需聚焦终态检测、状态一致性校验与体验指标告警最终形成从故障发现到根因定位的闭环。技术补丁包终态建模与指标定义 原理将用户可感知结果定义为终态并围绕其构建 SLI/SLO 设计动机解决“调用成功但体验失败”的监控盲区 边界条件终态需可观测、可归因避免定义过于宽泛 落地建议与产品对齐终态定义在会话表中增加final_state字段分层指标计算与告警 原理构建调用层、状态层、体验层三层指标优先监控体验层 设计动机实现从技术指标到业务影响的归因 边界条件避免指标过多导致告警疲劳聚焦核心终态 落地建议使用 Prometheus Grafana 实现指标计算与可视化设置体验指标为 P1 告警统一 Trace 与状态快照 原理在关键节点记录会话状态与上下文支持故障回溯 设计动机解决静默终态无法定位根因的问题 边界条件快照数据量可能较大需控制采样率 落地建议集成 OpenTelemetry 实现跨模块 Trace使用 Redis 缓存最近状态快照