AI_概念篇_MCP

AI_概念篇_MCP让 AI 真正能动手的标准协议没有 MCP 之前重复造轮子的时代早期 Agent2023 年前后的 AutoGPT、早期 GitHub Copilot 等要调用外部工具每个平台都得自己硬编码实现一遍Cursor 自己写一套读文件的逻辑 Copilot 自己写一套读文件的逻辑 你的 AI 项目 再写一套读文件的逻辑 GitHub 想让 AI 能操作 PR → 要分别适配 Cursor、Copilot、JetBrains、VS Code…… → 每新增一个平台就要重新适配一遍本质是M 个平台 × N 个工具 M×N 个适配。工具越多、平台越多适配成本指数级增长且彼此完全不通用。MCP 把 M×N 变成了 MN。工具开发者只需实现一次 MCP Server所有支持 MCP 的平台都能直接用平台只需支持 MCP就能调用所有已有的 Server。MCP 后续爆发的原因就不言而喻了MCP 的真正价值不在于协议本身而在于成为跨厂商的最小公约数这也是它被快速采用的核心原因。MCP 是什么MCPModel Context Protocol模型上下文协议是 Anthropic 于 2024 年 11 月发布的开放协议定义了一套标准工具如何向 AI 声明自己的能力AI 如何通过统一接口调用这些工具。MCP 工具 / 系统 与 LLM 之间的统一通信标准。 严格来说Tools 只是 MCP 三种能力之一Tools / Resources / Prompts 只是目前工程实践中 Tools 使用最广因此常被等价理解为工具调用协议。类比 USB 接口规定了接口形状和通信协议U 盘、键盘、摄像头都能插——MCP 做的是同样的事连接的是 AI 和各类外部工具。MCP Host宿主应用协调并管理所有 MCP Client 的 AI 应用程序。负责启动和回收 Server 进程、创建和管理 Client 实例、协调 Agent 决策流程是用户直接交互的入口如 Cursor、Claude Desktop。MCP Client客户端由 Host 创建的通信组件负责与某一个 MCP Server 维持专属连接并将 Server 提供的上下文能力交付给 Host 使用。每个 Client 与一个 Server 保持 1:1 的对应关系。MCP Server服务端向 MCP Client 提供上下文能力的程序。负责将某类外部能力如文件系统、数据库、GitHub API封装成符合 MCP 协议的标准接口可在本地或远程运行。三层架构谁在干什么MCP 在协议层面约定了三层架构。每一层可以由不同的开发者独立实现只要遵守通信规范就能互相配合——这正是 MCP 的核心价值A 开发的 Client能与 B 开发的 Server 通信也能被 C 开发的 Host如 Cursor使用。┌──────────────────────────────────────────────────────────────────┐ │ Host主机 │ │ Cursor / Claude Desktop / 你自己开发的 AI 应用 │ │ · 用户直接交互的 UI 界面 │ │ · 启动和管理所有 Client 实例的生命周期 │ │ · 协调 Agent 决策与工具调用的整体流程 │ └───────────────────────────┬──────────────────────────────────────┘ │ 管理1 Host : N Client ┌─────────────┼─────────────┐ ▼ ▼ ▼ ┌────────────────┐ ┌────────────────┐ ... │ Client A │ │ Client B │ │ Agent 的通信 │ │ Agent 的通信 │ │ 子模块 │ │ 子模块 │ │ · 发起请求 │ │ · 发起请求 │ │ · 接收结果 │ │ · 接收结果 │ └───────┬────────┘ └───────┬────────┘ │ │ │ 本地进程用 Stdio │ 远程服务用 Streamable HTTP ▼ ▼ ┌────────────────┐ ┌────────────────┐ │ Server A │ │ Server B │ │ 文件系统 │ │ GitHub │ │ read/write │ │ PR/commit │ └────────────────┘ └────────────────┘Host管理者不只是界面Host 是整个 MCP 运行环境的管理者。用户打开 Cursor 时Host 读取配置文件如mcp_settings.json把需要的 Server 作为子进程在后台拉起来并创建对应的 Client 实例建立连接——具体是启动时全部初始化还是按需创建取决于 Host 的实现协议本身不做规定。这一切对用户无感。用户关闭编辑器时Host 也负责断开连接、回收所有 Server 进程。Host 完全可以由任何人自己开发。比如想做一个专门用于法律文书审查的 AI 工具完全可以开发一个自己的 Host内嵌 Client连接文件系统和数据库 Server定制自己的 UI 和交互逻辑。Host 也不限于桌面应用。Claude Code、Gemini CLI 这类命令行工具同样是 MCP Host只是把 UI 换成了终端交互底层的 Server 管理和 Agent 协调机制完全一致。ClientAgent 的通信子模块Client 是 Agent 用来和 Server 通话的模块由 Host 创建和管理。注意 Client 本身不包含决策能力也不依赖 Agent 存在——即使没有 Agent例如简单规则系统Client 仍然可以独立工作。就像员工Agent用电话Client打外线但电话是公司Host装的也是公司负责维护的。Client 的职责很单纯选择合适的传输方式建立连接、发请求、收结果。复杂的决策逻辑在 Agent 里具体的工具实现在 Server 里Client 只做中间传话的角色。Client 与 Server 的连接方式有两种传输方式适用场景特点Stdio标准输入输出Server 是 Host 启动的本地子进程性能最优无网络开销进程间直接通信Streamable HTTPServer 是远程独立部署的服务支持多 Client 并发连接适合云端工具Streamable HTTP 是 MCP 2025-03-26 规范修订后的推荐传输方式取代了早期的 HTTP/SSE双通道HTTP 请求 SSE 长连接推送。新方案用单一 HTTP 连接同时支持请求/响应与流式推送SSE 变为可选更适合无状态云端部署。如果看到旧文章提及 HTTP/SSE指的是同一类场景下的旧版实现。实际工程中本地工具文件系统、终端执行用 Stdio第三方云服务GitHub、Slack、Gmail用 Streamable HTTP。Server能力的适配层不是工具本身Server 既是一个协议概念适配层的角色定义也是一个具体运行的程序。它做两件事对上实现 MCP 协议接口响应tools/list、执行tools/call、回传结果对下调用实际的底层能力fs 模块、Puppeteer、GitHub API 等底层能力fs 模块 / Puppeteer 库 ↓ 包装 MCP Server 程序filesystem-server / puppeteer-server ↓ 暴露标准接口 Agent 通过 MCP 协议调用你在生态表里看到的filesystem、Puppeteer、GitHub等指的就是对应的 MCP Server 程序而不是底层的 fs 模块或 Puppeteer 库本身。Server 程序把这些底层能力包装成了标准接口。比如你开发了一个闹钟应用同时也可以开发一个对应的 MCP Server——Server 负责把获取明天的闹钟列表、新增一个闹钟这些操作翻译成 MCP 能理解的标准格式任何支持 MCP 的 AI 应用就能直接调用你的闹钟了。Server 的工具列表由 Server 自身决定与客户端或操作系统无关。主流实现中工具通常在 Server 代码里静态声明协议也支持在响应tools/list时动态返回常见用途是根据配置或鉴权状态过滤可用工具集。对于动态数据如数据库的表结构主流做法是通过通用工具的参数传入而非将每条数据映射为独立工具。// Server 代码伪代码tools[{name:read_file,description:读取本地文件内容,parameters:{path:string}},{name:set_alarm,description:新增一个闹钟,parameters:{time:string,label:string}}]// 收到 tools/list 请求时直接返回这个列表就像餐厅菜单由厨房决定今天有什么食材就能做什么菜。实际工作流Cursor 中的完整一次调用以在 Cursor 中输入“请帮我设计一个登录页面考虑到我项目的 UI 组件、技术栈以及 UI 风格”为例完整还原三层架构如何协作用户输入需求 ↓ ① HostCursor接收输入交给 Agent 决策 ↓ ② Agent 判断要回答这个问题需要先读懂这个项目 → 决定调用工具 ↓ ③ Agent 通过 Client 发送 tools/list 请求Stdio 通信 Server 返回可用工具列表 read_file / list_dir / search_code / write_file … ↓ ④ Agent 决策调用顺序多轮工具调用 list_dir(src/components) → 了解有哪些 UI 组件 ↓ Client → Server → 结果回传 Agent read_file(package.json) → 确认技术栈React / Vue ↓ Client → Server → 结果回传 Agent read_file(tailwind.config) → 了解 UI 风格配置 ↓ Client → Server → 结果回传 Agent search_code(Button) → 查看现有组件的实际用法 ↓ Client → Server → 结果回传 Agent ↓ ⑤ Agent 把收集到的项目上下文 用户需求 一起拼入 Prompt发给 LLM ↓ ⑥ LLM 基于真实项目代码生成符合项目风格的登录页面关键点在 MCP 架构下LLM 通常不会直接访问文件系统而是通过 Server 间接获取数据。是 Agent 通过 MCP 这套管道把文件内容搬运过来的LLM 只负责最后的推理和生成。没有 MCPCursor 要实现这个能力就得自己写一套文件读取逻辑有了 MCP直接接入标准的 filesystem-server 即可其他平台也能复用同一个 Server。Server 的生命周期用户打开 CursorHost 启动 ↓ Host 读取配置文件找到需要的 Server 列表 ↓ 本地 ServerHost 作为子进程拉起npx filesystem-server 通过 Stdio 与 Client 建立连接 远程 ServerHost 通过 Streamable HTTP 建立连接不负责启动 ↓ Agent 开始工作通过 Client 调用 Server 工具 ↓ 用户关闭 Cursor ↓ Host 断开所有连接回收本地 Server 子进程 远程 Server 独立运行不受影响工具不可用时怎么办Server 不会自动感知环境变化但做得好的 Server 会在启动阶段主动做环境检测Server 启动时 → 检测依赖是否安装which ffmpeg → 检测 API Key 是否配置 → 检测系统版本是否满足 满足 → 注册该工具出现在 tools/list 不满足 → 跳过Client 拿到的列表里就不会有它如果工具已暴露但执行时才发现报错处理链路如下Client 发起 tools/call ↓ Server 执行时报错环境不支持 ↓ Server 返回标准错误响应 ↓ Agent 收到错误决定下一步 换一个工具 / 提示用户 / 带着错误信息重新请求 LLM 决策就像点外卖理想是菜单上直接标注售罄启动时检测但有时是下单后才告知没货运行时报错——这时候换菜还是退单是 Agent 的职责不是协议的职责。工具列表变化时如何通知连接建立后如果 Server 的工具列表发生变化新增、删除、修改MCP 协议支持 Server 主动推送一条通知给 Clientnotifications/tools/list_changedClient 收到后再发一次tools/list请求拉取最新列表。Server 工具发生变化 ↓ Server 推送通知给 Client notifications/tools/list_changed ↓ Client 收到通知重新发起 tools/list 请求 ↓ Server 返回最新工具列表 ↓ Agent 后续调用基于新列表决策有两个前提条件需要注意第一Server 必须在初始化时声明listChanged: true能力才会发送这条通知——这是 Server 开发者主动选择支持的功能不是默认行为。第二Client 端也必须实现对应的监听处理逻辑否则通知发过来也没用。部分 Host 实现目前仍存在这个问题——通知到了但没有注册处理器工具列表只在初始化时拉取一次动态变化感知不到。换句话说这个机制协议层有规定但实际落地程度参差不齐——这是目前 MCP 生态还在成熟过程中的真实现状。业界常见的 Server 生态MCP 是开放协议任何人都可以开发 Server。目前生态已非常丰富类型代表 Server能做什么文件系统filesystem读写本地文件、目录管理代码托管GitHub / GitLabPR、commit、issue、代码审查数据库Supabase、PostgreSQL查询、写入、管理数据表浏览器自动化Puppeteer、Playwright打开网页、点击、截图、内容抓取效率工具Notion、Slack、Gmail读写笔记、发消息、收发邮件支付商业Stripe查账单、创建支付链接媒体控制Spotify控制播放、搜索歌曲、管理歌单系统控制Windows Control控制鼠标键盘、截屏、管理窗口开发一个自己的 Server 只需做两件事实现tools/list返回工具描述实现tools/call执行工具逻辑并返回结果常用开发库注意上面的 Server 是能力封装下面的库是实现这些能力的技术手段两者不在同一层级系统操作subprocess/child_process执行 Shellos/pathlib文件系统HTTP 请求requests/httpxPythonaxios/fetchJavaScript浏览器自动化Playwright、Puppeteer云服务boto3AWS、google-cloud-*GCP除了上面提到的 ToolsMCP 协议还定义了另外两个原语最基本的、不可再分的操作单元ResourcesServer 向 Agent 提供结构化数据如文件内容、数据库记录和Prompts可复用的提示词模板比如代码 review 模板、“SQL 生成模板”。实际工程中这两者使用较少当前大多数 MCP Server 的核心能力都通过 Tools 实现。MCP vs Function CallingFunction CallingMCP工具定义位置嵌在 Prompt / API 里Server 侧声明工具发现方式随请求传入协议动态发现tools/list与模型的关系强绑定模型提供商与模型解耦任何 LLM 均可使用一句话区别Function Calling 是模型内能力MCP 是系统级能力。小结本质MCP 在协议层基于 JSON-RPC 2.0tools/list、tools/call本质上是标准的 RPC 调用。传输层Stdio / Streamable HTTP只是载体真正的核心是统一的方法调用协议。概念一句话MCP工具与 LLM 之间的 USB 标准解决 M×N 适配问题Host启动和管理一切的运行环境用户直接使用的应用ClientAgent 的通信子模块由 Host 管理Stdio 或 Streamable HTTP 连接 ServerServer将某类能力封装成标准接口的适配层工具列表由 Server 自身决定tools/listClient 问 Server你能做什么tools/callClient 请求 Server执行这个工具MCP 真正解决的是解耦问题——工具开发者实现一次接入所有平台平台支持一次调用所有工具。生态价值随 Server 数量的增长而指数级放大。当然 MCP 也存在一些挑战安全Prompt Injection 可能诱导调用危险工具权限Server 往往直接暴露系统能力鉴权协议本身不规定统一认证机制但 MCP 出现是为了解决连接问题而不是安全问题。