探索 MCP 和 A2A 協議：本質上新協議都基于 HTTP的

以下是以 CSDN 博客的形式記錄你對 MCP 協議和 A2A 協議數據傳遞的理解，重點探討了它們為何基于 HTTP 協議、HTTP 的優勢，以及數據傳輸的本質。文章面向技術社區，結構清晰，適合分享。

探索 MCP 和 A2A 協議：為何新協議都基于 HTTP？

作者：[你的用戶名]
日期：2025-04-13
標簽：MCP 協議、A2A 協議、HTTP、JSON-RPC、數據傳遞

背景

最近在研究 MCP（Model Context Protocol）和 A2A（Agent2Agent）協議，探索它們如何實現 AI 代理的自動化任務和代理間協作。我注意到，這兩個協議的底層傳輸都基于 HTTP，這讓我意識到：數據傳輸本質上還是要通過網絡進行，而 HTTP 作為一種成熟的網絡傳輸協議，成為了許多新協議的首選基礎。這篇文章記錄了我的發現，分析了 MCP 和 A2A 協議為何基于 HTTP，以及 HTTP 在現代協議中的核心作用。

發現過程

1. MCP 協議的底層傳輸：HTTP 的角色

MCP 是一個為 AI 代理設計的協議，允許 AI 代理安全地訪問外部工具和數據源（例如文件系統）。通過研究，我發現 MCP 的數據傳遞完全依賴 HTTP 協議（）。

1.1 MCP 的 HTTP 請求和響應

MCP 服務器監聽一個 HTTP 端點（例如 http://localhost:8000/mcp），AI 代理通過 HTTP POST 請求發送 JSON-RPC 格式的數據，服務器返回 HTTP 響應。以下是一個典型的 MCP 請求和響應：

HTTP 請求（調用 list_files 工具）：

POST /mcp HTTP/1.1
Host: localhost:8000
Content-Type: application/json{"jsonrpc": "2.0","id": 1,"method": "tools/call","params": {"name": "list_files","arguments": {"path": "/path/to/cache"}}
}

HTTP 響應：

HTTP/1.1 200 OK
Content-Type: application/json{"jsonrpc": "2.0","id": 1,"result": {"files": [{"name": "temp1.log", "path": "/path/to/cache/temp1.log", "mtime": "2025-03-01T12:00:00Z"},{"name": "temp2.log", "path": "/path/to/cache/temp2.log", "mtime": "2025-04-01T12:00:00Z"}]}
}

關鍵點：

MCP 的數據傳輸依賴于網絡，HTTP 提供了底層的傳輸通道。
在 HTTP 之上，MCP 使用 JSON-RPC 2.0 協議定義請求和響應的格式（）。

2. 為什么新協議（如 MCP、A2A）基于 HTTP？

我觀察到，不僅 MCP，很多現代協議（包括 A2A 協議）都選擇在 HTTP 之上構建（）。以下是原因：

2.1 HTTP 的廣泛支持和成熟性

基礎設施支持：HTTP 是互聯網的基礎協議，幾乎所有的網絡設備、服務器和客戶端（瀏覽器、應用程序）都支持 HTTP（）。基于 HTTP 的協議可以無縫運行在現有的網絡基礎設施上。
工具生態：HTTP 有豐富的工具支持，例如：
- 服務器：Nginx、Apache 等。
- 客戶端：cURL、Postman、各種編程語言的 HTTP 庫（Python 的 requests、JavaScript 的 fetch）。
- 調試工具：Wireshark、Fiddler 等。
安全性：HTTP 支持 HTTPS（基于 TLS/SSL），可以輕松實現加密通信。

MCP 的例子：

MCP 服務器可以運行在任何支持 HTTP 的環境中，例如 Node.js 或 Python Flask。
AI 代理可以使用標準的 HTTP 客戶端庫發送請求，無需額外的網絡支持。

2.2 HTTP 的靈活性和擴展性

傳輸層無關性：HTTP 不關心上層的數據格式（JSON、XML、純文本等），這使得它非常適合作為新協議的底層傳輸層。
通信模式支持：
- 請求-響應：HTTP 的基本模式，適合 MCP 的同步工具調用（例如 list_files）。
- 長連接和推送：HTTP 支持 WebSocket 和 Server-Sent Events（SSE），可以實現實時通信。MCP 和 A2A 都利用了 SSE 來支持任務狀態的實時更新（）。
擴展性：HTTP 支持多種方法（GET、POST、PUT、DELETE 等）和頭字段，可以滿足不同的通信需求。

MCP 和 A2A 的例子：

MCP 使用 HTTP POST 傳輸 JSON-RPC 請求，適合結構化的工具調用。
A2A 使用 SSE 進行任務狀態推送（），這是 HTTP 的擴展功能。

2.3 標準化和互操作性

標準化：HTTP 是標準化的協議（由 IETF 定義，例如 HTTP/1.1、HTTP/2），有明確的規范，確保了不同系統之間的互操作性。
JSON 的普及：現代協議通常使用 JSON 作為數據格式（），而 HTTP 非常適合傳輸 JSON 數據（通過 Content-Type: application/json）。
跨平臺：基于 HTTP 的協議可以在任何支持 HTTP 的平臺上運行。

MCP 的例子：

MCP 使用 JSON-RPC 2.0 作為上層協議，JSON-RPC 的請求和響應通過 HTTP 傳輸，確保了跨平臺的兼容性。

2.4 開發和調試的便利性

易于開發：HTTP 協議簡單，開發人員可以快速構建基于 HTTP 的協議。
易于調試：HTTP 請求和響應是文本格式（尤其是 JSON），可以用工具（如 Postman）直接查看和調試。

MCP 的例子：

開發人員可以用 cURL 測試 MCP 服務器的端點：

bash

curl -X POST http://localhost:8000/mcp \-H "Content-Type: application/json" \-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_files","arguments":{"path":"/path/to/cache"}}}'

3. MCP 和 A2A 的數據傳輸：HTTP 的具體應用

3.1 MCP 的數據傳輸

MCP 專注于 AI 代理與外部工具的交互（例如文件系統）。其數據傳輸流程如下：

AI 代理發送 HTTP POST 請求，調用工具（例如 list_files）。
MCP 服務器解析 JSON-RPC 請求，執行操作，返回 JSON-RPC 響應。
如果任務較長，MCP 支持通過 SSE 推送任務狀態（）。

MCP 的 SSE 示例：

AI 代理訂閱任務狀態：

GET /mcp/sse HTTP/1.1
Host: localhost:8000
Accept: text/event-stream

服務器推送更新：

event: TaskStatusUpdateEvent
data: {"taskId": "task-001", "status": "working"}

3.2 A2A 的數據傳輸

A2A 專注于代理之間的通信，數據傳輸也基于 HTTP（）：

代理通過 HTTP POST 發送 tasks/send 請求。
目標代理處理任務，返回任務狀態。
A2A 支持 SSE 和推送通知（push notifications）（）。

A2A 的推送通知示例：

代理設置推送通知的 webhook：

json

{"jsonrpc": "2.0","id": 1,"method": "tasks/pushNotification/set","params": {"webhookUrl": "https://client.example.com/webhook"}
}

服務器通過 HTTP POST 推送更新：

POST /webhook HTTP/1.1
Host: client.example.com
Content-Type: application/json{"taskId": "task-001","status": "completed"
}

發現：

MCP 和 A2A 都依賴 HTTP 進行數據傳輸，但通信模式不同：
- MCP 更注重同步工具調用（請求-響應）。
- A2A 更注重異步任務協作（通過 SSE 和推送通知）。

4. 為什么新協議不直接使用更底層的協議（如 TCP）？

我曾好奇，既然 HTTP 基于 TCP，為什么新協議不直接使用 TCP？以下是原因：

4.1 HTTP 提供了更高的抽象層

TCP 的復雜性：TCP 只負責字節流的傳遞，開發者需要自己定義數據格式、消息邊界、錯誤處理等。
HTTP 的便利性：HTTP 定義了請求-響應模式、狀態碼、頭字段等，開發者只需關注數據內容（例如 JSON）。

MCP 的例子：

如果 MCP 直接基于 TCP，開發者需要自己實現消息的序列化和反序列化。
使用 HTTP，MCP 可以直接利用 HTTP 的請求-響應模式。

4.2 HTTP 的生態支持

防火墻和代理：HTTP 流量（端口 80 和 443）通常被防火墻和代理允許，而 TCP 可能需要開放額外端口。
負載均衡：HTTP 支持負載均衡（例如通過 Nginx），適合分布式系統。

4.3 HTTP 的擴展性

HTTP 支持多種通信模式（請求-響應、SSE、WebSocket）。
HTTP/2 和 HTTP/3（基于 QUIC）進一步提高了性能。

MCP 和 A2A 的例子：

MCP 和 A2A 利用 HTTP 的 SSE 實現實時推送（），如果直接使用 TCP，需要自己實現類似功能。

5. 總結：HTTP 是新協議的理想基礎

通過分析，我總結了 MCP 和 A2A 基于 HTTP 的原因：

HTTP 的成熟性和廣泛支持：HTTP 是互聯網的基礎協議，基礎設施和工具支持完善。
靈活性和擴展性：HTTP 支持多種通信模式（請求-響應、SSE、WebSocket）。
標準化和互操作性：HTTP 和 JSON 的組合提供了標準化的數據傳輸方式。
開發和調試的便利性：HTTP 協議簡單，易于開發和調試。

MCP 數據傳輸的本質：

MCP 的底層傳輸是 HTTP，通過網絡進行數據傳遞。
在 HTTP 之上，MCP 使用 JSON-RPC 2.0 定義結構化的請求和響應。
MCP 的數據傳輸與 HTTP API 類似，請求體是 JSON-RPC 格式。

A2A 的相似之處：

A2A 也基于 HTTP，使用 JSON-RPC 進行通信，但更注重代理協作，支持 SSE 和推送通知。

我的觀察：我提到“數據傳輸還是要通過網絡進行的，所以好多新的協議都是在此基礎上進行的”，這非常正確！HTTP 提供了一個可靠、靈活的基礎，新協議可以在此基礎上定義更高層次的邏輯（例如 JSON-RPC、任務管理），從而專注于功能實現，而無需重新發明底層的傳輸機制。

未來計劃

抓包分析：使用 Wireshark 或 Postman 抓取 MCP 的 HTTP 請求和響應，觀察 JSON-RPC 的結構。
運行 MCP 服務器：啟動一個 MCP 文件系統服務器（例如 npx -y @modelcontextprotocol/server-filesystem /path/to/cache），手動發送 HTTP 請求，查看響應。
對比其他協議：研究其他基于 HTTP 的協議（例如 gRPC、GraphQL），理解它們如何利用 HTTP。

如果你對 MCP、A2A 或 HTTP 相關技術有更多想法，歡迎留言討論！

參考資料