把同一笔业务执行两遍，是混合编排里最容易被低估的故障类型。它不表现为报错，也不表现为流程中断，而是安静地在系统里留下两条一样的记录，直到对账时才发现。
RPA 时代的重复执行主要来自少数几个源头：定时任务重跑、补偿脚本被手工触发、上游文件重复投递。应对方式也相对直接——把幂等做在批处理边界上，用业务单据号加唯一约束挡住重复写入。触发源少且可控，问题基本收敛在运维层面。
智能体进来之后，触发结构变了。它由目标驱动，失败时会自行决定重试，工具调用超时后可能重新发起，任务队列本身也往往是至少一次投递语义。更麻烦的是重试的粒度：智能体的重试是语义级的——“这件事看起来没成，再做一次”，而不是传输层的“请求超时，重发一次”。这意味着重复会直接落在业务操作上，而不是被网关或连接层吸收掉。
幂等键不该由执行层自己生成
执行层如果自己生成幂等键，它能保证的只是“这次调用没有被记录两次”，识别不了“这已经是同一笔业务第三次进来了”。键必须来自业务实体的身份——单据号、订单号、业务流水号这类在执行之前就存在、且重复触发时保持不变的东西，由发起判断的那一方在构造任务契约时写入，执行层只负责校验和冲突处理。
用请求 ID、时间戳或随机数充当幂等键，等于没有幂等：每次重试都是新键，去重逻辑永远命中不了。
去重需要落在三个位置
任务契约层负责携带幂等键并在入队时拦截重复；执行层维护已处理键的记录，并且要能区分“处理中”和“已完成”两种状态，否则并发重试会同时穿过检查；数据层用唯一约束兜底。三层不能互相替代——只做应用层去重，进程重启或并发下就会漏；只做数据层约束，重复被挡住了却说不清为什么重复，排查时缺上下文。
配套的是窗口设计。幂等记录的保留时间要覆盖最坏情况下的重试跨度，包括人工复核挂起、批量补跑、上游补单这些非典型路径。窗口开得太短，重复就会恰好落在窗口之外，反而更难定位。
还有一种情况需要单独处理：同一个幂等键带着不同参数到达。这不是重复请求，是业务状态冲突，应当拦截并告警，而不是静默返回上一次的结果。把它当成重复吞掉，掩盖的是上游判断逻辑出了问题。
幂等记录本身也是审计材料。谁触发、何时到达、携带什么键、最终执行结果是什么，这些信息天然构成可回放的链路，混合编排里相当一部分追溯工作可以直接建立在这张记录之上，不必另建一套日志体系。
判断一条混合编排是否具备上线条件，可以回到几个具体问题：幂等键是否取自业务身份而非调用痕迹；重复请求是被明确识别，还是被静默吞掉；同键异参是否有拦截和告警；记录的保留期是否覆盖最长重试链路。这几条答不上来，说明幂等还停留在执行层的补丁层面，而不是流程设计的一部分。