AI工作流如何靠遥测减少返工

AI 自动化最容易留下的麻烦，是系统说任务完成了，业务侧却还在补单、查重、追结果。作者提出：记录工作流里的交接、重试、耗时和外部结果，用这些证据判断任务是否成功。

这篇短文的价值在于给出了一套可落地的观测清单。不过，它没有提供团队实测或返工下降的数据，更适合当作工程检查表，而不是已经验证的效果报告。

慢在哪里，要沿着状态变化去找

作者把生产工作流看成一连串状态变化。模型生成动作之后，可能还要等待 API 响应、人工审批或补充输入。只记录一次调用的总耗时，很难知道问题出在哪一步。

建议给每次运行和每个步骤记录这些信息：运行标识（run ID）、步骤标识（step ID）、时间戳、校验状态、下游响应码和外部执行结果。

这些字段要跟随持久化的运行状态保存。某一步失败之后，系统需要知道之前做过什么、现在停在哪里，才能决定继续、重试还是转交人工。

作者给出的基线包含五类信号：

• 完成率。
• 步骤耗时的中位数和第 95 百分位数。
• 每次运行的重试次数。
• 异常率。
• 人工介入率。

这里的第 95 百分位数，用来观察较慢的那部分步骤。中位数看着正常，并不代表用户不会遇到长时间等待。

指标还要按工作流和工具分别统计。把所有任务混在一起算平均值，可能会掩盖某一个持续出错的集成。

重试能救失败，也会制造重复业务

调用失败后再试一次，看起来很自然。但请求超时，未必代表下游没有执行成功。

假如系统已经写入 CRM，只是响应没有及时返回，再次执行就可能产生重复记录。发票和客户消息也有类似风险。

作者建议为每个预期动作分配幂等键（idempotency key），并把它和工作流状态一起持久化；同时限制尝试次数，超过上限的运行进入死信队列（dead-letter queue），等待后续处置。

重试是否安全，取决于系统能不能识别同一个业务动作。

这里有个原文没有展开的前提：保存幂等键只是起点，执行链路还得实际用它去重。作者没有说明键的生成规则、有效期，以及下游不支持幂等时如何处理。接入具体业务之前，这些仍然需要设计。

完成的依据，要从外部系统拿回来

作者划了两条边界：模型可以提出动作，执行权限由确定性服务掌握；模型可以声称完成，成功与否由外部证据决定。

确定性服务，就是按明确规则检查并执行的程序。它需要在执行前校验数据结构、权限、操作者、资源和具体操作。高影响变更还需要审批记录，并带有外部引用，便于追溯。

成功条件也应足够具体。例如拿到工单 ID、交易流水引用、记录版本，或者已经确认的送达状态，再把证据附到运行记录上。

模型回复「已完成」，不能替代业务系统的确认。

这些证据也要结合任务目标解释。获得工单 ID 能证明工单已经创建，却不能证明工单已经解决。原文列出了证据类型，没有进一步定义每类业务的完成标准，落地时需要补齐。

我的判断

我认同作者把重点放在状态、权限和结果证据上。相比只记录提示词、模型回答和调用耗时，这套方法更接近业务真正关心的问题：动作有没有执行、有没有重复、失败后谁来处理。

不过，标题所说的「减少运营返工」缺少对照数据。原文没有给出实施前后的返工量、成本变化或样本规模，这仍是一组工程主张，不能据此估算收益。

它与传统工作流系统的运行日志、幂等控制和故障队列也有大量重合。AI 场景增加的关键要求，是把模型建议与执行权限分开，并拒绝把生成文本直接当作执行结果。

作者建议每周复盘，按故障量和返工成本排序，为问题指定一名负责人，先修影响最大的工作流。这个做法合理，但观测数据只有进入修复流程，才可能减少返工。

能拿来做什么

• 在现有 Node 自动化服务里，先补齐 run ID、step ID 和步骤状态，把模型耗时、API 等待和审批等待分开记录。
• 给 CRM 写入、发票创建、客户消息发送等动作检查重试策略，确认幂等键确实参与去重，并设置尝试上限与死信去向。
• 为每类任务写出明确的成功条件，让运行记录保存工单 ID、交易引用或送达确认等证据。
• 每周按工作流和工具查看五类指标，结合故障量与返工成本选出优先修复项，并指定负责人。