OpenRouter 发布 AI Agent 回归测试最佳实践：构建行为契约与锁定用例集
随着 AI Agent 从原型走向生产环境，如何在 Prompt 微调、模型切换或工具定义变更时确保系统稳定性，成为开发者面临的严峻挑战。OpenRouter 最新发布的《AI Agent Regression Testing After a Prompt or Model Change》一文，深入剖析了 Agent 回归测试的独特逻辑，并提供了一套可落地的工程化方案。
为什么 Agent 回归测试不同于代码？
传统代码回归测试依赖“已知输入”与“已知正确输出”，通过 Diff 比对差异。然而，Agent 的运作机制打破了这一前提：
- 答案的多样性：LLM 生成的文本即使行为正确，其措辞也千差万别，简单的文本 Diff 极易误报。
- 模型的动态性：使用
~author/family-latest等别名时，模型版本可能在运行时自动更新，导致推理能力的漂移。 - 基准的失效：一旦基准（Baseline）发生移动，之前的测试通过结果便失去了参考价值。
因此，Agent 回归测试的核心不在于“输出是否一致”，而在于结构是否合规与行为是否违背业务规则。
三大核心变更场景
OpenRouter 将需要回归测试的变更归纳为三类，并指出了各自的检测难点：
-
系统提示词（System Prompt）变更：
- 影响：语气、 verbosity（详细程度）、工具调用优先级。
- 检测：针对每个用例建立结构断言（Structural Assertion），验证 Agent 是否调用了正确的工具及参数。
-
模型切换（Model Swap）：
- 影响：推理逻辑、幻觉概率。
- 检测：必须固定 Prompt、工具定义和用例集，仅更换模型。关键在于使用具体模型标识（Concrete Slug）（如
anthropic/claude-fable-5.1）而非别名，以排除模型版本波动带来的干扰。
-
工具模式或检索设置变更（Tool Schema / Retrieval Settings）：
- 影响：Agent 可见的上下文窗口、检索到的文档片段。
- 检测：这是最容易被忽视的。新增的字段或检索策略可能导致 Agent 依赖的关键信息移出视野，使其从“引用政策”变为“凭记忆回答”，导致看似流畅但错误的输出。
构建锁定用例集与行为契约
OpenRouter 强调，自动化测试的前提是建立一套锁定（Locked）的用例集，并为其编写行为契约（Behavioral Contract）。
1. 锁定用例集
用例集应包含：
- 高频场景：覆盖 Agent 日常处理的主要请求类型。
- 边界案例：如模糊输入、处于政策边缘的请求。
- 规则测试用例：专门设计用于测试“绝不允许发生”的规则（例如：超过 $500 退款必须人工审核）。
原则：一旦用例集建立，严禁随意增删或重写。任何修改都会破坏与历史运行结果的可比性，使测试失效。
2. 编写行为契约
每个用例需定义两层约束：
- 结构断言：规定 Agent 必须执行的动作。例如：
run.tool('lookup_order').toBeCalled()。这确保了 Agent 按逻辑顺序操作。 - 硬性不变量（Hard Invariant）：规定 Agent 绝不能做什么。例如：“禁止在没有订单 ID 的情况下批准退款”。这是自动阻断发布的关键指标，不依赖阈值判断。
实战示例：Ori Eval 支持
OpenRouter 的 Ori Eval 框架支持此类工作流。开发者可以编写类似 run.tool('escalate_to_human').toBeCalled() 的结构化断言，并结合 LLM Judge 对开放性问题进行语义评估。通过对比基准（Baseline）与候选（Candidate）列，若候选在硬性不变量上失败，则直接阻断发布。
官方引言： "回归测试一个 Agent 意味着每次 Prompt、模型或工具定义变更时，重新运行一组锁定的用例，并将结果与书面化的行为契约进行比对。"
通过这套机制，开发者能够将 Agent 的稳定性从“感觉良好”转变为“有据可查”，有效应对模型迭代带来的不确定性。
