在偶然的学习中接触到了近期炙手可热的MCP 于是在学习之后草率写一点自己的体会

笔者对AI学习了解主要停留在应用方面 这里也主要MCP在这上的作用和修改

When it comes to MCP 的概念，个人认为从AI工具的使用现状、其的作用和能带来的改善作为角度切入会更好理解.

那么

MCP是什么

生态协同

AI与MCP（?）

从21年的gpt3.5开始 ai技术不断进步 各种各样的效果评测 也能实打实得说明其无论是在计算 编码 搜索等领域上都有了很大的进步 但是相比之下 其本身集成速度（AI+）应用发展的很慢

3.5时代 我们的使用方法停留在文字对话 语句文字补全 仅chat对话和completion两模式

在以CloseAI为主的（那时还是Open的）独角兽厂商的推动下 人们通过他们提供的api 初步实现了多载体上使用api ide上 chrome插件上 在ds-r1横空出世之后 也是在国内掀起了一模一样的热潮

然后为了想让ai更好的完成任务 人们通过prompt 预训练 rag等方法 尝试通过加强某部分知识在ai“心目中的地位” 事实证明也确实起到了很好的效果 直至当前市场中 不少TOB的ai+任务 也都是通过这种模式来实现的

然后衍生出了AI Agent,function call,structure output等的概念 个人认为Agent本质上可以理解为是ai的一种抽象。原有的单chat模式是Agent的最原始任务，在用户将需求通过function call等方式传达给ai时 其认识并根据输入的信息进行任务的分类后 进行推理 而这个推理的过程本质上和回复是一致的 只是多了一个任务分类的过程

再之后 o1和深度思考以及联网素搜索的出现 首先是进一步增强了它的推理能力 在幻觉等指标上有大幅提升 另一方面也大大强化了Agent处理任务的能力

于是我们现在能发现在各家的ai中 ai生成ppt ai生成邮件回复内容 ai生成论文 ai进行cr 基本都已经随地可见了

但是

这些功能本质上都是相对独立的 想象一下 你可以通过ai在放上搜索最新的论文 然后根据这些论文结合你的主题 编写对应的code处理数据 根据获得的数据写一篇新的论文 为其配图配表格 写完之后甚至还能生成一个路演的ppt 最后将所获得的论文与ppt一并打包邮件发给导师

这么一看就很遥远了 因为在这个过程中会遇见各种各样的问题 eg 上下流协议不一致 模型不一致 上下文过短无法读取整体论文 模型任务不擅长等等

归根到底 出现这个问题的原因除了企业级之间的沟通合作外 技术方面的问题就是缺少一个开放的、通用的、有共识的协议标准

MCP就是这么一个角色 他推出了对应的开源组织和协议 企业测可以自行结合参与 或在这个基础上进行二次融合和合作

Agent与MCP

这里可能会有点混淆 主要是围绕着Agent和MCP的区别 Agent已经有了执行各个任务的能力 但是这个是相对自身而言的 一句话可以总结为 Agent基于单点任务开发 MCP是基于协议兼容开发

当我们多个Agent直接进行拼接 其实就可以达成多个任务流转的效果 但是这个过程是全员定制化的 每个任务之间的function call得到的效果可能都不一样 而且这个定制化一般是面对 单个企业或者多个合作中的企业而言的

和Function Call对比

想象你请了一位全能助理（AI模型），它本来只会回答理论问题。现在你想让它能实际操作一些事情：

  1. 传统Function Call（函数调用）➤ 就像给助理一本固定手册：”你只能按这20条指令做事”➤ 每次新增能力（比如订机票），都需要重新印刷整本手册➤ 不同公司的助理（GPT/Claude等）手册格式还不一样
  2. MCP协议➤ 给助理配了一个万能插座，可以随时插入新工具➤ 需要计算？插上计算器模块➤ 需要订餐？插上外卖系统模块➤ 模块由不同厂商提供，但插座标准统一
    关键区别：
  • 🔌 扩展性：Function Call像固定工具箱，MCP像无限扩展的USB接口
  • 🤝 协作性：MCP允许不同品牌的工具/助理互相兼容
  • 🛠️ 安全性：MCP的每个工具都有独立开关（权限控制）

而MCP作为标准协议 是面对整个编程界的 结合MCP使用 AI模型能够在不同厂商 不同的API和数据源之间的无缝流转 并且它的设计中 AI模型可以在不同的应用/服务间保持上下文 不仅起到了一种热插拔式的便捷修改 也提升了任务本身的执行效果

共识与MCP

所以 MCP本质上并不是什么高深莫测的东西 他只是集大成了目前ai所能做到的事 设计了一个具有共识的协议 各公司可以在此基础上维护一个良好的生态 但是大一统了任务结合的方式 不需要重复造轮子 对整个AI的发展历程 任务融合这一块是极好的 同时由于它的基本颗粒度是单个任务（ai应用） 可以在此基础上 同样以该颗粒度启用权限控制 保证数据安全

MCP的具体设计

架构设计

这里附上MCP的官方架构图
mcp-architecture

他所采用的是典型的客户端-服务器架构 主要可以分为三类角色：

  1. MCP主机-host: 发起连接并承载LLM应用的程序 是整个AI工作流的协调者 组织者 它不仅仅是起到一个调度的作用 更多的是类似意图识别、会话管理、任务规划之类的 本质上就是一个将查询query量化成具体任务流的过程

  2. MCP客户端-client: 运行在主机内部 将主机作为客户端的角色与暴露的MCP服务器相连接 不准确的话可以理解成host的通讯组件

  3. MCP服务器-server: 独立的轻量服务 暴露特定的能力或者数据 本质上就是操作数据源 进行查询搜索或其他功能的单个服务节点

这个图很好的介绍了上面三者的本质关系

主机通过客户端组件连接到多个MCP服务器 每个Server类似一个适配器 他们都遵循MCP协议 从而能够作为“外设” 将本地/远程的数据源或工具统一接口提供给AI模型使用

注意在这个交流的过程中 他们所采用的是双向通信 具体底层所使用的是JSON-RPC 2.9来进行信息编码和交换

这里所说的双向通信是指双方都建立传输信息的连接 而在传输层上的实现是：

  • 本地部署：标准输入/输出 管道 —— 进程间通信

  • 跨网络场景：HTTP+SSE 流式单向传输 —— 跨网络

通信流程

MCP为了保证Client和Server的顺利通信 他也有一个类似握手的建立连接环节

  1. 客户端首次连接服务器时 发送一个initialize请求 包含自身所使用的协议版本以及功能能力信息等 本质作用也是老生常谈的 协商一个可以共用的版本

  2. 服务器收到之后 也返回自己对应的协议版本和能力集合

  3. 客户端收到后 会再次发送一个initialized通知表示确认 至此双方进入正常通信阶段

可以看到就是类似http的三次握手 一旦初始化完成 两者也同样可以自由的进行信息的请求响应

而同样的 这里是单向连接的协议 所以如果需要双方进行双向连接的话 也还是需要建立两次单向的连接

而面对一些连接时出现的异常 MCP作为一个协议 它本身也定义了一些标准的错误代码

1
2
3
4
5
6
7
8
enum ErrorCode{
    // 标准JSON-RPC错误代码
  ParseError = -32700,
  InvalidRequest = -32600,
  MethodNotFound = -32601,
  InvalidParams = -32602,
  InternalError = -32603
}

Server核心概念

上方已经提到了 本质上实现数据源操作等功能的 还是MCP Server

分割一下它 可以分成三部分

  • 资源：这个就很好理解 在数据库场景下可以是被操作的数据 搜索场景下则是网络上的条目……等等等等 本质上就是在使用过程中可操作学习的知识和资源

  • 工具：这个可以广泛的理解为能力 具体可以提现在数据库时的查询能力 搜索时的网络爬虫和读取能力 文件的ocr 文件读取/写入等操作

  • 提示词: 这个就是一个预定义的规定和流程 由用户通过此 来对它进行一个g=工作流的预设 注意此处的预设和真正使用的时候不一样 此处的仅仅是针对单个 或者小部分形成的服务或者服务集 作的一个辅助作用 提升正常使用时所得到的效果

MCP具体改造

场景：使用MCP重构文档上传问答 过程包括rag等操作

原流程早期架构图

如何重构？

  1. 顶层Host（会话编排层）
  • 继续由Python服务承担意图识别、任务编排、用户上下文管理（部分也是由java应用完成）、Prompt组装。
  • 在内部嵌入MCP Client，把“调用Java问答接口”改为调用MCP Server的traffic_doc_qa工具（此时之前的java服务变成了一个MCP协议找中的server）。
  1. 能力服务器层（MCP Server）
    1. 将Java问答服务改造成纯Server：对外只暴露一个或少量工具（如traffic_doc_qa）。
    1. Java服务可升级为“二级Host”，内部再用Client调用下边的各类小server（以Http接口的形式对外暴露）：
    • DocumentIngest Server：PDF/Word/Excel解析、切分；
    • Embedder Server：文心、tao‑8k或其他向量化；
    • VectorStore Server：ES KNN / Milvus；
    • Rerank Server：重排模型；
    • LLM Server：大语言模型推理；

改造前后角色映射

现有组件 在MCP中充当的角色 说明
Python意图识别/编排服务 Host + Client 拥有会话状态，嵌入Client与下游通信
Java问答服务 Server（至少），可作为Host 暴露traffic_doc_qa，内部流程不变
ES向量检索 Server（如VectorStore Server） 由Java Host通过Client调用
tao‑8k Embedding Server (Embedder Server) 同上
Rerank模型 Server (Rerank Server) 同上
LLM推理 Server (LLM Server) 可为本地模型或第三方API

总

对于当前的发展趋势来说 可以总结为推动“标准化 + 场景化”协同

当前AI生态面临两个痛点：

  • 工具碎片化、互不兼容（没有标准协议）

  • 实际落地难、缺乏成熟应用（缺场景化支持）

有了MCP，大家用同一协议沟通，Agent之间就可以协同工作。

有了平台（如Dify/Coze），用户不需要懂代码，也能快速搭建应用。

After

写的挺乱挺啰嗦

学习了佬的终极指南