作者 | MacManus
出品 | 51CTO技術棧（微信號：blog51cto）
模型上下文協(xié)議 (MCP) 是 AI 代理和 API 之間的橋接技術。我們與 API 管理供應商 Speakeasy 探討了它的用途。
去年 11 月，Anthropic 推出了模型上下文協(xié)議(MCP)，這是一項開源標準，旨在簡化 AI 模型與 API 的交互方式。正如我們本月早些時候所解釋的那樣，其愿景是讓 MCP 成為 AI 代理觸發(fā)外部操作的通用方法。
MCP 在推出的頭幾個月就吸引了很多人的興趣，包括來自Speakeasy等 API 管理公司。API 公司將 MCP 視為連接LLM 和代理框架豐富生態(tài)系統(tǒng)的機制。為了了解更多信息，我采訪了 Speakeasy 首席執(zhí)行官Sagar Batchu。
模型上下文協(xié)議（MCP）？
正如其文檔中所解釋的，MCP“遵循客戶端-服務器架構，其中主機應用程序可以連接到多個服務器”。
本質(zhì)上，MCP 標準化了 AI 代理的 API 訪問。你也可以將其視為meta-API，正如Matt Pocock 的這張圖所示：
MCP 圖解
“因此，MCP 是一種協(xié)議，實際上是 API 之上非常薄的一層，它表示，這是該 API 需要向 LLM 或代理公開的定義，以便能夠查詢并了解有關 [...] 更多信息，無論這些數(shù)據(jù)是什么，”Batchu 解釋道。
MCP 客戶端可以是像 Claude 這樣的 LLM、像 Cursor 和 Windsurf 這樣的 IDE，以及各種其他工具（例如 SpinAI，一個用于構建 AI 代理的 TypeScript 框架）。
至于 MCP 服務器（上圖中的橙色塊），你可以自行構建或使用預構建的 MCP 服務器。Anthropic 在其介紹性博客文章中提到，已經(jīng)有預構建的 MCP 服務器“適用于流行的企業(yè)系統(tǒng)，如 Google Drive、Slack、GitHub、Git、Postgres 和 Puppeteer”。
私人定制版 MCP
構建私人定制版的 MCP 服務器是 Speakeasy 的用武之地。最近，該公司推出了MCP Server Generation，這是一種自動創(chuàng)建 MCP 兼容服務器的工具。
目前，Speakeasy 的 MCP 服務器版本支持基于 TypeScript 的 SDK。但鑒于 Python 在 AI 生態(tài)系統(tǒng)中的主導地位，該公司計劃很快添加 Python 支持。
Batchu 指出，由于 MCP 采用客戶端-服務器模型，因此與 MCP 服務器交互的 AI 代理可以使用任何編程語言。他解釋說，與傳統(tǒng)的 SDK（特定于語言且需要開發(fā)人員編寫集成代碼）不同，MCP 服務器公開了 AI 代理可以直接訪問的端點。
MCP 與 OpenAPI 相比如何？
OpenAPI是定義 API 的廣泛采用的標準，因此乍一看它也是 API 之上的一種層。但據(jù) Batchu 稱，MCP 建立在 OpenAPI 之上，而不是替代它。
“從 OpenAPI 規(guī)范到 MCP 的跨越非常小，”他說。“OpenAPI 在某種程度上是 MCP 所需的所有信息的超集，然后你將其與 LLM 的具體示例和描述打包在一起，并將其作為服務器運行。”
換句話說：雖然 OpenAPI 提供了 API 功能的結構化定義，但它主要是一種靜態(tài)規(guī)范。相比之下，MCP 引入了客戶端-服務器交互模型。MCP 服務器是一個實時運行的實例，AI 代理可以實時查詢。這意味著 MCP 服務器可以動態(tài)響應 AI 生成的請求，使 API 更易于代理工作流訪問。
正如 Batchu 所說，“區(qū)別在于，OpenAPI 規(guī)范只是一個定義，而 MCP 服務器實際上是一種服務器-客戶端體驗。”
在 MCP 出現(xiàn)之前，將 API 與 AI 模型集成一直是一項挑戰(zhàn)。Batchu 指出，許多基于 AI 的 API 集成都失敗了，因為模型缺乏理解 API 響應所需的架構信息。MCP 通過以 AI 可以理解的方式構建 API 交互來解決這個問題，從而使集成更加可靠。
MCP 服務器的實際用例
Batchu 表示，Speakeasy 已經(jīng)有幾個客戶在使用其 MCP 功能集。Vercel、Dub 等公司正在利用 MCP 服務器來增強其 API 驅(qū)動的工作流程。
在鏈接共享平臺 Dub 上，營銷團隊經(jīng)常創(chuàng)建短鏈接來跟蹤文章效果。他們現(xiàn)在無需手動搜索分析儀表板，而是可以要求 AI 助手檢索過去一周點擊次數(shù)最多的鏈接。AI 會查詢 Dub 的 MCP 服務器，獲取相關數(shù)據(jù)，甚至生成可視化效果 — 所有這些都無需用戶離開聊天界面。
Speakeasy 客戶 Dub 使用 MCP
我詢問了潛在的電子商務應用，因為這個領域似乎非常適合人工智能代理。Batchu 建議，想象一下這樣一家公司使用 MCP 來支持人工智能驅(qū)動的商業(yè)智能。人工智能助手可以向 MCP 服務器查詢銷售數(shù)據(jù)、生成報告，甚至根據(jù)實時洞察提出營銷策略。這將減少對手動數(shù)據(jù)提取和分析的需求。
未來將出現(xiàn)競爭標準嗎？
Anthropic 開發(fā)了 MCP，但到目前為止還沒有跡象表明其他人工智能巨頭會采用它 — — 例如 OpenAI、谷歌和 Meta。
Batchu 認為 MCP 范式很可能會與其他 AI 驅(qū)動的 API 方法一起發(fā)展。他指出，OpenAI 的函數(shù)調(diào)用已經(jīng)為 AI 模型提供了一種與外部服務交互的方式，盡管它缺乏 MCP 的標準化、開放性。
他說：“我相信，一段時間內(nèi)會出現(xiàn)一些模式之爭，直到最終形成像 OpenAPI 這樣的標準。”
無論如何，Batchu 認為 API 供應商嘗試 MCP 的時機已經(jīng)成熟。
“API 供應商應該投資 MCP 之類的代理工具，然后創(chuàng)建一個 GitHub repo，構建它，并將其發(fā)布到那里。”
同樣，他認為 API 消費者應該進行嘗試，盡管他承認他們會面臨更多“干擾和混亂”——因為標準仍在不斷變化。但他對負責使用 API 和 AI 的開發(fā)人員提出了一些建議。
“你可以做的第一件事實際上是查看 API 是否有 MCP 服務器。可以將其本地安裝到 IDE 或 LLM 桌面客戶端中，然后實際上只需通過自然語言查詢即可開始集成。”
Batchu 還指出，開發(fā)人員有機會通過使用 MCP 以及LangChain 和 AutoGen 等代理框架來自動化工作流程并從 API 中動態(tài)提取見解。
參考鏈接：https://thenewstack.io/mcp-the-missing-link-between-ai-agents-and-apis/
