Webhook
一种HTTP回调机制，当特定业务事件发生时，系统自动向指定URL发送POST请求，常用于实现系统间的事件驱动集成
核心事实
时间轴 (近 90 天)
在Agent系统中，Webhook让外部世界的变化直接成为Agent的启动信号；cron是基于时间表的定时触发器，适合周期性任务；两者结合可覆盖事件驱动与时间驱动两类自主触发场景。
Webhook 自动注册依赖服务商通过 API 提供以编程方式创建、更新和删除 Webhook 订阅的能力。
在 Vercel 无状态函数模型下处理 Webhook 时，事件可能重复投递，处理逻辑需要具备幂等性。
告警验证动作可以绑定到 webhook 目的地而非全局开关，使得同一 monitor 可以并行配置多个目的地：一个带 Critical Only 过滤的呼叫通道，以及一个接收全量告警的归档通道。
事件驱动架构（如Webhook或消息队列）是唤醒智能体的更优雅方案，但要求智能体平台提供回调接口，而目前多数个人助手并未开放此类能力。
Linear和Jira都提供API与Webhook，允许外部工具读取任务状态、更新工单或嵌入链接。
调度器负责按时间或事件触发Agent运行，如cron定时器、Webhook，使Agent能脱离人工指令在后台周期性执行任务。
对于已有 CI 流水线的团队，API 方式比 Webhook 更适合做安全门禁控制。
Webhook 端点需要校验签名以防伪造、实现幂等处理以应对重复投递，并通常先返回 2xx 再异步处理业务逻辑。
Claude Security 开放了 API、MCP 连接器和 Webhook 三种集成方式。
还有 40 条时间轴事件
全部知识事实 (20)
事件触发依赖 Webhook 机制——外部应用在事件发生时向 N8N 提供的 URL 发送 HTTP 请求，N8N 收到后即启动对应 Workflow。
75%已验证Webhook本质上是一个HTTP回调，仓库检测到代码推送等事件后向预配置的URL发送POST请求
75%已验证Webhook 是一种反向 API，不是由 n8n 主动请求外部服务，而是对外提供一个专属 URL，任何服务向该地址发起 HTTP 请求时即可触发 n8n 工作流。
70%已验证Webhook 签名验证通常使用 HMAC-SHA256 算法，签名覆盖时间戳与请求体内容，接收方用共享密钥本地重算签名并比对。
65%已验证Webhook必须经过签名验证，否则任何人都可以伪造请求来唤醒智能体，带来安全风险
65%已验证Webhook请求可能因超时、重试或消息队列的至少一次投递（at-least-once delivery）语义而被重复发送
65%已验证在n8n中，工作流（workflow）内放置的每一个功能单元叫做节点（node），通过连接节点让流程运行
65%已验证Webhook触发器适合需要实时响应外部事件的场景，而定时触发节点适合批量处理、定期同步等场景
65%已验证n8n的Webhook触发节点分为测试URL（test）和生产URL（production）两种模式，测试URL路径中带有test字样，主要用于配合Execute Workflow按钮进行开发阶段调试
65%已验证与轮询方式相比，webhook 无需客户端反复查询状态，延迟更低、资源消耗更少
65%已验证n8n支持三类触发器：Webhook触发、轮询触发、定时触发(按Cron表达式执行)
65%已验证Webhook 是一种反向 API 机制，业务系统在状态变更时向预先注册的 URL 发送 HTTP POST 请求，延迟通常在秒级以内
65%已验证Webhook 采用推送模型，当源系统发生事件时主动向目标 URL 发送 HTTP POST 请求，相比轮询（Polling）模式在延迟和资源消耗上有显著优势
65%已验证n8n回传结果时应使用HTTP请求节点而非Respond to Webhook节点
65%已验证如果在Webhook回调阶段才扣除积分，用户积分不足时任务已经完成，AI算力已消耗但积分无法扣除
65%待验证在AI SaaS架构中，n8n工作流通过Webhook与前端通信，而非通过表单触发
90%待验证飞书提供完整的机器人消息推送接口，允许外部系统通过HTTP请求将结构化内容直接发送到指定群组或文档
90%待验证成熟的系统通常采用Webhook加轮询兜底的双重机制来确保任务状态获取的可靠性
85%待验证积分预检和积分扣除是两个独立的环节，预检在任务提交前拦截积分不足的请求，扣除在Webhook回调时执行
85%待验证在典型的AI SaaS架构中，主流做法是客户端提交任务后立即获得任务ID，后端异步处理，处理完成后通过Webhook回调通知结果
85%