“ 網(wǎng)絡協(xié)議的本質是一種有固定格式的規(guī)則約束?！?/strong>

最近在研究MCP協(xié)議，由于之前深入了解過網(wǎng)絡協(xié)議這一塊，比如說TCP/IP，HTTP等，所以對MCP協(xié)議就比較好奇，于是就深入了解了一下。

剛開始了解MCP協(xié)議的時候就很奇怪一件事情，不管是TCP/IP協(xié)議，還是HTTP協(xié)議，都會有一個固定的報文格式；但在MCP的官方文檔中并沒有看到這個報文格式。只是簡單介紹了其幾個核心組件——hosts，client和server等。

所以就很好奇，MCP協(xié)議沒有一個固定的格式，那它服務端和客戶端是怎么通訊的，數(shù)據(jù)怎么解析的。

MCP協(xié)議的深入了解

從本質上來說，網(wǎng)絡協(xié)議就是一種規(guī)則，只不過這個規(guī)則有固定的格式；就類似于我們發(fā)快遞，發(fā)郵件一樣，需要有收件人姓名，地址，電話等；而TCP/IP和HTTP這種網(wǎng)絡協(xié)議就是嚴格按照這種規(guī)則設計的。

但在MCP協(xié)議中，這種規(guī)則好像并不存在；所以這些問題只能從MCP的官方文檔中尋找答案。

思考一個問題，MCP協(xié)議是怎么進行數(shù)據(jù)傳輸?shù)?，也就是說在智能體中使用MCP協(xié)議，那數(shù)據(jù)怎么從智能體傳輸?shù)組CP服務端？它的數(shù)據(jù)格式是什么樣的，客戶端應該怎么封裝請求數(shù)據(jù)，服務端應該怎么解析數(shù)據(jù)？

從官方文檔中我們了解到，MCP協(xié)議是整體建立在JSON-RPC2.0的基礎之上；JSON-RPC2.0是一種輕量級無狀態(tài)的遠程調用協(xié)議，簡單來說就是一種數(shù)據(jù)格式。而MCP使用JSON-RPC2.0作為協(xié)議層進行通訊，傳輸層可以使用http，sse，Streamable http等流式協(xié)議，以及本地開發(fā)測試使用的stdio協(xié)議。

而且，用戶可以根據(jù)自己的需求自定義傳輸層協(xié)議，只需要上層使用JSON-RPC2.0格式即可；也就是說MCP對傳輸層協(xié)議是無感的。

這樣做的好處就是，MCP協(xié)議完全屏蔽了底層網(wǎng)絡協(xié)議的復雜性，開發(fā)者只需要關注應用層的協(xié)議即可，需要說明的是這里的應用層和TCP/IP網(wǎng)絡模型中的應用層不是一個概念，在TCP/IP網(wǎng)絡模型中HTTP協(xié)議屬于應用層協(xié)議。

看到這里大家可能有疑問了，你這也沒講MCP協(xié)議的格式是什么樣啊，或者為什么MCP協(xié)議沒有固定格式。

其實，這里就是MCP協(xié)議比較強大的一個地方，MCP協(xié)議并不像傳統(tǒng)的網(wǎng)絡協(xié)議那樣，嚴格約束協(xié)議的格式規(guī)則，而是提供了很大的靈活性；在使用JSON-RPC2.0屏蔽底層協(xié)議的基礎之上；開發(fā)者可以在JSON-RPC2.0的基礎之上，去自定義自己的MCP報文格式，只不過需要開發(fā)者自己實現(xiàn)服務端和客戶端的報文解析功能；而MCP官方已經(jīng)封裝了一套基于JSON-RPC2.0的數(shù)據(jù)報文格式。

對我們普通開發(fā)者來說，只需要直接拿過來用就行了，而不用關心其底層的實現(xiàn)原理。MCP官方通過schema的方式抽象出MCP協(xié)議的格式對象，這樣在上層應用中就可以直接獲取到結構化的數(shù)據(jù)。

# JSON RPC的請求格式
{
  jsonrpc: "2.0";
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}


# JSON-RPC的響應格式
{
  jsonrpc: "2.0";
  id: string | number;
  result?: {
    [key: string]: unknown;
  }
  error?: {
    code: number;
    message: string;
    data?: unknown;
  }
}

MCP官方文檔地址

??https://modelcontextprotocol.io/introduction??

?

本文轉載自??AI探索時代??? 作者：DFires