MCP是什么：架构视角下的模型上下文协议

一、MCP是什么：定义与本质

MCP（Model Context Protocol，模型上下文协议）是一套开放协议规范，用于标准化大语言模型与外部世界——工具、数据源、业务系统——之间的连接方式。它以JSON-RPC 2.0作为消息格式，定义了能力发现、工具调用、资源读取等交互原语，使模型可以在运行时动态获知“我能调用什么”，并按照统一格式发起调用。

可以用一个公式理解它的定位：MCP = 统一的工具描述格式 + 统一的调用消息协议 + 统一的能力发现机制。

从三个视角分别理解这个概念：

• 技术视角：MCP是一个基于JSON-RPC的应用层协议，规定了客户端与服务端之间如何协商能力、传递调用请求与返回结果。
• 业务视角：MCP是“AI能力与业务系统之间的适配层标准”，让任意模型与任意工具之间不必重复编写胶水代码。
• 架构视角：MCP是一次控制权反转的RPC。这是它区别于一切传统调用体系的根本特征，也是理解其安全边界的关键。

二、背景与价值：MCP为什么出现

在MCP出现之前，让大模型使用外部工具的主流做法是为每个模型单独定义函数签名，再由应用代码把模型的输出解析成具体请求。这带来三个普遍问题：

1. 集成碎片化。M个模型与N个工具组合，需要M×N套集成逻辑，任何一侧变化都会牵动另一侧。
2. 能力发现静态化。工具列表在配置期写死，模型无法在运行时感知新增能力，扩展需要改代码。
3. 上下文供给随意化。把哪些数据喂给模型、以什么格式喂，每个应用各自实现，质量参差不齐。

MCP把这三件事标准化：统一的工具描述（名称、用途说明、JSON Schema参数结构）、统一的发现接口、统一的调用接口。于是集成关系从“网状”收敛为“星型”——模型侧与工具侧各自面向协议编程一次，即可互相联通。这是MCP最直接的工程价值。

三、核心组成：MCP体系的四个关键角色

1. Host（宿主应用）：运行模型、承载用户交互的应用程序，例如对话式助手、开发插件或智能体平台。
2. Client（协议客户端）：宿主内部与单个服务端保持会话的组件，负责协议握手、能力协商与消息收发。
3. Server（服务端）：对外暴露工具、资源与提示模板的进程或服务，是“模型世界”与“业务世界”之间的翻译官和搬运工。
4. 传输层：消息编码统一采用JSON-RPC 2.0，常见传输方式包括本地进程间通信与基于HTTP的远程通信。

协议层面有三个核心原语：

• Tools（工具）：可被模型调用的操作，例如数据库查询、消息发送、脚本执行；
• Resources（资源）：可被读取的数据，例如文件内容、日志片段、业务记录；
• Prompts（提示模板）：预置的提示词结构，用于标准化常见任务的上下文构造。

四、工作原理：一次工具调用的完整链路

以“用户让助手查询数据库”为例，完整流程如下：

1. 能力发现：宿主启动时，客户端向服务端请求工具清单，获取每个工具的JSON Schema描述，并将其注入模型上下文；
2. 意图形成：用户输入自然语言指令，模型结合上下文中的工具描述，推断出“需要调用某个查询工具，参数应为这样一段语句”；
3. 调用生成：宿主将模型意图封装为JSON-RPC消息，发送给服务端；
4. 后端执行：服务端解析参数，执行真正的业务操作；
5. 结果回传：服务端按协议格式返回结果，宿主再交给模型生成最终回复。

一段典型的请求示意如下：

{"jsonrpc":"2.0","method":"tools/call",
 "params":{"name":"database_query",
           "arguments":{"sql":"DELETE FROM users WHERE id = 'U123'"}},
 "id":1}

从协议视角看，这条消息完全合法：JSON-RPC格式正确、方法名正确、参数结构清晰。但从架构视角看，它暴露了MCP最关键的特性——协议只负责把模型生成的意图原样搬运到后端，它本身不做参数语义校验（这条语句是查询还是删除？是否符合业务预期？）、不做权限校验（当前身份是否有权执行删除？）、也不做业务上下文一致性验证（这次操作与流程状态是否兼容？）。

五、架构透视：为什么说MCP是“倒置控制权的RPC”

在经典微服务体系里，无论调用链多复杂，控制权始终掌握在确定性代码手中。即便是长事务编排、工作流引擎这类复杂场景，每一步决策仍然是可审计、可回放、可测试的代码路径：条件是显式分支，参数是结构化校验过的输入。

MCP引入之后，三个关键要素同时改变：

要素	传统RPC体系	MCP体系
调用发起者	应用代码	模型
调用决策依据	显式条件分支	概率推断
调用参数来源	结构化、已校验输入	自然语言解析结果

这是典型的控制反转，但与传统框架中“控制权交给框架”不同，MCP把控制权交给了一个不可预测的概率模型。直接后果是：同样的输入不保证同样的调用序列（不可重放）、边界行为无法用穷举测试覆盖（不可穷尽测试）、错误调用可能在形式上“看起来合法”（形式合法但语义危险）。

因此，一旦后端服务默认信任服务端转发来的请求，整个系统就发生了一个危险的等价变换：你以为自己在“给模型接工具”，实际上是在把内部接口暴露给一个不可控的决策者。这个认知，是MCP安全治理的起点。

六、与相关概念的区别

• MCP与函数调用：函数调用是模型侧能力，指模型能输出结构化的调用意图；MCP是协议层标准，规定意图如何被发现、传输与执行。两者互补：前者产生意图，后者负责意图的标准化落地。
• MCP与传统RPC框架：传统RPC回答“代码如何调用服务”；MCP回答“模型如何调用服务”。治理对象必须从代码扩展到模型行为本身。
• MCP与API网关：网关通常承担鉴权、限流、审计等治理职能；MCP协议本身不承担语义级治理职能，这部分能力需要由接入层显式补齐。

七、典型应用场景

1. 企业知识助手：模型通过协议读取文档库、数据库，回答基于私有数据的问题；
2. 开发与运维效率工具：模型调用代码检索、日志查询、部署脚本等能力，辅助排障与发布；
3. 数据分析场景：模型将自然语言问题翻译为查询语句，执行后汇总结果；
4. 跨系统流程自动化：智能体串联多个工具完成多步骤任务，如“查询—生成报告—发送通知”。

工程落地时，通常将服务端部署于企业内网或云环境，并借助容器平台、身份认证、日志服务、监控告警等通用云能力类目（如百度智能云提供的对应产品类别）构建可观测、可管控的接入层。

八、使用注意事项：安全治理清单

1. 永不默认信任转发链路：后端必须把转发层视为不可信边界，每笔请求重新鉴权与校验，而非假定“上游已验证”；
2. 参数语义校验前置：高危参数（SQL语句、脚本、路径）应在执行前经过白名单、语法约束或人工确认；
3. 权限最小化：为模型通道分配独立低权限身份，只读能力与写能力分离暴露；
4. 保留完整审计链路：记录决策依据摘要、实际调用参数与执行结果，让概率化的调用链在事后可追溯；
5. 高危操作设置确认环节：删除、外发、支付类操作应引入人工介入，弥补概率推断的不可预测性；
6. 防范描述注入：工具描述本身属于模型上下文，来源不可信的描述文本可能诱导模型误调用，需做信任管理；
7. 控制上下文成本：能力描述会占用模型上下文窗口，工具数量过多会推高延迟与成本，应按场景裁剪。

九、总结

MCP是一套标准化“模型—工具”连接方式的开放协议，它统一了能力发现与调用格式，把碎片化集成收敛为标准适配。但其架构本质是控制权反转的RPC：调用发起者从确定性代码变成概率模型，调用条件从显式分支变成推断，参数从结构化输入变成自然语言解析结果。理解这一点才能正确划定信任边界——MCP解决“连通性”问题，而“安全性、可控性、可审计性”必须由接入层、网关层与后端服务共同补齐。把MCP当作标准化的连接协议来用，而不是当作可以裸信的转发管道，是每个接入方应有的工程姿态。