影音先锋橹撸资源_人妻少妇孑伦无码视频_日本女人牲交视频免费看_国产香蕉视频上线免费_波多野结超清无码中文影片_婷婷色丁香五月激情综合在线观看_寡妇高潮流白浆A片_国产精品九色 Av_花房姑娘电影未删减版免费观看_国产亚洲综合一区三区在线播放

通過MCP，AI模型能夠以統(tǒng)一的方式訪問資源和工具，從而實現(xiàn)更高效、更智能的交互體驗。本文將詳細(xì)解讀MCP的工作原理、傳輸機(jī)制及其在實際應(yīng)用中的優(yōu)勢，幫助讀者更好地理解這一創(chuàng)新技術(shù)如何推動AI從簡單的聊天工具邁向真正的智能代理。

現(xiàn)如今，人工智能（AI）和大語言模型（LLM）越來越聰明，甚至接近了人類的智慧水平。但如果它們只能利用自身已有的數(shù)據(jù)，無法獲取外界實時信息或者調(diào)用外部工具（在線詞典、天氣、地圖等），那么它們的能力就會被大大的限制。比如用戶問，今天哪家公司股票漲幅最大？由于缺少實時數(shù)據(jù)和工具支持，再強(qiáng)大的AI也無法給出滿意的答案。

在沒有MCP之前智能體都是如何做的呢？

這里引入兩個概念：

大模型

大模型（LargeLanguageModel，LLM）是一種基于深度學(xué)習(xí)技術(shù)的人工智能模型，具有龐大的參數(shù)量和強(qiáng)大的學(xué)習(xí)能力，能夠理解、生成自然語言文本，并執(zhí)行多種復(fù)雜任務(wù)。

大模型在MCP協(xié)議出現(xiàn)之前已經(jīng)經(jīng)歷了兩個階段：

第一個階段：基于訓(xùn)練數(shù)據(jù)相對封閉階段

最初大模型（GPT、Claude等）本質(zhì)上是基于海量數(shù)據(jù)訓(xùn)練的下一個詞的預(yù)測器（Nexttokenprediction）。用戶輸入一個問題，大模型通過一個詞一個詞最大概率出現(xiàn)的方式去給到用戶輸出。他們是基于概率的預(yù)測，也意味著大模型并不是真的理解用戶的意思，而是基于概率預(yù)測。因此會經(jīng)常會出現(xiàn)一些幻覺（一本正經(jīng)的胡說八道）。這個時期的大模型是孤立存在的，沒有接收任何的外部信息。

第二階段：LLM+context上下文輸入給大模型階段

比如現(xiàn)在的deepseek、豆包、GPT、Kimi等，他們都有一個選項叫做聯(lián)網(wǎng)搜索，這個就是網(wǎng)絡(luò)的上下文。

短期記憶：模型的上下文對話記錄

長期記憶：像RAG知識庫。這些都是在給模型提供有力的上下文支撐。

現(xiàn)在以人造機(jī)器人舉例，這個機(jī)器人姑且叫它張三。大模型就相當(dāng)于張三的大腦，具備智力，可以和我們進(jìn)行對話。

智能體

張三具備人類的大腦，可惜只能跟我們聊天，手腳發(fā)育還不完全，別的事情做不了。為了讓張三具備更多的能力，經(jīng)過學(xué)習(xí)研究，大家終于為張三安上了假肢（FunctionCall)。張三可以借助假肢來使用一些簡單的工具。

Functioncalling沒有統(tǒng)一的標(biāo)準(zhǔn)，每家大廠的API定義都不一樣。調(diào)用工具時，每個工具都要單獨的適配，每個鏈接都需要去定制代碼、去寫特定性的服務(wù)、去處理權(quán)限、去管理格式、來保證足夠的兼容性。最后就會導(dǎo)致這整個系統(tǒng)非常的復(fù)雜。極難去維護(hù)、極難去規(guī)模化。

就像由于假肢是后面才做的，張三的大腦還不知道如何使用，因此，大家為張三量身打造了一些工具（函數(shù)、插件），可以理解為“筆”、“菜刀”，并且把工具的使用方法寫成詳細(xì)的說明書（提示詞）存儲到假肢的芯片中。

并且告訴張三，以后我讓你干活的時候，你可以先讀取一下假肢里的說明書，看看都需要調(diào)用哪些工具。

比如，讓我們告訴張三：請幫我們切個菜，他首先會拿出使用說明書看一下，找找他現(xiàn)在已有的工具中可以使用來做這件事的工具。

像這樣，擁有了工具使用能力的機(jī)器人（大模型）我們就稱它為智能體了。所以說智能體最核心的特點，就是具備工具調(diào)用的能力。

后來，大家做出了更多的大模型，比如又來了個李四（豆包）、王五（DeepSeek）……為了更加高效的組織和管理這些人呢，有人就創(chuàng)建了公司A（Coze、Dify等），將張三、李四、王五都招了進(jìn)來，并且專門制定了一套公司的工具使用制度（各自匹配的Functioncall)，還專門給張三、李四、王五配上了許多干活的工具（插件）。

這樣，這家公司A就就開始給大家提供各種各樣的服務(wù)，給大家干各種各樣的任務(wù)了。

可是有一天，有人建立了公司B，想把張三、李四和王五等人挖進(jìn)來，但是公司A的制度和工具肯定不會給B對吧？于是為了讓張三、李四和王五工作，公司B也只能重新研發(fā)工具使用制度和配備相關(guān)的工具（插件）。

那么現(xiàn)在問題來了，明明是同樣的工具，公司A和公司B沒法通用。

更夸張的是，有個人之前都是在公司A雇傭張三干活，還專門給他做了工具，但是現(xiàn)在這個人覺得公司A的費用太貴了，想找公司B，但是之前工具都在放在公司A那里根本拿不過來，更別說遷移使用了，只能重新再做。

后來這個人想，干脆不找公司A或者公司B了，我單獨雇傭張三來幫我干活（自己部署大模型研發(fā)智能體），自己還是要專門給他配個工具。

就這樣，重復(fù)做了好多事，浪費了很多資源。

如何讓他們安全、高效地與外部資源和工具進(jìn)行交互，就成了一個亟待解決的核心問題。

一、MCP應(yīng)運而生

因為前面遇到的問題，于是終于有人Claude母公司（Anthropic公司）制定了一個標(biāo)準(zhǔn)–MCP

MCP（全稱是ModelContextProtocol,即模型上下文協(xié)議）

從它的名稱上我們就可以看出，MCP不是一個產(chǎn)品、不是一個應(yīng)用，也不是一個APISDK，而是一個協(xié)議。它的目標(biāo)是希望任何一個AI的模型（Chatgpt、Claude、deepseek等）都能夠以一個統(tǒng)一的方式去訪問資源和工具。

任何你希望模型能知道、能用、能調(diào)用的內(nèi)容主要分為兩塊

資源（resources）：數(shù)據(jù)庫、API、第三方的saas等

工具（tools）：天氣、地圖、在線詞典、日歷、郵件、執(zhí)行命令、遠(yuǎn)程控制等等；

這些資源和工具是讓模型變得真的能干活的關(guān)鍵。

二、MCP是如何工作的呢？

AI客戶端：就像你手機(jī)里的ChatGPT/豆包App，是和AI聊天、發(fā)指令的“入口”，就是把一些含糊不清的自然語言轉(zhuǎn)化成一個明確的意圖。比如用戶要發(fā)一封郵件，我要看日歷。這種明確的意圖。

STDIO：理解成“信息快遞站”，負(fù)責(zé)把AI說的話、要干的事兒，打包發(fā)給后面的“服務(wù)器”

MCPServer：用戶意圖就會這些請求就會發(fā)給MCPserver（能力適配器）。MCPserver就負(fù)責(zé)和外部的系統(tǒng)通信，比如郵箱、日歷、地圖等等。并且會聲明出它提供的工具或者資源。把它們當(dāng)“AI管家團(tuán)隊”，A管家對接高德地圖、B管家對接日歷、C管家對接Github，分工幫AI跑腿干活。

比如用戶要發(fā)一封郵件，我要看日歷，這些請求就會發(fā)給MCPserver（能力適配器），MCPserver就負(fù)責(zé)和外部的系統(tǒng)通信，比如郵箱、日歷、地圖等等。并且會聲明出它提供工具或者資源。

比如Gmail的MCPserver它可以去發(fā)郵件、接收郵件，寫郵件。

一個Calendarserver，可以去設(shè)置日歷、創(chuàng)建日歷提醒等

一個GithubServer可能會執(zhí)行代碼的審查、代碼編寫等。

這些Server都實現(xiàn)了一個統(tǒng)一的協(xié)議，支持通過http、Json、或者通過本地輸入輸出的方式去跟MCP的Client進(jìn)行通信。

再舉一個更加實際的例子：

比如我發(fā)出請求說，幫我約小七老師這周日一起去健身，并發(fā)一個郵件給她提醒。

仔細(xì)拆解這個請求，其實包含著兩個任務(wù)，第一個任務(wù)是去找到我和小七老師周日都有空閑的時間段。第二個任務(wù)是去創(chuàng)建一個日程提醒并發(fā)送郵件給小七老師。

那么AI應(yīng)用作為一個MCP的Client，會先向系統(tǒng)中已經(jīng)注冊的MCPserver去查詢它的能力列表。比如是不是可以訪問日歷，是不是有權(quán)限去發(fā)郵件，是不是能獲取到小七老師的聯(lián)系人信息？

這些能力的聲明和用戶的請求一并去交給大語言模型去處理。

模型基于給定的上下文，去判斷我應(yīng)該怎么整合現(xiàn)有的工具去完成任務(wù)。

比如決策后發(fā)現(xiàn)：

第一步：我先從Calendarserver里面去找我和小七老師都空閑的時間段

第二步：決定最終的健身時間

第三步：調(diào)用Emailserver去發(fā)郵件

第四步：可能還會提問用戶，是不是還要叫上其他好友？整個流程非常的清晰標(biāo)準(zhǔn)化、邏輯也是閉環(huán)的，關(guān)鍵是你不需要為每個流程去寫死一個邏輯，模型也不需要提前訓(xùn)練才知道每個API

只要MCPserver有這個能力的聲明，模型就能夠動態(tài)的發(fā)現(xiàn)、調(diào)用、并且執(zhí)行。

三、MCP常用的幾種傳輸機(jī)制有哪些呢？

MCP提供了幾種不同的“溝通方式”（傳輸機(jī)制），最受關(guān)注的是以下三種：Stdio、SSE、StreamableHTTP，他們就像不同的交通工具，各有優(yōu)缺點，適用于不同的“路況”（應(yīng)用場景）。理解他們的差異，正是為AI應(yīng)用挑選最佳交互方式、充分釋放其潛力的關(guān)鍵所在。下面我們來詳細(xì)了解這三種協(xié)議及其優(yōu)缺點。

1.Stdio協(xié)議

1）通信原理

Stdio（StandardInput/Output，標(biāo)準(zhǔn)輸入/輸出）協(xié)議，是基于操作系統(tǒng)提供的標(biāo)準(zhǔn)輸入輸出機(jī)制實現(xiàn)的一種數(shù)據(jù)傳輸方式。在很多編程環(huán)境和系統(tǒng)交互中，Stdio作為基礎(chǔ)的數(shù)據(jù)交互通道，承擔(dān)著數(shù)據(jù)輸入與輸出的基礎(chǔ)功能。

例如在常見的命令行程序中，用戶通過標(biāo)準(zhǔn)輸入向程序傳遞指令和數(shù)據(jù)，程序則通過標(biāo)準(zhǔn)輸出返回處理結(jié)果。

2）核心優(yōu)勢

通用性和易用性：幾乎所有的操作系統(tǒng)和編程語言都原生支持標(biāo)準(zhǔn)輸入輸出，開發(fā)者無需額外配置復(fù)雜的網(wǎng)絡(luò)環(huán)境或引入特定的庫文件，就能快速實現(xiàn)數(shù)據(jù)的傳輸與交互，大大降低了開發(fā)門檻；

低延遲效率高：進(jìn)程間通過標(biāo)準(zhǔn)輸入輸出進(jìn)行數(shù)據(jù)交換，直接通過內(nèi)存或者內(nèi)部管道傳輸，能夠?qū)崿F(xiàn)快速、高效的協(xié)作；

高安全性：數(shù)據(jù)只在你的電腦內(nèi)部傳輸，不會流到外面去，隱私安全方面有保障。

3）局限性

傳輸效率相對較低，在處理大量數(shù)據(jù)時，頻繁的輸入輸出操作容易成為性能瓶頸。無法同時處理多個請求，不適合大規(guī)模應(yīng)用；

限定于本地只能在同一臺電腦上使用，無法滿足遠(yuǎn)程數(shù)據(jù)交互的需求（訪問不了其他電腦或者云端資源）

4）適用場景

本地小工具集成、處理個人隱私數(shù)據(jù)、快速做功能Demo看效果等。

2.SSE協(xié)議

1）通信原理

SSE（Server-SentEvents，服務(wù)器發(fā)送事件）協(xié)議是一種基于HTTP協(xié)議的單向數(shù)據(jù)傳輸協(xié)議，由服務(wù)器主動向客戶端推送數(shù)據(jù)。

在Web應(yīng)用中，SSE常用于實現(xiàn)實時數(shù)據(jù)更新功能，如股票行情的實時展示、新聞動態(tài)的即時推送等。服務(wù)器端可以隨時將新的數(shù)據(jù)變化推送給客戶端，而不需要客戶端頻繁地向服務(wù)器發(fā)起請求，有效降低了客戶端與服務(wù)器之間的交互壓力。

2）核心優(yōu)勢

實時性：實現(xiàn)了服務(wù)器端的主動推送，能夠快速將最新數(shù)據(jù)傳遞給客戶端，極大地提升了數(shù)據(jù)的實時性，為用戶帶來更加流暢的實時交互體驗；

穩(wěn)定性好：SSE基于HTTP協(xié)議，在網(wǎng)絡(luò)兼容性方面表現(xiàn)良好，能夠輕松穿越各種網(wǎng)絡(luò)代理和防火墻，保證數(shù)據(jù)傳輸?shù)姆€(wěn)定性；

支持遠(yuǎn)程訪問：可以連接不在同一臺電腦上的服務(wù)器，適合分布式系統(tǒng)；

實現(xiàn)簡單，開發(fā)成本較低，對于只需要服務(wù)器向客戶端單向推送數(shù)據(jù)的場景，是一種高效的解決方案。

3）局限性

單向傳輸協(xié)議，客戶端無法主動向服務(wù)器發(fā)送數(shù)據(jù)，這限制了其在雙向交互場景中的應(yīng)用。

服務(wù)器壓力大：需要一直建立連接，如果有多個客戶端，服務(wù)器負(fù)擔(dān)過重；

兼容問題：對瀏覽器的兼容性存在一定差異，在一些老舊瀏覽器中可能無法正常使用；

即將“淘汰”：官方覺得有更好的替換方案，準(zhǔn)備用下面要講的第三種StreamableHTTP來代替。

4）適用場景

適用于需要服務(wù)器實時推送通知到客戶端的遠(yuǎn)程服務(wù)器。

3.StreamableHTTP協(xié)議

1）通信原理

StreamableHTTP協(xié)議是一種基于HTTP協(xié)議的流式傳輸協(xié)議，它允許數(shù)據(jù)以流的形式在客戶端和服務(wù)器之間傳輸，而不需要一次性將所有數(shù)據(jù)加載完成。在視頻流播放、音頻在線收聽等場景中，StreamableHTTP協(xié)議發(fā)揮著核心作用。用戶無需等待整個媒體文件下載完成，就可以開始播放內(nèi)容，大大提高了用戶體驗。

2）核心優(yōu)勢

流式傳輸靈活性高：能夠顯著提升數(shù)據(jù)傳輸?shù)男屎陀脩趔w驗，對于大文件或持續(xù)產(chǎn)生的數(shù)據(jù)，采用流式傳輸可以避免因等待數(shù)據(jù)全部傳輸完成而造成的長時間延遲，實現(xiàn)數(shù)據(jù)的邊傳輸邊處理。

穩(wěn)定性好，基于廣泛使用的HTTP協(xié)議，具備良好的網(wǎng)絡(luò)適應(yīng)性和跨平臺性，無論是在Web應(yīng)用還是移動應(yīng)用中，都能穩(wěn)定運行。

兼容性好：能很好地配合API網(wǎng)關(guān)、CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）、負(fù)載均衡器等現(xiàn)代網(wǎng)絡(luò)設(shè)施一起工作。

3）局限性

網(wǎng)絡(luò)環(huán)境的依賴性較高：在網(wǎng)絡(luò)不穩(wěn)定的情況下，可能會出現(xiàn)卡頓、緩沖等問題，影響數(shù)據(jù)的連續(xù)性和流暢性。

稍復(fù)雜：由于數(shù)據(jù)是按流傳輸，在數(shù)據(jù)完整性校驗和錯誤恢復(fù)方面相對復(fù)雜，一旦出現(xiàn)數(shù)據(jù)丟失或錯誤，修復(fù)難度較大，可能需要開發(fā)者自己多做一些努力。

4）適用場景

StreamableHTTP協(xié)議憑借其靈活高效的數(shù)據(jù)傳輸特性，成為云函數(shù)（比如AWSLambda）、需要根據(jù)負(fù)載自動伸縮的分布式系統(tǒng)以及無狀態(tài)服務(wù)架構(gòu)等場景中遠(yuǎn)程通信的理想選擇。

4.對比總結(jié)

選擇建議

只在自己電腦上使用？建議用Stdio，簡單直接；

需要連接遠(yuǎn)程服務(wù)器？直接用StreamableHTTP，擁抱未來，避免以后還要改代碼，維護(hù)起來更麻煩。

5.推薦幾個MCP市場給大家

https://www.pulsemcp.com

https://smithery.ai

https://cursor.directory/mcp

https://bailian.console.aliyun.com/?tab=mcp#/mcp-market

https://tcb.cloud.tencent.com/mcp-server

總結(jié)

最后，咱們來總結(jié)一下，MCP從根本上重構(gòu)了AI的整個應(yīng)用架構(gòu)。真正把AI從Chatbox階段推進(jìn)到了AIAgent階段。它不僅僅是一個方便的工具接入接口，他是一個全新的協(xié)議標(biāo)準(zhǔn)，正在重構(gòu)AI和世界的交互方式。它讓我們真的做到了從人使用AI生成文字、圖片、視頻到AI自主使工具和資源的新范式。

題圖來自Unsplash，基于CC0協(xié)議

該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)

不可思議的神作《抗戰(zhàn)之中國遠(yuǎn)征軍》,被安排的明明白白?？男生...

聞言張弛這才知道問題出在哪。原本他還以為這沒什么大不了的，但往細(xì)里一想很快就嚇出一身冷汗：還真是，如果自己只是簡簡單單的一個兵的話，怎么可能會知道日軍要來！除非自己有千里眼，或者是日本人的奸細(xì)……奸細(xì)！他娘的，這又是一個死罪——|。張弛不由暗道一聲倒霉，到了這時空后動不動就是“死”，這命都等我繼續(xù)說。
第二本【書名】《抗戰(zhàn)之中國遠(yuǎn)征軍》【作者】遠(yuǎn)征士兵人氣熱度：★★★ 精選章節(jié)：雖然張弛不愿相信，但他卻又不得不相信……他回到了抗戰(zhàn)時代成了遠(yuǎn)征軍的一員，而且立足于緬甸戰(zhàn)場上|——。這不？不遠(yuǎn)處那槍炮聲打得正歡呢，據(jù)說那是日本鬼子又一次對遠(yuǎn)征軍防守的同古發(fā)動了進(jìn)攻_。他娘滴！想到這里張弛不由暗罵了一聲是什么。

抗戰(zhàn)烽火!中國遠(yuǎn)征軍改寫歷史,誓師東京,震撼全球!

抗戰(zhàn)烽火！中國遠(yuǎn)征軍改寫歷史，誓師東京，震撼全球！今日推薦：《抗戰(zhàn)之中國遠(yuǎn)征軍》作者：遠(yuǎn)征士兵-。點擊文末超鏈接開始觀看吧～第三章封鎖杜聿明的兵力部署本來沒有什么問題，問題就在于國軍的裝備不統(tǒng)一彈藥也與密支那的軍火不匹配。說起這國軍的裝備還真是件讓人頭疼的事情，比如現(xiàn)在位于密支那的這些部隊雖然全都說完了。
第二本：《抗戰(zhàn)之中國遠(yuǎn)征軍》作者：遠(yuǎn)征士兵 字?jǐn)?shù)：262萬，評分：9.3 精彩劇情：“英國佬這都啥玩意??？”小浙江有些想不通，他望著那些狼狽逃走的英國兵，頗為失望的說道：“虧俺還以為他們能打敗日本人呢，這一頓槍就把他們給嚇的……”對此張弛倒是覺得情有可原，美英等國的治軍觀念與中國不一樣，..

抗戰(zhàn)中的中國遠(yuǎn)征軍(24)周文星:我在印緬戰(zhàn)區(qū)當(dāng)憲兵

中國軍隊的軍訓(xùn)開始了，美國教官前來授課——-。中國軍官嚴(yán)格按照規(guī)定傳授射擊技巧，而美國教官則強(qiáng)調(diào)自由舒適，提倡實用性——_。這種不同理念導(dǎo)致了訓(xùn)練方法上的沖突，各個部隊在摩擦中進(jìn)行著訓(xùn)練。由于語言不通，中美兩國士兵之間的交流存在困難。然而，美國人展現(xiàn)出豁達(dá)大方的態(tài)度，表示友好--。即便存在摩擦，雙方也積極學(xué)習(xí)對方的等我繼續(xù)說_——。
2013年，93歲的中國遠(yuǎn)征軍老兵洪發(fā)祥說：“我這一輩子，低頭過了60年，就想有天國家能承認(rèn)我抗日，給我個名分，死也值了！”老人家住在廈門人和路一條熱鬧的小街巷，一間不到10平米的小屋，如果刮臺風(fēng)還會往里面滲水。耄耋之年的他領(lǐng)著一個月270元錢的低保生活，腦袋越來越不靈，腿腳也不如之前了。但仍然保持希望你能滿意__。

免責(zé)聲明：本文內(nèi)容由開放的智能模型自動生成，僅供參考。