• 文档
• 教程
• 知识库

Model Context Protocol（MCP）是一套开放标准，用于定义 AI 应用如何以一致的方式连接外部工具、数据源与服务。本文基于 developer-roadmap 仓库中 ai-agents 学习路径的 MCP 主题文档，结合仓库内 MCP 客户端、服务器、宿主与传输层等配套主题，系统讲解 MCP 的核心架构、各角色职责、服务器构建要点与部署形态。读完本文，你将掌握 MCP 的"标准接口 + 协议通信"思想，能够理解一个 Agent 如何通过 MCP 无缝接入文件系统、数据库与第三方 API，并知道从零构建与部署 MCP 服务器的关键步骤。

为什么需要 MCP：告别"为每个工具写一套集成"

在 AI Agent 的实际落地中，最繁琐的一环往往不是模型本身，而是"连接"。Agent 每需要访问一个文件系统、一个数据库或一个第三方 API，传统做法都是为它编写一套专用的连接代码：不同的服务有不同的鉴权方式、消息格式与调用约定，导致集成代码大量重复、难以复用。

MCP 正是为解决这一问题而生的开放标准。它不关心你接入的是哪个具体工具，而是提供一套任何合规客户端与服务器都能使用的公共接口。如图中所示，MCP 位于 Host 与 Server 之间，以标准化的消息协议屏蔽底层差异：

• 对 Agent 而言：新增能力时无需每次编写专属的连接代码（bespoke connection code），只需接入符合 MCP 的服务器即可"即插即用"；
• 对工具提供方而言：服务器遵循同一套共享协议，可以被不同的 AI 应用直接复用，无需针对每个应用做定制改造。

这正是 MCP 文档强调的核心价值："Instead of building a custom integration for every tool an agent needs, MCP provides a common interface that any compliant client and server can use to communicate."它把"每个工具一种集成方式"的碎片化世界，收敛为"一套协议、任意组合"的统一生态。

MCP 架构中的四大角色

从仓库内 mcp-servers、mcp-client、mcp-hosts 与 transport-layer 等配套文档可以梳理出 MCP 架构的完整拼图。

1. MCP 服务器（Server）：能力的提供方

MCP 服务器向任何兼容客户端暴露一组工具、数据或能力。它可以提供文件系统访问、数据库查询，或封装某个第三方 API。由于所有服务器都遵循同一协议，它们可以在不同 AI 应用之间被复用，而无需为每个应用编写自定义集成。换句话说，服务器是"能力容器"，把一种具体的外部资源翻译成 MCP 标准消息。

2. MCP 客户端（Client）：与模型对话的枢纽

客户端是 Agent 中与语言模型 API 对话的部分，承担完整的消息生命周期：

• 打包：收集消息、文件与工具信号（tool signals），按 MCP 协议封装后发送给模型；
• 解析：收到模型回复后拆包、校验格式，再把结果交给其他模块；
• 治理：跟踪 token 用量、过滤隐私数据、对失败调用进行重试，并记录关键事件用于调试。

它本质上是一个"翻译器 + 调度器"：把 Agent 的意图标准化地送达模型，再把模型的输出标准化地交还系统。

3. MCP 主机（Host）：可信的桥梁

MCP Host 是运行协议的计算机或服务，承担"枢纽"职责：

• 处理传入调用，加载 MCP 清单（manifest），校验请求；
• 在用户、工具与语言模型之间传递数据；
• 可缓存最近消息、跟踪 token 用量，并在把提示词发给模型之前附加安全或计费检查；
• 对外暴露 API 端点，方便应用接入。

Host 既可以在笔记本上运行用于本地测试，也可以部署到云平台以支撑规模化流量。它是Agent、工具与数据交汇的可信桥梁——安全策略与鉴权逻辑通常集中在这里。

4. 传输层（Transport Layer）：底层的通信保证

传输层负责在系统各组件之间可靠、高效地搬运数据，定义消息如何被打包、寻址与传输（跨网络或单机内部），确保信息无差错、无丢失地到达目的地，并将底层网络协议与硬件的复杂性对上层屏蔽。MCP 分层架构中，传输层位于 Host 与 Server 通信链路的基础位置，是"标准接口"得以落地的物理通道。

MCP 服务器构建要点：从端点设计到上线治理

仓库中的 Creating MCP Servers 给出了构建 MCP 服务器的完整路线图，可归纳为以下五个步骤：

第一步：选定语言与 Web 框架

先选择一门语言和一个 Web 框架作为服务器基础。官方 Building an MCP Server 文档指出，服务器的本质是"AI Agent 与各类数据源/工具之间的中间层"，因此任何成熟的后端技术栈都可以胜任。

第二步：设计 REST 端点

典型端点包括：

每个端点都按照 MCP 的 JSON Schema 交换数据，保证消息结构可被客户端与服务器双方解析。

第三步：会话数据持久化

使用数据库或内存存储保存会话日志，每条记录至少包含会话 ID、角色（role）与时间戳（timestamp），为多轮对话与上下文恢复提供数据基础。

第四步：鉴权与过滤

• 添加基于 token 的认证，防止未授权访问；
• 增加过滤机制，让 Agent 只获取其真正需要的数据子集，避免过度暴露；
• 设置消息大小上限与请求速率限制，防止单个请求拖垮服务或引发资源滥用。

第五步：测试、监控与压测

最后编写单元测试、接入监控，并运行负载测试（load tests）来验证稳定性——这与仓库内 unit-testing-for-individual-tools 等主题强调的"Agent 工具也要做工程化保障"一脉相承。

部署形态：本地桌面 vs 远程云

MCP 服务器有两种典型部署方式，对应不同使用场景：

• 本地桌面部署：参考 Connect to Local Server 文档，把 MCP 软件、所需运行时与模型文件直接装在个人电脑上，服务器监听127.0.0.1:8000这样的本地地址，默认仅本机可访问。适合快速测试、个人演示或私有实验，成本低且完全可控；缺点是受本机硬件性能限制，且外部访问需借助 ngrok 或本地端口转发等隧道工具。
• 远程/云部署：参考 mcp-hosts 中关于云平台部署的说明，将 Host 部署在云端可支撑规模化流量，便于多客户端共享同一套 MCP 能力。

在 developer-roadmap 中继续深入 MCP

本仓库为 MCP 提供了完整的学习闭环，你可以顺着以下文档逐步深入：

• 理解整体： Model Context Protocol (MCP)（本文主体）、ai-engineer 视角的 MCP 主题
• 拆解角色： MCP Servers、MCP Client、MCP Hosts、Transport Layer
• 动手构建： Creating MCP Servers、Building an MCP Server、Building an MCP Client
• 部署实践： Connect to Local Server、Connect to Remote Server

小结

MCP 的引入，把 AI Agent 的外部能力接入从"每工具一套定制代码"演进为"一套标准协议、任意组合复用"。理解服务器（能力提供方）、客户端（模型对话枢纽）、主机（可信桥梁）与传输层（底层通道）四者的分工，是掌握 MCP 的起点；而按"端点设计 → 会话持久化 → 鉴权过滤 → 限流 → 测试压测"的路线构建服务器，则是把标准落到实处的关键一步。无论你选择本地桌面还是云端部署，MCP 都能让 Agent 的能力扩展变得更快、更一致、更可复用。

• 文档
• 教程
• 知识库