当前位置：首页 > news >正文

探索 MCP 和 A2A 协议：本质上新协议都基于 HTTP的

news 来源：原创 2025/5/20 6:50:17

以下是以 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 相关技术有更多想法，欢迎留言讨论！

参考资料