引言：AI工具調(diào)用的變革之路

在人工智能飛速發(fā)展的今天，AI代理（AI Agents）已經(jīng)成為我們生活中不可或缺的一部分。從智能客服到代碼助手，從企業(yè)知識管理到個人生產(chǎn)力提升，AI代理的應(yīng)用場景無處不在。然而，在AI代理與外部工具和數(shù)據(jù)源集成的過程中，一直存在著一個亟待解決的問題：如何實(shí)現(xiàn)高效、安全、可擴(kuò)展且易于維護(hù)的工具調(diào)用？傳統(tǒng)的方法往往依賴于臨時的、特定于模型的集成方式，這不僅導(dǎo)致代碼庫碎片化，還增加了維護(hù)成本和開發(fā)難度。幸運(yùn)的是，Model Context Protocol（MCP）的出現(xiàn)，為這一問題帶來了全新的解決方案。

傳統(tǒng)AI工具集成的困境

在MCP出現(xiàn)之前，大型語言模型（LLMs）主要依靠臨時的、特定于模型的集成方式來訪問外部工具。例如，ReAct方法將鏈?zhǔn)酵评砼c顯式的函數(shù)調(diào)用相結(jié)合，而Toolformer則通過訓(xùn)練模型來學(xué)習(xí)何時以及如何調(diào)用API。此外，像LangChain和LlamaIndex這樣的庫提供了代理框架，將LLM提示與自定義的Python或REST連接器包裝在一起，而Auto-GPT等系統(tǒng)則通過反復(fù)調(diào)用定制服務(wù)來分解目標(biāo)為子任務(wù)。這些方法雖然能夠?qū)崿F(xiàn)工具調(diào)用，但它們存在一個共同的問題：每增加一個新的數(shù)據(jù)源或API，就需要編寫一個獨(dú)立的包裝器，并且代理必須經(jīng)過專門訓(xùn)練才能使用它。這種碎片化的集成方式不僅難以維護(hù)，還限制了AI代理的可擴(kuò)展性和靈活性。

Model Context Protocol（MCP）：AI工具調(diào)用的新標(biāo)準(zhǔn)

MCP是什么？

Model Context Protocol（MCP）的出現(xiàn)，正是為了解決上述問題。MCP是一種開放協(xié)議，旨在標(biāo)準(zhǔn)化AI代理發(fā)現(xiàn)和調(diào)用外部工具及數(shù)據(jù)源的方式。它定義了一個基于JSON-RPC的通用API層，連接LLM主機(jī)和服務(wù)器。簡單來說，MCP就像是AI應(yīng)用的“USB-C接口”，任何模型都可以通過它訪問工具。通過MCP，組織可以實(shí)現(xiàn)與數(shù)據(jù)源和AI工具之間的安全雙向連接，取代了過去零散的連接器。

MCP的核心優(yōu)勢

MCP的核心優(yōu)勢在于它的標(biāo)準(zhǔn)化和復(fù)用性。與傳統(tǒng)方法不同，MCP將模型與工具解耦。代理（或主機(jī)）只需連接到一個或多個MCP服務(wù)器，這些服務(wù)器以標(biāo)準(zhǔn)化的方式暴露數(shù)據(jù)或功能。代理從服務(wù)器獲取可用工具的列表，包括它們的名稱、描述以及輸入/輸出模式，然后模型可以通過名稱調(diào)用任何工具。這種標(biāo)準(zhǔn)化的調(diào)用方式，不僅簡化了開發(fā)流程，還提高了系統(tǒng)的可維護(hù)性和可擴(kuò)展性。

MCP的三個核心角色

MCP的開放規(guī)范定義了三個核心角色：

• 主機(jī)（Host）：用戶與之交互的LLM應(yīng)用或用戶界面（例如聊天界面、IDE或代理編排引擎）。主機(jī)嵌入LLM并作為MCP客戶端。
• 客戶端（Client）：主機(jī)內(nèi)部實(shí)現(xiàn)MCP協(xié)議的軟件模塊（通常通過SDK實(shí)現(xiàn)）?？蛻舳素?fù)責(zé)處理消息傳遞、身份驗證以及模型提示和響應(yīng)的序列化。
• 服務(wù)器（Server）：提供上下文和工具的服務(wù)（可以是本地或遠(yuǎn)程的）。每個MCP服務(wù)器可以包裝數(shù)據(jù)庫、API、代碼庫或其他系統(tǒng)，并向客戶端宣傳其功能。

MCP的設(shè)計靈感來源于在IDE中使用的語言服務(wù)器協(xié)議（LSP）。就像LSP標(biāo)準(zhǔn)化了編輯器如何查詢語言特性一樣，MCP標(biāo)準(zhǔn)化了LLM如何查詢上下文工具。通過使用通用的JSON-RPC 2.0消息格式，任何遵循MCP的客戶端和服務(wù)器都可以實(shí)現(xiàn)互操作，無論使用何種編程語言或LLM。

MCP的技術(shù)設(shè)計與架構(gòu)

消息傳遞機(jī)制

MCP依賴于JSON-RPC 2.0來傳遞三種類型的消息：請求、響應(yīng)和通知。這使得代理可以執(zhí)行同步工具調(diào)用，同時接收異步更新。在本地部署中，客戶端通常會啟動一個子進(jìn)程，并通過標(biāo)準(zhǔn)輸入/輸出（stdio傳輸）進(jìn)行通信。相比之下，遠(yuǎn)程服務(wù)器通常使用HTTP與服務(wù)器發(fā)送事件（SSE）來實(shí)時流式傳輸消息。這種靈活的消息傳遞層確保了工具可以被調(diào)用，并且結(jié)果可以返回，而不會阻塞主機(jī)應(yīng)用程序的主工作流程。

標(biāo)準(zhǔn)化實(shí)體

根據(jù)MCP規(guī)范，每個服務(wù)器都暴露三種標(biāo)準(zhǔn)化的實(shí)體：資源、工具和提示。

• 資源（Resources）：可獲取的上下文片段，例如文本文件、數(shù)據(jù)庫表或緩存文檔，客戶端可以通過ID檢索它們。
• 工具（Tools）：具有明確定義輸入和輸出模式的命名函數(shù)，無論是搜索API、計算器還是自定義數(shù)據(jù)處理例程。
• 提示（Prompts）：可選的、更高層次的模板或工作流，用于指導(dǎo)模型進(jìn)行多步驟交互。

通過為每個實(shí)體提供JSON模式，MCP使得任何有能力的大型語言模型（LLM）都可以解釋并調(diào)用這些功能，而無需專門的解析或硬編碼集成。

模塊化設(shè)計

MCP架構(gòu)清晰地將職責(zé)分離到三個角色中。主機(jī)嵌入LLM并協(xié)調(diào)對話流程，將用戶查詢傳遞到模型中，并處理其輸出。客戶端實(shí)現(xiàn)了MCP協(xié)議本身，管理所有消息序列化、身份驗證和傳輸細(xì)節(jié)。服務(wù)器宣傳可用資源和工具，執(zhí)行傳入請求（例如列出工具或執(zhí)行查詢），并返回結(jié)構(gòu)化結(jié)果。這種模塊化設(shè)計，將AI和UI集成在主機(jī)中，協(xié)議邏輯在客戶端中，執(zhí)行在服務(wù)器中，確保了系統(tǒng)的可維護(hù)性、可擴(kuò)展性和易于演進(jìn)。

MCP的交互模型與代理工作流

使用MCP的代理遵循一個簡單的發(fā)現(xiàn)和執(zhí)行模式。當(dāng)代理連接到MCP服務(wù)器時，它首先調(diào)用??list_tools()???方法，以檢索所有可用的工具和資源?？蛻舳穗S后將這些描述集成到LLM的上下文中（例如，通過將它們格式化為提示）。此時，模型已經(jīng)知道這些工具的存在以及它們所需的參數(shù)。當(dāng)代理決定使用某個工具（通常是受到用戶查詢的觸發(fā)）時，LLM會發(fā)出一個結(jié)構(gòu)化的調(diào)用（例如，一個包含??"call": "tool_name", "args": {...}???的JSON對象）。主機(jī)識別這是一個工具調(diào)用，客戶端隨后向服務(wù)器發(fā)出相應(yīng)的??call_tool()??請求。服務(wù)器執(zhí)行工具并返回結(jié)果，客戶端再將這個結(jié)果輸入到模型的下一個提示中，使其看起來像是額外的上下文。

這種工作流取代了脆弱的臨時解析方式。代理SDK會在每次運(yùn)行代理時調(diào)用MCP服務(wù)器的??list_tools()???方法，使LLM能夠了解服務(wù)器上的工具。當(dāng)LLM調(diào)用工具時，SDK會在后臺調(diào)用服務(wù)器的??call_tool()??函數(shù)。這個協(xié)議透明地處理了發(fā)現(xiàn)→提示→工具→響應(yīng)的循環(huán)。此外，MCP還支持可組合的工作流。服務(wù)器可以定義多步驟的提示模板，其中一個工具的輸出可以作為另一個工具的輸入，從而使代理能夠執(zhí)行復(fù)雜的序列。未來版本的MCP和相關(guān)SDK將增加諸如長會話、有狀態(tài)交互和計劃任務(wù)等功能。

MCP的實(shí)現(xiàn)與生態(tài)系統(tǒng)

實(shí)現(xiàn)語言無關(guān)性

MCP是一個實(shí)現(xiàn)無關(guān)的協(xié)議。官方規(guī)范在GitHub上維護(hù)，同時提供了多種語言的SDK，包括TypeScript、Python、Java、Kotlin和C#。開發(fā)者可以使用他們喜歡的技術(shù)棧編寫MCP客戶端或服務(wù)器。例如，OpenAI的代理SDK提供了類，使得從Python輕松連接到標(biāo)準(zhǔn)MCP服務(wù)器成為可能。InfraCloud的教程展示了如何設(shè)置一個基于Node.js的文件系統(tǒng)MCP服務(wù)器，從而使LLM能夠瀏覽本地文件。

開源服務(wù)器與生態(tài)系統(tǒng)

越來越多的MCP服務(wù)器已經(jīng)作為開源項目發(fā)布。Anthropic發(fā)布了許多流行服務(wù)的連接器，包括Google Drive、Slack、GitHub、Postgres、MongoDB以及使用Puppeteer的網(wǎng)絡(luò)瀏覽等。一旦一個團(tuán)隊為Jira或Salesforce構(gòu)建了一個服務(wù)器，任何符合標(biāo)準(zhǔn)的代理都可以使用它，無需重新開發(fā)。在客戶端/主機(jī)方面，許多代理平臺已經(jīng)集成了MCP支持。例如，Claude Desktop可以連接到MCP服務(wù)器，Google的代理開發(fā)工具包將MCP服務(wù)器作為Gemini模型的工具提供者，Cloudflare的代理SDK增加了McpAgent類，使得任何FogLAMP都可以成為具有內(nèi)置身份驗證支持的MCP客戶端。即使是像Auto-GPT這樣的自動代理也可以接入MCP：代理不再需要為每個API編寫特定的函數(shù)，而是使用MCP客戶端庫來調(diào)用工具。這種向通用連接器的趨勢，預(yù)示著一個更加模塊化的自主代理架構(gòu)。

在實(shí)踐中，這個生態(tài)系統(tǒng)使得任何給定的AI助手都可以同時連接到多個數(shù)據(jù)源。我們可以想象一個代理，在一次會話中，使用一個MCP服務(wù)器訪問企業(yè)文檔，另一個用于CRM查詢，還有一個用于設(shè)備上的文件搜索。MCP甚至能夠優(yōu)雅地處理命名沖突：如果兩個服務(wù)器都有一個名為“analyze”的工具，客戶端可以對它們進(jìn)行命名空間劃分（例如，“ImageServer.analyze”與“CodeServer.analyze”），從而使兩者都能被使用而不會發(fā)生沖突。

MCP相較于傳統(tǒng)范式的優(yōu)勢

MCP帶來了許多傳統(tǒng)方法所缺乏的關(guān)鍵優(yōu)勢：

標(biāo)準(zhǔn)化集成

MCP為所有工具提供了一個單一協(xié)議。在過去，每個框架或模型都有自己的工具定義方式，而MCP使得工具服務(wù)器和客戶端能夠就JSON模式達(dá)成一致。這消除了為每個模型或每個代理編寫單獨(dú)連接器的需求，簡化了開發(fā)流程，并消除了為每個工具輸出編寫自定義解析邏輯的需要。

動態(tài)工具發(fā)現(xiàn)

代理可以在運(yùn)行時通過調(diào)用??list_tools()??動態(tài)發(fā)現(xiàn)工具，學(xué)習(xí)可用功能。當(dāng)添加新工具時，無需重啟或重新編程模型。這種靈活性與那些在啟動時就將可用工具硬編碼的框架形成了鮮明對比。

互操作性與復(fù)用性

由于MCP是模型無關(guān)的，同一個工具服務(wù)器可以為多個LLM客戶端提供服務(wù)。通過MCP，組織可以為服務(wù)實(shí)現(xiàn)一個連接器，并使其與任何符合標(biāo)準(zhǔn)的LLM一起工作，從而避免了供應(yīng)商鎖定，減少了重復(fù)的工程工作。

可擴(kuò)展性與維護(hù)性

MCP極大地減少了重復(fù)工作。開發(fā)者不再需要為十個模型編寫十個不同的文件搜索函數(shù)，而是編寫一個MCP文件搜索服務(wù)器。對該服務(wù)器的更新和修復(fù)將使所有模型中的所有代理受益。

可組合生態(tài)系統(tǒng)

MCP使得獨(dú)立開發(fā)的服務(wù)器能夠形成一個市場。公司可以發(fā)布其軟件的MCP連接器，允許任何AI與他們的數(shù)據(jù)集成。這鼓勵了一個類似于Web API的開放連接器生態(tài)系統(tǒng)。

安全性與控制

該協(xié)議支持清晰的授權(quán)流程。MCP服務(wù)器描述其工具和所需權(quán)限范圍，主機(jī)在暴露數(shù)據(jù)之前必須獲得用戶同意。這種明確的方法提高了可審計性和安全性，與自由形式的提示相比有了顯著提升。

MCP的行業(yè)影響與實(shí)際應(yīng)用場景

MCP的采用正在迅速增長。主要供應(yīng)商和框架已經(jīng)公開投資于MCP或相關(guān)代理標(biāo)準(zhǔn)。組織正在探索將MCP用于將內(nèi)部系統(tǒng)（如CRM、知識庫和分析平臺）集成到AI助手中。

開發(fā)者工具

代碼編輯器和搜索平臺（如Zed、Replit、Sourcegraph）利用MCP使助手能夠查詢代碼庫、文檔和提交歷史，從而提供更豐富的代碼補(bǔ)全和重構(gòu)建議。

企業(yè)知識與聊天機(jī)器人

幫助臺機(jī)器人可以通過MCP服務(wù)器訪問Zendesk或SAP數(shù)據(jù)，回答有關(guān)開放工單的問題，或基于實(shí)時企業(yè)數(shù)據(jù)生成報告，所有這些都具有內(nèi)置授權(quán)和審計跟蹤。

增強(qiáng)檢索增強(qiáng)生成

RAG代理可以將基于嵌入的檢索與專門的MCP工具（如數(shù)據(jù)庫查詢或圖搜索）結(jié)合起來，從而克服LLM在事實(shí)準(zhǔn)確性和算術(shù)方面的局限性。

主動助手

事件驅(qū)動的代理通過MCP調(diào)用日歷和筆記工具，監(jiān)控電子郵件或任務(wù)流，自動安排會議或總結(jié)行動項目。

在每種情況下，MCP都使得代理能夠在不同的系統(tǒng)之間無縫擴(kuò)展，無需重寫集成代碼，提供了可維護(hù)、安全且互操作的AI解決方案。

與傳統(tǒng)范式的比較

與ReAct對比

ReAct風(fēng)格的提示將操作指令直接嵌入到自由文本中，需要開發(fā)者解析模型輸出并手動處理每個動作。而MCP為模型提供了一個使用JSON模式的正式接口，使客戶端能夠無縫管理執(zhí)行。

與Toolformer對比

Toolformer將工具知識與模型的訓(xùn)練數(shù)據(jù)綁定在一起，需要重新訓(xùn)練才能支持新工具。而MCP將工具接口完全從模型中分離出來，能夠在無需重新訓(xùn)練的情況下零樣本支持任何注冊工具。

與框架庫對比

像LangChain這樣的庫簡化了代理循環(huán)的構(gòu)建，但仍然需要硬編碼連接器。而MCP將集成邏輯轉(zhuǎn)移到一個可復(fù)用的協(xié)議中，使代理更加靈活，減少了代碼重復(fù)。

與自主代理對比

Auto-GPT代理通常將工具包裝器和循環(huán)邏輯嵌入到Python腳本中。通過使用MCP客戶端，這些代理無需為新服務(wù)編寫特定代碼，而是依賴于動態(tài)發(fā)現(xiàn)和JSON-RPC調(diào)用。

與函數(shù)調(diào)用API對比

盡管現(xiàn)代LLM API提供了函數(shù)調(diào)用能力，但它們?nèi)匀皇翘囟ㄓ谀Ｐ偷?，并且僅限于單輪交互。MCP將函數(shù)調(diào)用推廣到任何客戶端和服務(wù)器之間，支持流式傳輸、發(fā)現(xiàn)和多路復(fù)用服務(wù)。

MCP統(tǒng)一并擴(kuò)展了以往的方法，提供了一個單一協(xié)議，實(shí)現(xiàn)了動態(tài)發(fā)現(xiàn)、標(biāo)準(zhǔn)化模式和跨模型互操作性。

MCP的局限性與挑戰(zhàn)

盡管MCP具有巨大的潛力，但它仍在不斷成熟中：

身份驗證與授權(quán)

規(guī)范將身份驗證方案留給了實(shí)現(xiàn)者。當(dāng)前的解決方案需要在外部添加OAuth或API密鑰，這可能會在沒有統(tǒng)一身份驗證標(biāo)準(zhǔn)的情況下使部署變得復(fù)雜。

多步驟工作流

MCP專注于離散的工具調(diào)用。協(xié)調(diào)長運(yùn)行、有狀態(tài)的工作流通常仍然依賴于外部調(diào)度器或提示鏈，因為協(xié)議缺乏內(nèi)置的會話概念。

大規(guī)模發(fā)現(xiàn)

在大型環(huán)境中管理許多MCP服務(wù)器端點(diǎn)可能會很繁瑣。提出的解決方案包括知名URL、服務(wù)注冊表和中央連接器市場，但這些尚未標(biāo)準(zhǔn)化。

生態(tài)系統(tǒng)成熟度

MCP是相對較新的，因此并非每個工具或數(shù)據(jù)源都有現(xiàn)有的連接器。開發(fā)者可能需要為特定系統(tǒng)構(gòu)建自定義服務(wù)器，盡管協(xié)議的簡單性使得這項工作相對較少。

開發(fā)開銷

對于單一、簡單的工具調(diào)用，MCP的設(shè)置可能感覺比直接API調(diào)用更繁瑣。MCP的好處主要體現(xiàn)在多工具、長期生產(chǎn)系統(tǒng)中，而不是短期實(shí)驗中。

許多這些差距已經(jīng)由貢獻(xiàn)者和供應(yīng)商解決，計劃增加標(biāo)準(zhǔn)化的身份驗證擴(kuò)展、會話管理和發(fā)現(xiàn)基礎(chǔ)設(shè)施。

結(jié)語：MCP開啟AI代理的新時代

Model Context Protocol（MCP）是AI代理設(shè)計中的一個重要里程碑。它為LLM訪問外部工具和數(shù)據(jù)源提供了一個統(tǒng)一、可擴(kuò)展且互操作的解決方案。通過標(biāo)準(zhǔn)化發(fā)現(xiàn)、調(diào)用和消息傳遞，MCP消除了為每個模型或框架編寫自定義連接器的需求，使代理能夠無縫集成各種服務(wù)。早期采用者已經(jīng)在開發(fā)工具、企業(yè)聊天機(jī)器人和主動助手等領(lǐng)域中獲得了MCP帶來的可維護(hù)性、可擴(kuò)展性和安全性的好處。隨著MCP的不斷發(fā)展，增加更豐富的身份驗證、會話支持和注冊服務(wù)，它有望成為AI連接的通用標(biāo)準(zhǔn)，就像HTTP對網(wǎng)絡(luò)所做的那樣。對于研究人員、開發(fā)者和技術(shù)領(lǐng)導(dǎo)者來說，MCP為更強(qiáng)大、靈活且面向未來的AI解決方案打開了大門。

本文轉(zhuǎn)載自公眾號Halo咯咯    作者：基咯咯

原文鏈接：??https://mp.weixin.qq.com/s/4pnApsLRBA9G1f62G9lJTQ??