下载掌阅APP，畅读海量书库
立即打开
从上一章MCP的定义可知，MCP是LLM与外部系统之间的通信协议，但为什么要叫作“模型上下文协议”呢？要进一步理解MCP，需要先搞清楚什么是模型上下文（Model Context）。
随着ChatGPT被大众所熟知，Prompt（提示词）作为与LLM的唯一交互语言，从AI专业用语演变为大众名词。和LLM的每一次对话，都可以认为是一个完整的Prompt。比如：
1 解释一下Claude最新推出的MCP
类似的对话是大多数人日常的提问方式。但在构建AI Agent等更为复杂的场景中时，比如基于RAG知识库的问答产品背后的Prompt可能是这样的：
1 ···
2 {{Context}}
3 ···
4 基于上述知识库召回内容回答用户的提问。
5 user：解释一下Claude最新推出的MCP
6 answer：
其中，Context是从RAG知识库中检索出来的最相关文本内容，是在产品背后的业务流程中动态生成的。
在像Cursor这样的Coding Agent产品中的Agent模式背后，Prompt可能是这样的：
1 你是一个AI Coding助理，你会通过以下步骤来解决复杂问题：
2 1.任务规划：分解复杂问题为多个子问题
3 2.工具调用：调用提供的工具完成任务
4 3.反思纠错：审查任务是否完成，如遇到错误，尝试找到新的方法
5 4.解答问题：完成所有任务后，总结陈述
6
7 下面是用户提到的上下文代码片段：
8 ···
9 {{Context}}
10 ···
11
12 你有下面这些工具可以使用
13 ···
14 {{ToolList}}
15 ···
16
17 用户的问题是：帮我写一个查询天气的MCP服务器
其中，Context和ToolList均为动态注入Prompt中的内容。这些动态拼接到Prompt中的内容，都可以称之为模型上下文（Model Context）。这些内容会与Prompt一起对最终的模型推理效果产生作用。MCP的本质则关乎如何连接提供上下文的服务并获取相应上下文的标准。例如，连接并执行一个查询天气的工具，其目的是获取天气信息，并最终作为上下文交给模型进行推理。因此，“模型上下文协议”这个名称可以说是非常贴切的。
自ChatGPT发布以来的很长一段时间内，用户与LLM之间的交互都是问答式的，AI只会根据用户输入的问题生成一段文本进行回答。直到OpenAI推出了Function Call API，首次为行业提供了LLM调用外部工具的范式。AI从只能解决信息获取和认知问题，变成了可以调用各种外部工具来解决真实场景中更为复杂的问题。例如，你告诉模型“帮我点一杯星巴克中杯的香草拿铁”，模型可以在响应中给出下订单的API工具的调用描述，开发者通过编程实际执行这个动作，从而完成这个端到端的任务。
Function Call范式的出现是AI Agent发展的重要里程碑，但问题在于，MCP出现之前，所有基于Function Call开发AI Agent的开发者，都必须自己手动完成各种工具的对接实现，而且因为每个人开发的接口规范、通信协议都可能个性化，缺少统一的标准，所以也无法跨应用、跨场景复用。MCP的设计初衷就是解决这个问题，并由此衍生出一系列设计目标。
解决传统AI连接外部系统时需要为每个工具和数据源单独开发代码的问题，实现类似“AI领域的USB-C”，提供统一的协议，达成一次性开发、多系统复用的目标。例如，由社区开发的mcp-mysql-server（非真实名称），可以同时用于Claude、OpenAI、Deepseek等多种模型，而且支持拿来即用。
通过标准化资源（文件/数据库等）、工具（API）及提示词，强化模型对动态上下文的理解。
解决人与AI Agent协作过程中的一系列安全、权限控制等问题。例如，调用工具时主动向用户寻求许可，通过沙盒机制限定AI对本地文件的操作范围，以及对涉及第三方敏感服务的API密钥（如Google Map的API Key）实施规范化管理等。最终希望解决的问题是为AI Agent的运行提供一套标准的安全操作规范。
基于统一的MCP规范，希望可以通过开源社区的力量，生产适用于各行各业、各类产品的MCP服务器标准件。所有人都可以基于现有的MCP生态，快速组装自己需要的工具清单，并结合基座模型的强大推理能力，实现专属的AI Agent助理，真正从端到端层面解决实际问题，从而推动AI Agent应用的发展。