提示词或模型变更后如何保障行为一致性

代码回归测试依赖「固定输入、固定正确输出、差异即问题」的逻辑，但这套逻辑在 Agent 场景下会失效。Agent 的两次正确回答几乎不会完全相同，用黄金答案做文本比对只会产生大量误报。真正保持稳定的是结构性行为：Agent 是否调用了正确的工具、传入了正确的参数、遵守了业务策略、在信息缺失时主动询问。这是回归测试需要捕捉的信号，而非输出文本本身。

模型本身是一个会移动的变量。当你通过别名（如 ~author/family-latest）引用模型时，底层版本可能在没有任何代码提交的情况下悄然更新，而做出大部分推理决策的恰恰是这个部分。OpenRouter 在每次响应中都会返回实际服务该请求的具体模型标识符，读取这个字段是发现「回答你请求的模型已不再是你测试过的那个」的最低成本方式。

需要触发回归测试的变更分为三类。第一类是提示词改动，可能影响语气、详细程度以及 Agent 优先调用哪个工具；第二类是模型切换或别名背后的版本升级，可能影响策略遵从度、工具参数准确性和拒绝行为；第三类是工具定义、检索设置或对话历史长度的变化，这类变更最容易被忽视——新的文档分块策略或工具响应中新增的字段，都可能把 Agent 原本依赖的内容推出其可见范围，而错误表现往往不是报错，而是 Agent 开始凭记忆复述本应精确引用的内容。

用例集的构建应在考虑自动化之前完成，且一旦建立就应视为锁定状态。一个合理的用例集应包含高频请求的代表性案例、边界情况（如输入模糊或请求处于策略边界），以及至少一个专门测试绝对禁止行为的案例。对于客服 Agent，这意味着需要覆盖常规退款、无订单号的请求，以及超出策略上限的退款请求。随意增删或改写用例会破坏与历史运行的可比性，让你无法区分真实的回归问题和测试本身的变化。

行为契约分为两层。结构性断言描述 Agent 应该做什么，例如在执行操作前先调用 lookup_order、在处理常规退款时不触发 escalate_to_human。硬性不变量描述 Agent 绝对不能做什么，例如在没有人工介入的情况下批准超过 500 美元的退款——这个数字来自具体的业务规则，而非平台设定。大多数用例只需要结构性断言；硬性不变量则应作为自动阻断发布的触发条件，不设阈值，不留判断空间。在执行测试时，应使用具体的模型标识符而非别名，并避免设置 max_tokens 限制，因为截断响应可能切断工具调用的 JSON，产生与 Agent 决策无关的虚假失败。

在模型切换场景下，正确的做法是保持提示词、工具定义、用例集、评判标准和推理参数完全不变，仅替换模型标识符，然后对基线模型和候选模型分别运行完整套件。阅读结果时应先看基线列：如果某个用例在两侧都失败，说明测试本身有问题；如果硬性不变量仅在候选模型上被违反，则应阻止该版本上线。Ori Eval 等工具支持 run.tool('escalate_to_human').toBeCalled() 这样的工具调用断言，以及针对开放式回答的 LLM 评判，可以将上述流程系统化落地。

要点

• Agent 回归测试的核心不是比对输出文本，而是验证结构性行为：工具调用顺序、参数准确性和策略遵从度
• 必须使用具体的模型版本标识符而非自动解析的别名，否则模型可能在无任何代码变更的情况下悄然升级，导致测试结果不可复现
• 用例集一旦锁定就不应随意修改，每次改写都会破坏与历史运行的可比性，使真实回归问题难以识别
• 行为契约分两层：结构性断言描述期望行为，硬性不变量描述绝对禁止行为，后者应直接触发发布阻断
• 工具定义、检索设置或对话历史长度的变更同样需要触发回归测试，这类变更最容易被忽视但同样会导致行为漂移