🧪 Agent 评估与测试
🎯 Agent 测试的独特挑战
Agent 的测试比传统软件测试复杂得多——Agent 的行为具有非确定性、输出形式多样（文本/工具调用/代码）、执行路径高度动态。传统的"输入→预期输出"单元测试模式在面对 Agent 时几乎完全失效。
⚠️ Agent测试的独特性
- 非确定性输出：同一个输入可能产生不同但都正确的回答，传统精确匹配断言失效
- 多模态输出：Agent 可能输出文本、函数调用、代码，需要多维度的验证策略
- 状态依赖性：测试结果受 Agent 历史对话和内部状态影响，难以创建独立、可重复的测试用例
- 工具调用副作用：Agent 的测试可能触发真实的 API 调用、数据库写入，需要隔离和 Mock 策略
- 评估主观性：答案的"好坏"往往是主观判断，需要结合自动评估和人工评审
- 时间变化性：同一个工具调用在不同时间返回不同结果（如搜索 API），测试需要适应这种变化
🧪 测试金字塔：Agent 版
传统软件测试的金字塔模型（单元→集成→端到端）需要针对 Agent 进行适配：
⚙️ 单元测试 (大量 · 快速)
测试 Agent 的最小可测单元——工具定义、Prompt 模板、输出解析器。
- 工具 Schema 验证：确保工具定义符合规范
- Prompt 模板测试：验证模板变量是否正确填充
- 输出解析器：测试 JSON/XML 解析逻辑
- Mock LLM 调用：用固定响应替代真实 LLM
- 运行频率：每次提交
🔗 集成测试 (中等 · 关键)
验证 Agent 与单个工具/服务的集成是否正常。
- 工具 Mock 环境：模拟外部 API 的响应
- 单步决策验证：给定上下文 + 工具列表，验证 Agent 选择正确的工具
- 错误处理：注入工具调用失败，验证 Agent 的容错行为
- 运行频率：每次 PR
🎯 端到端测试 (少量 · 关键)
使用真实 LLM 运行完整的 Agent 任务，评估端到端行为。
- 真实场景测试集：覆盖典型用户任务的测试用例
- LLM 评估 LLM：用更强的模型评估 Agent 的输出质量
- 完整工具链：使用真实或高保真 Mock 工具
- 运行频率：每日/每次发布前
📏 评估维度
Agent 的评估需要从多个维度综合考量，单一指标无法全面反映 Agent 的质量：
🎯 准确性 (Accuracy)
Agent 是否给出正确的答案或执行了正确的操作？
指标：任务完成率、答案准确率、工具选择正确率
⚡ 效率 (Efficiency)
Agent 完成任务是否高效？是否存在冗余步骤？
指标：平均步骤数、Token 消耗、端到端延迟
🛡️ 安全性 (Safety)
Agent 是否会执行危险操作？是否泄露敏感信息？
指标：越狱成功率、PII 泄露率、危险操作拦截率
🪨 鲁棒性 (Robustness)
Agent 对异常输入、工具调用失败、边界条件的处理能力？
指标：异常恢复率、降级成功率、对抗样本抵抗率
🎭 一致性 (Consistency)
相同/相似输入是否产生一致的输出？
指标：输出方差、语义一致性分数
😊 用户体验 (UX)
Agent 的交互是否流畅、友好？回复是否可理解？
指标：用户满意度、回复可读性、首次解决率
📊 评估指标列表
| 指标名称 | 评估维度 | 计算方式 | 数据来源 | 目标值 |
|---|---|---|---|---|
| 任务成功率 | 准确性 | 成功任务 / 总任务 × 100% | E2E 测试 + 线上追踪 | > 90% |
| 工具选择准确率 | 准确性 | 正确工具调用 / 总工具调用 | 集成测试 + 标注 | > 95% |
| 平均步骤数 | 效率 | 所有任务的步骤数均值 | Trace 数据 | 越低越好（对比基线） |
| 平均 Token 消耗 | 效率 | 所有任务的 Token 消耗均值 | API 响应 metadata | 对比基线下降 20%+ |
| P99 延迟 | 效率 | 99% 任务的端到端耗时 | Trace 数据 | < 30 秒（视场景） |
| 越狱成功率 (Jailbreak) | 安全性 | 越狱成功 / 越狱尝试 | 红队测试 | < 1% |
| PII 泄露率 | 安全性 | 泄露 PII 的响应 / 总响应 | 自动化扫描 | 0% |
| 错误恢复率 | 鲁棒性 | 从错误中恢复 / 遭遇错误总次数 | 异常注入测试 | > 80% |
| 语义一致性分数 | 一致性 | 多次运行语义相似度均值 | 重复测试 | > 0.85 |
🔄 自动化评估流水线
将评估集成到 CI/CD 流程中，实现每次变更都自动评估：
📥 代码变更
→
⚙️ 单元测试
→
🔗 集成测试
→
🧪 E2E 评估
(真实 LLM)
(真实 LLM)
→
📊 评估报告
(对比基线)
(对比基线)
→
✅ 发布 / 🚫 阻断
流水线关键设计
- 评估数据集管理：维护分层测试集（核心回归集 + 探索测试集），定期更新
- 基线对比：每次运行与上一版本基线对比，自动检测性能退化
- LLM-as-Judge：使用 GPT-4 等强模型作为"评委"，对 Agent 的输出进行评分
- 成本控制：E2E 测试消耗真实 Token，需设置每日/每周预算上限
- 结果可视化：自动生成评估报告，突出退化项和改进项
📈 回归测试策略
Agent 的行为会随着模型版本更新、Prompt 调整、工具变更而发生变化。回归测试确保变更不会导致已有的能力退化：
| 策略 | 触发时机 | 测试规模 | 成本 |
|---|---|---|---|
| 快速回归 | 每次 PR | 50~100 核心用例 | 低（使用便宜模型） |
| 完整回归 | 每次发布前 | 500~2000 用例 | 中 |
| 模型切换回归 | 更换底层模型时 | 全量测试集 | 高（使用真实模型对比） |
| 线上采样验证 | 持续运行 | 线上流量抽样 | 低（复用生产流量） |
💡 测试最佳实践
- 从核心场景开始：优先覆盖高频、高风险的业务场景，不要试图一次性覆盖所有情况
- 分层评估：结合自动化指标（任务成功率）+ LLM-as-Judge（质量评分）+ 人工评审（主观判断）
- 建立基线：每次变更前运行完整评估，生成基线报告作为对比基准
- 退化即阻断：关键指标（任务成功率、安全指标）的退化应自动阻断发布
- 测试即文档：每个评估用例都应包含清晰的场景描述、预期行为和评估标准，测试集本身就是 Agent 的行为规范