先记住这个答案
可以先判断所选工具是否适合当前目标和允许范围，再检查参数是否符合结构契约与业务语义，最后单独检查工具执行结果。工具选错是能力或操作意图不匹配；参数错误则是在合适工具上填错字段、类型、对象或单位。结构校验通过仍可能传错目标标识，工具返回失败也未必是模型传参错误。评分要接受合理的替代工具路径，并保存当时可用信息作为判断依据。
- 选择、结构、业务参数与执行故障应分层记录
- 参数合法不等于目标正确，语义校验不可省略
- 评估基于当时可见信息，避免用事后答案苛责合理探索
先检查工具承担的操作是否正确
例如目标是读取构建状态，Agent 却选择重新触发构建，属于操作意图不同，即使参数格式完全合法也不是正确调用。如果使用状态查询工具但填入另一个项目的标识，则主要是对象参数错误。两者需要不同改进：前者可能要改工具区分，后者要改实体解析与证据传递。
工具库可能存在多种有效方式，例如按任务标识查询或先列任务再筛选。评估不应把参考实现中的唯一工具名当作全部正确答案，而要检查它是否能在允许范围内获取所需信息，以及是否产生了不必要的副作用。
区分结构错误与语义错误
缺少必需字段、把数组传成字符串属于结构问题，可以由 Schema 校验识别。将毫秒误写成秒、使用过期版本号或把显示名称当成内部标识，则需要业务语义检查。不能把通过 JSON Schema 当成参数已经正确的证据。
还应记录字段来源：来自用户明确输入、前一步工具结果还是模型推断。若上游返回了含糊名称，Agent 可能需要先解析唯一对象；如果环境根本没有提供必要标识，应把信息缺口与随意猜参数区分开，不能要求模型凭空知道答案。
把诊断结果映射到修复措施
对选择错误，可以检查工具名称、描述和能力重叠；对结构错误，可以收紧字段约束并返回清楚的校验提示；对语义错误，可以增加单位说明、标识解析或版本检查。只对所有错误统一增加重试，可能让同一个错误被重复执行。
统计时可以保留多标签，但确定一个主要根因，避免一条调用被重复算成多个独立失败。还需区分首次错误是否被正确恢复，以及最终任务是否完成。这样既能观察工具使用能力，也不会把有效纠错过程直接等同于整次任务失败。
容易答错的地方
- 返回非成功状态就算参数错误
- 权限变化、服务超时和业务条件冲突都可能导致失败，需要结合请求与返回证据归因。排查“Agent 工具选择错误与参数错误评估”时还要核对输入、版本和执行顺序，并用反例确认修复后的边界。
- 只检查参数的 JSON 格式
- 合法对象仍能指向错误实体。关键标识、单位、范围和版本应有对应的语义验证。排查“Agent 工具选择错误与参数错误评估”时还要核对输入、版本和执行顺序，并用反例确认修复后的边界。
面试官还会怎么问？
调用了更慢但正确的工具算选错吗？
如果完成目标且符合约束，通常应在效率维度扣分或标记优化机会，不能自动归为功能选择错误。针对“Agent 工具选择错误与参数错误评估”，还应保留最小复现、预期结果和失败路径，避免只凭一次现象下结论。
多个参数都错应该怎么计数？
可在调用层记录是否出错，在字段层记录错误分布；分别说明分母，避免把字段错误率与调用错误率混用。
模型能否自己审查传参？
可以作为补充，但关键结构和业务条件应由工具端执行确定性校验，不能只依赖再次生成一段自我确认。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。