当企业 AI 从一次性问答进入持续处理工单、材料和经营任务，供应商切换的对象就变成一整条业务链。接口能返回文字，只证明接入成功；业务能否接续、既有结果能否解释、退出需要多少人天，才决定企业是否拥有实际选择权。本文讨论长期有效的迁移准备方法，不把旧资料包装成新事件；文中算例为构造假设，不代表壹典项目或市场报价。
接口变得相似，迁移责任仍留在应用侧
截至2026年10月18日查阅，Anthropic的兼容层文档将response_format和工具strict标为忽略；其原生接口另有结构化输出能力。[1] 这是一条具体接入路径的限制，不能推成“该模型不能输出结构化结果”，却足以提醒团队：请求被接受，不表示传入的约束全部生效。
Google的Gemini兼容文档也保留通过extra_body传递专属能力的方式。[2] 因而相同SDK之下仍可能存在不同参数、响应处理和能力边界。企业应按正在使用的模型、接口及版本核实，不能凭“兼容”二字批准所有业务。
已有的企业大模型升级与业务回归方法回答新方案是否更适合现有任务。供应商切换还要追问：停用旧端点后，谁提供文件、历史状态和失败证据？本文的新增重点是把这些退出依赖变成可交付、可演练的工程资产，而非重复模型排名比较。
先做依赖清单，找出真正需要带走的资产
建议从一条已在运行的任务反向画出依赖：业务输入从哪里来，提示和工具定义存在哪里，文件是否只剩供应商标识，结果引用能否回到原始材料，未完成任务依靠什么状态继续。每项记录业务所有者、当前保存位置、导出方式、重建方式、所需权限与估计耗时。不要只列模型名称。
把资产分为可直接携带、需要转换、只能重建和不能迁移四类。例如自有提示模板可以版本化导出；供应商文件ID应映射到自有业务文档ID及获准保存的原文件；托管索引可能需要重建。分类取决于实际接口与数据许可，不能先假定所有服务都提供完整导出。
业务状态应记录已确认输入、授权范围、已完成工具动作、结果凭据和下一步待办。模型内部的不透明状态不宜被假设为通用格式。若新模型无法接续原过程，应从明确的业务检查点重新开始或转人工；不能把重做已执行动作当作无害的会话重放。
只保留供应商会话ID而没有业务检查点，会让切换变成状态重构；无差别复制全部日志则可能增加数据暴露。保留支持恢复与解释的必要信息，并明确保留期限、访问控制和删除传播。迁移准备与数据最小化需要同时设计。
统一必需契约，给专属能力留下明确边界
不必为了可迁移性抹平所有供应商特色。可把稳定业务契约留在应用侧：输入材料、允许的工具、业务输出字段、引用证据、人工接管条件和成本上限；把消息格式、流式事件和专属参数放在独立适配器中。某项原生能力确实带来价值，可以使用，但要标记它的替代路径和重建代价。
LiteLLM文档说明，不支持的通用参数默认会触发异常，也可以配置为丢弃这些参数。[3] 这是框架行为，不是质量保证。本文建议迁移验收期间对关键约束采取明确失败策略：发现无法执行的要求就阻断，而不是为了让演示跑通而静默删除。
给每条任务标记最低可接受能力。例如材料抽取需要字段校验和证据定位；普通摘要可以允许不同措辞；对外执行必须保留授权与结果对账。若候选供应商无法满足必需契约，可以缩小切换范围。保留有价值的专属能力，与承认某些任务暂不可迁移，并不矛盾。
退出演练必须能在旧服务不可用时完成
准备一个隔离演练环境，使用获准的脱敏或构造材料，并冻结输入、输出验收规则及适配器版本。先验证迁移包能恢复新请求，再验证未完成任务。演练环境禁用旧供应商端点，或者在访问策略中明确拒绝它；否则隐藏的旧文件下载和会话读取可能让“迁移成功”失真。这不要求在生产环境停用正常服务。
至少覆盖三种状态：尚未执行动作的新任务、已经得到工具结果但尚未形成答案的任务，以及外部动作结果未知的任务。第二类应复用可核对的结果凭据；第三类应先查询外部系统并对账，无法确定就转人工。切换模型不会撤销已经发生的订单、消息或写入。
验收分别记录业务结果是否合格、迁移资产是否完整、恢复用时、人工操作步骤和仍依赖旧服务的项目。导入成功率与业务通过率不能合并：全部文件导入，也可能丢失文档版本或引用关系。失败样本应保留原因与修复负责人，不能只提交一段顺利完成的演示录像。
业务回归可以复用既有任务集，但退出演练额外检查：没有原集成人员临场解释，另一名有授权的工程师能否按清单完成迁移。只有某个人知道隐藏配置，是人员依赖；有导出按钮但没有重建脚本，是交付依赖。它们都应计入准备程度。
用迁移总成本判断，避免只比较调用单价
建议把费用分成一次性迁移、切换期间双轨运行，以及迁移后的持续运营三部分。一次性费用包括适配、数据转换、评估和人工验收；双轨费用包括两边调用与必要的额外复核；持续费用包括新方案调用、适配器维护、状态存储及新增人工。已有必要成本不应被重复计算。
构造一个纯算术例子：旧方案每月调用支出3万元，新方案2万元；迁移一次性投入12万元，新增维护与复核每月4000元。忽略其他差异时，每月净节省6000元，简单回收期为20个月。若可预见使用期只有12个月，累计节省7.2万元，尚未覆盖迁移投入。这些数值不是供应商报价，也不是财务收益预测。
若切换是为了消除无法接受的服务依赖，不能仅因回收期长而否决；应另列需要避免的业务中断和能力缺口，承认其发生概率可能未知。反过来，不能随意填入巨额停机损失，把任何迁移都算成值得。把省钱理由与连续性理由分别呈现，决策才可复核。
可迁移性本身也有维护费。长期双供应商运行需要持续复测和权限管理；低频、人工复核的辅助任务，可能只需可导出的配置和定期重建演练。高后果或恢复时限很短的任务，才更需要预先验证可用容量与完整备用路径。
采购和交付应验收迁移包，而不只验收承诺
建议把迁移包列入技术交付清单：版本化提示及工具契约、业务文档与供应商标识映射、必要状态与结果凭据、重建步骤、已知不可迁移项，以及一次退出演练记录。交付物应采用团队能读取和维护的格式；拥有文件并不等于拥有解释这些文件的能力。
采购讨论可以具体到三个问题：解除旧服务依赖需要哪些外部配合，相关数据如何获得和删除，以及谁承担重建与验收。任何导出能力、服务期限或迁移支持，都应以实际产品、书面约定和演示证据确认。本文提供工程验收方法，不替代具体合同审核。
先选择一条范围清晰、可人工接管的任务做演练，测出真实工时，再决定是否扩大。最终决策单写明已验证范围、不可迁移资产、预计恢复时间的依据、持续维护责任及再次演练条件。企业需要的是可执行的选择权，而不是接口列表上越来越多的模型名称。