夜雨聆风副标题：先看清谁连接谁，再理解模型到底看见了什么
引言：上一讲讲区别，这一讲看结构
在上一篇文章里，我们讨论了 MCP 和 Function Call 的区别。
我希望你先建立一个层次感：Function Call 更靠近模型输出层，回答的是“模型如何发起一次调用”；MCP 更靠近能力连接层，回答的是“外部能力如何接入 AI 应用的上下文”。
但讲清这个区别之后，一个新的问题马上就会出现：
如果 MCP 负责把外部能力接进来，那它里面到底有哪些角色？谁在连接谁？谁在提供能力？模型真正看见的又是什么？
这一篇，我们就先把 MCP 的基础结构图立起来。
先说好，我不会带你看协议字段，也不会展开 JSON-RPC、stdio、Streamable HTTP、OAuth 这些细节。那些内容当然重要，但对刚开始理解 MCP 的人来说，第一步不是背协议，而是先看清角色关系。
你可以先记住这句话：
看懂 MCP，第一步不是看代码，而是看清 Host、Client、Server 之间的关系。
如果这张图没立住，后面再看 Tools、Resources、Prompts，就很容易又退回一句模糊的“模型接了很多工具”。但 MCP 真不是这么简单地“接工具”。
图注：这张图想先建立一个总览：用户面对的是 Host，Host 通过 Client 连接 Server，Server 再把 Tools、Resources、Prompts 暴露给 AI 应用。
一、到底是谁连谁？
很多人第一次听 MCP，会自然想象出这样一幅画面：
模型直接连上 MCP Server，然后去调用里面的工具。
这个想象很直观，但不够准确。
更准确的理解是：
通常不是模型直接连接 MCP Server，而是 AI 应用里的 MCP Client 连接 MCP Server。
这里有三个基础角色：
- • Host：用户真正使用的 AI 应用或运行环境。
- • Client：Host 内部负责和某个 MCP Server 通信的连接组件。
- • Server：外部能力的提供者，通过 MCP 暴露工具、资源和提示。
所以，MCP 的基础结构不是简单的：
模型 -> 工具
而更像是：
用户 -> Host -> Client -> Server -> 外部系统
模型当然很重要。Host 会调用模型，模型也会根据上下文判断是否使用某个工具。但从 MCP 的连接关系看，直接和 MCP Server 通信的，通常是 Host 里面创建出来的 Client。
这个区别很关键。
因为它意味着：MCP 不是让模型绕过应用、直接冲向外部世界，而是让 AI 应用以一种标准化方式接入外部能力，再决定哪些能力、哪些上下文、哪些工具说明要交给模型使用。
图注：左边是常见误解，右边是更准确的结构。模型不是直接钻进外部系统，真正维护 MCP 连接的是 Host 里的 Client。
二、Host：用户真正使用的 AI 应用
我们先说 Host。
Host 可以理解成用户真正打开和使用的 AI 应用。比如一个 AI 桌面应用、一个 IDE 里的 AI 助手、一个代码 Agent、一个企业内部 AI 平台，都可以是 Host。
用户通常不会说：“我打开了一个 MCP Client。”用户会说：“我打开了 Claude Desktop、Claude Code、Cursor，或者某个企业 AI 助手。”
这些用户真正面对的东西，就是 Host。
Host 不只是一个聊天窗口。它更像整个 AI 应用的现场管理者：处理用户输入，调用模型，组织上下文，管理多个 MCP Client，决定哪些 Server 可以连接，处理权限确认和安全策略，再把工具结果放回对话流程里。
所以我们可以这样理解：
Host 不是某个工具，而是把用户、模型、上下文和外部能力组织在一起的 AI 应用现场。
比如你在一个 AI 编程工具里让模型分析代码。这个 AI 编程工具本身就是 Host。它可能连接文件系统 MCP Server、GitHub MCP Server、数据库 MCP Server，也可能连接内部文档系统。
但用户真正看到的是这个 AI 编程工具。至于它内部创建了几个 Client、连了几个 Server、每个 Server 暴露了什么能力，通常会被产品界面和运行时藏起来。
这也是为什么理解 MCP 时，不能把 Host 和 Client 混为一谈。
Host 是整个应用现场，Client 是 Host 里面的一条连接。
三、Client：Host 里面的连接器
Client 这个词特别容易误导。
我们日常说“客户端”，往往指用户正在打开的应用。但在 MCP 语境里，MCP Client 更偏协议层组件。它通常不是用户直接操作的前台应用，而是 Host 内部创建出来、专门负责连接某个 MCP Server 的连接实例。
一个 Host 可以连接多个 MCP Server。比如：
- • 文件系统 Server
- • 数据库 Server
- • GitHub Server
- • 日历 Server
- • 内部知识库 Server
那么 Host 往往会为每个 Server 创建一个对应的 Client。一个 Client 负责维护一条和某个 Server 的连接。
你可以先用一个不严谨但很有用的类比：
Client 像 Host 派出去和某个外部系统对接的专员：一个专员负责一条连接，避免所有外部系统都混在一起。
它要做的事情包括建立会话、协商能力、路由消息、接收通知、维护连接状态。更重要的是，它帮助 Host 把不同 Server 之间的边界隔离开。
所以，你看到“Host 可以管理多个 Client”这句话时，不要把它想复杂。它说的其实是：一个 AI 应用可以同时连接多个 MCP Server，而每条连接都有自己的边界。
四、Server：外部能力的提供者
再看 Server。
MCP Server 也很容易被误解成“一个工具”。但更准确地说，Server 是外部能力的提供者，它通过 MCP 向 AI 应用暴露一组能力。
这个 Server 可以运行在本地，也可以运行在远程。它可以围绕文件系统、数据库、GitHub、Slack、Figma、浏览器、日历、企业内部业务系统提供能力。
关键不在于它部署在哪里，而在于它通过 MCP 把能力标准化地暴露出来。
而且，这些能力不只包括 Tools。MCP Server 还可以暴露 Resources 和 Prompts。
所以 Server 更像一个外部系统开的标准服务窗口：
它告诉 AI 应用：我这里有哪些资料可以读，哪些动作可以做，哪些任务模板可以复用。
这里要注意一点：Server 暴露能力，不等于模型一定会用对能力。
Server 只是把能力提供出来。至于这些能力是否展示给用户、是否放进模型上下文、工具调用是否需要确认、结果是否需要校验，仍然要由 Host、应用逻辑和后续工程机制来处理。
这一篇先不展开可靠性问题，我们先把结构看清楚。
五、Tools、Resources、Prompts：三类核心能力
理解了 Host、Client、Server 之后，我们再看 MCP Server 暴露的三类核心能力：Tools、Resources、Prompts。
很多人谈 MCP 时，只盯着 Tools。因为工具最显眼，最像“AI 终于能干活了”。但如果只看 Tools，就会错过 MCP 里非常关键的 Context 味道。
Tools：偏行动
Tools 可以理解成模型可以调用的动作。
比如查询数据库、调用 API、执行计算、写文件、创建日程、发送消息、读取某个系统的实时状态。这些都可以被设计成 Tool。
Tool 的重点是：
做一件事，或者取一个结果。
比如数据库 Server 可以暴露一个 query_orders 工具。模型在合适的时候，可以生成一次工具调用请求：我要调用 query_orders，参数是某个查询条件。
但注意，模型不是自己跑进数据库里执行 SQL。它是生成调用意图和参数，Host 或运行时再通过 Client 把请求路由到 Server。
Resources：偏上下文资料
Resources 更像资料、背景和上下文。
比如文件内容、数据库 schema、字段说明、项目文档、API 文档、日志片段、业务规则、知识库条目，都可以是 Resource。
Resource 的重点不是“让模型执行动作”，而是：
让模型知道相关背景。
同样是订单分析，如果模型只知道有一个 query_orders 工具，但不知道订单表有哪些字段、每个字段是什么意思、哪些状态代表退款、哪些渠道属于线下门店，它就很难稳定地分析问题。
这时候，数据库 Server 暴露的表结构 Resource 就很重要。Host 可以读取这些 Resource，把必要的部分组织进上下文，让模型在更明确的背景里使用工具。
所以 Resources 体现了 MCP 里的 Context 味道：不是只给模型一把工具，还要让模型理解工具背后的资料世界。
Prompts：偏可复用任务模板
Prompts 更像可复用的任务模板或工作流入口。
比如“分析订单异常”“总结本周会议”“根据 issue 排查代码路径”“生成客户回访建议”这类任务，如果每次都让用户从零描述一遍，就很低效。
一个 MCP Server 可以暴露 Prompt，让 Host 或用户选择使用。这个 Prompt 里可以包含任务步骤、需要读取哪些资源、应该使用哪些工具、输出应该长什么样。
Prompt 的重点是：
把一类任务的做法，封装成可以复用的交互模板。
所以，三者可以这样区分：
Tools 让模型可以行动，Resources 让模型获得背景，Prompts 让用户和应用复用任务流程。
图注：Tools、Resources、Prompts 都可以来自 MCP Server，但它们进入任务的方式不同：行动、背景和流程，是三个不同层次。
这个区分不是为了背概念，而是为了帮助我们理解：MCP 不是单纯的“工具调用协议”。它更像是在为 AI 应用提供一套外部能力和上下文的接入方式。
六、用一个数据库 MCP Server 串起来
我们用一个具体例子把这些角色串起来。
假设一个企业有订单数据库，数据团队搭了一个数据库 MCP Server。
这个 Server 暴露了三类能力：
- • 一个 Tool：
query_orders，用于查询订单数据。 - • 一个 Resource：
schema://orders，用于提供订单表结构和字段说明。 - • 一个 Prompt：
analyze_order_anomaly，用于引导订单异常分析。
现在，用户在一个 AI 数据分析应用里问：
帮我分析一下本周订单异常。
这时候，链路大概是这样的。
第一，用户面对的是 AI 数据分析应用。这个应用就是 Host。
第二，Host 发现自己配置了一个数据库 MCP Server，于是创建或使用一个 MCP Client，专门维护和这个数据库 Server 的连接。
第三，Client 从 Server 那里发现可用能力：有哪些 Tools、有哪些 Resources、有哪些 Prompts。
第四，Host 根据当前任务，可能会读取 schema://orders 这个 Resource，把订单表结构和字段说明放进上下文。
第五，Host 可能会让模型看到 query_orders 这个 Tool 的说明和参数结构，让模型知道如果需要查询订单数据，可以发起这个工具调用。
第六，如果用户选择了 analyze_order_anomaly 这个 Prompt，或者应用判断这个任务适合使用它，那么这个 Prompt 也可能成为本次任务的结构化指导。
第七，模型在上下文里看到这些信息之后，可能判断：我需要先查询本周订单数据。于是它生成一次工具调用请求。
第八，Host 接住这个调用请求，通过对应的 Client 转给数据库 MCP Server。Server 执行查询，把结果返回给 Client，再回到 Host。
第九，Host 把工具结果回填给模型，模型再基于结果生成解释：异常集中在哪些渠道、哪些商品、哪些时间段，可能原因是什么。
这条链路里，每一层的位置都不同：
Server 提供能力，Client 连接能力，Host 组织能力进入任务，模型基于上下文理解和使用能力。
图注：一个数据库 MCP Server 可以同时提供查询工具、表结构资源和分析提示模板。Host 决定如何把这些能力组织进当前任务。
一旦这样看，MCP 的结构就清楚很多。
七、几个特别容易误解的点
最后，我们把几个常见误解单独拎出来。
第一个误解：模型直接连接 MCP Server。
更准确地说，通常是 Host 里的 Client 连接 MCP Server。模型看到的是 Host 整理后的工具说明、资源内容、提示模板和对话上下文。
这不只是技术细节，也是控制边界的基础。因为中间有 Host，应用才有机会做权限控制、用户确认、上下文选择和结果处理。
第二个误解：Client 就是用户打开的 AI 应用。
在日常语言里，“客户端”常常指用户打开的软件。但在 MCP 语境下，Host 才是用户真正交互的 AI 应用，Client 是 Host 内部用于连接某个 Server 的协议组件。
如果混淆这两个词，后面看多 Server、多连接、权限隔离时就会很乱。
第三个误解：Server 就等于一个工具。
Server 不等于一个工具。一个 Server 可以暴露多个 Tools，也可以同时暴露 Resources 和 Prompts。
比如一个数据库 Server 不只是提供“查询”这个动作，还可以提供表结构、字段解释、常用分析模板。真正有价值的 MCP Server，往往不是孤零零的一把工具，而是一组围绕某个外部系统组织起来的能力入口。
第四个误解：Tools、Resources、Prompts 都由模型自动控制。
这也不准确。
从 MCP 的典型控制直觉看，Tools 更偏模型控制，Resources 更偏应用控制，Prompts 更偏用户控制。
也就是说，工具常常是模型根据任务选择是否调用；资源通常由应用决定什么时候读取、怎么放入上下文；Prompt 则常常通过用户选择或应用入口来触发。
当然，真实产品可以有不同设计，协议本身也不强制规定所有交互界面必须长成一种样子。但这个控制层次很有用，它能帮我们避免把所有能力都想象成“模型自动乱用”。
结语：先看结构，再看协议
这篇文章，我们没有看代码，也没有看协议字段，只做了一件事：把 MCP 的基础结构先立起来。
你可以先把它记成一条线：
Host 承载 AI 应用，Client 连接外部 Server，Server 暴露 Tools、Resources、Prompts，Host 再把合适的能力组织进模型上下文。
这句话看起来简单，但它能帮我们避开很多误解。
模型不是直接冲向外部系统；Client 不是用户打开的 AI 应用；Server 不只是一个工具；Tools、Resources、Prompts 也不是同一种东西。
理解 MCP，先不要急着背术语。先问三个问题就够了：
- • 用户正在使用的 AI 应用是谁？这是 Host。
- • Host 通过哪条连接对接外部系统？这是 Client。
- • 外部系统通过 MCP 暴露了哪些能力？这是 Server 以及它提供的 Tools、Resources、Prompts。
只要这张结构图立住了，后面再看 MCP 的权限、安全、Server 设计和工程边界，就不会像在背一堆陌生名词，而是在看一个系统里每一层到底承担什么责任。
参考资料
- • Model Context Protocol, Architecture overview: https://modelcontextprotocol.io/docs/learn/architecture
- • Model Context Protocol, Architecture specification: https://modelcontextprotocol.io/specification/2025-06-18/architecture
- • Model Context Protocol, Understanding MCP servers: https://modelcontextprotocol.io/docs/learn/server-concepts
- • Model Context Protocol, Server overview: https://modelcontextprotocol.io/specification/2025-06-18/server/index