哈嘍，我是老劉
老劉是個客戶端開發者，目前主要是用Flutter進行開發，從Flutter 1.0開始到現在已經6年多了。
那為啥最近我對MCP和AI這么感興趣的呢？
一方面是因為作為一個在客戶端領域實戰多年的程序員，我覺得客戶端開發的終局一定和AI是強綁定的。
另一方面就個人而言，我對新技術一直有很大的好奇心。
本文就來聊聊目前比較火熱的MCP到底是怎么來的，以及它和Agent等其它AI相關技術的關系。

一、LLM、Function call和MCP

LLM是啥： 大語言模型本質上是一個具有一定思考能力的對話機器。簡單來說就是你提問他回答。
但是他的回答只能限制在訓練LLM的語料庫范圍內，超出范圍的內容答不出來或者瞎編。

那么如何讓LLM回答實時性高的或者沒有訓練過的問題呢？

第一代方案：

人工搜索相關的文章后通過對話發給LLM，LLM整理后回答你的問題。
缺點是費時費力，所以有了第二代方案

第二代方案：

將第一代的人工搜索并喂給LLM通過瀏覽器插件或者其它軟件工具自動化完成。
這套方案的缺點是不夠智能，比如我問ai：“明天應該穿什么？”
這時插件會直接搜索明天穿什么而不是明天的天氣怎么樣。
其實我們真正的問題是：明天什么天氣，并且根據天氣判斷穿什么衣服。
所以有了第三代方案Function call

第三代方案（Function call）：

要解決上面的問題，就需要讓LLM去理解用戶的問題，并做出判斷：去搜索明天的天氣。
如何讓LLM能調用外部的工具搜索天氣呢？
ChatGPT在2023年6月份的時候提出來了Function call協議。
它的工作方式如下：

1、??請求階段??
用戶提問 + 函數定義列表 → 發送至ChatGPT API。

{"functions": [{"name": "get_weather","description": "獲取城市天氣","parameters": {"type": "object","properties": {"location": {"type": "string"}}}}]
}

??2、模型決策??
模型判斷需調用函數 → 返回函數名及參數字符串，如：

{"name": "get_weather","arguments": "{\"location\": \"Beijing\"}"
}

3、??函數執行??
AI客戶端（例如CherryStudio、Cursor）解析JSON，調用本地或外部API（如天氣接口），獲取結果。
4、??結果整合??
將函數返回數據再次發送給模型 → 生成最終自然語言回復（如“今日晴，25°C”）。

Function call最重要的作用是讓LLM能根據和用戶的對話自主分析需要調用哪些接口和工具。
但是Function call的缺點也很明顯：
從前面的工作方式中可以看出來，Function call并沒有明確規定向LLM發送函數列表以及LLM調用某個方法時的具體字段及協議標準。
這就會造成不同LLM接受函數列表以及調用時的字段可能各不相同。
比如我要開發一個天氣查詢服務，就需要針對不同的LLM開發不同的通知和解析過程。
而作為一個AI客戶端，比如Cursor或者CherryStudio，也需要針對不同的LLM以及不同的服務提供者做專門的適配。
為了解決上面這個問題，將Function call的通知和調用接口統一成標準協議自然而然的產生了，那就是MCP。

第四代方案（MCP）：

MCP通過定義一個統一的協議層解決了上述碎片化問題：
1、??統一交互協議??

• ??標準化函數描述格式??：所有服務提供者遵循同一套MCP Schema定義函數（名稱、參數、權限）
• ??調用指令規范化??：LLM返回的請求強制符合MCP JSON Schema，消除解析歧義

示例：MCP函數調用指令格式

{"action": "execute","tool": "weather","params": {"location": "Beijing"}
}

2、雙向解耦設計??

角色	受益點
服務提供者	一次開發即支持所有MCP兼容LLM（無需適配各平臺）
AI客戶端	通用解析引擎處理任意MCP服務，新服務接入零成本

3、MCP的工作流程
下面來看MCP的完整工作流程：

其實本質是是對Function call的標準化
在啟動客戶端后，會進行初始化操作，將目前客戶端已經配置好的MCP服務列表發送給LLM。
在具體的問答階段，LLM會自主判斷需要調用哪些外部工具，然后將調用的參數發送給Host（比如Cursor）。
Host收到調用的Json后會去調用MCP Server的對應接口，然后將返回的結果再發送給LLM。
這個過程可能會循環多次，直到LLM認為已經獲取足夠的信息，最終LLM將最后結果返回給用戶。

二、 MCP、工作流和Agent

Agent
先來說Agent，如果LLM是一個具備語義理解與推理能力的對話機器，那么Agent就是基于LLM的能力能夠獨立完成任務拆解、自主決策并執行相關動作的一個智能體。
它不再是只能和你對話，而是能完成“感知-規劃-執行”的閉環。
簡單來說就是Agent先讀懂你的要求，然后自己規劃一個執行步驟，最后能調用相關的外部工具完成執行動作。

工作流
那么工作流在這中間起到什么作用呢？
首先我們要知道LLM的語義理解與推理能力和人類的邏輯推理是不一樣的，LLM的推理是基于概率和模式匹配的。
直觀的結果就是一方面它有時候會一本正經的胡說八道，另一方面它拆解的執行步驟可能和我們預期的不太一致。
比如有可能你把任務換個說法，Agent拆解出來的步驟就不一樣了。
那么能否把一些明確的固定的工作流程或者好的實踐變成一個模板告訴Agent，讓Agent每次碰到同類的事務就按照這個固定步驟去執行呢？
比如“客戶訂單處理”的流程就固定為：接收→庫存檢查→發貨→通知
工作流就是這種標準化的操作模板，通過這些預設邏輯可以降低Agent決策復雜度，提升執行可靠性。

MCP
有了強大的LLM，以及優秀的工作流，Agent就可以像一個真正的人類一樣，把事情安排好，甚至做的比人類更好。
現在只剩下最后一件事，就是讓Agent能操作外部工具。這就是MCP的作用了。
有了Function call，LLM就已經可以調用外部工具獲取信息或者執行動作。
但是Function call本身沒有統一的標準，不利于推廣，因此MCP為各種不同的LLM和服務之間建立了統一的通信標準協議。
Agent或者工作流的任何一個步驟都可以通過MCP完成外部世界的信息獲取或者對外部世界的操作。

LLM、Agent、工作流和MCP的對比

組件	角色類比	依賴關系	核心價值
LLM	大腦	Agent的推理基礎	語義理解與決策生成
Agent	指揮官	驅動工作流，調度MCP	任務拆解與動態決策
工作流	戰術手冊	固化Agent的最佳實踐	提升執行效率與可復現性
MCP	萬能工具包	為Agent和工作流提供武器庫	打破數據孤島，實現工具即插即用

Coze

看到很多人問Coze和MCP以及和工作流的關系，這里簡單說一下我的理解。
Coze是一個幫助開發者搭建Agent的平臺。
你可以在里面創建自己的智能體Agent，為這個智能體指定特定的工作流。
給這個智能體配置一些基于MCP的外部工具。
最終將這個智能體打包成App、網站、小程序對話機器人等隊外的樣式并發布出去。

總結

以上是老劉對“MCP是什么？”、“MCP怎么來的？”、“MCP是如何工作的？”這些問題的理解。
作為一個客戶端、Flutter開發者，我覺得在這個AI蓬勃發展的時代，客戶端的未來一定是和AI強綁定的。
而MCP作為AI時代的API標準，也是每個客戶端程序員都應該掌握的技能。
好了，如果看到這里的同學對客戶端、Flutter開發或者MCP感興趣，歡迎聯系老劉，我們互相學習。
點擊免費領老劉整理的《Flutter開發手冊》，覆蓋90%應用開發場景。
可以作為Flutter學習的知識地圖。
覆蓋90%開發場景的《Flutter開發手冊》