APPLICATION

Agentic RAG与MCP集成指南

为了将Agentic RAG与MCP集成，我们需要一种架构，使AI代理能够通过MCP服务器检索知识并将其纳入生成管道中。

admin

• 36 min read
Agentic RAG与MCP集成指南

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

RAG（高层次）

在RAG管道中，用户查询用于搜索知识库（通常通过向量数据库中的嵌入），并提取最相关的文档，然后将其“增强”到模型的提示中以帮助生成一个基于事实的答案。

这减少了幻觉，并允许使用领域特定或私有数据来生成响应。

然而，传统的RAG存在局限性：它通常只查询单一数据源，并且只执行一次检索，因此如果初始结果不佳或查询措辞不当，答案就会受到影响。

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

1、基于代理的RAG

基于代理的RAG通过在RAG循环中引入AI代理解决了这些差距。 在基于代理的RAG系统中，检索和生成组件由智能代理协调，该代理可以计划多步查询，使用各种工具，并根据查询和中间结果调整其策略。 换句话说，“基于代理的RAG描述了一种基于AI代理实现的RAG”，它超越了静态的一次性检索。

代理通常由LLM提供动力，并增强以下功能：1）记忆（短期记忆用于保持对话状态，长期记忆用于记住先前的知识），2）规划/推理能力（决定采取哪些行动，例如重新制定查询或选择数据源），以及3）工具/接口到外部系统（如搜索引擎、数据库、计算器等）。

这些功能使代理能够动态决定是否以及何时检索信息，使用哪个来源或API，甚至在最终答案生成之前验证或交叉检查信息。

🔥 Weaviate有一个关于基于代理的RAG的精彩解释。

来源：https://weaviate.io/blog/what-is-agentic-rag

2、RAG系统中AI代理的分类

基于代理的RAG系统可能包括：

2.1 路由代理

这些代理在RAG生态系统中充当交通指挥员。 它们分析传入的用户查询并确定哪个知识源或工具最为合适。 在较简单的RAG实现中，它们会选择最佳的数据源来查询信息。

2.2 查询规划代理

作为项目经理，这些代理将复杂的查询分解为可管理的小任务。 它们：

  • 将复杂的问题分解为逻辑步骤
  • 将这些子任务委派给系统内的适当代理
  • 编译各种响应以形成连贯的最终答案

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

2.3 ReAct代理

ReAct（推理和行动）代理通过以下方式创建和实施逐步解决方案：

  • 制定逻辑解决方案路径
  • 确定每一步骤所需的有用工具
  • 根据中间结果灵活修改后续步骤

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

2.4 计划和执行代理

这些代理代表了ReAct代理的演变，具有独立执行完整工作流的能力，而无需持续监督。 它们通过提高自主性来降低运营成本，并通过全面推理所有必要步骤来实现更高的完成率和质量。

每种代理类型都为创建更智能、响应更快的RAG系统贡献了独特的功能。

3、积极参与数据

通过“积极参与”数据而不是仅仅检索一次，基于代理的RAG系统可以产生更准确和上下文感知的结果。 它们可以从多个知识库或API中提取数据（灵活性），适应不同的查询上下文或用户需求（适应性），并通过迭代优化检索结果来提高答案的质量（改进准确性）。

代理还可以执行多步推理——例如，制定更好的搜索查询或在第一次尝试不够充分时进行第二次检索。

这意味着，如果用户的提问模糊不清，代理可能会将其分解或重新表述以检索有用的信息（一种称为自查询或查询重写的技术）。 此外，代理还可以包含一个验证步骤——检查检索到的事实或过滤无关片段——以确保仅使用可靠的信息。

基于代理的RAG将被动查找系统转变为一种“适应性的、智能的问题解决”管道，在这里LLM可以主动采取行动并使用工具获取最佳答案。

4、Model Context Protocol（MCP）服务器简介

随着AI代理变得更加“主动”和工具使用，一个问题出现了：如何以一致且可扩展的方式将AI连接到所有这些外部数据源和工具。 这就是Model Context Protocol（MCP）的用武之地。 MCP是一个开放标准，它标准化了应用程序如何向LLMs提供上下文。 它常被描述为“AI应用的USB-C端口”，创建了一个通用接口以插入外部数据和服务。 参见这里。

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

Anthropic早在2024年就引入了MCP的概念。

MCP避免了为每个新数据源进行定制集成的需求。 不再是杂乱无章的一次性连接器，只要每个数据源或工具提供符合MCP标准的服务器，AI代理就可以集成任意数量的数据源或工具。

下图展示了大型语言模型（LLM）连接到外部数据或“工具”的三种逐步更强大的方式。

从左到右……单独的LLM（最左边）。 LLM孤立运行，没有直接连接到外部数据源或应用程序。 它只能回答基于其训练数据的知识，因此在更新或检索新信息方面非常有限。

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

使用Model Context Protocol（MCP）服务器的LLM（最右边）。 不是LLM直接连接到每个工具，而是有一个单独的MCP层在两者之间。 LLM发送请求到MCP，然后MCP路由请求到正确的工具（向量DB、自定义应用、网络搜索等）。 这一标准化使LLM获得上下文或执行操作变得更容易，而无需更改LLM内部逻辑即可添加或替换新工具。 这也简化了架构：LLM只有一个主要连接（到MCP），而MCP管理所有其他集成。

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

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

5、MCP与上下文记忆

MCP服务器的一个强大用途是为AI代理提供扩展记忆。 因为LLMs的内部上下文窗口有限，长对话或大型知识库不能完全由模型自身“记住”。CP服务器可以管理长期上下文数据。例如，MCP服务器可能与一个向量数据库接口，该数据库存储会话历史记录嵌入或用户特定信息。

代理可以通过查询此服务器来获取相关的过去事实或存储新的信息以备后用。换句话说，MCP服务器可以充当代理的 “脑部扩展”，根据需要为其提供记忆或知识。例如，一个以记忆为导向的MCP服务器可以存储用户的偏好、过去的交互或领域知识，并在需要时检索它们。具体来说，开源的mem0工具可以作为编码助手的MCP内存服务器：它存储代码片段、配置偏好和文档等内容，AI可以在以后的上下文中提取这些内容。

这种持久且可搜索的记忆极大地增强了代理在多个会话中保持上下文的能力，并使其能够个性化响应。总之，MCP服务器实现了双向上下文交换。AI代理不仅可以获取外部上下文（文档、记录、过去的对话），还可以将信息推送到外部存储中——在安全、标准化协议下进行。

6、结合RAG和MCP的系统架构

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

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

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

  • 一个内部知识库服务器（封装公司文件的向量数据库），
  • 一个网络搜索服务器（允许代理分发网络查询），
  • 一个记忆服务器（用于检索对话上下文或用户资料信息），
  • 可能还有其他实用服务器（例如，计算器API、代码执行工具等）。

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

代理的逻辑（可以通过代理框架实现，也可以通过LLM的功能调用能力实现）将决定何时调用服务器。例如，如果用户询问类似“上个季度X地区的销售额与本季度相比如何？”的问题，代理可能会：

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

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

代理可以将该结果格式化为提示的一部分，或者可能先进行计算（也许通过另一个工具），然后再生成答案。所有这些交互都通过标准的MCP API调用发生（例如，代理可能会在服务器上调用searchDocuments或getRecord方法），这些在代理看来就像是函数调用或工具操作。

数据流

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

  1. 用户查询摄入——用户的问题进入代理（LLM或其包装器）。例如，“生成一份关于开放支持工单的报告，并包括任何最近相关的客户反馈。”
  2. 代理规划——代理分析请求（可能通过一个鼓励逐步思考的提示）。它识别出需要从多个来源获取数据：支持工单数据库和客户反馈记录。它制定了计划：首先检索相关工单数据，然后检索反馈，最后编写报告。
  3. MCP检索操作——按照计划，代理（通过MCP客户端）向工单数据库MCP服务器发送请求（可能暴露一个像find_tickets(status="open")的查询）。服务器在其公司的工单系统上执行查询并返回，比如一个开放工单的JSON列表。接下来，代理向反馈MCP服务器发送请求（可能是对反馈语料库的向量搜索），查询与工单相关的数据（代理可能会制定一个具体的搜索，如“过去三个月关于产品X的反馈”）。该服务器返回相关的客户评论片段。
  4. 整合上下文——代理现在有了原始数据：开放工单详情和反馈片段。它将这些数据整合到LLM的上下文中。这可以通过构建提示部分来完成，例如：“以下是相关数据：[工单数据...]；[反馈摘录...]。利用这些信息，回答查询...”。如果使用链式思维方法，代理可能会先总结或重新格式化数据。无论哪种方式，关键是检索到的上下文被传递给LLM的输入。
  5. LLM生成——LLM（可能是驱动代理推理的相同模型，也可能是单独的实例）然后生成答案，例如结合工单统计数据和客户情绪的汇总报告。代理将此输出给用户。
  6. 可选的知识存储——在回应之后，代理可以存储一些结果以供将来重用。例如，它可能会通过MCP调用记录分析（例如更新“报告”数据库，或将摘要存储在向量内存中以备下次提问）。这样确保如果出现后续问题（如“你之前提到的上个季度的对比如何？”），代理可以回忆起之前计算的内容。

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

7、实施步骤

将具有代理功能的RAG系统与MCP服务器集成涉及设置知识检索管道和MCP连接的基础设施。以下是涵盖数据摄取、连接MCP服务器、代理集成和维护的分步指南。

将具有代理功能的RAG系统与MCP服务器集成
  1. 准备知识库和索引。首先收集并预处理AI需要检索的数据。这可能是一组文档、数据库转储或任何文本知识。将数据分割成合理大小的块（用于向量搜索），并使用嵌入模型生成向量表示。将这些嵌入加载到向量数据库（例如FAISS、Weaviate、Pinecone）或其他检索系统中。
  2. 如果你有多个不同的数据源（例如产品文档与用户手册），可能需要为每个数据源创建单独的索引或集合。还要考虑存储文档的元数据（时间戳、类别），以便稍后启用过滤或更有针对性的检索查询。此步骤确保您的知识库准备好进行语义搜索。（示例：将公司常见问题解答索引到向量存储中，以便用户的问题可以按相似性查询。）
  3. 设置MCP服务器以进行检索。部署一个MCP服务器，使其与上述知识库接口。如果存在官方连接器，请使用或改编它；否则，你可能需要实现自定义MCP服务器。对于向量数据库，MCP服务器将处理类似“在文档中搜索X”的请求。在幕后，它将执行查询的嵌入，运行向量索引中的相似度搜索，并返回顶部结果。许多开源MCP服务器示例可用（Anthropic发布了针对Google Drive、Slack、SQL数据库等的服务器，可以作为模板）。
  4. 确保你的服务器公开其功能（在MCP术语中，它可能会列出资源功能用于文档或工具用于搜索），以便客户端（代理）知道有哪些功能可用。可用性​
  5. 独立测试服务器：例如，通过JSON-RPC客户端或MCP检查工具发送样本搜索请求，以验证其是否返回相关文档。如果需要长期记忆存储，请同时设置Memory MCP服务器（这可能只是一个用于过去对话的向量存储库，或者一个用于配置文件信息的关键值存储）。
  6. 配置MCP客户端/主机环境。将MCP服务器与您的AI代理环境集成。如果您使用的是Claude桌面应用程序或Cursor等IDE，您需要在应用程序的设置中注册新的MCP服务器（例如，在Cursor中，您可以通过指定其端点URL和类型，如SSE来添加MCP服务器）。

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

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

在代理中集成检索调用。现在将检索能力整合到代理的推理或提示生成过程中。有两种常见的集成模式：

  • 使用代理框架或工具使用范式： 如果您的LLM支持函数调用（OpenAI函数调用等）或您正在使用LangChain等框架，您可以将MCP服务器的查询注册为工具函数。例如，定义一个函数search_knowledge(query: str) -> str，该函数内部调用MCP客户端的搜索请求并将结果作为字符串返回。向LLM提供此工具的描述（例如，“使用search_knowledge从知识库中查找相关信息”）。在运行时，LLM可以在需要信息时决定调用此函数。MCP服务器的响应（例如，前3个文档摘录）将传递回LLM，然后它可以将其纳入其答案中。
  • 手动编排： 或者，您可以围绕LLM编写自定义逻辑。例如，一个简单的循环，首先使用用户查询调用向量搜索MCP服务器，获取结果，然后构造一个包含这些结果的提示，最后调用LLM以获得最终答案。这是一种直接的RAG方法：答案 = LLM（带有检索上下文+问题的提示）。在代理设置中，您可能会迭代此过程：在获得初始答案后，您可以检查答案是否看起来不完整，并触发带有精炼查询的另一次检索。

无论哪种情况，您都需要在提示中适当地格式化检索数据。一种常见做法是包括引用或章节标题与每个片段一起，以便LLM可以引用它们。例如：“文档1摘录：... 文档2摘录：... 使用上述信息，回答问题：...”。代理还应通过系统提示或少量示例指导其仅使用检索的信息以确保准确性。在此阶段，确保端到端查询 -> MCP检索 -> LLM答案流程对基本查询正确工作。

8、实现查询扩展或多步检索（代理循环）

为了充分利用代理能力，当需要时启用代理执行多步检索。这可以通过LLM隐式完成（代理可以决定，例如，多次调用搜索工具）。例如，代理可能会首先检索一般上下文，然后意识到缺少特定细节并制定后续查询。如果使用框架，这是由代理的推理链处理的（LLM生成“我想搜索X”的想法，接着是“操作：search_knowledge”，系统执行此操作，然后观察等，按ReAct模式进行）。

确保MCP客户端能够高效地处理连续请求（服务器在整个会话期间可能保持连接）。您可能需要实现一些简单逻辑，例如：如果代理的第一个检索没有相关的信息，让它重新表述问题或扩大搜索范围。

这可能涉及使用LLM生成替代关键词或使用备用工具（例如，如果内部数据库没有结果，代理切换到网络搜索MCP服务器）。通过允许这种迭代，系统可以回答更难的问题。密切关注令牌使用并设置合理的限制——您可能限制每个用户查询最多2-3次检索调用来避免无限循环。在测试中，尝试需要代理结合两个来源信息的查询（确保它可以在一次会话中调用两个服务器）。

9、知识更新和存储

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

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

管理知识还意味着建立一个过程来验证和清理知识库——删除过时的信息（并可能具有元数据时间戳，以便代理优先选择较新的信息）。通过这一步骤，您的RAG系统应该能够持续学习：当业务更新政策时，您将其添加到知识库（并通过MCP重新索引）；当代理从用户那里发现新信息时，它会记录下来供以后使用。

最后，严格测试集成系统。尝试各种复杂程度的查询，并验证代理是否选择了正确的工具并提供了正确的答案。监控MCP调用的延迟和整体往返时间。如果响应似乎很慢，您可能需要优化计划（例如，如果代理进行了重复搜索）。调整包含在提示中的检索文档数量（有时使用太多会压倒模型——通常3-5个好的片段比10个更好）。

还要测试边缘情况：如果MCP服务器宕机怎么办？

代理应优雅地处理错误（也许通过回应“对不起，我现在无法访问数据”或尝试另一种途径）。满意后，在目标环境中部署代理，并随着时间的推移监控其性能，随时准备修补知识库或添加新的MCP连接器以满足新需求。

10、优化技术

为了从代理RAG + MCP设置中获得最佳性能和准确性，请考虑以下优化：

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

11、示例代码和配置片段

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

11.1 初始化MCP客户端和代理工具

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

from mcp import Client  # 假设的MCP客户端库  
from langchain.agents import Tool, initialize_agent  
from langchain.llms import OpenAI  

# 连接到MCP服务器（例如，运行在localhost:8080上，通过HTTP进行JSON-RPC）  
mcp_client = Client(server_url="http://localhost:8080")    
mcp_client.initialize()  # 执行MCP握手  
# 定义一个检索函数，调用MCP服务器的search  
def search_knowledge(query: str) -> str:  
    response = mcp_client.request("search", params={"query": query})  
    # 假设MCP服务器返回一个包含'text'片段的字典  
    docs = response.get("results", [])  
    # 将前几个文档合并为单个字符串（为安全起见截断）  
    return "\n".join(doc["text"] for doc in docs[:3])  
# 创建一个工具供代理使用  
search_tool = Tool(  
    name="KnowledgeBaseSearch",   
    func=search_knowledge,   
    description="搜索知识库以获取相关信息。输入：查询；输出：相关片段。"  
)  
# 初始化语言模型和代理  
llm = OpenAI(model="o3-mini", temperature=0)  # 或任何LLM  
agent = initialize_agent([search_tool], llm, agent="zero-shot-react-description")

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

✨ 📚 你可以从这里获得更多关于LangChain和MCP的信息。

11.2 使用代理回答查询

query = "什么是Agentic RAG相对于传统RAG的优势？"  
result = agent.run(query)  
print(result)

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

11.3 配置MCP服务器

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

{  
  "server": "FileExplorer",  
  "port": 8090,  
  "resources": [  
    {  
      "name": "Files",  
      "description": "访问本地文本文件",  
      "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服务器以标准化方式暴露工具。

注意安全性！不要授予不必要的文件访问权限！现在，你看到了我的免责声明……让我们来看看如何存储到长期记忆中。

11.4 存储到长期记忆

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

# 在回答问题后，将问答对存储在向量内存中以备将来参考  
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服务器，以及我们如何配置和使用此类服务器来扩展代理的能力。

到现在为止，你可以看到结合Agentic RAG与MCP服务器显著增强了AI性能，使代理不仅拥有所需的全部知识（通过检索），而且具有情境意识（通过记忆和数据集成）。AI驱动的系统变得更加自主和有用。它可以作为一个研究人员、助手或分析师，不仅掌握信息，而且了解何时以及如何应用这些信息。

原文链接：Integrating Agentic RAG with MCP Servers: Technical Implementation Guide

汇智网翻译整理，转载请标明出处