OpenClaw 工作流上线以后，最怕的不是失败，而是失败没人知道。一个 Agent 卡在外部接口等待里，一个队列任务反复重试，一个知识库返回空结果但系统照常回复，用户可能已经受影响了，运营团队还以为一切正常。
异常告警就是把这些问题提前暴露出来。它和 Agent 观测性、失败重试与幂等、事件重放 连在一起：先发现，再定位，再复盘。
失败率只是第一层信号
最容易做的告警是失败率，比如某个工作流 10 分钟内失败超过 5 次，或者失败比例超过阈值。但失败率只能发现显性错误，发现不了慢、堵、漏和静默错误。
所以每个关键节点都应该记录成功、失败、跳过、等待人工、重试中、已超时等状态。只看最后成功失败，很容易低估问题。
超时比失败更值得盯
很多 Agent 任务不会立即失败，而是卡住。外部 API 不返回、队列积压、人工确认没人处理、模型调用迟迟超时，这些都会让流程停在半路。对用户来说，卡住和失败一样糟糕。
OpenClaw 告警里应该有节点级超时和整条流程超时。比如工具调用超过 60 秒、人工确认超过 4 小时、队列等待超过 10 分钟，都可以触发不同级别提醒。
静默错误要靠业务指标发现
静默错误更麻烦。系统显示成功，但结果其实不对。比如工单被分到了错误队列，客户邮件缺少关键附件，知识库问答引用了旧文档，报销初审漏掉重复票据。这类问题不一定会抛异常。
发现静默错误，要结合业务指标和抽样复核。可以把 AI Agent 评估指标 里的复盘思路放进 OpenClaw 运行看板里，定期抽查“成功任务”的质量。
告警要降噪，否则没人看
告警太多，等于没有告警。不同问题要分级：低风险进入日报，中风险发到团队频道，高风险才打断负责人。连续重复的同类告警要聚合，而不是每失败一次都发一条。
告警内容也要带上下文：来源事件、任务 ID、失败节点、影响对象、最近重试、建议动作和是否可重放。这样负责人看到告警后能直接处理，而不是再去翻一堆日志。
总结
OpenClaw 异常告警的目标，不是把所有错误都喊出来，而是让团队在用户投诉前发现关键问题。失败率、超时、重试耗尽、静默错误和人工接管都要进监控，但告警必须分级、聚合、带上下文。
