RAG、MCP与智能体：大模型落地的三道关

大模型的能力是越发强大了，然而其落地却并非那般迅速。从单次对话转变至多步任务，其间横亘着庞大的系统工程。这篇文章所要探讨的是三个无法回避的技术方向，分别是RAG、MCP以及智能体。

一、RAG：让模型学会翻资料

截止于训练时刻的大模型知识，这属于天生存在的局限，RAG的思路是这样的，在用户进行提问这个行为的时候，首先要从知识库当中去检索与之相关的内容，然后再让模型借助这些资料来产生答案。

有关数据分片，这可是关键的第一步。文档要是切开得太过细碎，那上下文就会出现割裂的情况；要是切得太过完整，检索的时候就会不够精准。技术手册按照章节来切，问答对按照条目来切，不同的类型有着不一样的策略。进行分片之后生成向量，然后存入向量数据库中。

作为终点的并非检索。需要进行排序筛选的是被召回的片片断断点点零零星星。具有常见性的两阶段节段性检索呈现有：首先借助向量召回来一批批，接着凭借重排整整理理模型进进行行一一番番精排排。重排能够实现对相关性更精微细致的判判断断。不过其计算成本高高昂昂。

明确指令理解极为关键，“怎么配”以及“配错了怎么办”指向的是不同的文档，仅仅匹配关键词极易出现偏差，存在的一些系统会在检索之前增添一层意图识别。

向着GraphRAG这个进阶方向迈进，它是运用知识图谱去组织信息的方式，实体关系是需要预先进行抽取的，在检索的时候是沿着图谱前行的，这样就能回答更为复杂的问题，就像“A和B合作过哪些项目”这类问题，文档片段是难以拼凑起来的，而图谱却能够直接将相关内容列出来。

二、MCP：让模型学会用工具

硬伤在于，大模型没办法直接对外部系统进行操作，它既不能够去查询数据库，也不可以调用API，更无法执行代码。而MCP这类协议所解决的，正是模型与外部世界交互方面的问题句号。

“MCP定义客户端 - 服务器架构”这句不变，“通过该架构此模型充当客户端经标准协议调用各类工具服务器”，“这些工具服务器里头封装数据库查询、代码执行、API调用等能力”，“模型只要知道‘有哪些工具、怎样调用’，其实现乃由服务器达成”。

关于工具的描述得遵循规范，每一个工具都呀具备明确的名称，清晰的描述，还有参数列表，模型依据问题来判定调用哪一个工具，以及填入什么样的参数，要是描述不清楚的话就很容易选错，有些团队会撰写few-shot样例来助力理解。

多步骤要进行任务管理，复杂问题一般常常需要多次工具调用方可成功，并且后面所进行的操作依赖于前面的操作，“查询某公司去年的营收状况，之后将其与同行进行比较”，需要首先查询数据库从而获取到相关数据，接着调用分析工具展开对比，MCP能够支持任务以链式方式进行调用，中间所产生的结果能够在上下文之间予以传递。

底线是安全，工具调用或许潜在风险，协议一般给予沙盒隔离还有权限控制，敏感操作要用户二次确认，或者限定特定环境去执行。

刚由Google推出的A2A协议同样值得予以关注，它十分注重于多智能体之间的协作情况：其中一个智能体能够将子任务托付给另外的一个，并且任务的状态是能够实现同步的，借此为构建复杂的多智能体系统提供了标准化的基础条件。

三、智能体：从回答问题到完成任务

能让模型查资料的是RAG，能够让模型调工具的是MCP，把这两者结合起来，就能做出来真正干活的智能体了。

智能体区别于问答系统之处在于，它具备状态，能够进行规划，能够执行多步骤任务。对于“帮我订下周去上海的机票”，这需要查询时间，对比价格，填写信息，下单支付。每一个步骤可能会调用不一样的工具，在这个过程当中可能需要向用户追问。

核心是任务规划，模型要将大目标拆分成能够执行的子任务，存在这样的方式，采用CoT提示工程令模型一步步思考，还有的方式是运用专门规划器把拆解与调用分离开来，规划质量会对成功率产生直接影响。

记忆管理得进行分层，在多轮对话当中，用户存在中途修改需求的可能性，或者同一个智能体会处理多个任务，短期记忆会缓存最近几轮，长期记忆用于存储用户偏好，像MemGPT等框架将记忆做成层级结构，重要信息实现持久化，临时信息会随着对话而过期。

有多方面的模态进行支持，这是相当实用的。存在一种可能，那就是用户兴许会发送截图来询问“这按钮缘何点不了”，又或者通过语音去描述故障情况。多模态的智能体，得对文本、图像以及音频这些信息进行对齐，在跨模态理解之后，再去统一做出决策。模态的对齐以及融合，属于底层的关键技术。

群体智能属于更高一级的形态，单体智能体具备的能力存在局限，复杂的任务需要多个角色共同协作，AutoGen等框架为多智能体协同提供支持，其中一个负责进行计划、一个负责执行、一个负责质检，它们之间会相互讨论并加以修正，多智能体通信需要极为高效的消息传递以及任务状态同步，集中进行训练、分散开展执行是较为常见的范式。

四、从原型到产品还有多远

RAG，单独看并不陌生，MCP，单独看也不陌生，智能体，单独审视同样不陌生，然而，将它们整合到产品里，却会遭遇一连串的工程问题。

那速度方面，多步里的推理意味着要进行多次模型调用，如此一来延迟逐渐累加，缓存策略、负载均衡还有推理加速，每一层都必须得进行优化。

稳定性方面，模型生成存在不稳定状况，同样一个输入，却可能出现不同的输出结果。若将其应用于自动化流程，那就需要增添校验环节以及设置兜底措施。当置信度低于阈值之时，便会触发人工接管流程，在进行关键操作之后，要让用户予以确认。

成本，模型调用的次数较多，API所产生的开销不是少数，蒸馏模型，本地进行部署，运用小型模型去处理常规任务，将复杂问题交付给大模型，这些皆是控制成本的方式。

为了进行评估，要考虑如何来判断智能体做得好不好，这不能仅仅看单次回答状况的质量情况，还需要考量该智能体在任务完成方面的比率，以及多轮对话里成功的概率，还有资源消耗的情形领域不一样，指标必须要定制。

如今，大模型的能力边界仍在扩展，然而技术所关注的重点正从“模型究竟有多强”转变为“系统到底有多稳”。RAG能够使知识库充满活力，MCP可以打通工具链，智能体可实现自动化升级。唯有这三块拼图拼接起来，才有可能打造出真正能够落地的应用。

工程师高培觉得理论是骨架，落地才是血肉。

相关标签： # RAG # MCP # 智能体 # 系统工程 # 多智能体协作