Agent 测试与评估

把 deterministic tests、trace grading、dataset evals、shadow 和 canary 放在同一套 agent 质量体系里理解。

#type / synthesis #status / growing #tech / dev / test #tech / ai

[!info] related notes

Agent 测试与评估

范围

这篇笔记讨论的是 AI agent 的测试体系，而不是传统服务的单元测试。

为什么要把这些内容放在一起理解

agent 的风险不只是“代码错了”，还包括：

  • 路由漂移
  • 工具选择错误
  • prompt 改动后的行为漂移
  • guardrail 失效
  • 模型升级后质量波动

如果只靠人工聊一聊试一试，这类问题几乎无法稳定比较和回归。

agent 测试的五层

1. deterministic unit

这层最好尽量结构化，典型对象包括：

  • prompt rendering
  • tool schema
  • parser
  • policy filter
  • router output

如果 router / planner 输出可以被约束成严格 JSON，断言会比自然语言字符串稳定很多。

2. stubbed workflow tests

固定工具返回，验证：

  • 路由是否正确
  • 多步流程是否按预期推进
  • 失败分支是否被正确处理

这层比真实模型评估更快，也更适合高频运行。

3. trace grading

在 agent 调试期，最值钱的是看真实 trace：

  • 工具选择是否合理
  • handoff 是否正确
  • guardrail 是否触发
  • 哪里开始偏航

trace 让问题不再只体现在最终一句错误回复上。

4. dataset evals

当流程稳定后，就应该把代表性场景固化成数据集：

  • 输入
  • 上下文
  • 预期行为
  • graders / thresholds

这样每次改 prompts、models、tools、policies 时都能做版本对比。

5. shadow / canary

上线阶段还需要：

  • shadow traffic
  • 小流量 canary
  • prompt / model diff eval

因为很多非确定性问题只有在真实分布下才会暴露。

agent 测试和传统测试最大的不同

传统服务更强调编译、接口、状态和确定性输出；agent 还必须额外处理：

  • 非确定性
  • 数据分布变化
  • 模型版本变化
  • prompt 演化

所以 agent 的“测试”天然更接近“测试 + 评估 + 运行期观察”的组合。

evals 为什么必须版本化

如果 prompt、tool schema、grader、阈值和基线结果不版本化，团队就很难回答：

  • 这次行为为什么变了
  • 变好还是变坏
  • 回滚后为什么还回不到原来

这也是为什么 packages/evals 应该成为一等公民。

一个实用工作流

  1. 调试期先看 traces
  2. 把稳定问题收进 deterministic tests
  3. 把关键场景固化成 dataset evals
  4. 发布期做 shadow / canary
  5. 把生产反馈继续回流成新样本

最短记忆方式

agent 质量体系不是“多跑几次聊天”，而是 deterministic tests + traces + datasets + rollout checks 的组合。

参考资料

创建于 2026/4/23 更新于 2026/5/27