上篇文章中，給大家分享了一個使用 Dify+RAGFlow 實現(xiàn)的泵類設(shè)備的預(yù)測性維護案例，過去兩天里有很多盆友在后臺私信我了一些實現(xiàn)細節(jié)，比如：HTTP 請求的數(shù)據(jù)存在哪里？ IoT 平臺的數(shù)據(jù)能否直接實時“流”入 Dify？以及如何使用 MCP 的方案實現(xiàn)四個數(shù)據(jù)源（IoT, CMMS, MES, ERP）的智能查詢。

Dify+RAGFlow：泵類設(shè)備預(yù)測維護系統(tǒng)案例分享

前兩問的回答昨 晚我已經(jīng)寫在了知識星球內(nèi)，感興趣的移步去翻下。這篇文章試圖說清楚：

如何使用 Dify 自定義工具實現(xiàn) MCP 的方法， 從而標準化 LLM 與多個數(shù)據(jù)源的交互方式。

以下，enjoy:

1、MCP 的統(tǒng)一之美

有關(guān) MCP 的基礎(chǔ)概念這里不做贅述，如果有不清楚的盆友可以翻下我之前的一篇文章快速掃盲后再往下看。

都說 MCP 在連接和利用來自多個異構(gòu)系統(tǒng)的數(shù)據(jù)方面，扮演著所謂標準化粘合劑和智能調(diào)度員的角色，那 MCP 到底好在哪里，按照公開的說法和個人實踐體驗，按如下三點進行介紹：

1.1 標準化接口層

每個系統(tǒng)（ERP、MES 等）都有自己獨特的 API 接口、數(shù)據(jù)格式和認證方式。在 Dify 中直接調(diào)用意味著需要為每個系統(tǒng)配置和維護不同的 HTTP Request 節(jié)點，邏輯復(fù)雜且脆弱。

上篇文章中介紹的工作流，圈出的是4個http請求節(jié)點    

通過創(chuàng)建 Dify 工具 (Tool)，每個工具都封裝與對應(yīng)系統(tǒng) API 交互的細節(jié)（URL、參數(shù)、認證、數(shù)據(jù)解析）。這樣 Dify 的 Agent 或工作流不再需要關(guān)心底層 API 的復(fù)雜性，只需要知道調(diào)用一個名為 get_erp_stock 或 get_latest_iot_reading 的工具即可。這會極大地簡化了工作流的編排，提高了可維護性和可重用性。 

使用Dify的自定義工具替換了原有工作流中的四個http請求節(jié)點

1.2 上下文智能聚合

其次，LLM 的能力很大程度上取決于提供給它的上下文的質(zhì)量。簡單地將來自不同系統(tǒng)的原始數(shù)據(jù)堆砌給 LLM 可能效果不佳。 

上述提到的 MCP 理念構(gòu)建的工具可以被 Dify Agent 智能地選擇和調(diào)用。例如，當用戶問：“PUMP-CNC-001 狀況如何？需要訂購備件嗎？” Agent 可以識別出需要調(diào)用 get_latest_iot_reading 工具獲取實時狀態(tài)。 根據(jù) IoT 狀態(tài)（比如振動高），Agent 可能進一步判斷需要調(diào)用 get_cmms_history 工具查看類似故障記錄。 同時，調(diào)用 predict_failure 工具。 如果預(yù)測需要更換軸承，Agent 會調(diào)用 get_erp_stock 工具查詢 CFP5K-BRG01 的庫存。 

MCP 的方法可以讓 Agent 能夠根據(jù)任務(wù)需求，動態(tài)地、按需地從多個系統(tǒng)中拉取最相關(guān)的信息，并將這些信息結(jié)構(gòu)化地整合為高質(zhì)量的上下文，再提供給 LLM 進行分析、預(yù)測或生成報告，而不是一次性將所有可能的數(shù)據(jù)都查詢出來。 

此處需要說明的是，上下文智能整合的作用更多的體現(xiàn)在Agent中，下文會進一步說明。

1.3 異構(gòu)數(shù)據(jù)融合

不同系統(tǒng)的數(shù)據(jù)類型可能差別很多，這個案例中提到的來自 IoT 的是時序數(shù)據(jù)，來自 CMMS 的是文本記錄，而來自 ERP 的是結(jié)構(gòu)化庫存數(shù)據(jù)。 

真實數(shù)據(jù)改變而來的泵類設(shè)備維修記錄（知識庫）

而 MCP 工具在封裝 API 調(diào)用的同時，也可以進行初步的數(shù)據(jù)轉(zhuǎn)換和格式化，將不同系統(tǒng)返回的數(shù)據(jù)統(tǒng)一或整理成更適合 LLM 理解的格式。 這會降低在 Dify 主工作流中進行復(fù)雜數(shù)據(jù)清洗和轉(zhuǎn)換的負擔，使得數(shù)據(jù)能在 LLM 處理前得到更好的預(yù)處理。 

2、Dify 中如何構(gòu)建自定義 tool

2.1 厘清概念

相信很多盆友看到過很多介紹 MCP 概念時會提到的 MCP Client / Server / Host 的解釋，為了 避免大家有概念理解偏差，需要說明的是，在這個案例場景下： 

MCP Client

發(fā)起工具調(diào)用的實體，也就是 Dify 工作流或 Agent。它通過 Dify 平臺提供的標準化接口（工具節(jié)點）來請求服務(wù)。 

MCP Server / Host

提供實際服務(wù)的端點。在這個例子中，就是模擬 API 服務(wù)器 上的各個API (/api/pump/status, /api/cmms/pump/history 等)。這個服務(wù)器理解工具調(diào)用背后轉(zhuǎn)換成的 HTTP 請求并返回數(shù)據(jù)。 

Dify 平臺

扮演著協(xié)議轉(zhuǎn)換器、編排器和代理的角色。它接收來自 Client (工作流節(jié)點) 的標準化工具調(diào)用請求，根據(jù)工具的 Schema 定義，將其轉(zhuǎn)換為具體的 HTTP 請求發(fā)送給 Server/Host (你的 API)，接收響應(yīng)，再將其作為工具節(jié)點的輸出返回給工作流。

2.2 如何創(chuàng)建 tool

在 Dify 中，點擊"工作室”->"工具"->"創(chuàng)建自定義工具”。為每個工具輸入名稱(e.g.get_iot_status)。然后將編寫好的對應(yīng) JSON Schema 完整復(fù)制并粘貼到"Schema"輸入框中。

Dify 會自動解析Schema，并在下方"AvailableTools"部分顯示識別出的AP操作(Operation)。你應(yīng)該能看到類似 getIotstatus，getcmsHistory等。

確認"Authorization method" 為"None"。點擊"保存"。然后對其他三個工具重復(fù)此過程。此外，建議進一步點擊“test"做下進一步的連通性驗證。

注：Dify 的做法是使用 OpenAPI Schema 來定義和管理自定義工具，而不是直接實現(xiàn) Anthropic提出的特定 XML 交互格式，它們不直接等同，但目標一致，可以協(xié)同工作。

3、MCP 版 Agent

先設(shè)置好提示詞，確保在 "工具 (Tools)" 部分，已經(jīng)啟用 getCmmsHistory, getMesOperation, getErpSpareParts 以及 getIotStatus 這四個工具。另外確保在 "知識庫 (Knowledge)" 部分已經(jīng)正確綁定維修案例。 

嘗試以下幾種對話來觀察 Agent 的行為： 

注意，進行測試前需要先運行mock_api.py

3.1 簡單狀態(tài)查詢

"檢查一下 PUMP-CNC-001 的狀態(tài)怎么樣？" 

預(yù)期行為: Agent 只調(diào)用 getIotStatus。如果狀態(tài)正常，它會報告正常并可能給出讀數(shù)，不會調(diào)用 CMMS, MES, ERP 或知識庫。 

建議使用支持function call的LLM

3.2 觸發(fā)異常的查詢

"PUMP-CNC-001 好像有點問題，幫我看看。" (假設(shè)此時 getIotStatus 返回的數(shù)據(jù)是異常的，例如高振動 7.5，高溫度 75.8) 

預(yù)期行為: 

Agent 調(diào)用 getIotStatus，發(fā)現(xiàn)異常。 

Agent 接著決定調(diào)用 getCmmsHistory 和 getMesOperation 獲取更多背景。

Agent 同時/隨后查詢知識庫 (使用類似 "PUMP-CNC-001 振動高 溫度高 原因案例" 的查詢)。

Agent 綜合信息，可能會根據(jù)知識庫中 PUMP-CNC-002 的案例，推斷是軸承問題，需要 CFP5K-BRG01。

此時，Agent 才決定調(diào)用 getErpSpareParts (傳入 partId=CFP5K-BRG01)。 

最后，Agent 給出包含診斷、備件庫存信息和維修建議的完整答復(fù)。 

3.3 直接問解決方案

"PUMP-LATHE-08 流量很低，怎么辦？" 

預(yù)期行為: Agent 可能直接查詢知識庫，找到 PUMP-LATHE-08 的案例，然后告訴你可能是機械密封泄漏，需要更換密封件。它不一定需要調(diào)用 getIotStatus 或其他工具（除非它想確認當前狀態(tài)是否仍然是低流量）。

4、Chatflow 和 Agent 之爭

前文討論突出了 Agent（以及其背后利用的 MCP 思想）在處理需要動態(tài)規(guī)劃、多工具協(xié)作、復(fù)雜推理場景下的優(yōu)勢。但這并不意味著固定編排的工作流 (Chatflow/Workflow) 就沒有用武之地了。 

事實上，固定編排的 Dify 工作流在很多場景下更高效和可靠。當然，選擇哪種方式取決于你的具體需求、任務(wù)復(fù)雜度、以及你對流程控制的要求。以下是一些特別適合使用固定編排的 Dify Workflow/Chatflow 的情形:

4.1 流程確定且線性的任務(wù)

當一個任務(wù)的執(zhí)行步驟是固定的，或者只有有限且明確的分支 (可以通過 IF/ELSE 節(jié)點處理) 時，工作流是最佳選擇。你不需要 LLM 去“思考”下一步該干什么，因為流程已經(jīng)被精確定義好了。這對于需要保證合規(guī)性、安全性或特定業(yè)務(wù)邏輯的場景很重要。 

反之，Agent 模式下，LLM 的自主決策可能引入不確定性（例如調(diào)用了非預(yù)期的工具，或者跳過了關(guān)鍵步驟）。 

4.2 任務(wù)相對簡單，LLM 主要用于特定子任務(wù)

當 LLM 的作用只是流程中的一個“環(huán)節(jié)”（例如文本生成、摘要、翻譯、情感分析、簡單問答），而不是負責整個流程的規(guī)劃和決策時，工作流更簡單直接。 

比如，客服意圖識別與初步回復(fù)的流程一般是: 接收用戶問題 -> 使用一個簡單的分類模型或 LLM 判斷用戶意圖 -> 根據(jù)意圖路由到不同的回復(fù)模板或知識庫查詢 -> 輸出初步解答。 

4.3 對結(jié)果的穩(wěn)定性和可預(yù)測性要求高

由于工作流的流程是固定的，對于相同的輸入（和外部 API 狀態(tài)），其執(zhí)行路徑和最終結(jié)果通常是高度可預(yù)測和一致的。 Agent 的行為可能因為 LLM 的微小差異、Prompt 的理解偏差或上下文變化而產(chǎn)生波動。 

例如，我前期做過的一些律所訴狀和信貸風控報告類的項目中， 需要生成格式完全一致的法律文件或風險要點分析。 其中涉及執(zhí)行需要精確結(jié)果的計算或數(shù)據(jù)驗證任務(wù)，在工作流中 開發(fā)和調(diào)試也會相對簡單些。

Dify 的 Agent 模式特別適合利用 MCP工具， Agent會像人一樣，根據(jù)目標“規(guī)劃”需要使用哪些工具（訪問哪些系統(tǒng)），然后按順序或并行執(zhí)行，最終整合結(jié)果。這的確也比純粹線性的工作流更靈活、更強大。 

5、工作流+Agent 的珠聯(lián)璧合

回到這個預(yù)測性維護場景來說：如果是希望按照“檢查狀態(tài) -> (IF 異常 THEN 查 CMMS -> 查 MES -> 查 KB -> 預(yù)測 -> 查 ERP -> 建議)”這個固定流程來執(zhí)行，那么工作流方式是合適的。  

但如果希望問答助手能更靈活，比如用戶問“PUMP-CNC-001 上次換軸承是什么時候？”，問答助手應(yīng)該只調(diào)用 getCmmsHistory 就回答，而不是走完整個預(yù)測流程，那么 Agent 模式會更合適。

聽起來，這似乎是一個非此即彼的問題。但實際的生產(chǎn)場景中，可以通過在 Dify 中構(gòu)建一個智能的“路由器”，根據(jù)用戶問題的性質(zhì)將其導(dǎo)向最合適的處理單元（Agent 或 Chatflow）。

為了控制本文篇幅，這部分后續(xù)我在再專門寫篇文章進行介紹， 先貼一下核心架構(gòu)感興趣的可以手搓下試試看。

5.1 用戶入口

創(chuàng)建一個新的Dify應(yīng)用，模式設(shè)置為Chatflow，可以命名為"Pump_Assistant_Router"。 

5.2 后端 Agent

上述創(chuàng)建好的 "Pump_Maintenance_MCP" Agent 應(yīng)用，負責處理復(fù)雜的、需要動態(tài)規(guī)劃和工具調(diào)用的問題。 

5.3 后端 Chatflow

創(chuàng)建一個或多個專門處理固定流程任務(wù)的 chatflow 應(yīng)用。例如，Pump_Status_Check_chatflow: 接收 pumpId，調(diào)用 getIotStatus 工具，解析結(jié)果并直接回答狀態(tài)。 Pump_Maintenance_Report_chatflow: 一個接收 pumpId 和時間范圍，調(diào)用多個工具（如 getCmmsHistory, getMesOperation），并使用模板節(jié)點生成固定格式報告的 chatflow 等。

6、寫在最后

MCP (或其背后的標準化、工具化思想) 是打通信息孤島、充分利用 ERP、MES、CMMS、IoT 等多系統(tǒng)數(shù)據(jù)的關(guān)鍵。它通過標準化降低集成復(fù)雜度，通過智能調(diào)度提升上下文質(zhì)量，通過數(shù)據(jù)融合簡化處理流程，最終賦能 Dify (尤其是 Agent) 更高效、更智能地完成復(fù)雜任務(wù)，如本文的預(yù)測性維護案例。

后續(xù)我會繼續(xù)分享些實操案例，進一步介紹MCP 工具不僅能獲取信息 (get_...)，更能被設(shè)計用來執(zhí)行動作 (create_..., update_...)。這意味著基于 LLM 的分析和決策，可以直接觸發(fā)業(yè)務(wù)流程，例如自動創(chuàng)建預(yù)測性維護工單，或根據(jù)庫存情況建議訂購備件。AI 不再只是輔助，而是成為了業(yè)務(wù)自動化的引擎。