自动化跨线程防重复交付:让未知结果也消耗幂等键
用目标与内容身份建立全局幂等键,并通过未知结果处理和恢复后重检,阻止兄弟任务重复触发同一个外部副作用。
一次自动文件交付把同一份内容发送到了同一目标两次。原请求产生了两个兄弟任务,也就是从同一父请求派生的两个独立执行。第一个任务可能已经完成外部动作,但界面证据无法确认最终文件名,因此结果被记录为未知。第二个任务稍后恢复,只看到自己的本地执行尚未发送,于是再次越过交付边界。
这次重复暴露了智能体与工作流系统中常见的一处缺口。每个执行者的局部状态都可能看起来安全,组合后的外部行为却会产生重复副作用。这里的副作用指改变外部系统状态的动作。修复需要围绕一次外部交付建立全局判断,并明确处理“可能成功、确认不完整”的结果。
这次结果属于可能成功
脱敏证据确认了四项事实:
- 两个任务指向同一个目标,内容字节也完全相同;
- 较早的任务已经触发可能提交文件的控件;
- 界面出现了新的发出项,并且没有可见失败标志;
- 外部应用改变了项目的展示方式,导致任务无法确认交付后的精确文件身份。
这些证据支持 send_status_unknown,无法支持 not_sent。两者对应不同的重试权限。只有证据确认交付边界从未被越过时,后续执行者才可能安全重试;一次可能已经发生的交付需要阻止自动重试。
第二个任务依据的事实范围更窄:当前任务没有发送过文件。这条记录本身正确,但外部目标已经可能受到兄弟任务影响。
幂等身份需要绑定外部副作用
原流程为每个任务保存了执行历史,却没有为多个任务共享的交付动作定义统一身份。重启、跨夜恢复、委派执行或上下文重建,都可能产生一个局部上看起来全新的执行者。
修复使用两个稳定输入组成全局幂等键:目标身份与内容 SHA-256。幂等键是一项由同一交付意图的全部尝试共同复用的稳定标识;规范化后的两个值会在任何交付动作开始前组合成一个键。
目标部分描述副作用落到哪里;内容哈希描述被交付的字节,不依赖本机路径或文件名。能够取得平台分配的会话或接收方 ID 时,应优先使用这些稳定身份。受限的桌面流程可能只有界面中的精确标题,此时需要把标题可能重名写入适用边界。
这个键代表一次预期外部交付。父任务、兄弟任务、委派执行者和恢复任务都必须在打开附件选择器或触发同类外部控件之前解析同一个键。
未知结果同样消耗幂等键
门禁把结果分为三类:
not_sent:证据确认所有可能提交的控件都未触发,可以选择一个新的唯一执行者。sent_verified:外部结果已经确认,全部匹配任务停止。send_status_unknown:提交可能发生,最终确认不完整,全部匹配任务停止。
第三行承担防重复保障。某个任务一旦可能越过外部边界,对应幂等键就已经消耗。超时、界面变化、响应丢失或回读中断,都不会重新授予自动重试权限。
如果任务记录中出现“附件选择器已经接受文件”或“发送控件可能已经触发”等证据,即使最终状态标签缺失,也要应用同一规则。外部副作用证据的优先级高于局部状态摘要。
选出唯一执行者,并在边界附近重检
任何界面操作开始前,工作流先枚举能够访问的父任务、兄弟任务、委派任务和恢复任务,找出可能共享同一幂等键的记录,再执行以下判断:
- 任一匹配记录已经消耗键,当前任务立即停止。
- 多个匹配任务仍在运行时,只保留一个执行者;受限实现选择最早符合条件的任务。
- 历史结果为
not_sent时,仍要有证据确认交付边界没有被越过。 - 相关历史缺失、不可读或无法排除其他执行者时,任务按故障关闭处理;无法证明安全,就不再继续。
长任务只在开始时查询一次仍然存在风险。完整门禁要在进程重启、跨夜继续、工具超时、上下文重建或其他中断后重新执行;打开附件选择器前再查一次,触发提交控件前还要再次检查。任何状态变化都会让早先的判断失效。
这些重检可以缩小竞态窗口,但任务历史搜索没有原子性。要求严格单次执行的系统,应在外部请求可能被接受之前,通过事务型共享存储认领幂等键,或使用服务端提供的幂等令牌。
主动重发需要新的授权范围
用户在得知首次交付很可能成功后,仍可能明确要求再发送一份。此时应创建新的交付意图并记录知情授权,不能把旧任务解释成普通重试。
新的交付意图仍然只能选择一个执行者,也要执行相同的边界前检查。状态中需要同时保留两项事实:第一次交付的幂等键已经消耗;用户又明确授权了一次额外副作用。
验证覆盖失败路径,不产生新的外部交付
实现同步更新了交付规则和面向调用者的元数据,并通过技能结构校验。七个只读场景覆盖了门禁分支:
- 没有匹配历史任务;
- 两个匹配任务同时存在;
- 历史任务已经证明
not_sent; - 历史结果为
sent_verified; - 历史结果为
send_status_unknown; - 跨夜恢复时兄弟任务可能已经发送;
- 任务历史不可用或无法读取。
测试还覆盖了知情重发,并继续限制为单一执行者。验证过程没有打开外部应用,也没有传输文件。现有证据证明了规则分支和元数据契约,未证明并发搜索已经获得事务原子性。
经验与限制
幂等设计应描述外部副作用,不能只描述尝试执行它的工作线程。目标身份与内容哈希可以为文件交付形成实用的全局键;只要证据表明边界可能被越过,未知结果就要消耗该键。
缺少原子共享存储时,任务历史检查可以形成故障关闭保护。两个执行者若在极短时间内同时通过最后一次检查,系统仍有竞态风险。更强的实现需要事务型键认领、外部服务提供的幂等能力,或带隔离令牌的租约;隔离令牌使用递增版本让旧执行者失去写入权限。
内容哈希也无法表达全部业务意图。同一字节被主动交付两次可能合理,两个相同的界面标题也可能代表不同接收方。周边系统能够提供稳定平台身份和显式重发授权时,应把它们一并纳入交付协议。
先说明系统,再说明症状
如果需要生产排障、DevOps 交付或物流系统集成协作,请提供当前表现、预期结果、受影响环境、可用日志或数据样例,以及发布限制。我会从现有证据开始判断。
通过邮件开始