萬字長文：說清MCP的前世今生+RAGFlow整合應用示例
上篇文章給大家預告了我在研究些 RAG+MCP（大模型上下文協(xié)議）的事，前后斷斷續(xù)續(xù)寫了四天，終于完成了這篇稿子，這篇試圖說清楚兩個事情：
1、從復雜提示詞引導模型調(diào)用工具開始，到 MCP 作為統(tǒng)一協(xié)議標準的變化過程；
2、小試牛刀的演示下在傳統(tǒng) RAG 基礎上，針對機械加工場景結合 MCP 的一些功能延展示例。
以下，enjoy:
1、先說說大模型 API 調(diào)用
先簡單回顧下最簡單的大模型基礎聊天應用開發(fā)，也就是直接按照目標 LLM 的官方 API 文檔進行請求的做法。例如，如果我們要通過 Python 調(diào)用 DeepSeek-R1 模型進行問答，按照官方文檔說明示例如下：
from openai import OpenAI
client = OpenAI(api_key="<DeepSeek API Key>", base_url="https://api.deepseek.com")
response = client.chat.completions.create(
model="deepseek-chat",
messages=[
{"role": "system", "content": "You are a helpful assistant"},
{"role": "user", "content": "Hello"},
],
stream=False
)
print(response.choices[0].message.content)
因為大多數(shù)模型廠商都是兼容 OpenAI 規(guī)范的，也就是說在使用 OpenAI SDK 請求方式下，直接替換上述的 base_url 換成其他模型地址，都是可以實現(xiàn)請求響應的。比如如果要請求Qwen 系列模型，那base_url 就替換成： https://dashscope.aliyuncs.com/compatible-mode/v1 。進一步說，如果要想實現(xiàn)多輪對話，讓大模型“擁有記憶”滿足追問，以阿里的 QWQ 模型為例，可以把content字段通過{'role': 'assistant', 'content':拼接后的流式輸出 content}添加到上下文。（注：無需添加reasoning_content字段）
2、復雜提示詞工程的緣起
上面提到的聊天應用，只是基于 LLM 的已有知識，回答效果在有些場景下不符合預期。畢竟，LLM 在訓練完成的那一刻，它所掌握的知識就凍結了。這顯然是回答不了具有時效性或者準確來說是超出 LLM 訓練截止完成以前時間的問題，當然還包括私有化的信息等。
簡而言之，通過引入外部工具，可以讓 LLM 和外部世界進行交互。OpenAI 在 23年6月正式推出了 Function Calling 功能，最初在 GPT-3.5和 GPT-4 模型上實現(xiàn)。不過，在正式介紹這個 Fucntion Calling 功能之前，先來聊下在此之前通過復雜提示詞引導模型調(diào)用工具的嘗試。
以 get_current_weather 和 get_current_weather 兩個 tool 為例，下文進行相關實現(xiàn)方式的對比說明。
# 系統(tǒng)提示詞設計
SYSTEM_PROMPT = """
你是一個智能助手，具有以下工具：
1. 時間工具 (TIME)
- 格式：TIME: 獲取當前時間
- 功能：返回當前的完整日期和時間
2. 天氣工具 (WEATHER)
- 格式：WEATHER: 城市名稱
- 功能：獲取指定城市的當前天氣情況
3. 計算工具 (CALCULATE)
- 格式：CALCULATE: 數(shù)學表達式
- 功能：執(zhí)行數(shù)學計算
重要規(guī)則：
- 必須嚴格遵循上述格式
- 只有在確實需要使用工具時才使用
- 工具調(diào)用應該是輸出的唯一內(nèi)容
- 使用工具后，還需要對結果進行自然語言解釋
示例：
用戶: 北京今天幾點了？
助手: TIME: 獲取當前時間
用戶: 我想知道北京的天氣
助手: WEATHER: 北京
用戶: 幫我計算15乘以23
助手: CALCULATE: 15 * 23
"""
# 模擬工具實現(xiàn)
def mock_tool_execution(tool_call):
import datetime
if tool_call.startswith("TIME:"):
return datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
elif tool_call.startswith("WEATHER:"):
city = tool_call.split("WEATHER:")[1].strip()
# 模擬天氣API
return f"{city}：晴，溫度22°C，濕度45%"
elif tool_call.startswith("CALCULATE:"):
expression = tool_call.split("CALCULATE:")[1].strip()
try:
return str(eval(expression))
except Exception as e:
return f"計算錯誤：{str(e)}"
return "未識別的工具調(diào)用"
# 對話交互模擬
def chat_interaction():
print("智能助手已啟動。輸入'退出'結束對話。")
while True:
user_input = input("用戶: ")
if user_input == '退出':
break
# 模擬模型處理
# 實際場景中這里會是大語言模型的處理
tool_match = None
# 簡單的規(guī)則匹配
if "時間" in user_input:
tool_match = "TIME: 獲取當前時間"
elif "天氣" in user_input:
city_match = user_input.replace("天氣", "").strip()
tool_match = f"WEATHER: {city_match}" if city_match else None
elif "計算" in user_input or "*" in user_input or "+" in user_input:
# 嘗試提取計算表達式
import re
match = re.search(r'(\d+\s*[\+\-\*\/]\s*\d+)', user_input)
if match:
tool_match = f"CALCULATE: {match.group(1)}"
if tool_match:
print("助手:", tool_match)
result = mock_tool_execution(tool_match)
print(f"工具執(zhí)行結果: {result}")
else:
print("助手: 很抱歉，我沒有找到合適的工具來處理您的請求。")
# 運行交互
if __name__ == "__main__":
chat_interaction()示例運行展示效果如下：
智能助手已啟動。輸入'退出'結束對話。
用戶: 現(xiàn)在幾點了
助手: TIME: 獲取當前時間
工具執(zhí)行結果: 2024-03-18 16:45:30
用戶: 北京天氣怎么樣
助手: WEATHER: 北京
工具執(zhí)行結果: 北京：晴，溫度22°C，濕度45%
用戶: 計算15乘以23
助手: CALCULATE: 15 * 23
工具執(zhí)行結果: 345
用戶: 退出總結來說，這種復雜提示詞的做法，主要包括以下四個特征：
- 在系統(tǒng)提示中詳細說明輸出格式
- 使用特定的分隔符和標記（如 XML 標簽）
- 通過正則表達式解析模型輸出提取"函數(shù)調(diào)用"
- 在對話歷史中包含工具使用示例
這種做法的局限性首先就是表現(xiàn)為格式不可靠，大模型可能不一致地遵循指令。畢竟 Transformer 的底層邏輯還是 Next token prediction。其次，對于復雜參數(shù)結構就更加不靠譜。當然還有例如參數(shù)驗證困難、占用大量提示詞空間等問題，就不一一贅述了。
不過，需要給這種做法正名的是，對于簡單場景，可以考慮使用此類提示詞方法，實現(xiàn)成本低，也不依賴特定模型能力，但同時需要始終警惕模型輸出的不確定性。
3、Function Calling 初露鋒芒
上述提到的通過提示詞來引導模型調(diào)用工具的嘗試，OpenAI 將其標準化并作為 API 的一部分提供，也就有了現(xiàn)在大家所說的 Function Calling。
3.1創(chuàng)新之處
相比于提示詞引導模型調(diào)用工具的方法，主要創(chuàng)新之處體現(xiàn)在以下幾點：
結構化輸出：
確保模型能以預定義的 JSON 格式輸出函數(shù)調(diào)用參數(shù)，提高了可解析性和可靠性
函數(shù)定義明確：
通過函數(shù)模式（schema）清晰定義名稱、描述、參數(shù)類型等
降低解析復雜度：
開發(fā)者不需要編寫復雜的文本解析邏輯
提高準確性：
減少了模型在生成函數(shù)調(diào)用時的"幻覺"問題
簡化開發(fā)流程：
標準化了大模型與外部工具的交互方式
BTW，并不是所有的 LLM 都支持 Function Calling，因為模型要支持 Function Calling 通常需要專門的訓練或微調(diào)。具體來說，需要在預訓練或者微調(diào)階段引入函數(shù)調(diào)用的示例，訓練模型理解函數(shù)模式（schema），學習如何生成符合預期格式的 json 輸出，以及理解參數(shù)類型和約束條件等。
3.2實現(xiàn)機制
那大模型的工具選擇和調(diào)用具體關鍵機制是什么樣的呢，這里提供一個 Qwen 模型的簡單示例，具體實現(xiàn)上大致分為兩步：
1、意圖推理與工具匹配
- 大模型會基于用戶輸入，對可用工具的描述和參數(shù)進行語義理解
- 模型會通過自然語言理解和推理，判斷是否需要調(diào)用工具，以及調(diào)用哪個具體的工具
這個過程是自動的，不需要開發(fā)者手動硬編碼每一個判斷邏輯
2、智能參數(shù)填充
- 模型能夠從對話上下文中提取必要的參數(shù)信息
- 對于需要特定參數(shù)的函數(shù)，模型可以智能地填充這些參數(shù)值
import os
from openai import OpenAI
# 初始化OpenAI客戶端，配置阿里云DashScope服務
client = OpenAI(
# 若沒有配置環(huán)境變量，請用百煉API Key將下行替換為：api_key="sk-xxx",
api_key=os.getenv("DASHSCOPE_API_KEY"), # 從環(huán)境變量讀取API密鑰
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)
# 定義可用工具列表
tools = [
# 工具1 獲取當前時刻的時間
{
"type": "function",
"function": {
"name": "get_current_time",
"description": "當你想知道現(xiàn)在的時間時非常有用。",
"parameters": {} # 無需參數(shù)
}
},
# 工具2 獲取指定城市的天氣
{
"type": "function",
"function": {
"name": "get_current_weather",
"description": "當你想查詢指定城市的天氣時非常有用。",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "城市或縣區(qū)，比如北京市、杭州市、余杭區(qū)等。"
}
},
"required": ["location"] # 必填參數(shù)
}
}
}
]
# 節(jié)省篇幅，此處省略后續(xù)代碼例如，如果用戶問：
"現(xiàn)在幾點了？" → 模型可能調(diào)用 get_current_time"
北京今天天氣怎么樣？" → 模型可能調(diào)用 get_current_weather，并自動填充 locatinotallow="北京"
總結來說，關鍵實現(xiàn)包括：
- 工具描述（description）提供語義線索
- 參數(shù)定義（parameters）指導參數(shù)填充
- 模型的上下文理解和推理能力
盡管看起來很強大，但 Function Calling 會比較依賴模型的理解能力，而且工具描述的質(zhì)量直接影響調(diào)用準確性，所以也存在誤解或錯誤調(diào)用的可能性。
3.3Function Calling vs 傳統(tǒng)硬編碼
看到這里，可能會有盆友會疑惑 Function Calling 和傳統(tǒng)手動函數(shù)調(diào)用外部工具實現(xiàn)邏輯的差別是啥。同樣參照上述提到的兩個 tool，附上一個傳統(tǒng)硬編碼的做法示例：
import datetime
import requests
def get_current_time():
"""manually retrieve current time"""
return datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
def get_current_weather(location):
"""manually fetch weather for a specific location"""
# 模擬天氣API調(diào)用
try:
# 假設這里是一個真實的天氣API調(diào)用
# 實際場景中，你需要替換為真實的API端點和處理邏輯
response = requests.get(f"https://weather-api.example.com/current?city={location}")
weather_data = response.json()
return f"{location}的當前天氣：{weather_data['temperature']}°C，{weather_data['condition']}"
except Exception as e:
return f"獲取{location}天氣失敗：{str(e)}"
def process_user_query(query):
"""手動線性觸發(fā)函數(shù)"""
# 使用硬編碼的條件判斷
if "時間" in query:
return get_current_time()
elif "天氣" in query:
# 需要額外的參數(shù)提取邏輯
import re
location_match = re.search(r'([\u4e00-\u9fff]+)天氣', query)
if location_match:
location = location_match.group(1)
return get_current_weather(location)
else:
return "請?zhí)峁┚唧w城市名稱"
else:
return "無法理解您的請求"
# 模擬用戶交互
def main():
while True:
user_input = input("請輸入您的問題（輸入'退出'結束）：")
if user_input == '退出':
break
response = process_user_query(user_input)
print("系統(tǒng)回復：", response)
if __name__ == "__main__":
main()示例運行結果：
# 可能的交互示例
請輸入您的問題（輸入'退出'結束）：現(xiàn)在幾點了
系統(tǒng)回復：2024-03-18 15:30:45
請輸入您的問題（輸入'退出'結束）：北京天氣怎么樣
系統(tǒng)回復：北京的當前天氣：15°C，晴朗
請輸入您的問題（輸入'退出'結束）：退出這個示例清晰地展示了傳統(tǒng)手動觸發(fā)方法的局限性：代碼邏輯復雜、擴展性差、對用戶輸入的理解能力有限。相比之下，F(xiàn)unction Calling 提供了一種更智能、更靈活的工具調(diào)用范式。
4、GPTs 的試圖”大一統(tǒng)“
在正式說到 MCP 之前，還需要再聊下 GPTs 的故事。上述提到的 Function Calling 固然有很多好處，但是全部自己手動寫似乎有點太麻煩，于是大聰明 OpenAI 就在 23 年 11 月初的開發(fā)者大會上，首次介紹了 GPTs 的概念，用戶不需要任何編程知識，只需要通過自然語言指令和上傳知識庫，就能夠輕松的定制自己的個性化 GPT。p.s.此舉還有個實際效果是讓全球開發(fā)者主動的為 ChatGPT 開發(fā) Funtion Calling 工具。
此處忽略后來的狗血宮斗插曲，GPT Store 在 24 年 1 月對外正式發(fā)布，我查到的數(shù)據(jù)是，截止到 24 年1月份，用戶自主創(chuàng)建的 GPTs 據(jù)說就超過了 300 萬個。
想起我 23 年 11 月 11 號發(fā)布第一個自己的 GPTs 的時候，當時看到 GPTs 導航站的統(tǒng)計有 4000+個，當時感慨發(fā)布一周就這么快上新，不曾想后來會如此井噴。
下面展示一個獲取當前時間的 GPTs 示例，并解釋其工作機制。
# 1. manifest.json
{
"schema_version": "v1",
"name_for_human": "Time Assistant",
"name_for_model": "time_tool_gpt",
"description_for_human": "A GPT that can retrieve current time information across different time zones.",
"description_for_model": "You are a helpful time assistant capable of retrieving current time information precisely and efficiently.",
"auth": {
"type": "none"
},
"api": {
"type": "openapi",
"url": "https://your-domain.com/openapi.yaml"
},
"logo_url": "https://example.com/time-assistant-logo.png",
"contact_email": "support@example.com",
"privacy_policy_url": "https://example.com/privacy"
}
# 2. openapi.yaml
openapi: 3.0.0
info:
title: Time Assistant API
version: 1.0.0
description: API for retrieving current time information
servers:
- url: https://your-domain.com/api/v1
paths:
/current-time:
get:
summary: Get current time
operationId: getCurrentTime
parameters:
- name: timezone
in: query
required: false
schema:
type: string
default: "UTC"
description: Timezone to retrieve current time (e.g., 'UTC', 'America/New_York', 'Asia/Shanghai')
responses:
'200':
description: Successful time retrieval
content:
application/json:
schema:
type: object
properties:
current_time:
type: string
example: "2024-03-18T15:30:45Z"
timezone:
type: string
example: "UTC"
timestamp:
type: integer
example: 17107704454.1核心文件解析
1、manifest.json
定義 GPT 的基本元數(shù)據(jù)
指定 API 交互方式
提供人類和模型可讀的描述
配置身份驗證和 API 接入點
2、 openapi.yaml
定義具體的 API 接口規(guī)范
描述可用的端點、參數(shù)和響應結構
提供工具調(diào)用的接口約定
4.2使用場景示例
"現(xiàn)在幾點了？"、"北京現(xiàn)在是什么時間？"、"告訴我紐約當前時間"
GPT 會根據(jù)這些問題：
識別時間查詢意圖
選擇/current-time接口
傳入相應的 timezone 參數(shù)
4.3局限性
GPTs 完全綁定 OpenAI 生態(tài)系統(tǒng)，不兼容其他大模型平臺（Anthropic、Google 等），無法跨平臺移植和使用。在功能實現(xiàn)方面，工具調(diào)用方式高度標準化，缺乏靈活的參數(shù)傳遞機制，不支持復雜的狀態(tài)管理，也無法實現(xiàn)復雜的工作流編排。另外從托管方式上看，完全依賴 OpenAI 云平臺，不支持私有化部署，無法進行深度定制和二次開發(fā)等。
總結來說，GPTs 本質(zhì)上是一個封閉、受限的生態(tài)系統(tǒng)，適合快速構建簡單的交互工具，但對于需要高度定制和靈活性的場景，其局限性非常明顯。對于追求技術自主可控的企業(yè)和開發(fā)者，GPTs 并不是一個好的選擇。
5、MCP 推出的偶然和必然
模型上下文協(xié)議 (MCP) 24 年 11 月由 Anthropic 發(fā)布，總結來說就是兩個要點，首先是一個協(xié)議兼容所有的 AI 應用，另外在 Function Calling 基礎上增加了資源和提示詞的功能。
5.1工具調(diào)用示例
先看下 MCP 實現(xiàn)工具調(diào)用示例, 這里以 get_current_time 的工具為例：
用戶提問：現(xiàn)在幾點了？
MCP 執(zhí)行流程：
1、請求階段：
{
"messages": [
{"role": "user", "content": "現(xiàn)在幾點了？"}
],
"context": {
"tools": [
{
"type": "function",
"function": {
"name": "get_current_time",
"description": "當你想知道現(xiàn)在的時間時非常有用。",
"parameters": {}
}
},
{...} // 另一個工具定義
]
}
}2、模型響應階段
{
"response": {
"model": "DeepSeek-R1:32b",
"content": [
{
"type": "tool_use",
"id": "call_1",
"tool_use": {
"name": "get_current_time",
"parameters": {}
}
}
]
}
}3、工具執(zhí)行階段：系統(tǒng)執(zhí)行get_current_time函數(shù)，返回結果
{
"messages": [
{"role": "user", "content": "現(xiàn)在幾點了？"},
{
"role": "assistant",
"content": [
{
"type": "tool_use",
"id": "call_1",
"tool_use": {
"name": "get_current_time",
"parameters": {}
}
}
]
},
{
"role": "tool",
"tool_use_id": "call_1",
"content": {"time": "2025-03-18T14:30:00Z"}
}
]
}4、最終響應
{
"response": {
"model": "DeepSeek-R1:32b",
"content": [
{
"type": "text",
"text": "現(xiàn)在的時間是北京時間2025年3月18日22:30（世界協(xié)調(diào)時間14:30）。"
}
]
}
}5.2執(zhí)行步驟拆解
用戶查詢解析：
模型分析用戶問題，確定需要調(diào)用哪個工具
對于需要參數(shù)的工具，提取必要參數(shù)（如城市名稱）
工具調(diào)用請求生成：
模型生成標準化的工具調(diào)用請求，包含工具名稱和參數(shù)
每個工具調(diào)用都有唯一 ID，方便后續(xù)追蹤
工具執(zhí)行：
系統(tǒng)接收工具調(diào)用請求
執(zhí)行相應函數(shù)并獲取結果
將結果以標準格式返回，關聯(lián)到對應的工具調(diào)用 ID結果整合與回復生成：
模型接收工具調(diào)用結果
將結果整合到上下文中
生成自然語言回復給用戶
5.3MCP 資源訪問控制
MCP 的資源訪問控制功能可以精確定義大模型如何安全地訪問企業(yè)內(nèi)部資源。以機械加工企業(yè)部署 RAG 系統(tǒng)訪問 MySQL 數(shù)據(jù)庫為例做個效果演示：
{
"messages": [
{"role": "user", "content": "查詢公司圓鋼硬度標準"}
],
"context": {
"resources": [
{
"type": "database",
"id": "materials_db",
"config": {
"engine": "mysql",
"connection": {
"host": "192.168.1.100",
"database": "materials_specs",
"schema": "standards"
},
"permissions": ["read"],
"tables": ["material_standards", "quality_tests"],
"access_level": "restricted"
}
}
],
"tools": [
{
"type": "function",
"function": {
"name": "query_database",
"description": "查詢企業(yè)材料標準數(shù)據(jù)庫",
"parameters": {
"type": "object",
"properties": {
"resource_id": {"type": "string"},
"query_type": {"type": "string", "enum": ["standard", "test", "material"]},
"material_category": {"type": "string"},
"standard_type": {"type": "string"}
},
"required": ["resource_id", "query_type"]
}
}
}
]
}
}執(zhí)行過程
權限驗證層：系統(tǒng)首先驗證當前用戶對材料數(shù)據(jù)庫的訪問權限
資源邊界定義：MCP 限制只能訪問特定表（材料標準和質(zhì)量測試）
查詢限制：只允許讀取操作，禁止寫入或修改
數(shù)據(jù)篩選：可設置只返回非機密等級的標準數(shù)據(jù)
5.4實際應用優(yōu)勢
數(shù)據(jù)隔離：確保 LLM 只能訪問授權表，無法看到客戶數(shù)據(jù)、財務信息等敏感數(shù)據(jù)
審計追蹤：記錄所有數(shù)據(jù)庫查詢，便于合規(guī)審計
精細控制：可針對不同部門用戶設置不同的數(shù)據(jù)訪問范圍
防止 SQL 注入：MCP 可以驗證和清理查詢請求，增強安全性
5.5提示詞增強功能
MCP 的提示詞增強功能可以為 LLM 提供額外上下文和專業(yè)指導，使其更好地處理專業(yè)領域問題，此處同樣以機械加工企業(yè)為例：
{
"messages": [
{"role": "user", "content": "CNC加工中心出現(xiàn)S-02錯誤代碼，如何排查？"}
],
"context": {
"prompts": [
{
"id": "mechanical_expertise",
"content": "你是一名專業(yè)的機械加工技術顧問，熟悉CNC設備操作和故障排除?？偸莾?yōu)先考慮安全因素，并遵循ISO 9001質(zhì)量標準流程。在回答前，先確認錯誤的嚴重程度，然后按照'初步檢查→可能原因→解決步驟→預防措施'的順序組織回答。"
},
{
"id": "company_terminology",
"content": "使用公司標準術語：'加工中心'指HAAS VF-2SS設備，'S系列錯誤'表示主軸系統(tǒng)故障，'技術處理單'指企業(yè)內(nèi)部ERP系統(tǒng)中的故障報告表單。參考設備代號時使用'HC-'前綴。"
},
{
"id": "safety_guidelines",
"content": "任何設備維修建議必須包含以下安全提醒：'維修前確保設備完全斷電并上鎖掛牌，穿戴適當?shù)腜PE裝備，遵循公司MP-S-001安全手冊規(guī)定的維修流程。'"
}
],
"resources": [
{
"type": "vector_database",
"id": "equipment_manual_db",
"config": {
"collection": "equipment_manuals",
"filters": {"equipment_type": "CNC"}
}
}
]
}
}5.6應用場景與優(yōu)勢
專業(yè)術語統(tǒng)一
系統(tǒng)能理解并使用企業(yè)內(nèi)部特定術語（如"HC-1500"指特定型號的加工中心）
確?；卮鸱掀髽I(yè)標準規(guī)范和命名習慣
流程標準化
強制模型按照企業(yè)工藝流程標準回答問題
例如：CNC 故障診斷必須先檢查安全狀態(tài)，再進行電氣和機械系統(tǒng)排查
知識融合
結合行業(yè)通用知識與企業(yè)特定知識例如：將 ISO 標準與企業(yè)內(nèi)部工藝規(guī)范結合
安全與合規(guī)保障
針對高風險操作自動添加安全警告
例如：加工特殊材料時提示需要特定防護措施和環(huán)保要求
5.7具體應用實例
機械設備故障診斷
提示詞增強：設備故障回答必須包含：故障代碼解釋、可能原因（按概率排序）、診斷步驟（從簡單到復雜）、維修所需工具清單、預計維修時間工藝參數(shù)推薦
提示詞增強：回答材料加工參數(shù)問題時，必須考慮企業(yè)現(xiàn)有設備能力限制，并參考企業(yè)工藝數(shù)據(jù)庫中的歷史成功案例質(zhì)量輔助控制
提示詞增強：分析質(zhì)量問題時，自動關聯(lián)企業(yè)SPC數(shù)據(jù)，引用相關ISO標準條款，并建議適用的企業(yè)標準檢測方法6、RAGFlow 與 MCP 整合方案示例
為了實現(xiàn)企業(yè)多源數(shù)據(jù)的接入，這里演示下最近項目中初步實踐通過 MCP 將 MySQL、EMS 等系統(tǒng)數(shù)據(jù)整合到 RAGFlow 框架中做法，供參考。
6.1架構設計
┌─────────────────────────────────────────────────┐
│ RAGFlow + MCP 集成架構 │
├─────────────────┬───────────────────────────────┤
│ │ LLM調(diào)用層 │
│ ├───────────────────────────────┤
│ 原有RAGFlow │ 向量檢索層 │
│ ├───────────────────────────────┤
│ │ 文檔處理層 │
├─────────────────┼───────────────────────────────┤
│ │ MCP適配器層 ?──────────┼──? MCP協(xié)議定義
│ ├───────────────────────────────┤
│ MCP擴展部分 │ 資源訪問控制層 │
│ ├───────────────────────────────┤
│ │ 多源數(shù)據(jù)連接層 │
└─────────────────┴───────────────────────────────┘
▲ ▲ ▲
│ │ │
┌────────┘ │ └────────┐
│ │ │
┌────────┐ ┌────────┐ ┌────────┐
│ MySQL │ │ EMS │ │ 其他系統(tǒng)│
└────────┘ └────────┘ └────────┘6.2參考案例
場景：工程師查詢設備故障和相關維修歷史
（此處打個廣告，相關示例源碼請移步我的知識星球）
1、用戶查詢
"數(shù)控車床HC-2000最近頻繁報E-35錯誤，是否有相關的維修記錄？"2、系統(tǒng)處理流程
MCP 請求生成
{
"response": {
"model": "DeepSeek-R1:32b",
"content": [
{
"type": "tool_use",
"id": "call_1",
"tool_use": {
"name": "query_equipment_status",
"parameters": {
"resource_id": "production_db",
"equipment_id": "HC-2000",
"query_type": "maintenance_history"
}
}
}
]
}
}數(shù)據(jù)庫查詢執(zhí)行：系統(tǒng)從 MySQL 數(shù)據(jù)庫中查詢 HC-2000 的維修記錄工具執(zhí)行結果
{
"data": [
{
"date": "2025-02-15",
"issue": "E-35錯誤：主軸編碼器信號異常",
"solution": "更換主軸編碼器，調(diào)整編碼器間隙"
},
{
"date": "2025-01-20",
"issue": "E-35錯誤：斷續(xù)出現(xiàn)",
"solution": "清潔線纜接頭，重新固定連接器"
}
]
}向量檢索補充：同時系統(tǒng)從向量數(shù)據(jù)庫檢索與"E-35 錯誤"相關的設備手冊和技術文檔
最終回復生成：系統(tǒng)綜合數(shù)據(jù)庫查詢結果和向量檢索結果，生成完整回答
用戶獲得回答
根據(jù)維修記錄，HC-2000數(shù)控車床近期兩次出現(xiàn)E-35錯誤（主軸編碼器信號異常）：
1. 2025年2月15日：更換了主軸編碼器并調(diào)整了編碼器間隙
2. 2025年1月20日：清潔了線纜接頭并重新固定連接器
從設備手冊分析，E-35錯誤通常由以下原因?qū)е拢?- 編碼器線纜損壞或接觸不良（占70%的案例）
- 編碼器本身故障（約20%的案例）
- 主軸驅(qū)動電路問題（約10%的案例）
建議采取以下步驟：
1. 檢查編碼器線纜是否有磨損或松動
2. 測量線纜連接器與編碼器接口電阻值（應<0.2Ω）
3. 使用示波器檢查編碼器信號質(zhì)量
根據(jù)企業(yè)SOP-M1001標準，此類問題需填寫《設備異常跟蹤表》并由維修部門評估是否需要調(diào)整預防性維護計劃。7、整合技術要點
保持模塊化設計
將 MCP 適配器作為獨立模塊添加，不破壞現(xiàn)有 RAGFlow 核心功能
使用適配器模式連接 RAGFlow 和企業(yè)數(shù)據(jù)源
統(tǒng)一資源訪問接口
為所有數(shù)據(jù)源（向量庫、MySQL、EMS 等）創(chuàng)建統(tǒng)一的資源訪問接口
確保權限控制一致性
查詢路由機制
開發(fā)智能查詢路由，自動決定是使用向量檢索還是結構化數(shù)據(jù)查詢
支持混合查詢模式，綜合多種數(shù)據(jù)源結果
緩存與性能優(yōu)化
對頻繁查詢的數(shù)據(jù)庫結果進行緩存
使用批處理減少數(shù)據(jù)庫連接開銷
部署考慮
確保數(shù)據(jù)庫連接器在企業(yè)內(nèi)網(wǎng)環(huán)境正確配置
處理網(wǎng)絡隔離環(huán)境下的連接問題
8、LLM 工具調(diào)用技術演進的一點思考
從復雜提示詞→Function Calling→GPTs 插件→MCP 協(xié)議的技術演進路徑，非常類似于幾個經(jīng)典技術標準化的發(fā)展歷程，特別是 Web 技術、互聯(lián)網(wǎng)協(xié)議和 API 標準化的過程。以 Web API 的標準化進程類比，
Web API 演進 | AI 工具調(diào)用演進 |
早期：RPC（遠程過程調(diào)用）各自實現(xiàn) | 早期：提示詞工程中的工具調(diào)用 |
發(fā)展期：SOAP 和 XML-RPC 等框架 | 發(fā)展期：Function Calling 的 JSON 結構化調(diào)用 |
成熟期：REST API 成為主流 | 成熟期：GPTs 等平臺專屬實現(xiàn) |
統(tǒng)一期：GraphQL 等新一代標準 | 統(tǒng)一期：MCP 作為統(tǒng)一協(xié)議 |
觀察 LLM 工具調(diào)用和相關技術標準的發(fā)展，似乎可以歸納出技術標準化的普遍規(guī)律：
探索期：
各方以自己的方式解決問題（提示詞工程）
初步標準化：
出現(xiàn)基礎結構化方案（Function Calling）
平臺主導期：
主要平臺推出自己的解決方案（GPTs 插件）
開放標準期：
形成統(tǒng)一開放標準（MCP 協(xié)議）
從歷史經(jīng)驗看，統(tǒng)一標準的出現(xiàn)通常會帶來技術領域的爆發(fā)式增長，如 Web 標準統(tǒng)一后的互聯(lián)網(wǎng)繁榮。MCP 協(xié)議的出現(xiàn)，很可能標志著 LLM 工具生態(tài)即將進入一個快速發(fā)展、廣泛應用的新階段。
25 年由此說來，值得期待更多垂直場景的最佳實踐了。
