将Agentic RAG与MCP服务器集成的技术实现指南

检索增强生成（RAG）将大语言模型（LLM）与外部知识检索相结合，使得模型的回答基于最新的实事，而不仅仅依赖其训练数据。

在RAG流程中，用户查询被用来搜索知识库（通常通过向量数据库中的嵌入表示），然后将最相关的文档“增强”到模型的提示中，以帮助生成事实性的回答。

这减少了模型的幻觉现象，并允许在回答中使用特定领域或私有数据。

然而，传统RAG存在局限性：它通常只查询单一数据源，并且仅执行一次检索过程，因此如果初始结果质量不高或查询表述不够明确，回答质量就会受到影响。

系统中没有内置机制来推理如何检索更好的信息，或者在需要时使用额外的工具。

Agentic RAG

Agentic RAG通过在RAG循环中引入AI Agent（智能体）来解决这些不足。在Agentic RAG系统中，检索和生成组件由一个Agent协调，该Agent能够规划多步骤查询、使用各种工具，并根据查询和中间结果调整其策略。换句话说，“Agentic RAG描述了一种基于AI Agent的RAG实现”，超越了静态的单次检索。

该Agent通常由LLM驱动，并增强了以下能力：

1) 记忆（短期记忆用于维持对话状态，长期记忆用于保留先前的知识），

2) 规划/推理能力（用于决定采取什么行动，例如重新表述查询或选择数据源），

3) 与外部系统的工具/接口（例如搜索引擎、数据库、计算器等）。

这些能力使Agent能够动态决定是否需要检索信息、何时检索、选择哪种数据源或API，甚至在生成最终回答前验证或交叉检查信息。

RAG系统中AI Agent的分类

Agentic RAG 系统可能包括：

Routing Agents

路由（Routing）Agent在RAG生态系统中扮演着交通指挥的角色。它们分析用户输入的查询，并决定哪些知识源或工具最为合适。在较简单的RAG实现中，它们会选择最佳的数据源来查询信息。

Query Planning Agents

查询规划Agent如同项目经理，将复杂的查询分解为可管理的子任务。它们会：

• 将复杂问题分解为逻辑步骤

• 将这些子任务委派给系统内的适当Agent

• 将各种响应整合成一个连贯的最终回答

这种多个AI模型的协调代表了一种复杂的AI协作形式。

ReAct Agents

ReAct（Reasoning and Action，推理与行动）Agent通过以下方式创建并实施逐步解决方案：

• 制定逻辑解决方案路径

• 为每个步骤识别有用的工具

• 根据中间结果自适应地修改后续步骤

这种灵活性使它们能够随着新信息的出现调整方法。

Plan-and-Execute Agents

计划与执行Agent是ReAct Agent的进化版本，具有以下能力：

• 在无需持续监督的情况下独立执行完整的工作流程

• 通过更高的自主性降低运营成本

• 通过全面推理所有必要步骤，实现更高的完成率和质量

每种Agent类型都为创建更智能、更具响应性的RAG系统贡献了独特的能力。

主动与数据交互

通过“主动与数据交互”而非仅进行一次检索，Agentic RAG系统能够产生更准确且具有上下文感知的结果。它们可以从多个知识库或API中提取数据（灵活性），适应不同的查询上下文或用户需求（适应性），并迭代优化检索结果以获得更高质量的回答（提升准确性）。

Agent还可以执行多步骤推理——例如，制定更好的搜索查询，或者在第一次尝试不足时进行第二次检索。这意味着，如果用户的问题模糊，Agent可能会将其分解或重新表述以检索有用信息（这种技术称为自查询或查询重构）。此外，Agent还可以加入验证步骤——检查检索到的事实或过滤掉无关片段——以确保只使用可靠信息。

Agentic RAG将一个被动的查找系统转变为“自适应、智能的问题解决”工作流，在这个工作流中，LLM可以主动采取行动并使用工具来获得最佳答案。

MCP服务器简介

随着AI Agent变得更加“智能化”并使用更多工具，一个挑战浮现出来：如何以一致、可扩展的方式将AI连接到所有这些外部数据源和工具。这就是模型上下文协议（Model Context Protocol，MCP）的用武之地。MCP是一个开放标准，规范了应用程序如何为LLM提供上下文。它常被描述为“AI应用的USB-C接口”，为接入外部数据和服务创建了一个通用接口。

更多关于MCP的信息可以参见：

https://modelcontextprotocol.io/introduction

本质上，MCP定义了AI助手（客户端）与提供数据或动作的外部MCP服务器通信的通用协议。MCP服务器是一个轻量级程序，通过这一标准化协议暴露特定功能（数据源或工具）。例如，一个MCP服务器可能提供对公司文档库的访问，另一个可能与电子邮件或日历对接，还有一个可能连接到数据库（都遵循相同的交互规则）。

Anthropic在2024年提出了MCP的概念：

https://www.anthropic.com/news/model-context-protocol

MCP避免了为每个新数据源定制集成的需求。与其使用一堆一次性的连接器，AI Agent可以与任意数量的数据源或工具集成，只要每个数据源或工具提供符合MCP标准的服务器即可。

下图展示了将LLM连接到外部数据或“工具”的三种逐步增强的方式。

从左到右…

• 仅LLM（最左边） LLM单独运行，与外部数据源或应用程序没有直接连接。它只能使用训练时的知识回答问题，因此在更新或检索新信息方面“非常有限”。

• 传统的RAG应用（中间）在这里，LLM可以从特定工具或数据源（如向量数据库、定制应用程序或网络搜索API）获取上下文。每个工具都是单独集成的，因此AI应用必须“知道”如何与每个工具交互。

• 使用MCP服务器的LLM（右边）LLM不再直接连接每个工具，而是在中间加入了一个单一的MCP层。LLM将请求发送到MCP，MCP随后将请求路由到正确的工具（向量数据库、定制应用、网络搜索等）。这标准化了LLM获取上下文或执行操作的方式，使得添加或更换新工具变得更加容易，而无需更改LLM的内部逻辑。它还简化了架构：LLM只需要一个主要连接（到MCP），MCP管理所有其他集成。

这极大地简化了扩展Agent能力的过程。开发者可以“针对标准协议进行一次构建”，然后根据需要混合搭配数据连接器。

MCP服务器负责处理连接数据的细节（文件、数据库、网络API等），并以AI模型可用作上下文的格式呈现这些数据。与此同时，AI（MCP客户端/主机端）无需了解底层细节——它只需发送标准化请求（如“搜索文档X”或“检索项目Y”）并接收结果。这种AI逻辑与数据源细节的解耦使得生态系统更具互操作性和上下文丰富性。

MCP与上下文记忆

MCP服务器的一个强大用途是为AI Agent提供扩展记忆。由于LLM的内部上下文窗口有限，长时间对话或大型知识库无法完全被模型“记住”。MCP服务器可以管理长期上下文数据。例如，一个MCP服务器可能与存储对话历史嵌入或用户特定信息的向量数据库对接。

Agent可以查询此服务器以获取相关的历史事实，或存储新信息以供后续使用。换句话说，MCP服务器可以作为Agent的“大脑扩展”，按需提供记忆或知识。例如，一个面向记忆的MCP服务器可以存储用户偏好、过往交互或领域知识，并在需要上下文时检索它们。作为一个具体例子，开源工具mem0可以作为编码助手的MCP记忆服务器：它存储代码片段、配置偏好和文档，AI可以在需要时提取这些内容作为上下文。

这种持久、可搜索的记忆极大地增强了Agent跨会话保持上下文和个性化响应的能力。总之，MCP服务器支持双向上下文交换。AI Agent既可以获取外部上下文（文档、记录、过往对话），也可以将信息推送到外部存储——这一切都在一个安全、标准化的协议下进行。

结合RAG与MCP的系统架构

要将Agentic RAG与MCP集成，我们需要一个架构，使AI Agent能够通过MCP服务器检索知识并将其融入生成管道。从高层次来看，系统将包括以下组件：带有规划逻辑的Agent（LLM）、一个或多个提供知识源（可能还有工具）的MCP服务器、用于长期信息的向量数据库或知识存储（位于MCP服务器后面），以及将Agent连接到这些服务器的MCP客户端接口。Agent负责协调流程：它解释用户查询，决定检索哪些数据，使用MCP客户端查询适当的服务器，然后获取上下文数据，将其纳入LLM提示中以生成最终答案。

单Agent RAG架构，Agent作为多个工具的“路由器”。Agent接收用户查询，并动态选择适当的知识源或工具：例如，它可以查询向量数据库A或B（每个索引不同的文档集合），或者调用计算器，或执行网络搜索，具体取决于查询需求。检索到的上下文随后被整合到LLM的输入中，LLM生成响应。

在这个组合架构中，MCP服务器本质上是Agent的工具集。每个服务器可能封装特定的数据库或服务。例如，你可能有：

• 内部知识库服务器（封装公司文档的向量数据库），

• 网络搜索服务器（允许Agent分派网络查询），

• 记忆服务器（用于检索对话上下文或用户简介信息），

• 以及其他实用服务器（例如计算器API、代码执行工具等）。

MCP客户端运行在AI Agent的进程（或主机应用程序）中，并与每个服务器保持连接。这可以是通过如MCP规范所定义的STDIO（基于JSON的RPC）或HTTP/SSE流。

Agent的逻辑（可以通过Agent框架或LLM的函数调用能力实现）将决定何时调用MCP服务器。例如，如果用户提出一个问题，如“上季度X地区的销售额与本季度相比如何？”，Agent可能会：

1. 意识到需要从公司数据库中获取数据，

2. 使用MCP客户端向数据库MCP服务器发送查询，服务器随后在数据库上执行查询并返回结果。

然后，Agent可以将该结果格式化到提示中，或者可能通过另一个工具进行计算（例如调用计算器API），然后生成答案。所有这些交互都通过标准化的MCP API调用完成（例如，Agent可能调用服务器上的searchDocuments或getRecord方法），对Agent来说，这些表现为函数调用或工具动作。

数据流

为了说明这个流程，考虑在该集成系统中一个典型的查询往返：

1. 用户查询输入

用户的提问进入Agent（LLM或其包装器）。例如，“生成一份关于开放支票的报告，并包括最近相关的客户反馈。”  

2. Agent规划

Agent分析请求（可能使用鼓励其逐步思考的提示）。它识别出需要从多个来源获取数据：支票数据库和客户反馈记录。它制定计划：首先检索相关票务数据，然后检索反馈，最后撰写报告。  

3. MCP检索操作

根据计划，Agent（通过MCP客户端）向票务数据库MCP服务器发送请求（该服务器可能暴露类似find_tickets(status=”open”)的查询）。服务器在公司的票务系统上执行查询，并返回，例如，一个开放票务的JSON列表。接下来，Agent向反馈MCP服务器发送请求（可能是对反馈语料库的向量搜索），查询与票务相关的内容（Agent可能制定具体的搜索，如“过去3个月关于产品X的反馈”）。该服务器返回相关的客户评论片段。  

4. 整合上下文  

Agent现在拥有原始数据：开放票务详情和反馈片段。它将这些整合到LLM的上下文中。这可以通过构建提示部分实现，例如：“以下是相关数据：[票务数据…]；[反馈摘录…]。使用这些信息回答查询…”如果使用思维链方法，Agent可能还会先总结或重新格式化数据。无论哪种方式，关键是将检索到的上下文传递到LLM的输入中。  

5. LLM生成

LLM（可能是驱动Agent推理的同一模型，或单独的实例）随后生成答案，例如结合票务统计和客户情绪的总结报告。Agent将此输出给用户。  

6. 可选的知识存储

在响应后，Agent可以将一些结果存储起来以供将来重用。例如，它可能通过MCP调用将分析记录到知识库（例如更新“报告”数据库，或将摘要存储到向量记忆中以备后续问题）。这确保如果有后续问题（如“你提到的上季度比较是什么？”），Agent可以回忆之前计算的内容。

在这个过程中，必要的API包括MCP服务器接口（服务器暴露的函数或端点，如搜索查询、创建/读取操作等）和LLM的API（可能支持函数调用或工具使用集成）。如果使用Agent框架，它将在Agent选择工具时在底层调用MCP客户端的API。从开发者的角度来看，实现此架构意味着为你的服务器定义MCP请求/响应的模式（通常遵循JSON-RPC模式，如SearchRequest、SearchResult等），并确保Agent知道如何以及何时调用它们。该架构既支持单Agent设置（一个Agent完成所有工作），也支持多Agent设置（可能有专门的Agent）。例如，你可以有一个“研究Agent”通过MCP处理网络搜索，一个“数据库Agent”处理内部数据，它们都由主Agent协调。实际上，你可能从一个拥有多个MCP工具的单Agent开始（如上图所示），之后如果需要扩展，可以模块化为多个Agent（多Agent情况通常只是将工具职责分配给多个Agent进程或LLM）。

实现步骤

将Agentic RAG系统与MCP服务器集成涉及设置知识检索管道和MCP连接的管道。下面是一个，涵盖数据摄取、连接MCP服务器、Agent集成和维护的分步指南。

1. 准备知识库和索引

首先，收集并预处理AI需要检索的数据。这可能是一组文档、数据库导出文件或任何文本知识。将数据分块成合理大小的片段（适用于向量搜索），并使用嵌入模型生成向量表示。将这些嵌入加载到向量数据库（例如FAISS、Weaviate、Pinecone）或其他检索系统中。如果有多个不同的数据源（例如产品文档与用户手册），可以为每个数据源创建单独的索引或集合。还要考虑与文档一起存储哪些元数据（时间戳、类别），以便后续支持过滤或更精准的检索查询。这一步骤确保你的知识库为语义搜索做好准备。（例如：将公司常见问题索引到向量存储中，以便根据用户问题的相似性进行查询。）

2. 设置MCP服务器以进行检索

部署一个与上述知识库对接的MCP服务器。如果你的数据源已有官方连接器，可以使用或调整它；否则，可能需要实现一个定制的MCP服务器。对于向量数据库，MCP服务器将处理类似“在文档中搜索X”的请求。其内部会将查询嵌入，执行向量索引中的相似性搜索，并返回最相关的结果。现在又许多开源MCP服务器示例可供参考（Anthropic发布了适用于Google Drive、Slack、SQL数据库等的服务器，可以作为模板）。  

4. 公布服务器能力

确保你的服务器公布其能力（用MCP术语来说，它可能列出文档的资源功能或搜索工具），以便客户端（Agent）知道可用功能。  

5. 独立测试服务器

例如，通过JSON-RPC客户端或MCP检查工具发送样本搜索请求，验证其返回相关文档。如果需要长期记忆存储，还要设置一个记忆MCP服务器（这可以是用于过往对话的另一个向量存储，或用于简介信息的键值存储）。

6. 配置MCP客户端/主机环境

将MCP服务器与你的AI Agent环境集成。如果使用像Claude桌面应用或Cursor这样的IDE平台，你需要在应用设置中注册新的MCP服务器（例如，在Cursor中，通过指定端点URL和类型（如SSE）添加MCP服务器）。  

在代码中，如果是你自己实现Agent，可以使用提供的SDK或库（Python、TypeScript等有实现MCP协议握手的SDK）实例化MCP客户端。

客户端将连接到你的MCP服务器（如果是本地运行，通常是localhost上的指定端口），并执行初始化握手。连接建立后，Agent可以发现服务器提供的方法或资源。例如，服务器可能列出一个支持search(query)方法的Documents资源。确保在启动时建立此连接，并处理错误（如果服务器不可达，Agent应知道不调用它）。

现在将检索能力融入Agent的推理或提示生成过程。常见的集成模式有两种：  

• 使用Agent框架或工具使用范式

如果你的LLM支持函数调用（例如OpenAI的函数调用）或使用像LangChain这样的框架，可以将MCP服务器的查询注册为工具函数。例如，定义一个函数search_knowledge(query: str) -> str，内部调用MCP客户端的搜索请求并将结果作为字符串返回。为LLM提供此工具的描述（例如“使用search_knowledge从知识库中查找相关文档”）。在运行时，LLM可以在需要信息时决定调用此函数。MCP服务器的响应（例如前3个文档摘录）将传回给LLM，LLM随后将其融入答案。  

• 手动协调 

或者，你可以围绕LLM编写定制逻辑。例如，一个简单的循环：先用用户查询调用向量搜索MCP服务器，获取结果，然后构建包含这些结果的提示，再调用LLM生成最终答案。这是一个直接的RAG方法：答案 = LLM（包含检索上下文的提示 + 问题）。在Agentic设置中，你可以迭代此过程：获得初步答案后，检查答案是否完整，若不完整则用优化后的查询触发另一次检索。  

无论哪种方式，都需在提示中适当格式化检索数据。常见做法是连同每个片段包含引用或节标题，以便LLM参考。例如：“文档1摘录：… 文档2摘录：… 使用上述信息回答问题：…”还应通过系统提示或少样本示例指导Agent仅使用检索信息以确保准确性。在此阶段，确保端到端流程（查询 -> MCP检索 -> LLM答案）对基本查询正常运行。

实现查询扩展或多步检索（Agentic循环）

要充分发挥Agentic能力，启用Agent在需要时执行多步检索。这可以通过LLM隐式完成（Agent可决定多次调用搜索工具）。例如，Agent可能先检索通用上下文，然后意识到缺少具体细节并制定后续查询。如果使用框架，这由Agent的推理链处理（LLM生成“思考：我应该搜索X”，接着是“动作：search_knowledge”，系统执行后返回观察结果等，符合ReAct模式）。  

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

知识更新与存储

建立新信息或更新信息随时间输入系统的方法（这对一致性至关重要）。对于静态文档集，你可以定期重建或更新向量索引。但如果数据频繁变化（例如更新的政策文档或数据库中的新票务），考虑一个更新MCP服务器后端的管道。例如，如果使用数据库，MCP服务器可以每次查询实时数据（以保持最新）。  

如果使用向量存储，你可以在MCP服务器上实现更新API——例如，方法upsert_document(id, content)重新嵌入并存储新文档。你的Agent甚至可以在对话中调用此方法“学习”新信息。此外，使用MCP记忆服务器持久化对话中的重要片段。例如，在回答复杂问题后，Agent可以将该问答摘要存储到长期记忆中（通过MCP调用），以便下次无需重新计算即可回忆。  

管理知识还意味着设置流程来验证和清理知识库——移除过时信息（可能使用元数据时间戳让Agent优先选择较新信息）。到这一步结束，你的RAG系统应能持续学习：当业务更新政策时，你将其添加到知识库（并通过MCP重新索引）；当Agent从用户那里发现新内容时，它记录下来以备后用。

测试与优化

最后，严格测试集成系统。尝试不同复杂度的查询，验证Agent是否选择正确的工具并提供准确答案。监控MCP调用的延迟和整体往返时间。如果响应缓慢，可以优化计划（例如，如果Agent执行了冗余搜索）。调整提示中包含的检索文档数量（有时使用过多会让模型不堪重负——通常3-5个优质片段比10个更好）。  

还需测试边缘情况：如果MCP服务器宕机怎么办？Agent应优雅处理错误（可能回应“抱歉，我现在无法访问数据”或尝试替代路径）。满意后，将Agent部署到目标环境，并随时间监控其性能，准备修补知识库或根据新需求添加新的MCP连接器。

优化技术

为了从Agentic RAG与MCP设置中获得最佳性能和准确性，可以考虑以下优化措施：

• 缓存与重用

在多个层面实施缓存。缓存常见检索查询的结果——例如，如果许多用户询问“退款政策是什么？”，你可以缓存答案或至少缓存检索到的文档，这样Agent就不必重复对相同问题进行向量搜索。如果查询或文档的嵌入是即时生成的，也可以缓存这些嵌入。如果Agent倾向于多次请求同一资源（例如MCP文件服务器中的特定文件），服务器本身可以将该文件内容缓存在内存中。即使是部分缓存也有帮助——例如，在对话中缓存最近N个查询的向量搜索结果，这样如果用户稍微改述问题，你就能立即获得上下文。只是要注意在底层数据更新时使缓存失效（使用文档ID或时间戳来判断何时刷新）。

• 向量数据库调优

向量搜索是RAG的核心部分，调优它可以提升速度和相关性。实验不同的嵌入模型——某些模型可能为你的领域提供更精确的相似性（特定领域的嵌入可以提高检索精度）。调整搜索的相似性阈值或top-k值：较小的k值会带来更快的结果和更少无关数据，但太小可能遗漏内容；找到一个平衡点（通常是3-5个文档）。如果可用，使用元数据过滤器——例如，如果用户查询包含日期，按日期范围过滤文档，只搜索相关部分，这会同时提升速度和质量。如果你的向量数据库支持混合搜索（结合语义和关键词），可以为包含稀有关键词的查询启用它（这能捕获纯嵌入搜索可能忽略的精确匹配）。还要维护索引——定期移除或归档不再需要的内容，以免干扰结果。目标是最大化顶部结果真正解决查询的可能性。高精度的检索意味着LLM需要更少的猜测，能专注于正确的信息。

• 提示工程与Agent指令

谨慎设计引导Agent和LLM的提示。一个精心设计的系统提示可以显著提升Agent使用检索知识的方式。例如，你可以指示：“如果用户查询似乎需要外部信息，在回答前使用知识搜索工具。只使用检索到的信息回答，如果找不到答案，就说不知道。”这有助于减少幻觉，并确保Agent在适当时候调用MCP工具。提供使用工具的示例：例如，在少样本提示中展示一个场景和Agent的思考过程：用户提出技术问题 -> Agent思考：“我应该搜索这个API的文档” -> Agent动作：search_docs(“API方法X的使用”) ->（MCP返回相关片段）-> Agent在答案中使用它。提示中的这类示例能教会模型在集成系统中如何行为。此外，在提示中格式化检索上下文时，清晰地划分它（例如“上下文：…”），让模型知道那是参考材料。使用特殊标记或Markdown区分它，避免模型将上下文文本与用户输入或指令混淆。另一个提示工程技巧是要求模型逐步回答：你可以让Agent先输出其推理和参考（你捕获但不展示给用户），然后给出最终答案。这样，思维链可以被引导验证是否正确使用了信息。最后，考虑指示Agent输出来源或引用检索到的文档（如果对你的应用有用），这能提升信任度，也让你能复查它使用了哪些来源。

• 高效工具使用与回退

优化Agent选择和使用工具的方式。如果Agent有多个MCP服务器（数据源）可用，可以在Agent完全参与前实现一个快速查询分类器或路由器——例如，根据关键词决定哪个服务器最可能相关并优先查询它（Agent本身也可以进行这种推理，但轻量级启发式能节省时间）。确保MCP服务器本身经过优化（例如，如果服务器连接到API，确保API调用高效，或尽可能缓存API响应）。对于计算器或代码执行等工具，尽量批量操作——例如，如果Agent需要计算多件事，若工具支持，可以一次性完成。还要有失败安全路径：如果Agent在几次尝试后无法检索所需信息，应返回优雅的回答而非卡住。这可能是一个回退，如“抱歉，我找不到相关信息。”在推理过程中设置截止点，避免过多token使用和长时间延迟。

• 监控与持续调优

将部署视为一个不断演进的系统。使用监控查看Agent使用每个MCP服务器的频率、每次调用的时长以及成功率（例如，是否找到内容或空手而归）。这能突出进一步优化的方向。例如，如果注意到对“网络搜索”MCP的查询频繁且缓慢，可以引入一个小型内部知识库缓存这些答案，或升级搜索MCP使用更快的搜索API。如果Agent很少使用某个工具，可能是其提示描述不清晰或不必要——你可以移除或改进它。持续评估答案质量；如果用户报告问题，回溯查看是检索失误还是LLM错误。这一反馈循环将指导提示调整、MCP服务器改进，甚至添加新数据源填补空白。

示例代码与配置片段

为了巩固概念，以下是一些简化的代码片段，展示集成的关键部分。我们假设有一个为知识库运行的MCP服务器，暴露了一个搜索方法。

初始化MCP客户端和Agent工具

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

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

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

使用Agent回答带有RAG的查询

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

配置MCP服务器

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

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

注意安全性！不要给予不必要的文件访问权限！ 

存储到长期记忆

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

如果记忆通过MCP暴露，上述操作可以改为MCP服务器调用（例如mcp_client.request(“memory_insert”, params={…})）。目的是让Agent随时间学习。后来，当相关问题出现时，Agent的检索步骤可以搜索记忆数据库，看看是否已做过类似的问答，并利用它更快或更一致地回答。

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

至此，你可以看到，结合Agentic RAG与MCP服务器显著提升了AI性能，通过检索为Agent提供所需知识，并通过记忆和数据集成赋予其情境意识。这个AI驱动的系统变得更自主和实用。它可以作为研究员、助手或分析师，不仅信息触手可及，还理解何时以及如何应用这些信息。

https://becomingahacker.org/integrating-agentic-rag-with-mcp-servers-technical-implementation-guide-1aba8fd4e442

（文：PyTorch研习社）