把外部依赖管起来：供应商变更与退出预案

外部依赖会涨价、改接口、限流、下线。本文给出依赖登记表字段、四类变化的应对、必须提前做的三件事（抽象层/契约测试/切换演练）、该监控的四类信号与每个致命依赖该问的三问。

外部依赖是"会变的"

AI 功能几乎都依赖外部：模型服务、向量库、爬虫源、云厂商 ✔。

这些依赖会**涨价、改接口、限流、下线** ✔ —— 如果没准备，某天早上系统就会大面积挂掉 ✔。

**把外部依赖当风险来管** ✔：登记、监控、留退路 ✔。

```

依赖名｜用途｜关键程度（致命/可降级/可替换 ✔）

｜当前版本/接口｜计费口径｜变更通知渠道｜退路方案｜负责人

```

**要点**：**关键程度与退路方案**最常被省 ✗ ——

没有退路方案的"致命依赖"，就是单点故障 ✔。

| 变化 | 应对 |

|---|---|

| 涨价 | 成本上限告警；准备替代方案；按档位切换 ✔ |

| 接口变更 | 版本锁定 + 变更前灰度；沙箱先验 ✔ |

| 限流收紧 | 配额与排队；多供应商分流 ✔ |

| 服务下线 | **提前迁移**（这是最需要预案的 ✔） |

**"多供应商分流"是最实用的退路** ✗→✔：同一能力接两家 ✔，

平时按比例或按档位分流 ✔，一家出问题时能快速切换 ✔。

1. **抽象层** ✔：业务代码不直接调某家 SDK ✗ → 中间加一层适配 ✔（换供应商只改适配层 ✔）；

2. **契约测试** ✔：用同一批样本测两家供应商，确认行为差异在可接受范围 ✔；

3. **切换演练** ✔：真的切一次（见断上游演习那篇 ✔），确认链路能跑 ✔。

**各依赖的错误率与延迟**（分供应商 ✔）；

**配额使用率与限流触发次数** ✔；

**计费口径变化的异常**（单位成本突然抬升 ✔）；

**官方变更公告**（订阅渠道，别靠新闻 ✗）。

```

对每个"致命依赖"问三个问题：

① 它今天挂了，我们能撑多久？（小时/天 ✔）

② 有没有第二家能接？（有 → 演练过吗 ✔）

③ 迁移要多久？（人日量级 ✔ —— 超过一周就要提前立项 ✔）

```

> 你的主力模型供应商**明天宣布下线** ✔，你能否在**两周内**完成切换 ✔ 且质量不降 ✔？

> 答不出，说明外部依赖还只是"用着"，没有被管理 ✗。