智能体评测不只看成功率：步骤、成本与恢复能力怎么量

智能体把任务做对，只说明最后一步暂时正确；它可能绕了三次路、调用了错误工具、花掉过高成本，甚至在第一次失败后无法恢复。实用的评测要把“答对没有”拆成四本账：最终结果、工具轨迹、成本与延迟、失败恢复。这样改模型或改提示词时，才知道提升来自哪里，又牺牲了什么。

先把成功率拆成四个可观测维度

Google Cloud 的智能体评测文档把最终回答评测与轨迹评测分开：前者看是否完成目标，后者看工具调用路径是否合理。工程上还应补两项：每次运行的成本与延迟，以及工具出错后的恢复结果。四项指标不要先揉成一个总分，否则一个漂亮的最终答案可能掩盖危险的中间动作。

用一条评测记录把过程固定下来

评测集不要只保存用户问题和最终答案。对订单查询、知识库检索这类工具型任务，至少保存期望结果、允许工具、最大步骤数、成本预算和可接受的恢复动作。下面的 Python 只是一个模型无关的评分骨架，输入是一条已经采集的运行记录；示例输出是说明格式，不代表本文在本机执行过。

def score_run(run):
    # 先用确定性规则检查硬边界，避免只凭语言模型感觉打分
    trajectory = run.get("trajectory", [])
    expected_tool = run.get("expected_tool")
    max_steps = run.get("max_steps", 6)
    cost_limit = run.get("cost_limit_usd", 0.05)

    # 工具名、步骤数和成本属于可以稳定复现的指标
    tool_ok = any(item.get("tool") == expected_tool for item in trajectory)
    steps_ok = 0 

这里故意不把四个布尔值立即平均。若轨迹超出最大步骤数，即使最终答案正确，也应在发布或灰度门禁中标为失败；若结果正确但成本超预算，则记录为“功能通过、经济性不通过”。这种分项结果比一个 0.75 更容易定位问题。

把失败恢复单独记账

工具失败不是单一的“失败”。网络抖动可以有限重试，写操作失败可能需要回滚，权限不足应转人工，涉及安全边界的请求则应直接终止。恢复指标至少包含：首次错误后的动作、尝试次数、是否产生副作用、最终状态和人工接管原因。禁止无限重试，因为它会同时放大延迟、费用和外部写入风险。

Google 的智能体评测资料还把工具使用质量、最终回答质量、幻觉和安全列为可评估维度。对应到自己的评测集，可以把安全拒答设为一种“正确终止”，而不是简单计入失败；关键是先定义什么请求应该被拒绝，以及拒绝后是否没有继续调用高风险工具。

用分项看板比较版本，不让总分遮住退化

离线评测适合固定样本比较提示词、模型和工具编排，线上评测则用真实轨迹发现新边界。每次版本比较建议同时展示四项通过率、P95 总耗时、单任务成本和恢复成功率，并保留失败样本链接。只有当结果通过率不下降、成本和延迟未越过预算、恢复能力没有明显退化时，才把版本推进到下一环境。

一个简单的发布门槛可以是：最终结果通过率至少 95%，轨迹硬规则通过率至少 98%，P95 成本不超过预算，恢复成功率至少 90%。这些数字不是行业标准，应按业务风险、工具副作用和人工兜底能力调整。对支付、删除和权限变更任务，轨迹与安全门槛通常要高于普通问答。

常见问题

成功率高但步骤数变多，算不算回归？

如果步骤上限是业务约束，就算回归；如果只是探索任务，则记录为成本或延迟退化，不能用成功率掩盖。

一定要用另一个大模型当评委吗？

不一定。字段、工具顺序、步骤上限、预算和安全边界优先用代码判定；只有事实性、表达质量等难以规则化的部分再使用评分器，并抽样人工复核。

恢复成功率应该怎么算？

分母是发生可恢复错误的运行数，分子是最终达到安全终态且副作用可控的运行数；无限重试和没有记录的人工介入不能算成功。

智能体评测的重点不是制造一个更大的总分，而是让每次运行都留下可解释的证据：结果是否完成、路径是否合规、成本是否可接受、失败是否安全收敛。四项拆开，版本迭代才有明确的改进方向。