前一阵子团队内部做技术分享我整理了一份关于大模型应用开发的材料标题就叫“大模型三大核心技术RAG、Agent、多模态详解与实战指南”。整理完才发现这三样东西基本把当下大模型落地项目里最常碰到的难题都覆盖了模型知识不够新、模型不会用工具、模型只能看懂文字。很多朋友后台私信我说这份材料“收藏了就等于会了”我觉得不行还是得把里面的核心思路和踩坑经历拿出来好好聊一遍让真需要的人能照着做、能避开我走过的弯路。这篇内容适合正在做AI应用开发、从Prompt调包侠想往真实项目推进的开发者看也适合刚接触大模型、想系统了解应用层技术选型的产品和技术负责人。我会按RAG、Agent、多模态三个方向逐层拆解讲清楚每个技术解决什么问题、核心原理是什么、最小可用方案怎么搭最后再把三者融合的架构思路和工程落地中的常见坑一次性说透。1. 先搞清楚为什么偏偏是这三项1.1 大模型应用的真正挑战接触过大模型真实项目的人应该都有感触光会写Prompt远远不够。你拿一个通用的对话模型去做企业知识库问答它会一本正经地给你编造一个不存在的制度条款你让它去查一下某个实时数据它只能抱歉地说自己知识截止到某个时间点你给它一张截图让它提炼里面的信息它直接告诉你“我只能处理文本”。这几个痛点恰好指向了三个不同的能力缺口知识缺口模型训练完之后知识就冻结了它不知道你公司内部的资料也不知道昨天刚发生的事情。需要有一种机制把外部知识接入到模型生成过程中。行动缺口模型只会“说话”不会“做事”。让它查天气、订会议室、调接口它没有手也没有脚。需要给它一套调用外部工具的机制。感知缺口现实世界的信息不只是文字还有图片、语音、视频、表格。模型如果只能读文本很多真实场景根本没法落地。RAGRetrieval-Augmented Generation检索增强生成、Agent智能体、多模态Multimodal这三个技术正好分别对应这三个缺口的解决方案。这也是为什么业内现在聊大模型应用基本绕不开这三板斧。1.2 三者的边界与关系先说边界。RAG的核心是“先查资料再回答”它解决的是知识来源的问题Agent的核心是“规划动作并调用工具”它解决的是任务执行的问题多模态的核心是“让模型能理解图片、音频等非文本信息”它解决的是感知输入的问题。很多新手容易把它们看成三个独立的技术方向实际项目里这三者经常是协同工作的。用一个不太严谨但很好理解的类比如果把大模型比作一个人类员工RAG是给它配了一个资料库和搜索工具Agent是给了它一套工作流和执行力多模态是让它长了眼睛和耳朵。三者不是竞争关系而是互补关系。后面我会专门讲三者融合的架构设计这里先建立一个整体认知RAG负责让模型“知道”Agent负责让模型“做到”多模态负责让模型“看到听懂”。技术核心问题解决什么典型场景落地难度RAG知识来源知识过时、不了解私有数据企业知识库、客服问答较低最容易见效Agent任务执行模型只能说话不能做事自动办公、流程编排、代码生成中等工程复杂度高多模态感知输入模型只能处理文本图片理解、OCR、音视频摘要取决于业务复杂度2. RAG让大模型学会“查资料再回答”2.1 RAG到底在解决什么问题RAG这个概念刚出来的时候很多人以为它只是“在Prompt里拼一段资料再让模型回答”。这句话说对了一半但如果只是这么简单就不会有后面那么多工程优化的故事了。RAG的本质思路可以概括为“开卷考试”考试的时候允许你翻书但翻到什么内容、怎么把翻到的内容组织成答案决定了你的成绩。对应到大模型应用里“翻书”就是检索“组织答案”就是生成。具体流程是先准备一批文档把它们切分成小块chunk每一块用Embedding模型转成向量存入向量数据库。用户提问时把问题也转成向量在向量库里做相似度检索找到最相关的几个文档片段。然后把用户问题和这些片段一起拼进Prompt交给大模型生成回答。这样做的好处是模型不需要记住所有知识只要检索做得好就能拿到最新、最相关的信息来回答问题。相比给模型微调Fine-tuningRAG的优势在于成本低不需要训练、更新快改文档就行、可追溯能标注答案来源。2.2 从0搭一套最小RAG我在给某公司做内部知识库的时候第一版就是用最简单的流程跑通的。当时的目标是让模型能回答公司员工手册里的问题。步骤分解下来大概是这样的第一步文档加载与切分。把一份几十页的PDF转成纯文本按固定长度切块。当时我用的切块大小是400个字符左右重叠overlap设成50个字符。为什么这么设切太短会导致同一个知识点被截断检索时召回内容不完整切太长会让向量表达变得模糊而且占用上下文空间太多。50个字符的重叠是为了保证跨块时语义连续。第二步向量化与存储。用Embedding模型把每个文本块转成向量。我当时用的是开源的Embedding模型向量维度是768维。存储上选择了常见的向量数据库当然第一版为了快速验证直接用内存里的向量列表也能跑通。代码大致是下面的逻辑import numpy as np # 假设已经用 embedding_model 把文本块变成了向量 chunk_texts [员工手册第一章..., 员工手册第二章..., ...] vectors [embedding_model.encode(t) for t in chunk_texts] def retrieve(query, top_k3): query_vec embedding_model.encode(query) scores [cosine_similarity(query_vec, v) for v in vectors] top_indices np.argsort(scores)[-top_k:][::-1] return [chunk_texts[i] for i in top_indices]第三步拼接Prompt并调用大模型。这一步的Prompt模板非常关键要让模型知道“资料里没提到的不要瞎编”。我当时用的模板大致是这样的请根据以下资料回答问题。如果资料中没有足够信息请直接回答资料中未找到相关信息。 【资料】 {检索到的文本块} 【问题】 {用户问题}这套最小流程跑通之后效果已经能用了但离“靠谱”还有距离。比如员工问“年假天数怎么算”系统经常会漏掉最关键的那段文本。这个问题后面再细讲。2.3 一个文本线的实操细节补全上面的流程看着简单但每一环都有讲究。我再补充一些当时实际调参和排查的经验。首先是切分策略不能盲目追求固定大小。我当时发现在处理表格类文档时固定字符切分会把表格结构拆得稀碎。后来改成按段落优先切分段落太长再按句子切效果明显好很多。有些成熟框架会提供递归切分器Recursive Character Splitter本质上是先按大单位切再切到小单位目的就是尽量保住语义完整性。其次是Embedding模型的选型。不同模型对中英文的支持差异很大如果业务文档是中文为主一定要测几个模型的实际召回效果不能只看公开榜单。我印象很深的一个案例是某个中文Embedding模型在标准评测集上分数很高但放到某公司的法律合同文本上检索出来的相似片段经常语义不对。后来换了一个能更好处理长句的模型才解决。这个测试成本很高但比上线后再改划算得多。第三是检索策略。第一版我用的是纯向量相似度后来发现很多专业术语或产品编号用向量检索效果并不好。比如用户搜“MB-102型号”向量检索可能召回到语义相近但型号不符的文本。后来加了关键词检索BM25和向量检索的混合方案效果提升非常明显。这个思路在很多成熟系统里已经默认配置了。最后是重排序Rerank。向量检索先粗召回几十个候选再用一个专门的Rerank模型精排把最相关的几条放到最前面。这个步骤能显著提升最终回答质量但在小业务量场景下会引入额外延迟需要权衡。我当时在内部知识库系统里压测过加了Rerank之后回答准确率大概提升了15%但接口时延增加了200毫秒左右后来通过只在top_k5时才触发Rerank来缓解。2.4 实战中必须注意的坑RAG看似好上手真正落地的时候坑比想象中多。我从实际项目里总结了几类高频问题第一类检索质量差导致答非所问。这种问题别急着调Prompt先看检索结果对不对。排查方法很简单把RAG链路拆开单独打印检索出来的文本块看看跟用户问题是不是相关。如果检索结果本身就跑偏了后面生成环节做得再好也没用。我见过不少团队花了两周调提示词最后发现是Embedding模型没选对。第二类上下文窗口限制。检索回来的文本块数量不能贪多。有的文档片段很长四个片段就可能超过两三千字把上下文全塞满了模型反而找不准重点。我一般把Top_K控制在3到5个每个文本块控制在300-500字既能覆盖信息又不至于稀释注意力。第三类回答出现幻觉但引用真实来源。这是RAG系统里最隐蔽的坑模型生成的结论是瞎编的但它引用了一个文档编号导致用户信以为真。解决办法是在Prompt里强约束“只能基于资料逐条回答”并且在后处理环节校验生成内容是否真的来自检索文本。我现在做RAG系统一定会加一条规则答案必须能映射到具体的原文片段否则宁可让模型回复“资料不足”。第四类文档更新不及时。知识库文档改了但向量库里还是旧向量。这个属于工程问题需要在写入新文档时做版本管理实时更新向量库中的对应记录。某些团队用定时全量重建的方案文档量少的时候没问题量大之后很浪费资源最好做成增量更新。3. Agent让大模型学会“动手做事”3.1 从聊天到执行Agent的能力拆解RAG解决的是“知识”问题Agent解决的是“行动”问题。很多开发者第一次接触Agent都会觉得神奇你让模型查一下某城市明天的天气它真的能自己去调用一个天气API然后把结果整理成一段话告诉你。整个过程它没有真正“接入”API而是通过一种叫做“工具调用”Tool Calling / Function Calling的机制完成的。Agent的核心能力可以拆成四块规划Planning、工具使用Tool Use、记忆Memory、反思Reflection。规划把一个复杂任务拆解成多个子步骤决定先做什么后做什么。工具使用根据任务需要选择合适的API、函数或数据库去执行。记忆短期记忆是上下文窗口里的对话记录长期记忆是存到外部存储里的历史信息。反思模型根据执行结果调整下一步策略而不是一条路走到黑。想理解Agent最直观的类比是“请了一个实习生”他接到一个任务后会先想清楚怎么做然后调用公司内部的各种系统查资料、填表格如果某一步出错了他会看到错误结果再调整方法最后给你一份汇报。Agent的工作机制就是把这个流程自动化了。3.2 用最少代码写一个能查天气的Agent我不打算直接扔给你一个“Agent框架”因为那样容易让你以为Agent是某个黑盒框架的专利。实际上只要模型支持工具调用用几十行Python就能写出一个最小可用的Agent。先看一个最简单的工具定义。假设我有一个查天气的函数需要接收城市名和日期两个参数def get_weather(city: str, date: str) - dict: # 这里是真实查天气的逻辑 return {city: city, date: date, weather: 晴, temperature: 28}然后我需要把这个函数的“描述”告诉模型。描述的方式要遵循模型API的结构化格式大致像这样{ type: function, function: { name: get_weather, description: 查询某个城市某天的天气情况, parameters: { type: object, properties: { city: {type: string, description: 城市名}, date: {type: string, description: 日期格式YYYY-MM-DD} }, required: [city, date] } } }Agent的循环逻辑是先把用户问题发给模型并附带工具定义列表。模型如果判断需要查天气就会返回一个“工具调用请求”里面包含参数。我们拿到参数后执行真实的get_weather函数再把结果作为新的消息发回给模型。模型看到执行结果后生成最终的文本回答。这个“模型请求调用工具 - 程序执行工具 - 结果回传模型 - 模型生成最终回答”的循环就是Agent最基本的工作模式。很多复杂的Agent框架本质上是在这个循环上加了更复杂的规划、记忆和条件判断逻辑。3.3 让Agent更聪明地规划多步任务上面那个查天气的Agent只需要一步工具调用就能完成但真实业务里很多任务需要多步推理。举个例子某公司想做一个“自动生成周报”的Agent要求它从公司内部系统拉取本周项目进展再汇总成周报摘要。这个任务大致需要这样几步调用项目列表API拿当前负责的项目ID对每个项目ID调用项目进展API拉取各自的进展详情将所有进展汇总整理成周报格式。这样的任务让模型一次性做完整很难更常见的是让模型进入“思考 - 行动 - 观察”的循环每次只做一步根据上一步的执行结果来决策下一步。这种模式在业界被叫做ReAct模式Reasoning and Acting推理与行动交替进行核心启发是不要让模型一股脑规划好所有步骤然后执行而是让“行动计划”和“事实观察”交替进行每一步都基于真实反馈。这也是为什么现代Agent框架大多支持“多轮工具调用循环”的原因。实操时需要注意多步工具调用会显著增加Token消耗和延迟。某开发者曾跟我分享过一个失败案例他们做了一个复杂Agent预期3步能完成的任务模型跑了12步还没结束用户已经等得不耐烦了。后来他们在系统里加了最大迭代次数比如最多循环5步超过就强制结束并让模型基于已有信息作答。这一步非常关键。3.4 Agent工程化的关键细节Agent工程化的难点不在“跑通”而在“可控”。我在负责某业务流程自动化系统的过程中总结了几个非常重要的经验。第一个经验是工具描述必须极其精确。很多失败案例的根源在于模型选错了工具。比如你有两个工具一个叫“查余额”一个叫“查流水”如果描述写得太模糊模型可能把“查余额”理解成“查流水”。我建议在工具描述里明确写“什么时候应该用这个工具”和“什么时候不该用这个工具”必要时给出正反例。工具数量超过二三十个之后选择的准确率会明显下降这时候就需要引入一个分类器先缩小候选范围。第二个经验是防死循环和防超时。Agent框架里一定要配置最大迭代次数和单轮超时否则模型可能在某个错误分支上反复横跳。我们当时专门给测试环境加了“危险模拟器”故意让某个API返回异常看Agent能不能正确退出循环并上报错误。能正确处理异常路径的Agent才敢上生产。第三个经验是记忆管理。短期记忆靠上下文窗口但上下文窗口是有限的。对话一长早期信息就被挤掉了。解决方案是把“对话摘要”定期写入上下文或者把重要信息提取到长期记忆库。长期记忆可以用向量库也可以用普通数据库关键是结构化和检索要快。第四个经验是评估。Agent比RAG难评估得多因为它的行为是动态的。业内一个比较实用的做法是“剧本杀式评测”提前准备好几十个脚本每个脚本描述一个完整场景和预期结果让Agent按脚本走一遍检查它每一步的工具调用和最终输出是否符合预期。这种评测方式在识别“Agent会不会胡乱调用工具”这个问题上非常有效。第五个经验是成本控制。Agent每一步都要调用模型API多步循环意味着更多Token消耗。现在比较常见的优化是“先花小钱分诊再花大钱执行”第一步用一个便宜的模型做意图分类和任务拆解之后只对真正复杂的环节调用强模型。这个思路在并发热门后尤为重要我们的系统上线初期没做这个控制半个月下来模型账单直接翻了三倍。4. 多模态让大模型看懂图和声音4.1 多模态大模型到底多了什么多模态这个概念字面意思是“多种模态”落到大模型领域最常见的组合是“文本 图像”。你给它一张截图它能告诉你截图里写了什么你给它一张产品照片它可以说出照片里有哪些物体。更进一步的还有支持音频、视频输入的多模态大模型。从原理上看多模态大模型融合了多个信息源而不仅仅是把图像丢给语言模型。以图文理解为例主流做法是把图片切分成视觉块Patch每个视觉块经过视觉编码器转成“视觉Token”再像字词一样喂给语言模型。这种统一处理方式的不同之处在于模型能同时理解“图上有什么”和“文字在说什么”甚至能推理图像和文字之间的逻辑关系。落到实际应用层面多模态解决了很多以前需要单独部署OCR模型、目标检测模型、图像分类模型才能解决的场景。比如表格还原直接拍照上传一份纸质表格模型能按结构化表格格式输出内容截图理解用户发一张界面报错截图模型能识别出错误码和关键信息图文问答销售拿着产品手册拍照提问模型能根据图片内容直接回答音视频摘要上传一段会议录音模型能输出会议纪要和待办事项。这里重点提一下多模态和传统OCR的区别。传统OCR只能把图片里的文字提取成字符串而多模态大模型能理解文字的空间位置、表意关系和上下文。用一张带复杂排版的产品报价单举例传统OCR提取出来的可能是一堆错乱的字段而多模态模型能直接输出“型号、单价、数量”对应的结构化JSON。4.2 一个图片理解的实战例子多模态大模型的接入方式比想象中简单。现在很多模型服务都支持直接在对话接口里传图片调用方式和文本对话基本一致只是在请求结构里多了一个图片字段。以某项目中做一个“发票信息抽取”的Demo为例目标是让模型识别发票上的发票号、金额、日期和购买方名称。第一步准备图片输入。把发票图片转成Base64编码放进请求里。关键点是图片不能太大。我当时遇到的问题是原图有几兆大小直接传过去要么超时要么被拒后来先把图片压缩到长边不超过2048像素文件压缩到1MB以内才稳定通过。第二步设计抽取Prompt。针对结构化抽取任务我强烈建议让模型“只输出JSON并严格校验”这样能避免模型把描述文字和抽取结果混在一起。Prompt大致这样写请分析这张发票图片返回JSON格式数据 { invoice_no: 发票号码, amount: 价税合计金额, date: 开票日期, buyer: 购买方名称 } 如果某个字段无法识别填null。不要输出任何额外文字。第三步处理模型输出。模型返回的文本可能是带Markdown代码块标记的JSON字符串也可能因为幻觉产生不存在的字段。我在后处理里用正则提取JSON段落再交给JSON解析器做严格解析解析失败就标记为“识别失败”而不是硬着头皮返给用户。实测下来清晰度正常的发票图片识别准确率能达到业务要求尤其是日期和金额这种结构化字段而传统OCR方案需要额外配置模板和规则才能做到类似效果。4.3 做多模态应用容易踩的坑多模态看起来“喂张图就能出结果”但真实落地会遇到很多细节坑我一一列出来。第一个坑是图像分辨率与细节丢失。模型对输入图片的长宽比和分辨率有限制通常会把图片缩放成固定尺寸。如果原图是一张很长的截图直接缩放会导致边缘文字模糊。我当时做了一个“切片再拼合”的方案把长图按区域切成重叠的小块分别识别后再合并结果效果明显改善。这么做会增加请求次数但在某些场景下值得。第二个坑是图内文字幻觉。多模态模型对图片里的文本经常“脑补”。尤其当图片模糊、字体花哨、或者文字被logo遮挡时模型会编造根本不在图片上的内容。这在票据、合同扫描件场景里是致命的。解决办法有两个一是Prompt里强调“只能识别图内实际存在的文字”二是在关键字段上做二次校验比如金额字段必须符合数字格式、日期字段必须符合日期格式校验不通过就标记为存疑。第三个坑是中文场景下的差异。很多开源的图文模型是在英文数据上训练的对中文票据、中文手写体、中文表格版式的理解明显弱于英文。我在选型阶段一定要拿真实业务图而不是网上公开图集做测试因为公开Demo表现和真实业务表现经常是两回事。某次测试让某开源模型识别一句中文手写留言结果它把“明天下午三点开会”读成了“明天下午三点开会回”。这个错法虽然字形相近但语义完全变了当时差点因此误判模型能力。第四个坑是数据隐私。图片往往比文本更敏感。发票含税号聊记录含对话人车间照片含产品设计细节。如果调用云端模型API一定要做图片脱敏处理例如去掉敏感区域、打码、局部裁剪或者干脆选择私有化部署模型。我们的客户对此要求极高后来基本所有图片处理任务都走了本地部署的模型。5. 三者融合RAG Agent 多模态的典型架构5.1 融合架构示例个人知识库问答助手聊完单项技术来看一个把三者结合起来的真实系统形态个人知识库问答助手。这个助手要满足的需求是能读取用户上传的文档包括PDF、Word、图片截图能回答文档相关的知识问题能调用外部工具比如查天气、查日历、发邮件文字和图片问题都能处理。如果用单一技术硬扛效果会很差用融合架构整个系统就能各取所长。先看整个系统的数据流多模态模块负责“感知”用户上传一张图片先调用多模态大模型识别图片内容把图片“转译”成文字描述或结构化文本上传一份PDF如果是扫描件也需要先走多模态OCR识别成可检索的文本。RAG模块负责“记忆”所有识别出来或直接上传的文本文档经过切分、向量化后存入知识库。用户提问时先做检索把相关文档片段找出来。Agent模块负责“调度与执行”用户的请求先经过意图识别层。如果问题是知识类问题就启用RAG检索如果任务是操作某个系统比如“给某某发一封邮件”Agent会调用邮件发送API如果用户上传的是图片Agent把图片交给多模态模块处理再把结果整理成回答。这三者不是三个独立服务而是作为同一个系统里的三个能力由Agent统一编排。从我当前项目的实际经验看融合系统的关键在于“谁来做主控”。5.2 分工与优先级设计很多团队一开始的想法是“所有请求都先过Agent让Agent临场发挥”。我在实际运行中发现这条路很危险因为Agent的推理不可控任何一步走错都会导致整体失败而且排查问题非常困难。更稳健的做法是“主流程线性化Agent兜底而不是包揽一切”。具体来说先用一个轻量级意图分类模型甚至可以用关键词规则判断用户请求的类型。如果是知识类问题直接走RAG流程检索 - 拼接Prompt - 生成回答。这个流程是固定的、可预测的适合绝大多数常见问题。如果用户请求涉及动作指令才进入Agent流程模型规划步骤、调用工具、观察结果。如果是图片输入直接交给多模态模块解析然后将解析出的文本结果送到RAG或生成环节。为什么这样设计因为大多数问题其实用不到完整的Agent推理链。统计我们线上系统大概70%的请求都只是知识问答直接走RAG足够了。剩下30%需要工具调用或复杂逻辑才值得引入Agent。如果所有请求都让Agent自由发挥不仅Token成本高而且失败率也明显上升——模型一旦在一个无关的步骤上较真整个链条就绕进去了。5.3 工程上的稳健做法融合系统最怕“定位不了问题”。RAG检索错了、Agent工具调错了、多模态识别错了最后都表现为“用户收到一个错误回答”。怎么排查我们的经验是做“调用链追踪”。我在系统里加了统一日志中间件每一个请求进来都给一个请求ID记录这个请求经历了哪些模块、每个模块花了多长时间、返回了什么中间结果。比如一个请求最终回答是“未找到相关资料”看一眼日志就能判断是检索没召回到正确文档还是模型没按检索内容生成。正是这个调用链日志帮我们在一次客户问题中快速定位到多模态模块把一份PDF表格识别错了才导致后续RAG检索完全走偏。第二点尽量把“评估”贯穿在每一步。RAG阶段评估检索召回率和命中率Agent阶段评估工具调用正确率和任务完成率多模态阶段评估抽取字段准确率。三个模块的评估是独立的单独出问题单独改不会互相推锅。第三点灰度上线和回滚机制。对于Agent这种不可控模块我们的做法是先只让它在5%的流量里生效观察一周的错误率和用户反馈再逐步放量。多模态模块如果换了新模型也要先在离线数据集上跑一遍指标对比确认没有明显回退再切线上。这套流程不能少一旦正线上跑着跑着突然大面积错误压力会很大。6. 常见问题速查与选型建议6.1 一张表看懂三大技术怎么选有不少朋友在选型时容易钻牛角尖“我们是不是应该做个Agent”实际上技术选型应该先看问题和场景。我把最常见的场景和技术选型整理成了下面这张表格希望能帮你快速判断业务场景推荐技术为什么企业知识库问答制度、产品文档RAG回答基于私有知识需要可追溯、可更新实时信息查询天气、股价、新闻Agent 工具调用模型知识过期必须靠外部API拿实时数据客服机器人FAQ为主RAG 规则兜底大部分问题可检索固定知识少量问题人工/Agent兜底表格/票据/截图信息提取多模态输入是图片必须先理解图像内容自动周报/日报生成Agent需要主动调用多个内部系统并汇总图文混合文档问答多模态 RAG先识别图片再检索文档二者结合复杂业务流程自动化Agent 规则引擎需要规划、工具调用、异常处理大部分情况下你的第一个系统不建议一上来就做全功能融合。先解决最痛的那个场景跑通之后再扩展。6.2 部署与成本的一些经验关于模型部署一个常被问的问题“应该调API还是自己部署开源模型”我的看法是分阶段考虑。项目原型验证阶段直接用API是最高效的能快速验证核心链路不用操心硬件和部署。当项目准备进入生产且满足以下任一条件时建议考虑私有化部署一是数据敏感不能出域二是请求量大API成本高到不可接受三是对时延有严格要求的实时交互场景。私有化部署的隐性成本容易被低估GPU服务器费用、运维人力、模型升级迭代的重新评测。我在某项目里做过对比一个日请求量几千次的中型应用调API的月成本大约几千元私有化部署一次性硬件投入几十万甚至更多。业务量没有足够大之前调API是更划算的选择。开源和商业API怎么选开源的优势是可控、可定制、私有化劣势是性能和效果往往需要自己调优。商业API的优势是效果好、稳定性高劣势是费用和数据合规。建议的做法是“混合路线”常规文本走商业化API数据敏感且高并发的走私有化开源模型图片识别类任务则单独评估选型。6.3 给新手的入坑路径经常有朋友问我“我刚开始学大模型应用开发应该先学RAG还是Agent还是多模态”我的建议是先RAG再Agent最后多模态融合作为进阶目标。为什么先RAG因为RAG的技术栈最轻流程最直观学习曲线最友好。你只需要了解文档切分、向量化、向量检索、Prompt拼接就能做出一个让自己有成就感的知识库问答Demo。这个过程中你会自然理解Embedding是什么、向量是什么、相似度检索是什么。这些前置知识学完之后再看Agent会轻松很多。学Agent时我建议不要一开始就套用重型框架。先用模型自带的结构化输出能力写一个只有单个工具调用的最小循环理解“模型决定调工具 - 程序执行工具 - 结果回传”这个闭环之后再去看各种框架封装了哪些能力。框架能提升效率也能让你错过细节。前期手写一遍后期用框架会很有底气。多模态的学习相对独立可以随时穿插进来。先把图片输入方式在API上跑通再思考“图片转成文本后如何结合RAG”这种跨模块问题。当你三个单项Demo都做过一遍就可以开始想融合架构了。还有一条前置知识建议一定要熟练Python至少要会写函数、会用字典和列表、会处理JSON。大模型应用开发的大量胶水代码都是在做数据格式转换不懂基础语法会处处碰壁。我最近带的一个新项目正好是在边缘场景里把这三者揉在一起用户上传一张产品照片系统先多模态识别出产品型号再去RAG知识库里检索对应说明书最后通过Agent调用一个库存查询接口告诉用户这个产品有没有现货、在哪买。整个流程看起来一气呵成但我很清楚它背后每一个环节都踩过不少坑。如果你正准备在自己的项目里用上这三项技术我的建议只有一条先别急着做复杂的融合找一个最痛的单点场景用最简单的方式跑通闭环。跑通之后你会发现后面的优化和扩展都有了可以站稳的抓手。