切换模型后，Prompt、工具和测试还能用吗？

模型换代的速度越来越快，但很多团队发现：代码一行没改，Agent 的行为却变了。原来稳定的工具调用开始静默失败，精心调校的 Prompt 在新模型上答非所问。这不是个别现象，而是所有依赖大模型构建产品的团队都要面对的系统性问题。

模型切换为什么会让 Agent 悄悄失灵

底层模型的替换不像升级一个数据库驱动那样有明确的兼容性契约。模型的输出分布、指令遵循风格、对工具调用格式的偏好，甚至对 system prompt 的"服从程度"，都可能在版本之间发生偏移。

一个在旧模型上经过反复调试的 prompt，可能依赖了该模型特定的措辞习惯。换模型后，同样的输入会触发不同的推理路径。更隐蔽的是工具调用——旧模型可能稳定输出某种 JSON 结构，新模型则倾向于多加一层解释性文本，导致解析器静默丢弃调用请求。

问题的核心在于：模型行为没有版本化的接口约定。API 签名不变，但语义变了。

什么是工具调用（Tool Calling / Function Calling）：在大模型 Agent 架构中，模型并不直接执行动作，而是根据用户意图生成一段结构化的调用请求（通常是 JSON），标明要调用哪个工具、传什么参数，再由外部运行时解析并真正执行。例如模型输出 {"tool": "search", "args": {"q": "天气"}}，程序据此调用搜索接口。由于这一过程依赖模型对既定 schema 的"自觉遵循"，而不同模型对格式的理解、对多字段结构的偏好各不相同，schema 本身并不构成强制约束——模型仍可能少输出字段、多加自然语言包裹或改写键名，从而让解析器静默失败。这正是文章所说"API 签名不变、语义变了"的具体体现。

什么是系统提示词（System Prompt）服从程度：System prompt 是位于对话最前端、用于设定角色、约束和行为边界的指令。不同模型对 system prompt 的"权重"处理并不一致：有的模型会严格遵循其格式和语气要求，有的则更倾向服从用户消息的即时意图，甚至在安全策略上覆盖 system prompt 的指示。因此同一个 system prompt 在模型换代后可能产生明显的"人格漂移"或约束失效，这是 Prompt 团队最难通过阅读文档预判的一类变化。

实践中先坏掉的通常是什么

社区讨论中反复出现的模式是：最先暴露的往往不是核心推理能力，而是边缘行为。

工具调用的参数格式偏移是最常见的"第一故障"——模型开始多输出或少输出字段，或者把原本结构化的调用包裹在自然语言里。其次是拒绝行为的变化：旧模型会执行的指令，新模型可能因为安全策略调整而拒答。第三类是语气和格式漂移，虽然不影响功能，但会破坏面向用户的输出一致性。

一个值得注意的现象是：这些故障很少在切换当天就被发现。它们通常要等到特定边缘 case 被用户触发后才暴露，此时排查成本已经很高。

测试策略：从"没有测试"到"行为回归"

大多数团队的现状是：没有专门针对 Agent 行为的自动化测试。发现问题的渠道往往是用户反馈或线上监控告警。

少数有测试实践的团队，做法集中在几个方向：维护一组"黄金输入-期望行为"对，每次模型切换时跑一遍；对工具调用做 schema 校验和端到端 smoke test；用 LLM-as-judge 对输出质量做回归对比。

但这些方案都有明显局限。行为测试的期望值难以精确定义——同一个问题，两个合理的回答可能措辞完全不同。LLM-as-judge 本身也依赖模型，存在版本耦合。

资产存放：Prompt、工具定义和测试该放一起吗

一个被反复提及的工程问题是：Prompt 模板、工具 schema、测试用例目前散落在不同地方——Prompt 在配置系统里，工具定义在代码仓库里，测试在另一个 pipeline 中。

这种分散导致模型切换时很难做完整的"影响面分析"。你不知道改一个模型会影响哪些 prompt，也不知道哪些测试覆盖了受影响的路径。

比较务实的做法是把这三者作为同一个"Agent 契约"来管理：版本化、同仓库、变更时联动审查。虽然不能完全消除模型行为漂移，但至少让影响范围可见。

什么是 Agent 契约（Agent Contract）：文章提到的"契约"并非正式的行业术语，而是一种工程隐喻，指把 prompt 模板、工具 schema 和测试用例视作一份共同约束 Agent 行为的隐式协议——三者相互依赖，任何一处改动都可能影响另外两处的有效性。将其同仓库、同版本号管理，核心价值在于可追溯性：当模型切换引发行为变化时，能快速定位受影响的 prompt 与覆盖该路径的测试，从而把"悄无声息的失灵"变成可枚举、可复查的清单。与之相对的常见做法是把 prompt 放在运行时配置中心（便于热更新）、工具定义随服务代码走、测试散落在 CI 流水线，这种解耦在模型稳定时高效，但在模型换代时会让影响面分析几乎无法进行。

人工流程与缺失的工具

在没有理想工具的情况下，一些团队靠人工流程兜底：模型升级前跑一遍核心场景的手动验收，对比新旧模型的输出差异，记录已知的行为变化。

但这个流程的问题很明显——不可扩展、容易遗漏、依赖个人经验。

社区里被反复呼唤的工具能力包括：模型行为的 diff 工具（类似代码 diff，但对比的是行为而非输出文本）；Prompt 兼容性检测；跨模型的工具调用格式一致性检查；以及能自动识别"这个 prompt 在新模型上是否还成立"的静态分析。

目前这些能力大多需要自建，没有成熟的通用方案。

判断 Agent 变差的标准

一个更根本的问题：你怎么知道 Agent 变差了？

如果没有明确的评估基准，模型切换后的"变好或变坏"只是主观感受。建立评估体系——哪怕是粗糙的——是管理模型切换风险的前提。这个体系至少要覆盖：任务完成率、工具调用成功率、输出格式合规率，以及针对业务关键场景的专项检查。

模型切换带来的不是一次性的迁移问题，而是持续的运维挑战。把 Prompt、工具、测试当作需要随模型一起演进的一等资产来管理，可能是目前最实际的起点。

背景补充

什么是 LLM-as-judge 及其版本耦合问题：LLM-as-judge 是一种用大模型充当裁判、对另一个模型输出打分或判优的评估范式，常用于难以用规则匹配衡量的开放性问题。典型做法是把"黄金答案"和"待评答案"一起交给裁判模型，让它输出分数或偏好。问题在于，裁判模型本身也会随版本更新，其评分标准、对措辞的宽容度可能发生偏移。当被评模型和裁判模型同时升级时，评估结果的变化究竟来自哪一方变得难以归因。更极端的情况是，如果裁判模型与被评模型来自同一家供应商或共享训练数据，还可能存在系统性偏好。因此实践中通常需要保留一个固定版本的裁判模型、配合人工抽检，并对关键场景维护带明确判定标准的规则化测试，以降低对单一模型判断的依赖。