芦苇之思

什么是好的评估系统

一个好的 Agent 评估方案，核心不是“攒一堆 case 跑个通过率”，而是能回答三个问题：

1. 它有没有修掉真实 bug？
2. 它在不同问题类型上哪里强、哪里弱？
3. 它变差时，能不能快速定位是分类、规划、工具调用、上下文还是最终表达的问题？

我的判断是：好的 Agent 评估要分层，而不是只有一个总分。

一、数据集要像真实问题，不像考试题

好的金标集应该来自三类样本：

• 真实线上问题：生产日志、QA 复现、用户反馈、历史 bug。
• 边界问题：多轮省略、指代、时间歧义、跨能力混合、上下文缺失、工具失败。
• 分类覆盖问题：闲聊、日程、记事、搜索、健康、会议、主动服务等能力都要有独立统计。

不好的评估集通常有这些问题：同一句话换皮重复太多、case 太“干净”、只测单轮、只看最终回答、不记录问题来源、不知道一个 case 是为了防哪个 bug。

所以金标里每条最好有：

{
  "user_input": "...",
  "category": "schedule",
  "expected_intent": "create_event",
  "expected_capability": "schedule",
  "expected_plan": [...],
  "expected_behavior": "...",
  "bug_source": "prod_log / qa / manual",
  "risk_tags": ["multi_turn", "time_parse", "tool_call"],
  "must_not": [...]
}

二、评估对象要拆开

Agent 不是普通聊天模型，它至少有四个环节：

层级	看什么	典型指标
分类/路由	有没有走对能力	intent accuracy、capability precision/recall/F1、混淆矩阵
规划	plan 是否合理	plan step match、是否多余工具、是否漏步骤
执行	工具调用是否正确	tool name、参数正确率、副作用安全性、失败恢复率
回复	用户最终是否满意	task success、事实一致性、格式正确率、拒答/澄清质量

如果只看最终回答，会有两个问题：
一个是“答对了但过程危险”，比如误调用工具但最后话术圆回来了；另一个是“答错了但不知道错在哪”，无法指导修复。

三、指标不要只有 accuracy

我会把指标分成四组：

质量指标

• task_success_rate：用户目标是否完成。
• intent_accuracy：意图是否正确。
• capability_f1：能力分类的 precision / recall / F1。
• tool_call_accuracy：工具名和参数是否正确。
• context_usage_accuracy：多轮上下文是否正确使用。
• clarification_quality：该澄清时是否澄清，不该澄清时是否拖延。

回归指标

• bug_regression_pass_rate：历史 bug 是否继续通过。
• fixed_bug_reopen_count：已修问题是否复发。
• must_not_violation_count：禁止行为是否出现。
• golden_diff_count：相对上个基线变化多少。

数据质量指标

• unique_user_input_rate：去重后输入占比。
• duplicate_rows_removed：重复 case 清理量。
• category_coverage：覆盖多少类问题。
• intent_coverage：覆盖多少意图。
• capability_coverage：覆盖多少能力。
• multi_turn_anchor_kept：多轮是否保留关键终轮锚点，而不是把每轮都当独立样本膨胀。

工程指标

• latency_p50/p95
• cost_per_success
• tool_call_count_per_task
• retry_rate
• fallback_rate
• judge_disagreement_rate

尤其是分类性能，必须看混淆矩阵。比如“日程创建”误判成“闲聊”，和“日程创建”误判成“日程查询”，严重程度完全不同。

四、评估集应该分用途，不要混成一锅

我建议至少拆成这些集合：

集合	作用
golden_bug_regression	验证历史 bug 和高风险边界不复发
golden_category_eval	验证不同分类、意图、能力的性能
golden_multi_turn	专测上下文、指代、省略、状态延续
golden_tool_call	专测工具选择和参数
golden_latency_smoke	小样本快速冒烟，给 CI 用
compliance	合规安全闸门，独立跑，不和业务准确率混分

合规最好是“一票否决”的 gate，而不是和业务正确率加权平均。否则会出现业务分数很好但安全退化被平均数掩盖。

五、好的评估不是一个分数，而是一张诊断图

最终报告应该类似这样：

Overall task success: 82.4%
Bug regression pass: 96.8%
Capability F1:
  schedule: 0.91
  note: 0.86
  casual_chat: 0.78
  health: 0.74

Top regressions:
  1. multi_turn + time_parse: 下午省略场景下降
  2. casual_chat vs knowledge_query 混淆上升
  3. tool 参数 location 缺失率上升

Latency:
  p50: 1.8s
  p95: 5.6s

这样团队能知道该修哪里，而不是只看到“整体 82 分”。

六、我认为好的 Agent 评估方案有五条标准

1. 真实：case 来自真实使用、真实 bug、真实多轮，而不是理想化 prompt。
2. 可诊断：失败能归因到分类、规划、工具、上下文、回复中的某一层。
3. 可回归：每个修过的 bug 都进入金标，不靠人记忆。
4. 可比较：每次跑都有版本、指标、diff、混淆矩阵。
5. 可行动：报告能直接告诉研发“下一刀该切哪里”。

一句话总结：
好的 Agent 评估不是证明模型聪明，而是持续证明系统在真实用户问题上没有悄悄变笨。

要满足上面那种 Agent 评估，工作基本分成 8 件事。

1. 先定评估契约

• 明确评什么：分类、规划、工具调用、最终任务成功、合规。
• 明确不评什么：不能把合规和业务正确率混成一个分数。
• 定义每个 case 的标准输出结构。

2. 建评估集分层

• bug_regression：真实 bug、边界回归、多轮锚点。
• category_eval：按问题类型/能力分类测性能。
• multi_turn_eval：专测上下文、省略、指代、状态延续。
• tool_eval：专测工具选择和参数。
• compliance：独立闸门，不参与业务加权。

3. 做数据规范

• 统一字段：user_input / category / intent / capability / expected_plan / must_not / source / risk_tags / version
• 加溯源：每条样本都要知道来自线上、QA 还是人工构造。
• 去重和收缩：同义重复、同输入多来源、多轮重复 case 要清掉。

4. 做标注规则

• 定义标签体系：意图、能力、风险类型、是否需要澄清、是否允许工具调用。
• 约定边界：什么算对、什么算部分对、什么算失败。
• 红队复核：高风险样本先过一轮对抗性审查。

5. 做执行器

• 固定模型、提示词、温度、工具环境。
• 能逐条回放 case。
• 记录完整轨迹：分类结果、工具调用、回复、耗时、失败原因。

6. 做指标体系

• 分类：accuracy、precision/recall/F1、混淆矩阵。
• 回归：bug 复现率、修复回退率、must-not 违规率。
• 多轮：上下文利用率、锚点命中率。
• 工具：工具名正确率、参数正确率、失败恢复率。
• 工程：p50/p95 延迟、成本、重试率。

7. 做报告与诊断

• 总分之外，必须能看 slice。
• 按类别、能力、风险标签、来源分桶。
• 每次失败都能定位到“分类错 / 规划错 / 工具错 / 上下文错 / 表达错”。

8. 做流程化维护

• 修一个 bug，就加一条金标。
• 定期去重、重标、淘汰老旧 case。
• 设基线版本和阈值。
• 夜间全量、CI 冒烟、小样本快速回归分开跑。

最短落地顺序

1. 先定 schema 和标签体系
2. 再做 100-200 条高质量金标
3. 接上 runner 和基础指标
4. 再补分类矩阵、混淆分析、回归闸门
5. 最后做自动化和长期维护

一句话：
先把“测什么、怎么算对、失败怎么定位”这三件事定死，再去堆数据和自动化。