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

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

下面詳細介紹之。

一、AI Agent 現狀與架構

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

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

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

第一、尋找合適的接口

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

第二、解析接口返回格式

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

第三、編排多個 AI Agent

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

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

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

第一、作為南北向流量網關

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

第二、作為 AI 網關

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

第三、作為東西向網關

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

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

二、MCP 架構設計剖析

1、MCP 是什么？

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

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

MCP 包含三個核心概念：

第一、MCP Server

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

第二、MCP Tool

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

第二、MCP Client

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

2、MCP 的運作機制

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

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

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

第一、用戶提問

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

第二、LLM 推理

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

第三、調用 MCP Tool

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

第四、返回結果

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

第五、內容規整

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

第六、最終反饋

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

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

3、MCP System Prompt

MCP（模型上下文協議）與傳統協議定義不同，它并沒有固定的數據結構。其核心在于通過自然語言清晰地描述 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 做了詳細描 述。包括傳參格式。

第二、流程第一步：發送問題和 System Prompt

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

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

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

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

4、MCP 與 Function Calling 區別

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

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

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

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

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

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

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

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

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

5、MCP 的本質與挑戰

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

然而，將 MCP 引入企業級生產應用時，會面臨諸多挑戰：

第一、描述 MCP 信息的系統提示詞的挑戰

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

第二、MCP Client 與 MCP Server 之間協同關系的挑戰

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

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

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

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

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

通過這些增強能力的實現，解決了 MCP 在企業級應用中的關鍵挑戰。

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

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

一個云原生 API 網關三種角色，具備統一的管控底座，同時又實現各角色的協同調度。

Nacos 發揮注冊中心優勢，增加 MCP Server 的注冊能力，實現普通服務和 MCP Server 的統一管理，結合網關實現現存業務0改造轉換為 MCP Server。

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

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

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

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

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

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

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

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

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

在實際生產中，步驟3至8會多次循環交互。

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

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

在 MCP Server 和 MCP 提示詞的統一管理方面，借鑒了微服務領域中 Nacos 的服務注冊發現和配置統一管理的模式，并將其應用于 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 的系統提示詞

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

第一、MCP Server 統一管理

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

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

在 Nacos 中對 MCP Server 進行統一管理，可以實現以下功能：

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

第二、MCP Prompt 統一管理

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

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

通過 Nacos 對 MCP Server 提示詞進行統一管理，可以實現以下功能：

• 版本管理：支持版本回滾，確保系統穩定運行。
• 灰度管理：支持灰度發布，逐步推廣新版本。
• 安全管理：確保提示詞的安全性，防止被污染或篡改。
• 動態調優：支持動態調整提示詞，實時生效，提高系統靈活性。

第三、MCP 效果驗證體系

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

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

第四、MCP 安全性保障

在企業生產中，安全性始終是第一位的，MCP 領域也不例外。需要考慮的環節更多，包括：

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

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

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

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

3.1.2、如何解決 MCP Client 與 MCP Server 之間協同關系的挑戰

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

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

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

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

第一、云原生 API 網關

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

第二、AI 網關

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

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

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

云原生 API 網關的 AI 網關增強能力主要體現在以下四個方面：

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

第三、MCP 網關

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

1. MCP Server 動態發現

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

鑒于云原生 API 網關和 Nacos 在傳統服務領域已經實現了深度集成，能夠自動發現注冊在 Nacos 中的服務，我們在 MCP 范式下也實現了云原生 API 網關自動發現注冊在 Nacos 中的 MCP Server 的能力。

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

2. 傳統服務零代碼改造為 MCP Server

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

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

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

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

通過云原生 API 網關（MCP 網關），MCP Client 側自動發現由傳統服務轉換而來的 MCP Server。

3. 將 SSE 轉換為 Streamable HTTP

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

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

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

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

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

這里可以思考一下：

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

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

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

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

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

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

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

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

6. MCP Server 和 MCP Tool 的數據權限

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

比如：通過這種方式可以實現如下圖的數據庫讀寫分離的場景。

3.1.3、如何快速構建  MCP Server

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

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

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

第一、函數計算（FC）支持 MCP 運行環境

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

第二、MCP Server 的彈性效率

基于函數計算（FC）構建的 MCP Server 在彈性效率方面有顯著優勢，主要體現在兩個維度：

1、資源規格細粒度管控

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

2、完全按請求彈性

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

第三、MCP Server 的可觀測性

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

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

3.1.4、AI 應用可觀測體系

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

第一、觀測數據采集

數據采集的核心是覆蓋足夠廣泛的范圍，這主要體現在兩個層面：

1、編程語言和開發框架的支持

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

2、云產品數據上報

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

通過以上措施，我們實現了數據采集的全覆蓋，確保了可觀測體系的完整性。

第二、數據串聯與分析

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

1、縱向指標

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

2、橫向鏈路分析

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

通過這些功能，用戶可以清晰地了解 AI 應用的運行狀態，快速定位問題，優化性能，確保 AI 應用的穩定運行。

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

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

第一、MCP Server First 理念的興起

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

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

第二、AI 應用時代的變革

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

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

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

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

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

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

第四、未來展望

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

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

第五、總結

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

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