智能体调用业务系统时，最危险的重试往往发生在结果不明的时刻：提交采购申请后接口超时，智能体不知道申请是否已经写入，于是再次提交。第二次调用成功，不代表任务恢复正常；系统里可能已经有两笔申请。幂等控制要解决的不是“能不能重试”，而是同一业务意图被重复执行时，如何避免重复产生副作用。
控制点应设在实际执行交易的链路上，而不能只依赖智能体判断“这件事做过了没有”。流程发起时，需要为一次业务意图建立稳定的标识，并在后续工具调用、审批与交易记录之间保持关联。接收写入请求的一侧据此识别重复提交：已完成的返回既有结果，仍在处理的保持原状态，明确失败且允许重试的才重新执行。用户确实要发起一笔新申请时，则不能沿用旧标识；区分“重复请求”和“新业务意图”，是设计中的关键边界。
超时尤其不能直接等同于失败。智能体重新发起写入前，应先查询或核对业务系统中的交易状态；若状态仍无法确认，就暂停自动重试，交由既定异常流程处理。审批也需要纳入同一条执行链路：重复收到执行信号，不应绕过审批或重复写入。智能体负责理解请求和提出动作，流程层管理状态与重试，业务系统保存最终交易结果，各层都不能仅凭对话记录推断交易是否完成。
验收幂等控制时，不妨沿一笔业务检查用户重复提交、接口超时后重试、审批后再次触发这几种情况。检查结果不只是“没有报错”，还要确认交易记录没有重复、原申请状态可以追溯，以及确需重新办理时不会被误判为旧请求。只有把这些边界说清楚，重试才是恢复手段，而不是制造返工的新入口。