夜雨聆风MCP协议深度解析：AI Agent连接世界的通用语言
「Hermes Agent自进化智能体深度解析」系列 | 模块十一 · 第1篇
1983年，TCP/IP统一了网络。2024年，MCP统一了AI。
1983年1月1日，ARPANET正式切换到TCP/IP协议。在此之前，每两个网络之间的通信都需要一套专用协议——X.25连X.25，SNA连SNA，DECnet连DECnet。网络之间的互联是一场N×N的噩梦。TCP/IP用一套通用协议终结了这个混乱，互联网从此诞生。
四十年后，AI Agent面临完全相同的困境。你有Claude、GPT、Gemini、Llama，你有Slack、GitHub、PostgreSQL、Jira、Notion、Salesforce——但每对Agent和工具之间都需要一套定制的集成代码。5个Agent × 10个工具 = 50套集成。10个Agent × 100个工具 = 1000套集成。这不是工程，这是灾难。
Anthropic在2024年11月开源了MCP（Model Context Protocol），给了一个精确的答案：AI Agent不需要N×N的集成，它需要的是一种通用语言——一种让任何Agent都能与任何工具用同一套协议对话的语言。 MCP之于AI Agent，正如TCP/IP之于互联网。没有统一协议的Agent就像没有互联网的计算机——算力再强，也只是信息孤岛。
在#10（模块四第2篇）中，我们介绍了MCP与Hooks的基础概念——MCP负责"连接"，Hooks负责"治理"。今天，我们要拆开MCP的黑盒，深入到协议栈的四层架构、四大原语、以及它为什么是自进化智能体连接世界的唯一正确答案。
集成噩梦：为什么AI Agent需要MCP
N:1的现实
假设你的团队构建了一个AI Agent，它需要连接以下服务：
没有MCP的世界：Agent A ──定制适配器──→ GitHub API（REST + OAuth）Agent A ──定制适配器──→ PostgreSQL（SQL + 连接池）Agent A ──定制适配器──→ Slack（WebSocket + Event API）Agent A ──定制适配器──→ Jira（REST + API Token）Agent A ──定制适配器──→ S3（AWS SDK + IAM）Agent B ──另一套适配器──→ GitHub API（REST + OAuth）Agent B ──另一套适配器──→ PostgreSQL（SQL + 连接池）... repeat × N
每接入一个新Agent，所有集成工作从零开始。每接入一个新工具，所有Agent都要单独适配。这不是线性增长，而是笛卡尔积增长。当一个企业有10个Agent和50个工具时，集成代码的维护成本已经超过了Agent本身。
MCP改变了一切：
MCP的世界：Agent A ──┐Agent B ──┤ ┌── MCP Server ──→ GitHubAgent C ──┼── MCP协议 ───┼── MCP Server ──→ PostgreSQLAgent D ──┤ ├── MCP Server ──→ SlackAgent E ──┘ ├── MCP Server ──→ Jira└── MCP Server ──→ S3
N×N变成N+M。这就是协议标准化的数学力量。
MCP协议栈四层架构
MCP不是一个简单的API调用规范。它是一个完整的协议栈，从底层传输到上层应用，每一层都有明确的职责边界。
┌──────────────────────────────────────────────────────────────────────┐│ MCP Protocol Stack ││ ││ Layer 4: Application Layer ─ 面向用户的业务场景 ││ ┌──────────────────────────────────────────────────────────────┐ ││ │ · Claude Desktop / VS Code / Hermes Agent │ ││ │ · Agent根据任务选择调用哪些Tool、读取哪些Resource │ ││ └──────────────────────────────────────────────────────────────┘ ││ ↕ ││ Layer 3: Capability Layer ─ 能力发现与协商 ││ ┌──────────────────────────────────────────────────────────────┐ ││ │ · Resources（数据暴露）· Tools（操作暴露） │ ││ │ · Prompts（模板暴露）· Sampling（LLM请求） │ ││ │ · initialize / capabilities 协商 │ ││ └──────────────────────────────────────────────────────────────┘ ││ ↕ ││ Layer 2: Protocol Layer ─ JSON-RPC 2.0 消息协议 ││ ┌──────────────────────────────────────────────────────────────┐ ││ │ · request / response / notification 三种消息类型 │ ││ │ · 方法路由与分派（tools/call, resources/read, ...） │ ││ │ · 错误处理、超时、取消 │ ││ └──────────────────────────────────────────────────────────────┘ ││ ↕ ││ Layer 1: Transport Layer ─ 传输机制 ││ ┌──────────────────────────────────────────────────────────────┐ ││ │ stdio（本地进程通信）│ SSE（HTTP流式）│ Streamable HTTP │ ││ │ · 消息帧序列化 · 连接管理 · 重连与心跳 │ ││ └──────────────────────────────────────────────────────────────┘ │└──────────────────────────────────────────────────────────────────────┘
Layer 1: Transport——让字节流跑起来
Transport层解决的是最基础的问题：MCP Host（Agent侧）和MCP Server（工具侧）之间的字节怎么传输？
MCP定义了三种传输机制：
| stdio | ||
| SSE | ||
| Streamable HTTP |
在Hermes场景中，本地的文件操作、数据库连接走stdio；远程的SaaS API集成走SSE或Streamable HTTP。Transport层对上层完全透明——Protocol层不关心消息是走管道还是走网络。
Layer 2: Protocol——JSON-RPC 2.0的严谨骨架
MCP选择了JSON-RPC 2.0作为消息协议。这不是随意的选择——JSON-RPC 2.0提供了MCP需要的所有原语：
// Request — Agent向Server请求执行操作{"jsonrpc": "2.0","id": 1,"method": "tools/call","params": {"name": "query_database","arguments": {"sql": "SELECT count(*) FROM users WHERE active = true"}}}// Response — Server返回执行结果{"jsonrpc": "2.0","id": 1,"result": {"content": [{"type": "text","text": "active_users: 12,847"}]}}// Notification — 单向通知，无需回复{"jsonrpc": "2.0","method": "notifications/message","params": {"level": "info","data": "Database connection pool healthy"}}
三种消息类型覆盖了所有交互模式：Request/Response用于同步操作，Notification用于异步事件通知（日志、进度、告警）。这套消息骨架既简洁又完备——这正是协议设计追求的极简主义。
Layer 3: Capability——能力声明与发现
连接建立后，第一件事不是调用工具，而是协商能力。Agent问：“你能做什么？” Server回答：“这是我的能力清单。”
Agent MCP Server│ ││──── initialize ───────────────→│ "我是Hermes Agent v3.2，│ │ 我支持tools、resources、prompts"│ ││←─── capabilities ─────────────│ "我是postgres-mcp-server v1.4，│ │ 我提供以下3个tools和8个resources"│ ││──── tools/list ──────────────→│ "列出你的所有工具"│←─── [tool1, tool2, tool3] ───│ "query_database, execute_dml,│ │ explain_plan"
能力协商是MCP最精妙的设计之一。 Agent不需要硬编码知道Server提供什么——它动态发现、动态适配。这意味着一个MCP Server升级后新增了工具，所有连接它的Agent第二天就能自动使用——无需改一行代码。
Layer 4: Application——业务场景落地
Application层是Agent和MCP交互的最终呈现。Claude Desktop用它查询文件系统，VS Code用它搜索代码库，Hermes Agent用它执行任务编排。Application层的丰富性，正是底层协议标准化的直接回报。
四大原语深度拆解
MCP定义了四个核心原语（Primitives），每一个对应一种"Agent与外部世界交互"的基本模式。
┌─────────────────────────────────────────────────────────────────────┐│ MCP四大原语：Agent与世界的四种交互 ││ ││ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌───────────┐ ││ │ Resources │ │ Tools │ │ Prompts │ │ Sampling │ ││ │ "读什么" │ │ "做什么" │ │ "怎么问" │ │ "帮我思考" │ ││ │ │ │ │ │ │ │ │ ││ │ 数据暴露 │ │ 操作暴露 │ │ 模板暴露 │ │ LLM请求 │ ││ │ 只读访问 │ │ 可写可执行 │ │ 参数化模板 │ │ Agent请求 │ ││ │ │ │ │ │ │ │ Server向 │ ││ │ Server→Agent│ │ Agent→Server│ │ Server→Agent│ │ Agent借脑 │ ││ └─────────────┘ └─────────────┘ └─────────────┘ └───────────┘ ││ ││ 方向: Server暴露 ──→ Agent消费（Resources, Prompts） ││ 方向: Agent调用 ──→ Server执行（Tools） ││ 方向: Server请求 ──→ Agent思考（Sampling） │└─────────────────────────────────────────────────────────────────────┘
Resources：数据暴露——“我能提供什么信息”
Resources是MCP Server向Agent暴露的只读数据源。它解决的核心问题是：Agent如何知道外面有什么数据？
// Server声明自己提供的Resources{"resources": [{"uri": "postgres://users/table_schema","name": "用户表结构","description": "users表的完整DDL和索引信息","mimeType": "application/json"},{"uri": "file:///project/config.yaml","name": "项目配置文件","description": "当前项目的运行时配置","mimeType": "text/yaml"},{"uri": "github://repos/hermes/issues/open","name": "未关闭的Issue列表","description": "当前仓库的所有open状态Issue","mimeType": "application/json"}]}// Agent读取某个Resource{"method": "resources/read","params": {"uri": "postgres://users/table_schema"}}
Resource的核心设计哲学是URI寻址。每个Resource都有一个唯一的URI，Agent用URI请求数据，就像浏览器用URL请求网页一样。URI协议前缀标识数据来源——postgres://、file://、github://——Agent不需要知道背后是什么系统，只需要一个URI。
Tools：操作暴露——“我能执行什么动作”
Tools是MCP Server向Agent暴露的可执行操作。如果Resources是"读"，Tools就是"写"和"做"。
// Server声明自己提供的Tools（带JSON Schema参数定义）{"tools": [{"name": "query_database","description": "执行只读SQL查询并返回结果","inputSchema": {"type": "object","properties": {"sql": {"type": "string","description": "要执行的SQL SELECT语句"},"limit": {"type": "integer","description": "返回结果的最大行数","default": 100}},"required": ["sql"]}},{"name": "create_jira_ticket","description": "在Jira中创建一个新的Issue","inputSchema": {"type": "object","properties": {"project": { "type": "string" },"summary": { "type": "string" },"description": { "type": "string" },"priority": {"type": "enum","enum": ["critical", "high", "medium", "low"]}},"required": ["project", "summary"]}}]}
注意inputSchema——它使用JSON Schema定义了每个Tool的参数结构。这意味着Agent不需要文档，不需要猜参数格式——Schema本身就是自描述的合约。 这也是MCP与普通REST API的核心区别之一：API的参数定义散落在文档里，MCP Tool的参数定义内嵌在协议中。
Prompts：模板暴露——“你应该怎么问我”
Prompts是MCP Server向Agent暴露的参数化提示模板。它解决的是一个容易被忽视的问题：有些任务需要特定的提问方式才能获得最佳结果。
{"prompts": [{"name": "code_review","description": "代码审查模板：按安全/性能/可维护性三个维度分析","arguments": [{"name": "language","description": "代码语言","required": true},{"name": "focus_area","description": "审查重点：all|security|performance|maintainability","required": false}]}]}
当Agent需要做代码审查时，它不需要自己构造审查Prompt——直接调用Server提供的code_review模板，传入语言和关注点，获得一个经过千锤百炼的专业审查框架。Prompts让最佳实践从一个"建议"变成了一个"可调用的API"。
Sampling：LLM请求——“Server向Agent借脑”
Sampling是MCP四个原语中最"反直觉"的一个：MCP Server可以反过来请求Agent的LLM能力。
为什么一个工具Server需要调用LLM？考虑一个场景：数据分析Server在返回查询结果之前，想让Agent对数据做一个初步的异常检测——“这组数字看起来正常吗？” Server自己没有LLM，但它连接的Agent有。
// Server向Agent发起Sampling请求{"method": "sampling/createMessage","params": {"messages": [{"role": "user","content": {"type": "text","text": "以下数据是否显示异常模式？日活跃用户：1250, 1180, 1230, 50, 1210, 1240"}}],"maxTokens": 200,"systemPrompt": "你是数据异常检测专家。用一句话判断是否存在异常，并指出异常位置。"}}
Sampling打破了"Agent调工具"的单向模型，建立了一个双向协作模型。 Server不只被动提供数据，它还能主动"思考"——当然，思考的能力是向Agent借的。这种设计在复杂场景下极为强大：Server可以基于LLM判断对结果进行预过滤、预分析、预排序，让Agent拿到的不是原始数据，而是经过智能加工的半成品。
MCP vs 传统API：协议的代际差异
MCP不是"又一个API规范"。它和OpenAPI/gRPC/GraphQL之间不是竞争关系，而是代际差异——就像HTTP不是TCP的竞争者，而是建立在TCP之上的新一代协议。
┌──────────────────────────────────────────────────────────────────────┐│ 协议代际对比：从机器对机器到AI对世界 ││ ││ 维度 OpenAPI/REST gRPC GraphQL MCP ││ ───────── ─────────── ────── ──────── ────── ││ 协议目标 服务间通信 高性能RPC 灵活数据查询 AI×工具连接 ││ 消费者 人类开发者 人类开发者 人类开发者 AI Agent ││ 发现机制 Swagger文档 Proto定义 Schema Introspect 能力协商 ││ 状态管理 无状态/需自建 无状态/需自建 无状态/需自建 会话+订阅 ││ 工具理解 读文档才知道 读Proto才知道 读Schema才知道 Schema内嵌 ││ AI原生度 ★☆☆☆☆ ★☆☆☆☆ ★★☆☆☆ ★★★★★ ││ 自描述能力 低（靠文档） 中（靠Proto） 中（靠Schema） 高（内嵌） ││ 双向通信 否（需WebSocket）否（需流式） 否（需Sub） 原生支持 ││ 动态发现 否 否 是（Introspect） 是（运行时）│└──────────────────────────────────────────────────────────────────────┘
核心差异浓缩为一句话：传统API的设计假设消费者是"人类开发者"——他们读文档、写代码、调试接口。MCP的设计假设消费者是"AI Agent"——它读Schema、动态发现、自动调用。 这是从"人机接口"到"机机接口"的范式迁移。
举个具体的例子。一个REST API的错误码文档可能写着："返回403表示权限不足，请检查你的OAuth Token是否过期。"这段文字对人类开发者完全够用。但对AI Agent来说，它需要的是结构化的错误信息：
{"error": {"code": "TOKEN_EXPIRED","message": "OAuth token expired at 2026-06-01T14:30:00Z","suggestion": "Call auth/refresh endpoint to obtain a new token","retryable": true}}
MCP的每一个返回值都是结构化的、机器可理解的、自描述的。 这不是细节差异，这是设计哲学的根本不同。
震撼时刻：一个Server，十个Agent，十个不同的世界
现在来到这篇文章的震撼时刻。
想象一个enterprise-mcp-server，它背后连接着企业的全部数据资产——用户数据库、订单系统、CRM、文档库、监控平台。现在有10个不同的Agent通过MCP连接到这个Server。
┌─────────────────────────────────────────────────────────────────────┐│ 一个MCP Server × 十个Agent = 十个定制化的世界 ││ ││ enterprise-mcp-server ││ ┌──────────────────────────┐ ││ │ Resources: │ ││ │ · users_db (读) │ ││ │ · orders_db (读) │ ││ │ · crm_contacts (读) │ ││ │ · docs_library (读) │ ││ │ · metrics_dashboard (读) │ ││ │ │ ││ │ Tools: │ ││ │ · query_sql (查询) │ ││ │ · create_ticket (建工单) │ ││ │ · send_notification (通知)│ ││ │ · update_crm (更新CRM) │ ││ │ · generate_report (报告) │ ││ └─────────┬────────────────┘ ││ │ MCP协议 ││ ┌─────────────┼─────────────┐ ││ │ │ │ ││ ┌────────▼───┐ ┌─────▼──────┐ ┌──▼───────────┐ ││ │客服Agent │ │销售Agent │ │运维Agent │ ││ │ │ │ │ │ │ ││ │可见: │ │可见: │ │可见: │ ││ │ ·用户查询 │ │ ·CRM读写 │ │ ·监控仪表盘 │ ││ │ ·工单创建 │ │ ·订单查询 │ │ ·系统日志 │ ││ │ ·通知发送 │ │ ·报告生成 │ │ │ ││ │ │ │ │ │可做: │ ││ │不可见: │ │不可见: │ │ ·查询SQL │ ││ │ ·CRM更新 │ │ ·用户DB直查 │ │ ·发送通知 │ ││ │ ·SQL直查 │ │ │ │ │ ││ │ ·报告生成 │ │ │ │不可见: │ ││ └────────────┘ └────────────┘ │ ·CRM更新 │ ││ └──────────────┘ ││ ┌────────────┐ ┌────────────┐ ┌──────────────┐ ││ │数据分析Agent│ │合规审计Agent│ │产品经理Agent │ ││ │ │ │ │ │ │ ││ │只读访问全部 │ │只读访问全部 │ │只读+工单 │ ││ │不能写不能改 │ │不能写不能改 │ │其余不可见 │ ││ └────────────┘ └────────────┘ └──────────────┘ ││ ││ ... 还有4个Agent，每个都有定制化的能力视图 │└─────────────────────────────────────────────────────────────────────┘
十个Agent连接的是同一个物理Server，但它们看到的是十个完全不同的世界。 客服Agent只能查询用户和创建工单，对CRM数据一无所知；销售Agent可以读写CRM但无法直接查询用户数据库；合规审计Agent可以看到所有数据但一行都不能修改。
这不是通过部署十个不同的Server实现的——这是MCP的能力协商机制在运行时动态完成的。Server根据连接者的身份和权限，返回不同的capabilities声明。Agent在初始化阶段就完成了"我能看到什么"的限定——后续所有操作都在这个安全边界内进行。
这就是协议标准化的力量。 没有MCP，你需要为每个Agent写一套定制化的API网关。有了MCP，一个Server通过能力协商就能服务所有Agent——每个Agent获得精确适配它角色和权限的能力子集。
把这个场景与自进化数据飞轮结合起来看：10个Agent在同一个数据源上执行不同维度的操作，产生的执行数据——查询模式、成功率、异常频率——全部回写到自进化系统。客服Agent的高频查询优化了数据库索引建议；销售Agent的CRM操作模式优化了推荐算法；运维Agent的监控数据分析优化了告警阈值。同一个Server、同一份数据，10个Agent从10个维度驱动系统进化。 连接产生数据，数据驱动进化——这正是自进化智能体的核心闭环。
总结：MCP——自进化智能体的神经网络
回到开篇的类比。TCP/IP统一了网络通信，让数十亿设备自由互联。MCP统一了AI Agent与外部世界的通信，让任何Agent都能与任何工具用同一种语言对话。
这篇文章拆解了MCP的完整技术图景：
- 协议栈四层架构
：Transport（传输）→ Protocol（消息）→ Capability（能力）→ Application（应用），每一层职责清晰、对上层透明 - 四大原语
：Resources读数据、Tools做操作、Prompts用模板、Sampling借思考——四种交互模式覆盖Agent与外部世界的所有连接方式 - 代际差异
：MCP不是"又一个API"，它是第一个为AI Agent而非人类开发者设计的连接协议 - 协议标准化的力量
：一个Server服务多个Agent，每个Agent获得定制化的能力视图——N×N变成N+M
对Hermes自进化智能体而言，MCP的意义远不止"连接"。连接产生的每一次数据交换、每一次工具调用、每一次结果返回，都是自进化系统的燃料。MCP不只是Agent的"手"——它是自进化数据飞轮的"输入端口"。 没有连接，就没有数据；没有数据，就没有进化。
下一篇#32，我们将进入MCP Server开发实战——如何从零构建一个生产级MCP Server，如何定义Resources/Tools/Prompts，如何处理错误与重试，如何与Hermes Agent的自进化管线深度集成。从协议理解到工程实现，这是从"知道"到"做到"的跨越。
延伸阅读与交流
本文涉及的Hermes Agent自进化智能体技术体系，目前已有系统化的深度学习资源可供参考。中国通信工业协会通信和信息技术创新人才培养工程项目办公室将于近期组织相关技术专题分享，围绕本文讨论的AI原生架构、智能体工作流、自进化数据层等方向展开系统讲解。
专题信息
主题：AI原生Hermes自进化智能体系统 时间：2026年7月4-5日（周末） 形式：线上直播 内容方向：AI原生架构 · Hermes智能体拆解 · 全栈扩展 · 智能自动化 · 产品级实战 · Context Engine · 自进化数据层
分享嘉宾
王老师（Gavin），Agentic AI企业联合创始人兼CTO，十余年硅谷AI系统工程经验。长期深耕NLP、强化学习、可控AI与智能体系统架构，提出"语言即控制（Language as Control）"原创范式，在RLHF、PPO、DPO、GRPO等方向有系统化工程实践，推动智能体技术在社交媒体、医疗、金融、法律、教育等专业场景落地。
技术交流
联系人：Sam WeChat：NLP_ChatGPT_LLM Hermes Agent技术文档：https://hermes-agent.nousresearch.com/docs/