AI 成为基础设施之后：单链路接入的风险和企业数字韧性必修课

一、从"应用"到"基础设施"：AI 角色的根本性位移

过去三年，AI 在企业中的定位发生了两次跳跃。第一次是从"实验室模型"到"产品功能"，典型形态是智能客服、内容生成、代码补全；第二次是从"产品功能"到"基础设施"，典型形态是推理网关、模型路由层、Agent 编排框架。第二次跳跃的意义远大于第一次——当 AI 成为基础设施，它的可用性就不再只影响某个功能，而是会沿着调用链向上传导，影响整个业务系统。

这种位移有一个可观测的信号：越来越多的企业开始把模型调用写进核心业务流程，而不是旁路功能。例如订单风控、工单分派、合同初审、日志归因等场景，AI 输出直接进入决策路径。一旦这条路径中断，业务不是"体验变差"，而是"流程停摆"。笔者认为，判断一个 AI 组件是否已经"基础设施化"，标准不是调用量，而是它中断后业务是否还能继续运转。

从产业数据看，这一趋势有明确支撑。Gartner 在 2024 年的相关报告中指出，到 2026 年将有超过 80% 的企业使用生成式 AI 的 API 或模型，而 2023 年这一比例不足 5%（来源：Gartner, 2024）。CNCF 2024 年云原生调查显示，AI/ML 工作负载在 Kubernetes 上的部署比例持续上升，推理服务正在被当作标准工作负载管理（来源：CNCF Annual Survey, 2024）。这些数据共同指向一个结论：AI 组件正在被纳入与数据库、消息队列同级的可靠性要求。

但基础设施化的速度，快于可靠性工程的建设速度。数据库领域经过几十年沉淀，有了主从复制、多活、一致性协议、混沌工程等成熟实践；而 AI 推理链路的可靠性工程，仍处于早期阶段。多数团队对"模型供应商挂了怎么办"的回答，还停留在"换一家 API"这种朴素层面。

二、依赖拓扑：本文的分析主线

要系统分析单链路风险，需要一个统一的观察视角。本文提出"依赖拓扑"作为贯穿全文的分析主线。所谓依赖拓扑，是指把一次 AI 调用所经过的全部节点（客户端、网关、模型供应商、区域端点、向量库、工具函数、外部数据源）抽象为图，节点之间的调用关系构成边，边的数量、方向、冗余度决定了系统的脆弱程度。

这个视角的价值在于：它把"单链路"从一个模糊的说法，变成可度量、可比较的结构特征。一条链路是否"单点"，不取决于它经过几个组件，而取决于关键节点是否存在替代路径。一个经过五个组件但每个组件都只有一条路径的链路，脆弱性远高于一个经过十个组件但关键节点有冗余的链路。

基于依赖拓扑，本文把韧性建设拆成三层：架构层解决"路径冗余"，工程层解决"失效兜底"，治理层解决"契约与评测"。三层缺一不可。只做架构冗余而不做语义评测，会在切换时产生质量事故；只做工程兜底而不做治理，会在长期积累隐性债务。

三、单链路接入的失效模式图谱

3.1 供应商级失效

供应商级失效是最直观的一类。2024 年以来，多家主流模型服务商都出现过不同程度的中断。例如 OpenAI 在 2024 年多次出现 API 状态异常，其官方状态页记录了多起影响 API 与 ChatGPT 的事件（来源：OpenAI Status, 2024）。Anthropic、Google、Azure OpenAI 等也都有公开的状态事件记录。这些事件本身并不罕见——任何大规模在线服务都会有故障——但对单链路接入的企业而言，供应商的一次故障就是自己的一次全量故障。

更隐蔽的是"部分失效"。供应商整体可用，但某个模型版本、某个区域端点、某类请求（如长上下文、函数调用）出现异常。这类失效不会触发全局告警，却会让特定业务路径静默劣化。Uptime Institute 的年度报告长期指出，配置错误和第三方依赖是数据中心中断的主要成因之一（来源：Uptime Institute Annual Outage Analysis, 2023–2024）。AI 链路把"第三方依赖"的权重进一步放大了。

3.2 网络与区域级失效

即使供应商健康，网络路径也可能成为单点。跨境调用、专线、DNS 解析、TLS 证书、出口 IP 限流，任何一环出问题都会导致链路中断。云厂商的区域故障（region outage）在历史上多次发生，例如 AWS us-east-1 的多次重大事件、Google Cloud 的区域性故障等，均有公开复盘（来源：AWS Post-Event Summaries；Google Cloud Incident Reports）。如果企业的 AI 调用只配置了单一区域端点，区域故障就会直接穿透到业务。

3.3 配额、限流与成本级失效

这类失效常被忽视。供应商的速率限制（RPM/TPM）、并发上限、账户配额，在业务高峰或流量突增时会成为硬约束。它不是"坏了"，而是"接不住了"。当企业把单链路当作唯一通道，一次营销活动、一次爬虫误触发、一次重试风暴，都可能把配额打满，导致正常业务请求被拒绝。

重试风暴尤其值得警惕。当客户端在超时后无节制重试，会把一次局部故障放大为雪崩。这在分布式系统中是经典问题，Google 的 SRE 系列对此有系统论述（来源：Google SRE Book, O'Reilly）。AI 链路的特点是单次调用延迟高、token 消耗大，重试的代价比普通 RPC 更高。

3.4 语义级失效

这是 AI 链路最独特的一类失效。链路完全可用，接口返回 200，但输出质量下降。可能原因包括：供应商静默更新模型版本、温度参数漂移、系统提示被截断、上下文超限导致信息丢失、函数调用格式变化。这类失效不会触发传统监控，却会直接污染业务数据。

学术界对模型行为漂移已有研究。例如 Chen 等人关于大模型版本更新对下游任务影响的分析指出，模型"静默升级"可能导致同一提示词下的输出分布显著变化（来源：Chen et al., 2023, arXiv）。笔者认为，语义级失效是单链路风险中最危险的一类，因为它同时具备"高隐蔽性"和"高业务影响"两个特征，而传统可观测性体系几乎无法覆盖。

3.5 失效模式对比

表 1：四类失效模式对比（本文整理，结合公开事故报告与工程实践归纳）

四、架构层：多链路冗余与智能路由

4.1 从"备一家"到"拓扑冗余"

最朴素的做法是"主备两家供应商"。但这只解决了供应商级失效，且引入了新问题：备用链路平时不跑流量，切换时才发现接口不兼容、配额不足、质量不达标。本文评述：静态主备在 AI 场景下价值有限，因为 AI 链路的"兼容性"远比 HTTP 兼容复杂。更合理的做法是让多条链路平时就承载一定流量，保持"热"状态。

具体路径可以分三步走。第一步，抽象统一调用层，把供应商差异封装在适配器内，业务代码只依赖内部接口。第二步，为每条链路配置独立的配额、密钥与监控。第三步，按业务重要性分配流量比例，例如核心链路 70/30，非核心链路 90/10，并定期轮换主备角色。

4.2 智能路由的决策维度

多链路之上需要路由层。路由决策不应只看"谁便宜"或"谁快"，而应综合多个维度。下表给出一组可落地的决策维度与权重示例（权重为工程经验值，属模拟配置，非实测数据）。

表 2：路由决策维度与示例权重（模拟配置，供工程参考）

路由层还需要处理"粘性"问题。某些任务（如多轮对话、Agent 长任务）需要保持上下文一致，频繁切换供应商会导致语义断裂。可行的做法是按会话维度做粘性路由，同时为每个会话保留一条降级路径。

4.3 一个可落地的最小架构

对多数团队，不必一步到位做复杂路由。一个最小可行架构包含四层：统一 SDK（屏蔽供应商差异）、路由网关（健康检查 + 权重）、缓存层（语义缓存 + 结果缓存）、评测探针（定时抽样打分）。这四层可以用开源组件快速搭起来，例如 LiteLLM 提供多供应商统一接口，Envoy 或 Nginx 做网关，Redis 做缓存。相关教程可参考 LiteLLM 官方文档（https://docs.litellm.ai）与 Envoy 官方文档（https://www.envoyproxy.io/docs）。

五、工程层：缓存、降级与语义兜底

5.1 语义缓存

AI 调用的一个特点是"相似请求多"。客服问答、FAQ、模板化生成等场景，大量请求在语义上高度重复。语义缓存通过向量相似度匹配，把历史结果复用给相似请求，既降成本又降延迟，同时在供应商故障时提供一层缓冲。GPTCache 是这一方向的代表性开源项目（来源：GPTCache, GitHub）。

但语义缓存有风险：相似度阈值设得太松，会返回错误答案；设得太紧，命中率低。本文评述：语义缓存必须与业务风险等级绑定。低风险场景（如推荐语生成）可放宽阈值，高风险场景（如金额计算、合规判断）应禁用或严格限制。

5.2 分级降级策略

降级不是"关掉功能"，而是"按业务价值排序，逐级降低服务质量"。一个可操作的分级如下：

1. L0 正常：主链路，全功能。
2. L1 降模型：切换到更小、更快的模型，牺牲部分质量保可用。
3. L2 降功能：关闭非核心生成能力，保留核心问答或分类。
4. L3 走缓存：只返回缓存或模板结果，标注"可能不最新"。
5. L4 人工兜底：转人工队列或异步处理，明确告知用户。

分级降级的关键是提前定义"什么业务在什么级别下可以接受什么质量"。这需要业务、工程、风控共同参与，不能由工程单方面决定。

5.3 超时、重试与熔断的正确姿势

AI 调用延迟高，超时设置需要区分场景。流式输出与一次性输出应使用不同超时策略。重试必须带指数退避与抖动（jitter），并设置全局重试预算，避免重试风暴。熔断器应基于错误率与延迟双指标触发，并在半开状态下用小流量探测恢复。这些模式在微服务领域已成熟，Resilience4j、Polly 等库都有实现，可直接借鉴。

# 伪代码：带预算的重试与熔断
retry_budget = 100  # 每分钟全局重试上限
def call_llm(prompt):
    if breaker.is_open():
        return fallback(prompt)
    for attempt in range(3):
        try:
            return provider.call(prompt, timeout=adaptive_timeout(prompt))
        except (Timeout, RateLimit) as e:
            if retry_budget.exhausted():
                breaker.trip()
                return fallback(prompt)
            sleep(backoff(attempt) + jitter())
            retry_budget.consume()
    return fallback(prompt)

5.4 语义兜底

当所有模型链路都不可用时，系统仍应给出"有意义的失败"。例如返回结构化错误、引导用户稍后重试、提供知识库检索结果作为替代。语义兜底的目标是让用户感知到"系统在尽力"，而不是"系统崩了"。

六、治理层：契约、评测与供应商管理

6.1 把 SLA 读细

多数模型供应商提供 SLA，但条款差异很大。需要关注的点包括：可用性定义（是否按请求成功率）、统计周期、赔付方式、排除条款（如计划维护、不可抗力）、是否覆盖特定模型版本。本文评述：SLA 是"事后补偿"，不是"事前保障"。企业不能把 SLA 当作韧性方案，它只能作为供应商选择的参考维度之一。

6.2 建立内部评测基线

没有评测，就无法判断"切换后是否变差"。企业应建立与自身业务强相关的评测集，覆盖典型任务、边界案例、对抗样本。评测应定期跑，并在供应商版本更新、路由切换、提示词变更时触发。开源评测框架如 OpenAI Evals、LangSmith、Ragas 等可作为起点（来源：OpenAI Evals, GitHub；LangSmith 文档；Ragas 论文与文档）。

评测集的建设需要说明数据来源与预处理。以客服场景为例，可从历史工单中抽样，去标识化后人工标注标准答案，再按意图分类分层抽样，确保覆盖长尾。预处理细节应在内部文档中记录，便于复现。

6.3 供应商生命周期管理

供应商管理应覆盖准入、运行、退出三个阶段。准入阶段评估能力、合规、财务稳定性；运行阶段持续监控质量与成本；退出阶段确保平滑迁移。建议为每个关键供应商维护一份"依赖档案"，记录接口版本、配额、联系人、应急预案。

七、韧性度量：把"感觉稳"变成可量化指标

韧性建设如果没有度量，就无法改进。本文提出一组可操作的指标，覆盖可用性、恢复力、质量稳定性三个维度。

表 3：AI 链路韧性指标建议（目标值为工程参考，非行业标准）

这些指标应纳入现有 SRE 看板，与业务指标联动。例如当降级触发率上升时，应自动关联到具体业务线的转化率变化，形成"技术指标—业务指标"的闭环。

八、组织演练与前沿预判

8.1 混沌工程进入 AI 链路

混沌工程在传统系统已成熟，在 AI 链路同样适用。可设计的实验包括：注入供应商 5xx、注入高延迟、模拟配额耗尽、模拟语义漂移（返回低质量结果）、模拟缓存失效。Chaos Mesh、Litmus 等工具可用于基础设施层，应用层则需要自研注入点。相关教程可参考 Chaos Mesh 官方文档（https://chaos-mesh.org/docs）。

演练的关键是"有剧本、有观测、有复盘"。每次演练应明确假设、影响范围、回滚方案，并在结束后更新应急预案。

8.2 前沿预判

从学术与产业趋势看，几个方向值得关注。第一，模型路由的自动化与学习化，已有研究探索基于强化学习的路由策略（来源：相关路由研究，arXiv 2023–2024）。第二，推理层的标准化，如 OpenTelemetry 对 LLM 调用的语义约定正在推进（来源：OpenTelemetry Semantic Conventions for GenAI）。第三，端侧与小模型作为兜底路径，在隐私与可用性上都有价值。第四，监管对关键 AI 系统韧性的要求可能上升，例如欧盟 AI Act 对高风险系统的风险管理要求（来源：EU AI Act, 2024）。

笔者认为，未来两到三年，"AI 韧性工程"会像当年的"云原生可观测性"一样，从少数团队的实践变成行业标配。提前布局的团队，会在故障频发的周期里获得显著的竞争优势。

九、结论与行动清单

AI 成为基础设施，是趋势而非选择。单链路接入的风险，本质上是依赖拓扑的脆弱性。本文以依赖拓扑为主线，从架构、工程、治理三层给出路径。核心结论有三点：其一，冗余必须是"热"的，静态主备在 AI 场景下价值有限；其二，语义级失效是最危险的盲区，必须用在线评测覆盖；其三，韧性需要度量，没有指标就无法改进。

给出一份可直接执行的行动清单：

1. 盘点现有 AI 调用链路，画出依赖拓扑图，标出单点。
2. 抽象统一调用层，接入至少两家供应商，保持热流量。
3. 部署语义缓存与分级降级策略，明确各级业务影响。
4. 建立内部评测集，定期跑分，监控质量漂移。
5. 配置韧性指标看板，纳入 SRE 体系。
6. 每季度做一次混沌演练，更新应急预案。
7. 维护供应商依赖档案，覆盖准入到退出。