AI Agent重复执行频发？根因是状态建模错误

AI Agent在自动化任务中反复出现重复派发（duplicate dispatch）的问题，很多团队的第一反应是检查重试守卫（retry guard）是否缺失、幂等键（idempotency key）是否失效。但StareBrain在其工程博客中指出，这类Bug的真正根因往往不是逻辑漏洞，而是数据建模错误：把两个独立的状态问题塞进了一个枚举字段。

单枚举状态如何制造重复派发

典型Agent执行流程中，开发者习惯用一个SUCCESS/FAILED枚举来标记动作状态。问题在于，"是否获得派发证据"和"该证据是否满足预期结果"本质上是两个不同的问题，强行合并后就丢失了决定下一步操作所需的信息。

StareBrain还原了常见故障链：Agent派发动作 → 派发在确认到达前超时 → 系统看不到SUCCESS标记 → 判定为失败 → 触发重试 → 第二次派发产生重复。

问题的核心在第三步。「尚未收到确认」和「动作确实失败」不是同一种条件，但单一枚举迫使系统二选一：要么无限等待，要么冒着重复风险重试。

幂等键（Idempotency Key） 是分布式系统中防止同一操作被执行多次的常用手段：调用方在发起请求时携带一个全局唯一的标识符，服务端对该标识符去重，遇到相同键的重复请求直接返回首次结果而不重新执行副作用。它的前提是「服务的写入逻辑本身是可幂等的」，且标识符的生成、传递、存储环节都可靠。但在 AI Agent 场景中，幂等键常常失效：一方面，重试可能由不同层级的调度器发起，生成的键并不相同；另一方面，Agent 调用的外部 provider（如短信网关、邮件服务）未必支持幂等键语义，服务端无法据此去重。因此，幂等键只能缓解「同一逻辑动作被重复提交」的问题，却无法回答「上一次派发到底有没有成功」这一状态问题，这正是单枚举模型失效后补丁打不动的地方。

双轴状态模型：Delivery与Acceptance分离

StareBrain提出的方案是让每个产生可观测产物的动作追踪两个独立状态。DeliveryState回答的是"产物是否存在"，取值为PENDING（等待provider查询确认）、CONFIRMED（provider查询返回了产物）、FAILED（查询无结果或报错）。AcceptanceState回答的是"产物是否正确"，取值为PENDING（尚未评估）、ACCEPTED（产物匹配意图）、REJECTED（产物存在但语义不匹配）。

两个状态独立推进，组合状态是派生计算出来的，而非直接存储。这种设计让系统能够区分"需要继续等待"、"需要重新派发"和"需要修正动作定义"三种截然不同的恢复路径。

组合状态派生（Derived / Computed State） 与存储状态（Stored State）的区别是这里的核心设计取向。所谓派生，是指系统不单独维护一个「整体状态」字段，而是在需要时由底层的两个或更多原子状态即时计算得出，例如「已确认且被接受」对应 CONFIRMED + ACCEPTED，「已确认但被拒绝」对应 CONFIRMED + REJECTED。这样做的好处是消除冗余：如果同时存储组合状态和原子状态，二者可能在更新时序上不一致，产生难以排查的「幽灵状态」。代价是查询组合条件时需要显式的计算或物化视图。在实践中，团队常在写入侧只持久化原子状态，在读取侧通过纯函数派生组合判断，从而保证单一事实来源（Single Source of Truth）。

结构不变式：用状态机而非约定来保障安全

仅仅分离两个字段还不够，关键在于让非法状态转换在代码层面不可达。StareBrain通过tryAccept()方法实现了这一点：只有当delivery == CONFIRMED时，才允许接受状态从PENDING转移。否则方法会抛出异常，提示"必须先运行provider查询"。

这意味着代码中不存在任何路径能让一个未确认的派发被标记为已接受。安全性不是靠开发者记得遵守约定，而是由状态机强制执行。

在重新派发决策上，shouldRedispatch()的逻辑同样明确：delivery == PENDING时永不重派，动作保持DENIED_UNRESOLVED状态进入对账流程；只有delivery == FAILED（确认失败）或acceptance == REJECTED（语义不匹配）时才允许重新派发。

结构不变式（Structural Invariant） 指的是由类型系统、构造函数或方法签名强制保证、在任何执行路径下都不可能被违反的约束，它与「靠文档和代码评审提醒开发者遵守的约定」相对。经典的实现手段包括：用私有构造函数加静态工厂方法限制对象创建方式；用枚举加状态转换表在运行时拒绝非法迁移；在更强类型的语言中，用类型参数或代数数据类型让非法状态在编译期就无法表达。tryAccept() 属于第二种：它在方法体内显式检查前置条件，不满足即抛出异常，使「未确认即接受」这条路径在运行期不可达。相比注释和代码规范，结构不变式的优势在于它不依赖人的记忆，且能随代码演化持续生效。

两种失败模式，两条恢复路径

双轴模型揭示了一个容易被忽视的事实："语义不匹配"和"未确认交付"是两类完全不同的失败，需要完全不同的处理方式。

语义不匹配（CONFIRMED + REJECTED）：产物确实存在，已确认，但内容是错的——收件人不对、内容不对、载荷不对。恢复方式是修正动作定义后重新运行。原始派发记录是事件发生的证据，不需要重新检查。

未确认交付（PENDING）：产物尚未验证。此时不应重新派发，而应运行provider查询。如果产物存在，更新delivery状态为CONFIRMED并评估acceptance；如果不存在，此时才拥有一个真正需要处理的失败。

持久化三元组：跨重试的证明绑定

实际系统中，状态记录需要在重试和进程重启之间保持可查询。StareBrain的ActionRecord将actionId、dispatchId、providerObjectId、两个状态枚举以及三个时间戳一起持久化。

dispatchId与providerObjectId和acceptance绑定存储的意义在于：重试不能意外借用另一次运行的证据。每次派发是独立记录，绑定自己的产物标识。在Android短信派发的实际案例中，"已发送文件夹检查"本身不是证据，把确认的sentMessageId绑定到该次派发的dispatchId才是证据。缺少这层链接，你只知道"有东西发出去了"，而不知道"发出去的是不是对的东西"。

对账流程（Reconciliation） 是分布式系统中处理「状态未知」的标准手段：当事务结果无法立即确定时，系统不猜测、不重试，而是将该条目标记为待对账，交由一个独立的、可重入的巡检进程定期回查外部系统的真实状态，直到得出结论为止。它与「重试」的关键区别在于：重试假设上一次操作失败并主动再次执行副作用，而对账假设结果未知并只做只读查询，因此不会产生新的副作用。在本案例中，delivery == PENDING 的派发正是转入对账流程，而不是进入重试队列。对账机制通常需要配套三个要素：足够长且可配置的查询窗口、幂等的查询接口、以及能把查询结果正确回写到原始派发记录上的证据绑定关系，后者正是 dispatchId 与 providerObjectId 关联存储的用途。

对Agent开发者的启示

这个案例的价值超出了重复派发这一个Bug类型。它指出了一个更普遍的模式：当Agent系统的可靠性出现问题时，开发者倾向于在控制流层面打补丁——加重试守卫、加幂等键、加重试上限。但如果底层状态模型本身就是错的，这些补丁只是在错误的抽象层级上打转。

把复合状态拆解为独立维度、用派生逻辑替代存储逻辑、用结构不变式替代人工约定——这套方法论适用于任何需要追踪外部副作用的Agent系统。重试逻辑不需要"记住"什么时候该重试，状态机的结构本身就排除了错误的重试路径。