国产精品国产三级国产aⅴ9色,成人在线影院aaaa,国产免费黄频在线观看,久久久一本精品,日韩av一区不卡

模型上下文協(xié)議（Model Context Protocol，簡稱 MCP）是一種日益受到關(guān)注的協(xié)議，旨在幫助模型客戶端與外部服務(wù)及工具服務(wù)器進(jìn)行更為廣泛的交互。通過 MCP，模型客戶端的功能不再僅限于對話或信息檢索，而是能夠執(zhí)行實際操作，例如發(fā)送電子郵件、部署代碼或發(fā)布文章等。雖然已有許多文章對 MCP 進(jìn)行了介紹，但本文將重點討論在深入使用過程中發(fā)現(xiàn)的一些問題，以及這些問題蘊藏的潛在商業(yè)機(jī)會。

有哪些問題

MCP 作為一個開放標(biāo)準(zhǔn)協(xié)議，允許任何模型客戶端選擇支持這一協(xié)議，同時服務(wù)器端可以輕松構(gòu)建多個分發(fā)點，從而節(jié)省開發(fā)者的時間和精力。這種靈活性相比各家模型廠商獨立提供的功能調(diào)用或工具使用方式，確實便利了許多。然而，在長期使用過程中，仍然存在一些需要解決的問題。

無謂的復(fù)雜性

有時為了形成標(biāo)準(zhǔn)而設(shè)立標(biāo)準(zhǔn)，這種現(xiàn)象在新進(jìn)入者與現(xiàn)存主導(dǎo)者的競爭中比較常見，這種做法雖然可以理解，但實際上引發(fā)了一些值得思考的問題。如果希望大語言模型（LLM）能夠使用現(xiàn)有的服務(wù)，為什么不直接讓它調(diào)用現(xiàn)有的 API 呢？利用成熟的 RESTful 以及 Swagger/OpenAPI 規(guī)范生成所需的 JSON schem)a 似乎會更加簡潔（例如使用 agents.json）。專門創(chuàng)建 MCP Server 來包裝現(xiàn)有 API 的做法看起來有些多余，這也隨之帶來了新的安全性和訪問權(quán)限方面的挑戰(zhàn)。

安全性

在創(chuàng)建 MCP Server 時，惡意攻擊者可能通過注冊與合法服務(wù)器相似或相同的名稱，以此欺騙用戶安裝惡意服務(wù)器。此外，代碼注入攻擊可能發(fā)生在 MCP Server 的源代碼或配置文件中，威脅其安全性。在運行過程中，多個工具可能使用相似的名稱，這可能導(dǎo)致用戶在選擇工具時產(chǎn)生沖突，進(jìn)而執(zhí)行錯誤的操作或泄露敏感信息。同時，若多個工具注冊了相同或相似的命令，可能導(dǎo)致執(zhí)行時的歧義，造成意外的錯誤操作。此外，當(dāng) MCP Server 更新后，某些過時或被撤銷的權(quán)限可能未及時清除，這使得惡意用戶仍可利用這些權(quán)限進(jìn)行惡意操作。

訪問權(quán)限

企業(yè)用戶更傾向于自行托管 MCP Server，以便于分離數(shù)據(jù)層和控制層，從而確保安全性和合規(guī)性，并支持不同用戶訪問該服務(wù)器。從最新的規(guī)范來看，遠(yuǎn)程服務(wù)器的支持已經(jīng)有所增強(qiáng)，但仍然存在一些問題。

首先，采用基于 OAuth 2.1 的身份驗證機(jī)制。其次，之前的 HTTP+SSE 傳輸方式已被流式 HTTP 傳輸所取代。此外，系統(tǒng)還支持 JSON-RPC 的批處理功能。然而，即便某個工具通過了身份驗證，其使用范圍仍需明確界定。目前，MCP 尚未實現(xiàn)細(xì)粒度的權(quán)限控制，權(quán)限管理仍限于會話級別，這意味著工具要么完全開放，要么完全禁用。隨著工具數(shù)量的增加，管理權(quán)限將變得愈加復(fù)雜。

持久連接與狀態(tài)性

最初的設(shè)計更偏向于本地運行，特別是通過使用 uv/uvx 來將本地服務(wù)集成為獨立進(jìn)程。然而，這種子進(jìn)程的使用會帶來一些安全風(fēng)險。在 MCP 中，連接是有狀態(tài)的，支持在連接生命周期內(nèi)進(jìn)行多次請求和響應(yīng)。這種設(shè)計使得客戶端和服務(wù)器之間能夠進(jìn)行持續(xù)的交互，并維護(hù)上下文信息，從而提升了交互的效率和連貫性。然而，這一模式并不太符合當(dāng)前流行的無狀態(tài) API 架構(gòu)，例如 AWS Lambda 和 Cloudflare Workers。

工具過多占用上下文目前，MCP 將所有工具都納入到模型的上下文中，缺乏有效的優(yōu)先級和路由機(jī)制。這不僅造成了 token 的浪費，還可能導(dǎo)致模型行為的不穩(wěn)定。例如，當(dāng)我讓 Claude Desktop 從超過 60 種工具中選擇 5 種進(jìn)行調(diào)用時，其性能明顯下降，且大多數(shù)情況下模型并未選擇出最合適的工具。因此，需要一種分級路由的方式來逐步、選擇性地展示工具選項。目前社區(qū)正在探索通過命名空間和拓?fù)涓兄姆椒ㄟM(jìn)行分層，以改進(jìn)這一問題。總結(jié)

MCP 仍面臨諸多挑戰(zhàn)，但如果社區(qū)能夠有效解決這些問題（Roadmap 上已經(jīng)提出了相應(yīng)的方案），其潛力將會巨大。在此之前，我將保持謹(jǐn)慎樂觀，并繼續(xù)關(guān)注我感興趣的 Agent Network 以及在多輪持續(xù)對話場景下的工具調(diào)用研究。

問題就是機(jī)會

模型上下文協(xié)議（MCP）的核心依然是模型，其主要目標(biāo)是爭取下一個用戶交互的入口，使模型客戶端成為主要的交互界面。這樣的設(shè)計讓用戶能夠通過 API 完成操作，而無需依賴各個垂直 SaaS 軟件的圖形用戶界面（GUI）。在長鏈條任務(wù)中，這種設(shè)計與用戶利益高度一致，因此 OpenAI 理應(yīng)支持 MCP，因為這與 Anthropic 的利益是相符的。然而，這種模式可能會遭遇擁有大量用戶的產(chǎn)品的抵制，因為現(xiàn)有的守成者并不希望大模型成為新的交互入口。MCP 的陽謀在于“挾持開發(fā)者和用戶以制衡巨頭”：即使某些平臺不樂意，標(biāo)準(zhǔn)協(xié)議也能幫助實現(xiàn)更為體面的交互方式。

接下來，除了完善協(xié)議本身，模型廠商還需圍繞消費級需求提供更優(yōu)化的存儲、服務(wù)器商店等配套設(shè)施。這些領(lǐng)域單靠模型廠商難以完全覆蓋，因此為現(xiàn)有基礎(chǔ)設(shè)施廠商和開發(fā)者創(chuàng)造了機(jī)會。

Server 網(wǎng)關(guān)

作為 MCP 客戶端與服務(wù)器之間的中介組件，網(wǎng)關(guān)主要負(fù)責(zé)統(tǒng)一管理連接、分配任務(wù)與執(zhí)行安全驗證。隨著 MCP 的廣泛應(yīng)用，網(wǎng)關(guān)逐漸成為系統(tǒng)中關(guān)鍵的中間層，承擔(dān)統(tǒng)一認(rèn)證、權(quán)限控制、流量調(diào)度和工具選擇的職責(zé)。其功能與傳統(tǒng)的 API 網(wǎng)關(guān)類似，包括訪問控制、請求路由、負(fù)載均衡，并通過緩存響應(yīng)提高效率。在多租戶環(huán)境中，網(wǎng)關(guān)的作用尤為重要，因為不同用戶與 agent 可能擁有不同的訪問權(quán)限。一個標(biāo)準(zhǔn)化的 MCP 網(wǎng)關(guān)能夠簡化客戶端與服務(wù)器之間的交互，增強(qiáng)系統(tǒng)的安全性、可觀測性和可擴(kuò)展性，同時使 MCP 的部署和管理更為簡便。

一些反應(yīng)迅速的廠商已經(jīng)開始提供類似的能力，比如 Zapier 推出的 MCP 全流程方案，通過一個動態(tài)的 MCP 端點將 AI 助手與 Zapier 的廣泛集成網(wǎng)絡(luò)連接起來，實現(xiàn)對超過 8000 個應(yīng)用的直接訪問。此方案允許 AI 執(zhí)行真實操作，例如發(fā)送 Slack 消息或管理 Google Calendar 事件，Zapier 使開發(fā)者能夠?qū)Ｗ⒂诰幋a，而由其管理身份驗證、API 限制和安全性。此外，國內(nèi)的騰訊輕聯(lián)、集簡云等 iPaaS 平臺也可以快速實現(xiàn)類似的改造。

Server 發(fā)現(xiàn) 用戶在尋找和配置 MCP 服務(wù)器時，仍然需要手動操作，包括查找服務(wù)地址或腳本，并配置認(rèn)證信息。為了簡化跨不同 MCP 客戶端的服務(wù)器安裝流程，可以考慮構(gòu)建一個安裝工具（如 mcp-get）或創(chuàng)建一個服務(wù)器目錄導(dǎo)航站，以幫助用戶發(fā)現(xiàn)和訪問可用的 MCP 服務(wù)器。不過，根據(jù)官方 2025 年上半年的路線圖，MCP 包管理（標(biāo)準(zhǔn)化打包格式）、安裝工具、沙盒安全和服務(wù)器注冊等功能已經(jīng)被列入日程。到那時，按照標(biāo)準(zhǔn)設(shè)計的工具將會創(chuàng)造出新的商機(jī)。 Server 托管提供遠(yuǎn)程 MCP 服務(wù)器托管服務(wù)的市場正在發(fā)展，現(xiàn)有基礎(chǔ)設(shè)施廠商紛紛進(jìn)入這一領(lǐng)域。例如，Cloudflare 推出了遠(yuǎn)程 MCP 服務(wù)器部署功能，提供四個核心組件來簡化遠(yuǎn)程服務(wù)器的構(gòu)建過程：首先，workers-oauth-provider 作為 OAuth 2.1 庫，簡化了用戶認(rèn)證和授權(quán)流程，使開發(fā)者無需自行實現(xiàn)復(fù)雜的流程；其次，McpAgent 類集成在 Cloudflare Agents SDK 中，負(fù)責(zé)處理遠(yuǎn)程傳輸，使得 MCP 服務(wù)器能夠接收和處理來自 MCP 客戶端的消息；接下來，mcp-remote 作為適配器，允許本地 MCP 客戶端使用遠(yuǎn)程 MCP 服務(wù)器，便于這些客戶端連接和利用遠(yuǎn)程服務(wù)器；最后，AI playground 作為遠(yuǎn)程 MCP 客戶端，提供在線聊天界面，允許用戶與遠(yuǎn)程 MCP 服務(wù)器進(jìn)行交互和測試，同時進(jìn)行必要的認(rèn)證檢查。

Server 安全 MCP 服務(wù)器的安全性可以參考 DevSecOps 的方法，需要引入多種安全工具，以覆蓋 MCP 服務(wù)器的整個生命周期。在創(chuàng)建階段，包括服務(wù)器注冊、安裝部署和代碼完整性驗證，以確保服務(wù)器的正確配置和安全性；在運行階段，MCP 服務(wù)器需要根據(jù) AI 應(yīng)用請求執(zhí)行工具操作，處理命令，并實現(xiàn)沙盒機(jī)制，保障環(huán)境安全和穩(wěn)定地與外部資源交互；在更新階段，確保 MCP 服務(wù)器持續(xù)更新以適應(yīng)需求變化，同時涵蓋授權(quán)管理、版本控制和舊版本管理，從而防止安全漏洞和權(quán)限問題的出現(xiàn)。

工具調(diào)用管理

在構(gòu)建 MCP 客戶端時，工具的選擇是一個至關(guān)重要的問題。面對大量的服務(wù)，簡單地將所有工具放入上下文中進(jìn)行自動選擇顯然是不可行的（我嘗試從 60 個工具中選 5 個的時候就遇到了崩潰），也不能完全依賴人工來做判斷。那么，每位開發(fā)者是否都需要為工具創(chuàng)建獨立的檢索邏輯呢？是否可以構(gòu)建一個標(biāo)準(zhǔn)化的“中間層”，以減少重復(fù)開發(fā)并提高效率？

另一個問題是缺乏統(tǒng)一的工具調(diào)用接口和一致的 UI/UX 設(shè)計模式。一些工具依賴斜杠命令，而其他工具則使用自然語言指令。通過引入一個標(biāo)準(zhǔn)化的客戶端層，可以涵蓋工具的發(fā)現(xiàn)、排序和調(diào)用流程，從而為開發(fā)者和終端用戶提供更一致和可靠的體驗。

在交互過程中，常常需要依次調(diào)用多個工具（例如，單輪對話中的多步驟工具調(diào)用和多輪對話中的工具分批調(diào)用），但當(dāng)前的 MCP 并未內(nèi)置工作流管理機(jī)制。當(dāng)期望每個客戶端獨立實現(xiàn)中斷恢復(fù)和失敗重試等功能時，這種做法既不現(xiàn)實也低效。因此，構(gòu)建一個統(tǒng)一的工作流管理系統(tǒng)顯得尤為必要。