金字塔模型思维学习MCP
MCP（Model Context Protocol）是一种基于JSON-RPC 2.0的标准通信协议，用于实现AI应用程序与外部资源的安全高效连接。该协议解决了AI工具集成碎片化、安全权限控制、实时数据获取等核心问题，通过标准化接口、安全沙箱和动态上下文流三大机制，将外部工具、资源和私有数据的调用统一封装。其工作原理包括建立连接、能力查询、调用执行和上下文注入四个核心步骤，使AI应用能够安全、动
学习路线图
MCP定位
MCP是用于将AI应用程序和外部资源（工具调用、文件资源访问、工作流程执行）进行连接的标准通讯协议。
解释：MCP类似于TAB-C,将AI和外部资源的连接提供了一个连接标准化方式。
MCP解决哪些核心问题
1. MCP的应用场景
思路：在什么背景下出现了什么核心难题，需要做什么事情。
背景：
随着大模型能力爆发，很多企业都想将AI嵌入现有业务流，但面临一些核心问题：大模型无法感知实时数据、无法获取专业领域知识、无法操作外部工具，实际使用场景处处受限。
技术角度的核心难题：
|
痛点 |
具体表现 |
传统方案缺陷 |
|
1. 工具集成碎片化 |
为Copilot、Cursor、内部Agent分别开发Jira/Confluence适配器，重复投入 |
每新增1个AI工具需重写集成，维护成本指数级增长 |
|
2. 安全权限黑洞 |
硬编码API密钥、开放数据库直连，LLM可能越权操作敏感系统 |
网关层鉴权无法细粒度控制“LLM能调用什么”，审计缺失 |
|
3. 上下文静态割裂 |
模型回答基于训练数据，LLM无法动态获取用户所需的实时上下文（如当前项目进度、最新邮件），导致回答脱离实际场景。 |
RAG仅支持被动检索，缺乏“主动推送业务上下文”能力 |
|
4. 私有知识接入高危 |
为让模型理解内部流程，需微调或上传知识库至公有云 |
数据泄露风险高，且无法动态更新（如新发布的产品文档） |
|
5. 生态封闭锁死 |
某IDE插件绑定特定工具链，用户无法自由组合“最爱的AI+最爱的工具” |
厂商绑定严重，创新被平台生态限制 |
2. MCP的解决方案（设计思路）
- 定义统一的协议管理所有的AI和所有的工具连接（将AI应用程序和工具管理、资源访问等进行解耦解决生态和工具碎片化管理问题）
- MCP内部做安全权限和参数校验
- 将外部工具、资源、私有数据的调用统一封装在MCP内部
- MCP执行完成后主动推送应用上下文个LLM
a. 核心机制
- 标准化接口：定义
tools（可执行操作）、resources（可检索数据）、prompts（上下文注入）三类能力，工具方实现一次MCP服务，全域AI客户端即插即用。 - 安全沙箱：用户显式授权（如“允许AI查看当前项目Confluence”），调用全程审计，密钥永不暴露给LLM。
- 动态上下文流：MCP服务器主动推送业务上下文（例：开发者打开文件时，MCP注入“该文件关联的Jira Ticket"），让AI“看见”工作现场。
3. MCP架构
架构理解思路开篇点明MCP架构设计思想
- 分层解释每层职责
- 重点说明安全机制如何设计
- 举例说明典型工作流
- 总结架构价值
MCP调用的核心设计思想
协议标准化（JSON-RPC 2.0）、能力抽象（Tools/Resources/Prompts）、安全授权（用户显式授权）、生态解耦（Client/Server分离）
|
支柱 |
实现载体 |
解决的核心问题 |
|
协议标准化 |
JSON-RPC 2.0 + MCP 扩展规范 |
消除“每个 AI 工具重复造轮子”的生态碎片化 |
|
安全双闸设计 |
用户授权闸口（Host） + 服务鉴权守卫（Server） |
防止 LLM 越权操作，实现“用户全程可控” |
|
能力抽象解耦 |
Tools/Resources/Prompts 三元模型 |
工具提供方专注能力实现，Host 专注用户体验 |
MCP采用的是分层架构
|
层级 |
核心组件 |
核心职责 |
设计哲学 |
|
1. 用户交互层 |
Host 应用（VS Code/Claude） |
• 接收用户指令 |
用户体验中心 |
|
2. 协议执行层 |
MCP Client（Host 侧）MCP Server（工具侧） |
• 生成/解析 JSON-RPC 消息 |
通信标准化 |
|
3. 能力抽象层 |
Tools（可执行操作） |
• 将工具能力映射为标准语义单元 |
能力语义化 |
|
4. 工具服务层 |
Jira API / Confluence SDK本地文件系统 / 数据库 |
• 执行具体业务逻辑 |
业务专注 |
🔒 安全双闸架构（协议强制嵌入）
|
闸口 |
位置 |
触发时机 |
验证内容 |
协议依据 |
失败处理 |
|
用户授权闸口 |
Host 侧（MCP Client） |
发送 |
• 能力声明 |
MCP 安全规范： |
• 请求终止 |
|
服务鉴权守卫 |
Server 侧（安全校验器） |
收到请求后、执行前 |
• API Token 有效性（JWT/OAuth2） |
MCP 规范建议： |
• 返回标准错误码 |
MCP的构成和工作原理
MCP的构成
协议基石
定于通信协议的语法规范，基于JSON RPC 2.0协议，规范请求/响应格式、方法调用、错误处理语法，MCP 严格复用 JSON-RPC 2.0 的以下语法要素（官方规范）：
|
语法要素 |
规范定义 |
MCP 中的实际体现 |
为什么关键 |
|
1. 消息骨架 |
所有消息必须含 |
每个 MCP 请求/响应首行 |
标识协议版本，避免与 JSON-RPC 1.0 混淆 |
|
2. 请求标识 |
|
请求必带 |
匹配请求与响应，支持并发调用 |
|
3. 方法命名 |
字符串格式（如 |
MCP 扩展为 命名空间式： |
避免方法名冲突，清晰表达能力类型 |
|
4. 参数传递 |
|
MCP 强制使用对象参数： |
提升可读性与可维护性 |
|
5. 响应结构 |
成功： |
MCP 错误直接复用： |
全球统一错误语义（-32601=方法不存在） |
|
6. 标准错误码 |
预定义范围： |
Server 返回 = 无效参数 |
Host 无需自定义错误码，跨实现一致处理 |
|
7. 通知机制 |
无 |
MCP 禁止在 |
确保关键操作必有结果反馈 |
协议基石在 MCP 构成中的作用（四维价值）
|
维度 |
作用 |
无基石的灾难场景 |
|
1. 跨语言通信 |
任何语言（Python/Go/Rust）的 JSON-RPC 库可直接解析 MCP 消息 |
每个工具需为每种语言重写通信解析器 |
|
2. 高可读性 |
消息为纯 JSON，肉眼可读： |
二进制协议需专用工具解码，排查成本高 |
|
3. 生态复用 |
直接集成成熟 JSON-RPC 库（如 Python 的 |
从零实现通信层，易引入安全漏洞 |
|
4. 协议演进 |
JSON-RPC 2.0 稳定十年，MCP 专注业务语义创新 |
通信层频繁变更导致生态碎片化 |
通讯实体
MCP client
MCP Client ≠ 简单的JSON-RPC客户端：它是Host（AI应用）中专门负责MCP通信的模块，包含能力管理、授权控制、上下文注入等高级逻辑。
MCP Client 细粒度构成：
- 连接管理器（Connection Manager）：管理与多个Server的连接生命周期
- 能力缓存（Capability Cache）：存储从Server获取的Tools/Resources/Prompts列表
- 授权控制器（Authorization Controller）：触发用户授权弹窗、管理授权状态
- 请求构造器（Request Builder）：根据能力声明生成合规的JSON-RPC请求
- 响应处理器（Response Handler）：解析Server响应，注入LLM上下文或更新UI
- 错误处理器（Error Handler）：标准化处理JSON-RPC错误码
MCP server
声明能力和执行操作，MCP Server ≠ 简单的JSON-RPC服务端：它是工具提供方封装的MCP适配层，包含能力注册、执行引擎、安全校验等。
MCP Server 细粒度构成：
- 传输适配器（Transport Adapter）：处理stdio/WebSocket等连接
- 协议解析器（Protocol Parser）：验证JSON-RPC语法，路由到对应处理器
- 能力注册表（Capability Registry）：存储声明的Tools/Resources/Prompts元数据
- 执行引擎（Execution Engine）：调用实际业务逻辑（如调用Jira API）
- 安全校验器（Security Validator）：验证请求参数、权限（服务端层面）
- 通知管理器（Notification Manager）：（可选）推送资源变更通知
能力模型（核心三支柱）
tools:可执行函数
resource：可访问的资源信息
prompts：预制的提示词模板
三个核心支柱需要统一抽象为外部能力，使LLM可以理解并安全调用外部工具，每种能力都有标准声明和调用接口
连接通道
stdio streamable HTTP等，将协议逻辑和物理通道解耦，用于适配不同的部署场景
安全与生命周期管理
client和server的连接状态管理，包括握手、初始化、安全审查、心跳监控、断开连接等。
目的：确保最小权限原则，让LLM仅能访问用户显式授权的能力与数据
MCP的工作原理
本部分主要描述MCP是如何工作的，包括核心流程、组建交互、关键步骤等，聚焦动态的工作过程，而非构成说明
基准定调
MCP是一个基于JSON RPC 2.0协议的，用于在AI和外部资源建立一套标准化、安全、动态的通信连接的协议。
AI应用在使用MCP时采用预加载方式，AI应用在启动过程中会根据需要创建对应的MCP client和MCP的连接并将获取到的MCP资源信息注入到应用上下文中。
MCP的实际工作中分为4个核心步骤：
- 建立状态连接；Client首先与Server建立连接并统一协议版本以及能力沟通
- 能力查询；在建立连接后，client会根据server的能力声明（tools、resource、prompts）通过xxx/list查询方式查询所有的能力信息，将其加载到应用上下文当中
- 能力调用；LLM在根据用户查询分析需要调用的外部工具时会触发MCP的能力调用接口执行相应的动作
- MCP server在执行完任务后会将结果返回给Client，由client将拿到结果注入到上下文信息中。
第一步：建立连接
- 由client携带MCP协议版本信息、client的身份、能力信息等向server发起一个初始化（initialize）请求
- server收到初始化请求后根据请求中携带的信息完成初始化操作，并向client声明MCP的能力范围
- client根据收到的响应信息通过调用tools/list、resources/list、prompts list函数获取对应的工具信息、资源信息和提示词信息。
至此完成client和server的连接，client会将获取到的能力信息注入到应用上下文中。
第二步：调用MCP
注：AI应用程序在调用MCP之前会由LLM推理的结构化输出判断调用哪个MCP应用并执行
- 预处理；client首先检查权限声明，并通过弹窗等方式向用户发起授权请求
- 工具调用；在有权限的前提下，client携带上下文信息和权限信息以及身份认证等信息向server发起调用请求
- 工具执行；MCP server执行业务逻辑，包含安全校验、身份审查、、参数校验、执行、脱敏等并将结果返回给client
第三步：上下文信息注入
MCP client在收到最终信息后，将其注入到应用上下文中，给LLM生成最终结果使用。
MCP 在 AI 开发面试中的定位与要求
🔑 MCP 考察场景（精准判断）
全屏复
|
岗位类型 |
是否考察 MCP |
考察深度 |
您的应对策略 |
|
通用 AI 应用开发 |
低（<20%） |
概念级：”是否了解 MCP？“ |
了解核心价值即可 |
|
AI Agent/智能体平台开发 |
高（>70%） |
设计级：”如何设计安全工具调用方案？“ |
重点准备！ |
|
LLM 工具链/基础设施开发 |
极高（>90%） |
实现阶段：”用 Java 实现 MCP Server“ |
深度掌握 + 动手实践 |
📌 MCP 面试要求分层（按岗位匹配）
← 可左右滑动查看更多容 全屏复制
|
层级 |
要求 |
您需掌握的内容 |
面试话术示例 |
|
初级（了解） |
知道 MCP 是什么 |
• 定义：Model Context Protocol |
“MCP 是让 AI 安全调用外部工具的协议，类似 HTTP 之于 Web，解决工具集成碎片化问题” |
|
中级（应用） |
能描述工作流程 |
• 五步流程：连接→初始化→能力发现→授权→调用 |
“我们设计时会在 Host 侧加授权弹窗，Server 侧做 Token 校验，双闸保障安全” |
|
高级（设计） |
能设计方案/对比 |
• 为什么选 MCP 而非自研协议？（生态/安全/标准）<️ 集成 Java 项目：用 库实现 Server |
“在 Java 项目中，我们用 json-rpc 库封装业务逻辑为 MCP Server，Host 通过 stdio 调用，避免硬编码 API 密钥” |
✅ Java 工程师独特优势：
- 协议实现：JSON-RPC 2.0 有成熟 Java 库（如
com.googlecode.jsonrpc4j） - 企业集成：Java 擅长封装遗留系统（ERP/CRM）为 MCP Server
- 安全加固：Java 安全框架（Spring Security）可强化 Server 鉴权
实践价值：
- 面试时可展示：“我用 Java 实现了 MCP Server，封装了公司 Jira 系统”
- 体现工程能力：协议解析、安全校验、工具封装
- 直击企业痛点：“如何让 AI 安全调用内部系统”
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
13
0- 0
已为社区贡献1条内容
所有评论(0)