Flink面试高频六考点：状态管理、Watermark、Checkpoint与反压实战
2026/10/20 5:18:39
一、MCP 是什么
MCP（Model Context Protocol），模型上下文协议，由 Anthropic 在 2024 年 11 月发布，现捐赠给 Linux Foundation 旗下的 AAIF 开放治理。
一句话定义：AI 应用连接外部工具、数据源和工作流的统一开放协议。
类比：MCP 是 AI 世界的USB 接口。
| 对比 | Function Calling | MCP |
|---|---|---|
| 类比 | 每个设备配一条专用线 | USB 接口：一个标准，所有设备都能插 |
| 解决的问题 | 模型怎么表达调用意图 | 工具怎么标准化接入、发现、复用 |
| 层级 | 模型输出调用格式 | 工具连接层协议标准 |
二、为什么要用 MCP
Tool Calling 的痛点：
- 每个应用自己定义工具、手写对接代码
- N 个应用 × M 个工具 = N×M 组适配
- API 升级要改代码、跨平台不通用
MCP 的解决思路：
- N×M →N+M
- 工具只需实现一次，到处复用
三、MCP 三层架构
1. 角色层
| 角色 | 职责 | 例子 |
|---|---|---|
| Host | 宿主应用，总控台 | Claude Desktop、Cursor、你的 Agent |
| Client | Host 内连接 Server 的模块，负责能力发现和调用转发 | 每个 Server 对应一个 Client |
| Server | 能力提供方，暴露 Tools/Resources/Prompts | GitHub Server、数据库 Server |
关键细节：
- 一个 Host 可以连多个 Server
- Server 不关心上面是谁在用它
2. 能力层
| 能力 | 说明 | 特点 |
|---|---|---|
| Tools | 可执行动作（搜索 Issue、读文件、查数据库） | 可被调用，有参数 Schema |
| Resources | 只读上下文（文档、日志、数据库记录） | 放进上下文辅助回答 |
| Prompts | 提示模板（代码审查模板、故障排查模板） | 复用团队经验 |
为什么要拆开：读资料和执行动作的风险不同，复用提示和调用 API 的控制方式不同。
3. 协议层
消息格式：基于JSON-RPC 2.0
// Client 请求{"method":"tools/list","params":{},"id":1}// Server 响应{"result":{"tools":[...]},"id":1}传输方式：
| 方式 | 适用场景 |
|---|---|
| stdio | 本地子进程，简单快，适合本地工具 |
| Streamable HTTP | 远程 HTTP 服务，适合团队共享 |
消息格式和传输方式分开，同样的 JSON-RPC 消息可以跑在 stdio 或 HTTP 上。
四、Agent 调用 MCP 工具的流程
1. 连接 → Host 检查已配置的 MCP Server，本地启动子进程或远程网络连接 2. 查能力 → Client 查询各 Server 的 Tool List（含描述和参数 Schema） 3. 做选择 → Host 把用户问题和可用工具交给模型，模型判断是否调用 4. 拿结果 → 模型选择工具 → Client 转发调用 → Server 执行 → 返回结果 5. 继续判断 → 结果拼回对话，模型做下一步判断五、Client 和 Server 的交互协议
| 阶段 | 交互 |
|---|---|
| 初始化 | Client 发initialize→ Server 返回版本能力 → Client 发notifications/initialized |
| 查询工具 | Client 发tools/list→ Server 返回工具名、描述、参数 Schema |
| 调用工具 | Client 发tools/call（工具名+参数）→ Server 执行并返回结果 |
| 资源操作 | resources/list、resources/read、resources/subscribe |
| 变更通知 | Server 可通知 Client 工具/资源列表变化 |
六、MCP 和 Tool Calling 的关系
不是竞争关系，是配合关系：
| Tool Calling | MCP | |
|---|---|---|
| 管什么 | 模型怎么表达调用意图 | 工具怎么被标准化接进来 |
| 视角 | 单次调用的格式 | 工具生态的管理 |
| 运行时 | 模型输出结构化调用 | Host/Client 做能力发现和路由 |
一句话：Tool Calling 管一次调用怎么说清楚，MCP 管一批外部能力怎么接进来、管起来、复用起来。
七、MCP 的权限和安全
核心原则：MCP 是连接协议，不是权限的"免死金牌"。
必须的多层安全检查：
- 知情权：用户清楚启用了哪些 Server
- 透明度：Host 展示关键调用的意图与参数
- 确认机制：高风险写操作必须人工确认
- 服务端校验：Server 把关输入合法性、权限归属、访问范围
- 可追溯性：所有调用轨迹记录，支持审计
八、什么时候适合用 MCP
| 场景 | 选择 |
|---|---|
| Demo、只接一两个简单工具、不复用 | Tool Calling更直接 |
| 工具只服务一个应用，需要细粒度控制 | Tool Calling更直接 |
| 工具跨项目/跨团队/跨客户端复用 | MCP |
| 社区已有成熟 MCP Server | MCP |
| 工具数量多、复杂度高、变更频繁 | MCP |
| 正式 Agent 系统，接多种外部能力 | MCP |
一句话判断：只给自己用、逻辑很轻，Tool Calling 就够；要复用、要管理、要接入工具生态，MCP 更合适。
九、MCP 面临的问题
- 上下文膨胀：工具多时，Schema 占用大量上下文 → 渐进式披露、Tool Search
- 连接资源：远程要维护连接，本地要常驻子进程 → 连接复用、空闲回收、健康检查
- 协议能力多：按需启用，注意弃用项（Roots、Sampling、Logging 已弃用）
- 部署约束：受限环境可能不适合启动子进程或 HTTP 服务