一块白板上按五类依赖列出待办条目，每行右侧标着自托管、换平台、砍掉三种退路的勾选框

一、公告把供应商风险变成一张可点的清单

据公开报道，某智能体托管平台发布过一份停止服务公告，因业务调整将在指定日期停止服务，届时关闭应用访问、数据读写、接口调用、控制台使用等面向公众的服务，已发布到其他渠道的内容同样受影响。公告给出的具体日期与停服原因本篇都不引用也不推测，也不评价这家平台的业务决策。值得抄下来的是公告的结构：它把要关闭的能力一条条列清楚了。列得越具体，使用方越能照着把自己究竟有几处靠它拆干净。

平时讲供应商风险，通常是一句抽象的话：不要把关键能力放在别人手里。停服公告把这句话变成一张清单，清单上每一行都能对应到我方系统里某个真实存在的东西：一个用户能点开的入口、一批存在别人服务器上的数据与配置、若干我方服务对别人接口的调用、一组只在那个控制台里才看得见的运维与观测能力、一条把内容递到第三方手里的分发链路。这五类依赖的退出成本相差极大，混在一起盘只会得到“整体迁走”这种做不动的结论；分开盘，每一类都能给出退路、判据和窗口内该做的动作。

我们的态度是：停服那天不是使用方的责任日，公告期能完成多少，取决于此前把依赖记到了什么颗粒度。所以下面只写能执行的东西：盘点字段、退路判定依据、导出的验收判据、中断时的错误语义、对外告知的措辞纪律、窗口内的动作顺序。

二、五类依赖各自要盘到什么颗粒度

盘点表的每一格都要落到人和物上，只写“我们用了某平台”等于没盘。

第一类，对外可访问的应用入口。要列每个入口的域名或路径归属、由谁维护、有没有嵌进客户自己的系统、有没有在合同或服务说明里承诺过可用性。这一类最常被低估，因为它看起来只是一条链接，实际上工单模板、帮助文档、接口对接说明里都写着它，改一处不算改完。

第二类，存在平台侧的数据与配置。要分三层：原始数据（对话记录、用户上传的文件、业务表）、平台加工出来的派生对象（索引、向量、评估结果、会话摘要）、以及配置（角色与权限矩阵、环境变量、密钥引用、定时任务与回调地址）。三层里最常漏的是配置，尤其“某个开关为什么是开着的”这类只有当事人知道的事。窗口内不把这些问出来，事后就没人答得上。

第三类，我方系统对它的接口调用。按调用方逐条登记：哪个服务、哪个方法、日均量级、失败时用户能不能看见、有没有第二个供给源。这一类的风险不在数据而在运行期行为，很多功能只是恰好建在那个接口上，业务方从未把它当依赖看待。

第四类，控制台提供的运维与观测能力。告警在那里配、日志在那里查、配额与用量在那里看。停服之后这一类不会以报错的形式出现，而是直接变成盲区，所以要在窗口内把告警规则、指标定义、仪表盘查询语句导出成文本，截图不算导出。

第五类，已发布到第三方渠道的分发链路。公告里那句“已发布到其他渠道的内容同样受影响”最值得注意，因为它的影响面不在我方系统内，而在别人的产品里：应用市场、嵌入页、合作方站点。这一类的盘点口径是“谁手里现在有一份指向我们的东西”。

三、核心交付物之一：五类依赖的盘点表

下面这张表是我们建议照抄的形状。三列退路不是让你三个都选，而是逼你把“这条路走不通的理由”写下来；理由写不出来说明还没盘。

依赖类别 必填盘点字段 自托管复刻 换同类平台 砍掉该能力 判定依据
应用入口 域名归属、嵌入方清单、对外可用性承诺 需前端与网关两块能力 最快但会再撞一次同类风险 入口不可砍，只能改指向 是否承载收入
平台侧数据与配置 原始、派生、配置三层清单加字段字典 取决于数据格式是否公开 格式不通用时要先做转换层 派生对象多数可砍 数据可携程度
我方接口调用 调用方、方法、量级、失败可见后果 需自建同语义服务并承担运维 需接口语义对照后逐项替换 非核心链路可砍 迁移时间窗
控制台运维观测 告警规则、指标定义、查询语句、值班习惯 需接入自有观测栈 同类工具替换成本低但要重配 可降级为只看关键指标 是否承载收入与值守能力
第三方分发链路 谁手里有指向我们的对象、其变更由谁控制 不可自托管，只能改为自有渠道 取决于对方渠道的准入条件 可砍但会丢触达 可携程度与触达价值

判定依据只有三条，反复用：这件事是否承载收入或不可替代的合同义务；对方给出的数据是否可携、携出来的是不是能直接用的形态；从我方现有工程能力看，迁移时间窗够不够跑完一次完整回归。三条里任何一条答不上来，退路就不该选“换同类平台”，因为那只是把同一次事故推迟发生。

四、导出的验收与接口中断的兜底语义

导出这件事，只看“下载成功”是不够的。真正的验收判据我们按五条走：

  • 拿到的是原始数据还是平台视图。平台视图常常已经做过裁剪与折叠，例如把多轮结构摊平成单条文本，摊平之后会话就不能再当上下文使用。
  • 附件与图片是否随包，命名与路径关系是否保留。文本齐了、原件没了，是导出数据最常见的残缺形态。
  • 配置与权限能否还原。角色矩阵、可见范围、回调地址这三样导不出来，等于换平台时要重做一遍治理。
  • 抽样核对。条数一致只是最外层，还要做关键字段非空率比对，以及随机抽若干条与线上逐字段对照。
  • 拿一套干净环境真恢复一次。导出的东西在别处打不开，就叫备份失败，不叫备份完成。

接口调用那一类依赖要在窗口内补兜底，重点是错误语义必须可区分。“暂时不可用”与“永久下线”混在一起返回，客户端就会对一个已经不存在的东西持续重试，把配额和耐心一起耗光。做法分三层：调用侧设短超时与有限重试，熔断后停止发起；我方网关层把上游错误翻译成带原因码的稳定语义，原因码进监控而不只进日志；对用户的提示文案分开写，一种是稍后再试，一种是该能力已停止并给出替代路径。

客户端缓存还有一个坑：停服后本地缓存仍会命中，用户看到旧内容却以为在查新数据。缓存要有有效期上限，超期后宁可显示空态并标明来源已停用，也不能让陈旧数据继续冒充实时结果。

五、分发链路断掉之后的对外口径

对外的说明要回答三件事，缺一不可：哪里还能找到、旧链接怎么处理、多久算一个下线周期。

措辞上有几条纪律。不写“因业务调整给您带来的不便敬请谅解”这类把商业决定说成天灾的句子；更不写“请用户自行备份数据”，导出与迁移是使用期内服务方承担的义务，把它转嫁给终端用户既不合情理也不合合同逻辑。在没有核实之前，也不要写“未影响任何数据”。

推荐的四段式：事实（哪个服务将停止、影响到哪些具体功能）、影响（哪些入口会失效、哪些历史内容不再可访问）、已采取（替代入口、过渡页、恢复或重做的范围）、待确认（尚未定下来的事项挂在哪个前提上）。“待确认”这一栏要留着，四项全写满反而显得不可信。

旧链接不要直接给 404，要留过渡页，页面写清替代入口和重定向保留的上限周期。下线周期建议按一个完整业务周期定义，例如覆盖一个报表或结算周期，让使用方至少有一次能拿新旧两侧数据互相对照的机会。对照不上时还能找回来解释，窗口过了就只能猜。

六、核心交付物之二：窗口内的动作顺序与合同收口

顺序错了，同样的动作会做得更累。我们建议按六个阶段走，每阶段有明确完成判据和一个签字的人。

阶段 动作 完成判据 责任人
冻结新增依赖 新功能不再建在该平台，新接入一律经我方抽象层 新增依赖登记数归零 架构负责人
导出与恢复演练 五类内容按第四节判据导出并在干净环境恢复一次 恢复演练通过记录归档 数据负责人
观测搬家 告警规则、指标定义、查询语句在自有观测栈重建 注入一次故障能被新告警捕获 运维负责人
灰度切断调用 按流量比例先内部后外部逐项摘除 全链路在一个周期内无上游调用 服务负责人
对外告知 过渡页、替代入口、四段式说明上线 旧链接全部有确定去向 产品负责人
清理与归档 吊销密钥与令牌、清缓存、注销回调、归档工单 无残留凭据仍然有效 安全负责人

前两步的顺序不能换：先把新增依赖冻结住，否则一边拆一边建，窗口永远不够。观测搬家要排在切断调用之前，是为了切断之后仍然看得见；摘除动作没有可观测性支撑就是盲切。

顺带说一句免费平台的退出成本，它常常反而更高：没有合同就没有导出格式与协助义务的依据，多数免费层根本不开放批量导出接口，也没有迁移支持渠道。省下的采购费会在窗口期内以工程加班和临时决策的形式还回来，而那时候的决策质量最差。

对客合同的收口条款要具体到能执行：约定的导出格式与字段范围、导出接口的可用性与速率下限、停服通知期下限、终止后协助义务的期限与内容边界、涉及第三方渠道变更时的告知义务、以及数据删除后的可核验证明。只写“提供数据导出功能”这一句没有约束力，写清导出到什么粒度才有。

这两张表在洹拓的上线评审里是固定门禁项：任何新接入的第三方平台，先填满五类依赖字段再谈接入。这次公告能学的一件事很朴素，能不能在窗口内做完，取决于平时有没有把依赖写成清单，而不是取决于公告给了多少时间。

#依赖盘点 #供应商停服 #数据导出 #迁移窗口 #对外口径