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

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

第一、尋找合適的接口

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

第二、解析接口返回格式

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

第三、編排多個 AI Agent

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

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

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

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

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

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

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

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

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

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

二、MCP 架構(gòu)設(shè)計剖析

1、MCP 是什么？

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

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

MCP 包含三個核心概念：

第一、MCP Server

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

第二、MCP Tool

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

第二、MCP Client

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

2、MCP 的運作機制

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

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

基于 MCP 的調(diào)用過程分為六個核心步驟：

第一、用戶提問

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

第二、LLM 推理

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

第三、調(diào)用 MCP Tool

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

第四、返回結(jié)果

• time MCP Server 將當(dāng)前時間的結(jié)果返回給 AI Agent（MCP Client）。

第五、內(nèi)容規(guī)整

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

第六、最終反饋

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

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

3、MCP System Prompt

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

以下是一些關(guān)鍵的示例和步驟解析：

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

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

上圖告訴 LLM：

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

上圖告訴 LLM：

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

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

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

第三、流程第二步：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)地選擇和調(diào)用最適合的工具，從而實現(xiàn)靈活且高效的 AI 應(yīng)用開發(fā)。

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

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

第一、LLM 負(fù)責(zé)為 AI Agent 找到最合適的接口。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、AI 應(yīng)用架構(gòu)設(shè)計新范式

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

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

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

3.1、AI 應(yīng)用架構(gòu)新范式剖析

AI 應(yīng)用架構(gòu)結(jié)合 MCP，我們定義了 AI 應(yīng)用架構(gòu)的新范式。

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

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

以下是對圖中8步核心調(diào)用鏈路的解析：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 健康檢查：監(jiān)控 MCP Server 的健康狀態(tài)。
• 負(fù)載均衡：合理分配流量，提高系統(tǒng)穩(wěn)定性。
• 描述信息轉(zhuǎn)換：支持從 JSON 到 XML 的格式轉(zhuǎn)換。
• 上下線管控：靈活控制 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>
• 自動感知：結(jié)合治理能力，如果是Java或Go語言，可以自動感知服務(wù)的 Schema，自動生成 MCP Server 和 MCP Tool 的提示詞信息。

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

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

第三、MCP 效果驗證體系

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

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

第四、MCP 安全性保障

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

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

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

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

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

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

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

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

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

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

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

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

第二、AI 網(wǎng)關(guān)

MCP Client 與 LLM 之間的交互，以及傳統(tǒng)業(yè)務(wù)與 LLM 之間的交互，本質(zhì)上都面臨一系列共性問題。這些問題在應(yīng)用生產(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)嚴(yán)重的幻覺問題。
• 多模型切換問題：單一模型服務(wù)存在較大風(fēng)險和局限性，比如：穩(wěn)定性風(fēng)險，以及無法根據(jù)不同業(yè)務(wù)（消費者）需求選擇最優(yōu)模型。目前缺乏開源組件和框架來解決這類問題。
• 安全合規(guī)問題：企業(yè)客戶需要對問答過程進行審計，以確保合規(guī)并降低使用風(fēng)險。
• 模型服務(wù)高可用問題：當(dāng)自建平臺性能達(dá)到瓶頸時，需要一個大模型兜底方案，以提升客戶對大模型的使用體驗。
• 閉源模型 QPS/Token 限制問題：商業(yè)大模型通常基于 API Key 維度設(shè)置 QPS/Token 配額限制，需要一種有效方式快速擴展配額限制。

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

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

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

第三、MCP 網(wǎng)關(guān)

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

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

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

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

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

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

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

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

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

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

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

3. 將 SSE 轉(zhuǎn)換為 Streamable HTTP

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

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

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

• 更靈活：支持流式傳輸，但不強制。
• 更易用：支持無狀態(tài)服務(wù)器。
• 更兼容：適用于標(biāo)準(zhǔn) HTTP 基礎(chǔ)設(shè)施。

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

這里可以思考一下：

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

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

4. MCP 模式下的身份認(rèn)證和權(quán)限管控

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

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

5. MCP Server 和 MCP Tool 的使用權(quán)限

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

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

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

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

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

3.1.3、如何快速構(gòu)建 MCP Server

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

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

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

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

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

第二、MCP Server 的彈性效率

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

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

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

2、完全按請求彈性

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

第三、MCP Server 的可觀測性

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

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

3.1.4、AI 應(yīng)用可觀測體系

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

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

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

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

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

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

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

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

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

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

1、縱向指標(biāo)

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

2、橫向鏈路分析

• Span 列表：展示每個 Span 的詳細(xì)信息。
• Trace 列表：提供完整的 Trace 記錄。
• 散點圖：通過散點圖分析性能分布。
• 全鏈路聚合：對整個調(diào)用鏈進行聚合分析。
• 全鏈路拓?fù)洌赫故菊{(diào)用鏈的拓?fù)浣Y(jié)構(gòu)。
• 錯/慢 Trace 分析：分析錯誤和慢 Trace 的原因。
• 調(diào)用鏈展示：在調(diào)用鏈的每個環(huán)節(jié)展示輸入、輸出和 Token 消耗情況。

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

AI 應(yīng)用架構(gòu)設(shè)計新范式對企業(yè)的影響

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

第一、MCP Server First 理念的興起

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

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

第二、AI 應(yīng)用時代的變革

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

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

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

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

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

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

第四、未來展望

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

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

第五、總結(jié)

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

文章轉(zhuǎn)載自： 萬字長文深度剖析基于 MCP 實現(xiàn) AI 應(yīng)用架構(gòu)設(shè)計新范式的落地實踐

#你可能也喜歡這些API文章!

探索海洋數(shù)據(jù)的寶庫：Amentum海洋數(shù)據(jù)探測API的潛力

Jenkins API和Docker快速上手指南

HapiJS 身份驗證 : 使用 JWT 保護您的 API

使用 Axios 在 React 中創(chuàng)建集中式 API 客戶端文件

Cursor + Devbox 進階開發(fā)實踐：從 Hello World 到 One API

什么是聚類分析？

通過API監(jiān)控提高API穩(wěn)定性

使用 Whisper API 通過設(shè)備麥克風(fēng)把語音轉(zhuǎn)錄為文本

如何在 Apifox 中發(fā)布多語言的 API 文檔？