我的博客
返回首页

什么是 MCP：给 AI 应用接上外部世界的通用接口

MCP（Model Context Protocol）是连接 AI 应用、外部数据源和工具的开放协议。本文用一篇入门文章讲清楚它是什么、为什么会火、Host / Client / Server 怎么协作，以及它和 Function Calling、RAG、OpenAPI 的关系。

40 约 10 分钟 · 6966 字 AI
#AI #MCP #Agent #LLM #Tool Use

上一篇 Function Calling 入门 里聊过一件事：大模型本身只会生成文字，但它可以通过结构化的工具调用，间接完成查天气、查数据库、发邮件、改文件这些动作。

Function Calling 解决的是“模型怎么调用一个工具”的问题。那如果我们有十个 AI 应用、二十个外部系统，每个系统都要接一遍工具、鉴权、上下文、提示词、错误处理，会发生什么？

很快就会变成一张乱麻：

AI 应用 A -> GitHub / Notion / 数据库 / 文件系统 / 内部 API
AI 应用 B -> GitHub / Notion / 数据库 / 文件系统 / 内部 API
AI 应用 C -> GitHub / Notion / 数据库 / 文件系统 / 内部 API

每多一个 AI 应用，所有集成都要重写一遍；每多一个外部系统，所有客户端也要重新适配一遍。

MCP 要解决的，就是这个集成爆炸问题。

一句话定义

MCP（Model Context Protocol）是一个开放协议，用统一方式把 AI 应用连接到外部数据源、工具和工作流。

你可以把它理解成“AI 应用的通用接口层”：

  • AI 应用不需要单独知道 GitHub、Notion、数据库、浏览器、文件系统分别怎么接
  • 外部系统也不需要为每个 AI 产品单独写一套插件
  • 双方只要都遵守 MCP，就可以通过同一种协议发现能力、读取上下文、调用工具

官方文档里常用一个类比：MCP 像 AI 应用的 USB-C。USB-C 让不同设备通过同一个接口连接，MCP 则让不同 AI 应用通过同一个协议连接外部系统。

为什么需要 MCP

大模型真正有用的地方，往往不是“回答一个通识问题”，而是进入你的真实工作现场：

  • 读你项目里的代码和文档
  • 查公司内部数据库
  • 看 GitHub issue 和 PR
  • 读取 Notion、飞书、Slack、Google Calendar
  • 调用部署、测试、搜索、图像处理、数据分析工具
  • 根据结果继续规划下一步动作

没有 MCP 的时候，这些能力通常被做成某个产品里的私有插件。一个插件只能在一个宿主里用，换个客户端就要重写。比如你给 Claude Desktop 写了一个“查数据库”的工具，Cursor、VS Code、ChatGPT 或内部 Agent 平台想用，可能又要单独适配。

MCP 把问题拆开了：

  • AI 应用负责提供对话、模型、权限 UI 和用户体验
  • MCP Server 负责暴露某个系统的工具、资源和提示词
  • 协议负责约定双方怎么通信、怎么发现能力、怎么调用和返回结果

这样，一个 GitHub MCP Server 可以被多个 AI 应用复用；一个 AI 应用也可以同时连接多个 MCP Server。

这就是 MCP 火起来的核心原因：它把“每个应用接每个工具”的 N x M 问题，变成了“应用接 MCP、工具也接 MCP”的 N + M 问题。

三个核心角色

MCP 采用的是客户端-服务器架构，但名字容易绕。记住这三个角色就够了。

Host：AI 应用本体

Host 是用户真正打开和使用的 AI 应用，比如一个聊天客户端、IDE、代码 Agent、桌面助手或企业内部智能体平台。

它负责：

  • 管理用户会话
  • 调用大模型
  • 展示工具授权界面
  • 把多个 MCP Server 的能力汇总给模型
  • 决定什么时候把工具结果塞回上下文

你可以把 Host 理解成“舞台”。

Client：Host 内部的连接器

Client 不是用户单独打开的应用，而是 Host 里面负责连接某个 MCP Server 的组件。

一个 Host 可以连接多个 MCP Server，通常会为每个 Server 建一个对应的 MCP Client。这个 Client 负责握手、能力协商、发送请求、接收响应和处理通知。

你可以把 Client 理解成“插在 Host 和 Server 之间的线”。

Server：提供能力的一端

Server 是真正暴露外部系统能力的程序。它可以运行在本机，也可以是远程服务。

例如：

  • 文件系统 MCP Server：读取、搜索、修改本地文件
  • GitHub MCP Server：查询 issue、读取 PR、创建 comment
  • 数据库 MCP Server：查询 schema、执行只读 SQL、生成报表
  • 浏览器 MCP Server：打开网页、点击按钮、抓取页面信息
  • 内部业务 MCP Server：查询订单、创建工单、触发审批流

Server 不是“大模型”，它更像一个带有协议外壳的工具服务。

MCP 暴露什么能力

MCP 最常见的三个服务端能力是：Tools、Resources、Prompts。

Tools：让模型能做动作

Tools 是可执行函数。模型可以在需要时请求调用它们。

例子：

search_docs(query)
query_database(sql)
create_github_issue(title, body)
resize_image(path, width)
run_test(command)

每个 tool 通常会带上名称、说明和输入参数 schema。Host 读取这些元信息后，再把“有哪些工具、什么时候该用、参数怎么填”交给模型判断。

注意：模型只是决定“我想调这个工具”。真正执行工具的是 Host 通过 MCP Client 发请求给 MCP Server，Server 再执行代码并返回结果。

Resources：给模型提供上下文

Resources 是可读取的数据和内容。它们不一定是“函数”，更像是模型可以引用的资料。

例子：

file:///project/README.md
postgres://tables/users/schema
notion://page/product-roadmap
github://repo/issues/123

Resources 的价值在于：它们让上下文来源变得可发现、可枚举、可按需读取。模型不需要一开始就吃下所有内容，而是在需要时读取相关资源。

Prompts：复用工作流和提示模板

Prompts 是 MCP Server 提供的可复用提示词模板或工作流入口。

比如一个数据库 Server 可以提供：

explain_query_performance(sql)
generate_dashboard_from_table(table_name)
write_safe_readonly_sql(question)

这类 prompt 不只是“几句提示词”，它往往承载了某个外部系统的最佳实践。对用户来说，它像一个可调用的工作流按钮；对 AI 应用来说，它是可以发现和复用的能力。

一次 MCP 调用长什么样

假设你在一个 AI 编程助手里问：

帮我查一下最近 7 天博客访问量最高的 10 篇文章，并总结原因。

如果这个助手连接了一个博客数据分析 MCP Server，流程大概是这样：

1. Host 启动后连接 analytics MCP Server
2. Client 和 Server 完成 initialize，协商协议版本和能力
3. Host 通过 tools/list 发现 Server 有 query_analytics 工具
4. 用户提问：最近 7 天访问量最高的文章
5. 模型判断需要调用 query_analytics
6. Host 通过 MCP Client 发起 tools/call
7. MCP Server 查询数据库并返回结果
8. Host 把工具结果放回模型上下文
9. 模型基于真实数据生成总结

协议层面，它不是“模型直接连数据库”。中间始终有 Host、Client、Server、权限和协议消息。

这层结构很重要，因为它把“模型想做什么”和“系统允许做什么”隔开了。模型可以提出调用意图，但是否展示给用户确认、是否允许执行、结果是否回传，都由 Host 和 Server 的实现共同控制。

MCP 和 Function Calling 有什么区别

这两个概念很容易混在一起。

Function Calling 是模型接口层的能力。

它回答的是：模型如何用结构化格式表达“我想调用某个函数，以及参数是什么”。

MCP 是应用集成层的协议。

它回答的是：AI 应用如何发现外部工具、读取外部资源、连接不同 Server、进行能力协商和传输调用结果。

更具体一点：

  • Function Calling 偏向“模型和工具调用格式”
  • MCP 偏向“AI 应用和外部系统之间的协议”
  • MCP Server 暴露出来的 tools，最后经常会被 Host 转成模型可理解的 function/tool schema
  • 模型决定调用哪个工具后，Host 再把这个调用路由到对应的 MCP Server

所以它们不是替代关系，而是上下游关系：MCP 负责把工具和上下文标准化接进来，Function Calling 负责让模型在推理过程中选择和使用这些工具。

MCP 和 RAG 有什么区别

RAG（检索增强生成）是一种应用模式：先从知识库里检索相关内容，再把内容塞进上下文，让模型基于资料回答。

MCP 不是 RAG，但它可以承载 RAG 所需的数据入口。

比如：

  • 文档库 MCP Server 暴露 search_documents tool
  • 文件系统 MCP Server 暴露项目文件 resources
  • 数据库 MCP Server 暴露表结构和查询工具

这些能力都可以被用来做 RAG。但 MCP 本身不规定你怎么切 chunk、怎么做向量检索、怎么排序、怎么拼上下文。它只提供一个标准化通道，让 AI 应用更容易拿到外部上下文。

MCP 和 OpenAPI 有什么区别

OpenAPI 主要描述 HTTP API：有哪些 endpoint、参数是什么、响应是什么。

MCP 面向的是 AI 应用和上下文系统之间的交互，它除了工具调用，还包括：

  • resources/list 和 resources/read
  • prompts/list 和 prompts/get
  • initialize 能力协商
  • notifications 实时变更通知
  • sampling、roots、elicitation 等客户端侧能力
  • stdio 和 Streamable HTTP 等传输方式

你可以用 OpenAPI 描述一个普通 Web API，再写一个 MCP Server 把它包装成模型更容易使用的 tools。两者可以配合，但层级不同。

什么时候适合写 MCP Server

如果你有一个系统，满足下面任意一条，就很适合考虑 MCP：

  • 这个系统经常被 AI 助手查询或操作
  • 你希望同一套能力能被多个 AI 客户端复用
  • 你需要把本地文件、数据库、内部 API 接入 Agent
  • 你想把团队里的固定工作流做成可发现的 prompt
  • 你希望工具调用有统一的权限、日志和审计边界

一些典型场景：

  • 给个人开发环境接文件系统、Git、终端、浏览器
  • 给企业内部接知识库、工单系统、CRM、BI 数据
  • 给内容团队接选题库、素材库、发布系统
  • 给设计/三维/数据分析工具接自动化能力
  • 给代码 Agent 接项目上下文、测试命令和部署流程

MCP 最适合的不是“临时写一个函数给模型用”，而是“这套能力以后会反复被不同 AI 应用使用”。

安全问题不能省

MCP 的能力越强，安全边界越重要。因为 Tools 不是普通文本，它们可能真的会读文件、查数据库、发请求、改状态，甚至执行命令。

做 MCP 集成时，至少要记住几条原则：

  1. 最小权限

    Server 只拿完成任务所需的权限。能只读就不要写，能限制目录就不要开放整个磁盘，能限制表就不要给全库权限。

  2. 用户确认

    高风险工具调用前要让用户看清楚：要调用什么、参数是什么、会影响哪些数据。

  3. 区分可信和不可信上下文

    外部网页、issue、文档、评论区里的文字都可能包含提示注入。不要因为它被 MCP 读进来了，就默认它是可信指令。

  4. 工具描述也要谨慎

    模型会依赖 tool 的 description 判断怎么用工具。来自不可信 Server 的工具说明，不应该被当成绝对可靠的系统指令。

  5. 日志和审计

    企业环境里尤其需要知道谁在什么时候让 AI 调了哪个工具、传了什么参数、返回了什么结果。

MCP 提供了协议边界，但它不会自动替你完成安全治理。真正的安全来自 Host 的授权体验、Server 的权限设计和整个系统的审计能力。

2026 年的 MCP 处在什么阶段

到 2026 年，MCP 已经不只是“本地 AI 工具插件”的概念。官方路线图提到的重点方向包括：

  • 远程传输和规模化部署
  • Agent 通信与任务生命周期
  • 治理流程和规范演进
  • 企业级鉴权、审计、配置可移植性
  • 扩展生态继续成熟

这说明 MCP 正在从“开发者尝鲜工具”走向“AI 应用基础设施”。它还在快速变化，但方向已经很明确：让模型不只是会聊天，而是能以标准、安全、可组合的方式进入真实系统。

怎么开始理解 MCP

如果你只是想先建立直觉，可以按这个顺序学：

  1. 先理解 Function Calling：模型如何表达工具调用意图
  2. 再理解 MCP 的 Host / Client / Server：工具从哪里来，调用怎么被路由
  3. 接着看 Tools / Resources / Prompts：MCP Server 到底暴露什么
  4. 最后再看 transport、authorization、sampling、elicitation 这些高级能力

如果你要动手做，第一个 MCP Server 不要一上来就接复杂系统。可以从一个很小的工具开始：

get_project_summary()
search_notes(query)
list_recent_posts()
query_readonly_database(sql)

先跑通发现工具、调用工具、返回结果这条链路，再逐步加 resources、prompts、鉴权、日志和权限控制。

总结

MCP 的本质不是“又一个 AI 插件格式”，而是 AI 应用和外部世界之间的标准化协议。

它把外部系统包装成可发现、可调用、可读取、可复用的能力，让不同 AI 应用不用重复造轮子，也让同一个工具服务可以进入多个客户端。

用一句更工程化的话说：

Function Calling 让模型学会“伸手调用工具”，MCP 则规定“这些工具从哪里来、怎么发现、怎么连接、怎么返回结果”。

等 AI 应用越来越像真正的工作入口，MCP 这种协议层会越来越重要。因为真正复杂的不是让模型说一句漂亮话，而是让它在正确的权限边界里，稳定地读到正确上下文，调用正确工具，并把结果变成对人有用的行动。

参考资料