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

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

下面詳細(xì)介紹之。

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

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

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

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

第一、尋找合適的接口

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

第二、解析接口返回格式

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

第三、編排多個(gè) AI Agent

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

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

為了使 AI Agent 進(jìn)入第二階段（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)級(jí)問題，比如：多模型切換、模型 Fallback、多 API Key 管理、安全和聯(lián)網(wǎng)搜索等。

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

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

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

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

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)用，而無需為每個(gè) AI 模型和外部系統(tǒng)組合進(jìn)行定制集成。

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

MCP 包含三個(gè)核心概念：

第一、MCP Server

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

第二、MCP Tool

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

第二、MCP Client

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

2、MCP 的運(yùn)作機(jī)制

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

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

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

第一、用戶提問

• 用戶向 AI Agent 提問“現(xiàn)在幾點(diǎn)了？”。此時(shí)，AI Agent 作為 MCP Client，將用戶問題連同處理時(shí)間的 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)前時(shí)間。

第四、返回結(jié)果

• time MCP Server 將當(dāng)前時(shí)間的結(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é)果原封不動(dòng)地返回給用戶。

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

上圖告訴 LLM：

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

上圖告訴 LLM：

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

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

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

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

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

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

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

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

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

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

    第三、LLM 結(jié)合用戶問題和接口返回的結(jié)果，進(jìn)行內(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 需要為每個(gè)外部函數(shù)編寫一個(gè) JSON Schema 格式的功能說明，并精心設(shè)計(jì)一個(gè)提示詞模板，才能提高 Function Calling 響應(yīng)的準(zhǔn)確率。如果一個(gè)需求涉及幾十個(gè)外部系統(tǒng)，那么設(shè)計(jì)成本將是巨大的，產(chǎn)品化成本極高。

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

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

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

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

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

• 系統(tǒng)提示詞的安全性：系統(tǒng)提示詞是 MCP 的核心，如果被污染，LLM 可能會(huì)被誤導(dǎo)，選擇錯(cuò)誤甚至存在安全漏洞的 MCP Server 和 MCP Tool，從而導(dǎo)致整個(gè) MCP 流程癱瘓，給 AI 應(yīng)用帶來巨大風(fēng)險(xiǎn)。
• 系統(tǒng)提示詞的管理：當(dāng) MCP Server 或 MCP Tool 更新時(shí)，系統(tǒng)提示詞也需要相應(yīng)地進(jìn)行版本管理，以確保 LLM 能夠獲取最新的工具信息。
• 系統(tǒng)提示詞的調(diào)試與實(shí)時(shí)生效：系統(tǒng)提示詞沒有標(biāo)準(zhǔn)定義，每個(gè)企業(yè)都可以自定義模板。由于提示詞需要反復(fù)調(diào)試，因此需要一種機(jī)制能夠快速調(diào)整并實(shí)時(shí)生效。
• 系統(tǒng)提示詞的 Token 消耗：如果 MCP Server 和 MCP Tool 數(shù)量眾多，系統(tǒng)提示詞會(huì)變得非常長，消耗大量 Token，增加成本。因此，需要一種機(jī)制基于用戶問題預(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è)級(jí) 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)實(shí)。
• MCP Server 的統(tǒng)一管理：企業(yè)可能擁有自建的 MCP Server、第三方的 MCP Server 以及通過某種機(jī)制轉(zhuǎn)換而來的 MCP Server。需要一個(gè)類似 MCP Hub 或 MCP 市場的平臺(tái)來統(tǒng)一管理這些 Server，方便 MCP Client 使用。
• 企業(yè)級(jí)應(yīng)用中的安全與權(quán)限問題：在企業(yè)級(jí)應(yīng)用中，身份認(rèn)證、數(shù)據(jù)權(quán)限和安全防護(hù)是關(guān)鍵問題。在 MCP 的協(xié)同模式下，如何實(shí)現(xiàn)這些功能是亟待解決的挑戰(zhàn)。

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

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

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

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

通過這些增強(qiáng)能力的實(shí)現(xiàn)，解決了 MCP 在企業(yè)級(jí)應(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)的新范式。

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

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

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

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

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

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

第四步 LLM 交互（可選）：MCP 網(wǎng)關(guān)可能維護(hù)大量 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)過推理，返回解決問題的一個(gè)或多個(gè) MCP Server 和 MCP Tool 信息。

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

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

基于 MCP 的兩個(gè)本質(zhì)——系統(tǒng)提示詞和 MCP Server 與 LLM 之間的協(xié)同關(guān)系，我們可以深入剖析這個(gè)新架構(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)品中實(shí)現(xiàn)了一系列增強(qiáng) MCP 的能力。通過這些增強(qiáng)，Nacos 成為了統(tǒng)一管理 MCP Server 的 MCP Register（MCP Server 注冊/配置中心），成為 AI 應(yīng)用開發(fā)新范式的核心組件。

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

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

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

在 Nacos 中對 MCP Server 進(jìn)行統(tǒng)一管理，可以實(shí)現(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 中維護(hù) MCP Server 的 Prompt 有兩種方式：

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

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

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

第三、MCP 效果驗(yàn)證體系

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

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

第四、MCP 安全性保障

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

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

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

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

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

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

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

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

MCP Client 與 LLM 以及 MCP Client 與 MCP Server 之間的協(xié)同關(guān)系，本質(zhì)上是服務(wù)提供方與服務(wù)消費(fèi)方之間的關(guān)系。這涉及到兩個(gè)核心點(diǎn)：代理協(xié)作和流量管控。在傳統(tǒng)的開發(fā)范式中，這些功能通常由網(wǎng)關(guān)來負(fù)責(zé)。因此，我們在云原生 API 網(wǎng)關(guān)中增強(qiáng)了 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)，可以實(shí)現(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)的功能。這不僅在代理和流量管控層面實(shí)現(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)的靈活性和可維護(hù)性，同時(shí)也降低了開發(fā)和運(yùn)維的復(fù)雜性。

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

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

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

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

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

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

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

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

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

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

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

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

在 AI 時(shí)代，最有價(jià)值的是使用 AI 增強(qiáng)和提升客戶的現(xiàn)有業(yè)務(wù)，而不是完全重新開發(fā)一套 AI 應(yīng)用。因此，在開發(fā) AI 應(yīng)用或進(jìn)行現(xiàn)有業(yè)務(wù)的 AI 增強(qiáng)時(shí)，AI Agent 需要與大量現(xiàn)有業(yè)務(wù)進(jìn)行交互。雖然 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ù)的接口進(jìn)行描述。

通過云原生 API 網(wǎng)關(guān)（MCP 網(wǎng)關(guān)），MCP Client 側(cè)自動(dòng)發(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è)級(jí)應(yīng)用中存在許多弊端：

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

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

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

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

這里可以思考一下：

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

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

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

身份認(rèn)證和權(quán)限管控在任何架構(gòu)和業(yè)務(wù)場景下都是剛需，MCP 范式也不例外。這里有兩個(gè)層面的權(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ù)時(shí)，權(quán)限會(huì)下探到庫級(jí)別、表級(jí)別。

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

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

云原生 API 網(wǎng)關(guān)作為 MCP 網(wǎng)關(guān)，通過成熟的插件機(jī)制提供了 HTTP Basic Auth、OAuth2.0、JWT、API Key、外部認(rèn)證等多種認(rèn)證方式，以及基于消費(fèi)者認(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ù)時(shí)，權(quán)限會(huì)下探到庫級(jí)別、表級(jí)別。在這種場景下，云原生 API 網(wǎng)關(guān)作為 MCP 網(wǎng)關(guān)，可以通過插件機(jī)制改寫或增加 Request Header 的值，結(jié)合治理將 Header 的值透傳下去，然后在服務(wù)內(nèi)部進(jìn)一步做數(shù)據(jù)權(quán)限管控。

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

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

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

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

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

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

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

第二、MCP Server 的彈性效率

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

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

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

2、完全按請求彈性

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

第三、MCP Server 的可觀測性

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

通過函數(shù)計(jì)算（FC）的這些特性，企業(yè)可以高效地構(gòu)建和管理 MCP Server，優(yōu)化資源利用率，降低成本，同時(shí)快速響應(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)建主要圍繞兩個(gè)核心部分展開：數(shù)據(jù)采集和數(shù)據(jù)串聯(lián)與分析。

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

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

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

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

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

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

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

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

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

1、縱向指標(biāo)

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

2、橫向鏈路分析

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

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

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

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

第一、MCP Server First 理念的興起

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

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

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

API 調(diào)用的本質(zhì)：在 AI 應(yīng)用時(shí)代，盡管本質(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)建和維護(hù) MCP Server 上，而無需過多關(guān)注統(tǒng)一返回格式和開發(fā)語言的統(tǒng)一。

第三、團(tuán)隊(duì)角色的重新定義

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

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

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

第四、未來展望

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

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

第五、總結(jié)

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

本文轉(zhuǎn)載自??玄姐聊AGI??  作者：玄姐