MCP - 基础

引言

两人互联领域的重大挑战：

  1. Agent 与 Tools（工具）的交互

    • Agent 需要调用外部工具和APl、访问数据库、执行代码等 ———— MCP

  2. Agent 与 Agent（其他智能体或用户）的交互

    • Agent 需要理解其他 Agent 的意图、协同完成任务、与用户进行自然的对话。 ———— A2A

概念

MCP（Model Context Protocol，模型上下文协议） ，2024年11月底，由Anthropic 推出的一种开放标准。旨在为大语言模型（LLM）提供统一的、标准化方式与外部数据源和工具之间进行通信。

MCP的理解

  • 传统AI集成的问题：这种为每个数据源构建独立连接的方式，可以被视为一个M*N问题。
  • 问题：架构碎片化，难以扩展，限制了AI获取必要上下文信息的能力
  • MCP解决方案：提供统一且可靠的方式来访问所需数据，克服了以往集成方法的局限性。 M*N问题 ———— M+N问题

MCP 作为一种标准化协议，极大地简化了大语言模型与外部世界的交互方式，使开发者能够以统一的方式为 AI 应用添加各种能力。

与其他协议的对比

特性MCPTCPHTTPS
协议层级高层（AI模型上下文协议）传输层应用层（基于 HTTP+TLS）
用途模型与外部工具或上下文交互（如调用函数、插件、API 等）数据包可靠传输加密的网页通信
加密/安全不负责底层加密，但可以嵌套安全机制无加密使用 TLS 加密
依赖关系可能通过 HTTPS/TCP 等协议传输独立协议基于 TCP
使用场景AI 工具调用、agent 系统、LLM 与外部世界连接所有需要可靠数据传输的协议网页、API 安全通信

MCP原理

MCP 三种核心传输机制

  1. Stdio (Standard Input/Output) - 标准输入/输出

    • 适用场景：本地集成。当客户端和服务器运行在同一台机器上时使用，例如命令行工具、本地脚本或访问本地文件。
    • 工作原理：客户端将MCP服务器作为子进程启动。通信通过标准输入（stdin）和标准输出（stdout）进行。客户端向服务器的stdin写入JSON-RPC格式的消息，服务器从stdout读取消息并返回响应。日志信息可以输出到标准错误（stderr）。
    • 优势：
      • 设置简单，无需网络配置。
      • 延迟低，性能优秀。
      • 安全性高（依赖进程隔离）。
      • 资源消耗少。
    • 劣势：
      • 仅限于本地使用，无法跨网络通信。
      • 依赖子进程管理。

  2. Streamable HTTP - 可流式HTTP (推荐用于远程)

    • 适用场景：现代远程MCP服务器的推荐选择。适用于需要双向通信、简洁API设计的新项目。
    • 状态：自2025年3月的MCP协议版本起引入，旨在取代传统的HTTP+SSE，是官方推荐的新开发远程MCP服务器的传输方式。
    • 工作原理：
      • 使用单一HTTP端点进行通信，简化了架构。
      • 客户端通过HTTP POST发送JSON-RPC请求。
      • 服务器可以返回单个JSON响应（Content-Type: application/json），或升级为SSE流来推送多个消息（Content-Type: text/event-stream）。
      • 支持无状态的纯HTTP连接，也支持通过会话ID（session ID）进行有状态的连接和断线重连。
    • 优势：
      • 简化的单端点设计，减少配置复杂性。
      • 支持无状态和有状态模式。
      • 更好的双向通信支持。
      • 向后兼容，可选支持SSE流。
      • 减轻了服务器维持长连接的压力。
    • 劣势：
      • 作为较新的标准，部分旧客户端可能支持有限。

  3. SSE (Server-Sent Events) - 服务器发送事件 (已弃用)

    • 适用场景：早期的远程通信方式，目前已被官方弃用，主要用于兼容旧系统。
    • 状态：在2024年11月引入，但在2025年3月的MCP版本中被正式弃用，推荐迁移到Streamable HTTP。
    • 工作原理：
      • 需要两个HTTP端点：一个用于客户端通过HTTP POST发送请求，另一个用于服务器通过SSE向客户端单向推送流式响应。
    • 优势：
      • 支持远程通信和实时推送。
      • 大多数现有的远程MCP客户端都支持。
    • 劣势：
      • 需要两个端点，配置复杂。
      • 通信本质上是单向流式（服务器→客户端），灵活性差。
      • 服务器需要维持高可用的长连接，资源消耗大。
      • 存在DNS重绑等安全风险。
      • 不支持断线重连。

选择建议

  • 本地开发/测试：首选 Stdio，简单、快速、安全。
  • 新的远程项目：强烈推荐使用 Streamable HTTP，这是MCP的未来方向，设计更现代、更简洁。
  • 需要兼容旧客户端的远程部署：可以同时支持 Streamable HTTP 和 SSE，以确保向后兼容。
  • 现有SSE项目：建议尽快迁移到Streamable HTTP，以获得更好的性能和未来的兼容性。

总结：MCP的传输机制体现了从本地到远程、从简单到复杂的演进。Stdio 是稳定的本地标准，SSE 已成为历史并被弃用，而 Streamable HTTP 是当前和未来的主流，为远程通信提供了最佳实践。

最近更新:
Contributors: klc407073648