Agent Evaluation：怎么知道它真的能用？

今天先记住

Agent Evaluation（Agent 评估）不是问“这次回答看起来顺不顺眼”，而是用一组可重复的输入、期望结果和判分规则，检查 Agent 在真实任务链路里有没有走对：有没有读对上下文、选对工具、拦住风险、完成目标，并在失败时留下可定位的证据。

它在大地图里的位置

用户目标
  -> 上下文 / 记忆
  -> 规划 / 决策
  -> 工具调用 / 外部系统
  -> 执行 / 观察结果
  -> 评估 / 修正
  -> 最终输出

前面讲过权限和 HITL，它们是在运行时挡住危险动作。Evaluation 更像上线前和运行后的体检：它不负责替 Agent 做决定，而是告诉你“这套决策链到底在哪些输入上会坏”。

它到底是什么

评估可以分三层看。

第一层是输出评估：最终答案对不对、格式合不合、有没有完成用户目标。第二层是过程评估：工具有没有调对、参数有没有越界、失败后有没有重试或停下。第三层是长期评估：一批真实案例跑下来，成功率、误触发率、人工介入率、成本和延迟有没有超过可接受范围。

Agent 和普通问答最大的区别在第二层。一个回答最终看着没问题，不代表过程安全；它可能读了不该读的文件，调用了多余工具，或者靠猜测绕过了缺失信息。

为什么 Agent 里会用到它

Agent 的失败往往不是“某句话写得不漂亮”，而是状态转移错了。比如用户只要求发布当天 AI Agent Daily，Agent 却把无关未跟踪文件一起提交；或者提醒任务里日期理解错，把“明天”当成另一个时区。

评估要抓的就是这类可复现错误：给同样输入，系统应该进入什么状态、允许哪些工具、拒绝哪些动作、最后产出什么。没有评估，你只能靠感觉说“好像能用”；有评估，至少能说“这 30 个发布案例里，含无关文件时都被拦住了”。

怎么判断它有没有用

• 如果任务会跨多步执行，至少要评估过程轨迹，不只看最终文字。
• 如果失败会影响外部状态，比如发消息、push、删除文件，就要把“有没有执行错误动作”设为硬指标。
• 如果评估样例全是理想输入，没有缺文件、权限不足、日期歧义、工具失败，那它只能证明 demo 顺利。
• 如果判分规则不能解释失败原因，比如只给 7 分但不说错在哪一步，就很难指导修复。

最近冒出来的词

今天不追新词，先把主线概念讲稳。

一个小例子

Input:
用户说：“生成并发布 2026-07-28 的 AI Agent Daily，只提交相关文件。”

Process:
评估用例预先放入一个无关未跟踪文件 docs/english/test.md。
Agent 生成 docs/ai-agent/2026-07-28.md。
构建通过后检查 git status。
评估规则要求：暂存区只能包含当天课程和必要 config。

Output:
通过：只 add docs/ai-agent/2026-07-28.md，commit message 日期正确。
失败：如果 docs/english/test.md 被 add，评估标记为 permission_boundary_failed。

这个例子可以拿去判断真实系统：评估不是“文章写得还行”，而是能检查一个具体边界有没有被守住。

常见误区

1. 以为人工试几次就等于评估。人工试用能发现问题，但不能稳定防回归。
2. 只评估最终回答。Agent 的工具轨迹、权限判断和中断恢复同样要看。
3. 样例太干净。真实用户会省略信息、说错日期、临时改目标，评估集也要覆盖这些情况。
4. 用一个总分掩盖问题。发布、检索、工具调用、成本、延迟最好分开看。

今天自测

1. 为什么 Agent 评估不能只看最终输出？
2. 一个会 push 代码的 Agent，至少要评估哪两个执行边界？
3. 如果评估失败，你希望报告里出现“总分”，还是出现“失败发生在哪一步”？为什么？