前缀可执行性：别只看工具智能体的最终成功率

1. 一句话结论

这篇论文指出：工具调用智能体的最终成功率会掩盖中间轨迹根本跑不通的事实，于是提出"前缀可执行性"这一轨迹级评测协议，逐个前缀检查工具 schema、状态前置条件、数据依赖是否成立，并用五个指标把这种不可见的不靠谱量化出来。

2. 方法要点

核心动作只有一个：把评测单位从"终态"下移到"前缀"。

给定智能体预测出的工具调用序列 τ = (a₁, …, a_T)，对每一个前缀 π_t = (a₁, …, a_t) 判定它是否仍然可执行。判定是三类约束的合取：

E(π_t) = S(π_t) ∧ P(π_t) ∧ D(π_t)

• S（schema）：这一步调用的工具是否存在，参数类型、必填项、枚举值是否合法；
• P（状态前置条件）：调用时刻的世界状态是否满足该工具的前提，例如订单存在才谈得上退款；
• D（数据依赖）：这一步参数里引用的值，是否真的来自上游工具返回过的字段，而不是模型自己编出来的。

（上式是按论文定义整理的写法，论文以协议形式给出三类约束，未在摘要中给出符号化公式。）

在此之上，论文定义了五个汇总指标，从不同角度刻画一条轨迹的可靠性：

1. 前缀可执行性曲线（PEC）：横轴是前缀深度，纵轴是仍可执行的比例；
2. 首个错误深度（FED）：第一次不可执行发生在第几步，直接回答"错误从哪里进来"；
3. 轨迹可执行率（TER）：整条轨迹每个前缀都合法的比例；
4. 视野归一化 AUC-PEC：把长短不一的任务曲线归一化后再比，避免长任务天然吃亏；
5. 恢复率（RR）：中途已经出错、但最终仍然成功的比例，用来区分"一次做对"和"错了再救回来"。

论文最重要的观察是排名分叉：只按最终成功率排，和按前缀级指标排，结果不一样。那些把执行建立在一份未经验证的计划上的智能体，最终成功率的点估计反而高于不做计划条件化的基线，但 TER 与 AUC-PEC 明显更低。换句话说，高分里有一部分是靠"先规划再硬跑、跑挂了也照样蒙对终点"撑起来的，而这类失败模式正是前缀可执行性要暴露的东西。

作为验证性干预，作者加了执行前的显式计划检查，结果是可执行前缀的存活情况变好，同时最终成功率保持有竞争力。这说明该协议不只是诊断工具，也能反过来指导设计。

伪代码形态大致如下，可直接照着实现：

def prefix_executability(trajectory, env):
    flags, state = [], env.initial_state()
    for step in trajectory:
        ok = (schema_ok(step, env.tools)        # S: 工具名/参数类型/必填项
              and precond_ok(step, state)       # P: 状态前置条件
              and data_deps_ok(step, state))    # D: 引用的返回值确实存在
        flags.append(ok)
        if not ok:
            break                               # 记录 FED = 当前深度
        state = env.apply(step, state)
    return {
        "pec":  flags,                          # 逐步可执行序列
        "fed":  next((i for i, f in enumerate(flags) if not f), len(flags)),
        "ter":  int(all(flags)),                # 单条轨迹是否全程可执行
    }

3. 关键数字

论文在三个来源上实例化协议：BFCL-v3 多轮与 ToolSandbox 的分层样本，以及 τ³-bench 的 Airline、Retail 两个完整 base split。可核实的规模信息如下（数字均来自论文页面元数据与摘要）：

需要说清楚的是：arXiv 摘要与元数据没有披露逐数据集的具体跑分与百分比提升，只给出了方向性结论——计划条件化智能体的最终成功率点估计更高，但 TER 与 AUC-PEC 显著更低；执行前计划检查能抬高可执行前缀存活率并保持最终成功率有竞争力。任何具体百分点在被引页面中都查不到，因此本文不填。要拿到数字，需要下载 21 页正文与其中 2 张图，见 arXiv 摘要页 与 ar5iv 全文。

4. 局限与前提

论文摘要没有单列局限章节，但从协议定义可以直接读出三条硬前提：

• 必须有可判定的环境。S、P、D 三类约束的检查依赖工具 schema、状态机和数据流记录。对于没有明确状态模型、或者副作用不可回滚的工具（发邮件、下单扣款、调用第三方写接口），"前缀是否可执行"本身就没有确定答案。
• 必须有轨迹级日志。评测对象是完整调用序列，不是最终回答；只留最终答案的线上系统无法回溯计算 FED 与 RR。
• 点估计的样本量问题。论文自己强调的观察是"最终成功率高的智能体 TER 更低"，这意味着只报成功率的评测在小样本上会把这种差异抹平，需要分层采样才看得出来——这也是作者为什么要用分层样本而不是随机抽样。

另外，恢复率 RR 单看会误导：高 RR 可能是稳健，也可能是错得早、补救得多，需要和 FED 一起读。作者提出的执行前计划检查本身也带成本，多一次验证调用意味着多一份延迟与开销，论文给出的定性结论是"保持有竞争力的最终成功率"，而非零代价。

5. 能不能用

代码与权重：arXiv 页面提供了 PDF、HTML（实验版）与 TeX 源码，未在元数据中给出代码仓库或权重链接，也没有数据集发布说明。也就是说这套协议目前是"照论文自己实现"的状态，不是开箱即用的库。

本地复现需要什么：

1. 一个带工具 schema 与状态机的可执行环境，以及能重置、能回放的状态管理；
2. 智能体的完整工具调用轨迹日志（含每步参数与工具返回值），这是计算 D 类约束的唯一依据；
3. 三个基准的可获取切分：BFCL-v3 多轮、ToolSandbox 需自建分层采样，τ³-bench 用 Airline、Retail 的完整 base split；
4. 一个判分器，把上面的伪代码落到你的环境里，输出 PEC、FED、TER、AUC-PEC、RR 五个量。

值不值得用：如果你的智能体已经能跑出不错的最终成功率，却说不清它是"一次做对"还是"中途炸了又蒙对"，这套前缀级指标是低成本补上的观测层——它不改模型，只改你记什么、比什么。反过来说，如果你的工具调用没有可判定的前置条件，或者线上不留轨迹，那这套协议暂时落不了地。

参考来源

• Prefix Executability: Evaluating Tool-Using Agents Beyond Final Success — arXiv:2610.40444v1
• ar5iv 全文（HTML）
• DOI: 10.48550/arXiv.2610.40444