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要经得起过程评测。