智能体执行成功，不能只看接口返回

AI Agent 发出消息、预约时段或修改设置后，后端没报错，就能告诉用户「办好了」吗？作者的答案是：先看后端究竟能证明什么。有的能确认投递和受理，有的只能事后查状态，还有的发出去就没了下文。

这篇文章给出了一套按确认能力分层的设计：接入服务时声明能力，执行前确定核验策略，再把策略写进动作记录。它解决的是一个容易被忽略的问题：Agent 如何诚实地处理「不知道结果」。

收到请求，离确认成功还有多远

作者把服务提供方分成四档。下面的枚举把区别直接写进类型，避免业务代码凭感觉判断：

enum class ProviderCapabilityTier {
    FULL,           // 确认投递和受理
    RECONCILABLE,   // 没有直接确认，但可以在发送后查询状态
    PARTIAL,        // 仅确认投递，受理情况未知
    BLIND           // 没有确认，也没有可查询状态
}

要看清 PARTIAL 那一行：确认请求送到了，不等于确认动作已经被受理。

FULL 能返回明确结果，投递和受理都有确认。作者举了带写入 API 的日历服务、带投递回执的消息平台作为例子，但具体接口仍需检查：回执究竟证明了什么，不能只看产品类别。

RECONCILABLE 无法直接确认，却允许事后查询。执行前保存快照，执行后查询状态，再比较差异，就能寻找动作生效的证据。这里的核验，也就是 reconciliation，是把预期动作和实际状态对起来。

PARTIAL 只承认收到请求，无法说明动作是否落实；BLIND 连回执和状态查询都没有。对于后者，Agent 唯一知道的是自己发起过执行。

没有收到确认，既不能直接判成功，也不能直接判失败。

为什么核验策略必须在执行前确定

如果等后端沉默了才决定怎么补救，需要的证据可能已经来不及准备。例如，事后查到了一个预约，却没有执行前快照，就很难判断它是否由这次操作创建。

作者用 DispatchStrategy 保存四项信息：能力层级 tier、核验标识 reconciliationKey、最早允许核验的时间 eligibleForReconciliationAt，以及是否需要人工验证的 requiresManualVerification。

buildDispatchStrategy(tier, now) 根据能力生成策略：

• FULL 不生成核验标识，时间设为 now，无需人工验证。
• RECONCILABLE 调用 generateReconciliationKey()，等待一致性窗口后再核验，无需人工验证。
• PARTIAL 同样生成标识并等待窗口，但要求人工验证。
• BLIND 不生成标识，将核验时间设为 Instant.MAX，要求人工验证。

代码用 CONSISTENCY_WINDOW_SECONDS = 30L 定义窗口，再通过 now.plusSeconds(CONSISTENCY_WINDOW_SECONDS) 计算时间。等待的理由是复制延迟：刚写完立刻查询，可能读到旧状态，继而把尚未可见的结果误判为没有发生。

这里的 30 秒是示例配置。原文没有提供延迟分布或测试数据，不能把它当成所有服务都适用的参数。

动作记录要保存证据边界

作者把能力层级和执行策略一起放进 ActionRecord，并保留 delivery、acceptance 两条状态轴。投递是否完成、动作是否受理，要分别记录。

记录还包含 actionId、dispatchId、可空的 providerObjectId，以及 dispatchedAt、可空的 confirmedAt 和最早核验时间。这样，下游确认处理和核验任务读取记录就能工作，不必到处判断具体接了哪家服务。

对于 BLIND，Instant.MAX 表示记录永远不会进入自动核验。按照作者的状态模型，它会停留在 DENIED_UNRESOLVED，直到人工或更高层信号解决。这个状态名来自前文；本篇没有完整解释其状态转换规则，不能仅凭名称把它理解成后端明确拒绝。

作者强调在服务注册时声明能力，而每条动作记录保存相应策略。这个安排的价值，是让「接下来能查什么、何时查、谁来确认」成为执行时已经确定的信息。

我的判断

我认同把「结果未知」明确建模。相比统一等待超时后报失败，这种设计保留了证据边界，也让自动核验和人工处理有了明确入口。

不过，这是一篇设计经验分享，没有给出生产实测、误判率或与其他方案的对照数据。

分层也有前提。同一个服务的不同操作可能具有不同确认能力，接入时应逐项检查，不能只给整个品牌贴一个标签。状态差异也未必能唯一归因到当前动作：如果有人同时修改预约，快照比较需要额外的关联证据。原文没有展开这些情况。

另一个缺口是 PARTIAL：代码为它生成核验标识，却没有说明可查询什么、如何核验。标识可以帮助追踪，但不会自动补出后端缺失的证据。幂等键则解决重复执行问题，也不能替代结果确认。

能拿来做什么

• 给 Agent 的工具接口补充确认能力声明，分别核对投递回执、业务受理结果和状态查询能力，再决定采用哪种策略。
• 在 Node 执行任务时保存动作记录、执行前快照和核验时间，让后台任务按记录处理，并根据实际延迟配置一致性窗口。
• 在前端分别展示「已发送」「已确认」和「待核验」，让用户看到当前证据支持的状态。
• 对缺乏确认能力的操作保留人工处理入口；仅因没有回执就自动重试之前，先检查是否可能造成重复执行。