實踐：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 請求寫入資料看板系統，統計告警趨勢與回應時長。