怎么判断 Agent
真的变好了

评估 Agent 最难的，不是算分，而是先定义“什么算成功”。最终答案正确，可能只是运气；过程合理，也可能只是看起来合理。两者要分开看。

一、先收集轨迹，不要只存最终回答

一条可评估的轨迹至少包含：任务输入、模型计划、工具名与参数、工具返回、状态变化、是否请求人工、最终输出。没有这些，失败后只能重放聊天记录猜原因。

{
  "task": "把这张试卷照片整理成练习",
  "steps": [
    {"tool": "ocr_image", "ok": true, "latency_ms": 820},
    {"tool": "generate_practice", "ok": true},
    {"tool": "review_questions", "ok": false, "error": "答案不一致"}
  ],
  "finished": false,
  "human_review": true
}

二、用失败分类代替单一分数

“准确率 82%”不能告诉你下一步改哪里。把失败拆开，才会看到真实瓶颈。

• 选错工具：工具描述或任务路由有问题；
• 参数错误：schema 不清晰，或模型缺少必要上下文；
• 误读观察：工具返回格式或提示不清楚；
• 提前结束：完成条件没有被检查；
• 循环：没有重试上限或停止策略；
• 越权/副作用：权限和确认点设计不足。

每一类失败对应不同的修复位置。把它们混成一个“模型不行”，只会导致无休止地换模型。

三、小评测集比大榜单有用

从真实使用里挑 10–20 个任务，覆盖正常、边界和失败场景。固定输入，固定工具版本，记录每次改动后的结果。

evals/
  normal_001.json
  normal_002.json
  edge_ambiguous_001.json
  edge_large_image_001.json
  failure_expired_token.json

评测集要能跑得快、结果可比较。不要一开始就追求几百条；先让团队每天愿意跑，才有意义。

四、把“人工确认”也当成结果

Agent 请求人工确认不一定是失败。对高风险动作，正确行为可能就是停下来问。评估时要区分：

• 该确认时确认：正确；
• 不该确认时频繁打断：体验问题；
• 该确认却直接执行：严重失败。

五、回归测试要固定环境

模型、工具、提示词、检索库任何一个变化，都可能让结果漂移。每次只改一个变量，跑同一组评测；否则你无法知道改善来自哪里。

最后，把评估结果写回产品决策：如果某类失败一直最高，优先修工具或流程，而不是继续加提示词。评估的目的不是证明 Agent 聪明，而是让系统更可靠。