模型壓縮四劍客：量化、剪枝、蒸餾、二值化
目前 AI Agent 與各種 Tools（業務服務接口）、Memory（存儲服務接口）以及 LLMs（大語言模型）的交互主要通過 HTTP 協議實現。除了 LLMs 基本遵循 OpenAI 范式外，與其他 Tools 和 Memory 的交互需要逐一了解它們的返回格式進行解析和適配，這增加了開發的復雜性。
當一個 AI 應用包含多個 AI Agent，或者需要與多個業務服務接口和存儲服務接口交互時，開發工作量顯著增加，主要體現在以下三個方面：
第一、尋找合適的接口
第二、解析接口返回格式
第三、編排多個 AI Agent
因此，目前許多 AI應用只包含少數幾個 AI Agent，甚至很多應用背后只有一個 AI Agent。這也是目前 AI 應用背后的 AI Agent 仍處于第一階段（Siloed, Single-Purpose Agents）的原因。
為了使 AI Agent 進入第二階段（Platform-Level Agents），我們使用云原生 API 網關作為統一的接入層，通過網關的三種不同角色，解決了部分復雜度問題：
第一、作為南北向流量網關
第二、作為 AI 網關
第三、作為東西向網關
然而，上述方法僅解決了部分復雜度問題，更核心的尋找接口和解析接口的問題仍未得到解決。直到 MCP（Model Context Protocol）的出現，我們看到了真正通往第二階段（Platform-Level Agents）的道路，甚至有望觸及第三階段（Universal Agents, Multi-Agents）。
MCP（模型上下文協議，Model Context Protocol）是由Anthropic（Claude 的開發公司）開發的開源協議，旨在為大語言模型（LLM）提供一種標準化的方式，以便它們能夠連接到外部數據源和工具。它就像是 AI 應用的“通用接口”，幫助開發者構建更靈活、更具上下文感知能力的 AI 應用，而無需為每個 AI 模型和外部系統組合進行定制集成。
MCP 的設計理念類似于 USB-C 端口，允許 AI 應用以一致的方式連接到各種數據源和工具，如文件、數據庫、API 等。
MCP 包含三個核心概念：
第一、MCP Server
第二、MCP Tool
第二、MCP Client
要真正理解 MCP，我們需要深入其運作機制，這不僅能揭示 MCP 調用方式與傳統 HTTP 調用方式的差異，還能讓你明白為何 MCP 能夠助力 AI Agent 邁向第二階段。
以開發一個獲取時間的 AI Agent 為例，用戶只需提問“現在幾點了？”即可。假設我們已有一個處理時間的 MCP Server，其中包含兩個 MCP Tool：一個用于獲取當前時區，另一個用于獲取當前時間。
基于 MCP 的調用過程分為六個核心步驟：
第一、用戶提問
第二、LLM 推理
第三、調用 MCP Tool
第四、返回結果
第五、內容規整
第六、最終反饋
在整個 MCP 調用過程中，MCP Server 及 MCP Tool 的信息至關重要。從第一步和第二步可以看出，這些信息為 LLM 提供了解決問題的關鍵線索。這些信息本質上就是 MCP 中的 System Prompt，其核心作用是為 LLM 提供清晰的指導，幫助其更好地理解用戶需求并選擇合適的工具來解決問題。
MCP（模型上下文協議）與傳統協議定義不同，它并沒有固定的數據結構。其核心在于通過自然語言清晰地描述 MCP Serve r和 MCP Tool 的功能及作用，讓大語言模型（LLM）通過推理來選擇最合適的 MCP Server 和 MCP Tool。因此，MCP 的本質仍然是提示詞工程（Prompt Engineering）。
以下是一些關鍵的示例和步驟解析：
Cline 是一個 MCP Client，其 System Prompt 對 MCP Server 和 MCP Tool 都有明確的描述。比如：它會詳細說明每個 MCP Server 的功能以及其中包含的 MCP Tool 的作用。這種描述為 LLM 提供了足夠的上下文，使其能夠理解每個工具的用途。
上圖告訴 LLM：
上圖告訴 LLM：
在調用流程的第一步，用戶的問題（如“現在幾點了？”）和 System Prompt 一起被發送給 LLM。System Prompt 的作用是為 LLM 提供清晰的指導，幫助其理解用戶問題的背景和可用的工具。
在第二步，LLM 根據用戶問題和 System Prompt 中的信息，推理出最合適的 MCP Server 和 MCP Tool，并返回明確的解決方案。比如：LLM 可能會返回：“使用 time MCP Serve r中的 get_current_time MCP Tool 來解決用戶的問題。”并以 XML 格式 返回給 Client/Agent。
通過這種方式，MCP 利用自然語言描述和 LLM 的推理能力，動態地選擇和調用最適合的工具，從而實現靈活且高效的 AI 應用開發。
通過前面的介紹，相信大家對 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 可以加強全球開發者的協作，復用全球的開發成果，降低開發成本，提高開發效率。
通過前面的討論，我們可以總結 MCP（模型上下文協議）的本質：MCP 并非一個固定的數據格式或結構，而是系統提示詞與 MCP Server 和 LLM 之間協同關系的結合。它通過自然語言描述 MCP Server 和 MCP Tool 的功能，讓 LLM 能夠推理出最適合的工具來解決問題，從而解決了找接口和解析接口的問題。
然而，將 MCP 引入企業級生產應用時，會面臨諸多挑戰：
總之，盡管 MCP 為 AI 應用開發帶來了靈活性和效率提升，但在企業級應用中，仍需克服系統提示詞的安全性、管理、調試以及 MCP Client 與 MCP Server 之間的協同關系等多方面的挑戰。
為了解決 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 在企業級應用中的關鍵挑戰。
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 之間的協同關系，我們可以深入剖析這個新架構。
在 MCP Server 和 MCP 提示詞的統一管理方面，借鑒了微服務領域中 Nacos 的服務注冊發現和配置統一管理的模式，并將其應用于 MCP 范式。以下是這些概念之間的對應關系：
基于這些對應關系，在 Nacos 產品中實現了一系列增強 MCP 的能力。通過這些增強，Nacos 成為了統一管理 MCP Server 的 MCP Register（MCP Server 注冊/配置中心），成為 AI 應用開發新范式的核心組件。
第一、MCP Server 統一管理
MCP Server 注冊到 Nacos 有兩種方式：
在 Nacos 中對 MCP Server 進行統一管理，可以實現以下功能：
第二、MCP Prompt 統一管理
在 Nacos 中維護 MCP Server 的 Prompt 有兩種方式：
通過 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 應用開發提供了高效、靈活、安全的開發環境。
在 MCP 范式中，主要涉及三個角色之間的協同工作：
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 之間的交互，本質上都面臨一系列共性問題。這些問題在應用生產環境中尤為突出，具體如下：
這些問題都是客戶在實際使用過程中遇到的，有些源于大模型自身特性，有些則是部署架構導致。如果讓客戶逐一解決這些問題，不僅復雜度高，而且時間成本也很大。因此，需要 AI 網關的介入，以快速、統一地解決這些核心問題。
云原生 API 網關的 AI 網關增強能力主要體現在以下四個方面：
第三、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），本質上是一種長連接、有狀態的傳輸協議。這種協議在企業級應用中存在許多弊端：
幸運的是，MCP官方也意識到了這個問題，并在3月下旬發布了新的 Streamable HTTP 協議。Streamable HTTP 改變了 MCP 的數據傳輸方式，使協議更加靈活、易用和兼容：
簡單來說，原來的 MCP 傳輸方式就像你和客服通話時必須一直保持在線（SSE 需要長連接），而新的方式就像你隨時可以發消息，然后等待回復（普通 HTTP 請求，但可以流式傳輸）。
這里可以思考一下：
盡管 Streamable HTTP 仍在草案階段，但云原生 API 網關作為 MCP 網關已經支持將 SSE 傳輸協議自動轉換為 Streamable HTTP 傳輸協議。也就是說，通過云原生 API 網關（MCP 網關）代理的 MCP Server 同時支持 SSE 和 Streamable HTTP 兩種傳輸協議供 Client 使用。
4. MCP 模式下的身份認證和權限管控
身份認證和權限管控在任何架構和業務場景下都是剛需，MCP 范式也不例外。這里有兩個層面的權限管控：
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 的值透傳下去，然后在服務內部進一步做數據權限管控。
比如：通過這種方式可以實現如下圖的數據庫讀寫分離的場景。
在 AI 應用中，涉及 LLM 推理的場景通常調用頻率較低，屬于稀疏調用場景。由于 MCP 范式強依賴 LLM 推理，無論是基于 HTTP API 的傳統 AI 應用開發架構，還是基于 MCP 的新架構，目前都主要應用于這些稀疏調用場景。這引發了兩個關鍵問題：
在所有計算產品中，函數計算（FC）這種 Serverless FaaS 類型的計算產品，在資源粒度、彈性策略、彈性效率方面最適合稀疏調用場景。
阿里云函數計算（FC）目前支持 Python 和 NodeJS 兩種語言的 MCP 運行環境（其他語言的 MCP 運行環境也將很快支持）。用戶選擇 MCP 運行環境創建函數后，只需編寫 MCP Tool 的業務邏輯，無需考慮如何使用 MCP SDK。此外，云原生 API 網關與函數計算（FC）深度集成，天然適配 AI 應用開發的新范式。
基于函數計算（FC）構建的 MCP Server 在彈性效率方面有顯著優勢，主要體現在兩個維度：
函數計算（FC）提供從 0.05C 128MB 到 16C 32GB 的多種實例規格，用戶可以根據不同 MCP Server 承載的業務靈活選擇合適的資源規格。在 AI 應用中，尤其是流程式構建的模式中，大多數 AI Agent 的職責單一，計算邏輯簡單，因此可以用較小資源規格的函數承載。較小的資源規格在資源調度和彈性效率方面具有天然優勢。
函數計算（FC）的彈性機制完全基于請求，根據 QPS 自動拉起對應數量的實例，且實例可以復用。當 QPS 下降時，空閑實例會自動釋放，整個過程無需用戶介入。此外，用戶還可以設置按時間定時彈性或按指標閾值彈性策略，進一步滿足復雜多變的業務場景，實現資源成本最優。
函數計算（FC）具備完善的可觀測體系，這意味著基于函數計算（FC）構建的 MCP Server 同樣具備指標、鏈路、日志三個維度的可觀測能力。通過這套可觀測體系，用戶可以清晰地了解每個 MCP Server 的各類運行狀態，從而更好地管理和優化 MCP Server 的性能和成本。
通過函數計算（FC）的這些特性，企業可以高效地構建和管理 MCP Server，優化資源利用率，降低成本，同時快速響應業務需求，提升 AI 應用的開發和部署效率。
結合阿里云可觀測產品 ARMS 和鏈路追蹤 OpenTelemetry，我們構建了覆蓋 AI 應用全環節的可觀測體系。這一體系的構建主要圍繞兩個核心部分展開：數據采集和數據串聯與分析。
數據采集的核心是覆蓋足夠廣泛的范圍，這主要體現在兩個層面：
通過以上措施，我們實現了數據采集的全覆蓋，確保了可觀測體系的完整性。
在應用監控 ARMS 中，專門構建了 LLM 應用監控模塊，為 AI 應用場景提供了完善的可觀測體系。這一模塊從縱向和橫向兩個維度提供了豐富的監控指標和分析功能。
通過這些功能，用戶可以清晰地了解 AI 應用的運行狀態，快速定位問題，優化性能，確保 AI 應用的穩定運行。
隨著企業級 AI 應用架構新范式的逐步成熟，企業的運營、產品、研發、運維團隊之間的組織結構和協作關系，以及應用或系統的開發模式，都將迎來一系列變革。以下是我的一些暢想：
API First 與前后端分離：API First 和前后端分離的概念在海外企業中得到了較好的實踐，但在國內的應用相對較少。這可能是因為國內企業面臨著較重的歷史包袱，難以快速轉型。
Serverless 架構的實踐：在 Serverless 計算領域，AWS Lambda、Azure Functions、Azure App Service、GCP CloudFunction 和 GCP CloudRun 等架構方案已被廣泛研究和應用。然而，在國內，除了高德等少數企業通過函數計算重構系統實現了 API First 和前后端分離模式外，大多數企業仍處于探索階段。
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 應用架構將更加靈活、高效和智能。
文章轉載自： 萬字長文深度剖析基于 MCP 實現 AI 應用架構設計新范式的落地實踐
