一文看懂Agentic RAG+MCP ，开启智能检索新时代！

一、RAG基础回顾

RAG工作起来是这样的：用户提个问题，系统就会拿着这个问题去知识库（一般是通过向量数据库里的嵌入技术）找相关信息，找到最匹配的文档后，把这些文档“塞”到模型的提示里，辅助模型给出靠谱的回答。这一招可太妙了，不仅能减少模型“瞎编乱造”的情况，还能在回答里用上特定领域或私人的数据。

不过呢，传统RAG也有自己的“小脾气”。它通常只能查询单一数据源，而且就检索一次。要是一开始搜出来的结果不给力，或者用户问题问得有点“奇葩”，那最终答案的质量就很难保证了。另外，它也没有什么机制能让系统自己琢磨怎么找更有用的信息，遇到复杂情况也不会灵活调用其他工具。

二、Agentic RAG闪亮登场

Agentic RAG就是来解决传统RAG这些痛点的。它在RAG的流程里加了个AI智能体，能像个“指挥官”一样协调检索和生成这两个环节。在Agentic RAG系统里，智能体可以规划多步查询，调用各种工具，还能根据问题和中间结果随时调整策略。简单来说，它打破了传统RAG那种静态单次检索的局限。

这个智能体一般是由大语言模型（LLM）驱动的，

1. 记忆功能：短期记忆负责保存当前对话状态，长期记忆用来记住之前的知识。
2. 规划与推理能力：能决定下一步该采取什么行动，比如重新组织问题、选择合适的数据源。
3. 外部系统工具与接口：像是搜索引擎、数据库、计算器这些，都能成为它的“得力助手” 。

有了这些，智能体就能动态决定要不要检索信息、啥时候检索、用哪个数据源或API。

在Agentic RAG系统里，不同类型的智能体分工明确，各显神通：

1. 路由智能体：它就像是RAG生态系统里的“交通警察”，分析用户的问题，判断哪个知识库或工具最适合，在简单的RAG系统里，它负责挑出最佳数据源去查询信息。
2. 查询规划智能体：这是个“项目经理”角色，把复杂问题拆分成一个个小任务。它先把复杂问题分解成逻辑步骤，再把这些小任务分配给系统里合适的智能体，最后把各个智能体的回答整合起来，形成一个完整的答案。
3. ReAct智能体：ReAct（推理与行动）智能体通过制定逻辑解决方案、为每个步骤挑选合适工具、根据中间结果灵活调整后续步骤，一步步解决问题。这种灵活性让它能根据新信息随时改变策略。
4. 计划执行智能体：它是ReAct智能体的“进化版”，更厉害啦！可以独立完成整个工作流程，不需要时刻盯着；还能通过提高自主性降低运营成本；而且经过全面推理，完成率更高，答案质量也更好。

这些智能体相互配合，让RAG系统变得更智能、更灵敏，回答起问题来又快又准。

三、MCP服务器是什么“神仙”？

随着AI智能体越来越“能干”，能使用的工具也越来越多，新问题就来了：怎么把AI和这些外部数据源、工具稳定又高效地连起来呢？这时候，Model Context Protocol（MCP）就闪亮登场啦！

MCP是个开放标准，专门规范应用程序给LLM提供上下文信息的方式，大家都把它比作 “AI应用的USB-C接口”，有了它，外部数据和服务就能轻松接入。简单来说，MCP定义了AI助手（客户端）和提供数据或功能的外部MCP服务器之间的通信协议。MCP服务器是个轻量级程序，按照这个标准协议，把特定的能力（比如一个数据源或一种工具）开放出来。像有的MCP服务器能让人访问公司的文档库，有的能连接邮箱、日历，还有的能对接数据库，虽然功能不同，但交互规则都是一样的 。

Anthropic在2024年提出了MCP这个概念，它最大的好处就是，以后接入新数据源不用再一个个去做定制化集成了。AI智能体只要按照MCP标准，就能连接任意数量的数据源或工具，再也不用被那些乱七八糟的一次性连接器搞得焦头烂额。

从下面这张图就能很清楚地看出区别：

• 最左边：单独的LLM，它自己“闭门造车”，没办法直接连接外部数据源或应用程序，回答问题只能靠自己训练时学到的那点知识，获取新信息的能力特别有限。
• 中间：LLM搭配多个直接连接的工具。这种情况下，LLM能调用特定的工具或数据源，像向量数据库、定制应用程序或者网络搜索API。不过每个工具都得单独集成，LLM得“记住”怎么和每个工具交流。虽然功能变强了，但每加一个工具，都得单独连一次，太麻烦。
• 最右边：LLM通过MCP服务器连接工具。LLM不再直接和每个工具连接，中间加了个MCP层。LLM把请求发给MCP，MCP再把请求转发到正确的工具上（向量数据库、定制应用、网络搜索等等）。这样一来，LLM获取上下文信息和执行操作的方式都标准化了，添加新工具或者替换现有工具的时候，也不用改LLM的内部逻辑，架构变得简单多了。LLM只需要和MCP建立一个主要连接，其他的集成工作都交给MCP去处理。

MCP服务器还有个厉害的功能，就是给AI智能体提供扩展记忆。LLM的内部上下文窗口有限，长对话或者大量知识库内容它根本“记不住”。这时候MCP服务器就能派上用场了，它可以管理长期上下文数据。比如说，MCP服务器可以连接向量数据库，存储对话历史的嵌入信息或者用户特定信息。智能体可以随时查询这个服务器，获取过去的相关事实，也能把新信息存起来备用。就像开源工具mem0，它能作为代码助手的MCP记忆服务器，把代码片段、配置偏好、文档这些东西存起来，AI之后需要上下文信息的时候就能随时调取。

这种持久可搜索的记忆功能，大大增强了智能体在不同会话中保持上下文连贯性的能力，回答问题也能更个性化。总的来说，MCP服务器实现了双向上下文交换。AI智能体既能获取外部上下文信息（文档、记录、过往对话），也能把信息存到外部存储里，而且整个过程都是在安全、标准的协议下进行的。

四、Agentic RAG与MCP结合的系统架构

要把Agentic RAG和MCP结合起来，得设计一个合理的架构，让AI智能体可以通过MCP服务器获取知识，再把这些知识融入到生成答案的流程里。从宏观上看，这个系统主要包含这么几个部分：

1. 智能体（LLM）：带有规划逻辑，负责解读用户问题，制定获取数据的计划。
2. 一个或多个MCP服务器：提供访问知识库（可能还有工具）的接口。
3. 向量数据库或知识库：存储长期信息，一般通过MCP服务器来访问。
4. MCP客户端接口：把智能体和MCP服务器连接起来。

智能体在这个系统里起着“总指挥”的作用：它先理解用户的问题，判断需要获取哪些数据，然后通过MCP客户端向合适的服务器发送查询请求，收到上下文数据后，把这些数据加到LLM的提示里，最后生成答案。

在单智能体RAG架构里，智能体就像个“路由器”，连接着多个工具。它收到用户问题后，能根据问题的需求，动态选择合适的知识库或工具。比如说，它可以查询向量数据库A或B（每个数据库索引不同的文档集合），调用计算器，或者进行网络搜索。找到的上下文信息会被整合到LLM的输入里，LLM再给出回答。

在这个结合的架构里，MCP服务器就像是智能体的“百宝袋”，每个服务器都封装了特定的数据库或服务。常见的有：

1. 内部知识库服务器：封装公司文档的向量数据库。
2. 网络搜索服务器：让智能体可以进行网络查询。
3. 记忆服务器：用来获取对话上下文或用户个人资料信息。
4. 其他实用服务器：比如计算器API、代码执行工具等等。

MCP客户端在AI智能体（或者宿主应用程序）里运行，和每个MCP服务器保持连接，连接方式可以是基于JSON的远程过程调用（RPC），通过标准输入输出（STDIO），也可以是HTTP/SSE流，这些都符合MCP规范。

智能体的逻辑（可以通过智能体框架实现，也可以利用LLM的函数调用能力）会决定什么时候调用哪个服务器。举个例子，如果用户问 “X地区上一季度和这一季度的销售额对比如何？”，智能体可能会：

1. 意识到需要从公司数据库获取数据。
2. 通过MCP客户端向数据库MCP服务器发送查询请求，服务器在数据库里执行查询，返回结果。

之后，智能体可能会把结果整理成提示内容，或者再调用其他工具进行计算，最后生成答案。所有这些交互都是通过标准化的MCP API调用完成的，对智能体来说，就像是在调用函数或者使用工具。

五、数据流转过程

咱们以一个常见的查询流程为例，看看数据在这个集成系统里是怎么流转的：

1. 用户查询输入：用户提出问题，比如 “生成一份关于未解决支持工单的报告，并包含近期相关的客户反馈”。
2. 智能体规划：智能体分析这个请求（可能会借助一个引导它逐步思考的提示），确定需要从多个数据源获取数据，比如支持工单数据库和客户反馈记录。然后制定计划：先获取相关工单数据，再获取反馈，最后撰写报告。
3. MCP检索操作：按照计划，智能体通过MCP客户端向工单数据库MCP服务器发送请求（服务器可能提供类似 find_tickets(status="open") 的查询接口），服务器在公司工单系统里执行查询，返回一个JSON格式的未解决工单列表。接着，智能体向反馈MCP服务器发送请求（可能是在反馈语料库上进行向量搜索），查询与工单相关的反馈（比如 “近3个月内关于产品X的反馈”），服务器返回相关客户评论片段。
4. 整合上下文：这时智能体拿到了原始数据，也就是未解决工单的详细信息和反馈片段。它把这些数据整合到LLM的上下文里，方式是构建一个提示部分，比如 “以下是相关数据：[工单数据…]; [反馈片段…]。请根据这些信息回答问题…”。如果采用思维链方法，智能体可能会先对数据进行总结或重新格式化。不管用哪种方法，关键是把检索到的上下文信息传递给LLM作为输入。
5. LLM生成答案：LLM（可以是驱动智能体推理的同一个模型，也可以是单独的实例）根据输入生成答案，比如一份结合工单统计和客户情绪的总结报告。智能体把这个答案输出给用户。
6. 可选的知识存储：回答完问题后，智能体可以把一些结果存起来，供以后使用。比如，它可以通过MCP调用把分析结果记录到知识库（更新 “报告” 数据库，或者把总结存到向量记忆里，方便回答后续问题）。这样，如果用户提出后续问题（比如 “你之前提到的上一季度对比情况怎么样？”），智能体就能回忆起之前计算的内容。

在整个过程中，涉及到的API主要有MCP服务器接口（服务器提供的函数或端点，比如搜索查询、创建/读取操作等等）和LLM的API（可能支持函数调用或工具使用集成）。如果使用智能体框架，当智能体选择某个工具时，框架会在底层调用MCP客户端的API。从开发者的角度来看，实现这个架构需要定义MCP请求/响应的模式（通常遵循JSON-RPC模式，比如 SearchRequest、SearchResult 等），还要确保智能体知道如何以及何时调用这些接口。这个架构既支持单智能体设置（一个智能体包办所有事情），也支持多智能体设置（有专门的智能体负责不同任务）。比如说，可以有一个 “研究智能体” 通过MCP处理网络搜索，一个 “数据库智能体” 负责内部数据，由一个主智能体进行协调。实际开发中，一开始可以先采用单智能体搭配多个MCP工具的模式（就像前面提到的架构图那样），随着业务规模扩大，再逐步模块化，拆分成多个智能体（多智能体模式通常是把工具职责分配给不同的智能体进程或LLM）。

六、实现步骤

将智能体RAG系统与MCP服务器集成，需要同时搭建知识检索管道和MCP连接。以下是涵盖数据导入、连接MCP服务器、智能体集成和系统维护的分步指南。

集成智能体RAG系统与MCP服务器

1. 准备知识库和索引：首先收集并预处理AI需要检索的数据，这些数据可以是一组文档、数据库转储文件或任何文本知识。将数据分割成适合向量搜索的大小，并使用嵌入模型对其进行嵌入，以创建向量表示。然后将这些嵌入向量加载到向量数据库（如FAISS、Weaviate、Pinecone）或其他检索系统中。

• 如果有多个不同的数据源（例如产品文档与用户手册），可以为每个数据源创建单独的索引或集合。同时考虑为文档存储哪些元数据（时间戳、类别等），以便日后进行筛选或更有针对性的检索查询。这一步确保你的知识库为语义搜索做好准备。（例如：将公司常见问题解答索引到向量存储中，以便可以根据与用户问题的相似性进行查询。）

2. 设置用于检索的MCP服务器：部署一个与上述知识库对接的MCP服务器。如果你的数据源有官方连接器，可以使用或修改它；否则，可能需要实现一个自定义的MCP服务器。对于向量数据库，MCP服务器将处理诸如“在文档中搜索X”之类的请求。在底层，它将对查询进行嵌入处理，在向量索引中运行相似性搜索，并返回最相关的结果。有许多开源的MCP服务器示例（Anthropic发布了针对谷歌云端硬盘、Slack、SQL数据库等的服务器示例，可以作为模板）。

• 确保你的服务器公布其功能（在MCP术语中，它可能会列出文档的资源特性或搜索工具），以便客户端（智能体）知道有哪些可用的功能。
• 单独测试服务器：例如，通过JSON - RPC客户端或MCP检查工具发送一个示例搜索请求，以验证它是否返回相关文档。如果你需要长期内存存储，还可以设置一个内存MCP服务器（这可以像另一个用于存储过去对话的向量存储，或用于存储个人资料信息的键值存储一样简单）。

3. 配置MCP客户端/宿主环境：将MCP服务器与你的AI智能体环境集成。如果你使用的是Claude桌面应用程序或Cursor等IDE这样的平台，你可以在应用程序的设置中注册新的MCP服务器（例如，在Cursor中，你可以通过指定端点URL和类型，如SSE，来添加MCP服务器）。

• 在代码中，如果你自己实现智能体，可以使用提供的SDK或库实例化一个MCP客户端（Python、TypeScript等都有实现MCP协议握手的SDK ）。
• 客户端将连接到你的MCP服务器（如果服务器在本地运行，通常通过指定端口连接到localhost）并执行初始化握手。一旦连接成功，智能体就可以发现服务器提供哪些方法或资源。例如，服务器可能会列出一个名为“Documents”的资源，该资源支持“search(query)”方法。确保在启动时建立连接，并处理错误（如果无法连接到服务器，智能体应该知道不要调用它）。

4. 在智能体中集成检索调用：现在将检索功能集成到智能体的推理或提示生成过程中。有两种常见的集成模式：

• 手动编排：或者，你可以在大语言模型周围编写自定义逻辑。例如，一个简单的循环，你首先使用用户查询调用向量搜索MCP服务器，获取结果，然后在调用大语言模型获取最终答案之前，构建一个包含这些结果的提示。这是一种简单的RAG方法：Answer = LLM(prompt with retrieved context + question)。在智能体设置中，你可以对此进行迭代：在获得初始答案后，你可以检查答案是否完整，并使用优化后的查询触发另一次检索。

• 在这两种情况下，你都需要在提示中适当地格式化检索到的数据。一种常见的做法是为每个片段添加引用或章节标题，以便大语言模型可以引用它们。例如：“文档1片段：…… 文档2片段：…… 根据以上信息，回答问题：……”。还应该通过系统提示或少量示例指示智能体仅使用检索到的信息以确保准确性。在这个阶段，确保从查询到MCP检索再到LLM回答的端到端流程对于基本查询能够正确工作。

• 使用智能体框架或工具使用范式：如果你的大语言模型支持函数调用（如OpenAI函数调用等），或者你使用的是LangChain这样的框架，你可以将MCP服务器的查询注册为一个工具函数。例如，定义一个函数search_knowledge(query: str) -> str，该函数在内部调用MCP客户端的搜索请求，并将结果作为字符串返回。向大语言模型提供这个工具的描述（例如，“使用search_knowledge从知识库中查找相关文档”）。在运行时，当大语言模型需要信息时，它可以决定调用这个函数。MCP服务器的响应（例如前3个文档片段）将被传回大语言模型，然后大语言模型可以将其整合到答案中。

5. 实现查询扩展或多步检索（智能体循环）：为了充分利用智能体的能力，在需要时让智能体执行多步检索。这可以由大语言模型隐式完成（例如，智能体可以决定多次调用搜索工具）。例如，智能体可能首先检索一般上下文，然后意识到缺少特定细节，并制定后续查询。如果使用框架，这由智能体的推理链处理（大语言模型生成“想法：我应该搜索X”，然后是“行动：search_knowledge”，系统执行该行动，然后是观察等，按照ReAct模式）。

• 确保MCP客户端能够高效处理连续请求（服务器可能在整个会话中保持连接）。你可能需要实现一些简单的逻辑，例如：如果智能体的第一次检索没有产生相关信息，让它重新表述问题或扩大搜索范围。
• 这可能涉及使用大语言模型生成替代关键词，或者使用备用工具（例如，如果内部数据库没有结果，智能体切换到网络搜索MCP服务器）。通过允许这种迭代，系统可以回答更复杂的问题。注意令牌使用情况并设置合理的限制——你可能限制每个用户查询进行2 - 3次检索调用，以避免无限循环。在测试中，尝试需要智能体结合两个来源信息的查询（确保它可以在一次会话中调用两个服务器）。

6. 知识更新和存储：确定随着时间的推移，新的或更新的信息将如何输入到系统中（这对于一致性至关重要）。对于静态文档集，你可以定期简单地重建或更新向量索引。但是，如果数据频繁变化（例如更新的策略文档或数据库中的新工单），可以考虑一个更新MCP服务器后端的管道。例如，如果使用数据库，MCP服务器可以每次查询实时数据（这样它始终是最新的）。

• 如果使用向量存储，你可以在MCP服务器上实现一个更新API —— 例如，一个upsert_document(id, content)方法，该方法重新嵌入并存储新文档。你的智能体甚至可以在对话中调用这个方法来“学习”新信息。此外，使用MCP内存服务器来持久保存对话中的重要信息。例如，在回答一个复杂问题后，智能体可以通过MCP调用将该问答的摘要存储在长期内存中，这样下次它可以回忆起来而无需重新计算。
• 管理知识还意味着建立一个验证和清理知识库的流程——删除过时的信息（也许可以使用元数据时间戳，让智能体优先选择较新的信息）。在这一步结束时，你的RAG系统应该能够持续学习：当业务更新策略时，你将其添加到知识库中（并通过MCP重新索引）；当智能体从用户那里发现新信息时，它会记录下来以备后用。
• 最后，严格测试集成系统。尝试不同复杂度的查询，并验证智能体是否选择了正确的工具并提供了正确的答案。监控MCP调用的延迟和整体往返时间。如果响应似乎很慢，你可以优化计划（例如，如果智能体进行了冗余搜索）。调整提示中包含的检索文档数量（有时使用太多文档会使模型不堪重负——通常3 - 5个好的片段比10个更好）。
• 还要测试边缘情况：如果MCP服务器宕机怎么办？智能体应该优雅地处理错误（也许通过回复“很抱歉，我现在无法访问数据”或尝试其他途径）。一旦满意，将智能体部署到目标环境中，并随着时间的推移监控其性能，随时准备根据新需求修补知识库或添加新的MCP连接器。

优化技术

为了从智能体RAG + MCP设置中获得最佳性能和准确性，可以考虑以下优化方法：

1. 缓存和重用：在多个级别实现缓存。缓存常见检索查询的结果——例如，如果许多用户问“退款政策是什么？”，你可以缓存答案，或者至少缓存检索到的文档，这样智能体就不会重复对相同问题进行向量搜索。如果动态生成查询或文档的嵌入，也可以缓存它们。如果智能体倾向于多次请求相同的资源（例如，从MCP文件服务器请求特定文件），服务器本身可以在内存中缓存该文件的内容。即使是部分缓存也有帮助——例如，在对话中缓存最后N个查询的向量搜索结果，这样如果用户稍微重新表述问题，你可以立即获得上下文。只是要注意，当基础数据更新时，使缓存无效（使用文档ID或时间戳来确定何时刷新）。
2. 向量数据库调优：向量搜索是RAG的核心部分，因此对其进行调优可以提高速度和相关性。尝试不同的嵌入模型——某些模型可能在你的领域中产生更精确的相似性（特定领域的嵌入可以提高检索精度）。调整搜索的相似性阈值或前k个结果：较小的k值将给出更快的结果和更少的无关数据，但太小可能会遗漏某些内容；找到一个最佳平衡点（通常是3 - 5个文档）。如果可用，使用元数据过滤器——例如，如果用户查询包含日期，按日期范围过滤文档，这样你只搜索相关部分，这可以提高速度和质量。如果你的向量数据库支持混合搜索（结合语义和关键词），对于包含罕见关键词的查询，可以考虑启用它（这可以捕获纯嵌入搜索可能忽略的精确匹配）。此外，维护你的索引——定期删除或存档不再需要的内容，以免结果混乱。目标是最大化最相关结果真正解决查询的机会。高检索精度意味着大语言模型需要做的猜测工作更少，可以专注于正确的信息。
3. 提示工程和智能体指令：精心设计引导智能体和大语言模型的提示。一个设计良好的系统提示可以显著改善智能体使用检索到的知识的方式。例如，你可以指示：“如果用户的查询似乎需要外部信息，在回答之前使用知识搜索工具。仅使用检索到的信息回答，如果找不到答案，就说不知道。”这有助于减少幻觉，并确保智能体在适当的时候实际调用MCP工具。提供使用工具的示例：例如，在少量示例提示中，展示一个场景和智能体的思考过程：用户提出一个技术问题 -> 智能体思考：“我应该搜索文档以获取这个API的信息” -> 智能体行动：search_docs(“API方法X的用法”) -> （MCP返回相关片段） -> 智能体在答案中使用它。提示中的这些示例教会模型在集成系统中如何表现。此外，在提示中格式化检索到的上下文时，要清晰地划分它（例如，“上下文：…”），以便模型知道这部分是参考材料。使用特殊令牌或Markdown来区分它。这可以防止模型将上下文文本与用户输入或指令混淆。另一个提示工程技巧是要求模型逐步回答：你可以让智能体首先输出其推理和参考（你捕获但不显示给用户），然后是最终答案。这样，思维链可以被引导以验证它正确使用了信息。最后，考虑指示智能体输出来源或引用检索到的文档（如果这对你的应用程序有用），这可以提高可信度，并且还可以让你仔细检查它使用了哪些来源。
4. 高效的工具使用和备用方案：优化智能体选择和使用工具的方式。如果智能体有多个MCP服务器（数据源）可用，你可以在智能体完全参与之前实现一个快速查询分类器或路由器——例如，根据关键词，决定哪个服务器最可能相关并先查询它（智能体本身也可以进行这种推理，但一个轻量级的启发式方法可以节省时间）。确保MCP服务器本身经过优化（例如，如果一个服务器连接到API，确保API调用高效，或者如果可能的话缓存API响应）。对于计算器或代码执行等工具，尝试批量操作——例如，如果智能体需要计算多个内容，如果工具支持，让它一次性完成。还要有一个故障安全路径：如果由于某种原因智能体在尝试几次后无法检索到所需信息，它应该返回一个得体的答案，而不是一直等待。这可能是一个备用回答，如“很抱歉，我找不到关于那个的信息。”在推理过程中设置截止点可以避免过度使用令牌和长时间延迟。
5. 监控和持续调优：将部署视为一个不断发展的系统。使用监控来查看智能体使用每个MCP服务器的频率、每次调用花费的时间以及成功率（例如，它是否找到了信息还是返回为空）。这可以突出需要进一步优化的地方。例如，如果你注意到对“网络搜索”MCP的查询频繁且缓慢，你可以引入一个小型内部知识库来缓存这些答案，或者升级搜索MCP以使用更快的搜索API。如果智能体很少使用某个工具，也许它的提示描述不清楚或者不需要它——你可以删除或优化它。持续评估答案的质量；如果用户报告问题，追溯查看是检索失误还是大语言模型错误。这个反馈循环将指导提示调整、MCP服务器改进，甚至添加新的数据源以填补空白。

示例代码和配置片段

为了巩固这些概念，以下是一些简化的代码片段，用来说明集成的关键部分。我们假设运行了一个用于知识库的MCP服务器，它公开了一个搜索方法。

初始化MCP客户端和智能体工具

假设我们使用Python和一个智能体框架进行演示。首先，连接到MCP服务器并定义一个智能体可以使用的工具函数：

from mcp import Client
from langchain.agents import Tool, initialize_agent
from langchain.llms import OpenAI

mcp_client = Client(server_url="http://localhost:8080")
mcp_client.initialize()

def search_knowledge(query: str) -> str:
    response = mcp_client.request("search", params={"query": query})
    docs = response.get("results", [])
    return"\n".join(doc["text"] for doc in docs[:3])

search_tool = Tool(
    name="KnowledgeBaseSearch",
    func=search_knowledge,
    description="Searches the knowledge base for relevant documents. Input: a query; Output: relevant snippets."
)

llm = OpenAI(model="o3-mini", temperature=0)
agent = initialize_agent([search_tool], llm, agent="zero-shot-react-description")

在这段代码中，我们创建了一个MCP客户端，并将其搜索调用封装在search_knowledge函数中。然后，我们将其作为一个可用工具提供给智能体。这个智能体（使用ReAct风格的零样本智能体）会在其推理过程中使用“KnowledgeBaseSearch”工具。现在，当我们运行这个智能体时，如果提示或问题表明需要外部信息，它就可以决定调用这个工具。

你可以在https://github.com/langchain-ai/langchain-mcp-adapters获取关于LangChain和MCP的更多信息。

使用智能体通过RAG回答查询

query = "What are the benefits of Agentic RAG over traditional RAG?"
result = agent.run(query)
print(result)

当调用agent.run()时，在内部，大语言模型（LLM）可能会产生类似 “我应该在知识库中搜索智能体RAG的优势” 这样的想法，然后它会调用search_knowledge(query)。MCP客户端将搜索请求发送到服务器，例如从一篇关于智能体RAG优势的文章中检索两个片段并返回。然后智能体获取这些片段并继续大语言模型的推理，最终生成一个包含从检索文本中得出的优势（例如灵活性、适应性、准确性等）的最终答案。以上代码只是一个简单的示例，在实际应用中，你需要处理错误，并且可能会用引用格式来格式化结果。

配置MCP服务器

假设我们正在设置一个简单的文件系统MCP服务器，以允许智能体读取文件（这可用于长期记忆或本地文本文件知识库）。一个配置（以JSON或YAML格式）可能如下所示，用于指定服务器的功能：

{
    "server": "FileExplorer",
    "port": 8090,
    "resources": [
        {
            "name": "Files",
            "description": "Access to local text files",
            "methods": [
                {
                    "name": "read_file",
                    "params": {"path": "string"},
                    "returns": {"content": "string"}
                },
                {
                    "name": "search_files",
                    "params": {"query": "string"},
                    "returns": {"results": "array"}
                }
            ]
        }
    ],
    "permissions": {
        "allowed_paths": "/home/agent/docs/"
    }
}

这个假设的配置声明了一个在8090端口运行的FileExplorer MCP服务器。它有一个名为“Files”的资源，包含两个方法：read_file（用于获取文件内容）和search_files（可能用于在文件中搜索文本）。我们还指定它只能访问特定目录下的文件（这是一种安全措施）。连接到这个服务器的智能体在初始化后就会知道它可以调用这两个方法。例如，如果用户问 “给我看看昨天的错误日志”，智能体可能会通过MCP客户端调用search_files({"query": "2025-11-14 ERROR"})，获取一个文件命中列表，然后对相关的日志文件调用read_file。这个示例展示了如何配置MCP服务器以标准化的方式公开工具。

存储到长期记忆

如果使用向量存储作为记忆，当有新信息要添加时，你可以在代码中直接与之交互。例如：

from embeddings import embed_text

qa_pair = f"Q: {user_question}\nA: {agent_answer}"
vector = embed_text(qa_pair)
memory_db.insert(vector, metadata={"type": "Q&A", "topic": current_topic})

如果记忆是通过MCP公开的，那么上述操作可以是一个MCP服务器调用（例如mcp_client.request("memory_insert", params={...})）。其核心思想是智能体可以随着时间学习。之后，当一个相关问题出现时，智能体的检索步骤可以在记忆数据库中搜索是否已经有类似的问答，并利用它更快或更一致地回答问题。

这些代码片段只是示例，在实际实现中，你需要根据自己特定的库和基础设施进行集成。但它们展示了智能体如何像调用函数一样调用MCP服务器，以及我们如何配置和使用这样的服务器来扩展智能体的能力。

到目前为止，你可以看到，将智能体RAG与MCP服务器相结合，通过为智能体提供所需的知识（通过检索）和对情境的上下文感知（通过记忆和数据集成），显著提高了人工智能的性能。这个人工智能驱动的系统变得更加自主和有用。它可以充当研究员、助手或分析师，不仅能随时获取信息，还能理解何时以及如何应用这些信息。

那么，如何系统的去学习大模型LLM？

作为一名从业五年的资深大模型算法工程师，我经常会收到一些评论和私信，我是小白，学习大模型该从哪里入手呢？我自学没有方向怎么办？这个地方我不会啊。如果你也有类似的经历，一定要继续看下去！这些问题啊，也不是三言两语啊就能讲明白的。

所以我综合了大模型的所有知识点，给大家带来一套全网最全最细的大模型零基础教程。在做这套教程之前呢，我就曾放空大脑，以一个大模型小白的角度去重新解析它，采用基础知识和实战项目相结合的教学方式，历时3个月，终于完成了这样的课程，让你真正体会到什么是每一秒都在疯狂输出知识点。

由于篇幅有限，⚡️ 朋友们如果有需要全套 《2025全新制作的大模型全套资料》，扫码获取~

👉大模型学习指南+路线汇总👈

我们这套大模型资料呢，会从基础篇、进阶篇和项目实战篇等三大方面来讲解。

👉①.基础篇👈

基础篇里面包括了Python快速入门、AI开发环境搭建及提示词工程，带你学习大模型核心原理、prompt使用技巧、Transformer架构和预训练、SFT、RLHF等一些基础概念，用最易懂的方式带你入门大模型。

👉②.进阶篇👈

接下来是进阶篇，你将掌握RAG、Agent、Langchain、大模型微调和私有化部署，学习如何构建外挂知识库并和自己的企业相结合，学习如何使用langchain框架提高开发效率和代码质量、学习如何选择合适的基座模型并进行数据集的收集预处理以及具体的模型微调等等。

👉③.实战篇👈

实战篇会手把手带着大家练习企业级的落地项目（已脱敏），比如RAG医疗问答系统、Agent智能电商客服系统、数字人项目实战、教育行业智能助教等等，从而帮助大家更好的应对大模型时代的挑战。

👉④.福利篇👈

最后呢，会给大家一个小福利，课程视频中的所有素材，有搭建AI开发环境资料包，还有学习计划表，几十上百G素材、电子书和课件等等，只要你能想到的素材，我这里几乎都有。我已经全部上传到CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

相信我，这套大模型系统教程将会是全网最齐全 最易懂的小白专用课！！