隨著AI技術(shù)的快速發(fā)展，智能體（Agent）和上下文協(xié)議（MCP）正成為推動AI應(yīng)用落地的關(guān)鍵技術(shù)。本文從Agent的概念出發(fā)，詳細介紹了其背后的組成要素，包括“大腦”（LLM）、“眼睛和手”（外部工具接口）以及“工作紀要”（上下文窗口）。同時，文章深入探討了MCP協(xié)議的重要性，將其比作AI領(lǐng)域的“USB-C接口”，能夠標準化地連接AI模型與外部工具和數(shù)據(jù)源。

這幾天，Agent 的相關(guān)概念沸沸揚揚。

不做詞義追源，僅從大眾角度，這個事兒是前年初開始的，也就是 2023 年 2-3 月。標志性事件包括：

• AutoGPT 等開源項目的發(fā)布：這是第一批基于自然語言的 AI 自動化實踐：你告訴它一個任務(wù)，它就會通過自然語言的自我對話，將這個任務(wù)進行拆分、規(guī)劃并實現(xiàn)。你可以認為這是 Manus 的前輩：成功率極很低，能干的事兒很少
• 斯坦福小鎮(zhèn)一類的項目實踐：給予不同的 Bot 以不同的人格，搭配記憶窗口，讓它們之間相互對話。
• 發(fā)表于 2 月的論文《Toolformer: 大模型可以教自己使用工具》，以及 OpenAI 在 3 月底發(fā)布的插件計劃：這意味著，大模型從原來的“思想家”，通過對外部工具的使用，變成了實干家。

《AI 學會使用工具了》

2023年2月14日，報道自賽博禪心

由于語言泛化，今天出現(xiàn)了很有趣的現(xiàn)象：「Agent 是什么」，這個問題沒有了標準的定義。

一個常見的觀點是：Agent 是一種讓 AI 以類似人的工作和思考方式，來完成一系列的任務(wù)。一個 Agent 可以是一個 Bot，也可以是多個 Bot 的協(xié)同。就像是職場里，簡單的工作獨立完成，復(fù)雜的工作協(xié)作完成一樣。

對于每個 Bot 來說，可能會包括：

• 一個大腦：判斷和規(guī)劃行為，這里通常需要 GPT-4或更高水平的 LLM；
• 眼睛和手：確認信息和使用外部工具，一般是各種插件/action/api；
• 工作紀要：儲存已經(jīng)發(fā)生的事，通常的媒介是上下文窗口，或者一個 todo 文件，也或者數(shù)據(jù)庫；
• 行為SOP：明確這個 Agent 的身份、任務(wù)、目標和機制。這個 SOP 可能是用戶給的，也可能是由其它 Bot 給出的。

再具象一點，這里我從 GPTs 里截了個圖：

GPTs，通常被認為是由 OpenAI 設(shè)計的最簡版的 Agent。默認情況下，只能進行單 Bot 交互：

• 一個大腦：在 ChatGPT GPT Store 里，GPT-4 是唯一可選的 LLM；
• 眼睛和手：可以在 Capabilities 里勾選由 OpenAI 提供的第一方能力，也可以通過Actions 來拓展更多的外部能力；
• 工作紀要：一般來說就是對話記錄，GPTs 可以回顧之前的對話，；
• 行為SOP：存放在 Description, Instructions 以及 Knowledge 里。
• 在這里，大腦鏈接眼睛和手，需要一種神經(jīng)信號，代碼里叫做協(xié)議。

最早的協(xié)議是 OpenAI Plugin 協(xié)議，發(fā)布于 2 年前的差不多這個時候，定向邀請。

之后 Anthropic 在去年發(fā)布了 MCP 協(xié)議，是公開版的

當時我也做了個短評：

類比來說，可理解為 Claude 桌面版的插件系統(tǒng)（類比 OAI 去年3月的發(fā)布），不同點在于：
– Claude 的插件，暫還不能共享
– 只能在「Claude 桌面版」（網(wǎng)頁版不行）、「Zed」、「Cody」里面使用
– 沒有更新到接口（仍然沒有正式的 Function Calling / JSON Mode / Sturctured Output）
– 早期版本，很多東西還是餅，比如 Sampling
從進步角度，一定程度上解決了 Claude 不能輸出結(jié)構(gòu)化信息的問題：之前 Claude 想要結(jié)構(gòu)化輸出，只能 prompt + prefill + regex
公眾號：賽博禪心
短評Claude 發(fā)布的 MCP 協(xié)議

而下面，就讓我們一起來看看這個 MCP 協(xié)議。

Norah Sakal 寫了一篇不錯的介紹，寶玉進行了翻譯

什么是模型上下文協(xié)議（MCP）？它如何比傳統(tǒng)API更簡單地集成AI？

https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained/

模型上下文協(xié)議（Model Context Protocol，簡稱MCP） 是一種全新的開放協(xié)議，專門用于標準化地為大語言模型（LLMs）提供應(yīng)用場景和數(shù)據(jù)背景。

你可以把MCP想象成AI領(lǐng)域的“USB-C接口”，它能讓不同的AI模型與外部工具和數(shù)據(jù)源輕松連接。

本文將清晰地解釋MCP的價值、工作原理，以及它與傳統(tǒng)API的關(guān)鍵區(qū)別。

什么是MCP？

模型上下文協(xié)議（MCP） 就像是為AI模型量身定制的“USB-C接口”，可以標準化地連接AI系統(tǒng)與各類外部工具和數(shù)據(jù)源。

什么是MCP？

就像USB-C接口讓你的電腦更容易連接各種設(shè)備一樣，MCP讓AI模型更簡單地獲取數(shù)據(jù)、工具與服務(wù)。

為什么要用MCP，而不是傳統(tǒng)的API？

通常，AI系統(tǒng)想連接外部工具時，需要單獨整合多個不同的API。每個API都有獨立的代碼、文檔、認證方式、錯誤處理和后續(xù)維護，極大地增加了開發(fā)復(fù)雜度。

為什么說傳統(tǒng)API就像每扇門都有一把不同的鑰匙？

打個比方： API就像不同的門，每扇門都需要自己的鑰匙和特定的規(guī)則。

為什么使用MCP而非傳統(tǒng)API？

傳統(tǒng)的API要求開發(fā)者為每個服務(wù)或數(shù)據(jù)源單獨編寫代碼和整合方案。

MCP背后是誰？

MCP最早由Anthropic ↗[1]公司開發(fā)，目的是幫助AI模型（如Claude）更容易地連接工具和數(shù)據(jù)源。

但現(xiàn)在，MCP已經(jīng)成為一個開放協(xié)議，越來越多的企業(yè)和開發(fā)者開始采用它，這也讓它逐漸成為AI與工具互動的新標準。

?? 想深入了解？可以訪問官方的MCP規(guī)格文檔 ↗[2]。

MCP與API快速對比

MCP與傳統(tǒng)API關(guān)鍵區(qū)別：

? 單一協(xié)議： MCP像一個統(tǒng)一接口，只要一次整合，就能連接多個服務(wù)。

? 動態(tài)發(fā)現(xiàn)： AI模型能自動識別并使用可用的工具，不用提前寫死每個接口。

? 雙向通信： MCP支持類似WebSockets的實時雙向通信，模型不僅能查詢數(shù)據(jù)，還能主動觸發(fā)操作。

為什么要有雙向通信？

MCP提供實時互動，模型能：

? 拉取數(shù)據(jù)： 模型實時查詢數(shù)據(jù)，如查看你的日歷。

? 觸發(fā)操作： 模型主動向服務(wù)器發(fā)出指令，如重新安排會議或發(fā)送郵件。

MCP如何工作：架構(gòu)原理

MCP采用簡單的客戶端-服務(wù)器架構(gòu)：

MCP的工作架構(gòu)

? MCP主機（Host）： 如Claude桌面應(yīng)用或智能開發(fā)環(huán)境（IDE），需要訪問外部數(shù)據(jù)或工具。

? MCP客戶端（Client）： 與MCP服務(wù)器建立一對一的穩(wěn)定連接。

? MCP服務(wù)器（Server）： 提供特定功能，連接本地或遠程的數(shù)據(jù)源。

? 本地數(shù)據(jù)源： 文件、數(shù)據(jù)庫或服務(wù)。

? 遠程服務(wù)： 外部API或互聯(lián)網(wǎng)服務(wù)。

簡單說，MCP像一座橋梁： 它本身不處理復(fù)雜邏輯，只負責協(xié)調(diào)AI模型與工具之間的信息流動。

實際中的MCP客戶端案例

比如，一個Python腳本（client.py）作為MCP客戶端，可以輕松連接MCP服務(wù)器，以控制Gmail、Slack或日歷應(yīng)用，無需每個工具單獨編寫代碼。

MCP應(yīng)用案例：什么時候用它？

設(shè)想下面幾個場景：

1. 旅行規(guī)劃助手

? 使用 API 時： 分別為谷歌日歷、郵件、機票預(yù)訂寫代碼，繁瑣而復(fù)雜。

? 使用 MCP 時： AI助手直接通過MCP統(tǒng)一協(xié)議，查看日歷、訂機票、發(fā)郵件確認，無須單獨整合每個工具。

2. 智能IDE（代碼編輯器）

? 使用 API 時： 手動連接文件系統(tǒng)、版本管理、包管理和文檔，耗時費力。

? 使用 MCP 時： IDE 通過 MCP 一次連接所有功能，帶來更豐富的上下文支持，更強大的智能建議。

3. 復(fù)雜的數(shù)據(jù)分析

? 使用 API 時： 人工管理與每個數(shù)據(jù)庫、數(shù)據(jù)可視化工具的連接。

? 使用 MCP 時： AI自動發(fā)現(xiàn)并連接多個數(shù)據(jù)庫和可視化工具，通過統(tǒng)一的MCP接口輕松完成分析任務(wù)。

MCP 的好處

? 簡化開發(fā)： 一次整合，多次復(fù)用，不再重復(fù)開發(fā)。

? 靈活性強： 輕松切換AI模型或工具，無需復(fù)雜的重新配置。

? 實時互動： 長連接保證數(shù)據(jù)實時更新。

? 安全可靠： 內(nèi)置標準化安全和權(quán)限控制。

? 擴展性強： AI系統(tǒng)擴展時，只需連接新的MCP服務(wù)器。

什么時候傳統(tǒng) API 更適合？

如果你的應(yīng)用場景需要精準且嚴格受控的交互方式，那么傳統(tǒng)API可能更合適。MCP提供廣泛而靈活的動態(tài)能力，更適合需要上下文理解的場景，但不一定適用于嚴格受控的場合。

傳統(tǒng)API更合適的場景：

? 需要細粒度控制、功能嚴格限制；

? 更偏好緊耦合以提升性能；

? 希望最大化交互的可預(yù)測性。

如何開始使用MCP？

快速集成MCP的步驟：

1. 定義能力： 明確你的MCP服務(wù)器提供哪些功能。

2. 實現(xiàn)MCP層： 按照協(xié)議標準進行開發(fā)。

3. 選擇通信方式： 本地連接（標準輸入輸出）或遠程連接（如WebSockets）。

4. 創(chuàng)建資源/工具： 開發(fā)或連接你的數(shù)據(jù)源和服務(wù)。

5. 建立客戶端連接： 與MCP服務(wù)器建立安全穩(wěn)定的連接。

總結(jié)

再次回顧什么是MCP：

? MCP： 為AI模型統(tǒng)一連接數(shù)據(jù)與工具的標準接口。

? API： 傳統(tǒng)的方式，每個服務(wù)單獨連接，開發(fā)更復(fù)雜。

什么是MCP？

MCP讓AI與外部數(shù)據(jù)、工具的連接變得更加標準化和高效。

結(jié)論

MCP不僅僅是另一種API，而是一個強大的連接框架，讓AI應(yīng)用能更智能、更動態(tài)地融入豐富的上下文環(huán)境，快速實現(xiàn)復(fù)雜的功能互動。

引用鏈接

[1] Anthropic ↗: https://www.anthropic.com/news/model-context-protocol

[2] MCP規(guī)格文檔 ↗: https://modelcontextprotocol.io/