很多 AI agent 平台在早期都会默认选一家最顺手的模型、推理或基础设施供应商。开发效率高、能力足够强、文档也完整，这当然是合理选择。问题在于，一旦平台进入真实业务，供应商就不再只是技术依赖，还会变成价格依赖、合规依赖、地区依赖和事故依赖。供应商涨价、模型退市、区域服务受限、合同条款变化，甚至公司战略调整，都会突然把“以后再说的可迁移性”变成必须马上回答的问题。
平台在这个时刻最怕听到的一句话，就是“理论上可以迁，只是工程量会比较大”。因为这通常意味着平台从 prompt、路由、评估、审计到运行环境，已经在太多地方把供应商假设写死了。模型名字写进 prompt contract，错误语义绑在某家 API 返回上，成本和限流逻辑依赖某个计费模型，回放和审计字段只适配一套 provider metadata。看起来每一层都只是为了更快交付做的小优化，叠起来却会把 exit path 一点点封死。
所以 vendor portability 和 exit migration 真正要解决的，不是让平台永远不绑定任何供应商，而是让系统在不得不迁的时候，仍然拥有一条可执行而不是停留在架构图上的退出路径。没有 exit plan，多供应商往往只会停留在采购和 PPT 语义里。
建议配合 AI agent 模型路由与回退链设计、AI agent Version Set Pinning 与 Rollback、AI agent 多执行环境路由 和 AI agent Data Residency 与 Regional Placement 一起看。
真正难迁的，从来不只是模型 API，而是整套围着供应商长出来的判断环境
| 依赖层 | 表面上像什么 | 真正迁移时会卡住什么 |
|---|---|---|
| Prompt / contract | 模型名、token 上限、工具调用风格 | 迁走后行为边界和输出结构一起变化 |
| Runtime / routing | 某家 provider 的超时、重试、区域路由 | 新供应商的性能和可靠性假设不同 |
| Eval / quality | 旧供应商上的评分基线和回归阈值 | 迁移后无法判断质量是变好了还是变坏了 |
| Audit / billing | provider metadata、计费维度、trace 字段 | 旧账和新账接不上，复盘也难对齐 |
这也是为什么很多团队以为自己已经做了 abstraction layer，却仍然很难真正迁走。抽象层通常只抽掉了调用接口，没有抽掉周围那一圈真实依赖：质量阈值、成本模型、日志语义、回滚路径和客户承诺。
可迁移性最容易被高估的地方，是把“有备用路由”误当成“有退出计划”
平台确实可能已经支持多个 provider，也确实可能在低风险任务上做过 fallback。可这和能不能真的 exit 是两回事。因为真正的 exit migration 还要回答：
- 历史 session、审计记录和计费字段在新旧供应商之间怎么对齐
- 哪些任务类型可以先迁，哪些任务因为质量或合规原因必须最后迁
- 旧供应商下特有的 tool-calling、内容过滤或错误码语义怎么被替换
- 出现质量偏移时，是回滚整组环境，还是接受某类能力暂时退化
只要这些问题没有答案，所谓 portability 就更像运行时的弹性，而不是组织层面的退出能力。
一个很真实的事故：供应商没有完全宕机，但平台已经被商业和合规信号逼着迁走
某团队的 AI agent 平台原本主要依赖一家模型供应商，技术上也做了基础 fallback。后来这家供应商调整了地区可用性和计费条款，某些企业客户开始明确要求迁往本地区更稳、合同条款更清晰的替代方案。团队最初以为这只是改路由配置，结果一动才发现：
- prompt contract 里写死了某家 provider 的工具调用习惯
- 回归评估集和质量阈值都建立在旧模型输出风格上
- 审计系统依赖旧 provider 的 trace 字段解释异常行为
- 成本 reconciliation 也只会读旧账单语义
最后平台不是不能迁，而是必须先拆一整圈隐性耦合。真正让团队痛的，不是切流量本身，而是他们以为自己早就具备的 portability，其实只是接口级 portability，不是系统级 portability。
迁移时最稳的顺序，通常不是一口气切流，而是先做对齐，再做替换
更靠谱的 exit migration 往往分三步：
- 先建立跨供应商的质量、计费和审计对齐层，至少保证比较不是在拿苹果和橘子硬比。
- 在 version set 和路由层引入可追踪的迁移批次，让新供应商只进入明确的任务类型和租户范围。
- 把旧供应商能力一点点从 contract、monitoring 和 support runbook 中剥离，而不是只在调用层换地址。
这套顺序的关键不是更谨慎，而是让迁移始终可解释。因为对 AI agent 平台来说，客户不只会问“有没有切过去”，还会问“切过去之后为什么质量没变差、为什么账单还能对上、为什么审计还能看懂”。
如果你现在只能先补一层，先把 exit path 写成一张依赖图
平台今天最值得做的，不一定是立刻接第二家供应商，而是先诚实地画出 exit dependency map：哪些地方已经把供应商假设写死，哪些地方只能做到接口替换，哪些地方一迁就会影响质量、计费、日志或合规。只有把这张图画出来，团队才会知道 portability 到底差在哪一层。
AI agent 平台迟早会遇到供应商变化。真正能降低风险的，不是现在就假装自己已经完全无供应商依赖，而是确保当那个时刻真的来时，平台手上拿着的是可执行迁移路线，而不是一句“理论上可以”。
延伸阅读：
