這才是MCP 爆火的原因!
現在很多人讓大模型調用外部工具,最常見的做法就是 Function Calling。
乍一看,能調起來沒問題。但真要接多個服務、跑一個完整流程,Function Calling 就顯得太粗糙了——定義繁瑣、結構不統一、模型換一個就得重寫一遍。
本質上,它解決的只是“能不能調用”,但沒解決“怎么標準、高效地調用”。
而 MCP 出現,就是為了解決這個“工程化不成體系”的問題。
我認為 Function Calling 更像是“你教模型怎么用某個函數”;而 MCP,是“你把這些函數變成服務,模型自然知道怎么用”。
MCP像是給你寫的工具函數裝了一個“USB標準口”,以后不管哪個模型來,都能直接插上用。
一、什么是 MCP?
MCP(Model Context Protocol)是一套協議,專門讓大模型更穩、更方便地調用外部服務。
它不是工具、不是框架,而是像 HTTP、SQL 一樣的“語言規范”,
讓大模型在面對不同的工具時,說話有標準,調用有格式,接入有規矩。
我們先明確一點:MCP 不會幫你寫代碼,你該寫服務還是得寫服務。
那 MCP 到底解決了啥?
很多人一聽 MCP 就頭大,總覺得它是某種框架或者平臺,但其實本質非常簡單。
場景設定:調用一個“查天氣”的工具
我們希望:大模型收到一句自然語言,比如“請幫我查一下北京今天的天氣”,就能觸發一個查天氣的工具,返回結果。
寫法一:傳統 Function Calling 寫法(OpenAI 風格)
你得自己寫一個函數,并且注冊到模型里,同時描述這個函數:
{
"name": "get_weather",
"description": "獲取指定城市的天氣",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "查詢天氣的城市名"
}
},
"required": ["city"]
}
}
然后你在代碼里寫這個函數:
def get_weather(city):
# 調用真實的天氣 API
return f"{city} 今天多云,最高溫 26°C"
整個流程:
你注冊函數描述
用戶問話 → 模型判斷要用這個函數 → 填參 → 調用 → 返回
這樣的問題:
- 函數定義和調用分開寫,靠自己綁定;
- 函數描述得自己寫一遍;
- 多個服務無法統一管理;
- 不能“自動注冊、自動識別”,全部靠人工維護;
- 接入多種服務,寫法冗余、難復用。
寫法二:使用 MCP 協議 + MCP SDK 實現
第一步:你寫一個“天氣服務”的 MCP Server(可以用 Flask)
from flask import Flask, request, jsonify
app = Flask(__name__)
@app.route("/invoke", methods=["POST"])
def handle():
req = request.get_json()
city = req["params"]["city"]
result = f"{city} 今天多云,最高溫 26°C"
return jsonify({
"status": "ok",
"result": result
})
注意,這個服務只要實現了 /invoke 接口,格式遵循 MCP 協議,就可以被任意支持 MCP 的模型接入。
第二步:模型那邊(Client)用 MCP SDK 發請求
from mcp import MCPClient
client = MCPClient("http://your-mcp-server-url")
response = client.invoke(
tool="weather", # 工具名
params={"city": "北京"}
)
print(response["result"])
關鍵點在這兒:
- MCP 定義了一套【工具格式、參數結構、通信協議】;
- 工具只要部署成 MCP Server,就能自動接入;
- 模型這邊只要用 MCP Client 發請求,就能統一對接任何符合協議的工具。
總結一下
我們可以這樣理解:
HTTP 是瀏覽器和服務器之間說話的協議;
SQL 是你和數據庫之間說話的協議;
MCP 是大模型和外部工具之間說話的協議。
有了 HTTP,網頁才能統一訪問后端服務,不用每個頁面自己發明新格式;
有了 MCP,大模型也能統一調用你寫的工具,不用每個模型手動綁接口、拼參數、猜格式。
它不是要替你寫業務代碼,
而是讓模型知道:“你要想用我這個函數,得按照 MCP 的方式來交流。”
三、最后幾點感悟
MCP 本質上不是“新能力”,而是把原本凌亂的工具接入方式,變成了一套大家都能理解、能協作的規范。
它不會讓大模型變聰明,但它會讓模型調用外部服務這件事,更穩、更標準、更能規模化落地。
這可能不是最酷炫的技術方向,但卻是讓大模型真正走向業務系統的一步關鍵工程基礎。
不管你做的是 Agent、RAG、還是企業內智能系統,理解 MCP、會用 MCP,會是你構建長期可維護系統的底座能力之一。
本文轉載自???大圣數據星球???,作者:大圣
