作者 | rian

OpenAI 官宣全面支持MCP協議，至此MCP已得到業界廣泛的認可。正逐步成為AI應用架構的基礎協議。做為AI應用架構的USB-C,MCP原理是怎樣的？對實際業務又有何影響呢？本文以MCP原理解讀及業務實踐為切入點，探索AI應用架構在業務領域落地的路徑。

一、技術背景

大模型很長時間面臨認知邊界和工具使用的雙重約束：其知識體系受限于預訓練階段的靜態數據沉淀并缺少完成任務的工具。而傳統Function Call存在先天性的不足：線性指令執行機制帶來的性能瓶頸與異構接口標準帶來的兼容性瓶頸。這種局面在 Anthropic 2024.11 發布 Model Context Protocol 后得到改變——該協議重新定義了大語言模型與現實世界的交互范式。

1. Function Call vs MCP

Function Call，標桿開源項目是 Langchain Tools，它提供了"All In One"的工具箱，號稱大模型的瑞士軍刀。

而MCP的設計思路則不同，它遵循微內核架構的設計理念：定義架構和協議標準。號稱工具調用的USB-C標準。

標準發布后開源生態活躍，MCP 官方及三方組件累計已達到4000+。

官方MCPServer：GitHub - modelcontextprotocol/servers: Model Context Protocol Servers

基于這一框架，大語言模型突破了原有束縛：動態語義對齊機制將工具理解準確率提升至新量級，指令編排引擎則實現了高并發任務的智能調度。MCP通過標準化接口的語義映射能力，將離散的API調用轉化為具備上下文感知的協作指令集。

2. MCP Timeline

(1) 2024年11 月 24 日

Anthropic 發布 MCP 協議人工智能公司 Anthropic 首次提出 MCP（Model Control Protocol），旨在為無法直接修改底層邏輯的 Agent（如 Cursor、Claude 桌面端等）提供工具調用標準。協議允許用戶為第三方 Agent 動態接入自定義工具，無需開發者介入。

(2) 2024年12月

Claude + MCP 應用案例涌現 技術社區出現首批基于Claude 3.5 + MCP 的應用案例，例如通過MCP協議實現Claude與本地文件系統、數據庫的自動化交互。開發者工具Cursor同期發布MCP適配版本，驗證了該協議在多工具協作場景的可行性。

(3) 2025年3月初

MCP生態進入規模化應用階段 企業級應用：Block、Apollo等企業通過集成MCP實現跨系統數據調度，業務流程響應速度提升數倍；開發者工具：Cline、Windsurf 等工具原生支持MCP協議。

(4) 2025年3月11日

LangChain 官方發布核心辯論文章 LangChain 聯合創始人 Harrison Chase 與 LangGraph 負責人 Nuno Campos 圍繞 MCP 展開激辯。40% 參與者支持 MCP 成為未來標準。（33% 的人表示觀望）。

(5) 2025年3月12日

開源社區復現 Manus 技術方案 開發者社區組織線上分享會，探討如何基于 MCP 協議復現 Anthropic 的 Manus 框架（一種多 Agent 協作系統），進一步推動協議落地應用。

解讀：Manus 產品形態上讓人眼前一亮。而在 Manus 發布之前，完成特定領域任務的AI Agent 已經投入實際的生產工作（如AI編碼工具Cursor、Cline）。Manus 的關鍵詞是 "通用、復雜任務"。

(6) 2025年3月17日

Anthropic推出的MCP協議新傳輸方案"Streamable HTTP“。

該方案徹底重構了通信機制。解決了原HTTP+SSE方案在連接恢復性、服務器負載及雙向通信方面的核心瓶頸。

PR已于3.24合入。

解讀：1. 按需建立流式通道：會話初始化階段僅需常規HTTP請求，當檢測到需要持續交互（如工具執行進度反饋）時，服務器自動觸發SSE升級機制。2. 無狀態運行支持: 服務器無需長期維護連接狀態，處理完請求即可釋放資源，適合Serverless架構。

(7) 2025年3月27日

OpenAI宣布支持MCP協議。

3. MCP Roadmap

2025H1 MCP官方計劃支持以下能力：

(1) Remote MCP Support:

OAuth2授權&鑒權能力、服務注冊與發現、無狀態操作（支持serverless場景）

(2) Distribution & Discovery:

Package管理、沙箱環境（通過隔離提升安全性）、MCP Server注冊表

(3) Agent Support:

• 分層代理系統：通過命名空間與拓撲感知支持多級代理樹結構。
• 交互式工作流：優化跨代理層級的權限管理、用戶信息請求及輸出定向（用戶而非模型）。
• 流式結果：支持長任務實時結果推送，提升響應效率。

(4) Broader Ecosystem:

開放標準共建：推動社區主導的標準制定，鼓勵AI廠商平等參與治理，滿足多樣化應用需求。多模態支持：拓展音頻、視頻等非文本格式的兼容性。

這些都是MCP 架構工程化落地很需要的能力。

二、初步驗證

紙上得來終覺淺，了解到MCP概念后，我使用 Cline（VSCode插件）體驗了MCP Server開發、配置和使用的過程。

1. 開發 MCP Server

這里使用 Claude Sonnet 大模型和MCP模板快速實現了幾個MCP Server：openweather：基于openwheather api 查詢天氣信息。note-sqlite：使用 sqlite 保存、查詢筆記。

MCP Server 需要實現大模型友好的接口定義，核心的接口是：

2. 配置 MCP Server

將開發好的MCP Server 添加到Cline插件的MCP Server配置文件。

3. MCP Host 執行任務

在Cline對話框輸入任務："查詢并記錄天氣"。任務執行情況如下：

(1) 意圖識別與任務分解

Cline 將用戶prompt 和可用工具列表作為入參傳遞給LLM，LLM執行意圖識別與任務分解。

可以看到，大模型將任務分解為兩個主要步驟：

• 使用openweather 獲取深圳天氣數據 2. 使用note-sqlite 保存天氣數據
• 在此步驟大模型的輸出是：任務執行的工作流（查詢天氣->保存筆記）及Tool Call參數。

(2) 查詢天氣數據

Cline 根據大模型返回的工作流及Tool Call參數，調用get_current_weather 查詢天氣信息：

(3) 數據處理與格式化

Cline 將"查詢天氣"的結果加入到上下文中傳遞給大模型，大模型將其轉化為調用save_note工具的參數。

(4) 記錄天氣數據

Cline 使用大模型返回的 Tool Call 參數調用save_note工具保存筆記：

(5) 結果呈現

Cline 將"保存筆記"的結果加入到上下文傳遞給大模型，大模型返回任務總結：

為了驗證大模型對同類工具的選擇機制，我又開發、配置了一個weather-sqlite 服務，專門用于記錄天氣信息。

在查詢網天氣信息后，在note-sqlite和weather-sqlite 都可用的前提下，選擇了后者用于保存天氣信息。以下是大模型給出的決策理由：

三、原理解析

接下來看一下大模型和MCP工具集是如何協同完成用戶特定任務的。

1. 核心架構

(1) MCP Host （如Claude Desktop、Cursor IDE、Cline）可以看做是一個AI Agent。調用LLM執行意圖識別，制定任務計劃。然后調用MCP Server 完成任務流中的一個一個子任務。同時負責管理與用戶的會話。

(2) MCP Server 即大模型友好的工具集。通過類似OAS標準的Schema標注，讓大模型能很好地理解工具的功能范圍及使用方法。MCP Server需要有安全控制機制，以保障接口/資源不被越權訪問。

(3) MCP Client 即通信中間件。MCP Client 是MCP Host 引用的組件，負責與MCP Server 建立連接，并處理 JSON-RPC/SSE 等協議交互。

2. 交互流程

這里花了一點時間完整地探究了一下Cline 完整地梳理了Cline 處理用戶請求的流程。主要涉及兩個階段：

• 初始化階段：MCP Host啟動時基于配置與MCP Server 建立連接，獲取并緩存工具/資源的元數據描述（如接口定義JSON Schema）。
• 任務處理階段：MCP Host調用大模型做意圖識別和任務規劃。大模型結合用戶prompt及上下文信息、可用工具列表動態規劃任務流程并適配 Tool Call 參數。該階段采用ReAct循環機制，當參數不完整或輸出結果置信度低于閾值時啟動用戶協同修正流程。

3. 技術關鍵點

這里展開說一些關鍵技術細節

(1) 統一語義空間

MCP Server通過 Schema（類 OAS3標準） 明確定義工具的能力范圍及接口字段（包含類型、校驗規則及自然語言描述等）。

下面是一個示例Schema：

可以看到接口定義了兩個字段：city 和 days。兩個字段均有明確的描述信息和校驗規則。接口自身的功能描述信息也有在Schema中標注。

大模型基于用戶意圖動態規劃工具調用指令流。并根據上下文信息、工具的 Input Schema 生成調用參數。實現自然語言與工具調用的語義對齊。

(2) 雙向通訊協議

通過雙向通訊機制MCP Host 不僅可以通過RPC調用工具集，還可以實時感知工具和資源的變更。目前支持STDIO、Streamable HTTP兩種通訊協議。覆蓋了本地進程間通訊和遠端通訊的場景。

日志/文件處理是一個典型的應用場景。

(3) 微內核架構

得益于MCP微內核架構，任何支持 MCP 的 AI 應用（MCP Host）均可直接配置并使用應用市場的MCP Server（官方、三方），無需預編碼適配。類似于 USB 設備插入即用。

Cline MCP Server配置文件示例：

四、業務探索

為了探索AI應用架構在QQ機器人場景落地的路徑。我遵循MCP提供的思路，搭建了一個的AI Agent DEMO機器人。

1. DEMO制作

機器人基于MCP協議接入工具集，基于大模型的意圖識別和動態規劃能力完成用戶任務的過程，采用ReAct模式迭代處理用戶任務，直至任務完成。

共涉及3個服務：MCP Host（即機器人服務端）和2個MCP Server（包含查詢天氣的工具、制定行程計劃的工具）。

驗證截圖如下：

機器人首先提示用戶補全信息，然后調用MCP Server工具集完成了"查詢天氣 -> 制定行程"的任務流程。最后調用大模型輸出了任務總結。

由于token成本的原因，demo機器人未開放體驗。

2. 架構推演

實際業務場景中智能體需要響應用戶各種各樣的請求，比如：搜索、畫圖、拍照解題、文檔處理等等。單Agent架構難以支撐，難以擴展。我們把目光投向了時下熱度很高的Multi-Agent架構。

(1) 引入Multi-Agent架構

我們調研了：LangManus、OpenManus、OWL、Tars等完整產品形態的開源框架。同時也調研了一些更輕量的后臺框架，比如eino 。這些框架在這些框架有一些共同點：引入了多Agent動態協同、上下文管理、任務流編排與執行等能力。核心邏輯都采用了ReAct模式進行循環迭代。都引入一套處理特定任務的工具集（如搜索、文檔處理），同時支持MCP擴展。

這里基于調研的結論及對開源框架的理解畫了一下 Multi-Agent的架構示意圖：

這里不展開說。后續會發專項文章。敬請期待。

(2) 解決大模型應用開發的痛點

大模型給應用開發帶來了很大的便利：

• 基于語義的文本處理能力：能夠理解和生成人類語言，處理非結構化的內容語義關系
• 動態決策能力：能夠基于上下文進行推理和判斷，做出相應的行為決策

但大模型提供良好泛化能力的同時也引入了一些痛點，那就是準確性和穩定性。

典型 case：

• 準確性 ：用戶希望使用AI Agent的P圖功能，在發送圖片給Agent后，又說"卡通風格"。而AI Agent 出戲了回復了一段文字解釋了卡通風格。大模型沒有理解到用戶處于畫圖的流程中。
• 穩定性：用戶輸入"我明天去第比利斯旅行，請幫我制定一個4天旅行計劃"。可能存在大模型第一次規劃的任務流程和第二次不一致的情況，比如：第一次"調用工具查詢天氣 -> 調用工具制定行程計劃"，第二次"詢問用戶當地的天氣情況- > 調用工具制定行程計劃"。

可以從算法和工程兩個維度來改進。這里主要探討工程化的提升手段/措施：

① 提升意圖識別準確性的工程化手段

• 精細化提示詞管理、上下文管理，為大模型提供必要準確的信息。
• 通過任務質量Agent 收集低置信度意圖識別結果。完成反饋與修正流程。

② 提升任務流規劃穩定性的工程化手段

• （參考eino框架的思路）開發者預先定義執行圖的結構和可能的路徑，固化某些業務的處理流程，而大模型在運行時根據任務內容動態決定具體走哪條路徑。這種設計既保證了系統的結構化和可控性，又提供了足夠的靈活性來處理各種復雜任務。
• 復雜流程處理上：增加按照用戶響應判斷是否跳出任務的處理過程的邏輯或步驟。

拋磚引玉。這里簡單聊了一下我在探索AI應用架構落地過程中遇到的一些問題和思考。

五、總結與展望

寫這篇文章加實踐探索先后花了2周左右的時間。這段時間MCP生態活躍。我也不斷在更新文章第一章節的Timeline。

我深切地感受到技術創新正以前所未有的速度進行著。同時也意識到技術創新給業務生態帶來的無限可能：

各個行業可以基于MCP協議開放工具（比如購買機票、預訂外賣），參與AI工業革命的進程。

智能體應用（手機APP、桌面端或網頁）可以基于MCP開放生態接入的海量工具構建業務形態。比如：用戶發出的自然語言指令，智能體應用借助外部服務/工具完成用戶任務（比如用戶："幫我購買8月份去格魯吉亞旅游的低價往返機票"。智能體應用：首先提供機票查詢結果，然后在用戶確認后購買機票，并設定日程提醒）

后續會持續分享AI應用架構在QQ業務場景落地的實踐。歡迎大家來交流。