1. 模型上下文协议 MCP是什么
模型上下文协议是一个标准化的接口和框架，允许AI模型与外部工具、资源和环境无缝交互。它可以被视为是AI系统和外部服务都可以使用的通用适配器，可以相互理解而无需自定义粘合代码。
MCP协议使AI应用中的每一个相关方都受益。
对于开发人员来说，无需为每个工具编写自定义集成，只需要在应用程序中实现一次MCP，之后各种工具和数据源即插即用，大大减少了集成工作量和维护工作。
对于API提供商来说，如果有有用的服务或库，可以通过MCP公开，并立即提供给任何使用MCP的AI应用。主要在本地实现一次MCP协议，即可与许多AI系统兼容。
对于最终用户来说，将将获得更强大、更灵活的AI应用。由于支持MCP的AI可以获取实时信息、使用特定功能或控制设备，因此用户能够获得更相关、更准确的帮助。AI不再局限于其训练数据，能够真正充当用户的代理。
MCP是一种开放协议，用于AI应用程序或代理环境和外界服务之间的结构化通信。通过统一接口，MCP打破了数据孤岛和互操作性障碍。例如，在MCP下，无论AI需要查询SQL数据库、调用Web API还是执行脚本，都使用相同的协议和消息格式。
此外，MCP的灵感来源于语言服务器协议（LSP）在开发工具领域的成功。LSP定义了一个标准，以便编辑器可以以统一的方式与任何编程语言的分析引擎对话，而不是每个编辑器都需要为每种语言定制一个插件。
同样，MCP还支持AI助手来与任何实现MCP服务标准的工具进行对话。AI Agent可以根据任务上下文自主发现、选择和协调工具，而不是局限于设计时连接的固定工具箱。
2. LLM中的上下文管理
LLM根据上下文窗口生成响应，即提供给模型的文本输入，这通常包括用户的输入提示、对话历史记录、指令或提供给模型的额外输入。模型的响应完全由这些上下文及其训练决定。但是，有几点需要注意：
模型的最大上下文长度是有限的。如果所需信息超出了此范围，模型就无法在单次交互中直接看到它。
基于海量数据的模型预训练有素，但过了截止日期，知识就会被冻结；还缺乏对训练数据之外的任何事件或事实的感知。上下文管理需要提供更新或专门的信息来增强模型的静态知识。
3. 早期的上下文管理方法
- 在MCP等高级协议出现之前，开发人员使用以下基本技术来管理LLM中的上下文：
能会丢失。
截断或滑动窗口：对于多轮对话，一种常见的方法是尽可能多地包含最近的对话/聊天，同时删除较旧的消息或对其进行汇总。可以确保模型能够看到最新的用户查询和一些历史记录，但重要的上下文可
内容摘要：一种策略是将长文档或对话历史记录摘要为模型可以处理的较短形式，将摘要作为上下文提供给模型。虽然这种方法可以捕捉关键点，但它会引入一个额外的层，从而容易出现错误。例如：糟糕的摘要可能会遗漏关键细节，甚至导致错误。此外，动态地为每个潜在的上下文创建良好的摘要也需要相当对的资源。
基于模板的提示：开发人员学会了设计包含结构化赏析问的提示。这个方法确保了模型明确接收所需的数据。然而，检索或生成相关信息部分负担落在了开发人员或自动化流程身上，这对于大型知识源来说可能很复杂。
4. MCP技术出现前
4.1 静态提示（预工具）
最初，使用LLM意味着在提示中提供所有必要的信息并希望它能给出答案。如果模型不知道某些信息，那么它就没有直接的方法来找出答案。
4.2 检索增强生成
在RAG系统中，外部系统（而不是模型本身）进行搜索或数据库查找，然后将结果作为上下文提供给模型。这有助于获取最新信息金额 特定领域知识，但它仍然将模型视为数据的被动消费者，模型本身并没有主动发起这些查询。此外，RAG主要解决知识查找，不允许模型执行操作或使用工具。
4.3 提示链接和代理
一些高级应用程序开始使用代理，其中的模型输出可以被解释为执行操作的命令。这种技术通常被称为ReAct模式或者通过思维链提示的工具使用，它功能强大，但比较临时，相对脆弱。
4.4 函数调用机制
函数调用通过将自然语言意图转换为API调用来弥合语言和代码之间的差距。因为MxN问题并没有让开发者的工作变得容易。
在没有统一协议的情况下，将多个AI模型与多个工具集成需要为每对模型定制连接，这种碎片化不仅给开发人员带来了困难，也限制了AI系统本身的发展。AI Agent也无法轻松地与其他Agent共享工具或上下文，而且添加新功能也很繁琐。
