一、概述

Claude code、Codex、Hermes等Agent在广泛使用的过程中经常出现这几个名词：Skills、MCP.

其实Skills可以理解成智能体能使用的工具箱，里面有说明可以实现的“功能”。至于MCP，接下来听我说些作者在使用中的了解及个人理解。

MCP，全称Model Context Protocol模型上下文协议。说到协议，就是定义的一套规范。是针对什么的规范呢，针对Agent与外界资源交互的一套标准化协议。

1、背景

2024年年底，各类AI Agent概念爆发，但各厂商的“工具调用”实现互不兼容。例如，OpenAI的Function Calling只能用于其API内部；LangChain虽提供抽象层，但每一步集成仍需定制代码。这种“烟囱式”架构阻碍了Agent生态的通用化。Anthropic借鉴了LSP（Language Server Protocol）的成功经验，推出MCP试图统一这一层。

2、MCP的核心组件

MCP采用的是客户端-服务端模式。

• MCP HOST宿主：通常是AI应用或者软件，比如说claude、codex桌面版等等。
• MCP Client客户端：与服务器进行一对一连接的用户端口。
• MCP Server服务端：为每个外部资源或工具（如数据库、文件系统、GitHub API等等）提供一个轻量级的服务器进程，暴露标准化的“资源”（Resource）和“工具”（Tool）端点。

读者看到这里可能又有点迷惑了，这里作者来打一个生活中的案例：就比方说你去一家超市或者餐厅吃饭。你就是客户端，你购买了某些东西或者消费某些服务，这个服务器就相当于店长加服务员：1. 眼睛（读取）：去查实时库存、查你的账户余额。2. 手（操作）：把选购的商品加入购物车、扣除余额。3. 嘴巴（反馈）：告诉顾客“xx已购买，余额剩余50元”。在这个场景里超市或者餐厅就是外部资源或工具。 

3、通信方式

基于Json-RPC 2.0，本地采用stdio协议进行传输，远程采用Streamable Http（旧版采用的是Http+SSE）协议传输。

4、关键能力

• 资源暴露：mcp server将外部资源或工具（如数据库等等）暴露给agent，供agent进行拉取。
• 工具调用：mcp server定义“可执行动作”，模型通过Agent框架自动选择合适的工具并生成参数，Server执行后返回结果。
• 安全边界：server会申明权限设置，为用户提供授权和沙盒。

二、常见的协议

这里想分享的是软件层的一些通信协议，最常见的就是http/https协议了。

1、http/https

HTTP是明文传输的超文本传输协议，而HTTPS是HTTP通过SSL/TLS协议加密的安全版本。Https默认是443端口，Http默认是80端口。另外http还有0.9、1.0和2的版本区别，HTTP/1.0是严格的半双工，HTTP/2是全双工。由于当前绝大多数主流网站已支持 HTTP/2 或 HTTP/3，因此绝大多数情况下，现代浏览器的 HTTP 数据传输是全双工的通信。

2、websocket

WebSocket是一种在单个TCP连接上实现全双工通信的协议，主要用于浏览器与服务器之间的实时双向数据交换。它在http端口通过Upgrade头部完成握手，随后建立持久TCP连接。数据以帧（Frame）格式传输，开销极小（仅2字节头）。

适用场景：需要频繁双向交互的应用，例如聊天室、实时大屏、游戏等。

3、SSE

Server-Sent Events (SSE) ：基于HTTP的单向服务器推送，客户端通过EventSource接口接收数据。数据流向：服务器→客户端单向。连接时间持续时间持久，延迟低 。 

适用场景：单向推送（如新闻订阅、股价更新）

4、RabbitMQ

RabbitMQ 是一个消息代理，实现了 AMQP 0-9-1 协议规范。它使用 Erlang/OTP 构建，核心概念（交换机、队列、绑定）直接来自 AMQP 模型。

5、stdio

stdio即是指标准输入输出，stdio 不是用来在网络上传输数据的协议，而是计算机程序与外界（人、文件、其他进程）进行数据交换的“通用接口。这里a哥觉得可以类比成用户个人电脑读取系统环境配置类似的文件参数的“接口”，这样方便理解。

三、一些协议之间的对比

1、为什么浏览器用http/https而不是websocket

答案：浏览器优先用 HTTP，是因为它简单、兼容性强、无状态且符合“按需索取”的互联网基础模式；而 WebSocket 只是当需要实时双向互动（如聊天、游戏）时的专用补充工具。
打个比方：HTTP = 打电话（我说一句，你回一句，说完挂断）。适合：加载网页、发表单、取数据。WebSocket = 开专线（电话一直通着，随时互说）

2、在mcp协议里要求Client 发请求、Server 推结果，那么用的是Websocket吗？

答案：不是，mcp支持两种传输方式。分别适用于不同场景。本地场景用 stdio，Client 把 Server 作为子进程启动，通过标准输入输出通信，延迟极低，不用开端口，也没有网络安全问题。

远程场景现在推荐用 Streamable HTTP，Server 作为独立的 HTTP 服务部署，多个 Client 可以共享同一个 Server，适合团队统一管理工具服务。

MCP 早期版本（2024-11-05 规范）的远程传输是「HTTP + SSE」双端点方案，2025 年 3 月的规范更新里被标记为 deprecated（保留向后兼容但不推荐新项目使用），Streamable HTTP 成为了推荐的远程传输方式。但是不管哪种传输方式，底层消息格式都统一用 JSON-RPC 2.0，传输方式只影响「怎么传」，消息协议本身不变。

3、为什么 Streamable HTTP 取代了 SSE？

旧方案 (HTTP + SSE)：
Client -> Server: 发送 POST 请求 (建立连接 A)。Server -> Client: 开启一个新的 SSE 长连接 (连接 B) 推送数据。
问题：如果连接 A 断了，或者连接 B 断了，系统很难知道当前对话处于什么状态。
新方案 (Streamable HTTP)：
Client -> Server: 发送 POST 请求 (建立连接 C)。 Server -> Client: 在连接 C 上直接返回流式响应。
解决：请求和响应在同一根管道里。如果网络断了，就是整个对话断了；如果成功，就是整个流程完成了。状态管理变得非常简单（Request ID 即可追踪）