AI 系统分层治理：从用户无感知降级到多能力协同的架构演进

用户症状：一次“正常”的对话中断

2026 年初，某企业 AI 助手上线三个月后，客服团队陆续收到用户反馈：“有时候问完问题，等了很久只返回‘稍等一下’，然后就没了下文”。前端日志显示请求已发出，后端日志显示任务已创建，但用户端未收到最终回复。该问题在高峰时段偶发，平均每天影响约 300 次对话，占总量 0.7%。

表面看是响应延迟，但深入排查发现，系统并未真正“失败”——任务在 Agent 编排层被标记为“处理中”，却因 RAG 检索超时、模型路由策略僵化、补偿机制缺失等原因，长期滞留在中间状态，最终因前端超时主动断开连接，导致用户感知为“静默中断”。

本文将围绕这一真实场景，拆解 AI 系统从单能力到多能力协同演进过程中，架构分层与治理策略的关键设计取舍，重点说明如何通过职责划分、状态显式建模、分层补偿与指标归因，构建可观测、可恢复、可决策的长期稳定系统。

技术链路：从单一模型调用到多能力编排

早期版本中，系统采用“前端 → API 网关 → 模型服务 → 返回”的简单链路。随着需求复杂化，逐步引入 RAG 增强、多 Agent 协作、模型路由、MCP 协议对接等能力，形成如下分层结构：

1. 接入层：处理用户输入、会话上下文、权限校验，输出标准化请求。
2. 编排层：基于意图识别，决策调用 RAG、Agent 或直连模型，管理任务生命周期。
3. 能力层：包含 RAG 检索、模型路由、MCP 工具调用等独立模块，各自维护状态与超时策略。
4. 数据层：向量数据库、模型元数据、任务状态存储等。

问题出现在编排层与能力层的协同边界。当 RAG 检索因知识库索引延迟而超时（默认 5s），编排层未及时感知，继续等待；同时，模型路由因未收到 RAG 结果，无法触发降级策略（如切换轻量模型），导致整个任务卡在“等待 RAG 响应”状态。前端因 10s 超时断开，但后端任务仍在运行，形成“静默悬挂”。

关键故障点：状态盲区与补偿缺失

通过链路追踪与日志分析，定位出三个关键故障点：

• 状态未显式建模：编排层仅用“pending”、“success”、“failed”三态，无法表达“部分完成”、“等待外部依赖”等中间态，导致监控无法识别异常滞留。
• 补偿机制缺失：能力层超时后，编排层无自动重试或降级策略，依赖人工介入。
• 指标割裂：RAG 超时率、模型路由成功率、任务完成率分别由不同团队维护，缺乏统一 SLI/SLO 定义，难以归因。

进一步分析发现，系统在设计时过度关注“功能实现”，忽略了“状态一致性”与“故障恢复”的架构约束。尤其在引入 MCP 协议对接第三方工具后，外部依赖增多，但编排层未建立“外部依赖健康度”评估机制，导致局部故障扩散为全局静默。

修复方案：分层治理与显式状态控制

1. 引入四层状态机模型

将任务状态从三态扩展为六态，显式建模中间过程：

• init：任务创建
• rag_pending：等待 RAG 检索
• agent_planning：Agent 制定执行计划
• tool_calling：调用 MCP 工具
• model_inferring：模型推理中
• completed / failed：终态

每个状态变更均记录时间戳与上下文，便于追踪与告警。

2. 构建分层补偿机制

针对不同层级设计补偿策略：

• 能力层补偿：RAG 超时后，自动切换至缓存快照或简化检索策略；模型路由失败时，按预设权重降级至备用模型。
• 编排层补偿：任务滞留超过阈值（如 30s）时，触发“强制终态”流程，向用户返回“服务繁忙，建议重试”并记录异常。
• 数据层补偿：向量写入失败时，启用本地缓存队列，异步重试入库。

补偿策略需配置熔断机制，避免雪崩。例如，RAG 连续失败 3 次后，自动禁用该能力 5 分钟，并通知运维。

3. 统一 SLI/SLO 与指标归因

定义三层可观测指标：

| 层级 | SLI | SLO | 归因维度 | |------|-----|-----|--------| | 用户体验 | 对话完成率 | ≥99.2% | 用户 ID、会话类型 | | 系统能力 | RAG 检索成功率 | ≥98% | 知识库 ID、查询复杂度 | | 基础设施 | 模型推理 P99 延迟 | ≤2s | 模型类型、输入长度 |

通过统一 Trace ID 串联各层日志，实现从用户请求到模型调用的全链路归因。当对话完成率下降时，可快速定位是 RAG 超时、模型路由错误还是 MCP 工具故障。

4. 动态权重路由与效果感知

模型路由不再依赖静态配置，而是结合实时指标动态调整：

• 基于模型响应时间、错误率、成本，计算综合健康度得分。
• 路由策略按得分分配流量，低健康度模型自动降权。
• 引入“效果反馈闭环”：用户是否重试、是否投诉，作为路由策略的长期优化信号。

例如，某模型虽响应快但常被用户重试，系统将自动降低其权重，优先选择响应稍慢但准确率更高的模型。

风险与边界：治理不等于过度工程

分层治理带来收益的同时，也引入新风险：

• 复杂度上升：状态机膨胀可能导致调试困难，需配套可视化工具。
• 补偿误触发：过度补偿可能掩盖真实问题，需设置人工审核阈值。
• 指标噪声：用户行为波动可能干扰 SLO 判断，需引入滑动窗口与异常检测。

边界条件需明确：

• 补偿机制仅适用于“可恢复故障”，如网络抖动、临时过载；对于数据损坏等不可逆问题，应直接失败并告警。
• 动态路由不适用于强一致性场景（如金融审核），需保留手动指定模型能力。
• 状态建模粒度需权衡性能开销，避免高频状态变更影响吞吐量。

预防机制：从故障响应到长期演进

为避免类似问题复发，建立三层预防机制：

1. 架构评审 checklist：新增能力模块时，必须定义状态流转图、超时策略、补偿方案。
2. 混沌工程演练：定期模拟 RAG 超时、模型不可用等场景，验证补偿机制有效性。
3. 成本-稳定性权衡看板：将模型成本、响应时间、错误率纳入统一决策框架，支持业务方自主选择“快但贵”或“慢但稳”策略。

长期来看，AI 系统应从“功能堆叠”转向“治理能力驱动”。分层不是目的，而是实现可控、可观测、可进化的手段。

技术补丁包

1. 显式状态机建模 原理：将任务生命周期拆分为原子状态，每个状态对应明确的处理逻辑与超时策略。 设计动机：解决“静默悬挂”问题，提升系统可观测性与故障恢复能力。 边界条件：状态数量不宜超过 8 个，避免状态爆炸；需配套状态转换图文档。 落地建议：使用有限状态机库（如 XState）建模，状态变更记录至日志与数据库。

2. 分层补偿策略 原理：在不同层级（能力层、编排层、数据层）设置独立的超时、重试、降级机制。 设计动机：避免单点故障扩散，提升系统整体韧性。 边界条件：补偿操作需幂等；重试次数需限制，防止资源耗尽。 落地建议：补偿逻辑与主流程解耦，通过消息队列异步执行；配置熔断器监控失败率。

3. 统一 SLI/SLO 归因体系 原理：定义跨层级的可量化指标，并通过 Trace ID 实现端到端关联。 设计动机：打破指标孤岛，支持快速故障定位与业务决策。 边界条件：SLO 需基于历史数据设定，避免过于激进；归因维度不宜过多，防止查询性能下降。 落地建议：集成 OpenTelemetry 实现全链路追踪；使用 Prometheus + Grafana 构建监控看板。

4. 动态模型路由 原理：结合实时健康度指标（响应时间、错误率、成本）动态调整模型流量分配。 设计动机：实现成本与效果的平衡，避免静态配置导致的资源浪费或性能瓶颈。 边界条件：不适用于强一致性场景；需保留人工 override 能力。 落地建议：使用加权轮询或一致性哈希实现流量分配；健康度计算采用滑动窗口（如 5 分钟）。

5. 效果反馈闭环 原理：将用户行为（如重试、投诉、停留时长）作为模型效果的长期反馈信号。 设计动机：弥补仅依赖技术指标的不足，实现业务导向的优化。 边界条件：需处理数据稀疏性与噪声；反馈延迟可能影响实时性。 落地建议：构建用户行为事件流，定期训练路由策略模型；设置 A/B 测试验证策略有效性。

总结

AI 系统的稳定性不仅取决于模型能力，更依赖于架构的分层治理。从用户无感知降级问题出发，本文展示了如何通过显式状态建模、分层补偿、统一指标归因与动态路由，构建可观测、可恢复、可决策的长期稳定系统。治理不是银弹，但它是 AI 工程从“能用”走向“好用”的必经之路。