Agent 评估与测试方法论

为什么 Agent 评估困难

传统软件有明确输入输出和预期结果，Agent 的输出是开放式的——同一问题可以有多个正确答案。评估需要分层：功能正确性、工具选择合理、回答质量、安全保障。

三层评估体系

1. 单元级别 (Component Eval)

• 工具调用准确性：给一组用户输入，检查 Agent 是否调用了正确的工具和参数
• 意图识别：路由层能否正确判断用户意图（分类准确率）
• 检索召回：RAG 链路的 recall@k、MRR 指标
• 输出格式：结构化输出是否符合 JSON Schema

2. 端到端 (End-to-End Eval)

• Golden Dataset：人工标注的 Q&A 对，逐条比对回答质量
• LLM-as-Judge：用 GPT-4/Claude 等强模型评估回答的完整性、准确性、安全性
• Pairwise Comparison：两版本输出对比，胜率统计
• Trajectory 分析：检查 Agent 的思考链是否合理，是否有多余工具调用

3. 生产监控 (Production Monitoring)

• 用户反馈收集：点赞/踩、编辑提交、重试率
• 错误率追踪：工具调用失败、超时、异常回复
• 成本审计：每次对话的 Token 消耗、模型调用次数
• 回归测试：每次 Prompt 变更自动运行 Golden Dataset

实践工具链

LangSmith：提供数据集管理、在线评估、追踪回放。适合团队使用的基础设施。
LangFuse：轻量开源替代，支持评分、标注、Trace 查看。
自建 Pipeline：将 Golden Dataset 集成到 CI/CD，每次部署自动运行评估并生成报告。

常见坑

• Judge Bias：LLM-as-Judge 偏爱更长、更自信的回答，需结合多维度指标
• 数据污染：Golden Dataset 可能泄露到训练集中，需定期更新
• 过度优化：盲目追求单指标可能损害整体体验，建议用综合评分
• 工具成功率 ≠ 用户满意度：工具调用 100% 成功但回答无意义的情况常见

推荐方案

起步阶段：30-50 条 Golden Dataset + LLM-as-Judge + 回归 CI。逐步扩展到 200+ 条覆盖各场景。工具选 LangFuse（开源免费）或自建轻量评估脚本。核心原则：先跑通基线，再迭代优化。