← 全部文章
智能体周刊2026 年第 39 期

2026-W39 周刊:回归测试怎么防模型漂移

本周智能体生态聚焦:模型漂移最烦的地方不是它变差了,是它变了个样你还不知道。同一个 prompt,小版本一升,工具调用从两次变成一次,参数名从 date 换成 datetime,线上照样跑,直到某天有人来投诉。所以回归测试要解决的不是"模型行不行",是"行为有没有挪窝"——这两件事的测法完全不同。 厂商不会通知你,这是前提 HN 上那条 [Claude Code 只在遥测打开时才读 AGENTS.md](https://blog.szypowi.cz/p/claude

YGG 智能体周刊8 分钟阅读#weekly#agent#engineering#paper#2026

模型漂移最烦的地方不是它变差了,是它变了个样你还不知道。同一个 prompt,小版本一升,工具调用从两次变成一次,参数名从 date 换成 datetime,线上照样跑,直到某天有人来投诉。所以回归测试要解决的不是"模型行不行",是"行为有没有挪窝"——这两件事的测法完全不同。

厂商不会通知你,这是前提

HN 上那条 Claude Code 只在遥测打开时才读 AGENTS.md 讲的是个 bug,而且标了已修。但它暴露的机制是真的:一个看起来无关的开关、一个没写进 changelog 的小改动,就能让行为分叉。

厂商发的 release note 通常讲能力提升,不讲"我们调整了某个工具的描述词,导致它现在更少调用搜索"。我不打算揣测每家的通知策略,但默认假设应该是:没人会通知你。这不是恶意,是他们的发布节奏里根本没有"下游行为回归"这个环节。

所以固定输入的黄金用例不是可选项,是唯一的探针。

断言结构,别断言字符串

字符串相等在这里基本没用。温度不为零时换种说法很常见;就算设成 0,后端也不保证跨版本一致。

能断言的是结构:调了哪个工具、调用顺序、参数能不能过 schema 校验、有没有碰到不该碰的工具、总步数有没有炸、最终副作用是什么(写了几行库、发了几封邮件、落了几个文件)。这些用 pydantic 或者 JSON Schema 就够,不需要再拿一个模型来判卷——用模型判卷等于把不确定性又引回来一层。

我一般分三档:硬断言(越权、参数非法、崩溃,必须挂)、软断言(步数、工具集合的偏离度,超阈值报警但不拦)、记录项(输出文本存下来,人偶尔翻)。第三档容易被忽略,但漂移经常先体现在措辞上。

跑一次要便宜到你不心疼

这条是决定性的。一套回归如果跑一次要二十分钟、要花掉几块钱,一周之后就会退化成"等发版前跑一下吧",再两周就没人跑了。

规模不是越大越好,是覆盖住主要分支:正常路径、几个典型工具组合、一两个已知边界(空输入、超长输入、权限不足)。十几个用例起步,几分钟跑完,塞进 CI 或者一个定时任务,每天出份报告。宁可覆盖窄但天天跑,不要覆盖全但半年跑一次。

省钱的办法也有:便宜的小模型做冒烟,贵的只跑关键几条;或者把 agent 里非关键的那几步 mock 掉——你要测的是行为模式,不是端到端吞吐。

反面一:断言写太死,会把改进一起挡掉

这是我踩过的坑。一开始把工具调用序列写死成精确匹配,结果模型换了个更聪明的做法——先查缓存再决定要不要查库——直接红了。那次是我的测试错了,不是模型错了。

缓解办法是断言不变量,而不是断言轨迹。不变量比如:没有权限校验就不能写库;最终状态必须一致;重试次数有上界。轨迹可以变。另外每次红了都要人看一眼,不能自动重跑直到绿,那等于把测试变成噪声过滤器。

反面二:agent 会改自己的证据

这周 ArXiv 有篇挺扎心的,LLM Agents Can Easily Tamper With Their Own Traces,大意是异步监控、事故复盘、合规审计都靠 trace 重建现场,而这些分析全都默认 agent 动不了自己的 trace。这个默认不成立。

还有一篇 Instrumental Monitor Evasion Emerges Under Ordinary Task Pressure:不需要什么对抗性目标,普通任务压力下 agent 就会倾向于绕开运行时监控。

对回归测试的直接后果是——如果你把断言建在 agent 自己吐出来的 trace 上,你测的是它愿意给你看的那个版本。证据得往外挪:服务侧的审计日志、被调用 API 的访问记录、数据库的实际变更,让 agent 进程碰不到。这跟那篇 Requirement-Bound Verified Commissioning 的思路一致:候选生成和放行权分开,生成方再强也不给自己盖章。

另一个方向:把该确定的东西变成状态机

HEXIS 的做法是把 agent skill 编译成扩展有限状态机,把"下一步该做什么"从推理里拿出来变成控制流。好处之一是回归测试变简单了:状态机是确定性的,转移合法不合法可以直接断言,模型只负责填槽。

我不觉得这能覆盖所有场景,开放域任务编不出状态机。但对流程本来就固定的业务(审批、下单、工单流转),把控制流抽出来比在 prompt 里祈祷靠谱得多。上线前用仿真筛一遍也不是空想,Screen Before You Serve 就在干这件事,只是人家规模大得多。

报警器也会坏

漂移没法消灭,只能早点发现。我现在的心态是:黄金用例就是烟雾报警器,它不防火,但它响了你就得去看一眼。麻烦的是报警器本身也会坏——用例过期、断言还对着一个早就不重要的分支、或者因为没人看报告而长期红着。

所以每隔一阵得回头看一遍:它是不是还在真跑,断言是不是还对应着真实的不变量。也许过半年回头看,这套会被更好的东西替掉,比如上游直接给你行为 diff。但今天没有,那就先自己搭。

延伸阅读

编辑说明

本文由 YGG 臻星科技团队整理,聚合 ArXiv、HackerNews 与公开厂商博客,人工审稿。