人工审批无人响应，工作流该如何超时

n8n 的执行记录全绿，客户却等了三天也没收到回复。作者遇到的问题没有出在 LLM 或发送节点，而是卡在人工审批：审批人休假，工作流就一直等着，最终积压了 40 份草稿。

这篇文章的结论很明确：人工审批也是一种会不可用的依赖，必须设置等待期限、升级路径和最终处理动作。它值得 AI 工作流开发者读几分钟，因为「等人确认」很容易被当作安全措施，却没有被当作故障来源。

为什么节点全绿，业务仍然停了

作者的工作流负责起草客户消息的回复，交给人工审核，通过后再发送。它连续几周运行正常，直到一个周一，审核队列里堆了 40 份未批准的草稿，最早的一份已经等了三天。客户追问后，问题才暴露出来。

系统没有报错，因为它确实在按设计等待。审批人休假这件事，却没有进入工作流的处理逻辑。

执行没有失败，不等于业务已经完成。

人工介入（human-in-the-loop）保留了人的判断，也引入了人的可用性约束。人会休假、生病、忙不过来。如果流程只定义「批准后做什么」，没有定义「一直不批准怎么办」，业务完成时间就没有上限。

这也是此类问题难排查的原因：错误监控盯着失败节点，真正的故障却藏在一个合法的等待状态里。

每个人工审批，都要补齐三种安排

作者提出的第一项是超时期限。期限由业务决定：客户回复可以设为 4 小时，内部报告可以设为 1 个工作日。这些是文中的示例，并非适用于所有团队的标准。关键是提前写清楚，不能拿「等到有人批准」充当截止时间。

第二项是超时后的升级处理。到期后，任务应转给第二审批人、共享频道或值班人员。升级必须成为明确的工作流步骤，不能寄希望于有人主动查看队列。

提醒内容也要能推动处理。作者采用的消息会写明具体事项、已等待时间和所需动作，例如某位客户的回复草稿已等待 4 小时，请在指定位置批准或拒绝。泛泛地说「有待处理事项」，很容易继续被忽略。

第三项是升级后仍无人处理时的默认动作。作者对客户回复的选择是发送一条接收确认，告知客户消息已收到，后续由人工跟进；对内部草稿，则移入过期待处理列表并发出告警，不直接发送。

超时后的默认动作，要比较持续沉默与错误发送各自的代价。

接收确认没有解决客户的问题，但可以避免完全没有回应。内部草稿则可能宁可延后，也不能未经审核流转。这个取舍应该在上线前做，而不是等队列塞满再临时决定。

审批队列该监控什么

作者跟踪两个指标：最早一份未审批事项已经等待多久，以及超过各自截止时间的事项有多少。

前者能暴露长期被遗忘的单个任务，后者能反映超期积压的规模。任一指标越过阈值，作者都会像处理执行失败一样接收告警。

这里有个很实用的变化：审核队列从「想起来就看一眼」，变成了有期限、有指标的运行对象。节点错误仍然要监控，但它无法代替对业务停滞的监控。

原文没有给出这两个指标的具体告警阈值，也没有提供 n8n 节点配置、计时实现或升级后的第二次等待期限。它讲清了需要哪些机制，还没有展开成可以直接导入的完整方案。

我的判断

我认同作者把人工可用性纳入工作流设计。相比只增加一条催办通知，「超时、升级、默认动作」覆盖得更完整：通知发出去之后，流程仍然需要一个确定的去向。

但超时不能自动等同于放行。客户接收确认适合作者描述的回复场景，不能据此推导出所有 AI 草稿都可以到期自动发送。默认动作需要按消息类型和错误成本分别制定。

作者称这些修复来自其销售、维护的真实模板，并经过测试。不过，文章没有提供修复前后的响应时间、积压数量变化或对照数据。因此，它是一套有实际事故支撑的经验做法，还不足以证明某个期限或升级方式最有效。

另外，接收确认只是暂时回应。后续人工跟进是否完成，原文没有展开，落地时仍需补上这部分责任归属。

能拿来做什么

• 检查现有 n8n 或 AI 编程工作流中的人工确认步骤，为每一步写清截止时间、超时接收人和最终动作，优先处理目前无限等待的环节。
• 对客户回复草稿，把「发送正式答复」与「发送接收确认」分别定义，避免超时逻辑绕过原本必须保留的人工审核。
• 如果你负责 Node 服务或审批页面，就把最早未审批事项的等待时长、超期事项数量接入监控，让队列停滞能够触发告警。
• 在上线验收时模拟审批人一直不响应，沿着超时、升级和默认处理走完一次，检查业务是否真的有后续去向。