企业官网建设流程全解析

1. 为什么现在要同时盯住RAG、Agent和多模态这三条线

2025年大模型的应用形态已经和一年前完全是两个世界。单点调API的时代基本过去了，现在大家聊得最多的，不再是要不要用大模型，而是怎么把RAG、Agent、多模态这三件事组合起来，搭一套真正能落地、能扛住业务压力的系统。

这个标题里面三个关键词，其实代表了大模型落地三条完全不同的技术路径。RAG解决的是知识实时性和准确性问题，Agent解决的是复杂任务自动拆解和执行的问题，多模态解决的是数据形态多样化的问题。三者的关系不是互相替代，而是互相补齐。

我做过的几个真实项目里，早期最常用的是纯RAG方案，就是个知识库问答机器人。做到后面发现单纯的问答远远不够，业务方开始要求自动做报表、自动整理周报、甚至自动跨系统执行操作，这时候就必须引入Agent。再往后，输入从纯文本变成了截图、语音、PDF扫描件就得把多模态的部分接进来。如果你现在才开始学大模型应用开发，我的建议很直接：三条线都要碰，但要有主次。先以RAG为基础，再往上叠Agent能力，最后补充多模态输入输出的处理经验。

这篇文章不做那种泛泛的概念科普，我把三个方向拆开讲，从架构选型到代码细节，再把我踩过的坑和处理方案一并写上。适合准备做大模型应用落地、正在做技术选型或者已经接了内部知识库项目的读者，大部分内容是从真实项目里沉淀出来的，不是官方文档复读。

2. RAG的工程化落地：检索质量决定了回答质量的天花板

2.1 RAG的全部意义在于“不重新训练”也能拥有最新知识

先聊RAG，这个方向概念上不难理解，本质上就是把大模型的“记忆能力”外包给外部知识库。大模型的知识截止日期是训练时定死的，RAG通过检索外部文档，把相关内容塞进上下文，让模型拿着材料作答，既不更新权重，也不重新训练。

但工程化的RAG和Demo级别的RAG完全是两种难度。很多初学的人搭出来效果差，说检索不准，说是模型不行，其实大部分问题的根子都在切分、嵌入、召回、排序这四条链路上。

切分方式直接影响嵌入质量。我之前见过一个团队，直接用固定长度切分把PDF切成小块，结果一个完整业务术语被从中间切断，检索的时候根本匹配不上。后来改成按语义段落加滑动窗口的混合策略，命中率明显提升。

先给一张我常用的RAG链路图，用文字描述：

文档进入后，先做内容解析与清洗，区分出标题、正文、表格、页眉页脚，然后按结构块进行语义切分，再经过嵌入模型转成向量，写入向量库。查询到来时，先用同样的嵌入模型把问题向量化，在向量库里做近似检索，同时配合关键词做BM25召回，两路结果做重排，最终把Top-K内容拼进Prompt交给大模型。

这里面检索方式的选择很关键。只做向量检索在处理专业术语、代码片段、编号类问题时经常翻车。比如用户问“关于2024年第三季度的销售总额是多少”，如果文档里写的是“Q3销售额”，向量相似度可能拿不到，反而被语义上相近的其他内容带偏。

我现在的项目里基本都用混合检索，两路召回的结果再丢给重排模型。重排这个步骤很多人会跳过，觉得没必要，但实测下来效果差异非常大。向量召回的Top-20经常混着不少噪声，只有经过交叉编码器精排，才能把真正和问题强相关的内容顶到最前面。

2.2 文档切分必须跟着版式结构走，不能一刀切

切分这件事说简单也简单，说难也确实藏了不少细节。粗糙的就是按字符数切，比如每500个字切一段，加上100个字的重叠。问题是这种切法根本不理解内容的边界在哪里。

我踩过比较典型的一次坑是处理一份产品手册，里面包含几十张规格表格。固定长度切分之后，表格被砍成两半，上半部分是表头，下半部分是数据行，检索时经常只召回到半个表格，大模型拿着残缺的数据做推理，结果自然跑偏。

后来我换了一条思路，按版面结构切分。对于PDF，先用版面分析把每一页识别成多个块，包括正文块、表格块、标题块，然后针对不同块类型用不同的策略。正文按段落和标题层级聚合，表格则尽量保留完整，一个表格宁可一整块存入，不要因为长度超限强行切开。

还有一个点容易被忽略，就是图片和表格里的信息。很多企业资料里的关键信息，内容是以图片形式存在的，直接做文本抽取会完全丢失。现在主流的做法是接一个多模态模型，把图表识别成结构化文本或Markdown表格，再走后续流程。这就是为什么多模态和RAG要在同一个系统里配合，而不是两个孤立的能力。

切分的经验可以简化成一句话：宁可单元大一点，也别切碎语义。所谓Token超限的问题，可以用后续的重排和摘要来解决，但切碎了就补不回来了。

2.3 嵌入模型和向量库的选型逻辑

嵌入模型的选择，直接影响检索的召回上限。目前主流的嵌入模型基本分成三类——通用型、中文优化型和领域微调型。通用型适合起步验证，中文优化型在中文场景下明显更稳，领域微调型则适合专有名词特别密集的场景。

如果你做的是企业内部知识库，我的建议是先用通用或中文优化模型跑通全流程，再用业务数据做效果评测。不要在起步阶段就急着微调嵌入模型，因为你连baseline都没有，拿到结果也不知道好坏。

向量库的选择也要看场景。数据量在几十万级别以内，用轻量级的向量库就够了，部署和维护成本低。到了千万级以上，同时要求毫秒级响应，就要考虑分布式的向量数据库。要注意的是，向量库不只是存向量，还承担了元数据过滤、混合检索、高并发查询这些职责，选型时要看整体能力，不能只看向量检索速度。

我常用的组合是：中等规模项目用轻量级方案，数据量几条数据级别，单体部署，处理几百万条向量没问题。到了更大规模再上分布式方案，通过分片扩展。这个路线的好处是前期轻，后面扛不住了再平滑迁移。

2.4 RAG效果调优的评测方法和实用经验

接入RAG之后，最容易陷入的误区是用“感觉”调优。发现回答不对，就换一个切分参数或者换个嵌入模型，但没有评测体系，根本不知道改动是变好还是变坏。

标准做法是准备一个评测集，包含测试问题、标准答案、相关文档ID。每次改动后跑一遍评测集，看召回率、命中率和最终回答的准确率。这个评测集不用太大，二三十条高质量问题就够发现大部分问题，关键是覆盖不同类型，包括事实查询型、推理型、比较型和否定型。

我把自己调优过程中的几类常见问题整理一下，方便你排查时对号入座：

调优顺序上，我建议先从检索侧入手，确保召回内容本身是准的，再去优化Prompt。检索侧的事情没做好，Prompt写得再漂亮也没有用。

3. Agent的设计核心：任务拆解比模型选择更值得投入

3.1 从单轮问答到自主执行，Agent的关键能力是“拆”

RAG做的是“回答”，Agent做的是“执行”。如果你拿到的需求是帮我写一份季度分析报告、帮我排查系统异常并给出处理建议，这不单纯是问答能够覆盖的，更需要一个智能体把大任务拆成子步骤、逐个调用工具、中间进行决策修正，最后归并结果。

Agent的本质是让大模型承担“规划者”的角色，而不是全部答案的来源。大模型负责理解目标、拆解步骤、判断需要调用什么工具，具体的操作逻辑由工具来负责。这里引出一个核心原则：模型做判断，代码做执行，不要什么活都丢给模型做。

比如说一个常见的需求，让Agent自动收集多份文档中的信息并汇总成表格。正确写法是，先用API工具批量把文档读取出来、做文本解析，把结构化数据交给模型做格式整理和归纳。错误写法是，直接把几百页文档塞进Prompt，让模型一边读一边理解一边输出，结果不仅是Token费用爆炸，而且模型在长上下文里的信息利用率非常低。

这也是很多人做Agent失败的原因：设计上把大模型当成了万能执行器。实际上，凡是能用确定性代码解决的问题，就不要让模型自由发挥。模型的位置应该在任务拆解、工具选择、结果判断这几层上。

3.2 工具调用是Agent的“手”，工具协议的选型直接决定扩展性

Agent要真正落地，工具调用协议是绕不开的。目前主流的实现方式是Function Calling，模型在推理时输出结构化的工具调用请求，由应用层负责找到对应函数并执行，再把执行结果返回给模型继续推理。

定义一个工具时，关键是给模型提供足够清晰、无歧义的描述，包括工具用途、参数含义、返回结构。模型不靠看代码理解工具，它靠的是描述和参数schema推测工具能力，描述写得含糊，调用成功率就惨不忍睹。

举一个普遍遇到的例子：一个处理订单的工具函数query_order，参数定义为order_id。如果描述里没有说明“订单号是数字型、在订单管理页面可查询”，模型在对话中提取参数时很容易把用户说的“帮我查一下昨天那笔订单”中的时间信息当成订单号传进去。真正正确做法是参数描述里明确指向性强的内容，如果上下文里无法确定就触发追问，不允许猜测填入。

工具数量多了以后，还要考虑工具调用的冲突和顺序问题。我见过的情况是Agent在连续调用两个工具时，把第二个工具需要的参数拿错了，比如获取用户信息后，再用用户ID去查工单的时候ID字段选错。这种问题没有银弹，只能靠设计阶段让工具间边界清晰，同时在验证阶段引入模拟用户对话测试，把链路走顺。

3.3 Agent循环的稳定性：记忆、上下文压缩与失败重试

Agent在一次任务执行中可能会发生多轮工具调用，每一轮都要带着新的结果继续推理。如果对话全程都保留原始历史，上下文越来越长，最终会导致延迟升高、费用上升，更严重的是模型在超长上下文中迷失重点，忽略早期设定的指令。

所以要给Agent设计“记忆管理”机制。我的常用做法是分层设计，任务本身的原始目标和工作流上下文保留在一层，过程中产生的中间结果放进短期记忆区，执行完成后重写为摘要存入长期记忆。模型当前看到的是压缩后的关键信息，而不是全部流水账。

另外一个必须处理的问题是失败重试。工具调用不是每次都成功，可能是网络超时、权限不足、参数校验失败，也可能是模型推理错误导致乱传参数。Agent循环里必须包含重试逻辑，但要注意：模型自己重试时，如果不断使用同样错误的参数，是有问题的。建议在重试逻辑里加入错误信息反馈，让新模型看到“上一次调用失败原因是什么”，这样才有机会修正自己的行为。

实际项目中，我把重试次数限制在两次以内，连续失败就直接抛给人工处理，然后记录日志用于后续分析。这个逻辑在线上运行了几个月，大部分故障都能在重试环节被吸收，但依然会出现少数模型纠缠在错误路径上的情况，人工接管兜底必须有。

3.4 用更轻的方案搞定Agent落地，不一定要重型框架

很多初学者一上手就引入全套Agent框架，把图编排、状态机、语义路由全部拉进来，结果项目复杂度比业务逻辑本身还要大。Agent化改造的正确姿势应该是按需引入，从最简单的方案开始。

最简单形态就是写一个循环调模型的脚本，五到六次迭代以内可以处理简单的任务。到需要多个工具协同、有条件的多分支跳转时，再引入统一工作流引擎。有没有必要引入框架取决于你的场景有没有并发要求、需不需要可视化运维监控。

我个人的建议是，初始验证阶段，手动管理对话循环加工具注册表就够了，侧重验证模型对工具调用的准确率和任务完成的稳定性。框架类工具更多是锦上添花，可以在项目跑通以后再看哪块功能真正需要。

4. 多模态技术落地：输入LLM化与输出结构化是关键增量

4.1 多模态不是“看图说话”，而是把视觉听觉信息变成可被计算的结构化数据

多模态大模型听起来炫酷，但在大部分真实业务场景里，它的价值不体现在“识别图像里有什么”，而是体现在“把一张图、一份扫描件、一段语音，变成下游系统能直接使用的结构化数据”。

我举一个具体例子，一套面向企业内部的服务工单系统，用户提交的问题里经常带着截图和照片，比如系统报错截图、网络拓扑图、拍摄的设备故障照片。过去纯文本方案只能处理描述文字，图片信息全部丢失。后来在工单接入链路里加入多模态模型，图片先被识别成文字描述，再与文本描述一起送入基础模型进行分类和摘要提取。实测下来，不少问题在人工介入前就能自动识别出故障类型并给出处理建议，工单分发的准确率有了明显提升。

这就是“输入LLM化”的核心思路：在渠道层就把各种非结构化数据转化成人机都能理解的结构化文本，上层的RAG和Agent不需要处理原始图片和音频，直接用转换后的信息做检索、推理和执行。

与此对应的还有“输出结构化”。多模态模型不仅要只接收图片，还要能输出可用的结构化结果，比如把表格图片识别成Markdown、把流程截图识别成步骤列表、把票据照片识别成字段JSON。这个能力在RAG链路里特别有用，前面提到的表格整体识别入库，靠的就是这一个环节。

4.2 多模态模型的选型标准与实际应用场景的匹配

选多模态模型，不能只看跑分。不同的业务场景对多模态能力的要求重点完全不一样。

表格识别场景，重点看的是复杂表格结构的还原能力，要能区分合并单元格、跨行跨列、多层表头。如果模型在表格结构上能力弱，识别结果会丢行列关系，下游转成结构化入库后数据乱套。

长文档扫描件场景，重点看的是版面分析和OCR的综合效果，要能区分标题、正文、页眉页脚和图片注释，尤其对清晰度不高、背景杂乱的扫描件要有稳定的抗干扰能力。

视觉问答场景，比如对着产品图问某个部件的位置，重点看的是定位描述能力和细节判别能力。这类问题对模型的细粒度感知要求高，有些模型连图中文字都读不准，更别提做空间关系的推理了。

我的选型流程是，先明确自己业务里最多的输入形态是哪几种，再去挑模型。多模态模型的推理成本普遍高于纯文本模型，尤其图片Token消耗量大，所以能用小型专用模型完成的任务，就不要动不动上超大杯多模态大模型。

还有一点容易被忽略，就是模型的上下文长度限制。多模态能力的引入会大幅增加Token占用，图片被Token化之后消耗很高，如果模型上下文窗口不够大，做完识别后再拼入其余信息就可能超限。所以设计流程时要合理安排，把识别、结构化、再处理分成多个阶段，避免一次性把大量图片信息塞进一个模型会话。

4.3 图像预处理对识别效果的影响，比换模型更明显

在实践中，我发现一个现象：很多人觉得识别不准就该换更强的模型，但真正的问题出在图像的预处理环节。扫描件的识别效果不好，直接交给模型是不行的，需要先做基础处理。

图像预处理我常用的步骤包括旋转校正、去噪、增强对比度和边缘锐化。尤其是拍摄的文档，存在透视变形和光照不均的情况，直接识别容易出错。先用算法把图片转成近似正视角度的扫描效果，识别准确率会明显提升。另外，低分辨率图像先做超分放大再识别，细节信息的保全程度远高于直接用小图识别。

这类图像预处理的能力，很多开源图像处理库都能提供，不需要自己搭复杂的视觉模型。但要注意的是，预处理虽然能带来提升，也不要做过头。过度增强、过度锐化会产生伪影，反而把文字边缘弄得一塌糊涂，识别率下降。

多模态的处理链路在工程上分得细一点没有坏处，甚至可以拆成独立的微服务。前一步的输出作为后一步的输入，每步都有独立缓存和日志，处理链路出问题时，排查起来非常直观。

4.4 多模态与RAG、Agent组合的实际案例参考

用一个我调试过的模拟项目来串一遍组合逻辑，帮你建立整体感。这个项目的需求是，搭建一个面向售后场景的智能助手，用户上传故障设备拍照图片加一段文字描述，系统自动识别故障类型、检索相关处理文档、输出处理建议，并根据故障等级自动通知对应负责人。

整体链路拆成四层。第一层是输入预处理，图片做校正和增强，然后由视觉模型识别设备型号、故障部位和可见异常，输出结构化文本。第二层是用多模态能力处理说明书和工单手册，把PDF中的表格、流程示意图识别入库，形成RAG的知识底座。第三层是Agent编排，模型结合识别出来的故障信息，调用RAG检索相似案例和处理文档，再调用通知服务触发事件。第四层是兜底逻辑，识别结果置信度低或者检索不到相关内容时，自动转入人工服务队列，并把日志结构化保存用于模型迭代。

这个案例基本把三条技术线都串起来了。核心想表达的是，不要把它们当成三个割裂的功能模块，而是在真实业务问题前自然组合成一条流水线。

5. 架构设计与性能优化：把技术栈组合成可维护系统

5.1 一个可扩展的大模型应用系统的模块划分

当你的项目涉及RAG、Agent、多模态之后，单机脚本已经不够用了，至少需要做模块化拆分。我推荐的划分方式是按照能力边界分成四层。

接入层负责统一接收用户输入，完成文本、图片、音频的接收和预校验。处理层负责多模态预处理、文本清洗、格式归一化。业务编排层负责Agent的任务流程，调用工具、检索知识、拼装上下文。模型调度层负责对接不同的模型提供方，做模型路由、重试、限流和成本统计。

分层的收益是，模型供应商换了不影响上层业务逻辑，上游输入格式变了只动处理层，新增工具不影响核心链路。这个架构对中小团队来说足够清晰，扩展起来也顺手。

5.2 缓存、限流与成本控制，三个被忽视的必考题

聊技术方案的时候，性能指标经常被提得很高，但真上线之后，最先压力爆表的往往是资源和成本。

缓存策略上，同用户在同会话窗口内的重复问题应该直接命中缓存。用户问完隐私条款，紧接着又问了一遍，系统完全有条件不重新跑完整链路，直接返回上次结果，省掉模型的推理费用。

限流策略上，如果不做限制，个别高并发场景会把模型服务的配额打爆。我习惯在接入层做两层限流，外层按用户维度限制调用频率，内层按模型维度限制整体吞吐，超出就排队或降级返回通用了兜底答案。

成本统计也很关键，核心指标是单次交互成本和每月总成本。需要在日志系统里记录每次请求用了哪个模型、Token消耗多少、延迟多少。上线初期成本可能不明显，量级上来后，没有计量就只能看着账单发愁。

5.3 日志、监控与评测迭代，维护期真正依赖的东西

上线不是终局，而是开始。大模型应用在线上持续稳定运行，需要的周边系统比模型本身更重要。

日志要覆盖完整链路，包括用户原始输入、经过预处理后的输入、检索到的文档ID、模型调用参数、完整回复内容、耗时和Token消耗。这样任何一次异常回答，都能回溯是哪一环出了问题。

评测集要持续更新，把线上出现的语义模糊、工具调用失败、错误检索的案例沉淀成回归用例。这样每次调整模型参数或者Prompt之后，都快速验证已有能力没有被破坏。

性能监控上要重点盯三个指标：模型调用的TP99延迟、检索链路的P95召回耗时和Agent执行成功率。任何一项恶化都说明系统在退化，需要及时介入。

6. 真实场景中的高频问题和排查方法

6.1 上下文被“中间遗忘”，回答丢失关键约束

大模型在超长上下文里对中间部分内容的关注度会明显下降，这种情况业内很多人遇到过，模型开头记住了指令，结尾看到了最新信息，中间插入的关键事实反而被忽略。

排查时先看实际注入的上下文长度，再看关键信息所在的位置。解决手段有两个方向，一是把关键约束和指令信息在System Prompt里重复强化，二是把重要信息安排在上下文的开头和结尾区域。

6.2 检索质量高但回答质量低，问题多出在Prompt设计

有一种情况很让人困惑，检索结果明明已经很好地覆盖了问题，但大模型的回答仍然不准确。这时候问题基本出在Prompt侧的引导不够。

我自己的经验是，Prompt在RAG链路里的角色不只是把检索内容拼进去，还要告诉模型怎么使用这些材料，比如“如果检索内容与问题不相关，请直接说明无法根据提供的信息回答，不要自行推测”。没有这个约束，模型容易把文档里不相关的信息也硬扯进答案里。

6.3 Agent执行链路过长导致失败率高，怎么收敛

Agent执行过程中，调用链越长，单步失效的概率叠加在一起就会导致整体成功率急剧下降。我的收敛方法是，减少模型决策的节点，把确定性的步骤从模型手中拿回来，用代码写死执行流程，只在真正需要智能判断的分支保留模型决策。

另外一个处理方式是加自动检查点。每一步工具调用返回后，加一层简单的校验逻辑，返回结果是否符合预期格式，不符合就立即终止该分支，而不是继续往下执行。这样可以避免错误被后续步骤放大。

6.4 多模态识别结果的误差如何影响RAG答案的思考

如果多模态识别出来的内容本身是错的，那么无论下游的检索和生成多好，答案都会错。所以多模态环节不能被当作黑盒直接吞掉结果。

我的做法是在处理链路中给多模态输出增加置信度标记和人工抽检机制。当置信度低于一定阈值时，不直接进入结构化入库或者Answer生成，而是转人工确认。这个兜底成本不高，但能把大量隐性错误挡在系统入口前。

7. 几条从实战中沉淀的个人经验

如果你只打算记住这篇文章的一部分内容，我希望是下面这几条。

第一，先跑通最小闭环，再追求系统完善。不要一开始就搞复杂架构，选择一个业务场景，用最简单的RAG加一个工具调用，把流程跑通，再逐步叠加Agent和多模态能力。复杂系统在没跑通前，你根本不知道瓶颈在哪里。

第二，每一条能力的引入都要有明确的业务收益。如果某个场景用传统正则表达式或者规则引擎就能解决，就不要上模型。我发现过不少简单需求被生搬硬套上大模型的案例，效果不见得更好，成本和延迟却增加了。

第三，评测集是你的“质检员”。没有评测集就没有调优依据。宁可花时间先建二十条高质量评测问题，也不要凭感觉乱试参数。这个质检员会伴随项目的整个生命周期，每次改动都跑一遍，回报非常稳定。

第四，多模态放宽了眼界，但别变成负担。能用文字描述清楚的信息，就不要让用户上传图片然后在模型和图像处理上叠成本。多模态是补齐原有链路覆盖不到的盲区，不是替代所有输入方式。

踩过几次坑之后，我的整体感觉是，大模型应用的技术门槛已经明显降低了，真正拉开差距的是工程化的综合能力。把RAG、Agent、多模态在合适的场景里组合好，注意评测和成本，系统的稳定性和效果一定差不了。