AI接入工单、监控或配置系统后，常见异常是工具没有及时返回结果。最直接的处理是“再试一次”，但超时只说明调用方没有按时收到响应，并不能证明远端没有执行。
对于状态查询，重复读取通常风险较低；对于建单、发送通知、修改配置等动作，盲目重试可能造成重复任务或重复变更。因此，工具调用首先要管理执行状态，再谈重试次数。
一、把工具分成读操作和写操作
读操作包括查询状态、检索文档、读取脱敏日志。写操作包括创建记录、发送消息、修改参数和删除数据。不同类型要使用不同的超时和重试策略，不能套用同一个默认配置。
部分看似查询的接口也可能有副作用，例如触发扫描或生成报告。登记工具时，应由接口负责人确认其行为、权限、限流和幂等能力，不能仅靠名称判断。
二、区分三种结果，而不是只有成功或失败
一次调用至少可能产生三种状态：已确认成功、已确认失败、结果未知。连接建立前失败，与请求已提交但响应丢失，后续处理方式不同。
AI对客户的表述也要与状态一致。“系统未按时返回，正在确认执行状态”比“操作失败，马上重试”更准确。结果未知时，应暂停后续依赖步骤，避免在错误前提上继续执行。
三、写操作使用幂等键或任务编号
发起写操作前，为同一业务意图生成唯一标识，并保留到任务结束。重试时沿用该标识，让服务端识别这是同一请求，而不是新的操作。
如果接口不支持幂等，应先通过业务编号查询是否已创建成功，并使用任务表记录提交、执行和完成状态。本地任务表可以限制并发提交，但不能证明远端没有完成；如果查不清状态，不应自动补交写操作。不能仅依靠AI阅读聊天记录来防止重复，因为上下文可能被截断或重新生成。
写操作应限定在已批准的权限和流程内；生产配置、权限变更和删除等高影响动作，应设置人工审批及回滚条件。结果未知时进入人工确认，不能通过连续重试“碰运气”。
四、重试要有间隔、上限和退出条件
对可安全重试的请求，可以采用逐步增加等待时间并加入随机抖动的方式，避免多个任务在同一时刻反复冲击故障服务。遇到服务端限流，应遵守返回的等待建议。
业务参数错误、权限不足和明确拒绝，通常不应原样重试；需要先修正输入或权限。连续失败达到上限后，进入降级或人工队列，而不是让模型不断改写参数再次提交。
重试期间要保留总体截止时间。单次调用没有超时，不代表整个客户请求可以无限等待。
五、为后续步骤设置“完成门槛”
例如只有确认工单创建成功并拿到编号，才发送包含编号的通知；只有确认配置变更完成并验证结果，才记录为已解决。
系统应显式检查这些条件，而不是让模型根据一句模糊返回值自行判断。异步任务使用轮询或回调确认状态，并验证返回任务编号与原请求一致。
如果某一步需要撤销，预先定义补偿动作和审批条件。删除一个重复草稿与回滚生产配置，风险不同，不应使用同一套自动补偿策略。
六、日志要能还原一次调用
至少记录请求标识、工具名称、脱敏参数、开始与结束时间、超时类型、重试次数、返回状态、审批记录和最终结果。日志中不得保存不必要的凭据、客户原文或完整敏感数据。
复盘时重点看结果未知比例、重复提交数量、重试成功率、调用总耗时、人工介入次数和恢复后的积压任务。重试成功率高，也可能意味着服务本身不稳定，不能单独作为好结果。
上线前应模拟响应丢失、服务限流、重复回调和任务完成后连接断开等情况，验证系统会不会重复执行、错误报成功或遗失任务。
可靠的AI工具调用，不是遇到异常后更积极地尝试，而是知道当前状态、下一步依据和停止条件。先分清“没有收到结果”与“没有执行”，自动化才不会把一次网络异常放大成业务错误。
