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