实践：Webhook 告警自动处理

本篇以「Webhook 告警自动处理」为例，讲解蓝域（LanSphere）工作流中 Webhook 回调触发器、条件判断分级路由、知识库检索与蓝信 MCP 通知的组合用法。与定时触发不同，Webhook 由外部系统主动调用，适合事件驱动的实时响应场景。适合需要对接监控系统、实现告警自动分发与处理的运维与开发人员阅读。

场景与价值

监控系统产生的告警靠人工盯屏处理，问题不少：

• 告警全天候产生，夜间和节假日无人值守时容易漏看；
• 不同级别告警混在一起，值班人分不清轻重缓急；
• 告警来了不知道怎么处理，翻文档查方案浪费时间；
• P0 紧急告警需要同时通知值班人和应急群，手动操作延误响应。

用工作流把告警处理链路自动化：外部监控系统通过 Webhook 回调触发 → 条件判断按级别分路 → 知识库检索处理方案 → 大模型生成摘要 → 蓝信 MCP 通知对应人员与群组，实现秒级响应、分级触达。

你将搭建什么

一个「告警自动处理」工作流应用：由外部监控系统通过 Webhook 回调触发，接收告警 JSON 数据（告警级别、系统名称、告警内容、时间戳）；条件判断节点按级别分为 P0 紧急、P1 重要、P2 一般三路——P0 检索知识库后大模型生成摘要，同时通过蓝信 MCP 私聊通知值班人与群聊通知应急群；P1 检索知识库后大模型生成摘要，群聊通知运维群；P2 大模型生成摘要后记录到输出。

链路：Webhook 回调 → 条件判断 → [P0 → 知识库 → 大模型 → MCP（私聊值班人）+ MCP（群聊应急群）] / [P1 → 知识库 → 大模型 → MCP（群聊运维群）] / [P2 → 大模型 → 输出] → 输出。

推荐流程

准备工作

第一步：创建应用并配置 Webhook 触发器

1. 点击「新建项目」，应用类型选择「工作流」，填写名称（如「告警自动处理」）。
2. 在画布中，开始节点选择「Webhook 回调」（替代默认的「输入」节点）。添加后，平台会生成一个回调地址，外部系统通过 POST 请求调用该地址即触发工作流。
3. Webhook 回调节点会接收外部系统传入的请求体，作为输出变量供下游节点引用。监控系统通常传入 JSON 格式的告警数据，字段示例：

{
  "level": "P0",
  "system": "订单服务",
  "content": "数据库连接数超过阈值，当前 980/1000",
  "timestamp": "2026-08-04T02:30:00Z"
}

4. 在环境变量中新增值班人与群 ID 变量（如 DUTY_STAFF_ID、EMERGENCY_GROUP_ID、OPS_GROUP_ID），值设为对应的蓝信 ID，设为保密变量。

注意：回调地址是触发工作流的唯一入口，保存并发布后才能被外部系统调用。调试阶段可用页面提供的模拟请求功能测试。

第二步：编排条件判断分支

1. 添加「条件判断」节点，连接在「Webhook 回调」节点之后。
2. 配置三个分支，按告警 JSON 中的 level 字段判断：

3. 配置兜底分支，未知级别走 P2 路径（生成摘要后记录到输出）。

提示：条件判断的分支条件引用 Webhook 回调节点输出变量中的 level 字段，确保字段名与监控系统传入的 JSON 一致。

第三步：P0 与 P1 分支连接知识库与大模型

P0 与 P1 分支的链路结构相似，以 P0 为例：

1. 添加「知识库」节点，关联运维知识库，输入引用告警 content 字段（Webhook 输出变量），设置 Top K 为 3、检索方式为混合检索。
2. 添加「大模型」节点，连接在知识库之后，上下文引用告警数据与知识库召回片段，提示词示例：

你是运维告警助手。以下是监控系统传入的告警信息和从知识库中检索到的处理方案：

告警级别：（此处插入 level 变量）
告警系统：（此处插入 system 变量）
告警内容：（此处插入 content 变量）
告警时间：（此处插入 timestamp 变量）
检索结果：（此处插入知识库节点的输出变量）

请生成一段告警摘要和处理建议，要求：
1. 开头标注告警级别与系统名称，一句话概括告警内容。
2. 依据检索结果给出处理建议，分条陈述。
3. 检索结果中没有对应方案时，回复"暂无标准处理方案，请值班人员排查"。
4. 全文控制在 200 字以内，适合在群聊中快速阅读。

3. P1 分支按相同方式连接知识库与大模型，提示词结构一致。

第四步：MCP 节点通知值班人与群组

P0 分支（双路通知）

1. 在大模型节点之后添加第一个 MCP 节点，选择蓝信 MCP 的「发送私聊消息」工具：
   • 接收人引用环境变量 DUTY_STAFF_ID；
   • 消息内容引用大模型节点的输出。
2. 添加第二个 MCP 节点，选择「发送群聊消息」工具：
   • 群 ID 引用环境变量 EMERGENCY_GROUP_ID；
   • 消息内容引用大模型节点的输出。

注意：P0 分支的两个 MCP 节点为串行连接——先私聊通知值班人，再群聊通知应急群。如需并行通知，可使用「批处理」节点。

P1 分支（群聊通知）

在大模型节点之后添加 MCP 节点，选择「发送群聊消息」工具：

• 群 ID 引用环境变量 OPS_GROUP_ID；
• 消息内容引用大模型节点的输出。

P2 分支（仅记录）

P2 分支不检索知识库、不发通知。添加「大模型」节点，上下文引用告警数据，提示词生成简要摘要（一句话概括告警内容即可），直接连接输出节点记录。

第五步：连接输出节点

1. 三个分支最终都连接到「输出」节点。输出内容引用各分支的处理结果：
   • P0/P1：引用大模型摘要与 MCP 节点的发送结果；
   • P2：引用大模型节点的摘要。
2. 工作流通过「输出」节点在结束时返回处理结果，供「对话日志」中追溯。

节点配置速查表

第六步：模拟 Webhook 请求调试

Webhook 触发的工作流无法用普通的整体调试直接测试，需要模拟外部系统的 POST 请求：

1. 在 Webhook 回调节点的配置中，查看平台提供的回调地址与请求格式说明。
2. 用工具（如 curl 或 Postman）向回调地址发送模拟请求，分别测试三个级别：

# P0 紧急告警示例
curl -X POST {回调地址} \
  -H "Content-Type: application/json" \
  -d '{"level":"P0","system":"订单服务","content":"数据库连接数超过阈值","timestamp":"2026-08-04T02:30:00Z"}'

3. 逐节点检查：
   • Webhook 回调：确认节点接收到了完整的告警 JSON；
   • 条件判断：确认告警进入了正确的级别分支；
   • 知识库：确认召回片段与告警内容相关；
   • 大模型：确认摘要包含告警信息与处理建议，无编造；
   • MCP 节点：确认值班人/应急群/运维群收到了对应消息。
4. 每个节点的输入、输出与报错都可在调试详情中查看，过往记录进入「调试历史」回看。

常见问题排查：

第七步：保存与上线

1. 点击「保存」保存工作流。发布前检查清单会自动检查配置完整性与逻辑正确性，按提示补齐缺漏。
2. 点击「保存」按钮下拉 →「发布到应用广场」，或通过「发布渠道」页签开通 API 访问。
3. 复制 Webhook 回调地址，配置到外部监控系统的告警通知规则中，使其在产生告警时自动调用回调地址。
4. 上线后进入应用详情页「对话日志」页签，查看每次告警的触发记录、分级路由与通知结果。

提示：上线初期建议值班人确认收到通知后回复处理结果，核对告警级别路由与通知触达是否准确，再放手让告警链路自动运行。

调优与边界

扩展思路

• 告警聚合：用「脚本执行」节点对短时间内同一系统的多条告警做聚合，合并为一条通知；
• 自动恢复检测：监控系统在告警恢复时再次调用 Webhook，工作流根据 level 走恢复通知分支；
• 工单系统联动：P0 告警额外连接工单系统 MCP 创建工单，自动派单给值班人；
• 多渠道通知：除蓝信外，通过 HTTP 请求节点调用短信/邮件网关，实现多渠道触达；
• 告警看板：将每次告警处理结果通过 HTTP 请求写入数据看板系统，统计告警趋势与响应时长。