结论：Evals 回答"它够不够好"，确定性测试回答"这条路对不对"。前者依赖真实模型的概率行为，后者通过替身（mock/录制回放）验证工程逻辑是否正确——两者互补，缺一不可。

一、为什么要"确定性"

你的 Agent 逻辑里有很多与模型能力无关的部分：工具调用链、参数拼装、状态流转、失败分支、格式解析。这些必须能稳定测试，不能每次都依赖真实模型的随机输出。否则一条失败分支可能永远测不到。

二、三种替身手段

用 Mock 可以精确构造"模型返回了畸形 JSON""工具超时"这类真实环境中难复现的场景。

三、要测什么

• 工具选择与参数拼装是否正确。

• 输出解析与校验是否健壮（畸形输入不崩）。

• 失败、重试、降级路径是否被正确触发。

• 状态在多轮之间是否正确传递。

• 上下文组装是否符合预期。

四、与 Evals 的边界

先保证确定性测试全绿，再谈 Evals 分数。 逻辑都错了，评测分数没有意义。

五、常见误区

• 只测理想路径，异常分支从不覆盖；测试依赖真实模型导致不稳定；替身与真实差异过大，测了等于没测；只做 Evals 不做确定性测试。

六、检查单

• [ ] 关键链路有确定性测试

• [ ] 覆盖异常与失败分支（畸形输出、超时）

• [ ] 工具依赖用桩隔离

• [ ] 录制回放保证链路一致

• [ ] 替身行为贴近真实，定期校准

• [ ] 每次提交自动跑

• [ ] 与 Evals 分工清晰，先绿后评