如何评估 Agent 的规划能力？

简化版

评估 Agent 规划不能只看最终任务有没有完成，还要检查计划是否覆盖必要子目标、依赖顺序是否正确、动作能否由现有工具执行、是否有无用或高风险步骤，以及环境变化后能否局部重规划。应在固定初始状态的可重放环境中，结合最终成功率、计划质量、执行效率和故障恢复指标，并用消融实验区分“计划好”与“工具碰巧救回来”。

详细版

规划评估分为四层：目标层看约束和交付物是否被覆盖；结构层看依赖图、顺序、并行性和死节点；执行层看工具选择、参数、步骤数、成本与副作用；适应层看工具失败、信息变化和用户修改目标后能否正确重规划。

不能只拿模型生成的计划文本与参考答案做字符串相似度，因为同一目标可能有多条正确路径。更可靠的是由模拟器或沙箱执行计划，以状态谓词定义成功，并记录每个节点的前置条件和结果。对于开放任务，再由带量表的人评或校准后的评审模型补充判断。

Plan Score = Goal coverage + Dependency validity + Executability
           + Efficiency + Recovery - Risk violations

测试集应包含正常任务、信息缺失、不可达目标、工具故障、动态环境和提示注入，并固定工具版本、随机种子与初始状态。报告平均成功率之外，还要给 P95 步数、无效动作率、重规划收益、成本和置信区间。

完整版教学

一、任务成功不等于规划优秀

一个 Agent 可能计划很差，却靠不断试错最终成功；也可能计划正确，但工具偶发故障导致失败。只用最终成功率，会把规划、执行器、工具可靠性和环境随机性混成一个数字。

规划评估要回答两个问题：在已知信息下，这份计划是否合理；执行出现新信息后，Agent 是否正确更新计划。前者评价静态结构，后者评价动态适应。

记忆钩子：结果指标告诉你“到没到”，过程指标才解释“为什么到、花了多少、是否可重复”。

二、先把成功写成环境状态

“完成采购”不能由模型自行声明。测试环境应把成功定义为可检查谓词，例如订单存在、SKU 正确、金额不超预算、且没有重复订单。多个约束必须同时满足。

success = order_created
       AND sku == requested_sku
       AND total_price <= 500
       AND duplicate_orders == 0

对不可达任务也要有正确行为：若库存为空，优秀计划应在验证后停止并报告，而不是为了提高表面完成率选择错误商品。因而评测标签除了成功，还应包含合理拒绝和正确澄清。

三、目标覆盖率检查有没有漏项

把任务拆成必须满足的子目标与硬约束，再检查计划是否覆盖。一次差旅安排可能需要交通、住宿、时间冲突检查和总预算；计划只订了机票，即使那一步执行完美，覆盖率也不合格。

若 8 个必需项中覆盖 7 个，简单覆盖率是 7/8=87.5%。但安全约束不应和普通格式要求同权，可以给“不得超过预算”更高权重，并把违反硬约束直接判为失败。

覆盖判断要基于语义和预期产物，不用关键词命中。计划说“处理住宿”却没有查询、选择和确认产物，仍可能是假覆盖。

四、依赖正确性检查顺序和并行

计划节点有前置条件。先发送邮件后生成附件、先发布后运行测试，都是依赖错误。把计划转成 DAG 后，可以检查环、缺失依赖、无法到达节点和错误并行。

问题	例子	后果
前置缺失	未登录就读取私有文档	执行必然失败
顺序颠倒	付款后才核对金额	产生风险副作用
错误并行	两步同时写同一文件	竞态与覆盖
循环依赖	A 等 B，B 等 A	永远无法调度

依赖评分可以计算正确边占参考必要边的比例，但不要求与唯一参考图完全相同；只要满足环境前置条件，替代路径也应得分。

五、可执行性检查计划是否落地

“分析市场趋势”不是可直接调度的动作，除非系统有对应工具和输出契约。每个计划节点应能映射到已注册工具、子流程或人工节点，并提供可满足的参数。

评测可在不真正产生副作用的 dry-run 模式中验证工具名、参数 Schema、权限和资源是否存在。若 10 个节点中 2 个使用不存在的工具，可执行率最多 80%。

还要识别幻觉依赖：计划假设网页一定有 API、用户一定有管理员权限，或工具可以访问未提供的数据。这些假设应在计划中变成明确的检查节点。

六、效率指标揭示暴力试错

两条路径都成功时，步骤、token、费用、墙钟时间和重复动作决定哪条更好。可把最短已知可行路径作为参考，计算路径效率：

efficiency = reference_cost / actual_cost

若参考路径需 5 次调用，Agent 用了 12 次，在调用单价相近时效率约 5/12=41.7%。但最短不一定最好：多一次安全验证可能值得，因此应把必要验证排除在浪费之外。

无效动作率、重复工具调用率和最终丢弃分支成本，往往比总步骤更能定位规划问题。

七、动态重规划要用扰动测试

真实环境会变：工具超时、价格变化、文件被其他人修改、用户追加约束。评测可以在固定步骤注入扰动，看 Agent 是否识别受影响节点、保留仍有效产物并局部更新计划。

例如第三步让首选航班售罄。正确行为是重新搜索交通并重新检查总预算，不必重做已经确认的会议时间。若 Agent 从头执行全部流程，虽可能成功，但重规划效率差；若继续购买旧航班，则状态理解失败。

比较“无重规划”和“允许重规划”的成功率与额外成本，可以量化重规划真实收益，而非只看模型输出了一份新列表。

八、让实验可复现并拆分误差

工具和网页持续变化会让结果无法比较。离线评测应使用快照、模拟器或记录回放，固定初始状态、工具版本、超时规则和随机种子；线上再用影子流量验证现实分布。

至少重复运行多次并报告置信区间。某 Agent 在 100 个任务成功 72 个，不能凭一次结果断言比成功 70 个的版本更好；差异可能来自采样波动。

做消融也很重要：固定计划只换执行模型，或固定执行器只换规划器，才能知道提升来自哪里。否则工具升级可能被误记为规划能力提升。

九、常见误区与追问

• 误区：最终成功率高就说明规划好。 暴力试错和工具容错可能掩盖坏计划。
• 误区：计划与参考文本越像越正确。 同一任务存在多条可行路径，应验证状态与依赖。
• 误区：最短计划一定最好。 必要验证、审批和回滚步骤虽然增加长度，却降低风险。
• 误区：只测静态计划即可。 Agent 的核心能力还包括观察变化后的局部重规划。
• 误区：评审模型给高分就是客观结论。 需要校准、人评抽检和可执行环境证据。
• 追问：没有唯一参考计划怎么办？ 定义成功状态、硬约束和工具前置条件，允许所有满足条件的路径。
• 追问：如何区分规划和执行错误？ 记录节点契约并做消融，分别固定规划器与执行器测试。
• 追问：开放任务怎样评估？ 用明确量表评价覆盖、证据和风险，再结合人评与端到端结果。

十、加强记忆

规划评估记住“目标、结构、落地、效率、适应”：先用环境谓词定义真正成功，再检查必需目标和硬约束是否覆盖；把计划转成依赖图检查顺序、环和并行；dry-run 验证工具与参数；用步骤、成本和无效动作衡量效率；最后注入工具失败与环境变化，看能否局部重规划。只有把结果和过程拆开，才能知道 Agent 是会规划，还是只是碰巧做成。