业务副作用幂等

让同一被授权动作在重试与恢复中只产生预期效果。

幂等针对的是同一个业务动作，而非同一条网络请求。工具可能已经成功创建工单，但响应在途中丢失；如果恢复后重新生成ID再创建，业务就重复发生。稳定操作身份必须先于外部调用保存，并在重试、进程恢复和必要的Run切换中保持。

理想情况是接收端支持幂等键，并检查相同键是否对应相同规范化参数。已完成动作返回原结果；参数改变不能沿用旧键。没有原生支持时，可以利用目标唯一约束或可查询的业务标识实现去重。无法可靠查询或去重的高风险动作，要暂停对账，不能声称客户端保存过一个UUID就已经exactly-once。

幂等键不能过宽。用户明确要求再次发送、创建第二张合法订单或对新资源版本执行操作，需要新业务身份；不能为了防重复而吞掉新的合法工作。批准hash、operation_id和attempt_id分别代表授权内容、业务动作和网络尝试，不宜混用。

持久工作流也可能重跑Activity，外部效果仍由应用合同保证。工具调用ID有助关联，但模型request_id不能直接替代业务身份。验证应在提交前、外部成功后和回执落盘前分别制造故障，再重试与恢复；对照外部记录数量、参数和receipt，而不是只检查本地日志是否去重。

操作参数的规范化规则也应版本化。日期格式、金额精度、收件人集合顺序等差异，可能使同一动作产生不同hash，也可能把实质不同的动作错误合并。应以业务含义定义相等性，并保留原始批准内容；这类规则适合确定性代码与边界测试，不应交给模型临场判断。

幂等记录需要明确保存期限。保留期短于客户端重试或工作流恢复窗口，会在旧任务重放时重新产生效果。

实践重点：操作ID先持久化；接收端唯一键或幂等接口；跨Run沿用同动作身份。

验证抓手：工具成功后断网再重试，检查是否只生效一次。

常见误区：每次网络尝试生成不同ID，或把所有合法动作复用一个ID。

Temporal：执行状态与外部副作用；Agents SDK：Model接口和call ID约束。