评估 Agent，要核对执行后的真实状态

Agent 能选工具、拿结果、给出像样的回答，只能证明演示跑通了。真正要检查的是：请求含糊时会不会追问，工具超时后会不会重复操作，证据不全时会不会谎报成功。

这篇 Day 20/90 的重点，是给第一个可运行的 Agent 做故障复盘。作者提出了一套从执行结果、失败起点到修复优先级的检查方法。它没有提供性能提升数据，但能帮助开发者回答一个实际问题：接下来该修哪里，又凭什么认定修好了。

回答像成功，不代表操作真的成功

作者用了一个假想的客服场景：用户要求「取消我最近的订单」，Agent 回复「订单已取消」。

这句话几乎没有证明力。它可能找错订单，可能没有取消权限，也可能调用失败后仍然生成了成功回复。检查时至少要追问：选中的是不是正确订单，操作是否获准，工具是否完成执行，系统最终状态是否确认取消。

评价 Agent，要同时检查它说了什么，以及系统实际发生了什么。

作者引用的 τ-bench 研究，会比较最终数据库状态与预期目标状态，也考察多次试验中的可靠性。这里可以借用的思路很直接：对有写入操作的任务，验收依据应该包含操作后的真实状态。

这也解释了为什么执行轨迹很重要。最终回答只是最后一环，前面还有记录查询、权限判断、工具路由和参数生成。一次错误查询，可能一路传递成错误操作和虚假的成功声明。只改最后一句话，缺陷仍然存在。

先写清验收条件，再判断 Agent 有没有失败

作者建议先建立一个规模较小、要求明确的评审集，覆盖七类情况：

• 请求清晰，应该正常完成。
• 请求含糊，需要补充确认。
• 请求超出 Agent 的权限。
• 工具返回的信息不完整。
• 工具发生暂时性故障。
• 操作可能已完成，但调用超时。
• 任务无法在执行预算内完成。

每个用例都要提前写下预期结果、禁止动作和可接受的停止方式。否则，评审者很容易把「没有完成任务」一概判成失败。

例如，信息不足时追问可能就是正确结果；越权请求应当拒绝；预算耗尽时，应明确说明任务尚未完成。成功标准由用例要求决定，不能只看 Agent 有没有给出一个肯定答复。

其中，操作可能已完成后的超时尤其需要单独检查。超时只说明调用方没有及时拿到结果，不能据此认定操作没有发生。评审必须覆盖这种不确定状态，避免把盲目重试当成恢复成功。

作者还建议给失败分类，但明确表示这是一套拟议中的调试框架，并非标准研究分类。原文也没有展开一张完整的分类表。实际复盘时，可以围绕文中提到的路由、参数、证据、恢复和权限问题定位，重点是找出最早影响结果的错误，再追踪后续问题。

能用状态检查的地方，别只让模型打分

不同失败，需要不同的验收方式。

工具参数是否合法、是否尝试了禁止操作、预期状态是否改变、执行限制是否遵守，这些通常可以用代码检查。是否需要追问、是否讲清不确定性、回答是否超出证据范围，则需要更多判断。

作者引用 Anthropic 的 Agent 评估建议，将确定性检查、模型评分和人工评审结合起来，同时查看执行轨迹，并用人工判断校准模型评分器。

大白话解释就是：机器能直接核对的事实，先核对事实；解释质量等难以写死规则的部分，再让模型和人参与。

LLM judge 可以帮助评审一段解释，但数据库检查更能证明订单是否取消。模型觉得回复合理，不能代替业务事实。

修复以后，也不能只运行一次。作者建议保留失败输入和相关环境状态，写明预期行为，做一次有针对性的修改，再多次重跑该用例，同时重跑此前通过的用例。

这里还要检查评估器本身。规则过严，也可能把合法的解决方式判成失败。回归测试既要拦住旧问题，也要允许合理解法。

我的判断

我认同作者把「后果」放在「频率」前面。一次低频的越权操作，可能比大量措辞不顺更值得优先处理。

作者给出的修复顺序是：先阻止有害或未经授权的动作，再修错误操作与虚假成功声明，然后处理常见任务失败，接着优化成本和延迟，最后打磨表达。同一组内，再考虑发生频率、用户影响和修复覆盖范围。原文重复列出了这些条目，实际只有这五档优先级。

这套顺序适合用作评审会议的讨论起点，但作者没有给出对照实验，也没有证明它适用于所有团队。它是经验性的取舍方法，不是通用评分公式。

与只看最终回复的评估相比，它能暴露操作链路里的问题；与完全依赖人工逐条审查相比，确定性检查也更容易重复执行。不过，前提是团队能够拿到工具调用记录和业务状态。原文没有说明这些证据如何采集，也没有给出重复试验的次数或可靠性达标线。

因此，读者可以直接借用评审流程，不能据此声称自己的 Agent 已达到某种生产可靠性水平。

能拿来做什么

• 给现有 Agent 建立一组起步用例，覆盖原文的七类情况，并为每例写清预期结果、禁止动作和允许的停止方式。
• 在 Node 工具执行层记录调用参数、返回结果和相关状态变化，让评审能够追到最早的错误，而不是只看到聊天记录。
• 对修改业务数据的任务，把最终状态检查纳入验收；对于「可能已执行但超时」的情况，单独定义检查与停止要求。
• 每确认一个故障，就保存输入与相关环境状态，形成回归用例；修复后多次运行，并检查此前通过的任务是否仍然成立。