不懂就问：RAG到底是不是RAG？

最近圈子里聊大模型，翻来覆去绕不开三个词：RAG、Agent、多模态。但说实话，我在一线把项目从零拉到上线，发现一个挺有意思的现象——很多人对这三个词的理解停留在PPT层面。

有人觉得RAG就是“给模型挂个知识库”，有人觉得Agent就是“调API的自动化脚本”，还有人觉得多模态就是“能看图能说话”。这些说法对不对？方向对，但太糙了。真正的工程落地，是另一套逻辑。

我手头刚做完一个综合类项目，正好把这三块全揉进去了。这个项目本身不复杂，就是把企业内部一堆散落的文档、图片、表格，变成一个能对话、能分析、能自动完成任务的系统。做的时候踩了不少坑，也把RAG、Agent、多模态这些东西从理论到代码彻底过了一遍。这篇文章不写PPT，就写我怎么拆的，怎么搭的，以及哪些环节最容易翻车。

如果你是刚接触大模型应用开发的同学，或者被这三块概念绕晕了的从业者，这篇文章应该能帮你把思路理清楚。哪怕你暂时不写代码，理解这几个技术背后的设计思路，对你选型、排期、跟开发沟通都会有帮助。

1. 三大技术到底在解决什么问题

先说一个总基调，这点要是没想清楚，后面全是糊涂账。

2023年之前大家聊大模型，焦点是“模型本身”。一个模型有多强，看它参数多大、训练数据多广、推理能力多好。但到了2024年之后，风向变了，大家更关心的是“模型能用起来做什么”。于是围绕“用起来”这件事，长出了三棵技术树：RAG、Agent、多模态。

它们分别解决了三个完全不同的痛点，这三句话建议刻进脑子里：

这三者不是竞争关系，而是互补关系。RAG解决的是“知识从哪来”，Agent解决的是“事情怎么做”，多模态解决的是“数据长什么样”。

打个比方：你要做一个企业智能助手。RAG相当于给它配了一个公司内部图书馆，员工提问时它先翻书再回答。Agent相当于给它配了一个执行团队，你说“帮我整理这个季度的销售报告”，它自己去翻报表、找模板、调图表工具、生成文档。多模态相当于给它配了眼睛和耳朵，你丢给它一张截图、一个PDF扫描件、一段会议录音，它都能理解并提取信息。

这三样东西单独拎出来都能写一篇论文，但真正干活的时候，它们必须协同工作。

1.1 为什么不是微调

这里必须回答一个很多人会问的问题：做知识增强，为什么不直接微调模型？

我理解大家的直觉——模型不知道公司内部规范，那就拿公司内部数据去训练它，这逻辑听着很通。但实际工程里，微调的问题很明显：成本高、周期长、更新难。

微调一次模型，你得准备训练数据、算力资源，跑一轮训练可能以周为单位计算。而且模型内部的知识是“固化”的，公司制度改了、产品参数变了，你得重新训练。

RAG的做法就聪明得多：模型本身不动，知识文档放在外部知识库里，用户提问时，系统先把相关问题检索出来，连同问题一起丢给模型，让它“看着资料回答”。文档更新是即时的，今天改完明天就能生效，成本低到可以忽略，这就是它成为主流方案的根本原因。

当然，RAG也不是银弹。如果某个领域需要模型本身的推理模式发生变化，比如让它改变回答风格、学会特定的计算规则，那还是得考虑微调。但90%的知识型场景，RAG先一步，够用了。

1.2 Agent和多模态的关系

这个点容易被忽视。很多人以为Agent就是纯文本的“智能体”，多模态就是另一条线上的事。其实二者结合才有爆发力。

一个Agent如果只能处理文字，那它就是个“纯文职”。但它如果能看图表、能听录音、能读扫描件，那它就是“全能助理”。

我做的这个项目里，就遇到了典型场景：用户上传一张模糊的照片，上面有某个设备型号，Agent需要识别出型号、查知识库里的维护手册、调出对应参数、然后生成一份处理方案。这一连串动作，没有多模态能力做感知、没有RAG做知识支撑、没有Agent做任务编排，任何一个环节缺了都玩不转。所以，别把这三个技术当成三门课来学，它们是一个整体工程的三个支撑点。

2. RAG：核心逻辑与实操拆解

RAG全称是Retrieval-Augmented Generation，检索增强生成。名字听着学术，原理其实特别简单：让模型在回答问题之前，先从一个外部资料库里检索相关内容，然后拿着这些内容作为参考来生成答案。

我常用的比喻是开卷考试。传统模型是闭卷，它只能靠训练时学到的知识答题，不知道的就是不知道。RAG是开卷，考试时先翻书，找到跟题目相关的段落，再组织语言作答。事实性错误少、回答有依据、知识可以随时更新，这三点已经把闭卷秒得体无完肤。

2.1 知识拆解：从文档到向量

RAG的第一步，是把原始文档处理成计算机能理解的形式。这一步在工程上叫“知识库构建”，核心操作是从文档里提取文本片段，然后把片段做向量化。

具体流程我直接拆开说：

1. 收集文档：Word、PDF、网页、Markdown、TXT，凡是公司需要的知识源，都统一收进来。
2. 文档清洗：去掉页眉页脚、图片水印、冗余的空格和换行，这个环节看着不起眼，但脏数据对后续检索质量影响极大。
3. 文本切分：长文档不能直接整个丢进去，模型处理不了那么长的检索单元，需要切成小块。切分策略是门手艺活，后面细说。
4. 向量化Embedding：把每一小块文本用Embedding模型转成一串数字列表。这串数字就是文本的“语义坐标”，语义相近的文本，向量距离就近。
5. 构建索引：把所有向量存进向量数据库，建立索引，供后续的相似度检索使用。

这里面最考验经验的是第3步——切分。切片太大，检索精度下降，返回的内容太宽泛；切片太小，上下文信息不完整，模型难以理解整体语义。

我落地时的经验是：优先按文档本身的段落结构切分，段落太长再按句子边界二次拆分。同时每条切片要保留元数据，比如来源文档名、章节标题、页码，将来给模型做引用标注时用得上。具体参数上，我常用的切片大小在200到500字左右，重叠区间20到50字。

提示：重叠区间很重要。如果两段文本刚好在一个关键句中间被切断，重叠能保证关键信息不会丢失，检索时两段都能命中。

2.2 检索链路：怎么找得准

知识库建好了，查询链路就成了关键。

用户提问后，系统要做的事非常清晰：把用户的自然语言问题转成向量，去向量数据库里做相似度搜索，找出最相关的几个文本切片，把这些切片内容拼接成上下文。这个过程看起来简单，但藏着好几个容易踩的坑。

第一个坑是“问题与答案的表述不一致”。用户问“工伤报销额度上限是多少”，文档里写的是“员工医疗费用报销比例”，字面上完全不像，但语义很接近。这是Embedding模型的语义理解本事，但如果Embedding模型的选型跟不上——用了个老版本——可能就搜不到，或者搜出来一堆不相关的内容。选Embedding模型的时候，别光看榜单分数，要拿自己行业领域的文档实测。

第二个坑是混合检索。纯向量检索会遇到一个问题：精确匹配被忽略。比如用户查“A3-210型传感器”，如果文档里写的是“A3-210”，向量检索可能因为编码差异而“找不到”。所以我现在做项目，基本都上混合检索：向量检索管语义相似，BM25关键词检索管精确匹配，两者结果做加权融合。RAG之所以叫“检索增强”，这个融合机制就是工程上的灵魂。

第三个坑是重排序。第一次检索可能返回20条结果，但这20条里可能只有3条是真正有用的，得有个环节把“最有用的”排到最前面。这环节叫Rerank。轻量级做法可以用交叉编码器跑一次精细打分，把分数高的几条作为最终投喂给模型的上下文。加了这一步之后，回答准确率提升非常明显，强烈建议别省。

2.3 生成环节与引用可溯

资料检索回来了，最后一棒交给大模型做生成。这里有个细节很多人忽略—上下文窗口。

你把检索出来的Top5切片全丢给模型，但如果切片很长，加上用户问题，总量超出了模型上下文窗口，那就得做截断或摘要，否则直接报错。实操里，我通常的做法是：先设定一个“可投喂的上下文预算”，比如4096个token，检索结果从高到低往里灌，灌不下的就舍弃。这个预算要根据模型的具体规格来定，不能拍脑袋。

还要注意引用标注。企业场景里，用户问一个制度问题，AI回答完不能没凭没据。所以我在检索切片里保留了文档ID、标题、页码这些元数据，让模型在生成回答时把引用信息也带出来，用户点击引用就能看到原始出处。这不仅是体验问题，更是信任问题。没有引用的企业知识问答，回答得再漂亮，内部员工也不敢信。

我做的方案里，RAG部分的效果是通过命中率和准确率两个维度评估的。命中率看“应该命中的文档有没有被检索出来”，准确率看“检索结果排前面的文档是不是真的相关”。这两个指标，建议做RAG的人持续跟踪，它比看几个演示案例要有说服力得多。

3. Agent：编排任务与工具调用的核心场景

Agent这个说法，在圈子里被用滥了。有的产品就是个聊天框加个知识库，非要叫Agent；有些自动化脚本套了层LLM，也自称Agent。真做落地的时候得把边界划清楚：Agent的核心不是“能聊天”，而是“能做事”。

什么叫能做事？你给它一个目标，它能自己拆解成步骤、选择工具、执行动作、根据结果调整下一步，直到目标完成。这里面最关键的三个能力：规划能力、工具调用能力、记忆与反思能力。

我项目里有一个具体场景最能说明问题：内部员工要做一个“竞品信息整理”的任务。老办法是人工去搜、去抄、去汇总，Agent做这件事时，过程是这样的：

1. 理解任务目标：收集指定竞品最近三个月的产品动态。
2. 拆分步骤：先确定关键词，再逐个搜索，收集结果后去重、整理、生成对比表。
3. 调用工具：搜索API、网页抓取工具、读取内容并结构化。
4. 汇总输出：用模板生成一份报告。
5. 自查完善：对比目标，看看哪部分信息缺失，补充二次搜索。

这一连串动作，没有一个人工写死的流程图，全靠Agent自己规划。它解决的核心问题是“把灵活的、不确定的、多步骤的任务自动化”。

3.1 Agent的两种主流设计模式

做Agent工程落地，绕不开两种设计模式，理解它们对后续排期和选型特别关键。

一种是单Agent模式。所有规划、工具调用、记忆管理都在一个Agent内部完成，适合任务和目标相对单一的场景。优点是链路简单、开发调试容易，缺点是任务复杂后，Agent的推理负担重，指令一多容易“精神分裂”。

另一种是多Agent模式。多个Agent各管一段，比如一个负责需求理解，一个负责检索信息，一个负责生成内容，再有一个总控Agent做协调和汇总。适合复杂的端到端任务，但工程复杂度翻倍——Agent之间的通信协议、状态同步、异常处理都得考虑。

我在项目里并没有追求高大上的多Agent架构，而是用一个“规划器+执行器”的轻量双层结构。规划器Agent负责把任务拆成子步骤，执行器Agent负责执行具体动作。子步骤少的时候，一个Agent跑完；子步骤复杂时，规划器动态调度多个执行器协作。这种设计的好处是：代码量可控、逻辑清晰、出现问题能靠日志快速定位。对多数中小规模项目来说，这比一上来就铺一个“Agent联邦”靠谱得多。

心得：不要为了Agent而Agent。任务如果能用传统脚本固定流程解决，就用脚本。Agent的优势在于处理“流程不确定、输入不确定、结果需要动态调整”的任务。硬把确定性流程套上Agent，只会增加故障点和成本。

3.2 提示词即逻辑：Agent调优核心

Agent的表现，很大程度上不是靠改代码，而是靠改提示词。

我给Agent写提示词的时候，最重视两点：格式约束和边界约束。

格式约束是指让模型的输出严格遵循一个固定结构。比如要求它返回JSON，字段固定为“步骤编号”“动作类型”“参数”“描述”。这样程序才能稳定解析Agent的“思维过程”，否则模型自由发挥，写出来的下一步动作，程序读不懂。

边界约束是划定Agent的权利边界。比如“你只能执行查询操作，不能执行删除操作”、“遇到需要人工确认的操作，必须停下来等待批准”。这一步在真实业务里是保命用的。Agent的自主性越强，就越需要边界约束，否则它在执行中自己决定做了一件超出权限的事，后果不堪设想。

调优过程中，我积累的经验是：把提示词当成代码来管理，每个版本的提示词记录改动点、测试效果。很多团队在RAG和Agent上调优靠“玄学”，改了又测、测了又改，最后不知道哪个词起了作用。如果每次变更都做了版本记录，调优效率会明显提升。

3.3 工具调用：Agent的手和脚

Agent要执行任务，必须能操作外部工具。这就是Function Calling机制。模型根据用户意图输出一个结构化的工具调用请求，程序解析确认后执行对应函数，再把结果回传给模型。对开发者来说，做工具调用有三种路线，我根据不同项目分别用过：

给我最大的教训是：工具调用环节，不要追求“一步到位”。把大任务拆成一个个小工具，每个工具只做一件事，做好一件事。比如“搜信息的工具”和“解析网页的工具”分开，“生成图表的工具”和“格式化文档的工具”分开。工具粒度越小，Agent调度越灵活，出错时也越好排查。

4. 多模态：从看懂到动手

多模态技术要解决的问题很直接——让模型“像人一样”感知和理解不同类型的信息。

文字、图像、音频、视频、表格、扫描件，每种形态都有各自的复杂性。多模态模型的核心，就是把不同模态的信息对齐到同一个语义空间里，模型既能理解文字描述对应的图像是什么样，也能理解图像里包含的文字信息是什么意思。

我用一个实际场景说明：某项目需要处理一批设备维修记录，其中既有手写的维修单扫描件，也有设备故障照片，还有维修前后的对比文字记录。老路子是人工分拣录入，多模态模型做这件事，它能直接识别扫描件里的手写文字，能看懂故障照片里设备哪个部位异常，能把图像中的信息和文字记录做对应关联，然后整体输出一份结构化维修档案。这就是多模态在真实场景里的价值。

4.1 输入侧：识别与理解

多模态模型的输入处理，是整个链路最基础也最容易出问题的环节。

首先是文档解析。PDF扫描件、翻拍的照片、带水印的截图，这类数据直接送给模型，效果通常不理想，要先做预处理。我踩过的坑是：有些PDF看着正常，页面是扫描图片，根本没有文本层。如果直接把整份PDF喂给模型，文字提取为零。处理方法是加一个OCR环节，先用识别模型把图片里的文字“抠”出来，再进入后续流程。

这其中的工程细节还有不少讲究。比如倾斜矫正，拍照扫出来的文档经常是歪的，不做矫正，文字识别的准确率会明显下降；图像增强对低对比度、阴影遮挡的图片尤其重要，先用增强算法把文字区域突出；还有分栏处理，学术论文、报纸这类双栏排版文档，不处理的话OCR结果会串行，左右两栏的文字交织在一起。我见过不少新手在这上面栽跟头，做出来的文字提取结果颠三倒四，后面所有步骤全被带偏。

其次是表格结构化识别。大模型处理表格，光靠OCR识别文字远远不够，还得把文字重新组织成行列关系，这个过程叫“表格结构识别”。我做了个实验印象很深刻，同样一张带合并单元格的复杂表格，纯OCR提取的文字是乱的，但加了表格结构识别之后，模型直接输出一个干净的Markdown表格，内容和原表结构严丝合缝。

4.2 输出侧：生成与理解

多模态模型的输出能力，是这两年技术迭代最明显的部分。过去的模型只能给图片写文字描述，现在的模型已经能做到“看图作答”甚至“按图生成图文并茂的内容”。

举一个我实际调过的例子：把一张产品的宣传海报图给模型，要求它“总结海报设计的核心卖点，并生成三句适合发朋友圈的宣传文案”。模型不仅准确识别了海报里的产品名称、优惠价格，还能说清楚海报的视觉风格，最后生成的文案也贴合海报调性。这种输出侧的能力，在营销素材生产、内容创作辅助场景里非常实用，极大减少了从素材到成品之间的繁琐人工环节。

输出侧还有一个被低估的能力是“视觉问答之外的推理”。比如给模型一张布局复杂的仪表盘截图，问它“哪一个模块的数据与上个月相比呈下降趋势？”，模型需要先定位图表、再理解图例、再基于图像里的数据趋势做分析判断。这个调用链，比单纯问“图片里有什么”复杂得多，也是衡量多模态模型真实水平的试金石。

4.3 多模态与文档管线的工程整合

多模态单独拿出来做演示，效果总是震撼的，但放到工程管线里，就要考虑成本和性能的平衡。

多模态模型的调用价格比纯文本模型高出一个量级，所以我的策略是“能轻则轻”。图片、PDF这类文件进来，先做一个分类鉴别，判断里面有没有需要复杂理解的元素。如果只是纯文本页，走成本较低的OCR加文本模型通道；只有遇到复杂图表、手写体、多栏混排这类高难度内容，才调用多模态大模型。

另一个工程要点是缓存。同一份文档被多个部门、多个场景频繁查询，如果每次都重新过一遍识别流程，成本浪费很严重。我把识别后的结构化结果按文档ID缓存起来，第二次访问直接读缓存。这个优化在实际运行中帮我省掉了大量重复的算力消耗，响应速度也从秒级降到毫秒级，体感非常明显。

5. 三大技术如何组合：一个完整案例复盘

单点技术讲完，回到我最开始说的那个项目。这部分把我实际做过的完整案例做一个复盘，帮大家把三大技术怎么协同落地看清楚。

这个模拟项目的背景是：某公司需要一个内部智能问答与文档处理系统。员工可以提问公司制度、查项目资料，也可以上传文件要求做摘要、提取信息、生成报告。先明确项目目标，然后组合三大技术：RAG做知识问答的底座，Agent做多步任务的编排，多模态处理非文本类的输入。

5.1 整体架构设计

系统架构从顶层往下分四层，每一层对应一项明确的职责：

第一层是用户接入层，包含聊天界面和文件上传入口，对话框里既能聊文本，也能拖入图片、PDF、语音。 第二层是任务编排层，这是Agent的所在位置。它负责区分任务类型：文本问答任务直接走RAG链路，文档处理任务则先调用多模态识别再进入信息提取，复杂分析任务则拆成多步骤流程。 第三层是能力层，三大技术的能力封装成标准化服务：检索服务、问答服务、识别服务、报告生成服务，每个服务都可以被上层独立调用。 第四层是数据层，存向量索引、原始文档、识别缓存、操作日志，提供统一的数据访问。

这个架构一点也不复杂，但每层之间的接口定义花了我不少心思。我坚持的原则是层与层之间走标准化的“指令输入—结果返回”模式，这样任意一层替换技术方案，其他层不需要大改。后来RAG从旧的向量数据库迁移到新的方案，数据层接口没变，整条链路没怎么受影响，这种解耦带来的好处是立竿见影的。

5.2 用户问题流转全流程

用一个具体用户提问来看整条链路的流转，问题很典型：“请帮我分析这张产品故障图片，并查找相近型号的维修手册，给出排查建议。”

这个问题单靠任何一项技术都答不好，但三大技术协同就顺了：

第一步，用户上传故障图片，多模态服务启动，识别出产品型号和设备状态。识别结果是结构化的信息，比如型号A3-210、故障部位指示灯不亮。第二步，Agent读取到型号信息后，发起RAG检索，从维修手册知识库里找出A3-210相近型号的维修章节、常见故障排查流程。第三步，Agent把多模态识别结果和RAG检索结果做整合，汇总成一份排查建议报告，返回给用户，报告里还带上引用来源，方便用户打开原始手册核实。

从用户体验来看，这就是一句话的事情，但背后的三大技术协同，环环相扣，缺一不可。这个例子也说明，不谈协同、孤立理解三大技术，是没法真正应对真实业务场景的。

5.3 编排层的决策逻辑

编排层是整套系统的大脑，它的决策逻辑直接决定了系统会不会“答非所问”或者“答得非常笨”。

我实现的时候，编排层内部维护一个意图识别模块，送入用户的问题和文件后，这个模块根据内容走不同的分支。分支规则并不复杂：纯文本且含具体实体名词，走RAG检索问答；文本较长且要求做摘要，走摘要生成；含图片或PDF，先走多模态识别提取；多步骤任务，进入Agent编排。实际使用中，分支规则足以覆盖大多数场景，而更细的调度，则需要在Agent的提示词里明确——一个关键技巧是给Agent一段完整的“工作说明”，告诉它遇到什么情况调用哪个服务、服务返回结果后怎么判断是否继续或是结束。

这套编排逻辑，我一开始写得很复杂，想用规则引擎做完整覆盖，后来发现过度设计，维护成本远超收益。后来改成“意图分类模型做粗粒度判断，规则做细粒度兜底”，系统反而稳定了，这也算我在这个项目里最深的一个感悟。

6. 落地过程中的踩坑与排错经验

这一节是干活的部分。说实话，理论网上到处都有，真把三大技术落地到项目里，坑一个接一个。我把印象最深的几个问题整理出来，给大家提个醒。

6.1 向量检索“答非所问”的排查

遇到过最头疼的问题：知识库里有答案，模型也能答出这个答案，但检索环节就是搜不到正确的内容。找了一圈，发现原因有两个。

一是Embedding模型对专业术语识别差。品牌名、型号名、内部缩写，这些词汇在通用Embedding模型里并没有被很好地区分，相近型号的向量距离过近，检索时频繁混淆。解决办法是换行业微调过的Embedding模型，或者干脆加关键词权重。二是切片不合理。长文档里一个核心知识点被切开，分到了两条切片里，任何一条单独拿出来，都和问题对不上。调整切分策略，按语义段落切分并增加重叠区，问题就解决了。

排查思路其实很清晰：先看检索的结果列表，检索出的是不是相关内容。如果列表不相关，问题在Embedding和切分；如果列表相关但回答还是错的，问题在生成环节的提示词和上下文组织。两头拆，别在中间瞎调参数。

6.2 Agent循环失控与工具误调

Agent跑着跑着开始疯狂循环，这是一个特别经典的坑。症状是它在同一个步骤上来回执行，或者不断调用同一个工具，始终不推进下一步。

我见过最离谱的一次：Agent要搜索一个关键词，结果它把“搜索结果为空”也当成了一次成功执行，然后又发起了一模一样的搜索，无限循环，直到触发我设置的调用次数上限才停下来。那次之后我做了一个重要改进——给Agent的所有工具调用加“最大重试次数”和“终止条件”两个硬约束。

解决循环问题，还有一个实战技巧：日志中记录每次工具调用的输入和输出，一个循环能造成的资源浪费非常惊人——每调用一次服务都是钱，都是时间。所以排查时看日志，基本一眼就能看出循环模式。后来我给Agent增加了状态记录，每次进入新步骤时都要求它更新状态，如果状态没有变化而动作却在重复，就直接终止。

6.3 多模态识别结果不准

多模态识别不准，是用户感知最强的问题。识别出错，后续的RAG检索和Agent编排全部受影响，差错会被逐级放大。

排查下来发现，问题绝大多数不在模型本身，而在预处理环节。有一类情况是图片质量差——亮度低、遮挡多、角度偏；另一类情况是文档排版复杂，比如表格合并单元格、目录配图、扫描件阴影。处理方案也很直观：图片先做质量增强、倾斜矫正、方向校正再送入模型；扫描件先做OCR预处理，再按文本块重组；复杂表格加表格结构识别模型，而不是让大模型硬看图片。

这里有一条实践出的判断标准：只要多模态识别结果和你肉眼看到的内容有明显出入，先怀疑预处理环节，不要急于换模型。绝大多数识别质量问题的真凶都在上游。

6.4 成本失控与性能优化

大模型应用落地，成本是绕不开的话题。纯做技术Demo，不会太在意成本，但正式上线，每一分钱都要算清楚。

我总结的成本控制三板斧：第一，尽量用轻量模型。不是所有任务都需要大模型，意图分类、实体提取、信息规整这类任务，用一个小模型足够，没必要每次都调大模型。第二，做好缓存。同一个问题问十次，如果不需要追求最新数据，直接读缓存回答，成本为零。第三，控制上下文长度。投喂给大模型的上下文越长，成本越高，我加了一个上下文压缩模块，检索到的长文本先压缩成精华摘要，再喂给模型。三层叠加，整体成本比最初方案下降了将近一半，回答质量几乎没有下降。

7. 选型经验与未来扩展

三大技术落地，选型才是决定后续研发效率的隐藏变量。这块我给出一些实用经验，供大家参考。

模型选型上，生成模型选主流高性价比系列。RAG场景单轮问答用中小参数模型即可，长上下文需求再说。Agent场景尽量选有原生Function Calling支持的模型，这个能力是否原生，直接影响开发效率和稳定性。Embedding模型一定拿行业文档实测，对比不同模型的检索命中率。

向量数据库选择，优先看三件事：是否支持混合检索，是否有完善的过滤机制，是否有方便的扩展能力。数据量小的项目用轻量方案即可，数据量大再上分布式架构。

多模态模型按场景做取舍：需要OCR和表格识别的选专业识别方案，需要复杂推理的选旗舰多模态模型。另外强烈建议把RAG切分模块、Agent编排模板、多模态预处理流程做成内部通用组件，沉淀成工具库。这样后续接新项目时，三天就能搭出原型，不用从零再来。

关于未来扩展，有几个方向值得关注。RAG方面，融合知识图谱做结构化推理、动态更新知识源是重点方向。Agent方面，更强的长程规划能力和多Agent协作框架还在快速演进。多模态方面，视频理解、实时语音交互、跨模态生成是明显的趋势。三大技术的边界会越来越模糊，最后走向同一件事——让机器更像一个能听、能看、能想、能做的智能体，这个趋势已经很清晰了。

我把这些坑和经验写下来，是希望后来者少走弯路。做RAG别光学检索，做Agent别只写提示词，做多模态别只跑Demo——把三者串成一条完整的产品链路，你才真正知道大模型应用的水有多深、风景有多好。