Agent重试逻辑暗藏竞态：查询谎言与重复分发

你的AI Agent分发了一个动作，紧接着调用服务商查询接口确认是否成功。查询返回“未找到”，你标记为失败并重试——但动作实际上已经成功了。你刚制造了一次重复分发。

这不是重试逻辑的bug，而是对查询结果信任模型的缺陷。

问题本质：写入成功不等于读取可见

许多服务商采用最终一致性模型。写入操作返回HTTP 200无错误，但产物不会立即出现在读副本上。根据服务商和负载不同，复制延迟可能是200毫秒、2秒甚至30秒。

分发后立即执行的查询，读到的时钟尚未同步。

这里有两种外观完全相同的故障模式：

查询结果："not found"
情况A：动作确实失败——没有任何写入
情况B：动作已成功——读副本尚未同步

两者返回相同结果，但只有情况A应该触发重试。

这是典型的竞态条件：Agent的验证模型默认“读己之写”立即可见，但分布式系统中读副本的同步存在固有延迟。当重试逻辑直接依赖查询结果做决策时，复制窗口就成了重复分发的温床。

最终一致性（Eventual Consistency） 是分布式系统中广泛采用的一致性模型，与强一致性相对。在强一致性下，写入一旦返回成功，所有后续读取都能立即看到新值；而最终一致性只保证「如果没有新的写入，最终所有读副本都会收敛到相同状态」，但对收敛所需的时间不做严格承诺。典型的分布式存储（如Amazon S3、DynamoDB、Cassandra）以及大量SaaS服务商的API都基于此模型构建，因为它们需要在可用性和延迟之间做权衡——同步复制到所有副本会显著增加写入延迟。

读己之写（Read-Your-Writes） 是一致性会话保证的一种，指的是某个客户端写入后，该客户端自己的后续读取一定能看到该写入。单机数据库通常天然满足这一保证，但跨地域、多副本的分布式系统往往需要额外机制（如会话令牌、主副本路由）才能实现。AI Agent的验证模型通常隐含假设「读己之写立即可见」，而实际调用的服务商API可能并不提供这种保证，这个认知落差正是竞态条件的根源。

朴素状态机的致命缺陷

一个典型的重试确认函数可能长这样：

suspend fun confirmDispatch(record: ActionRecord, provider: ActionProvider): ActionRecord {
    val artifact = provider.lookup(record.dispatchId)
    return if (artifact != null) {
        record.copy(delivery = DeliveryState.CONFIRMED)
    } else {
        // BUG：假设"未找到"等于"失败"
        // 但它可能只是"尚未传播"
        record.copy(delivery = DeliveryState.FAILED)
    }
}

如果这段代码在分发后立即执行，“未找到”的响应是模糊的——无法区分真正的失败和复制延迟。一旦标记为FAILED，重试队列就可能发起重复分发。

据StareBrain的技术分析，这种模式在设备端动作中尤为危险：当无障碍层确认UI操作已触发后，下游服务商是否已记录该操作，属于另一个时钟。两个时钟，一个验证模型，它们之间的间隙就是重复分发的来源。

竞态条件（Race Condition） 指系统的输出依赖于不受控事件的发生顺序或时序。在本例中，Agent的查询操作与读副本的复制操作之间存在竞态：查询可能在复制完成前到达，也可能在复制完成后到达，两种时序返回不同结果，但调用方无法从结果本身判断究竟处于哪种时序。

竞态条件在分布式系统中之所以危险，是因为它往往不可复现——在低负载、本地测试环境下复制延迟可能只有几毫秒，查询几乎总能读到最新数据，bug隐身；一旦进入生产环境、跨地域部署或高负载时段，复制延迟放大到秒级，重复分发才突然爆发。因此这类问题的修复不能依赖「让查询更快」或「增加重试次数」，而必须在模型层面引入时间维度的显式约束，把不确定的时序转化为可判定的状态。

修复方案：最小年龄门控

核心思路是：不允许PENDING状态的记录在一致性窗口关闭前进入对账流程。

data class ActionRecord(
    val actionId: String,
    val dispatchId: String,
    val providerObjectId: String?,
    val delivery: DeliveryState,
    val acceptance: AcceptanceState,
    val dispatchedAt: Instant,
    val confirmedAt: Instant?,
    val eligibleForReconciliationAt: Instant  // dispatched_at + consistency_window
)

fun ActionRecord.isEligibleForReconciliation(): Boolean {
    return Instant.now().isAfter(eligibleForReconciliationAt)
}

对账循环在查询前检查资格：

suspend fun reconcileIfEligible(record: ActionRecord, provider: ActionProvider): ActionRecord {
    if (!record.isEligibleForReconciliation()) {
        // 时机太早——查询结果不可信
        return record
    }
    val artifact = provider.lookup(record.dispatchId)
    return if (artifact != null) {
        record.copy(
            providerObjectId = artifact.id,
            delivery = DeliveryState.CONFIRMED,
            confirmedAt = Instant.now()
        )
    } else {
        // 此时"未找到"才真正意味着失败，一致性窗口已关闭
        record.copy(delivery = DeliveryState.FAILED)
    }
}

这相当于在分布式系统的读操作上加了“保鲜期”：窗口内的查询结果不构成任何证据。

最小年龄门控（Minimum Age Gating） 的思想与分布式系统中的 Lease（租约） 和 Fencing Token（隔离令牌） 一脉相承：通过引入一个基于时间的屏障，让系统在一段已知不可信的时间窗口内拒绝基于该数据的决策，而不是试图消除延迟本身。

与常见的指数退避重试不同，最小年龄门控不是「等一会儿再试」，而是「在窗口关闭前，任何查询结果都不被采纳为证据」。这两种思路的关键区别在于：退避重试仍然会消费查询结果，只是推迟了消费时间；而门控完全忽略窗口内的结果，从语义上切断了「查询返回未找到 → 判定失败」的推理链。

实现上需要注意时钟源的选择——应使用单调时钟（monotonic clock）而非墙上时钟（wall clock）来计算资格时间，避免NTP校时或时区变更导致的判断错误。在跨进程、跨机器的场景中，还可能需要依赖服务端提供的时间戳或版本号，而非本地时间。

一致性窗口的取值来源

窗口时长不是随意设定的。代码中应针对不同服务商配置具体值：

object ConsistencyWindows {
    // 来自服务商文档
    val STRIPE_EVENTS = Duration.ofSeconds(5)
    // 来自经验观察（无公开SLA）
    val GOOGLE_CALENDAR = Duration.ofSeconds(10)
    // 无文档时的保守默认值
    val DEFAULT = Duration.ofSeconds(30)
}

关键原则：如果服务商不公布复制延迟，就自己测量。分发测试写入，轮询读端点，记录何时可见。务必在负载下测试，而非理想条件。

迟到的确认与替换竞态

另一个相关问题：当确认信号在记录已被标记FAILED并排队替换之后才到达，该怎么办？

suspend fun handleLateConfirmation(record: ActionRecord, artifact: ProviderArtifact): ActionRecord {
    return when (record.delivery) {
        DeliveryState.FAILED -> {
            // 迟到的确认——动作成功了，尽管之前判定失败
            // 在更新状态前取消已排队的替换
            cancelQueuedReplacement(record.actionId)
            record.copy(
                providerObjectId = artifact.id,
                delivery = DeliveryState.CONFIRMED,
                confirmedAt = Instant.now()
            )
        }
        DeliveryState.PENDING -> {
            // 正常确认路径
            record.copy(
                providerObjectId = artifact.id,
                delivery = DeliveryState.CONFIRMED,
                confirmedAt = Instant.now()
            )
        }
        DeliveryState.CONFIRMED -> {
            // 已确认——幂等，不做改变
            record
        }
    }
}

替换分发必须在触发前立即读取投递状态，而不是在调度时读取。调度替换和实际分发是两个独立时刻，状态检查属于分发时刻。

幂等性（Idempotency） 指同一操作执行一次与执行多次产生相同效果。在分布式系统中，由于网络分区、超时重试和消息重放的存在，任何跨服务调用都必须假设「消息可能重复到达」。本例中，handleLateConfirmation 对 CONFIRMED 状态直接返回原记录，正是幂等设计的体现——重复收到同一确认信号不会改变状态，也不会触发副作用。

更隐蔽的是 替换竞态：调度替换与执行替换是两个独立时刻。如果在调度时记录是FAILED，但执行前收到迟到的确认并转为CONFIRMED，那么按调度时的快照执行替换就会造成重复分发。因此替换逻辑必须在实际分发前的最后一刻重新读取状态，而不是复用调度时的状态副本。这就是为什么分布式事务中常说「检查与使用之间不能有间隙」——所有基于状态的决策都应在靠近副作用发生点的位置进行。

完整状态机中的表现

enum class DeliveryState {
    PENDING,      // 已分发，等待确认
    CONFIRMED,    // 查询返回了产物
    FAILED        // 一致性窗口关闭后查询仍无结果
}

fun ActionRecord.resolvedStatus(): ActionStatus = when {
    delivery == DeliveryState.PENDING && !isEligibleForReconciliation() -> 
        ActionStatus.DENIED_UNRESOLVED  // 窗口仍开放
    delivery == DeliveryState.PENDING && isEligibleForReconciliation() -> 
        ActionStatus.DENIED_UNRESOLVED   // 需要查询
    delivery == DeliveryState.FAILED -> ActionStatus.FAILED
    delivery == DeliveryState.CONFIRMED && acceptance == AcceptanceState.REJECTED -> ActionStatus.FAILED
    delivery == DeliveryState.CONFIRMED && acceptance == AcceptanceState.ACCEPTED -> ActionStatus.CONFIRMED
    else -> ActionStatus.DENIED_UNRESOLVED
}

DENIED_UNRESOLVED不会因为一次早期查询就衰减为FAILED，它需要窗口外的查询才能转变。窗口内的查询不构成任何证据。

实践意义

一致性窗口是你验证模型的一部分。如果它没有以具名常量（而非魔法数字）的形式出现在代码中，那它就是一个假设。而假设正是重复分发的栖息地。

对开发者而言，这意味着在设计Agent的重试逻辑时，必须将服务商的一致性窗口作为一等公民对待。不要假设查询结果反映当前真实状态，而要显式建模“何时查询才可信”。这是从“查询即真相”到“查询需等待真相可见”的范式转变。

两个时钟，一个验证模型，它们之间的间隙就是你的重复分发来源。把这个间隙放进代码，而不是留给运气。