Agent 规划评测：计划漂亮不代表执行稳定
一、Agent 很会写计划
很多 Agent 在回答时能列出漂亮步骤：先分析需求，再调用工具，再验证结果，最后输出报告。但真正执行时，可能工具选错、参数缺失、状态丢失、重复尝试或遇到错误不会恢复。一个典型失败模式：Agent 计划里写"先用文件搜索定位相关代码，再读取文件分析"，但执行时跳过搜索，直接猜测文件名读取，命中空文件后编造了分析结果。
Agent 规划评测不能只看计划文本，要看计划是否能稳定执行。
二、评测要拆成两层
flowchart TD A[Agent 任务] --> B[计划质量] A --> C[执行质量] C --> D[工具调用] C --> E[错误恢复] C --> F[最终结果]计划质量关注步骤是否合理，执行质量关注工具调用是否正确、能否处理异常、最终结果是否满足任务。
agent_eval: plan_completeness: true tool_accuracy: true recovery_ability: true final_success: true这四项缺一不可。分离计划与执行的用意在于：计划漂亮但执行不稳定的 Agent 在生产中比完全不会计划的更危险——它会给出看似合理但实际错误的结果，让用户更难识别问题。
三、工具调用要计成本
Agent 能完成任务，但调用了 30 次工具、重复读取同一文件、反复走错路径，说明规划不稳定。评测要记录工具次数、失败次数和无效动作。
{ "tool_calls": 12, "failed_calls": 2, "redundant_calls": 3, "final_success": true }同样成功的任务，路径越短、错误越少，Agent 越可靠。
四、错误恢复是关键
真实环境里工具会失败：文件不存在、接口超时、权限不足、返回格式变化。Agent 评测要故意注入这些异常，看它是否能换方案。
fault_injection: missing_file: true timeout: true permission_denied: true malformed_response: true如果 Agent 遇到一次错误就胡乱猜答案，说明它不适合生产任务。
最后，评测报告要保留轨迹。计划、每次工具调用、观察结果、决策理由都要能回放。没有轨迹，很难改进 Agent。
规划评测还要看是否过度规划。有些简单任务只需要一次工具调用，Agent 却先写长计划、拆很多步骤、反复确认上下文。过度规划会增加延迟和成本，也会让用户觉得系统拖沓。
planning_efficiency: min_required_steps: estimated actual_steps: measured over_planning_penalty: true还要评估计划和执行是否一致。Agent 计划里说要先验证输入，实际却直接执行；计划里说会回滚，失败后没有回滚动作。这类不一致比计划写得差更危险，因为它制造了虚假的安全感。
对于多工具 Agent，还要检查工具选择边界。能用只读工具解决的问题，不应该调用写入工具；能用本地缓存回答的问题，不应该调用外部接口。评测要把权限最小化作为指标。
最后，Agent 评测最好包含长任务。短任务成功不代表它能在 20 步之后仍然保持目标、状态和约束。
还要评测中断恢复。真实 Agent 可能因为服务重启、用户暂停、工具超时而中断。恢复后是否能从任务状态继续，而不是重新开始或重复执行危险动作，是生产级能力。
interruption_eval: pause_after_step: 5 resume_from_state: true avoid_duplicate_write: true评测集还应包含不可完成任务。比如缺少权限、资料不存在、目标互相矛盾。可靠 Agent 应该说明无法完成，而不是编造执行结果。
五、总结
Agent 规划评测要同时评估计划完整性、工具调用效率、异常恢复和最终任务成功。
计划漂亮不代表执行稳定。真正可靠的 Agent，要经得起过程评测。
