业务从一个基座大模型迁移到另一个（比如换到 GLM 系列），工程上要做哪些改造？

先这样答

第一关是接口适配。各家 API 的请求结构、参数命名、流式返回格式都不同，做法是加一层统一的模型网关，业务代码只面向自家抽象接口，网关里做各家的协议转换。工具调用协议的差异也要在这层消化：不同模型的函数定义格式、参数校验行为、并行调用支持都不同，网关统一成内部协议。

第二关是长度核算。token 数按各家分词器计算，同样的中文 prompt 在不同模型下 token 数可能差百分之几十，所有依赖「字符数估算 token」的截断逻辑都要换成目标模型的分词器实测。上下文窗口的计费口径也变了，成本模型要重算。

第三关是提示词重写。提示词是强模型相关的：角色设定力度、few-shot 示例个数、思维链引导方式，换模型后原提示词的效果不能平移。第四关是输出对齐：JSON 输出的稳定性、拒绝回答的措辞、安全边界的位置都变了，下游解析的容错要重新校准。第五关是效果回归：上线前拿固定评测集跑新旧模型对比，覆盖典型任务和边界用例，任何指标明显下滑都要先修再切。

切换策略上用灰度双跑：新旧模型按流量比例并行，对比线上质量指标，稳定后再全量。回滚预案要在网关层保留旧模型的直通开关。

面试官会怎么追问

• 「为什么提示词不能直接复用？」 模型对指令的敏感度不同，同样的提示词在 A 模型上触发格式化输出，在 B 模型上可能被忽略。迁移期的提示词要按目标模型的特性重调，这个工作量常被低估。
• 「工具调用协议差异具体指什么？」 函数 schema 的字段要求、参数缺失时的行为、多工具选择的表达方式、调用结果回传的格式。Agent 框架如果没有适配层，这些差异会散落到每个业务调用点。
• 「怎么证明迁移是划算的？」 三本账：成本账，同任务 token 单价乘用量；质量账，评测集得分和线上人工抽检；能力账，新模型带来的新功能空间。只看单价降了就迁移，质量滑坡会吃掉全部收益。

回答的坑

• 把迁移说成「改个 base URL」。五个环节里最贵的恰恰是提示词和输出对齐的回归验证。
• 不做双跑灰度直接切。模型行为差异造成的线上事故往往发生在长尾用例上，小流量对比才能提前暴露。