你有没有想过这样一个问题当一个正在自动处理你银行转账的AI程序被强制关机重启之后它会不会把你的钱转两次这不是一个假设。这是一篇论文用五个主流AI智能体框架、三种数据库后端、真实的SIGKILL强制杀进程实验一点一点验证出来的真实答案。而答案比大多数人想象的要糟糕得多。一个所有人都默认成立、却从没人验证过的承诺现在几乎所有做AI智能体agent的开发团队都在用一类工具LangGraph、CrewAI、LlamaIndex Workflows 这些工作流框架。它们共同的卖点是持久化说白了就是你的AI程序在执行到一半时可以暂停等人工审批或者哪怕服务器崩了重启之后也能接着跑不用从头再来。这个承诺听起来朴素但背后藏着一个极其棘手的问题那些已经执行完的动作恢复之后到底会不会重来一遍如果你的AI智能体只是在读写文本、生成摘要重复执行一次问题不大顶多浪费点算力。但现在的AI智能体开始被授权去做真正有后果的事情转账、发邮件、写文件、下单。这时候重复执行就不再是小毛病而是真金白银的损失。论文作者做了一件很基础但此前没人做过的事把五个框架的官方文档摆在一起对比。结果发现三个框架给出了三种互相矛盾的说法。CrewAI 的检查点功能文档明确写着恢复时不会重新运行已完成的工作。LlamaIndex Workflows 的文档却告诉用户某个模式下代码会被重新执行所以你得自己保证前面的代码重新执行也是安全的。而 LangGraph 采用的是记忆化策略声称已完成的任务结果会被记住不会重复执行。三个框架三套完全不同的承诺。而当作者实际去测试时发现更让人意外的事实**三个框架里有两个连自己文档里写的承诺都没做到。**这就是这篇论文的起点一个开发者如果想把一个涉及真实资金操作的AI工作流从一个框架迁移到另一个框架他没有任何类型系统、任何签名、任何文档能告诉他这两个框架的恢复语义是否一致。这个信息真空就是一个个GitHub issue一次次线上事故的源头。把恢复这件事拆成六个必须回答的问题论文作者没有急着去抓框架的bug而是先做了一件更根本的事定义什么样的行为才算是正确地恢复。这套定义被称为**RESUME CONTRACT恢复契约**包含六条核心性质外加一条协议层面的补充要求。第一条是**前缀延续性PCPrefix Continuation**恢复必须从已经持久化记录的那个断点状态开始不能凭空捏造一个初始状态去重新推导。 前缀延续性*简单说就是接着往下走而不是从头再走一遍哪怕走的路径和之前一样状态也必须是从真实记录里读出来的不能是重新猜的。第二条是**效果恰好一次EOEffect Exactly-Once**每一个带有副作用的任务在一次分支执行里最多只能真正触发一次外部效果。第三条是**分叉确定性FDFork Determinism**如果同一个中断点被两次不同的输入值恢复比如人工审批先后给了同意和拒绝两个答案这两次恢复必须走向不同的分支结果。第四条是**检查点有效性CVCheckpoint Validity**任何被持久化保存的状态记录都必须符合预定义的数据结构格式错误的数据不应该被悄悄存进去。第五条是**消费一次COConsume-Once**一个中断点只能被一次恢复消费掉之后重复发来的恢复请求应该是无效的。第六条是**恢复确定性RDRecovery Determinism**从完全相同的持久化记录出发两次独立的恢复过程必须做出完全相同的决策。这六条性质里第三条和第五条之间藏着一个有意思的逻辑矛盾。想象你负责审批一笔付款你回复同意。过了一会儿你改变主意又发了一次拒绝。系统应该怎么办从分叉确定性的角度看第二次的拒绝应该被当成一次全新的分叉请求走向不同的结果。但从消费一次的角度看这个中断点已经被同意消费过了第二次请求应该是无效的、被忽略的。这两个要求字面上完全对立。论文用一个数学证明引理1说明了这一点**如果协议本身没有办法区分这是一次故意的重新分叉和这只是重复发送的旧消息那么无论用什么算法都不可能同时满足分叉确定性和消费一次这两条性质。**这就好比你收到两条一模一样的短信一条是朋友手滑重发的一条是他改了主意重新发的内容却字面相同。如果短信本身没有携带任何这是第几次发送的标记你压根没法区分这两种情况无论你多聪明都做不到。所以论文引入了第七条性质**分叉意图可表达性FIFork-Intent Expressibility**。它要求协议本身必须能够表达这是一次故意的分叉这个信号比如带一个明确的序号或标志位。这不是一条行为性质而是一条对接口设计的硬性要求**如果协议连我想分叉这句话都说不出来那底层实现就只能靠猜猜错了就会出问题。**而LangGraph恰好就是那个说不出这句话的协议。它的恢复地址checkpoint_id在官方文档里被赋予了两种含义一种是创建分支的时间旅行一种是重放。这种文档层面的双重解释本身就是FI缺失的活生生的例子。用一台数学显微镜照出问题的根源光提出概念还不够作者接下来做了一件更硬核的事把整套契约写成TLA形式化规范用模型检测器TLC做穷举验证。 TLA*一种用来精确描述系统状态和状态转换规则的形式化语言由图灵奖得主Leslie Lamport发明亚马逊内部大量使用它来验证分布式系统设计。 TLC*TLA配套的模型检测工具能够自动穷举一个系统在给定范围内所有可能的状态检查是否有任何一种情况违反了你定义的规则。作者建了一个参考语义模型也就是理论上完全正确、六条性质都满足的理想版本。TLC对这个模型做了穷举检查在扩大规模之后跑出了740万个不同状态全部合规零错误。接着作者往这个模型里注入了六种故障开关每一种都对应一个真实框架里观察到的具体问题比如恢复时从任务1重新开始执行对应CrewAI的行为、第二次恢复被强行服务成第一次的结果对应LangGraph的#6663号问题。每打开一个开关模型就会在4到7步之内自动找到一个具体的违规场景白纸黑字地展示出问题究竟是怎么发生的。更进一步作者还做了一件很讲究的事把每一个故障开关拿去和全部六条性质逐一交叉检验一共39次运行。结果发现有的故障只破坏它该破坏的那一条性质比如分叉故障只破坏分叉确定性但有的故障会连带破坏好几条性质比如恢复决策不确定这个故障会同时破坏效果恰好一次、前缀延续性和恢复确定性三条。这个交叉验证矩阵回答了一个可能有人会问的质疑这些故障开关是不是照着答案反推出来的专门设计成刚好破坏对应的那条性质如果真是这样那么每个开关理应只破坏自己的目标性质其他格子应该全是干净的。但实际结果是有四行故障的交叉格子里出现了意外的违规说明这些故障开关反映的是真实的机制问题而不是凑出来的标签。论文还进一步证明了这六条性质里有五条EO、PC、FD、CV、RD在逻辑上彼此独立也就是说满足其他五条完全不能保证第六条也成立必须单独验证。唯一的例外是消费一次CO这条性质它拆成两半后其中效果惰性这一半在数学上必然被效果恰好一次所蕴含属于结构性依赖而消费计数那一半则依然独立。这个独立性证明不是靠抽样验证的而是靠穷举出一个完全满足其他五条、却违反目标那一条的具体模型来证明的。这种证明方式在逻辑学里叫反例见证一旦找到一个完整穷举过的反例结论就是确定的不需要靠跑得越多越可信这种统计式的信心。后来作者甚至用TLAPS对参考语义整体做了无界证明一共处理了196个证明义务全部通过意味着这个结论不再局限于某个具体规模的状态空间而是对任意满足模型假设的取值都成立。 TLAPS*TLA Proof System一个能对TLA规范做数学定理证明的工具比TLC的穷举有限状态更进一步可以证明性质在无限状态空间下也成立。LangGraph的分叉漏洞不是bug是设计选择的影子理论建好了接下来是把它砸向真实框架。这部分测试结果是全文最刺激的部分。先说LangGraph这是目前最流行的AI智能体工作流框架之一。作者发现它有一个持续存在了至少五个版本、跨越一年发布周期的分叉漏洞编号为#6663。测试场景很简单一个流程在某个节点暂停等待人工输入。测试者先发送同意True再对同一个暂停点发送拒绝False。按理说第二次输入应该触发一个新的分支走向拒绝对应的结果。但实测结果是**两次恢复返回的都是第一次的值。第二次输入的拒绝被彻底吞掉从未被采纳。**这个bug在三种不同的存储后端内存、SQLite、真实的PostgreSQL数据库上表现一致说明它不是某个存储实现的偶然问题而是更上层的执行逻辑出的问题。作者没有止步于发现问题而是深入源码找到了问题的确切位置。原来LangGraph为了让用同一个值重复调用这件事变得幂等也就是重复调用不会产生额外副作用设计了一条去重规则只要一个恢复通道已经记录过写入值之后的调用就直接服用之前记录的那个值不再重新处理新输入。这个设计本身是有道理的如果同一个人不小心把审批按钮点了两次你当然不希望系统真的执行两次转账。**但这条为了防止意外重复而设计的规则恰好把故意的二次分叉也一并挡在了门外。**论文用一个专门针对LangGraph的形式化模型重现了这个机制给两次调用不同的值 va 和 vb模型服务出来的结果是 va 和 va正是实测中看到的现象。也就是说**这个bug不是程序员写错了而是防重复和允许重新分叉这两个需求在没有区分标志位的前提下天然冲突被设计选择精确地实现出来了。**这就好比一个门禁系统为了防止有人反复刷卡骗系统多次开门设定了同一张卡在短时间内只认第一次刷卡结果的规则。这在防重复闯入上非常有效。但如果这张卡的持有人真的改变主意想告诉门卫我其实是想让另一个人进系统却压根不听第二次的意思只会重复第一次的判断。如果不设这条规则会怎样会议室门禁可能被人一直刷卡骗开无数次设了这条规则又会导致合法的改主意请求被忽略。**两难的根源在于卡片本身没有告诉门禁这是第几次尝试这个信息。**更让人在意的是这个漏洞在LangGraph官方文档里其实有两种矛盾的解释。文档一方面把这种恢复地址描述成在任意检查点分叉图状态的时间旅行功能另一方面又暗示它是重放机制。**在这两种解释里无论按哪一种理解实测的行为都构成了对文档承诺的违背。**悄无声息的数据腐败检查点有效性的崩塌另一个在LangGraph 1.2.9上发现的问题比分叉漏洞更隐蔽也可能更危险。测试构造了一个用pydantic定义了严格数据结构的状态比如要求某个字段必须是字符串列表然后让某个节点故意写入一个不符合结构的值比如None。按理说这种写入应该被拒绝或者至少在读取时报错提醒用户这里有问题。在早先的版本里这种非法写入确实会被持久化保存然后在之后调用历史读取接口时抛出异常好歹给了个提示。但在最新的1.2.9版本里**这个非法数据被悄悄地、完整地写入了数据库读取历史记录时什么错误都不会报调用者完全不知道自己的数据已经坏了。**作者进一步做了细分测试发现这个悄无声息其实分两种情况。如果非法写入发生在流程的最终节点那就是彻底的沉默你调用状态读取接口拿到的就是那个坏掉的值直到你尝试用pydantic验证它才会报错而且这个沉默甚至能在数据从磁盘重新加载后依然保持。但如果非法写入发生在流程中间的某个节点情况会稍好一点坏数据先被写进去但下一步执行时会立刻抛出验证错误之后调用这个流程的读取接口也会持续报错。这两种情况都不理想但第一种更危险因为它给人一种一切正常的假象。崩溃路径 vs 中断路径同一个API的两副面孔如果说前两个问题是明显的功能缺陷那接下来这个发现就更微妙、也更具启发性了**LangGraph在人工中断恢复这条路上做得对但在进程崩溃恢复这条路上却做得不对而这两条路走的是同一个持久化接口。**测试构造了一个两步任务流程第一步的结果已经被持久化写入数据库然后模拟第二步执行时进程崩溃。恢复之后正确的行为应该是跳过已完成的第一步直接从第二步继续。但实测结果是**已经完成、且已经持久化保存了结果的第一步被重新执行了一遍。**为了排除这只是异常测试的假象这种质疑作者还做了真实的SIGKILL强制杀进程实验用文件系统屏障精确同步杀进程的时机确保杀进程发生在结果已经写入磁盘之后。结果依然一样**重启一个全新的解释器进程那个本该被跳过的任务又被执行了一遍。**而LangGraph自己的文档明确写着已完成节点的写入之所以要被存储就是为了让你在恢复时不需要重新运行成功的节点。这句承诺在崩溃这条路径上被自己的实现打破了。这个发现意味着什么意味着**同一个持久化API在被中断唤醒时表现出恰好一次的语义在崩溃恢复时却表现出至少一次的语义。**同一套代码两种截然不同的可靠性保证取决于你是通过哪种方式触发恢复的。这种不一致对一个想要设计可靠系统的开发者来说几乎是灾难性的因为它意味着你没法通过阅读一次文档就摸清楚整个系统的行为边界。CrewAI写的承诺和做的事完全是两回事如果说LangGraph的问题主要出在执行细节层面那CrewAI的问题就更直接**它的检查点功能文档明确承诺恢复时不会重新运行已完成的工作但实测结果直接推翻了这句承诺。**测试流程是这样任务s1执行完成并写入检查点任务s2执行时抛出异常导致流程中断。作者用官方推荐的from_checkpoint方法从最新检查点恢复流程。结果是s1这个明明已经完成的任务被重新执行了一次它的效果计数器从1变成了2。更微妙的是流程本身显示的状态计数器读数却是正确的数字看起来完全没问题因为CrewAI在恢复时是把状态从初始值重新计算出来的而不是真的从持久化记录里继续。**这意味着如果第一步是给信用卡扣款那么这张卡会被真实地扣两次款而流程本身呈现给你的状态却显示一切正常。**这正是为什么论文坚持要用一个独立于框架内部状态的外部效果台账ledger来做验证的原因。**如果只相信框架自己汇报的状态你根本发现不了这个重复扣款的问题因为框架的状态显示层本身就是错的。**这就好比一个自动记账软件明明重复给你的信用卡扣了两次钱但账本上却只显示扣了一次因为账本是根据这个月总共应该花多少钱这个公式重新算出来的而不是逐笔记录实际发生了什么。如果你只看账本你永远不会发现钱被多扣了。你必须去查银行卡的真实流水才能发现问题。论文作者用的外部SQLite账本扮演的正是银行卡流水这个角色。作者还发现了一个更宽泛的规律只要crewAI的持久化边界不完整无论在哪一个操作节点上模拟崩溃都会导致已完成的工作被重新执行。这不是某一个偶然的边界情况而是这套持久化机制在设计上就存在的系统性缺陷。pydantic-graph安全得像个死人第四个被测试的框架叫pydantic-graph它的问题走向了另一个极端**它没有出现任何重复执行的问题因为它压根不让你从崩溃中恢复。**测试场景是这样第一个节点执行完成并生成了快照然后在第二个节点执行过程中模拟崩溃。作者调用框架自己文档记载的恢复入口结果直接抛出异常无法从状态持久化中恢复快照。从不会重复执行副作用这个角度看这个框架是安全的因为它压根没有恢复执行自然也就不会有重复。但这种安全是一种安全得像个死人的安全。论文管这种现象叫**安全性靠死寂**所有安全性质都满足但活性liveness也就是流程最终能跑完这条基本要求彻底失败了。这就好比一辆车为了绝对避免撞车事故永远不启动。从零事故这个KPI来看它完美达标但它已经不能算是一辆能开的车了。如果不追问能不能开这个问题光看事故率你会误以为这是最安全的车。有意思的是这个bug只在进程在节点执行中途崩溃这种情况下出现。如果崩溃发生在流程暂停等待人工输入的时候恢复反而是正常的。这说明问题出在一个很窄但很关键的时间窗口里而现实中长时间运行的AI节点比如等待一个模型响应恰好最容易崩溃在这个窗口内。并发才是真正的深水区一个approve被同时消费了好几次前面说的所有问题都是单个进程、单次操作触发的。但论文测试的最后一个、也是最惊人的一个发现出现在并发场景下。**在只有一个进程访问的情况下LangGraph对消费一次这条性质是完全合规的。**一个已经被消费过的中断点再次收到相同的恢复请求会被正确地忽略不产生任何重复效果。但如果换成两个独立的操作系统进程同时对同一个暂停中的中断点发起恢复请求呢结果是**在开发机上跑10次10次全部触发了两次效果执行。在容器环境里也复现了。**换到基于真实网络PostgreSQL数据库的场景下同样是10次里10次重复。**这个漏洞跨越了不同的宿主机甚至跨越了不同的物理机器两个在不同机器上的竞争者10次里10次都产生了重复消费。**这个问题的本质是一个经典的数据库并发问题**读取-判断-写入这个操作序列没有被设计成原子操作。**两个进程几乎同时读到这个中断点还没被消费这个状态于是都判断自己可以继续执行各自都触发了副作用等它们再去写已消费这个标记时已经太晚了。 竞态条件race condition*指多个进程或线程同时访问、修改同一份共享数据时由于执行顺序的不确定性导致结果出错的现象。这里具体表现为丢失更新这种经典的数据库并发异常。这就好比一张演唱会门票两个人几乎同时在网上查询这张票是否还能用系统显示可用于是两个人都刷了这张票进场。等系统真正把票标记为已使用时两个人都已经进去了。**如果检票系统只是简单地先查询再更新而不是把查询和更新绑成一个不可分割的操作那么在两个人同时到达检票口的极端情况下这张票就会被消费两次。**作者没有止步于发现这个漏洞还专门做了一次剂量-反应式的深度测量系统地改变并发进程数量从2个到16个和到达时间差从0毫秒到25毫秒。结果发现这个漏洞窗口的宽度**恰好和被中断的那个节点自身的执行时长挂钩**如果一个节点本身要跑2秒钟比如在等一个大模型的响应那么在这2秒钟之内到达的所有并发请求几乎全部都会触发重复消费饱和率达到100%。测试范围内没有观察到任何进程数量的上限16个并发进程同时涌入16次全部触发了重复执行。这个发现的意义在于**这不是一个只在极端压力测试下才出现的边角案例。任何一个真实部署的AI智能体只要它的暂停节点背后是一次真实的模型调用通常都要几秒钟这个窗口就是活生生存在、随时可能被触发的。**REMIT一个带数学证明的修复方案发现了问题之后论文没有止步于发现还给出了一个具体的修复实现叫做**REMIT**一个可以直接安装使用的Python包remit-contract。REMIT的核心思路是在框架的持久化接口那一层做拦截而不是去改框架本身的代码。它内部用Rust编写核心逻辑通过PyO3绑定暴露给Python调用并且这套Rust核心的关键不变式用Verus这个工具做了机器验证。 Verus*一个用来对Rust程序做形式化验证的工具可以数学证明代码的某些性质在所有可能的执行路径下都成立而不是靠测试用例去抽样检查。针对分叉确定性这个问题REMIT把每个恢复分支按一个唯一的键值检查点ID加恢复序号来区分而不是像LangGraph原本那样只服用第一次记录的值。作者一开始尝试在写入这一层做这个修复但发现完全没用因为LangGraph的执行循环压根不会在决定该走哪条分支之前去询问存储层的意见决策是在存储层之上的执行逻辑里就已经做完了。**真正有效的修复点在读取这一层。**也就是说在框架从数据库把状态读出来、准备决定下一步该怎么走的那个瞬间去介入而不是在写入数据库的那个瞬间。这个写入路径失败、读取路径成功的模式后来在修复并发消费问题时又重复出现了一次说明这不是巧合而是这类先读、再决定、后写架构的一个通用规律**任何在决策发生之后才介入的补丁都没法否决那个已经做出的决策。**针对并发消费的问题REMIT的修复方案是在共享的存储层加一个基于唯一约束的原子插入操作谁先成功插入这条声明记录谁就赢得消费权另一个进程会收到一个明确的拒绝异常而且这个拒绝发生在任何节点真正执行之前。修复之后10次并发竞争测试里变成了稳定的1个赢、10个都被拒绝无论是在同一台机器还是跨越两台不同的物理机器上效果都是一致的。REMIT的验证工作被分成了好几个明确标注的层级论文很坦诚地说明了哪些地方是完全经过数学证明的哪些地方只是经过了大量测试但没有完整证明。比如核心的恢复决策逻辑不仅在抽象模型层面被证明正确还进一步验证了这段可执行的Rust代码和实际发布的库中的代码逐行一致并且这个一致性检查被放进了持续集成流程每次代码提交都会自动核查。但从经过验证的抽象模型到编译出来的最终二进制文件之间并没有一个完整的数学证明链条把两者严格连接起来作者明确把这一点列为尚未完成的工作没有藏着掖着。五个框架没有两个是一样的把所有测试结果放在一起看会得出一个很扎实的结论**在被测试的五个框架里没有任何两个框架拥有相同的合规表现。**作者专门做了一个两两配对分析十对框架组合里九对是在同一个测试场景下给出了不同的行为结果剩下的一对AutoGen和LlamaIndex Workflows虽然在共同测试的场景里表现一致但因为两者能测试的路径本身就不完全重叠所以严格来说也算不上完全相同。这个结果说明了什么说明**目前整个AI智能体框架生态在恢复这件最基础的事情上处于一种彻底碎片化、互不兼容的状态。**一个开发者今天用LangGraph写好的、依赖恢复语义的业务逻辑换到CrewAI上大概率会出问题换到pydantic-graph上可能压根跑不起来。论文还发现两个此前被官方修复过的LangGraph问题编号#7361和#6792是在1.1.x版本里作为回归引入的直到1.2.9版本才被修复。这说明**在没有一套标准化契约和自动化测试套件的情况下即便是同一个框架语义也会随着版本迭代悄悄漂移。**今天正确的行为明天的一次更新就可能悄悄破坏它。写在后面读完这篇论文最让我意外的其实不是那些具体的bug而是那个关于分叉确定性和消费一次互相矛盾的数学证明。这不是一个可以靠更仔细写代码解决的bug而是一个协议设计层面的根本矛盾如果你的通信协议里没有携带这是第几次尝试的信息你永远没法区分重复和改主意。这让我想到很多看似是实现细节的问题追根溯源其实是接口设计阶段就埋下的根写代码的人再仔细也补不回来。另一个让人印象深刻的细节是论文里反复出现写入路径的修复没用读取路径的修复才有效这个模式而且是在两个完全不同的问题分叉确定性、并发消费上各自独立发现的。这种重复出现的结构性规律比单独任何一个bug报告都更有价值因为它揭示的是一类系统架构先读状态、再决策、最后才通知存储层的通用弱点而不是某个框架的偶然疏忽。论文里没有回答、但我很好奇的一个问题是这套契约有没有可能反过来推动框架团队在设计阶段就把恢复语义当作一等公民来对待而不是像现在这样等用户提交issue之后才发现问题毕竟网络协议和文件系统花了几十年才建立起对崩溃恢复这件事的行业共识AI智能体框架会不会也需要经历类似的漫长过程QAQ1RESUME CONTRACT具体包含哪几条性质A一共六条核心性质分别是前缀延续性恢复必须从持久化记录的断点开始、效果恰好一次副作用不能重复触发、分叉确定性不同输入应导向不同分支结果、检查点有效性持久化数据必须符合规定格式、消费一次中断点只能被消费一次、恢复确定性相同记录必须导出相同决策外加一条协议层面的分叉意图可表达性要求。Q2LangGraph的分叉漏洞#6663具体是什么问题A当同一个中断点先后收到两次不同的恢复值比如先同意后拒绝时LangGraph会把两次都服务成第一次的结果第二次输入被静默忽略。这个漏洞在五个版本、三种存储后端上都稳定存在根源是框架为了让重复调用幂等而设计的去重规则恰好把合法的重新分叉请求也一并挡住了。Q3并发场景下消费一次这条性质为什么会失败A因为读取中断状态、判断是否已消费、写入消费标记这三步操作没有被设计成一个不可分割的原子操作。当两个进程几乎同时读取到未消费的状态时都会各自判断自己可以继续执行导致副作用被触发两次。测试显示这个漏洞窗口的宽度跟着被中断节点自身的执行时长走节点跑得越久窗口越大重复消费的概率越接近100%。