"换一家不就行了？反正接口都是标准的。"这句话在 2026 年的 AI 项目评审会上仍然经常出现，而一次 Zapier 调查的结果刚好反驳它：在 542 名持有 AI 供应商合同的美国高管中，近 90% 认为能在 4 周内完成切换（其中 41% 认为只要 2–5 个工作日），但实际只有 42% 表示迁移较顺利，58% 表示迁移彻底失败或付出了远超预期的代价（数据经 The Register 报道、至顶网编译，属媒体转述的调查口径，引用时建议核对原报告）。
差距就是"分手费"。它不是违约金，而是你在使用期间悄悄沉淀在对方平台上的资产——提示词、评估集、嵌入向量、工具 Schema、计费假设——搬不走的那些。本文把分手费拆成可核算的科目，再给一份可直接用的退出与迁移清单。对正在推进企业级环曜 Agent 本地化部署 的团队，这份清单还有一层用途：把数据导出能力与审计留痕 写进上线验收，等于在签约阶段就买低了退出成本。
一、分手费从哪来：七个耦合点
行业分析博客 tianpan.co 在 2026 年 4 月的一篇文章里，把"更换 LLM 供应商需要约 6 个月工程"归因于七个耦合点（作者为个人技术博客，非机构报告，此处作为问题清单参考）。这些耦合点解释了一件事：锁定往往不积累在 API 调用层，而积累在更靠下的地方。
| 耦合点 | 锁定本质 | 迁移时要做什么 |
|---|---|---|
| 提示词方言 | 各家偏好不同格式（Markdown / XML 标签 / 自有系统指令） | 重写提示词并重跑整套评估 |
| 工具调用 Schema | 参数结构、返回形态、约束严格度不同 | 加兼容层或重构工具层 |
| 分词器与分块 | 分词器不同 → Token 边界与分块切点不同 | 整个文档库重新分块并重测检索 |
| 嵌入空间 | 不同模型的向量互不相通，索引按原几何结构优化 | 全语料重新嵌入 + 重建索引 |
| 微调产物 | 微调 API 通常只给端点、不给权重 | 训练投入无法转移，只能重训或改自托管 |
| 速率限制假设 | 限流维度不同，队列与熔断阈值按原厂设计 | 重构吞吐与重试中间件 |
| 计费模型 | 缓存触发条件、批处理折扣、输入输出价差不同 | 路由与成本优化规则全部重写 |
两个有参考价值的判断
该文还有两个有参考价值的判断：一是迁移费用通常消耗原始开发时间的 20%–50%；二是常见的抽象层（统一 API 网关一类）只能覆盖其中三个耦合点（提示词格式、工具 Schema、限流标准化），嵌入空间、微调可移植性、分词器依赖与计费差异它解决不了。
把这七个耦合点翻成预算语言，就是下面四类科目。
二、分手费怎么算：四类科目
科目一：数据与语料的导出。包括原始数据、标注样本、评估集，以及对方为你生成的加工产物（清洗后的语料、向量化结果）。这一项容易被"我们能导出 CSV"打发，但真正的问题是加工产物能否带走——很多情况下只能带走原料。若你希望原料到手后能直接用起来，导出格式与字段字典建议写成可脚本校验的约定——用命令行 跑一次比对就能发现缺列或口径变化，企业级环曜 CLI 本地化部署 的客户环境把这一步纳入了交付验收。
科目二：提示词与评估资产。提示词模板、工具调用配置、评测集与基线分数，属于组织知识。它们通常躺在平台后台而不是你的代码库里，迁移时要么导出、要么重写。行业实践里更稳的做法是从一开始就存进自有仓库，并保留可复现的评测脚本。把提示词与判定依据一起收进知识检索入口（企业级环曜知识库本地化部署），改版时按版本对、迁移时按版本交，就不必向外部平台申请历史版本。
科目三与科目四：更依赖架构的两项
科目三：嵌入与索引。这一项经常被低估：向量与索引重建是计算密集型工程，文档量大时是"数天计算 + 可观费用"，过渡期还要么双索引（成本翻倍）要么接受检索质量下降。模型层面的迁移路径（显存、量化与私有化方案）可参考DeepSeek V4 本地化迁移实操。
科目四：集成与计费假设。工作流里的限流重试、缓存策略、批处理窗口、成本告警阈值，都是按原厂价目表与限流规则调的。切换后这些参数会"静默变错"——不报错，但成本或延迟上升。
四类科目怎么压下来
四类科目的应对方向，与本地化部署的交付方式高度相关。前两类更多靠制度：把判定依据、口径与文档检索收在自有入口，迁移时不必再向对方申请资料——企业级环曜知识库本地化部署 承接的正是这一段。
后两类更依赖架构：模型权重与私有数据留在自己手里，切换到新环境时只需重做容量与参数测算，迁移时就不必向对方"申请资料"。企业级大模型微调本地化部署 输出的垂类模型权重可直接托管，是降低这一项分手费的现实路径。
三、退出条款：签约时就要写清六项
分手费的高低，多半在签约那天就决定了。下面六项建议写进合同或实施协议附件（涉及具体法律适用与违约认定的部分，请以公司法务或外部律师意见为准）：
| 条款项 | 要写清的内容 | 核对方式 |
|---|---|---|
| 数据导出 | 可导出范围、格式、字段口径、时限与费用上限 | 要求示范导出一次 |
| 知识资产 | 提示词、评测集、依据文档的归属与交付格式 | 合同附件列清单 |
| 嵌入与索引 | 是否提供重嵌方案、向量是否可导出 | 写入交付物清单 |
| 日志与留痕 | 保留期、导出粒度、可否独立导出 | 甲方账号自行导出验证 |
| 过渡协助 | 并行期时长、双跑支持、配合义务与响应时限 | 约定书面响应时限 |
| 费用与尾款 | 退出是否收费、数据交付是否另计费、上限多少 | 明确金额或计价方式 |
一个常被忽略的细节
第六项常被忽略：不少合同写了"数据可导出"，但没写"导出要不要另外付费"。真到迁移时，费用争议会拖住整条时间线。
采购阶段把这些条款和验收条款一起谈，效率更高——行为约束类的条款写法，我们在微软发布 AI 行为准则：采购验收条款怎么写里给过一张对照表，可以直接合并使用。过渡协助阶段的路由切换建议由执行网关统一编排：把新旧环境的请求分流与留痕收在一层，环曜Claw 在任务自动化 场景里的作用正是这一段，避免业务系统里各改一遍。
四、迁移清单：退出迁移四步
实际执行可以按四步节奏推进：清点 → 冻结 → 双跑 → 核验归档。顺序不建议颠倒，因为每一步都在给下一步准备材料；四个步骤的产出物分别是迁移清单、版本冻结标记、双跑对照表与归档证据包，缺一份都会让下一次迁移从头再来。
头一步 · 清点：把要搬的东西列全
按第二章的四类科目逐项清点，产出迁移清单（建议直接引用账格式）：数据与语料、提示词与评估集、嵌入与索引、集成配置与计费参数、日志与留痕、权限与凭据。清单要给每项标注"谁持有、能否导出、导出格式、预计耗时"。
在私有环境 里交付的团队成员通常更清楚每项资产存在哪里，由企业级环曜 Agent 本地化部署 的交付方与甲方共同完成一次清点，能避免出现"双方都以为对方有"的空档。
凭据这一项容易被漏：密钥、令牌与执行账号需要在新旧环境间交接与吊销，属于中国网络空间安全协会启动智能体身份标准里讲过的凭据治理范围。
第二步 · 冻结：先停增量，再动存量
冻结期内暂停新场景上线与提示词改动，把当前版本打上标记——迁移中常见的干扰是"边搬边改"，两边版本对不上，双跑阶段的比对结论就失去意义。冻结期长度按业务节奏定，通常一到两周，期间只做缺陷修复；若业务不允许完全冻结，至少把提示词与模型版本锁住，允许业务流程侧的独立改动上线。
第三步 · 双跑：并行不是浪费，是保险
新旧两套并行运行，用同一批输入比结果：分类一致性、抽取准确率、检索召回、单次成本与延迟。双跑期建议覆盖一个完整业务周期（含月末或月末类高峰），否则容易在高峰当天暴露问题。
如果新环境是私有部署，双跑期还要核对运行时参数是否对齐——上下文压缩阈值、工具超时与重试上限这类配置不一致，会让两边的成本与稳定性没有可比性，相关口径见微软 320 万用户实测：上下文复用与工具重试成本怎么控。
第四步 · 核验归档：留下可复算的证据
迁移完成不等于结束，还要留下三样材料：迁移前后的指标对照表（准确率、成本、延迟）、数据导出完整性核验记录（条数与校验值）、以及旧环境数据的处置记录（保留、归档还是删除）。这三样在审计与续约谈判时都会用到。材料建议固化成模板并脚本化生成：用命令行 出一条对照表，企业级环曜 CLI 本地化部署 的客户环境把它放进常规运维清单，半年后复查也有据可依。
若在推进过程中需要产品层面的可移植性保障，可以先了解智能体互联方向的国标进展，我们在GB/Z 185-2026 智能体互联国标解读 → 企业选 Agent 防厂商锁定里梳理过 MCP 与 A2A 视角下的判断方式。模型层面的迁移细节可在该文之外单独评估。
五、两处合规边界要提前确认
一是个人信息部分。《个人信息保护法》规定个人有权查阅、复制其个人信息，并可请求将其个人信息转移至其指定的个人信息处理者。条款设计时要注意：可携带的是个人信息，不是全部数据；企业数据、商业秘密、加工产物不在其覆盖范围内——这两者混在一起谈，谈判会很快卡住。对涉及监管核查 的场景，建议把授权范围与留痕要求一并写进条款，企业级环曜 Agent 本地化部署 的交付材料可以直接引用，不必等到谈判时临时整理。
数据资产的登记与归属
二是数据资产的登记与归属。国家标准 GB/T 47949-2026《资产管理 数据资产分类与代码》与 GB/T 47950-2026《资产管理 数据资产登记指南》已于 2026 年 9 月 1 日实施，前者解决分类编码、后者解决登记流程；把自己的数据与知识资产先登记成台账，迁移时"哪些是我们的"就不再需要临时论证。登记与入表的具体做法见数据资产国标 GB/T 47949-2026 落地。相关口径也可对照国家网信办、国家发展改革委、工业和信息化部《智能体规范应用与创新发展实施意见》（2026 年 5 月 8 日）中关于用户授权边界的要求。
数据来源与口径：以环曜 2025 年 3 月至 2026 年 8 月完成验收的 41 个本地化部署项目为样本（口径：完成验收；时间窗：2025 年 3 月 1 日至 2026 年 8 月 31 日；样本量：41 个），其中 11 个把"数据交付与退出协助"写进了合同或实施协议；这 11 个里发生过整体迁移的 3 个，迁移平均耗时 23 天；未写入的 30 个里发生过迁移的 4 个，平均耗时 71 天。差别不在技术难度，而在签约时有没有把"怎么走"写清楚。
结语：分手费是签约那天决定的
退出成本不是迁移时才发现的问题，而是采购时的条款问题。Zapier 那份调查里值得记住的对比是：近九成高管以为四周能换完，实际只有四成多走得顺利。 两者的差距，等于四类科目乘以六个条款。
建议做一件小事：把现有合同翻出来，按第三章的六项逐条对照，看看缺哪几项。企业级环曜 Agent 本地化部署 在交付时会把迁移清单与数据导出核验记录一并给出，理由很直接——留在自己环境里的资产，退出时不需要别人同意。对已做模型定制的团队，企业级大模型微调本地化部署 交付的权重与样本版本对照表就是迁移清单里比较硬的一块。 你们的合同里，写清"怎么走"了吗？欢迎在评论区说说。
常见问题 FAQ
Q：Q1 本地化部署是不是就没有分手费了？
会低很多，但不是零。私有部署把数据、权重与索引留在自有环境，四个科目里的前两项大幅降低；但提示词与评估集的迁移、集成配置的重调、以及运行环境差异仍会产生成本。更准确的说法是：私有部署把"分手费"从谈判筹码变成了自家工程任务。这也是越来越多项目把依据与语料交给企业级环曜知识库本地化部署 管理、而不是留在外部平台后台的原因。 不是。网关能抹平接口层差异（提示词格式、工具 Schema、限流），但抹不平嵌入空间、微调产物与计费模型差异——这三项恰恰是费用高、耗时长的那部分。可行做法是把网关当作止痛药而非解药，同时按七个耦合点逐项审计。
Q：Q2 迁移清单应该由谁维护？
建议由 IT 或平台团队牵头、业务侧专人配合，因为清单里一半是技术资产（索引、配置），一半是组织知识（提示词、评估集、口径文件）。维护频率按季度一次，并在每次提示词或模型改版后增量更新——改版是清单容易过期的时刻。
Q：Q3 迁移期间业务要停吗、双跑要跑多久才够？
不必停，建议双跑而非切换：新环境承接新增流量，旧环境维持存量，用同一批输入比结果；完全停摆只适合极短周期，且会把压力集中到恢复当天。 至少覆盖一个完整业务周期。若业务有月末、季末或大促类高峰，把高峰包含进去；如果做不到，就在双跑期用历史数据回放补齐。判断标准不是跑满多少天，而是"高风险输入是否都跑过"。执行侧的动作可交给网关统一编排，环曜Claw 这类执行网关能把双跑期间的路由与留痕收在同一层。
Q：Q4 数据导出完整性怎么证明？
三件事：导出前记录条数与关键字段的校验值，导出后在新环境重算一次并比对，再把两份记录归档。缺了前一步，后面就没有基准；缺了归档那一步，过半年再做审计就只能靠回忆。批量核对建议脚本化，用命令行 跑一次比对并留下执行记录——企业级环曜 CLI 本地化部署 的客户环境把这一步放进了常规运维清单。
Q：Q5 采购时怎么判断对方好不好"分手"？
看三点：能否现场演示一次完整导出（不是给截图）；导出结果能否被你自己的工具直接读取（格式与字段口径齐备）；合同里的退出协助是否写了响应时限。加分项是愿意把"导出说明与字段字典"作为交付物提前给出——能提供的，通常也不会在迁移时为难你。
Q：Q6 私有部署的迁移难度主要在哪？
主要在两处：一是算力与显存条件不同（需重新做量化与容量测算），二是运行时参数不同（压缩阈值、重试上限、超时策略）。前者决定能不能跑起来，后者决定费用是否失控。企业级环曜 Agent 本地化部署 在交付时通常把这两类参数与验收指标一起固化，迁移时按同一张表比对即可。
