模型升级最怕的不是回复质量下降，而是那些“静默失效”的行为变更。

很多同事在公司里给 AI Agent 换模型时，习惯性的操作就是改个模型名称，跑几个 case 看看回复是不是还像人话，没问题就直接合入主分支。这种“体感测试”风险极大，因为 Agent 最容易崩的地方不是对话，而是工具调用（Tool Call）。我之前踩过一个大坑：换模型后，Agent 依然能流畅地告诉用户“您的订阅已取消”，但后台的 cancel_subscription 函数压根没被触发。用户以为办好了，结果下个月又扣了钱，投诉直接爆掉。

为了避免这种低级错误，我现在在团队里推行一套 20 分钟的“模型迁移对照检查法”，用实测数据代替体感。

一、 建立行为基准线（Baseline）

在动任何代码之前，必须先记录当前模型的真实行为。因为一旦模型切换，旧的行为模式就彻底消失了。

我们可以利用代理工具记录 Agent 的所有请求和响应。重点是：必须选择那些需要“做事”的场景（比如调用 API、修改数据库），纯聊天场景基本没法测出问题。

# 启动记录代理，将结果输出到 baseline.jsonl
npx whatbroke-cli record --out baseline.jsonl

为了排除大模型随机性带来的干扰，每个关键场景我要求跑 3 遍，并给每组运行标记名称（如 refund-flow#1, refund-flow#2）。如果某个行为在 3 次中只出现 1 次，那可能是随机波动；如果 3 次全挂，那就是实锤的回归问题。

配置 SDK 指向本地代理：

# OpenAI SDK 配置
OPENAI_BASE_URL=http://127.0.0.1:4141/v1 

# Anthropic SDK 配置
ANTHROPIC_BASE_URL=http://127.0.0.1:4141

二、 纯净切换与二次记录

这里有个细节：一次只改一个变量。

只修改模型字符串，不要在这个时候顺便优化 Prompt。如果你同时改了模型和提示词，最后发现工具调用参数偏移了，你根本分不清是新模型不听话，还是你的新 Prompt 把它带跑偏了。

切换完后，重复第一步的记录过程：

npx whatbroke-cli record --out swapped.jsonl

三、 深度 Diff 分析

有了两份 jsonl 文件，就可以进行量化对比了：

npx whatbroke-cli diff baseline.jsonl swapped.jsonl

分析结果时，我会按优先级排序：

• Breaking（破坏性变更）： 比如原本该调用的工具没调，或者直接报错。只要出现一项，这个模型版本绝对不能上线。
• Changed（行为偏移）： 这是最阴险的。工具调了，但参数变了（比如金额的小数点丢失，或者日期格式从 YYYY-MM-DD 变成了 MM/DD/YYYY）。这类问题必须人工逐一核对。
• 性能指标： 关注延迟（Latency）和成本（Cost）。默认情况下，如果延迟增加超过 1.5 倍或成本增加 25%，系统会直接预警。

四、 将检查集成到 CI 流水线

为了防止以后又有同事凭感觉换模型，我把这个步骤直接塞进了 CI 流程。只要出现 Breaking 级别的变更，Pipeline 直接挂掉，禁止 Merge。

# 在 CI 中运行，若有破坏性变更则退出码为 1
npx whatbroke-cli diff baseline.jsonl current.jsonl --fail-on breaking

如果之前没做基准线记录，但公司内部用了 Langfuse 或 LangSmith 这种能记录 Trace 的工具，其实也可以通过导出上周和本周的 Trace 数据来补课：

npx whatbroke-cli import last-week-export.json --run baseline
npx whatbroke-cli import this-week-export.json --run swapped
npx whatbroke-cli diff last-week-export.whatbroke.jsonl this-week-export.whatbroke.jsonl

这种方法的本质就是把 AI Agent 的测试从“文学评论”变成了“单元测试”。对于在公司里负责落地的开发者来说，能拿出的 Diff 报告比说“我觉得这个模型更好”要有说服力得多。