本文提供了一個全面的視角，來看待如何利用模型上下文協(xié)議（MCP）實現(xiàn) AI 應用架構設計新范式的落地實現(xiàn)，核心內容主要是以下5點：

• MCP 概念與機制。
• MCP 與 Function Calling 區(qū)別。
• MCP 本質與挑戰(zhàn)：挑戰(zhàn)包括系統(tǒng)提示詞的準確性、Client 與 Server 協(xié)同、快速構建 Server、自建 Dify 的痛點等。
• 解決 MCP 挑戰(zhàn)的方法：通過 MCP Register、統(tǒng)一管理 Server 和 Prompt、建立效果驗證體系與安全保障、設置 MCP 網(wǎng)關、動態(tài)服務發(fā)現(xiàn)、Streamable HTTP、彈性效率、可觀測等手段解決。
• AI 應用架構設計新范式：MCP 推動 AI 應用架構向新范式發(fā)展，并通過 Server First 理念，提升應用性能和用戶體驗。

下面詳細介紹之。

一、AI Agent 現(xiàn)狀與架構

AI 大模型在商業(yè)領域的應用正成為推動創(chuàng)新和效率提升的核心力量。其關鍵在于多個AI Agent 的協(xié)作，這些 AI Agent 通過分工與合作，共同承載 AI 應用所支持的業(yè)務需求。這種協(xié)作模式不僅優(yōu)化了企業(yè)運營，還展現(xiàn)了 AI 在解決高影響力挑戰(zhàn)中的潛力。

目前 AI Agent 與各種 Tools（業(yè)務服務接口）、Memory（存儲服務接口）以及 LLMs（大語言模型）的交互主要通過 HTTP 協(xié)議實現(xiàn)。除了 LLMs 基本遵循 OpenAI 范式外，與其他 Tools 和 Memory 的交互需要逐一了解它們的返回格式進行解析和適配，這增加了開發(fā)的復雜性。

當一個 AI 應用包含多個 AI Agent，或者需要與多個業(yè)務服務接口和存儲服務接口交互時，開發(fā)工作量顯著增加，主要體現(xiàn)在以下三個方面：

第一、尋找合適的接口

• 尋找三方服務接口。
• 在公司內部尋找合適的服務接口。
• 如果找不到，就需要自行開發(fā)接口。

第二、解析接口返回格式

• 無論是三方服務接口還是公司內部的服務接口，返回格式可能千差萬別，需要逐一了解和解析。

第三、編排多個 AI Agent

• 使用如 Dify 這類流程可視化的工具輔助編排，雖然減輕了一些工作量，但復雜度依然較高，且在運行效率和性能方面存在瓶頸。
• 通過編碼方式編排（比如：使用 Spring AI Alibaba 或 LangChain 等），雖然性能更優(yōu)，但復雜度更高，編排效率和靈活性不足。

因此，目前許多 AI應用只包含少數(shù)幾個 AI Agent，甚至很多應用背后只有一個 AI Agent。這也是目前 AI 應用背后的 AI Agent 仍處于第一階段（Siloed, Single-Purpose Agents）的原因。

為了使 AI Agent 進入第二階段（Platform-Level Agents），我們使用云原生 API 網(wǎng)關作為統(tǒng)一的接入層，通過網(wǎng)關的三種不同角色，解決了部分復雜度問題：

第一、作為南北向流量網(wǎng)關

• 統(tǒng)一管理 AI Agent 的入口流量，核心功能包括轉發(fā)、負載均衡、鑒權認證、安全和流控等。

第二、作為 AI 網(wǎng)關

• 代理各類 LLMs，向 AI Agent 屏蔽了繁雜的接入，并解決了許多生產(chǎn)級問題，比如：多模型切換、模型 Fallback、多 API Key 管理、安全和聯(lián)網(wǎng)搜索等。

第三、作為東西向網(wǎng)關

• 統(tǒng)一管理來自不同源（ACK、ECS、函數(shù)計算FC、SAE、三方服務）的各類服務，供 AI Agent 使用。

然而，上述方法僅解決了部分復雜度問題，更核心的尋找接口和解析接口的問題仍未得到解決。直到 MCP（Model Context Protocol）的出現(xiàn)，我們看到了真正通往第二階段（Platform-Level Agents）的道路，甚至有望觸及第三階段（Universal Agents, Multi-Agents）。

二、MCP 架構設計剖析

1、MCP 是什么？

MCP（模型上下文協(xié)議，Model Context Protocol）是由Anthropic（Claude 的開發(fā)公司）開發(fā)的開源協(xié)議，旨在為大語言模型（LLM）提供一種標準化的方式，以便它們能夠連接到外部數(shù)據(jù)源和工具。它就像是 AI 應用的“通用接口”，幫助開發(fā)者構建更靈活、更具上下文感知能力的 AI 應用，而無需為每個 AI 模型和外部系統(tǒng)組合進行定制集成。

MCP 的設計理念類似于 USB-C 端口，允許 AI 應用以一致的方式連接到各種數(shù)據(jù)源和工具，如文件、數(shù)據(jù)庫、API 等。

MCP 包含三個核心概念：

第一、MCP Server

• 基于各語言的 MCP SDK 開發(fā)的程序或服務。
• 它通過某種機制將現(xiàn)有的程序或服務轉換為 MCP Server，使其能夠與 AI 應進行交互。

第二、MCP Tool

• MCP Tool 屬于 MCP Server，一個 MCP Server 可以有多個 MCP Tool。
• 可以將其理解為一個類中有多個方法，或者一個服務中有多個接口。

第二、MCP Client

• 當一段代碼、一個 AI Agent 或一個客戶端基于 MCP 的規(guī)范去使用或調用 MCP Server 中的 MCP Tool 時，它就被稱為 MCP Client。

2、MCP 的運作機制

要真正理解 MCP，我們需要深入其運作機制，這不僅能揭示 MCP 調用方式與傳統(tǒng) HTTP 調用方式的差異，還能讓你明白為何 MCP 能夠助力 AI Agent 邁向第二階段。

以開發(fā)一個獲取時間的 AI Agent 為例，用戶只需提問“現(xiàn)在幾點了？”即可。假設我們已有一個處理時間的 MCP Server，其中包含兩個 MCP Tool：一個用于獲取當前時區(qū)，另一個用于獲取當前時間。

基于 MCP 的調用過程分為六個核心步驟：

第一、用戶提問

• 用戶向 AI Agent 提問“現(xiàn)在幾點了？”。此時，AI Agent 作為 MCP Client，將用戶問題連同處理時間的 MCP Server 及 MCP Tool 信息一并發(fā)送給 LLM。

第二、LLM 推理

• LLM 接收到信息后，根據(jù)用戶問題和 MCP Server 信息，篩選出最合適的 MCP Server 和 MCP Tool 來解決問題，并將結果反饋給 AI Agent（MCP Client）。LLM 返回的信息可能是：“使用 time MCP Server 中的 get_current_time MCP Tool，它能解決用戶的問題?！?/li>

第三、調用 MCP Tool

• AI Agent（MCP Client）依據(jù) LLM 的建議，調用 time MCP Server 中的 get_current_time MCP Tool，獲取當前時間。

第四、返回結果

• time MCP Server 將當前時間的結果返回給 AI Agent（MCP Client）。

第五、內容規(guī)整

• AI Agent（MCP Client）將用戶問題和從 time MCP Server 獲取的結果再次提交給 LLM，請求 LLM 結合問題和答案規(guī)整內容。

第六、最終反饋

• LLM 將規(guī)整后的內容返回給 AI Agent（MCP Client），AI Agent 再將結果原封不動地返回給用戶。

在整個 MCP 調用過程中，MCP Server 及 MCP Tool 的信息至關重要。從第一步和第二步可以看出，這些信息為 LLM 提供了解決問題的關鍵線索。這些信息本質上就是 MCP 中的 System Prompt，其核心作用是為 LLM 提供清晰的指導，幫助其更好地理解用戶需求并選擇合適的工具來解決問題。

3、MCP System Prompt

MCP（模型上下文協(xié)議）與傳統(tǒng)協(xié)議定義不同，它并沒有固定的數(shù)據(jù)結構。其核心在于通過自然語言清晰地描述 MCP Serve r和 MCP Tool 的功能及作用，讓大語言模型（LLM）通過推理來選擇最合適的 MCP Server 和 MCP Tool。因此，MCP 的本質仍然是提示詞工程（Prompt Engineering）。

以下是一些關鍵的示例和步驟解析：

第一、 MCP Client（Cline）中的 System Prompt

Cline 是一個 MCP Client，其 System Prompt 對 MCP Server 和 MCP Tool 都有明確的描述。比如：它會詳細說明每個 MCP Server 的功能以及其中包含的 MCP Tool 的作用。這種描述為 LLM 提供了足夠的上下文，使其能夠理解每個工具的用途。

上圖告訴 LLM：

• 告訴 LLM 你有一堆工 具可以用。
• 告訴 LLM 每次你只能選一個工具用。
• 告訴 LLM 工具是通過 XML 描述定義的。并詳細描述了 XML Tag 的定義。并給出了樣例。本質就是告訴 LLM 你選擇完后該返回什么樣的格式。

上圖告訴 LLM：

• 向 LLM 解釋了什么是 MCP。
• 對每個 MCP Server 和 MCP Tool 做了詳細描 述。包括傳參格式。

第二、流程第一步：發(fā)送問題和 System Prompt

在調用流程的第一步，用戶的問題（如“現(xiàn)在幾點了？”）和 System Prompt 一起被發(fā)送給 LLM。System Prompt 的作用是為 LLM 提供清晰的指導，幫助其理解用戶問題的背景和可用的工具。

第三、流程第二步：LLM 返回解決方案

在第二步，LLM 根據(jù)用戶問題和 System Prompt 中的信息，推理出最合適的 MCP Server 和 MCP Tool，并返回明確的解決方案。比如：LLM 可能會返回：“使用 time MCP Serve r中的 get_current_time MCP Tool 來解決用戶的問題?！辈⒁?XML 格式 返回給 Client/Agent。

通過這種方式，MCP 利用自然語言描述和 LLM 的推理能力，動態(tài)地選擇和調用最適合的工具，從而實現(xiàn)靈活且高效的 AI 應用開發(fā)。

4、MCP 與 Function Calling 區(qū)別

通過前面的介紹，相信大家對 MCP 有了清晰的認識。MCP 是否解決了找接口和解析接口的問題呢？答案是肯定的。因為這兩個任務都交給了 LLM（大語言模型）來完成。

    第一、LLM 負責為 AI Agent 找到最合適的接口。

    第二、AI Agent 調用接口時，無需解析返回結果，而是將結果原封不動地交給LLM。

    第三、LLM 結合用戶問題和接口返回的結果，進行內容規(guī)整處理。

那么，MCP 與 LLM 的 Function Calling 有什么區(qū)別呢？核心區(qū)別在于是否綁定特定的模型或模型廠商：

    第一、MCP 是通用協(xié)議層的標準，類似于“AI 領域的 USB-C 接口”，定義了 LLM 與外部工具/數(shù)據(jù)源的通信格式，但不綁定任何特定模型或廠商。它將復雜的函數(shù)調用抽象為客戶端-服務器架構，使得不同模型和工具之間的交互更加靈活和通用。

    第二、Function Calling 是大模型廠商提供的專有能力，由大模型廠商定義，不同廠商在接口定義和開發(fā)文檔上存在差異。它允許模型直接生成調用函數(shù)，觸發(fā)外部 API，依賴模型自身的上下文理解和結構化輸出能力。

例如，LLM Function Calling 需要為每個外部函數(shù)編寫一個 JSON Schema 格式的功能說明，并精心設計一個提示詞模板，才能提高 Function Calling 響應的準確率。如果一個需求涉及幾十個外部系統(tǒng)，那么設計成本將是巨大的，產(chǎn)品化成本極高。

而 MCP 統(tǒng)一了客戶端和服務器的運行規(guī)范，并且要求 MCP 客戶端和服務器之間也統(tǒng)一按照某個既定的提示詞模板進行通信。這樣，通過 MCP 可以加強全球開發(fā)者的協(xié)作，復用全球的開發(fā)成果，降低開發(fā)成本，提高開發(fā)效率。

5、MCP 的本質與挑戰(zhàn)

通過前面的討論，我們可以總結 MCP（模型上下文協(xié)議）的本質：MCP 并非一個固定的數(shù)據(jù)格式或結構，而是系統(tǒng)提示詞與 MCP Server 和 LLM 之間協(xié)同關系的結合。它通過自然語言描述 MCP Server 和 MCP Tool 的功能，讓 LLM 能夠推理出最適合的工具來解決問題，從而解決了找接口和解析接口的問題。

然而，將 MCP 引入企業(yè)級生產(chǎn)應用時，會面臨諸多挑戰(zhàn)：

第一、描述 MCP 信息的系統(tǒng)提示詞的挑戰(zhàn)

• 系統(tǒng)提示詞的安全性：系統(tǒng)提示詞是 MCP 的核心，如果被污染，LLM 可能會被誤導，選擇錯誤甚至存在安全漏洞的 MCP Server 和 MCP Tool，從而導致整個 MCP 流程癱瘓，給 AI 應用帶來巨大風險。
• 系統(tǒng)提示詞的管理：當 MCP Server 或 MCP Tool 更新時，系統(tǒng)提示詞也需要相應地進行版本管理，以確保 LLM 能夠獲取最新的工具信息。
• 系統(tǒng)提示詞的調試與實時生效：系統(tǒng)提示詞沒有標準定義，每個企業(yè)都可以自定義模板。由于提示詞需要反復調試，因此需要一種機制能夠快速調整并實時生效。
• 系統(tǒng)提示詞的 Token 消耗：如果 MCP Server 和 MCP Tool 數(shù)量眾多，系統(tǒng)提示詞會變得非常長，消耗大量 Token，增加成本。因此，需要一種機制基于用戶問題預篩選 MCP Server 和 MCP Tool 的范圍，減少 Token 消耗，提高效率。

第二、MCP Client 與 MCP Server 之間協(xié)同關系的挑戰(zhàn)

• MCP Client 的稀缺性：目前市面上的 MCP Client（比如：Cline、Claude、Cursor 等）數(shù)量有限，且大多基于 C/S 架構，僅支持 SSE 協(xié)議。這種有狀態(tài)的協(xié)議存在諸多弊端，比如：不支持可恢復性、服務器需維持長期連接、僅支持單向通信等，難以與企業(yè)級 AI 應用結合。
• 現(xiàn)存業(yè)務的轉換難題：開發(fā) MCP Server 依賴于特定語言的 MCP SDK （目前僅支持 Python、Java、TS、Kotlin、C#）。對于使用 Go 或 PHP 等其他技術棧的企業(yè)，轉換為 MCP Server 的工作量巨大，且不現(xiàn)實。
• MCP Server 的統(tǒng)一管理：企業(yè)可能擁有自建的 MCP Server、第三方的 MCP Server 以及通過某種機制轉換而來的 MCP Server。需要一個類似 MCP Hub 或 MCP 市場的平臺來統(tǒng)一管理這些 Server，方便 MCP Client 使用。
• 企業(yè)級應用中的安全與權限問題：在企業(yè)級應用中，身份認證、數(shù)據(jù)權限和安全防護是關鍵問題。在 MCP 的協(xié)同模式下，如何實現(xiàn)這些功能是亟待解決的挑戰(zhàn)。

總之，盡管 MCP 為 AI 應用開發(fā)帶來了靈活性和效率提升，但在企業(yè)級應用中，仍需克服系統(tǒng)提示詞的安全性、管理、調試以及 MCP Client 與 MCP Server 之間的協(xié)同關系等多方面的挑戰(zhàn)。

三、AI 應用架構設計新范式

為了解決 MCP 在企業(yè)級應用中面臨的諸多挑戰(zhàn)，對 AI Agent 的架構進行了深度重構。通過在云原生 API 網(wǎng)關和注冊配置中心 Nacos 中引入 MCP 增強能力，成功解決了大部分挑戰(zhàn)點。同時，分別針對快速開發(fā) MCP Server 和提升開源 Dify 性能的問題提供了有效解決方案。這些舉措共同構建了一個基于 MCP 的 AI 應用開發(fā)新范式，推動了 AI 應用的高效開發(fā)與部署。

云原生 API 網(wǎng)關與 Nacos 的 MCP 增強：通過這兩個產(chǎn)品的增強能力，解決了系統(tǒng)提示詞的安全性、管理、調試以及 MCP Client 與 MCP Server 之間的協(xié)同關系等核心挑戰(zhàn)。云原生 API 網(wǎng)關提供了強大的流量管理和安全防護功能，而 Nacos 則在服務發(fā)現(xiàn)和配置管理方面發(fā)揮了關鍵作用，確保了 MCP Server 和 LLM 之間的高效協(xié)同。

通過這些增強能力的實現(xiàn)，解決了 MCP 在企業(yè)級應用中的關鍵挑戰(zhàn)。

3.1、AI 應用架構新范式剖析

AI 應用架構結合 MCP，我們定義了 AI 應用架構的新范式。

一個云原生 API 網(wǎng)關三種角色，具備統(tǒng)一的管控底座，同時又實現(xiàn)各角色的協(xié)同調度。

Nacos 發(fā)揮注冊中心優(yōu)勢，增加 MCP Server 的注冊能力，實現(xiàn)普通服務和 MCP Server 的統(tǒng)一管理，結合網(wǎng)關實現(xiàn)現(xiàn)存業(yè)務0改造轉換為 MCP Server。

以下是對圖中8步核心調用鏈路的解析：

第一步用戶請求：用戶向 AI 應用發(fā)起請求，請求流量首先進入流量網(wǎng)關（云原生 API 網(wǎng)關）。

第二步請求轉發(fā)：云原生 API 網(wǎng)關維護管理不同類型的 AI Agent 的 API 或路由規(guī)則，將用戶請求轉發(fā)至對應的 AI Agent。

第三步獲取 MCP 信息：AI Agent 在需要獲取數(shù)據(jù)時，向 MCP 網(wǎng)關（云原生 API 網(wǎng)關）請求獲取可用的 MCP Server 及 MCP Tool 信息。

第四步 LLM 交互（可選）：MCP 網(wǎng)關可能維護大量 MCP 信息，借助 LLM 縮小 MCP 范圍，減少 Token 消耗，向 AI 網(wǎng)關（云原生 API 網(wǎng)關）發(fā)請求與 LLM 交互。

第五步返回 MCP 信息：MCP 網(wǎng)關將確定范圍的 MCP Server 及 MCP Tool 信息列表返回給 AI Agent。

第六步發(fā)送至 LLM：AI Agent 將用戶請求信息及從 MCP 網(wǎng)關獲取的所有 MCP 信息通過 AI 網(wǎng)關發(fā)送給 LLM。

第七步 LLM 推理：LLM 經(jīng)過推理，返回解決問題的一個或多個 MCP Server 和 MCP Tool 信息。

第八步調用 MCP Tool：AI Agent 拿到確定的 MCP Server 和 MCP Tool 信息后，通過 MCP 網(wǎng)關對該 MCP Tool 發(fā)起請求。

在實際生產(chǎn)中，步驟3至8會多次循環(huán)交互。

基于 MCP 的兩個本質——系統(tǒng)提示詞和 MCP Server 與 LLM 之間的協(xié)同關系，我們可以深入剖析這個新架構。

3.1.1、MCP Register（MCP Server 注冊中心）

在 MCP Server 和 MCP 提示詞的統(tǒng)一管理方面，借鑒了微服務領域中 Nacos 的服務注冊發(fā)現(xiàn)和配置統(tǒng)一管理的模式，并將其應用于 MCP 范式。以下是這些概念之間的對應關系：

• SpringCloud 服務/Dubbo 服務/Go 服務 → 各類 MCP Server
• SpringCloud 服務/Dubbo 服務/Go 服務暴露的接口 → 各類 MCP Server 提供的 MCP Tool
• SpringCloud 服務/Dubbo 服務/Go 服務暴露的接口描述 → 各類 MCP Server 提供的 MCP Tool 的描述
• SpringCloud 服務/Dubbo 服務/Go 服務的配置文件 → 各類 MCP Server 的系統(tǒng)提示詞

基于這些對應關系，在 Nacos 產(chǎn)品中實現(xiàn)了一系列增強 MCP 的能力。通過這些增強，Nacos 成為了統(tǒng)一管理 MCP Server 的 MCP Register（MCP Server 注冊/配置中心），成為 AI 應用開發(fā)新范式的核心組件。

第一、MCP Server 統(tǒng)一管理

MCP Server 注冊到 Nacos 有兩種方式：

• 手動創(chuàng)建：在 Nacos 控制臺手動創(chuàng)建，將 MCP Server 的 Endpoint 配置到 Nacos 中。
• 自動注冊：通過 Nacos SDK 自動將 MCP Server 注冊到 Nacos，邏輯與當前 Java SpringCloud、Java Dubbo 服務類似。

在 Nacos 中對 MCP Server 進行統(tǒng)一管理，可以實現(xiàn)以下功能：

• 健康檢查：監(jiān)控 MCP Server 的健康狀態(tài)。
• 負載均衡：合理分配流量，提高系統(tǒng)穩(wěn)定性。
• 描述信息轉換：支持從 JSON 到 XML 的格式轉換。
• 上下線管控：靈活控制 MCP Server 的上線和下線。

第二、MCP Prompt 統(tǒng)一管理

在 Nacos 中維護 MCP Server 的 Prompt 有兩種方式：

• 手動創(chuàng)建：手動創(chuàng)建 MCP Server 的配置信息，配置文件的 Data ID 命名格式為 [MCP Server name]-mcp-tools.json。在配置文件中管理 MCP Tool 的提示詞信息，比如：整體作用描述、入?yún)⒚枋龅取?/li>
• 自動感知：結合治理能力，如果是Java或Go語言，可以自動感知服務的 Schema，自動生成 MCP Server 和 MCP Tool 的提示詞信息。

通過 Nacos 對 MCP Server 提示詞進行統(tǒng)一管理，可以實現(xiàn)以下功能：

• 版本管理：支持版本回滾，確保系統(tǒng)穩(wěn)定運行。
• 灰度管理：支持灰度發(fā)布，逐步推廣新版本。
• 安全管理：確保提示詞的安全性，防止被污染或篡改。
• 動態(tài)調優(yōu)：支持動態(tài)調整提示詞，實時生效，提高系統(tǒng)靈活性。

第三、MCP 效果驗證體系

當 MCP Server 數(shù)量較多時，描述信息會變得復雜，導致 Prompt 過長，消耗大量 Token，降低 LLM 推理效率。因此，需要一種機制基于用戶輸入縮小 MCP Server 范圍，減少 Token 消耗，提高推理效率。此外，提示詞的好壞需要多次調試，MCP 流程強依賴提示詞工程。如果提示詞調整不當，LLM 無法返回準確的 MCP Server 和 MCP Tool，整個流程將無法使用。

在 Nacos 中，構建一個 MCP 效果驗證體系。核心原理是提供一個基于 Spring AI Alibaba 開發(fā)的 AI Agent，通過用戶配置的業(yè)務輸入、LLM、圈定的 MCP Server 和 MCP Tool 集合進行驗證，并將結果以視圖形式展示（如成功率等）。用戶可以在 Nacos 中動態(tài)調整成功率低的 MCP Server 的提示詞，進行優(yōu)化。

第四、MCP 安全性保障

在企業(yè)生產(chǎn)中，安全性始終是第一位的，MCP 領域也不例外。需要考慮的環(huán)節(jié)更多，包括：

敏感信息安全管理：注冊到 Nacos 的 MCP Server 可能包含 API Key、AK/SK、密鑰、登錄密碼等敏感信息。Nacos 與阿里云 KMS 深度集成，對這些敏感信息進行加密處理。

Prompt 安全管理：同樣依托于 Nacos 與 KMS 的深度集成，對 MCP Server 和 MCP Tool 的完整 Prompt（描述信息）進行加密處理，防止 Prompt 被污染。

Prompt 安全校驗：結合驗證體系和內容安全集成，實現(xiàn) Nacos 對 MCP Server Prompt 的合法性校驗，確保系統(tǒng)安全運行。

通過以上措施，Nacos 不僅實現(xiàn)了 MCP Server 和 MCP Prompt 的統(tǒng)一管理，還構建了效果驗證體系和安全保障體系，為 AI 應用開發(fā)提供了高效、靈活、安全的開發(fā)環(huán)境。

3.1.2、如何解決 MCP Client 與 MCP Server 之間協(xié)同關系的挑戰(zhàn)

在 MCP 范式中，主要涉及三個角色之間的協(xié)同工作：

• MCP Client：與 LLM 交互，發(fā)起請求并接收響應。
• LLM：處理 MCP Client 的請求，推理并選擇合適的 MCP Server 和 MCP Tool。
• MCP Server：提供具體的工具和功能，執(zhí)行實際的任務。

MCP Client 與 LLM 以及 MCP Client 與 MCP Server 之間的協(xié)同關系，本質上是服務提供方與服務消費方之間的關系。這涉及到兩個核心點：代理協(xié)作和流量管控。在傳統(tǒng)的開發(fā)范式中，這些功能通常由網(wǎng)關來負責。因此，我們在云原生 API 網(wǎng)關中增強了 LLM 代理和 MCP Server 代理的能力，使其具備了流量網(wǎng)關、AI 網(wǎng)關（LLM 代理）和 MCP 網(wǎng)關的功能。這使得云原生 API 網(wǎng)關成為 AI 應用開發(fā)新范式的核心組件。

在企業(yè)的整體系統(tǒng)架構中，通過使用云原生 API 網(wǎng)關，可以實現(xiàn)流量網(wǎng)關、API 網(wǎng)關、微服務網(wǎng)關、AI 網(wǎng)關和 MCP 網(wǎng)關的功能。這不僅在代理和流量管控層面實現(xiàn)了傳統(tǒng)業(yè)務和 AI 業(yè)務的統(tǒng)一，還通過結合 AI 應用開發(fā)的新范式，平滑地將 AI 業(yè)務與傳統(tǒng)業(yè)務相結合。這種整合方式極大地簡化了企業(yè)的技術棧，提高了系統(tǒng)的靈活性和可維護性，同時也降低了開發(fā)和運維的復雜性。

第一、云原生 API 網(wǎng)關

云原生 API 網(wǎng)關在業(yè)界得到了廣泛應用，眾多業(yè)務深度依賴其強大的企業(yè)級產(chǎn)品能力、穩(wěn)定性和性能。因此云原生 API 網(wǎng)關的可靠性和高效性就變得極其重要。

第二、AI 網(wǎng)關

MCP Client 與 LLM 之間的交互，以及傳統(tǒng)業(yè)務與 LLM 之間的交互，本質上都面臨一系列共性問題。這些問題在應用生產(chǎn)環(huán)境中尤為突出，具體如下：

• 成本平衡問題：部署大語言模型（比如：DeepSeek R1 671B 滿血版）需要高昂的成本，至少需要2臺8卡 H20 機器，年度費用超過100萬元，且其 TPS 有限，難以滿足多用戶并發(fā)請求。即使是 Meta 新發(fā)布的 Llama4，也需要至少一張 H100 顯卡來運行。因此，需要找到 TPS 與成本之間的平衡點。
• 模型幻覺問題：即使是性能強大的 DeepSeek R1 671B 滿血版模型，在沒有聯(lián)網(wǎng)搜索的情況下，也會出現(xiàn)嚴重的幻覺問題。
• 多模型切換問題：單一模型服務存在較大風險和局限性，比如：穩(wěn)定性風險，以及無法根據(jù)不同業(yè)務（消費者）需求選擇最優(yōu)模型。目前缺乏開源組件和框架來解決這類問題。
• 安全合規(guī)問題：企業(yè)客戶需要對問答過程進行審計，以確保合規(guī)并降低使用風險。
• 模型服務高可用問題：當自建平臺性能達到瓶頸時，需要一個大模型兜底方案，以提升客戶對大模型的使用體驗。
• 閉源模型 QPS/Token 限制問題：商業(yè)大模型通?；?API Key 維度設置 QPS/Token 配額限制，需要一種有效方式快速擴展配額限制。

這些問題都是客戶在實際使用過程中遇到的，有些源于大模型自身特性，有些則是部署架構導致。如果讓客戶逐一解決這些問題，不僅復雜度高，而且時間成本也很大。因此，需要 AI 網(wǎng)關的介入，以快速、統(tǒng)一地解決這些核心問題。

云原生 API 網(wǎng)關的 AI 網(wǎng)關增強能力主要體現(xiàn)在以下四個方面：

• 多模型適配：能夠代理市面上所有主流的模型托管服務，以及兼容 OpenAI 協(xié)議的 AI 服務。該模塊包括協(xié)議轉換、多 API Key 管理、Fallback、多模型切換等多個核心功能。
• AI 安全防護：安全防護涵蓋三個層面：輸入輸出的內容安全防護、保護下游 LLM 服務的穩(wěn)定，以及管控 AI 接口消費者。該模塊包括內容審核、基于 Token 的限流降級、消費者認證等多個核心功能。
• AI 插件：AI 網(wǎng)關的靈活擴展機制通過插件形式實現(xiàn)，目前提供許多預置插件，用戶也可以開發(fā)自定義插件來豐富 AI 場景流量的管控。比如：基于 AI 插件機制實現(xiàn)了結果緩存、提示詞裝飾器、向量檢索等能力。
• AI 可觀測：AI 場景的可觀測性與傳統(tǒng)場景有很大區(qū)別，監(jiān)控和關注的指標也不同。云原生 AI 網(wǎng)關結合阿里云日志服務和可觀測產(chǎn)品，實現(xiàn)了貼合 AI 應用業(yè)務語義的可觀測模塊和 AI 觀測大盤，支持 Tokens 消費觀測、流式/非流式的 RT、首包 RT、緩存命中等可觀指標。同時，所有輸入輸出 Tokens 都記錄在日志服務 SLS中，可供用戶進行更詳細的分析。

第三、MCP 網(wǎng)關

在 MCP 范式下，MCP Client 與 MCP Server 之間的交互模式與傳統(tǒng)的服務提供者和服務消費者模式有所不同。為了更好地支持這種交互模式，在云原生 API 網(wǎng)關中增加了 MCP 相關的能力。盡管從產(chǎn)品版本劃分層面，這些能力仍然屬于 AI 網(wǎng)關的范疇，但它們專門針對 MCP 場景進行了優(yōu)化。

1. MCP Server 動態(tài)發(fā)現(xiàn)

在前面的內容中，提到 Nacos 作為 MCP Server 的注冊和配置中心。那么，MCP Client 如何發(fā)現(xiàn)這些注冊的 MCP Server 呢？如果讓 MCP Client 直接與 Nacos 交互，就需要在 MCP Client 中引入 Nacos SDK，這無疑會增加編碼的復雜度。

鑒于云原生 API 網(wǎng)關和 Nacos 在傳統(tǒng)服務領域已經(jīng)實現(xiàn)了深度集成，能夠自動發(fā)現(xiàn)注冊在 Nacos 中的服務，我們在 MCP 范式下也實現(xiàn)了云原生 API 網(wǎng)關自動發(fā)現(xiàn)注冊在 Nacos 中的 MCP Server 的能力。

通過這種方式，MCP Client 只需使用云原生 API 網(wǎng)關的接入點，即可自動、動態(tài)地獲取所有注冊在 Nacos 中的 MCP Server。云原生 API 網(wǎng)關（MCP 網(wǎng)關）變成了一個 MCP Hub，無論 MCP Server 如何更新或變更，只需在 Nacos 中操作即可，MCP Client 無需做任何修改。

2. 傳統(tǒng)服務零代碼改造為 MCP Server

在 AI 時代，最有價值的是使用 AI 增強和提升客戶的現(xiàn)有業(yè)務，而不是完全重新開發(fā)一套 AI 應用。因此，在開發(fā) AI 應用或進行現(xiàn)有業(yè)務的 AI 增強時，AI Agent 需要與大量現(xiàn)有業(yè)務進行交互。雖然 MCP 提供了統(tǒng)一的協(xié)議，但將現(xiàn)有業(yè)務重構為 MCP Server 的成本非常高，且目前支持的開發(fā)語言有限，像 Go 和 PHP 都沒有對應的 MCP SDK。這使得許多企業(yè)雖然想擁抱 MCP，但卻無從下手。

網(wǎng)關最擅長的是協(xié)議轉換。Nacos 在傳統(tǒng)微服務場景下已經(jīng)注冊了許多現(xiàn)有服務，因此我們將兩者結合起來，通過網(wǎng)關將注冊在 Nacos 中的現(xiàn)有服務零代碼改造為 MCP Server。

注冊在 Nacos 中的現(xiàn)有業(yè)務服務（比如；SpringCloud 服務、Dubbo 服務、Go 服務）無需做任何改變。

在 Nacos 中新增 [Server Name]-mcp-tools.json 命名規(guī)范的配置文件，在配置文件中使用 MCP 規(guī)范對現(xiàn)有業(yè)務的接口進行描述。

通過云原生 API 網(wǎng)關（MCP 網(wǎng)關），MCP Client 側自動發(fā)現(xiàn)由傳統(tǒng)服務轉換而來的 MCP Server。

3. 將 SSE 轉換為 Streamable HTTP

MCP 范式默認的傳輸協(xié)議是 SSE（Server Sent Event），本質上是一種長連接、有狀態(tài)的傳輸協(xié)議。這種協(xié)議在企業(yè)級應用中存在許多弊端：

• 不支持可恢復性（Resumability）：連接斷開后，客戶端必須重新開始整個會話。
• 服務器需要維持長期連接（High Availability Requirement）：服務器必須保持高可用性，以支持持續(xù)的 SSE 連接。
• SSE 僅支持服務器→客戶端消息，無法靈活進行雙向通信。
• 目前只有少數(shù)幾個C/S架構的客戶端和 MCP 提供的用于測試驗證的 Web 客戶端支持 MCP 范式和 SSE 協(xié)議，無法應用于企業(yè)級的生產(chǎn)應用中。

幸運的是，MCP官方也意識到了這個問題，并在3月下旬發(fā)布了新的 Streamable HTTP 協(xié)議。Streamable HTTP 改變了 MCP 的數(shù)據(jù)傳輸方式，使協(xié)議更加靈活、易用和兼容：

• 更靈活：支持流式傳輸，但不強制。
• 更易用：支持無狀態(tài)服務器。
• 更兼容：適用于標準 HTTP 基礎設施。

簡單來說，原來的 MCP 傳輸方式就像你和客服通話時必須一直保持在線（SSE 需要長連接），而新的方式就像你隨時可以發(fā)消息，然后等待回復（普通 HTTP 請求，但可以流式傳輸）。

這里可以思考一下：

• Streamable HTTP 打破了目前幾個 C 端 MCP Client 的壁壘，意味著任何請求方（甚至是一段簡單的 HTTP Request 代碼）都可以像請求標準 HTTP API 一樣與 MCP Server 交互。
• 換句話說，當可以使用標準 HTTP API 的方式與 MCP Server 交互時，所謂的 MCP Client 可能就不存在了。

盡管 Streamable HTTP 仍在草案階段，但云原生 API 網(wǎng)關作為 MCP 網(wǎng)關已經(jīng)支持將 SSE 傳輸協(xié)議自動轉換為 Streamable HTTP 傳輸協(xié)議。也就是說，通過云原生 API 網(wǎng)關（MCP 網(wǎng)關）代理的 MCP Server 同時支持 SSE 和 Streamable HTTP 兩種傳輸協(xié)議供 Client 使用。

4. MCP 模式下的身份認證和權限管控

身份認證和權限管控在任何架構和業(yè)務場景下都是剛需，MCP 范式也不例外。這里有兩個層面的權限管控：

• Client 有權使用哪些 MCP Server：Client 有權使用哪些 MCP Server，以及有權使用某 MCP Server 中的哪些 MCP Tool。
• Client 通過 MCP Tool 有權獲取哪些數(shù)據(jù)：當 MCP Server 是數(shù)據(jù)類服務時，權限會下探到庫級別、表級別。

5. MCP Server 和 MCP Tool 的使用權限

當傳統(tǒng)業(yè)務可以零代碼轉換為 MCP Server 后，注冊在 Nacos 中的 MCP Server 和 MCP Tool 肯定會有很多。從業(yè)務領域來說，可能有與財務相關的 MCP Server、與銷售相關的 MCP Server、與售后服務相關的 MCP Server等。在返回 MCP Server 和 MCP Tool 信息時，不可能將所有信息都返回，只能返回 Client 身份有權使用的 MCP Server 信息。

云原生 API 網(wǎng)關作為 MCP 網(wǎng)關，通過成熟的插件機制提供了 HTTP Basic Auth、OAuth2.0、JWT、API Key、外部認證等多種認證方式，以及基于消費者認證功能，讓用戶可以靈活地管理和控制 Client 的身份認證和 MCP Server/MCP Tool 的使用權限。

6. MCP Server 和 MCP Tool 的數(shù)據(jù)權限

當 MCP Server 是數(shù)據(jù)類服務時，權限會下探到庫級別、表級別。在這種場景下，云原生 API 網(wǎng)關作為 MCP 網(wǎng)關，可以通過插件機制改寫或增加 Request Header 的值，結合治理將 Header 的值透傳下去，然后在服務內部進一步做數(shù)據(jù)權限管控。

比如：通過這種方式可以實現(xiàn)如下圖的數(shù)據(jù)庫讀寫分離的場景。

3.1.3、如何快速構建  MCP Server

在 AI 應用中，涉及 LLM 推理的場景通常調用頻率較低，屬于稀疏調用場景。由于 MCP 范式強依賴 LLM 推理，無論是基于 HTTP API 的傳統(tǒng) AI 應用開發(fā)架構，還是基于 MCP 的新架構，目前都主要應用于這些稀疏調用場景。這引發(fā)了兩個關鍵問題：

• 在稀疏調用場景下，如何優(yōu)化運行 MCP Server 的計算資源利用率，實現(xiàn)成本最優(yōu)？
• 在新的業(yè)務中，如何快速構建 MCP Server？

在所有計算產(chǎn)品中，函數(shù)計算（FC）這種 Serverless FaaS 類型的計算產(chǎn)品，在資源粒度、彈性策略、彈性效率方面最適合稀疏調用場景。

第一、函數(shù)計算（FC）支持 MCP 運行環(huán)境

阿里云函數(shù)計算（FC）目前支持 Python 和 NodeJS 兩種語言的 MCP 運行環(huán)境（其他語言的 MCP 運行環(huán)境也將很快支持）。用戶選擇 MCP 運行環(huán)境創(chuàng)建函數(shù)后，只需編寫 MCP Tool 的業(yè)務邏輯，無需考慮如何使用 MCP SDK。此外，云原生 API 網(wǎng)關與函數(shù)計算（FC）深度集成，天然適配 AI 應用開發(fā)的新范式。

第二、MCP Server 的彈性效率

基于函數(shù)計算（FC）構建的 MCP Server 在彈性效率方面有顯著優(yōu)勢，主要體現(xiàn)在兩個維度：

1、資源規(guī)格細粒度管控

函數(shù)計算（FC）提供從 0.05C 128MB 到 16C 32GB 的多種實例規(guī)格，用戶可以根據(jù)不同 MCP Server 承載的業(yè)務靈活選擇合適的資源規(guī)格。在 AI 應用中，尤其是流程式構建的模式中，大多數(shù) AI Agent 的職責單一，計算邏輯簡單，因此可以用較小資源規(guī)格的函數(shù)承載。較小的資源規(guī)格在資源調度和彈性效率方面具有天然優(yōu)勢。

2、完全按請求彈性

函數(shù)計算（FC）的彈性機制完全基于請求，根據(jù) QPS 自動拉起對應數(shù)量的實例，且實例可以復用。當 QPS 下降時，空閑實例會自動釋放，整個過程無需用戶介入。此外，用戶還可以設置按時間定時彈性或按指標閾值彈性策略，進一步滿足復雜多變的業(yè)務場景，實現(xiàn)資源成本最優(yōu)。

第三、MCP Server 的可觀測性

函數(shù)計算（FC）具備完善的可觀測體系，這意味著基于函數(shù)計算（FC）構建的 MCP Server 同樣具備指標、鏈路、日志三個維度的可觀測能力。通過這套可觀測體系，用戶可以清晰地了解每個 MCP Server 的各類運行狀態(tài)，從而更好地管理和優(yōu)化 MCP Server 的性能和成本。

通過函數(shù)計算（FC）的這些特性，企業(yè)可以高效地構建和管理 MCP Server，優(yōu)化資源利用率，降低成本，同時快速響應業(yè)務需求，提升 AI 應用的開發(fā)和部署效率。

3.1.4、AI 應用可觀測體系

結合阿里云可觀測產(chǎn)品 ARMS 和鏈路追蹤 OpenTelemetry，我們構建了覆蓋 AI 應用全環(huán)節(jié)的可觀測體系。這一體系的構建主要圍繞兩個核心部分展開：數(shù)據(jù)采集和數(shù)據(jù)串聯(lián)與分析。

第一、觀測數(shù)據(jù)采集

數(shù)據(jù)采集的核心是覆蓋足夠廣泛的范圍，這主要體現(xiàn)在兩個層面：

1、編程語言和開發(fā)框架的支持

• 支持范圍廣：支持 AI 應用開發(fā)的主流編程語言，比如：Python、Java、Go，并且相比社區(qū)規(guī)范提供更加精細化的埋點和屬性。
• 框架支持：支持常見的 AI 框架和模型，包括 Spring AI Alibaba、LLamaIndex、Langchain、通義千問2、OpenAI、PromptFlow 等。

2、云產(chǎn)品數(shù)據(jù)上報

• 標準統(tǒng)一：AI 應用架構新范式中涉及的云產(chǎn)品需要以相同的標準上報數(shù)據(jù)。
• 網(wǎng)關支持：云原生 API 網(wǎng)關支持 OpenTelemetry 協(xié)議，網(wǎng)關自身和插件都會基于 OpenTelemetry 上報觀測數(shù)據(jù)。
• 深度集成：函數(shù)計算 FC 和 Serverless 應用引擎 SAE 均與應用監(jiān)控 ARMS 以及鏈路追蹤 OpenTelemetry 產(chǎn)品深度集成。

通過以上措施，我們實現(xiàn)了數(shù)據(jù)采集的全覆蓋，確保了可觀測體系的完整性。

第二、數(shù)據(jù)串聯(lián)與分析

在應用監(jiān)控 ARMS 中，專門構建了 LLM 應用監(jiān)控模塊，為 AI 應用場景提供了完善的可觀測體系。這一模塊從縱向和橫向兩個維度提供了豐富的監(jiān)控指標和分析功能。

1、縱向指標

• 在線 AI 應用數(shù)
• Trace 數(shù)
• Span 數(shù)
• 大模型數(shù)
• Token 使用情況
• 會話數(shù)
• 用戶數(shù)
• 模型調用次數(shù)
• Token 消耗情況
• 模型調用耗時
• Token 消耗排行

2、橫向鏈路分析

• Span 列表：展示每個 Span 的詳細信息。
• Trace 列表：提供完整的 Trace 記錄。
• 散點圖：通過散點圖分析性能分布。
• 全鏈路聚合：對整個調用鏈進行聚合分析。
• 全鏈路拓撲：展示調用鏈的拓撲結構。
• 錯/慢 Trace 分析：分析錯誤和慢 Trace 的原因。
• 調用鏈展示：在調用鏈的每個環(huán)節(jié)展示輸入、輸出和 Token 消耗情況。

通過這些功能，用戶可以清晰地了解 AI 應用的運行狀態(tài)，快速定位問題，優(yōu)化性能，確保 AI 應用的穩(wěn)定運行。

四、AI 應用架構設計新范式對企業(yè)的影響

隨著企業(yè)級 AI 應用架構新范式的逐步成熟，企業(yè)的運營、產(chǎn)品、研發(fā)、運維團隊之間的組織結構和協(xié)作關系，以及應用或系統(tǒng)的開發(fā)模式，都將迎來一系列變革。以下是我的一些暢想：

第一、MCP Server First 理念的興起

API First 與前后端分離：API First 和前后端分離的概念在海外企業(yè)中得到了較好的實踐，但在國內的應用相對較少。這可能是因為國內企業(yè)面臨著較重的歷史包袱，難以快速轉型。

Serverless 架構的實踐：在 Serverless 計算領域，AWS Lambda、Azure Functions、Azure App Service、GCP CloudFunction 和 GCP CloudRun 等架構方案已被廣泛研究和應用。然而，在國內，除了高德等少數(shù)企業(yè)通過函數(shù)計算重構系統(tǒng)實現(xiàn)了 API First 和前后端分離模式外，大多數(shù)企業(yè)仍處于探索階段。

第二、AI 應用時代的變革

API 調用的本質：在 AI 應用時代，盡管本質上依然是對各種 API 的調用，但將 HTTP API 改為 REST API 的改造成本巨大。MCP 的出現(xiàn)為這一問題提供了新的解決方案，使得企業(yè)能夠以0代碼的方式快速轉型到 AI 應用架構新范式。

MCP Server First 的可能性：MCP Server First 理念的提出，意味著企業(yè)可以將更多的精力放在構建和維護 MCP Server 上，而無需過多關注統(tǒng)一返回格式和開發(fā)語言的統(tǒng)一。

第三、團隊角色的重新定義

運維團隊：負責云產(chǎn)品的維護（比如：云原生 API 網(wǎng)關、Nacos、Serverless 應用引擎、PAI 等產(chǎn)品的開通和升配），以及可觀測體系的維護。運維團隊還將與云廠商保持持續(xù)溝通，確保系統(tǒng)的穩(wěn)定運行。

研發(fā)團隊：專注于理解公司業(yè)務的原子化能力，負責構建 MCP Server 池。研發(fā)團隊將更加專注于后端服務的開發(fā)和優(yōu)化，而無需過多關注前端展示邏輯。

運營/市場/產(chǎn)品團隊：通過低代碼可視化方式構建業(yè)務流程（業(yè)務編排），用大白話描述業(yè)務需求，快速完成業(yè)務流程的搭建或 AI 應用的構建。這些團隊將更加專注于業(yè)務邏輯的梳理和需求的快速實現(xiàn)。

第四、未來展望

企業(yè)級 MCP Server市場：未來，每個企業(yè)都可能擁有自己的 MCP Server 市場。在這個市場中，MCP Server 將被分門別類，每類 MCP Server 由專門的研發(fā)團隊負責。這種模式將極大地提高開發(fā)效率，減少重復工作。

業(yè)務需求的快速實現(xiàn)：當運營、市場、產(chǎn)品等業(yè)務方有新的業(yè)務需求或產(chǎn)品功能需求時，可以通過統(tǒng)一界面快速構建 AI 應用。MCP 和 LLM 的結合將實現(xiàn)業(yè)務編排，推動“PRD 即產(chǎn)品”（PRD as a Product）的新開發(fā)模式。

第五、總結

企業(yè)級 AI 應用架構新范式的出現(xiàn)，不僅為企業(yè)的技術轉型提供了新的思路，也為團隊協(xié)作和開發(fā)模式帶來了新的變革。通過 MCP Server First 理念的實踐，企業(yè)可以更加高效地構建和維護 AI 應用，提升整體運營效率。未來，隨著技術的不斷發(fā)展和成熟，企業(yè)級 AI 應用架構將更加靈活、高效和智能。

本文轉載自??玄姐聊AGI??  作者：玄姐