AI 工作流要区分鉴权失败与追踪失败

业务已经成功，追踪服务却超时了，整个工作流该不该重跑？作者的结论是：可观测性故障不该拖垮生产流程，但必须先分清，失败的是业务、权限检查，还是追踪记录的投递。把这些异常统一处理，可能补回一条日志，却多执行一次业务。

这篇短文的价值在于拆清失败边界。它没有可用性实测，也没有交付保证，提供的是一组值得拿去审查 AI 工作流的设计问题：哪些结果已经确定，哪些操作可以重试，缺失的证据又该如何被发现。

先确认谁失败，再决定要不要重试

一个工作流可能连续做三件事：检查权限、执行业务、发送追踪记录。它们在代码里挨得很近，失败后的处理却不能共用一条规则。

权限检查不可用时，系统无法确认当前操作是否被允许，不能把异常当作可选日志忽略。完整性检查也应留在必要的控制路径上。相反，已经获得授权、并且确认完成的业务操作，不该因为后续追踪投递失败就被判定为失败。

业务结果与追踪投递结果，应当分别记录。

例如，同一次执行可以处于「业务已确认成功，追踪仍待投递」的状态。这比一个笼统的「执行失败」更有用，因为恢复程序可以据此判断该补什么。

这里的追踪记录（trace），可以理解为工作流留下的执行证据，包括做过什么决策、识别了什么风险、是否进入人工审核。记录没送到，不等于业务没发生；业务是否发生，也不能只靠追踪平台里有没有记录来判断。

所以，作者建议先问「哪个职责失败了，哪些状态已经确定」，再讨论异常要不要吞掉。

补追踪记录，为什么可能多出一条审核任务

作者构造了一个虚拟案例：工作流把一个项目转入人工审核，路由操作已经确认成功，随后向可观测性桥接层（bridge）发送追踪记录时超时。

如果编排器遇到任何下游异常都重跑整个流程，就可能再次创建审核项。此时，可观测性故障已经变成了业务重复执行。

作者提出的恢复方向，是利用追踪记录与原有执行之间的关联，只重试追踪操作，或核对、补齐缺失记录，而不是推定审核路由失败。

不过，这只是用来解释边界的假设案例。原文没有报告真实事故，没有给出已实现的队列配置，也没有验证任何投递保证。桥接模式在这里说明的是职责如何分开，不能据此认定它已经解决了可靠投递。

另一个容易忽略的问题是慢请求。即使追踪失败不会直接终止业务，持续等待、不断积压的投递任务，仍可能间接影响业务路径。因此，审查设计时还要看重试次数、等待时间和缓冲是否有界，以及重试后能否保留同一次执行的身份。

业务可以继续，缺失的证据也必须有人发现

不让追踪故障中断业务，不代表可以丢掉这个故障。

如果连续投递失败，却没有独立的运行信号暴露问题，团队就会失去判断依据：追踪平台没有记录，究竟是业务没发生，还是记录没送到？

作者要求保留发现这类缺口的能力，并能够核对缺失结果。但原文没有规定必须使用哪种告警渠道，也没有证明已有的告警机制能在追踪目的地失效后正常工作。这些都需要实现和验证。

降级路径还必须遵守数据最小化。追踪服务不可用时，把原始消息、认证材料、私有业务载荷全部写进本地日志，并不是合格的恢复方案。缩减后的追踪仍应使用获准字段和脱敏引用，描述决策、风险及审核状态。

可观测性降级，不能顺便降低数据保护要求。

作者认为，下一步证据应来自受控中断测试和核对记录。公开契约说明了标准化、脱敏的追踪字段与安全边界，但规则写在文档里，并不能证明运行时遵守了它；覆盖率和审核结果捕获情况也仍需收集。

我的判断

我赞同把「业务是否成功」和「证据是否送达」拆开。相比在最外层统一捕获异常、统一重试，这种处理更能表达实际状态，也更容易限定恢复操作的范围。

它的前提同样明确：系统得有可信的业务结果记录，还得能把补投递关联回原来的执行。原文没有讲清这些状态如何持久化，也没有交代业务执行结果不确定时该怎么办。因此，这是一组设计原则和审查问题，不能直接当成完整的恢复方案。

与同步等待追踪相比，缓冲后投递可以作为候选做法，但它会引入积压、容量和核对问题。作者没有提供两种方案的对照数据，也没有展示故障注入结果，不能据此宣称某种架构更可靠。

这篇文章最值得保留的，是它对验证标准的要求：别只检查流程有没有继续跑，还要检查有没有重复业务、缺了哪些记录，以及这些缺口是否能被发现。

能拿来做什么

• 审查 Node 或 AI 工作流的重试入口，逐项区分权限检查、业务执行和追踪投递，尤其检查「任一步报错就重跑全部」是否会重复创建任务。
• 为执行结果保留独立的业务状态和追踪状态，让排查人员能够区分「业务未发生」与「业务已完成但记录缺失」。
• 在测试环境中模拟追踪目的地超时和持续不可用，检查业务是否重复、等待任务是否积压，以及独立的运行信号能否暴露缺口。
• 检查追踪失败后的日志降级路径，继续使用获准字段和脱敏引用，避免把原始消息、认证材料或私有载荷作为兜底日志写出。