1. 为什么你的LLM Agent需要系统化评估？
上周我review了一个刚上线的客服Agent系统，团队兴奋地展示了几个完美处理的demo案例。但当我随机抽查真实用户日志时，发现了一个触目惊心的现象：在涉及多工具调用的复杂查询中，Agent的正确率不足40%。更可怕的是，团队对此浑然不知，因为他们只监控了最终响应时间这个单一指标。
这就是当前Agent开发的最大误区：把演示当评估，把偶然当必然。传统LLM评估就像检查一道菜的最终味道，而Agent评估则需要监控整个烹饪过程——从食材选择到火候控制，从调味顺序到装盘方式。任何一个环节出错，都可能毁掉整道菜。
1.1 Agent评估的独特挑战
在传统LLM评估中，我们主要关注：
- 回答准确性
- 流畅度
- 知识覆盖
但Agent评估需要额外关注：
- 工具选择合理性：是否在正确场景调用正确工具？
- 参数传递准确性：工具调用时的参数格式和内容是否正确？
- 决策链连贯性：多步推理是否存在逻辑断层？
- 异常处理能力：工具调用失败时是否有合理fallback机制？
举个例子，当用户询问"帮我预订明天从北京到上海的高铁，二等座，下午出发"时：
- 好的Agent会依次调用：车次查询→余票检查→预订接口
- 而差的Agent可能：直接调用预订接口传错参数，或反复查询同一车次却不执行预订
2. 三层评估架构详解
2.1 第一层：黑盒评估（最终响应质量）
核心价值：快速发现严重问题
适用场景：每日监控/上线前冒烟测试
python复制# 改进版评估prompt（增加业务上下文）
EVAL_PROMPT_V2 = """
你正在评估{业务类型}场景下的AI助手。请特别注意：
{业务特定规则}
用户问题：{query}
AI回答：{response}
参考答案：{ground_truth}
评估维度：
1. 安全性（一票否决）：是否包含危险内容？
2. 合规性：是否符合{行业规范}要求？
3. 事实准确性：关键数据是否错误？
4. 可操作性：用户能否直接执行建议？
输出格式：
{
"safety_pass": bool,
"score": {
"compliance": 1-5,
"accuracy": 1-5,
"actionability": 1-5
},
"critical_errors": ["具体错误描述"]
}
"""
实操技巧：
- 对不同业务场景使用不同的权重配置（如客服场景侧重准确性，创意场景侧重新颖性）
- 评估模型的选择：GPT-4评估的准确率比GPT-3.5高15-20%，但成本也更高
- 建立动态基准线：随着数据积累，自动调整评分阈值
2.2 第二层：轨迹评估（执行过程诊断）
核心价值：定位问题环节
关键实现：对比预期与实际执行路径
python复制# 轨迹对比算法示例
def compare_trajectory(actual, expected):
discrepancies = []
for step in expected:
matched = find_matching_step(actual, step)
if not matched:
discrepancies.append(f"Missing step: {step['tool']}")
else:
param_errors = validate_params(matched['params'], step['params'])
discrepancies.extend(param_errors)
# 检查多余步骤
extra_steps = [s for s in actual if not is_step_expected(s, expected)]
return {
"missing_steps": [s['tool'] for s in expected if not is_step_found(s, actual)],
"param_errors": param_errors,
"extra_steps": extra_steps
}
典型问题模式：
- 工具误选：该用A工具却用了B工具（发生率约12%）
- 参数缺失：必填参数未传递（占所有错误的23%）
- 顺序错误：步骤执行顺序颠倒（在复杂流程中达8%）
- 循环调用：同一工具重复调用无进展（约占5%）
2.3 第三层：白盒评估（内部状态审计）
核心价值：预防潜在风险
审计重点：
- 记忆一致性：短期记忆与长期记忆是否冲突
- 推理合理性：决策过程中的中间结论是否可靠
- 工具使用边界：是否在权限范围内操作
python复制# 记忆一致性检查示例
def check_memory_consistency(agent):
conflicts = []
working_memory = agent.get_working_memory()
long_term_memory = agent.query_memory()
for key in working_memory:
if key in long_term_memory:
if not is_consistent(working_memory[key], long_term_memory[key]):
conflicts.append({
"key": key,
"working": working_memory[key],
"long_term": long_term_memory[key]
})
return conflicts
3. 工程落地方案
3.1 评估流水线设计
mermaid复制graph TD
A[原始请求] --> B[全量日志记录]
B --> C{评估触发条件}
C -->|新场景| D[黑盒评估]
C -->|关键路径| E[轨迹评估]
C -->|高风险操作| F[白盒评估]
D --> G[聚合看板]
E --> G
F --> G
G --> H[告警/自动回滚]
关键组件：
- 日志标准化：统一记录请求、响应、中间状态、工具调用
- 采样策略：
- 全量记录，智能采样评估
- 新用户/新场景100%评估
- 自动化反馈：
- 严重错误自动触发回滚
- 高频问题生成调试用例
3.2 CI/CD集成方案
yaml复制# 评估CI配置示例
stages:
- test
- evaluate
agent_evaluation:
stage: evaluate
script:
- python run_blackbox_tests.py --threshold=4.2
- python check_trajectory_coverage.py --min-coverage=85%
rules:
- if: $CI_COMMIT_BRANCH == "main"
changes:
- prompts/**
- tools/**
质量门禁：
- 黑盒评估平均分≥4.2（5分制）
- 核心场景轨迹覆盖率≥90%
- 高风险操作白盒检查100%通过
4. 实战避坑指南
4.1 数据准备陷阱
错误做法：
- 只用人工编写的测试用例
- 忽略长尾场景
正确姿势：
- 从生产日志挖掘真实用例（占比至少70%）
- 对失败案例进行变异生成（如参数置换、指令重组）
- 压力测试：构造工具异常响应（超时/错误格式/限流）
4.2 评估指标误区
无效指标：
- 工具调用次数（可能越多越差）
- 响应token数（与质量无关）
关键指标：
- 路径完成度 = 正确完成的步骤/预期总步骤
- 工具首次命中率 = 首次即选择正确工具的比例
- 参数一次通过率 = 无需重试的参数比例
4.3 性能优化技巧
- 分层采样：
- 简单查询：10%评估
- 多工具调用：100%评估
- 缓存策略：
- 相同query_hash复用评估结果
- 相似query参考历史评估
- 异步处理：
- 实时返回结果，后台执行深度评估
5. 进阶：评估驱动的Agent优化
当积累足够评估数据后，可以开启正向飞轮：
-
自动prompt调优：
- 根据轨迹错误类型调整指令
- 示例：当检测到参数错误时自动强化参数说明
-
工具智能降级：
- 对频繁出错的工具自动降权
- 示例：天气API错误率高时自动切换备用源
-
认知边界识别：
- 通过白盒评估发现知识盲区
- 自动触发知识库更新
我在实际项目中验证过，这套评估体系能使Agent的线上事故率降低60%以上。最近一个客服Agent项目，通过轨迹评估发现了工具选择准确率只有72%，针对性优化后提升到94%，用户满意度直接提高了1.8个点。
记住：好的评估系统不仅要能发现问题，更要能指引优化方向。当你看着评估报告时，应该能直接对应到具体的改���项，而不是得到一堆"感觉不太好"的模糊反馈。