智能体失败恢复的量化，核心不在于统计“失败了几次”，而在于建立一套可重复、可比较、可追溯的观测框架。当前多数评估仍以“任务是否完成”为单一终点，这恰恰掩盖了恢复能力这一关键维度——一个系统可能最终答对了，但过程中依赖了危险的猜测、越权操作或不可复现的运气。要真正量化恢复能力，需要把异常注入、行为观测和过程评分三者绑定在同一轮测试中。
量化的第一步是制造可控的失败。在隔离环境中设置固定位置的故障，例如让一次查询返回超时、让某条记录暂时不可访问、让写入工具返回失败。故障的触发位置和错误信息必须对所有受测系统保持一致，否则比较的是故障差异而非智能体能力。这里要区分两类情形：可恢复错误与不可恢复错误。短暂超时允许按预设次数重试；权限不足、缺少必要字段或规则冲突，则不应靠反复调用工具绕过。测试用例应明确写出哪些错误允许重试、最多几次、何时必须停止。没有这层预设，后续的“恢复”行为就无法判定是合理策略还是盲目重试。
第二步是定义观测点。智能体面对异常时，记录它是否识别到错误、是否进行有边界的重试、是否改用允许的替代路径，以及失败后是否如实说明未完成部分。尤其要盯住重复提交风险：如果写入工具已经成功但返回确认失败，智能体再次调用是否会造成重复记录？无法确认操作状态时，合适的行为可能是暂停并请求人工核查，而不是继续猜测。这一项单独列出，是因为它直接关系到真实业务中的副作用安全，比“最终答案对不对”更值得警惕。
第三步是评分结构。建议将结果质量与过程可靠性分开打分，避免一次“答对”掩盖危险操作。一个可用的权重框架是：完成质量占三成五，任务规划占两成，工具调用占两成，结果校验占一成五，失败恢复占一成。每个维度采用0到4分制。同时应单独标记安全违规、未经授权的副作用、虚构工具结果等严重问题——对高风险任务，这些问题不应被其他项目的高分抵消。评分标准要提前定义，例如客服任务中“找出规则允许的金额”与“实际执行退款”是两个不同结果，后者未获授权即属于越界，即使金额正确也不能算作完整成功。
最后是过程留痕与重复运行。单次运行不足以说明恢复能力，因为异常处理天然带有随机性。应对相同任务和配置重复运行多次，报告每次结果、均值或中位数、波动范围以及严重错误出现次数，保留原始记录而不是只挑最好的一次。版本更新后应重新执行固定任务集，区分能力变化与任务、提示词或工具环境变化。这样量化出来的恢复能力，才是可审计的证据，而非演示中的偶然表现。