Agent开发中，接口超时后再次执行同一个动作，可能产生两笔业务记录。超时只说明调用方没有得到明确结果，不代表服务端没有执行。区分重试与重新提交，需要同时识别业务意图、请求身份和已经发生的状态变化。
假设用户要求为一个订单创建发货任务。Agent发出请求后连接中断，此时可能是请求没有到达，也可能是任务已经创建、响应没有返回。如果直接生成新请求再次提交，系统就有机会创建第二个任务。恢复流程应先使用原任务标识查询结果，再决定继续等待、重试原请求，还是交给人工处理不确定状态。
同一个业务意图的重试，应当携带能够被服务端识别的稳定标识。这个标识不能每次调用都随机变化，否则服务端看到的始终是新动作。与此同时，标识也不宜仅使用宽泛的订单号，因为同一订单可能确实需要不同操作。可以把动作类型、业务对象和本次操作身份关联起来，使“重复发出同一请求”与“新增另一次操作”能够区分。
幂等机制的细节必须查具体接口。Stripe官方接口文档说明，其幂等请求机制会保存首次请求结果，并检查重复使用键时的参数一致性。这个例子说明，幂等不仅是客户端记住一个字符串，还需要服务端提供相应语义。不能把某个服务的保留时间、错误处理方式和适用接口范围，直接套用到所有系统。
重新提交则意味着业务意图已经改变，或用户明确要求再做一次。例如原任务取消后重新安排另一仓库发货，不能仅因商品相同就沿用原请求。新动作应有新的操作身份，同时关联原任务，便于解释为什么出现两条记录。是否属于新动作，应由业务状态决定，而不是由模型看到“再试一下”四个字自行猜测。
取消操作也需要状态约定。用户在等待时取消，不一定能撤回已经到达服务端的请求。系统应区分停止后续动作与撤销已发生业务，并查询最终结果。若需要补偿操作，应使用单独身份和授权，而不是修改原请求记录假装没有执行。这样日志能够解释原动作与后续处理之间的关系，避免恢复时再次触发。
客户端也要保存必要状态。记录应包括任务身份、参数摘要、提交时间、服务端返回的业务编号和结果确认状态。这样，Agent重启后仍能判断之前是否已经提交。仅把状态保存在对话文字里，容易在上下文缩短或任务切换后丢失，也不利于多个执行进程共享同一事实。
失败类型会影响恢复方式。参数校验失败需要修正输入，权限失败需要处理授权，短暂网络故障才可能适合按约定重试。对已经产生外部影响的动作，应优先查询业务结果；对结果仍不明确的情况，保留不确定状态，不要用“失败”掩盖可能已经发生的写入。重试次数也应有限，避免持续制造负载。
验收可以模拟响应丢失、执行进程中断和重复点击，检查最终只产生预期的业务记录。测试时同时观察任务日志与目标系统，而不是只看Agent是否显示成功。当同一操作能够被识别、查询和解释，恢复机制才不会把技术上的重跑变成业务上的重复执行。