★ FEATURED ARTICLE 1. 先搞清楚这三个词分别解决什么问题MCP、RAG、Agent这三个词最近在AI应用开发圈子里出现的频率高得吓人。我隔三差五就会被人问到同一个问题这三个东西到底什么关系是不是同一种技术的不同叫法先说结论它们不是同一个维度的事物完全不冲突但确实经常被放在一起讨论因为在一个完整的AI应用里它们往往同时出现、互相配合。用一句话给它们定位RAG管的是“知识怎么进模型”解决模型不知道、记不住的问题MCP管的是“模型怎么够到外部系统”解决模型动不了手、连不上的问题Agent管的是“任务怎么被拆解和执行”解决模型只会聊天、不会干活的问题。我见过不少人一上来就想装一套RAG系统折腾了半个月发现召回质量一塌糊涂再去学Agent又发现模型根本调不了外部工具——其实从一开始就应该先把这三者的边界和关系理清后面每一步才走得顺。这篇文章我尽量不堆术语用实际开发场景来讲清楚每一块是什么、怎么落地、踩过什么坑。如果你是刚接触AI应用开发的技术人或者正准备给业务系统接大模型能力这篇应该能帮你省下不少弯路。2. RAG先让模型“翻书”再回答2.1 RAG解决的问题模型不会魔法它只靠记忆大模型的知识全部冻结在训练完成的那一刻。你今天问它今年的新鲜事它答不上来不是因为它笨而是因为它的“记忆”里根本没有这部分内容。这就好比让一个博览群书的学者做闭卷考试题目超出他读过的书他只能靠推理硬编编错了也正常。RAGRetrieval-Augmented Generation检索增强生成的思路很直接既然闭卷答不好那就开卷。在模型回答之前先从外部知识库里检索出和问题相关的内容把找到的内容拼进提示词一起送给模型让模型基于这些材料来回答。道理听起来简单真正落地过的人都知道里面全是细节活。我见过很多团队的第一版RAG就是三步走把文档切碎、向量化、存进向量库然后用户提问时做相似度检索把TopK结果塞进提示词。这套流程其实只是“最小可用版本”离“能用”还有不小距离。2.2 选择路线什么时候该用RAG什么时候该换别的很多人一提到要给模型补充私有知识第一反应就是微调。这里我说句实在话微调适合的是改变模型的行为模式和输出风格而不是给它灌知识。你让模型学会用某种格式写周报这是微调的强项但你想让它知道公司几百页的制度规范微调既贵又效果差每次制度更新还得重新训练一遍维护成本直接失控。RAG的优势在于知识更新是即时生效的文档改了索引更新了模型下一次回答用的就是新知识。而且RAG天然可溯源回答能追到原始文档这在企业场景里是刚需——合规部门不会接受一个答完说不出依据的AI助手。还有一个经常被忽略的选项如果你的知识量很小就固定的几条规则那直接写死在提示词里就够了完全不用上RAG。RAG有它自己的复杂度检索链路一长出问题的环节就多能用提示词解决的事不要急着上系统。2.3 RAG链路拆解从文档到答案的四道工序一个完整的RAG流程标准化拆解是四个环节文档解析、文本切分、向量化入库、检索召回。每一个环节都有对应的坑。文档解析是所有环节里最容易被低估的。PDF里的表格、扫描件、复杂排版用现成的解析库直接抽文本抽出来的经常是乱的。我处理过一个实际案例某项目方给的材料里有大量数据表格直接用常规方式解析表格结构全丢了检索时查“去年第三季度的营收数据”召回的内容只是一堆散落的数字。后来换了按版面解析的方式把表格转成结构化文本再入库效果才正常。这里我建议你在文档解析阶段多花点时间别急着入库——输入的质量决定输出的上限。文本切分直接影响检索粒度和上下文完整性。切得太粗一个块几千字检索出来一半内容跟问题无关白白占掉提示词空间切得太细几百字一块语义又不完整模型看到的信息缺头少尾。我个人的经验值是通用文档按800到1000字符切带章节结构的文档优先按标题层级切保持块间有少量重叠比如上一块末尾留50到100个字符。表格类内容单独处理一张完整的表尽量不要被切开。向量化的核心是选Embedding模型。通用中英文混合场景目前主流方案效果差异已经不太大但如果你的文档领域性很强比如医疗、法律、制造建议在某些开源模型的基础上用领域语料做增量训练或者至少测试一下通用模型在你这个领域上的表现再定。有一条经验大家可以记住先拿3到5个有代表性的真实问题去测召回的TopK结果如果前3条里就有准确答案说明向量化方案基本合格如果答案排到十几名开外问题大概率出在切分或向量模型上而不是检索逻辑。检索召回最大误区是只依赖向量相似度。向量相似度对“语义相近但关键词不同”的查询效果很好但对“关键词一致但含义不同”的情况容易翻车对数字、型号、专有名词这类精确匹配的查询也天然弱势。成熟的做法是混合检索向量检索加BM25关键词检索两路结果做归一化融合。融合权重要看业务场景我一般从五五开起步然后拿真实问题调。还有些场景需要重排模型比如召回范围很大、候选多的时候重排能显著提升排序质量但会增加一个模型调用的开销。对于刚起步的项目混合检索加TopK截断通常已经够用。2.4 检索召回不满意先查这三个地方做RAG最常见的挫败时刻就是系统上线了问了一个业务问题答案驴唇不对马嘴。这种时候先别急着怀疑模型能力按下面三个方向排查看原始文档里的答案是否真的存在。有时候不是系统不行是知识本身就没收录进去或收录了但内容和你想象的不一样。看召回出来的原文片段。把系统实际检索到的TopK内容打印出来看一眼。如果内容压根不相关问题大概率在切分或向量化如果内容相关但很零散大概率是切分太碎导致语义不完整。看问题本身的复杂度。多个条件叠加的问题比如“找出最近三个月所有未结算且金额超过五万的订单”这类复合查询对基础RAG几乎是必错项——需要走查询改写或意图拆解把一个大问题拆成几个子查询再合并结果。我见过太多团队在向量库选型上纠结半天分片策略、索引参数调了一轮又一轮最后发现问题出在文档压根没被正确切分。记住RAG的性能瓶颈大概率不在向量数据库而在前面的解析和切分。3. MCP给大模型装一套标准化的“手”3.1 背景为什么AI应用需要一套对外接口协议先把话说明白MCPModel Context Protocol模型上下文协议以前大家叫它“模型上下文协议”后来官方把它定名为“Agent互连协议”——不过业界依然习惯叫MCP。它解决的是AI应用怎么连接外部工具和数据源这个难题。在MCP出现之前AI应用接外部工具是典型的碎片化场景接一个数据库要写一套接口接一个内部系统要写一套接口接一个第三方服务再写一套接口。每个系统的鉴权方式不同、数据格式不同、错误处理不同AI应用框架里堆满了形形色色的适配代码。每接一个新系统都要重新开发一遍而且这些代码和具体服务强绑定换个环境基本作废。MCP的思路和行业早期的标准化运动很像——比如USB接口统一了外设连接方式。它把“模型怎么调用工具”这个交互过程抽象成一套标准协议模型通过统一的客户端向服务端发请求服务端按协议标准返回工具列表、资源内容、调用结果。你想给AI助手增加一套新能力只需要做一个标准的MCP服务端不用关心上层框架怎么用、模型怎么调度。3.2 架构与核心概念Host、Client、Server之间的关系MCP的架构拆开看是三件套Host运行AI应用的进程比如一个聊天助手、一个IDE插件、一个自动化脚本。它是用户直接打交道的那一层。Client嵌入在Host里的协议客户端负责建立连接、维护状态、收发协议消息。Server提供能力的一方暴露工具、资源、提示词给客户端调用。我拿一个具体场景来举例。假设你正在用某个集成开发环境写代码IDE里装了一个AI编程助手插件。这个插件就是Host插件通过MCP Client连上一个能查询项目文档的服务端这个Server里封装了一个“搜索代码仓库”的工具。你问AI“这个模块有没有被其他地方引用”AI判断需要调用搜索工具于是经过MCP链路发起调用Server执行搜索并返回结果AI再基于结果生成回答。整个过程里最关键的一点是AI模型本身并不知道这个工具怎么实现的它只知道自己有一个工具叫“搜索代码仓库”传入关键词参数就可以。工具的数量、能力、参数定义全部由Server端声明Host侧动态加载。这种设计带来的直接好处是AI应用增加工具能力时只需要配一个新的Server地址一行业务代码都不用改。3.3 三种核心原语工具、资源、提示词MCP的Server可以暴露三类能力Tools工具可执行的函数有明确的输入输出比如查询订单状态的接口、发邮件的接口、跑SQL的接口。这是最常用的一类Agent的“行动力”主要靠它。Resources资源只读的数据内容比如一份配置文件、一张数据表、一段代码片段。客户端可以按URI读取相当于给AI提供了“查阅资料”的能力。Prompts提示词模板预定义好的提示词串用户或AI可以直接套用比如“代码审查”模板、“周报生成”模板。这类能力适合把高频场景标准化省得每次重新写一遍长提示词。三类能力解决的需求完全不同。如果把AI应用比作一个员工工具是让员工能干活的“手”资源是供员工查的“资料库”提示词是教员工按固定套路做事的“操作手册”。一个完整的MCP Server通常同时包含这三类能力但要根据实际场景决定侧重。3.4 MCP的限制它管不了Agent之间的协作MCP最近热度很高有些人开始吹“MCP就是一切”这里我必须泼一点冷水。MCP定义的是AI应用与工具/数据源之间的交互协议它解决的是一对多的连接问题。但AI应用之间、智能体之间怎么协作MCP并不涉及。业界讨论“智能体之间互连”时会提到另一个概念A2AAgent-to-Agent智能体互连协议它的定位是让不同的Agent能够互相发现、传递任务上下文、协同完成复杂的跨系统流程。MCP是“模型到工具”A2A是“智能体到智能体”两者关注层次不同可以共存。做技术选型的时候分清楚需要接数据库、接API、接内部系统用MCP需要让多个独立Agent协同跑一个跨部门流程考虑A2A而不是期待MCP给你包办一切。还有一个容易被忽略的点MCP适合有明确边界的工具集成。如果你的业务逻辑本身高度耦合、流程复杂、多变频繁强行套MCP反而会增加一层协议开销。MCP的价值在于标准化但标准化不意味着适合所有场景。4. Agent从“答话”到“办事”4.1 Agent的本质把大模型从对话引擎变成任务执行引擎很多人对Agent的理解停留在“一个AI助手”这个层面但实际上Agent是一个机制设计——让模型具备规划任务、调用工具、完成任务、根据反馈自我纠错的一套循环过程。它的核心不是模型本身而是那套循环流程。我用电脑维修来类比。你问大模型“电脑蓝屏怎么办”它能给你列出七八条排查建议但不会真的动手修。而一个Agent形态的维修助手会这样做先判断蓝屏是近期更新导致的可能性大于是调系统工具读取最近的更新记录确认之后调工具查驱动版本然后执行回滚操作重启后再验证问题是否解决。每一步都用工具获取了真实信息每一步都在验证自己的操作是否生效这就是Agent和纯聊天的本质区别。4.2 Agent的运行框架规划、行动、观察、反思的闭环目前最常见的Agent实现框架是ReAct模式思考Thought加行动Action交替进行。模型先根据用户目标做规划决定第一步做什么然后选择一个工具执行得到一个观察结果再根据观察结果决定下一步动作循环往复直到目标达成或资源耗尽。举个生活中的例子你让Agent帮你订一间明天下午适合开会的会议室。它可能会先调日历工具确认你明天的空闲时间再调会议室预订工具查可用房间发现目标时段没有了于是查相邻时间段的空房最后预订并给你推送确认信息。整个过程模型做了两次规划、两次工具调用、一次失败处理全部自动完成。在这种机制里模型的能力上限决定了规划的质量而工具的数量与质量决定了行动的范围。一个模型再聪明手里没有工具也只能空想一个工具再丰富模型不会拆解任务也无从下手。4.3 Agent的记忆短期、长期与工作记忆多轮任务里Agent必须能记住“我们进行到哪一步了”。这依赖三类记忆短期记忆当前对话上下文里的信息比如用户刚才提的需求、上一次工具调用的结果。这个通常靠提示词里的历史消息维持但上下文窗口有限长会话要截断或摘要。长期记忆跨会话沉淀下来的信息比如用户的偏好、历史任务结论。可以存在外部存储里在需要时检索出来并注入提示词。工作记忆当前任务执行过程中的中间状态比如子任务清单、已完成步骤。任务越复杂工作记忆的管理越关键搞不好Agent就会跑偏做着做着忘了最初的目标。我见过一个典型翻车案例一个自动化数据处理Agent执行一个五个步骤的流程做到第三步时一次工具调用返回了异常数据Agent没有回到主目标重新对齐反而顺着异常数据往下走最后输出了一份完全错误的结果。问题就出在工作记忆里缺少“主目标追踪”机制——每步行动之前都应该重新核对一次当前状态与最终目标是否一致。4.4 不要把Agent想得太全能风险与边界Agent再强也是概率模型的产物你必须在设计阶段就设好边界否则上线之后出问题很被动。成本失控Agent会自主规划多轮调用一个简单任务可能磨掉几十次大模型调用一个复杂任务烧掉几百次都有可能。设计时必须设置调用次数上限、超时时间超了自动终止。不可控性模型在途中可能提出事先没设计过的操作路径有些路径不在预期范围内。关键操作必须加“人工确认”环节比如删除操作、外部发送消息、资金类操作一律先确认再执行。信任边界Agent的执行结果要有验证机制尤其是数据处理类任务。如果工具本身提供校验能力Agent应当在执行后主动核对如果没有设计者应该在上层加一道校验关卡宁可多一次检查不要盲目信任Agent的输出。5. 三者如何配合一个完整的落地案例前面分别讲了三者现在把它们放到一个具体场景里串联起来。假设你要给某公司做一个内部合同审查助手目标是让业务人员直接提问“帮我看看这份采购合同里有没有付款周期风险”。整个系统是这样工作的首先把公司过去三年的合同文本、法务审核意见、常见风险条款说明整理成知识库做切片、向量化、入库——这是RAG的活。Agent在判断合同条款时需要调用RAG去检索“这个条款在过去审核中的常见问题是什么”“公司对付款周期的标准要求是什么”。没有RAG模型只能用自己训练时的通用知识来审合同完全不适用于公司内部规范。然后把公司内部的合同管理系统、人员通讯录、审批流程系统通过MCP Server暴露出来。Agent需要的时候通过MCP调用合同系统读取合同原文、调人员系统确认业务负责人信息。没有MCP这些外部系统每个都要单独写一套适配代码进Agent框架每换一个系统Agent的逻辑就得跟着改。最后用户提交一份合同时Agent负责拆解任务先读取合同原文再逐条对照RAG检索出的历史风险点识别可疑条款最后调用审批系统走流程。整个过程中Agent是“大脑中枢”RAG是知识来源MCP是行动通道。这三个角色的分工放在一张表里就是这样角色职责类比RAG提供知识依据工具箱里的资料库MCP打通工具通道标准化的电源与数据接口Agent规划并执行任务手拿工具、查着资料干活的工人很多团队的误区是先花大力气做了一套RAG效果勉强能用然后想叠Agent能力发现调工具要写一堆胶水代码或者是先搭了Agent框架发现模型什么都敢答但答案没有依据又折回来补RAG。正确做法是在设计阶段就明确三者的边界和接口而不是上线之后反复修补。6. 实践建议新手可以按什么顺序入手6.1 一条从易到难的路径参考如果你目前对这些概念都只是听说还没真正动过手我建议你按这个顺序走一遍。第一步先做RAG。找一批你自己的文档搭一个最小可跑的检索问答链路。这一步的目标是理解文本切分、向量化、检索、重排的基本流程。我用下来的经验是用成熟框架起步没有问题但一定要把中间过程的数据都打开看尤其是切分后的文本块和检索结果的相似度得分这会加速你对RAG机制的理解。第二步再学MCP。把一个现成的工具服务封装成标准的MCP Server接进Agent跑通。这里不用自己写复杂服务先拿一个简单的工具练手比如让AI通过MCP调用一个本地计算接口。目标是把Host、Client、Server这条链路走一遍搞清楚工具声明、参数传递、结果返回的往返全过程。第三步最后做Agent。把前两步串起来RAG提供的知识库作为资源MCP暴露的工具作为行动能力Agent负责规划调度。建议从封闭场景开始比如只让Agent在一个限定工具集里做选择任务目标也设定得具体一点跑通了再逐步扩大场景范围。6.2 几个让我印象深刻的踩坑记录有些坑几乎是所有人都会踩一遍的我挑三个最有代表性的说。第一个是RAG的召回率看着很高但准确率很低。有一次我把TopK从5调到20召回的相似度分值都在0.7以上心里觉得稳了一验证却发现正确答案排在第十四位。排查之后发现问题出在切分策略原文里答案横跨两个文本块第一块只提到了问题里的关键词但没有答案内容第二块有答案但向量相似度不够靠前。后来改成按语义段落切分并增加重叠效果明显改善。记住向量相似度高不等于答案正确关联度和答案信息量是两回事。第二个是MCP工具的参数定义写得太随意。第一次写工具声明时我把“查询订单”这个工具的参数只定义了一个订单号字段结果Agent经常拿着错误的格式去调用服务端解析失败。后来我仔细写了参数的描述和示例值Agent的工具选择准确率立刻上来了。模型对工具参数的理解完全依赖声明里的描述文本别嫌麻烦写清楚就是给自己省事。第三个是Agent在没有明确停止条件时会一直循环下去。有一次测试一个自动化尽调任务Agent在一个问题上拿到的结果不理想它就反复换工具重试一直跑到调用次数上限才停下成本烧得吓人。从那以后我在所有Agent场景里都设置了最大步数和最大成本预算超过直接终止并上报状态这一条在面向业务方的系统里尤其重要。6.3 最后说一点我的个人体会这三样东西我的建议很简单动手之前先把它们各自解决什么问题、边界在哪里想清楚。不用追求一步到位把三个技术全部堆满先跑通最小闭环再逐步加深。技术选型真的没有银弹每个方案都要拿你的真实业务场景去验证。把细节打磨到位把每一步的“为什么”弄明白最终的产出会远超预期。
阅读完成 · 觉得有帮助？
