一个智能体选中工具、拿到结果、返回一个看起来很有说服力的答案——这只能算一个能跑的演示。当请求本身含糊、工具超时、或者拿到的证据不完整时，它会在哪一步先出问题？
这正是第20天要处理的事：复盘第一个能工作的智能体，把失败分门别类，再决定先改哪一块。前面几天谈过的工具契约、权限、路由、有界执行、预算和澄清，在这里汇到一起。
先看结果，再看执行
一个最终答案听起来正确，底下的动作却可能是错的。设想一个客服智能体：用户说“取消我最近的一笔订单”，智能体回答“您的订单已取消”。这句话本身不能证明成功。
要核对的是：它有没有找对订单？这次取消是否被允许？工具是否真的完成了操作？最终的系统状态是否确认了取消？τ-bench 这项研究评估使用工具的智能体时，用的办法是把最终数据库状态与预期目标状态做比对，同时考察重复试验下的可靠性。可用的经验是：评估实际发生了什么，而不只是智能体说了什么。
先分类，再改系统
“智能体失败了”这个说法太宽，没法指导修复。复盘时可以用一组实用分类，这是一套调试框架，不是标准化的研究分类法。同一次运行里可能同时出现几类问题。
一个错误的最终答案，起点可能是一次查错了记录。只改措辞，原始缺陷还留在原地。复盘要找出最早的那个有意义的错误，以及它之后连带发生的失败。
建一个小而明确的复盘集
跑一个用例之前，先写下什么算成功。起步阶段可以包含这些：
- 一个清晰、应当成功的请求；
- 一个含糊、需要澄清的请求；
- 一个超出智能体权限的请求；
- 一个信息缺失的工具响应；
- 一次临时性的工具故障；
- 一次动作可能已经完成之后的超时；
- 一个在执行预算内无法完成的任务。
每个用例都要定义预期结果、禁止动作和可接受的停止行为。澄清可以是正确的，拒绝也可以是正确的，明确说明任务仍未完成同样可以是正确的。成功与否取决于这个用例的要求。
检查手段要匹配失败类型
有些属性用代码检查很直接：工具参数是否合法？是否尝试了被禁止的操作？预期的状态变更是否发生？执行限制是否被遵守？
另一些属性需要判断：澄清是否必要？回答有没有把不确定性讲清楚？答案是否停留在现有证据之内？Anthropic 的智能体评估指南描述了把确定性检查、基于模型的评分和人工复核结合起来，也建议检查执行轨迹，并用人工判断校准模型评分器。大模型评审可以帮忙看一段解释，但要证明订单被取消，数据库检查是更强的证据。
按后果排优先级
出现最频繁的失败，不一定是最紧急的。建议的改进顺序是：
- 阻止有害或未授权的动作。一次罕见的权限失败，分量可能压过许多轻微的响应问题。
- 修正错误动作和虚假的成功声明。用户需要知道请求的操作到底有没有发生。
- 改善常见的任务失败，处理反复出现的路由、参数、证据和恢复问题。
- 降低不必要的成本与延迟。等基本行为可靠之后，再优化重复调用和低效执行。
- 打磨呈现。底层行为可靠之后，再改措辞和格式。
每一组内部，可以看频率、用户影响，以及一个修复能覆盖多广。这是一套实用的排优先级方法，不是通用的评分公式。
把确认的失败变成回归用例
选定一个修复之后：保留失败的输入和相关环境状态，定义预期行为，只做一处针对性改动，把该用例重复跑多次，再重跑此前通过的用例。
还要检查测试本身是否有效。一个过严的评估器会把合法的解法判为不通过。重复试验之所以重要，是因为单次成功对一致性的证明力有限。
一个能工作的智能体，给了我们一个具体可评的对象。下一步的改进应当来自观察到的失败：它们从哪里开始，造成什么后果，以及一处针对性改动能否在阻止它们的同时不破坏其他行为。要带下去的问题是：下一个修复该给哪一类失败，又用什么证据说明修复生效了？
热门跟贴