持久执行保存状态，却守不住规则：AI Agent复活的治理盲区

持久执行解决了什么，又遗漏了什么

在 AI Agent 基础设施领域，耐久执行（durable execution）是当下最有说服力的技术叙事之一。它让一个 Agent 可以运行数小时甚至数天，在进程中崩溃后依然精确地从断点恢复，不丢失任何状态。这是一项扎实的工程成就，做到这一点的团队值得尊敬。如果你的问题是“在一个漫长、易出错的多步骤流程中别丢进度”，耐久执行就是正确的工具。

但耐久执行的承诺边界非常明确：它保证状态（state）在暂停期间完好无损。至于暂停结束后规则（rules）是否仍然成立，它把它交给了别人。而一个严肃的 Agent 最常见的暂停原因，恰恰是这个缺口最致命的地方——它在等人类批准某件事。

不是状态问题的暂停

一个关键性的 Agent 回合遇到了需要人类批准的一步：释放付款、批准例外、签署变更。于是它停下来。可能是三十秒，也可能是到下周一。

耐久执行完美地回答了关于这次暂停的一个问题：恢复时我们还能拿到完全一致的状态吗？ 能。但决定恢复是否安全的问题完全是另一组：

• 周一恢复时，该操作是否仍然被授权？批准者的角色是否变了？权限是否被撤销了？世界是否已经变了？
• 它凭什么身份恢复？ 是原始执行者、重新验证过的身份，还是某个为了实现目标而悄悄提权的系统身份？
• 如果一个缓慢但存活的 worker 和一个重试同时认为它们拥有恢复权，操作会触发两次吗？
• 人类的批准本身是否被记录为可控事件，以便日后审计？

耐久执行引擎按自己的逻辑回答第三个问题。例如 Temporal 保证一个 activity “将被观察为恰好完成一次”，但同时指出它“可能被执行多次”，并建议让 activity 具备幂等性。其余三个都是治理问题，而耐久执行作为一种原语，把它们留给了你在其上编写的代码。

幂等性（idempotency） 是理解这一节的关键前提。所谓幂等，是指一个操作无论执行一次还是多次，对系统产生的最终影响相同。例如“将账户余额设为 100 元”是幂等的，而“向账户余额加 100 元”则不是。Temporal 之所以建议把 activity 写成幂等，是因为它只能承诺“逻辑上被观察为完成一次”，底层仍可能因重试、worker 崩溃重启而实际执行多次。缺少幂等设计时，一次重复执行就可能造成重复扣款、重复发货等后果。要真正做到幂等，通常需要业务侧维护去重键、唯一约束或状态版本号，这属于应用层责任——正是耐久执行引擎无法代劳、却容易被忽视的部分。

恢复是一个受治理的操作

在受治理的运行时中，human-in-the-loop 是流程状态机的持久化状态：一个按角色门控的阻塞式审批，写入数据库，能跨重启、交接和重试存活。在整个暂停期间，该回合作为耐久状态处于暂停，等待期间没有任何进程或连接被占用。

审批触发的恢复作为一个受治理操作运行：

• 它以原始执行者的身份恢复，身份贯穿整个暂停期，绝不会被替换为一个有特权的系统账户。在任何步骤运行前，它从数据库重新读取该执行者的角色分配，并对照流程声明的 resume 策略检查。未声明此类策略的流程对任何角色都恢复。
• 它失败关闭（fail closed）。如果策略不再允许该执行者，运行会在执行任何步骤之前以 resume_denied 结束为 failed，一个 FlowFailed 事件写入哈希链，用户收到一条消息说恢复不再被允许。
• 它是纯模板且无模型的。它在不再次调用推理器的情况下完成流程剩余部分；如果剩余步骤中任何一步调用模型，它一个都不运行，而是等待用户的下一条消息，因此暂停不会在出口路径上打开新的注入入口。
• 它通过可验证的声明实现竞态安全。每次恢复尝试都携带自己的身份和一个通过心跳续租的租约。缓慢但存活的尝试会持续续租而不被接管；死亡的租约过期（默认 60 秒后），恰好一个尝试接管它。同一时间只有一个尝试拥有恢复权，被批准的步骤不会再次运行：它的决策作为该步骤的结果被注入。
• 决策以及做出决策的人落入哈希链，与被批准解决的步骤绑定，运行的完成或失败同样如此；发生时间由密封它的签名检查点界定。

因为该回合从未保持连接打开，当它解决时结果通过带外方式宣布：一个内建事件（webhook 或实时流）告诉调用方新回合已就绪可读，而不是一个阻塞到周一的请求。

失败关闭（fail closed） 是一种安全设计原则：当系统无法确认某个操作是否被授权时，默认拒绝，而非默认放行。与之相对的是失败开放（fail open），即在不确定时仍允许操作继续，把安全性寄托于“大概没问题”。在恢复场景中，失败关闭意味着：如果重新读取的角色策略不再允许该执行者，运行必须立即终止，而不是先执行几步、寄望事后补救。这一原则的价值在于把风险挡在副作用发生之前。文中提到运行会以 resume_denied 结束为 failed，正是失败关闭的具体落地——任何步骤都不得在授权确认之前运行。

哈希链（hash chain） 是一种防篡改的日志结构：每条记录都包含前一条记录的密码学哈希，任意一条被修改都会导致其后所有哈希校验失败，从而暴露篡改。文中反复提到“事件写入哈希链”“决策与决策者落入哈希链”，其意义正在于此——审批、恢复、完成或失败都被固化为可事后验证的链条，任何试图悄悄改写“谁在何时批准了什么”的行为都会留下痕迹。结合签名检查点（sealed checkpoint），链中记录的时序也能被独立佐证。这是审计视角下，受治理运行时能够自证的关键机制，也是普通工作流日志不具备的性质。

“恢复”的两种含义

两个系统都可以说“Agent 在长时间暂停后恢复”，但含义截然不同。一个保证字节存活。另一个还检查权限和执行者，保持恢复的单一所有者，并写下记录。对于长时间运行的内部自动化，前者足够。对于触及金钱或受监管决策、且等待人类批准的操作，合规问题就坐在两者之间的缺口里。

诚实的边界

这不是在声称比耐久执行引擎更耐久。 对于通用、多周、多步骤的编排，以及尽可能强的恢复保证，专用的耐久执行平台更成熟，对那类工作它才是正确的工具。这里的耐久性范围限定在受治理的 Agent 回合和合约声明的流程：Postgres 行加一个任务队列，而不是通用工作流引擎。

恢复门控只和流程策略一样严格，且只在审批路径上。 未声明 resume 策略的流程对任何人恢复。当暂停的运行改为从用户的下一条聊天消息被拾起时，运行时读取的是会话的角色快照，而不是重新读取分配；被拒时它把运行从对话中分离，保持 paused 状态，而不使其失败。

无模型恢复是有意收窄。 如果流程剩余部分声明了模型步骤，审批触发的恢复不会运行它：它告诉用户该步骤已解决并等待其下一条消息，那一次普通、受门控的回合运行剩余部分。

声明租约解决的是一个特定竞态。 它保证同一时间只有一个 worker 拥有恢复权，通过区分存活和死亡的 worker。它不能让崩溃变得无代价：一个运行到一半死亡的 worker 还没把它完成的步骤写入运行行，接管的 worker 会再次运行它们。一个仍然存活却被驱逐的 worker 会在步骤之间停下，因此那一刻正在执行的步骤仍可能完成。

审计视角下的真正赌注

一个审计员看长时间运行的 Agent，会远远超出“你丢状态了吗”的问题，转而问：“这个操作等了四天审批——证明审批是真的、那个人当时仍有权限、它以正确的执行者身份运行、并且只执行了一次。”耐久执行日志能显示工作流恢复了。受治理的运行时能在上述限制内从其自身记录和执行的检查中回答其余问题：链记录了决策和决策者；批准者的权限是角色门控在其决策时依据版本化合约检查的内容；恢复在任何步骤运行前再次检查了原始执行者。批准者的角色本身并未被记录为一个独立事实。

撤销场景会这样做：在一个 resume 策略指定了允许恢复角色的流程上，将回合阻塞在人类审批上，在暂停期间撤销执行者的角色，然后批准——恢复重新读取角色，在任何步骤运行前以 resume_denied 将运行结束为 failed，并把失败记录进链。

核心分歧所在

两种“恢复”的差异不是实现细节，而是治理模型的分野。耐久执行把暂停当作一个状态管理问题；受治理的运行时把暂停当作一个权限延续问题。前者对内部自动化足够，后者在 Agent 触及资金、受监管决策或需要向审计证明“谁在何时凭什么授权了什么”时变得必要。选择哪一种，取决于你的 Agent 暂停时等待的是“进度”还是“许可”。

背景补充

合约声明的流程（contract-declared flow） 是本文受治理模型的基本单位。它指流程在定义时显式声明其规则，例如 resume 策略指定哪些角色可以在审批后恢复运行。声明即承诺：只有当流程明确写出 resume 策略时，恢复门控才会生效；未声明的流程等于声明“任何人都可恢复”。理解这一点很重要，因为它揭示了这套机制的边界——治理强度取决于合约写了多少。文中提到的“未声明 resume 策略的流程对任何角色都恢复”，不是实现缺陷，而是显式合约带来的可预期行为。用户需为自己的安全需求补全声明，而非依赖运行时的默认兜底。