Webhook Trigger 让外部系统主动启动 Dify Workflow。稳定接入需要先冻结请求字段和认证方式，再把通过校验的数据交给智能体；收到 HTTP 请求不等于业务已经成功。 本文按 Dify 当前 Trigger 文档整理，未连接你的外部系统实测；公网入口的签名、重放防护、速率限制和敏感数据处理需按两端实际能力设计。
本篇验收要点：在 Trigger 中取得当前 Webhook 地址和请求结构，外部系统发送测试事件后，只把经过校验的字段映射给后续 Agent。 为每个请求传入唯一 event_id，在 Dify 运行历史中核对输入、分支、错误和输出，重复 event_id 不得产生第二次业务写入。
开始前准备
- 一个 Dify Workflow 与 Webhook Trigger
- 可配置请求的外部系统
- event_id、event_type、occurred_at 和 payload 契约
- 只处理测试数据的下游动作
按顺序搭建
- 在 Start/Trigger 设计中定义 event_id、event_type、occurred_at、payload，区分必填与可选字段，限制 payload 大小。
- 复制当前环境的 Webhook 地址，先用最小 JSON 发起测试。生产地址、测试地址和应用版本不要混用。
- 在智能体前加入校验：来源认证、时间窗口、允许的 event_type、字段类型和 event_id 去重。校验失败直接返回错误，不调用模型。
- 把 payload 中确实需要的文本映射到 Agent，并把 event_id 一路传到结果和外部写入节点。
- 发送正常、缺字段、伪造类型、重复 event_id 和下游失败五种请求，在运行历史中逐条核对。
可复制的最小示例
建议先用最小事件契约联调：
{
"event_id": "evt_20261001_001",
"event_type": "ticket.created",
"occurred_at": "2026-10-01T13:00:00Z",
"payload": {"ticket_id": "T-883", "text": "无法登录"}
}
怎样验收结果
验证标准是合法事件只生成一次运行，非法或过期请求在模型调用前被拒绝，运行历史能按 event_id 找到输入和失败节点，下游失败不会被响应包装成业务成功。
- 缺少 event_id 的请求被拒绝
- 相同 event_id 重放不会重复写入
- 敏感签名和令牌不进入模型提示词
- 运行日志能定位具体失败节点
常见失败与处理
- 请求到达但变量为空：对照 Trigger 实际解析的 body 路径。
- 外部系统反复重试：返回明确状态，并在服务端保存 event_id 幂等记录。
- Workflow 成功但业务失败：把下游结果作为终态判断，不用 HTTP 接收成功代替。
读者下一步是用一个固定 event_id 的测试 JSON 调通 Webhook，再重复发送同一请求验证幂等处理。
相关问答
Webhook 地址能公开在前端吗？
不应把仅凭 URL 就能触发敏感流程的入口暴露给不可信客户端；至少使用平台支持的认证，并在后端代理校验。
Dify 能自动防止重复事件吗？
不要假定。业务系统应以 event_id 建立可核对的幂等记录，并用实际测试确认平台行为。
官方资料与适用边界
Ai菜鸟网。发布者：AI小管家，转载请注明出处：https://www.alyyhw.com/32436.html
