OpenClaw 接入外部系统时，Webhook 是很常见的入口。表单提交、CRM 状态变化、工单更新、支付回调、代码仓库事件，都可以触发一个 Agent 工作流。但 Webhook 入口一旦设计粗糙，就会带来误触发、重复执行和安全风险。
前面写过 任务队列与并发控制、失败重试与幂等设计、连接器审计，Webhook 触发器正好把这些能力放到入口层。
第一步是来源验签
Webhook 不能只靠一个公开 URL 接收事件。至少要校验签名、时间戳和来源系统。不同系统的签名规则不一样，但目标一致：确认这条事件确实来自可信系统，而且内容没有被中途篡改。
验签失败的请求不要进入工作流，也不要触发重试。它应该被记录为安全事件，方便后面检查是否有人扫接口、伪造事件或配置错了密钥。
事件去重是必需项
很多外部系统会重复发送同一条 Webhook，尤其是在网络不稳定或接收方返回超时时。如果 OpenClaw 每次都当成新事件处理，就可能重复发消息、重复更新 CRM、重复创建任务。
所以每条事件要有幂等键，可以来自事件 ID，也可以由来源系统、对象 ID、事件类型和时间窗口组合生成。进入队列前先查幂等键，已经处理过的事件只更新接收日志，不再重复执行工作流。
重放保护别等出事再补
攻击者或误配置系统可能把旧事件反复发回来。如果没有时间戳校验和重放保护，旧订单、旧工单或旧审批可能再次触发流程。Webhook 入口应该拒绝超过时间窗口的事件，并记录异常原因。
对高风险动作，比如外部发送、权限修改、付款相关通知，还可以接入 人工确认节点，让 Agent 先生成建议，不直接执行最终动作。
触发器也要有限流和审计
Webhook 入口可能被突发流量打满。速率限制、队列缓冲和失败重试要提前设计。低优先级事件可以排队，高风险事件可以暂停确认，明显异常的来源可以临时熔断。
审计日志要记录请求来源、验签结果、幂等键、入队状态、触发的工作流版本和最终处理结果。后面做 影子模式 或灰度发布时，这些记录会非常有用。
总结
OpenClaw Webhook 触发器不是简单收一个 HTTP 请求。来源验签、事件去重、重放保护、速率限制、失败重试和审计日志都要在入口层做好，外部系统事件才能安全地进入 Agent 工作流。
