为 AI 工作流建立可追踪的异常契约

AI 生成的运营简报可能条理清楚，却还不具备执行条件：交期有了，审批没找到；两个系统的状态互相矛盾；建议的下一步超出了操作者的权限。作者提出，工作流需要一份「异常契约」，把这些未决事项变成可追踪、可分派、可关闭的数据。

这里的重点不是让模型更会解释，而是让系统明确表达：知道什么、缺什么、谁来处理，以及当前能不能执行。原文给出了具体设计建议，但没有提供异常处理带来收益的量化证据。

信息缺失，不能被写成业务结论

作者首先区分了两件容易被 AI 混在一起的事：观察与解释。

「审批字段不可用」是对信息状态的观察，「审批被拒绝」则是业务判断。前者可能来自接口故障、数据尚未同步，也可能只是当前账号没有读取权限。系统不能因为没查到，就替业务补一个否定结论。

缺少证据，应当成为待处理状态，而不是自动生成的业务事实。

一条自由文本警告能提醒人，却很难稳定地分派、去重和关闭。作者建议，异常记录应包含类型、来源上下文、受影响的工作、负责人和解决状态。

下面这段虚构记录，用来表达「审批情况无法确认，因此暂缓执行」：

{
  "type": "approval_context_missing",
  "observed_state": "required approval could not be established",
  "proposed_action": "hold for review",
  "owner_role": "production_coordinator",
  "resolution_state": "open",
  "execution_allowed": false
}

要看最后一行：execution_allowed 明确为 false，把建议动作和执行许可分开了。

但这只是说明契约的例子，不是生产环境导出的完整记录。作者也明确指出，实际实现还需要稳定标识和经过授权的来源引用，同时避免把私密原始内容暴露到公开日志中。

人工介入要写清任务，恢复流程要写进状态机

队列里只有一句「AI 不确定」，操作者就得从头调查。更有效的待办应该直接要求一个动作：确认适用的审批、解决来源冲突，或者指定负责人。

运营简报也应同步展示已知事实、未解决的依赖，以及建议动作受阻的原因。这样，人才能明确安排优先级。

作者用标准操作流程（SOP）更新举了另一个例子：Agent 可以整理修改建议，但在责任人和必要审批人处理之前，它仍然是草稿。缺少审核应被记录为异常，不能成为发布草稿的许可。

异常还会变化。缺失字段可能补齐，冲突可能消除，已经作出的决定也可能因来源更新而失效。这就需要状态机：明确哪些事件能让事项从未解决转为已解决，哪些变化需要重新打开它。

重试时，应尽可能更新或协调已有事项，避免每跑一次就多一条通知。关闭时，要保留关闭原因和证据。

这里还有一个实用区分：

• 连接器暂时不可用，可以考虑技术重试。
• 政策决定尚未明确，需要交给有责任和权限的人。

把两者都放进「稍后重试」，只会让需要人处理的工作继续悬着。作者没有声称案例中的所有状态迁移路径都已验证，这部分仍属于实现建议。

日志要能追责，也要说明自己漏了什么

作者建议，追踪记录应识别工作流、决策、结果、风险和审核状态，通过脱敏引用关联有权限访问的证据，而不是直接倾倒客户消息或凭证。

另一个要求更容易被忽略：日志系统出故障，不应不受控地拖垮整个业务流程；但系统也不能隐瞒审计覆盖缺失。

究竟继续执行、限制操作还是暂停，要看具体动作的要求，并提前定义降级行为。原文没有给出统一答案。

衡量异常处理是否有效，也不能只看「关闭了多少条」。作者建议采集未解决事项的存续时间、反复转交情况、缺少负责人的情况，以及来源变化后重新打开的异常，并结合审核投入和错误分析一起看。

这些都是建议采集的指标，原文没有给出测量结果。

我的判断

我认同这套设计最有价值的地方：它让 AI 的表达能力服从工作流的事实和权限边界。尤其是涉及审批、跨系统状态和流程修改时，一段措辞确定的回答很容易被误当成执行依据。

和只加一句「请人工确认」相比，结构化异常更容易进入队列、指定负责人、协调重试，也更方便追查为什么曾经允许或阻止某个动作。

但契约本身不会自动生效。execution_allowed: false 必须被实际执行路径读取和遵守；负责人字段也需要对应真实的职责安排。原文没有展开这些约束怎样落地，不能仅凭这段 JSON 判断系统已经具备执行控制。

作者提到的电商运营案例和可观测性案例，都没有建立异常处理收益的量化证据。因此，这是一套有参考价值的设计主张，尚不足以证明它比现有人工队列或工单流程更省时。已有成熟审批系统的团队，更适合先把 AI 产生的未决事项接入现有流程。

能拿来做什么

• 给 AI 工作台设计异常展示时，分别呈现缺失信息、来源冲突和权限不足，并为每条事项写出具体下一步，避免统一显示「生成失败」。
• 在 Node 工作流中区分技术重试和人工决策；重试时关联已有未决事项，关闭时保存原因及来源上下文。
• 让 Agent 起草 SOP 更新时，保留草稿状态，把责任人处理和必要审批作为发布条件。
• 检查现有运营简报能否直接用于执行：逐项确认依赖是否满足、权限是否足够，以及审计信息不完整时系统会如何处理。