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

最新推荐文章于 2025-12-07 19:40:17 发布

原创最新推荐文章于 2025-12-07 19:40:17 发布 · 901 阅读

CC 4.0 BY-SA版权

文章标签：

#人工智能 #LLM #AI大模型 #大模型入门 #agent #智能体 #程序员

最近在做AI智能体客服项目，如何将RAG和MCP更好的结合引起了我的思考，如何发挥出不同技术的优势，利用好RAG和MCP，提升模型检索精准度并满足用户不同需求，使模型能够在解决用户需求时能够更灵活的知道哪些任务需要进行RAG检索，哪些任务需要MCP工具就能完成，因此如何让模型做区分，是在RAG中用MCP还是在MCP中用RAG，谁先谁后，单智能体还是多智能体来处理，本篇文章就是要为以上问题总结出一个答案，如有偏颇请指正。欢迎大家一起来交流。

一、RAG基础回顾

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

传统RAG中也有其自身的缺点。它通常只能查询单一数据源，也就是我们搭建的知识库，而且只能根据用户的要求检索一次。要是一开始搜出来的结果不给力，或者用户问题问得有点“奇葩”，那最终答案的质量就很难保证了。所以我们在做项目的时候，如何提升模型的回答的精准度也是一项重要的任务。另外，它也没有什么机制能让系统自己琢磨怎么找更有用的信息，除了相似度检索外，遇到复杂情况也不会灵活调用其他工具。对复杂的问题处理还是存在一定的局限性，那如何解决这个问题？

二、Agentic RAG闪亮登场

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

这个智能体一般是由大语言模型（LLM）驱动的，具备了以下能力：

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

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

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

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

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

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

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

后面我会出一篇详细介绍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服务器获取知识，再把这些知识融入到生成答案的流程里。从宏观上看，这个系统主要包含这么几个部分：

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

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

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

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

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

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

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

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

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

五、数据流转过程

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

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

在整个过程中，涉及到的API主要有MCP服务器接口（服务器提供的函数或端点，比如搜索查询、创建/读取操作等等）和LLM的API（可能支持函数调用或工具使用集成）。

如果使用智能体框架，当智能体选择某个工具时，框架会在底层调用MCP客户端的API。从开发者的角度来看，实现这个架构需要定义MCP请求/响应的模式（通常遵循JSON-RPC模式，比如 SearchRequest、SearchResult 等）。

还要确保智能体知道如何以及何时调用这些接口。这个架构既支持单智能体设置（一个智能体包办所有事情），也支持多智能体设置（有专门的智能体负责不同任务）。比如说，可以有一个 “研究智能体” 通过MCP处理网络搜索，一个 “数据库智能体” 负责内部数据，由一个主智能体进行协调。实际开发中，一开始可以先采用单智能体搭配多个MCP工具的模式（就像前面提到的架构图那样），随着业务规模扩大，再逐步模块化，拆分成多个智能体（多智能体模式通常是把工具职责分配给不同的智能体进程或LLM）。

六、技术选型

Java技术栈的多智能体实现

Java生态在构建企业级、高可靠性的多智能体应用方面具有优势，特别是在与现有Spring生态系统集成时。

Spring AI Alibaba：这是目前Java生态中构建多智能体应用功
能最丰富的框架之一。
核心特性：提供了Graph多智能体框架（spring-ai-alibaba-graph-core），其设计灵感来源于LangGraph，支持通过图形化方式编排智能体工作流，定义节点（智能体或工具）和状态流转。
智能体协作：内置了多智能体协作架构，例如其DeepResearch示例中就包含了协调者（Coordinator）、研究者（Researcher）、程序员（Coder）、报告者（Reporter）等角色化智能体，它们协同完成深度研究任务。
企业级支持：无缝集成阿里云百炼平台、Nacos（服务发现）、ARMS（监控），提供了良好的可观测性和企业级部署特性。
简易示例：通过AgentHandoff可以配置智能体间的交接。
Spring AI：Spring官方项目，提供了构建AI应用的基础抽象。
定位：更侧重于单一智能体的构建，为其提供模型交互、提示词管理、RAG和工具调用等能力。
多智能体支持：本身不直接提供多智能体编排功能，但可以与LangChain4j集成，或者利用其底层的ChatClient、PromptTemplate等组件自行构建多智能体交互逻辑。
价值：是Spring AI Alibaba的基础，其标准化抽象为Java生态的AI应用开发打下了良好基础。
LangChain4j：是知名Python框架LangChain的Java实现。
功能全面：提供了一系列用于构建基于LLM应用的组件，包括链（Chains）、工具（Tools）、智能体（Agents）、记忆（Memory）等。
多智能体能力：它提供了构建多智能体系统的工具箱，开发者可以利用其抽象手动编排智能体间的协作。社区也有探索性的扩展（如与LangGraph4j结合）。
挑战：其概念和API相对复杂，学习曲线较陡峭。

Java技术栈选型建议：

对于基于Spring Boot的新项目，且希望获得开箱即用的多智能体工作流支持和企业级特性，Spring AI Alibaba是目前的最佳选择。
如果需要高度定制化的多智能体逻辑，且团队技术实力较强，可以基于Spring AI或LangChain4j进行底层构建。
Agents-Flex是一个值得关注的新兴框架，它强调灵活性和可移植性，不绑定特定Web框架，适合需要兼容老旧JDK版本或非Spring项目。

🐍 2. Python技术栈的多智能体实现

Python是AI领域的传统强势语言，拥有极其丰富和成熟的生态系统，在多智能体开发方面框架选择更多样。

DeerFlow：
背景：字节跳动开源的深度研究框架。
核心特性：集成了语言模型、搜索爬虫与代码执行工具，支持自动化完成复杂研究任务并生成多模态报告（文本、PPT、播客）。具备多智能体协作（Coordinator, Planner, Researcher, Coder, Reporter）、强搜索能力、Python数据分析和可视化、报告自动生成等功能。
技术架构：基于LangGraph DAG（有向无环图）组织Agent协作，支持异步执行与并行任务。智能体模块化设计，各司其职。
LangChain / LangGraph：
LangChain：提供了构建AI应用的基本模块，其AgentExecutor是构建单一智能体的核心。多智能体需要在其上自行设计。
LangGraph：专门用于构建有状态、多参与者（智能体）应用的库。它通过图结构明确定义智能体之间的控制流和数据流，是构建复杂多智能体系统的强大工具。许多框架（如DeerFlow）底层都基于或借鉴了LangGraph的思想。
Common Ground：
核心理念：一个开源的多智能体协作平台，强调透明性和人性化管理。其采用了“合伙人-总监-专员”（Partner-Principal-Associate）的层级架构来模拟咨询公司团队的工作模式。
特色：提供了丰富的实时可视化界面（如看板、流程图、时间线），让用户能清晰看到每个智能体的工作状态和中间过程。智能体的行为可以通过YAML文件配置，无需修改代码。