Agent 工具调用失败怎么办：超时、重试与不确定结果
工具调用不是一句函数执行
Agent 工具调用通常分成几个步骤：模型提出工具名和参数，应用校验请求并执行工具，再把结果反馈给模型。真正访问数据库、发送消息或创建订单的是应用代码。模型输出不能自动获得这些权限。
因此，工具失败要先判断发生在哪一层。参数不符合 schema、业务权限不足、目标服务返回错误和网络超时，需要不同处理方式。把所有错误都交给模型“再试一次”，很容易制造重复操作。
先校验，再执行
为工具提供明确的参数定义，但不要把结构化输出当成完整的业务校验。应用仍要检查必填项、类型、值域、资源归属和用户权限。模型传来的用户 ID、文件路径或 URL 都不能直接作为可信边界。
例如“查询订单”必须使用当前登录用户的可见范围，不能只相信参数中的用户 ID。调用外部地址的工具应限制允许的目标，避免用户或文档内容把服务引向内部管理地址。
工具输出也应结构化，至少区分成功、可修复错误和失败。返回给模型的是必要业务结果与脱敏说明，凭据、内部堆栈和完整敏感响应应留在受控日志中，并按现有规则脱敏。
哪些错误适合重试
参数缺失可以把可修复信息反馈给模型，让它在预算内重新生成参数；权限不足和业务拒绝通常应停止，不能通过换参数反复尝试绕过。
限流、临时服务错误或连接失败，可以按工具特性有限重试，采用退避并遵守服务端的重试提示。每个工作流应有最大调用次数与总时间预算，避免模型不断调用同一个失败工具。只读查询通常更容易安全重试，但仍需控制成本和负载。
超时为什么最容易出错
调用创建工单接口后超时，并不能证明工单没有创建：可能是服务端已经处理完成，但响应没有送达。这时直接再次创建，可能得到两张工单。
对有副作用的操作，应优先使用下游提供的幂等键。幂等键对应同一次业务操作，并在重试中保持不变。若下游不支持幂等，但能按业务请求号查询结果，可以先查再决定。无法确认时，应把状态标成“结果待确认”，停止重复写入，向用户说明需要核对。
不能为了避免重复而随意把每个 Agent 步骤都建成复杂状态机；先保护真正产生副作用的边界，例如发送、创建、删除和支付。
用一个失败场景验证
假设工具是“创建支持工单”。测试时让下游成功保存工单，却故意不返回响应。正确结果应是：系统记录同一个操作标识，通过查询或相同幂等键确认结果；若无法确认，停止并给出待核对状态。测试不应仅检查“发生了重试”，还要检查下游最终只产生一张工单。
另一个关键检查是权限失败：普通用户请求创建无权访问项目中的工单，应在实际执行前被拒绝，并且不能因为模型再次提出调用而放行。
这里描述的是验证方法，尚未提供已执行的工具实现或测试结果。接入具体 API 时，应根据其幂等与查询协议实现并验证。
面试时怎样回答
可以这样组织：“我把模型建议和工具执行分开，在应用层校验权限与参数；只对暂时性错误有限重试；对写操作使用稳定幂等键；超时结果无法确认时停止重复写入，再通过查询或人工核对收敛。”随后给出一个你实际验证过的失败案例，比泛泛地说“加重试和日志”更有说服力。