Dify+MCP：泵類設備的預測性維護案例 （升級版 ）
上篇文章中，給大家分享了一個使用 Dify+RAGFlow 實現的泵類設備的預測性維護案例，過去兩天里有很多盆友在后臺私信我了一些實現細節，比如：HTTP 請求的數據存在哪里？ IoT 平臺的數據能否直接實時“流”入 Dify？以及如何使用 MCP 的方案實現四個數據源（IoT, CMMS, MES, ERP）的智能查詢。
前兩問的回答昨 晚我已經寫在了知識星球內，感興趣的移步去翻下。這篇文章試圖說清楚：
如何使用 Dify 自定義工具實現 MCP 的方法， 從而標準化 LLM 與多個數據源的交互方式。
以下，enjoy:
1、MCP 的統一之美
有關 MCP 的基礎概念這里不做贅述，如果有不清楚的盆友可以翻下我之前的一篇文章快速掃盲后再往下看。
都說 MCP 在連接和利用來自多個異構系統的數據方面，扮演著所謂標準化粘合劑和智能調度員的角色，那 MCP 到底好在哪里，按照公開的說法和個人實踐體驗，按如下三點進行介紹：
1.1 標準化接口層
每個系統（ERP、MES 等）都有自己獨特的 API 接口、數據格式和認證方式。在 Dify 中直接調用意味著需要為每個系統配置和維護不同的 HTTP Request 節點，邏輯復雜且脆弱。
上篇文章中介紹的工作流，圈出的是4個http請求節點
通過創建 Dify 工具 (Tool)，每個工具都封裝與對應系統 API 交互的細節（URL、參數、認證、數據解析）。這樣 Dify 的 Agent 或工作流不再需要關心底層 API 的復雜性，只需要知道調用一個名為 get_erp_stock 或 get_latest_iot_reading 的工具即可。這會極大地簡化了工作流的編排，提高了可維護性和可重用性。
使用Dify的自定義工具替換了原有工作流中的四個http請求節點
1.2 上下文智能聚合
其次，LLM 的能力很大程度上取決于提供給它的上下文的質量。簡單地將來自不同系統的原始數據堆砌給 LLM 可能效果不佳。
上述提到的 MCP 理念構建的工具可以被 Dify Agent 智能地選擇和調用。例如，當用戶問：“PUMP-CNC-001 狀況如何？需要訂購備件嗎？” Agent 可以識別出需要調用 get_latest_iot_reading 工具獲取實時狀態。 根據 IoT 狀態（比如振動高），Agent 可能進一步判斷需要調用 get_cmms_history 工具查看類似故障記錄。 同時，調用 predict_failure 工具。 如果預測需要更換軸承，Agent 會調用 get_erp_stock 工具查詢 CFP5K-BRG01 的庫存。
MCP 的方法可以讓 Agent 能夠根據任務需求，動態地、按需地從多個系統中拉取最相關的信息，并將這些信息結構化地整合為高質量的上下文，再提供給 LLM 進行分析、預測或生成報告，而不是一次性將所有可能的數據都查詢出來。
此處需要說明的是，上下文智能整合的作用更多的體現在Agent中，下文會進一步說明。
1.3 異構數據融合
不同系統的數據類型可能差別很多，這個案例中提到的來自 IoT 的是時序數據，來自 CMMS 的是文本記錄，而來自 ERP 的是結構化庫存數據。
真實數據改變而來的泵類設備維修記錄（知識庫）
而 MCP 工具在封裝 API 調用的同時，也可以進行初步的數據轉換和格式化，將不同系統返回的數據統一或整理成更適合 LLM 理解的格式。 這會降低在 Dify 主工作流中進行復雜數據清洗和轉換的負擔，使得數據能在 LLM 處理前得到更好的預處理。
2、Dify 中如何構建自定義 tool
2.1 厘清概念
相信很多盆友看到過很多介紹 MCP 概念時會提到的 MCP Client / Server / Host 的解釋，為了 避免大家有概念理解偏差，需要說明的是，在這個案例場景下：
MCP Client
發起工具調用的實體，也就是 Dify 工作流或 Agent。它通過 Dify 平臺提供的標準化接口（工具節點）來請求服務。
MCP Server / Host
提供實際服務的端點。在這個例子中，就是模擬 API 服務器 上的各個API (/api/pump/status, /api/cmms/pump/history 等)。這個服務器理解工具調用背后轉換成的 HTTP 請求并返回數據。
Dify 平臺
扮演著協議轉換器、編排器和代理的角色。它接收來自 Client (工作流節點) 的標準化工具調用請求，根據工具的 Schema 定義，將其轉換為具體的 HTTP 請求發送給 Server/Host (你的 API)，接收響應，再將其作為工具節點的輸出返回給工作流。
2.2 如何創建 tool
在 Dify 中，點擊"工作室”->"工具"->"創建自定義工具”。為每個工具輸入名稱(e.g.get_iot_status)。然后將編寫好的對應 JSON Schema 完整復制并粘貼到"Schema"輸入框中。
Dify 會自動解析Schema，并在下方"AvailableTools"部分顯示識別出的AP操作(Operation)。你應該能看到類似 getIotstatus，getcmsHistory等。
確認"Authorization method" 為"None"。點擊"保存"。然后對其他三個工具重復此過程。此外，建議進一步點擊“test"做下進一步的連通性驗證。
注：Dify 的做法是使用 OpenAPI Schema 來定義和管理自定義工具，而不是直接實現 Anthropic提出的特定 XML 交互格式，它們不直接等同，但目標一致，可以協同工作。
3、MCP 版 Agent
先設置好提示詞，確保在 "工具 (Tools)" 部分，已經啟用 getCmmsHistory, getMesOperation, getErpSpareParts 以及 getIotStatus 這四個工具。另外確保在 "知識庫 (Knowledge)" 部分已經正確綁定維修案例。
嘗試以下幾種對話來觀察 Agent 的行為：
注意，進行測試前需要先運行mock_api.py
3.1 簡單狀態查詢
"檢查一下 PUMP-CNC-001 的狀態怎么樣？"
預期行為: Agent 只調用 getIotStatus。如果狀態正常，它會報告正常并可能給出讀數，不會調用 CMMS, MES, ERP 或知識庫。
建議使用支持function call的LLM
3.2 觸發異常的查詢
"PUMP-CNC-001 好像有點問題，幫我看看。" (假設此時 getIotStatus 返回的數據是異常的，例如高振動 7.5，高溫度 75.8)
預期行為:
Agent 調用 getIotStatus，發現異常。
Agent 接著決定調用 getCmmsHistory 和 getMesOperation 獲取更多背景。
Agent 同時/隨后查詢知識庫 (使用類似 "PUMP-CNC-001 振動高 溫度高 原因案例" 的查詢)。
Agent 綜合信息，可能會根據知識庫中 PUMP-CNC-002 的案例，推斷是軸承問題，需要 CFP5K-BRG01。
此時，Agent 才決定調用 getErpSpareParts (傳入 partId=CFP5K-BRG01)。
最后，Agent 給出包含診斷、備件庫存信息和維修建議的完整答復。
3.3 直接問解決方案
"PUMP-LATHE-08 流量很低，怎么辦？"
預期行為: Agent 可能直接查詢知識庫，找到 PUMP-LATHE-08 的案例，然后告訴你可能是機械密封泄漏，需要更換密封件。它不一定需要調用 getIotStatus 或其他工具（除非它想確認當前狀態是否仍然是低流量）。
4、Chatflow 和 Agent 之爭
前文討論突出了 Agent（以及其背后利用的 MCP 思想）在處理需要動態規劃、多工具協作、復雜推理場景下的優勢。但這并不意味著固定編排的工作流 (Chatflow/Workflow) 就沒有用武之地了。
事實上，固定編排的 Dify 工作流在很多場景下更高效和可靠。當然，選擇哪種方式取決于你的具體需求、任務復雜度、以及你對流程控制的要求。以下是一些特別適合使用固定編排的 Dify Workflow/Chatflow 的情形:
4.1 流程確定且線性的任務
當一個任務的執行步驟是固定的，或者只有有限且明確的分支 (可以通過 IF/ELSE 節點處理) 時，工作流是最佳選擇。你不需要 LLM 去“思考”下一步該干什么，因為流程已經被精確定義好了。這對于需要保證合規性、安全性或特定業務邏輯的場景很重要。
反之，Agent 模式下，LLM 的自主決策可能引入不確定性（例如調用了非預期的工具，或者跳過了關鍵步驟）。
4.2 任務相對簡單，LLM 主要用于特定子任務
當 LLM 的作用只是流程中的一個“環節”（例如文本生成、摘要、翻譯、情感分析、簡單問答），而不是負責整個流程的規劃和決策時，工作流更簡單直接。
比如，客服意圖識別與初步回復的流程一般是: 接收用戶問題 -> 使用一個簡單的分類模型或 LLM 判斷用戶意圖 -> 根據意圖路由到不同的回復模板或知識庫查詢 -> 輸出初步解答。
4.3 對結果的穩定性和可預測性要求高
由于工作流的流程是固定的，對于相同的輸入（和外部 API 狀態），其執行路徑和最終結果通常是高度可預測和一致的。 Agent 的行為可能因為 LLM 的微小差異、Prompt 的理解偏差或上下文變化而產生波動。
例如，我前期做過的一些律所訴狀和信貸風控報告類的項目中， 需要生成格式完全一致的法律文件或風險要點分析。 其中涉及執行需要精確結果的計算或數據驗證任務，在工作流中 開發和調試也會相對簡單些。
Dify 的 Agent 模式特別適合利用 MCP工具， Agent會像人一樣，根據目標“規劃”需要使用哪些工具（訪問哪些系統），然后按順序或并行執行，最終整合結果。這的確也比純粹線性的工作流更靈活、更強大。
5、工作流+Agent 的珠聯璧合
回到這個預測性維護場景來說：如果是希望按照“檢查狀態 -> (IF 異常 THEN 查 CMMS -> 查 MES -> 查 KB -> 預測 -> 查 ERP -> 建議)”這個固定流程來執行，那么工作流方式是合適的。
但如果希望問答助手能更靈活，比如用戶問“PUMP-CNC-001 上次換軸承是什么時候？”，問答助手應該只調用 getCmmsHistory 就回答，而不是走完整個預測流程，那么 Agent 模式會更合適。
聽起來，這似乎是一個非此即彼的問題。但實際的生產場景中，可以通過在 Dify 中構建一個智能的“路由器”，根據用戶問題的性質將其導向最合適的處理單元（Agent 或 Chatflow）。
為了控制本文篇幅，這部分后續我在再專門寫篇文章進行介紹， 先貼一下核心架構感興趣的可以手搓下試試看。
5.1 用戶入口
創建一個新的Dify應用，模式設置為Chatflow，可以命名為"Pump_Assistant_Router"。
5.2 后端 Agent
上述創建好的 "Pump_Maintenance_MCP" Agent 應用，負責處理復雜的、需要動態規劃和工具調用的問題。
5.3 后端 Chatflow
創建一個或多個專門處理固定流程任務的 chatflow 應用。例如，Pump_Status_Check_chatflow: 接收 pumpId，調用 getIotStatus 工具，解析結果并直接回答狀態。 Pump_Maintenance_Report_chatflow: 一個接收 pumpId 和時間范圍，調用多個工具（如 getCmmsHistory, getMesOperation），并使用模板節點生成固定格式報告的 chatflow 等。
6、寫在最后
MCP (或其背后的標準化、工具化思想) 是打通信息孤島、充分利用 ERP、MES、CMMS、IoT 等多系統數據的關鍵。它通過標準化降低集成復雜度，通過智能調度提升上下文質量，通過數據融合簡化處理流程，最終賦能 Dify (尤其是 Agent) 更高效、更智能地完成復雜任務，如本文的預測性維護案例。
后續我會繼續分享些實操案例，進一步介紹MCP 工具不僅能獲取信息 (get_...)，更能被設計用來執行動作 (create_..., update_...)。這意味著基于 LLM 的分析和決策，可以直接觸發業務流程，例如自動創建預測性維護工單，或根據庫存情況建議訂購備件。AI 不再只是輔助，而是成為了業務自動化的引擎。
