两个工作者同时写入了同一个键。两次写入都“成功了”。其中一个消失了。

如果你运行一个带有并行工作者的编排器，或者共享状态（内存存储、决策文档、计划文件）的长时间运行智能体，这里是我在多智能体设置中经常发现的两种故障模式。它们从外部看起来一模一样：运行正常结束，然后在下游某个地方，系统表现得好像更新从未发生过。两者最初都被归咎于模型。但两者都不是模型的问题。 **故障1：并发丢失更新。** 一个规划器派发了六个工作者，每个工作者将其结果写入一个共享键。两个工作者在同一瞬间完成。两次写入都返回成功。但其中一个随后就不见了。典型的最后写入获胜，但智能体使其比普通服务更糟糕：没有人会怀疑地重新读取文档。下一个提示只是继承了任何幸存下来的内容，流畅地对其进行推理，而差距在三步之后才显现为“智能体忘记了X”。 **故障2：僵尸写入者。** 一个长时间运行的智能体在持有写入授权时中途停滞。恢复机制（正确地）回收了授权，以便其余进程不会被阻塞。一个小时后，停滞的进程醒来并完成了它的写入。这就是陷阱：如果在此期间没有其他东西接触过该工件，版本号仍然匹配。所有版本检查都通过。过时的提交覆盖在了系统早已越过的状态之上。 我最终从写入路径中想要的东西，并且最终构建了： * 并发的同键写入者解析为恰好一个获胜者。失败者会得到一个类型化的、可重试的冲突（重新读取、重新计算、再次提交），而不是静默丢弃。 * 被回收的写入者会被栅栏化。每次回收都会增加一个所有权纪元，每次声明都会记录其所属的纪元，并且提交会原子性地检查两者以及版本持久化。即使版本号从未变动，僵尸写入也会被拒绝。 这些保证在TLA+中进行了模型检查。检查器在CI中运行，每个规范都携带一个已记录的突变（删除守卫），该突变必须使检查器变红。如果删除守卫没有使模型失败，那么该不变量就不是承重的。 范围说明，以免有人安装后期望更多：一个协调器，一个主机，并且只有通过它的写入者。跨主机未实现。我将其限制在有人真正需要时才开放。它运行在跨进程共享的普通文件上，带有针对 LangGraph、CrewAI、AutoGen 和 OpenAI Agents SDK 的适配器。仓库中有一个确定性的、无需键的丢失更新模式复现。 如今在生产环境中，人们如何处理对共享智能体状态的并发写入？重试和希望？架构上的单写入者？还是尚未遇到问题？同样好奇你们遇到了哪些这个方案无法捕获的故障模式。