尧图网站建设 
1. 从RAG的“爆火”到“失声”一个技术范式的自然演进最近和几个做AI应用开发的朋友聊天发现一个挺有意思的现象大家讨论的焦点已经从去年铺天盖地的“RAG”检索增强生成技术悄然转向了“AI Agent”和“MCP”模型上下文协议。RAG这个词好像一夜之间就从技术圈的热搜榜上“消失”了。这不禁让我思考是RAG技术本身过时了吗还是说它已经完成了自己的历史使命以一种更高级、更内化的形式融入了新的技术浪潮里要理解这个现象我们得先回到RAG技术爆火的起点。本质上RAG解决的是一个非常具体且核心的痛点大语言模型LLM的“幻觉”问题和知识“保鲜期”问题。一个训练数据截止到2023年初的模型你问它今天的热点新闻它要么胡编乱造要么直接说不知道。RAG的思路很巧妙我不去动你模型本身那几百上千亿的参数成本太高而是给你一个“外挂知识库”。当用户提问时我先从你的私有文档、数据库、最新网页里检索出最相关的几段信息然后把这些信息作为“上下文”和问题一起喂给模型让模型基于这些“新鲜出炉”的素材来组织答案。这样一来答案的准确性和时效性都得到了极大提升。所以RAG在2023年几乎成了企业级AI应用的“标配”。你想做一个智能客服用RAG接入产品手册和工单历史。你想做一个法律助手用RAG接入法典和案例库。它的价值是立竿见影的技术栈也相对清晰向量数据库如Chroma、Milvus、Embedding模型如text-embedding-ada-002、检索器、重排序器再配上LangChain或LlamaIndex这类框架一个原型很快就能搭起来。那时候各种“手把手教你搭建RAG知识库”、“RAG实战避坑指南”的文章满天飞技术社区充满了探索的热情。然而当大家真正把RAG投入到生产环境去解决复杂的、真实的业务问题时它的局限性就开始显现了。RAG就像一个非常优秀的“图书管理员”你问它一个问题它能飞快地从书架上找到几本最相关的书并把相关的段落摘抄给你。但现实世界的问题往往不是“找书”那么简单。比如用户说“帮我分析一下上季度华东区的销售数据对比一下A产品和B产品的表现然后写一份总结报告并建议下季度的推广策略。” 面对这个任务一个纯粹的RAG系统会感到无力。首先它需要理解这是一个包含多个步骤的复杂任务分析数据、对比产品、撰写报告、提出建议。其次它需要“执行”而不仅仅是“检索”。它可能需要调用数据分析工具如SQL查询数据库、调用图表生成工具、调用文档编辑API并在这些步骤之间传递和整合信息。最后它还需要根据中间结果进行判断和决策比如如果A产品销量下滑严重是否要调整建议。这一系列需要规划、工具调用、状态管理和自主决策的能力已经远远超出了传统RAG“检索-增强”的范畴。RAG提供的是“知识”但复杂任务需要的是“行动”。这就是AI Agent登场的背景。2. AI Agent的核心跃迁从“知道”到“做到”AI Agent智能体不是一个全新的概念但在大语言模型能力的加持下它被赋予了全新的内涵。我们可以把AI Agent理解为一个具备一定自主性的“虚拟员工”。它不仅仅能回答问题像ChatGPT也不仅仅能根据资料回答问题像RAG它能够理解一个复杂目标自主地规划步骤调用各种工具API、函数、软件去执行并在执行过程中根据环境反馈进行动态调整直至完成任务。这个“规划-执行-反思”的循环是AI Agent区别于传统对话式AI或RAG系统的核心。我们来看一个具体的对比传统RAG场景用户问“我们公司的年假政策是什么” 系统检索员工手册中“年假”相关段落生成摘要回答。AI Agent场景用户说“我想申请下周五和下下周一共四天年假并同步到我的日历再帮我看看那几天团队有没有重要会议冲突。” Agent需要规划分解任务为a) 验证年假余额b) 提交请假申请c) 查询团队日历d) 在个人日历创建事件。执行调用HR系统API查询用户年假余额并提交申请。调用日历API如Google Calendar查询指定日期团队的会议安排。根据查询结果判断是否有冲突并可能建议调整日期。调用日历API在获批的日期创建“年假”事件。反思如果HR系统返回“余额不足”Agent需要调整计划通知用户并可能建议使用其他假期类型。在这个例子里知识年假政策的获取只是任务中的一个环节可能通过RAG检索手册也可能直接调用HR系统的标准接口。Agent的核心价值在于串联起了多个系统完成了从“信息获取”到“事务处理”的闭环。RAG在这里扮演的角色从一个独立的系统退化为了Agent可以调用的众多“工具”Tools或Skills之一——一个专门用于从非结构化文档中检索信息的工具。这就是为什么“RAG被提及得越来越少”的第一个关键原因它从舞台中央的“主角”变成了AI Agent生态中一个重要的“配角”或“基础能力模块”。当大家讨论如何构建一个能处理报销、写周报、做竞品分析的智能助手时讨论的焦点自然是这个助手的整体架构、规划能力、工具调用框架而“如何接入知识库”只是其众多实现细节中的一个。RAG技术本身并没有消失而是被封装、被集成、被内化了。3. Skill与MCPAI Agent时代的“乐高积木”与“通用接口”随着AI Agent概念的火热两个相关的术语出现的频率越来越高Skill技能和MCPModel Context Protocol模型上下文协议。它们共同构成了AI Agent生态的基石也进一步解释了RAG地位的变化。Skill技能可以理解为Agent能够执行的单个原子能力。比如“发送邮件”是一个Skill“查询数据库”是一个Skill“从Confluence文档中检索信息”也是一个Skill。而后者本质上就是一个RAG Skill。在AI Agent的框架下例如像LangChain的AgentExecutor或是新兴的Hermes Agent、WorkBuddy等框架开发者不再需要从头构建一个庞大的单体应用而是像搭积木一样将一个个预定义或自定义的Skill组合起来赋予Agent解决复杂问题的能力。那么如何让大语言模型作为Agent的“大脑”知道它拥有哪些“积木”Skill并且学会如何调用它们呢这就是MCP模型上下文协议要解决的问题。MCP是由Anthropic等公司推动的一个开放协议它旨在为LLM和各种工具、数据源之间建立一个标准化的通信方式。你可以把MCP想象成电脑的“即插即用”Plug and Play协议。在没有MCP之前每个工具比如一个特定的数据库连接器、一个邮件API的封装都需要为不同的AI框架LangChain, LlamaIndex, AutoGen…编写特定的适配器代码非常繁琐。MCP定义了一套标准的“描述”语言一个工具在MCP中称为Server服务器可以通过MCP协议向LLMClient客户端宣告“嗨我是一个工具我叫‘数据库查询器’我能帮你执行SQL查询这是我的使用说明Schema。” LLM在收到任务时就能根据这些标准的描述知道该在什么时候、以什么格式去调用哪个工具。这对于RAG技术意味着什么意味着一个标准的“文档检索”Skill可以通过MCP协议被任何支持MCP的AI Agent框架所识别和调用。例如你可以部署一个“Tavily网络搜索MCP服务器”或一个“Brave搜索MCP服务器”再部署一个“本地向量数据库MCP服务器”这就是一个标准化的RAG工具。然后在你的Codex或Claude Code项目中你只需要按照MCP的配置步骤将这些服务器的地址添加到Agent的配置文件中你的Agent就立刻拥有了网络搜索和知识库检索的能力。这个过程比之前为每个框架单独集成RAG要标准化和简单得多。所以“搜索类MCP服务器添加进Codex的详细步骤”成为热搜词恰恰反映了社区正在从“如何造轮子构建RAG”转向“如何用标准接口使用轮子集成MCP Skill”。RAG的实现细节被封装在MCP Server背后对Agent开发者变得透明。大家更关心的是如何快速组装一个功能强大的Agent而不是重复实现底层的检索逻辑。RAG技术因此进一步“基础设施化”变成了水管里流淌的水人们更关注的是水龙头Agent和整栋房子的管道设计MCP生态。4. 技术栈的收敛与分化RAG框架的进化与Agent框架的崛起如果我们观察技术社区的热点变化会发现两条清晰的脉络一条是RAG技术栈自身的深化和专业化另一条是AI Agent技术栈的快速崛起和多元化。在RAG领域早期的通用框架如LangChain的RAG模块正在面临更垂直、更极致的解决方案的挑战。大家不再满足于一个“能用”的RAG而是追求“好用”和“精准”。于是我们看到了一系列针对RAG痛点的深度优化检索质量提升单纯的向量相似度搜索容易受到“词汇不匹配”或“语义漂移”的影响。因此重排序Re-Reranking技术变得至关重要。在首轮检索出N个相关文档后使用一个更精细的交叉编码器模型如BGE-Reranker对Top K个结果进行二次打分和排序能显著提升最终送入LLM的上下文质量。这个过程就是让“图书管理员”在找到一堆书后再请一位“专家”快速翻阅一下挑出最切题的那几页。架构专业化出现了像RAGFlow、AnythingLLM这样开箱即用的RAG应用它们提供了美观的UI、多格式文档解析、可视化的检索链路等让非开发者也能快速搭建知识库。同时对于开发者如何完善这些系统的细节如“AnythingLLM咋完善RAG访问”成为新的讨论点比如调整分块策略、优化Embedding模型、接入自定义的重排序器等。与知识图谱结合单纯的向量检索缺乏对实体关系的理解。Ontology RAG本体论RAG或结合知识图谱的RAG尝试将结构化关系与非结构化文本检索结合起来。例如在医疗领域先通过知识图谱定位到“糖尿病”和“并发症”的关系再检索相关的治疗文献使得回答更具逻辑性和深度。这些讨论非常技术化但圈子相对聚焦。与此同时AI Agent的讨论则呈现出“爆炸性”的多元化框架百家争鸣LangChain、LlamaIndex继续演进强化其Agent能力。AutoGen专注于多智能体协作。Hermes Agent、WorkBuddy等新兴框架则更强调生产级部署和与企业工具的集成。还有针对特定场景的框架如Pi Agent可能专注于个人效率。基础设施层凸显像Harness这样的概念被提出它被描述为“一套包裹在AI Agent核心推理逻辑之外的基础设施层”。这意味着什么意味着当你想管理成千上万个Agent的部署、监控、版本迭代、成本核算时你需要一个类似Kubernetes之于容器的管理平台。Harness负责调度、容错、日志、安全而不干涉Agent内部的推理逻辑。这标志着Agent技术开始进入工业化部署的深水区。学习路径成型随着上海交大等机构推出Agent教程“AI Agent学习路线”成为热门搜索。学习路径通常包括LLM基础、提示工程、Function Calling/Tool Calling、Agent核心架构ReAct, Plan-and-Execute、多智能体协作、评估与测试“AI测试Agent层特指什么”、特定框架如LangChain Agent实战。开发工具集成如何“在VS Code里导入AI Agent”成为实际问题开发者希望能在熟悉的IDE里进行Agent的开发和调试。MCP协议的出现也使得像“Chrome DevTools MCP”这样的工具成为可能让Agent能直接与浏览器开发者工具交互进行Web自动化测试或数据抓取。在这个分化中RAG的讨论被归入了“子领域”或“技能实现”而AI Agent的讨论则涵盖了更宏观的架构、生态和商业模式。这自然导致了前者声量的相对下降。5. 未来展望RAG与Agent的共生与融合那么RAG会彻底消失吗当然不会。相反它会以更强大的形态在AI Agent时代发挥更关键的作用。未来的趋势将是深度共生与融合。首先RAG将成为Agent的“长期记忆”和“专业知识库”。一个面向金融领域的Agent不仅需要调用实时行情API工具更需要一个基于海量研报、财报、新闻构建的RAG知识库作为其决策的背景知识。这个知识库是持续更新的为Agent提供深度的行业洞察。这里的RAG可能集成了更复杂的检索链比如先通过关键词搜索缩小范围再用向量检索精确定位最后用重排序模型确保质量。其次Agent将赋予RAG动态性和主动性。传统的RAG是被动的用户问它才检索。而拥有Agent能力的系统可以是主动的。例如一个监测市场风险的Agent可以定期主动检索最新的政策法规和舆情报告利用RAG技能一旦发现与公司业务高度相关且风险较高的信息主动生成预警报告并推送给负责人。RAG在这里成为了Agent感知环境变化的“嗅觉器官”。再者多模态RAG与具身Agent的结合。当前的RAG多以文本为主。但随着多模态大模型的发展RAG可以处理图像、音频、视频甚至传感器数据。一个机器人Agent可以通过视觉RAG识别仓库环境中的物体和标识通过音频RAG理解语音指令的历史上下文。这为物理世界的AI Agent如机器人、自动驾驶提供了强大的环境理解能力。最后从开发者的角度来看未来的工作流可能会是这样当你需要为一个电商公司构建客服Agent时你不再思考“如何做RAG”而是思考“我的Agent需要哪些Skill”。你从Skill市场或公司内部选取一个“产品知识库查询Skill”其背后是优化好的RAG服务、一个“订单查询Skill”调用订单系统API、一个“退货流程引导Skill”可能结合RAG和预定义工作流。通过MCP协议将这些Skill装配到你的Agent框架中。你所关注的是Agent的流程编排、异常处理、用户体验和商业价值。结论是清晰的RAG并非被淘汰而是被升华了。它从一个需要被大肆宣扬和单独实施的“明星技术”沉淀为AI智能体数字躯干中一个强大且必不可少的“器官”——负责知识检索与回忆的“海马体”。技术讨论的热点从“器官如何工作”转移到“如何构建一个完整、智能、能动的生命体Agent”这是一种必然的、健康的技术演进逻辑。对于我们从业者而言理解RAG的原理依然是重要的基础但我们的视野需要扩展到如何利用包括RAG在内的各种“技能”去设计和构建真正能够解决复杂问题、创造价值的智能体系统。这场Agent时代的浪潮才刚刚开始。 从RAG到AI Agent：技术演进、MCP协议与智能体生态构建
1. 从RAG的“爆火”到“失声”一个技术范式的自然演进最近和几个做AI应用开发的朋友聊天发现一个挺有意思的现象大家讨论的焦点已经从去年铺天盖地的“RAG”检索增强生成技术悄然转向了“AI Agent”和“MCP”模型上下文协议。RAG这个词好像一夜之间就从技术圈的热搜榜上“消失”了。这不禁让我思考是RAG技术本身过时了吗还是说它已经完成了自己的历史使命以一种更高级、更内化的形式融入了新的技术浪潮里要理解这个现象我们得先回到RAG技术爆火的起点。本质上RAG解决的是一个非常具体且核心的痛点大语言模型LLM的“幻觉”问题和知识“保鲜期”问题。一个训练数据截止到2023年初的模型你问它今天的热点新闻它要么胡编乱造要么直接说不知道。RAG的思路很巧妙我不去动你模型本身那几百上千亿的参数成本太高而是给你一个“外挂知识库”。当用户提问时我先从你的私有文档、数据库、最新网页里检索出最相关的几段信息然后把这些信息作为“上下文”和问题一起喂给模型让模型基于这些“新鲜出炉”的素材来组织答案。这样一来答案的准确性和时效性都得到了极大提升。所以RAG在2023年几乎成了企业级AI应用的“标配”。你想做一个智能客服用RAG接入产品手册和工单历史。你想做一个法律助手用RAG接入法典和案例库。它的价值是立竿见影的技术栈也相对清晰向量数据库如Chroma、Milvus、Embedding模型如text-embedding-ada-002、检索器、重排序器再配上LangChain或LlamaIndex这类框架一个原型很快就能搭起来。那时候各种“手把手教你搭建RAG知识库”、“RAG实战避坑指南”的文章满天飞技术社区充满了探索的热情。然而当大家真正把RAG投入到生产环境去解决复杂的、真实的业务问题时它的局限性就开始显现了。RAG就像一个非常优秀的“图书管理员”你问它一个问题它能飞快地从书架上找到几本最相关的书并把相关的段落摘抄给你。但现实世界的问题往往不是“找书”那么简单。比如用户说“帮我分析一下上季度华东区的销售数据对比一下A产品和B产品的表现然后写一份总结报告并建议下季度的推广策略。” 面对这个任务一个纯粹的RAG系统会感到无力。首先它需要理解这是一个包含多个步骤的复杂任务分析数据、对比产品、撰写报告、提出建议。其次它需要“执行”而不仅仅是“检索”。它可能需要调用数据分析工具如SQL查询数据库、调用图表生成工具、调用文档编辑API并在这些步骤之间传递和整合信息。最后它还需要根据中间结果进行判断和决策比如如果A产品销量下滑严重是否要调整建议。这一系列需要规划、工具调用、状态管理和自主决策的能力已经远远超出了传统RAG“检索-增强”的范畴。RAG提供的是“知识”但复杂任务需要的是“行动”。这就是AI Agent登场的背景。2. AI Agent的核心跃迁从“知道”到“做到”AI Agent智能体不是一个全新的概念但在大语言模型能力的加持下它被赋予了全新的内涵。我们可以把AI Agent理解为一个具备一定自主性的“虚拟员工”。它不仅仅能回答问题像ChatGPT也不仅仅能根据资料回答问题像RAG它能够理解一个复杂目标自主地规划步骤调用各种工具API、函数、软件去执行并在执行过程中根据环境反馈进行动态调整直至完成任务。这个“规划-执行-反思”的循环是AI Agent区别于传统对话式AI或RAG系统的核心。我们来看一个具体的对比传统RAG场景用户问“我们公司的年假政策是什么” 系统检索员工手册中“年假”相关段落生成摘要回答。AI Agent场景用户说“我想申请下周五和下下周一共四天年假并同步到我的日历再帮我看看那几天团队有没有重要会议冲突。” Agent需要规划分解任务为a) 验证年假余额b) 提交请假申请c) 查询团队日历d) 在个人日历创建事件。执行调用HR系统API查询用户年假余额并提交申请。调用日历API如Google Calendar查询指定日期团队的会议安排。根据查询结果判断是否有冲突并可能建议调整日期。调用日历API在获批的日期创建“年假”事件。反思如果HR系统返回“余额不足”Agent需要调整计划通知用户并可能建议使用其他假期类型。在这个例子里知识年假政策的获取只是任务中的一个环节可能通过RAG检索手册也可能直接调用HR系统的标准接口。Agent的核心价值在于串联起了多个系统完成了从“信息获取”到“事务处理”的闭环。RAG在这里扮演的角色从一个独立的系统退化为了Agent可以调用的众多“工具”Tools或Skills之一——一个专门用于从非结构化文档中检索信息的工具。这就是为什么“RAG被提及得越来越少”的第一个关键原因它从舞台中央的“主角”变成了AI Agent生态中一个重要的“配角”或“基础能力模块”。当大家讨论如何构建一个能处理报销、写周报、做竞品分析的智能助手时讨论的焦点自然是这个助手的整体架构、规划能力、工具调用框架而“如何接入知识库”只是其众多实现细节中的一个。RAG技术本身并没有消失而是被封装、被集成、被内化了。3. Skill与MCPAI Agent时代的“乐高积木”与“通用接口”随着AI Agent概念的火热两个相关的术语出现的频率越来越高Skill技能和MCPModel Context Protocol模型上下文协议。它们共同构成了AI Agent生态的基石也进一步解释了RAG地位的变化。Skill技能可以理解为Agent能够执行的单个原子能力。比如“发送邮件”是一个Skill“查询数据库”是一个Skill“从Confluence文档中检索信息”也是一个Skill。而后者本质上就是一个RAG Skill。在AI Agent的框架下例如像LangChain的AgentExecutor或是新兴的Hermes Agent、WorkBuddy等框架开发者不再需要从头构建一个庞大的单体应用而是像搭积木一样将一个个预定义或自定义的Skill组合起来赋予Agent解决复杂问题的能力。那么如何让大语言模型作为Agent的“大脑”知道它拥有哪些“积木”Skill并且学会如何调用它们呢这就是MCP模型上下文协议要解决的问题。MCP是由Anthropic等公司推动的一个开放协议它旨在为LLM和各种工具、数据源之间建立一个标准化的通信方式。你可以把MCP想象成电脑的“即插即用”Plug and Play协议。在没有MCP之前每个工具比如一个特定的数据库连接器、一个邮件API的封装都需要为不同的AI框架LangChain, LlamaIndex, AutoGen…编写特定的适配器代码非常繁琐。MCP定义了一套标准的“描述”语言一个工具在MCP中称为Server服务器可以通过MCP协议向LLMClient客户端宣告“嗨我是一个工具我叫‘数据库查询器’我能帮你执行SQL查询这是我的使用说明Schema。” LLM在收到任务时就能根据这些标准的描述知道该在什么时候、以什么格式去调用哪个工具。这对于RAG技术意味着什么意味着一个标准的“文档检索”Skill可以通过MCP协议被任何支持MCP的AI Agent框架所识别和调用。例如你可以部署一个“Tavily网络搜索MCP服务器”或一个“Brave搜索MCP服务器”再部署一个“本地向量数据库MCP服务器”这就是一个标准化的RAG工具。然后在你的Codex或Claude Code项目中你只需要按照MCP的配置步骤将这些服务器的地址添加到Agent的配置文件中你的Agent就立刻拥有了网络搜索和知识库检索的能力。这个过程比之前为每个框架单独集成RAG要标准化和简单得多。所以“搜索类MCP服务器添加进Codex的详细步骤”成为热搜词恰恰反映了社区正在从“如何造轮子构建RAG”转向“如何用标准接口使用轮子集成MCP Skill”。RAG的实现细节被封装在MCP Server背后对Agent开发者变得透明。大家更关心的是如何快速组装一个功能强大的Agent而不是重复实现底层的检索逻辑。RAG技术因此进一步“基础设施化”变成了水管里流淌的水人们更关注的是水龙头Agent和整栋房子的管道设计MCP生态。4. 技术栈的收敛与分化RAG框架的进化与Agent框架的崛起如果我们观察技术社区的热点变化会发现两条清晰的脉络一条是RAG技术栈自身的深化和专业化另一条是AI Agent技术栈的快速崛起和多元化。在RAG领域早期的通用框架如LangChain的RAG模块正在面临更垂直、更极致的解决方案的挑战。大家不再满足于一个“能用”的RAG而是追求“好用”和“精准”。于是我们看到了一系列针对RAG痛点的深度优化检索质量提升单纯的向量相似度搜索容易受到“词汇不匹配”或“语义漂移”的影响。因此重排序Re-Reranking技术变得至关重要。在首轮检索出N个相关文档后使用一个更精细的交叉编码器模型如BGE-Reranker对Top K个结果进行二次打分和排序能显著提升最终送入LLM的上下文质量。这个过程就是让“图书管理员”在找到一堆书后再请一位“专家”快速翻阅一下挑出最切题的那几页。架构专业化出现了像RAGFlow、AnythingLLM这样开箱即用的RAG应用它们提供了美观的UI、多格式文档解析、可视化的检索链路等让非开发者也能快速搭建知识库。同时对于开发者如何完善这些系统的细节如“AnythingLLM咋完善RAG访问”成为新的讨论点比如调整分块策略、优化Embedding模型、接入自定义的重排序器等。与知识图谱结合单纯的向量检索缺乏对实体关系的理解。Ontology RAG本体论RAG或结合知识图谱的RAG尝试将结构化关系与非结构化文本检索结合起来。例如在医疗领域先通过知识图谱定位到“糖尿病”和“并发症”的关系再检索相关的治疗文献使得回答更具逻辑性和深度。这些讨论非常技术化但圈子相对聚焦。与此同时AI Agent的讨论则呈现出“爆炸性”的多元化框架百家争鸣LangChain、LlamaIndex继续演进强化其Agent能力。AutoGen专注于多智能体协作。Hermes Agent、WorkBuddy等新兴框架则更强调生产级部署和与企业工具的集成。还有针对特定场景的框架如Pi Agent可能专注于个人效率。基础设施层凸显像Harness这样的概念被提出它被描述为“一套包裹在AI Agent核心推理逻辑之外的基础设施层”。这意味着什么意味着当你想管理成千上万个Agent的部署、监控、版本迭代、成本核算时你需要一个类似Kubernetes之于容器的管理平台。Harness负责调度、容错、日志、安全而不干涉Agent内部的推理逻辑。这标志着Agent技术开始进入工业化部署的深水区。学习路径成型随着上海交大等机构推出Agent教程“AI Agent学习路线”成为热门搜索。学习路径通常包括LLM基础、提示工程、Function Calling/Tool Calling、Agent核心架构ReAct, Plan-and-Execute、多智能体协作、评估与测试“AI测试Agent层特指什么”、特定框架如LangChain Agent实战。开发工具集成如何“在VS Code里导入AI Agent”成为实际问题开发者希望能在熟悉的IDE里进行Agent的开发和调试。MCP协议的出现也使得像“Chrome DevTools MCP”这样的工具成为可能让Agent能直接与浏览器开发者工具交互进行Web自动化测试或数据抓取。在这个分化中RAG的讨论被归入了“子领域”或“技能实现”而AI Agent的讨论则涵盖了更宏观的架构、生态和商业模式。这自然导致了前者声量的相对下降。5. 未来展望RAG与Agent的共生与融合那么RAG会彻底消失吗当然不会。相反它会以更强大的形态在AI Agent时代发挥更关键的作用。未来的趋势将是深度共生与融合。首先RAG将成为Agent的“长期记忆”和“专业知识库”。一个面向金融领域的Agent不仅需要调用实时行情API工具更需要一个基于海量研报、财报、新闻构建的RAG知识库作为其决策的背景知识。这个知识库是持续更新的为Agent提供深度的行业洞察。这里的RAG可能集成了更复杂的检索链比如先通过关键词搜索缩小范围再用向量检索精确定位最后用重排序模型确保质量。其次Agent将赋予RAG动态性和主动性。传统的RAG是被动的用户问它才检索。而拥有Agent能力的系统可以是主动的。例如一个监测市场风险的Agent可以定期主动检索最新的政策法规和舆情报告利用RAG技能一旦发现与公司业务高度相关且风险较高的信息主动生成预警报告并推送给负责人。RAG在这里成为了Agent感知环境变化的“嗅觉器官”。再者多模态RAG与具身Agent的结合。当前的RAG多以文本为主。但随着多模态大模型的发展RAG可以处理图像、音频、视频甚至传感器数据。一个机器人Agent可以通过视觉RAG识别仓库环境中的物体和标识通过音频RAG理解语音指令的历史上下文。这为物理世界的AI Agent如机器人、自动驾驶提供了强大的环境理解能力。最后从开发者的角度来看未来的工作流可能会是这样当你需要为一个电商公司构建客服Agent时你不再思考“如何做RAG”而是思考“我的Agent需要哪些Skill”。你从Skill市场或公司内部选取一个“产品知识库查询Skill”其背后是优化好的RAG服务、一个“订单查询Skill”调用订单系统API、一个“退货流程引导Skill”可能结合RAG和预定义工作流。通过MCP协议将这些Skill装配到你的Agent框架中。你所关注的是Agent的流程编排、异常处理、用户体验和商业价值。结论是清晰的RAG并非被淘汰而是被升华了。它从一个需要被大肆宣扬和单独实施的“明星技术”沉淀为AI智能体数字躯干中一个强大且必不可少的“器官”——负责知识检索与回忆的“海马体”。技术讨论的热点从“器官如何工作”转移到“如何构建一个完整、智能、能动的生命体Agent”这是一种必然的、健康的技术演进逻辑。对于我们从业者而言理解RAG的原理依然是重要的基础但我们的视野需要扩展到如何利用包括RAG在内的各种“技能”去设计和构建真正能够解决复杂问题、创造价值的智能体系统。这场Agent时代的浪潮才刚刚开始。