企业官网建设流程全解析

我去年底接手了一个企业级知识库问答助手项目，最初方案只用了RAG，后来被用户需求一步步逼到了RAG+Agent的组合上。回头复盘才发现，这不仅是技术选型问题，而是对大模型落地场景的一次重新理解。现在很多团队都在聊RAG、Agent、架构这些词，但真正把两者组合好、能在生产环境稳定跑起来的并不多。这篇就围绕这个核心组合展开，把设计思路、关键细节、实操过程和踩过的坑一起捋清楚，适合正在做大模型应用落地、智能客服、流程自动化或Agent开发的工程师参考。

1. 先搞清楚：RAG和Agent各自补什么短板

1.1 不是大模型不会，是它“记不住”“动不了”

抛开概念去看，单个大模型本身有两个致命短板。第一是知识时效性问题，模型训练完参数就冻结了，你问它最近三个月的新政策、内部系统的API字段、某个私有文档里的报价逻辑，它要么答不上来，要么一本正经地胡编。第二是能力边界问题，它可以写文案、总结代码、分析数据，但你让它去查一下数据库订单状态、调用CRM系统建个工单、自动把结果发到钉钉群，它做不到，因为模型本身只是一个“文本生成器”，不通网络、不连系统、不能执行动作。

这两个短板，恰好是RAG和Agent各自的主场。RAG解决“记不住”，Agent解决“动不了”。把两者组合在一起，等于给大模型装上了外挂知识库和手脚，这也是为什么RAG+Agent架构会变成大模型智能体落地的核心组合。

1.2 RAG：把外部知识变成可检索、可更新的记忆

RAG的核心逻辑不复杂，一句话就是“先检索，再生成”。把企业文档、操作手册、FAQ等非结构化文本切分成小块，用嵌入模型转成向量存进向量数据库；用户提问时，先把问题也转成向量，去库里检索最相关的片段；最后把这些片段连同问题一起交给大模型，让它基于给定材料作答。

以前纯粹靠模型死记硬背，RAG相当于把答案来源从模型参数内部转移到了外部知识库。好处很明显，知识可以随时更新，不用反复重新训练模型；回答可以被引用溯源，用户点开能看到依据来源，信任度完全不同；企业私有数据不出内网，合规上也安心很多。我随便拿一组数据来说明，常规RAG检索Top5片段给模型做上下文，很多业务问答的准确率能从纯模型的60%左右提升到85%以上，前提是检索质量本身过关。

1.3 Agent：把语言能力变成执行能力

Agent就更有意思了。它不满足于“答得好”，而是追求“办得到”。一个典型的Agent工作循环包括感知、规划、调用工具、观察结果、再规划，直到完成目标。

比如用户说“帮我分析一下上个月的销售数据，有问题就生成告警邮件发给相关负责人”。大模型单靠自身能力做不到，但Agent可以分解成几个步骤：检索知识库找到销售数据表的位置和字段说明，调用SQL接口查数据，让模型分析异常指标，调用邮件API发信，最后汇总结果反馈给用户。这个过程里每一步都对应一个工具调用，大模型扮演的是“大脑”的角色，负责规划决策，外部系统充当“手脚”。

Agent的价值在于把零散的工具串成一条按意图驱动的工作流。没有Agent的时候，一个业务流程对应一段硬编码逻辑；有了Agent，业务流程变成了模型的动态规划，系统的扩展性和适应性都上了一个台阶。

2. RAG与Agent怎么组合，架构长什么样

2.1 为什么要把RAG嵌进Agent而不是并列

我见过不少架构图把RAG和Agent画成两个并列的模块，左边一个RAG服务，右边一个Agent服务，互不干涉。这种设计在演示Demo时问题不大，做真实的复杂业务就会露馅。

核心原因在于Agent本身也需要知识，而且需要的知识种类远多于问答场景。Agent要规划任务，得知道当前有哪些可用工具、每个工具入参出参是什么样的；Agent要学会特定业务规则，比如“退货金额超过一万元必须人工审批”，这是模型参数里根本没有的内容；Agent在执行中途遇到问题，还要能查找解决方案。这些知识都放在同一个知识库里，让Agent在不同环节随时检索，才能让系统真正“懂事”。

所以正确做法是RAG作为Agent能力链路上的一环，嵌入到Agent的感知、规划、执行各个阶段，形成所谓的Agentic RAG模式。RAG不再是被动等待外部调用的接口，而是Agent主动使用的一个核心工具。

2.2 一套可落地的整体架构

我按生产环境标准给你一个我实际验证过的架构分层，从上到下分别是接入层、智能体层、能力层和知识层。

接入层负责对接多渠道，比如企业微信、钉钉、Web页面，统一把用户请求送进智能体网关。智能体层是核心，里面运行着Agent主循环，通常会用LangGraph之类的工作流引擎来管理Agent状态，也可以基于LangChain的Harness架构做二次开发，这类框架的好处是任务节点可编排、循环可控制、出错可以回溯。能力层挂载各类工具，包括RAG检索、SQL查询、HTTP API、消息推送、OCR识别等。知识层则负责统一承接数据，包括向量数据库、文档存储、结构化业务库，以及知识更新管道。

这个架构关键点在于每一层之间都通过标准接口通信。Agent不直接查数据库，而是调用一个工具接口；工具接口不直接实现业务逻辑，而是转发给后端服务。每一层都可以单独扩容，知识层性能不够就加检索节点，能力层要接新系统就加一个工具，不用动主框架代码。

2.3 主流程：感知—检索—推理—行动

把整个流程走一遍。用户提了问题之后，Agent进入规划阶段，它可能先用意图识别工具判断用户是想问答、查数据还是操作业务流程。

进入问答类任务时，Agent触发RAG检索工具，系统会做意图改写、生成多路查询词、在知识库中做混合检索，把返回结果交给负责答案合成的子Agent。进入操作类任务时，Agent需要先检索操作手册和工具说明，确认执行方式和参数规范，再调用对应工具。工具返回结果后，Agent观察结果判断是否达到预期，如果不够就重新调整方案继续，直到任务完成或者达到最大迭代次数。

这里插一句需要注意的地方：规划不是越多越好，幻觉型规划比不规划更可怕。如果你的Agent总在规划一些不存在的步骤，或者调用一些并不存在的工具，那多半是工具描述写得不够清楚，或者系统提示词里没有限制“只能使用列表中的工具”。我见过一个Agent在知识库里乱翻文档，硬生生把一条退款流程规划成了七个步骤然后挨个报错，最后靠预设的熔断机制才算刹住。

3. 关键环节的实操与踩坑记录

3.1 知识库建设：分块、嵌入、混合检索

知识库是RAG的地基，地基不牢，上面全白搭。第一步文档解析就要讲究，PDF要有OCR和版面分析能力，表格要单独处理，否则大量表格内容会在切分时被拦腰截断，信息就丢了。我自己做过一次实验，同一份产品参数表，用普通文本切分和用版面分析后结构化切分，同样问题回答准确率差出将近30个百分点。

分块参数不能拍脑袋定，需要根据实际文档做评测。一般推荐先定一个chunk_size区间，从500字符到1500字符各跑一批测试问题，看召回和生成质量，选出最合适的值。纯中文场景我会配一个200字符左右的重叠量，防止关键句被从中间切断。嵌入模型目前我个人比较推荐bge-m3这类中英双语模型，效果和兼容性都在线。

但向量检索不是万事大吉。向量检索擅长语义匹配，但对精确关键词、编号、型号、人名这类实体词经常翻车，比如用户搜“A3-120型传感器”，向量库里可能返回一堆语义相近但型号完全不同的内容。所以混合检索是必选项，BM25负责精确匹配，向量检索负责语义召回，两路结果用RRF或者加权方式进行融合，效果会有明显提升。

3.2 Re-ranking和上下文压缩，这一步别省

检索召回的Top结果里往往混着一些噪声片段，直接塞给大模型，它分不清主次，回答就容易偏。Re-ranking的作用是对召回结果做精细打分排序，把最相关内容顶上来。RAG系统加了bge-reranker这类模型之后，整体答案准确率普遍能再提3到8个百分点。

上下文压缩同样关键。一次检索可能召回6到10个片段，加起来好几千字，全塞给模型一是浪费Token，二是会稀释关键信息。我的做法是先做相关性截断，只保留得分靠前的片段；再做信息压缩，把每个片段里跟问题无关的废话删掉；最后按时间顺序和逻辑关系重组这些片段，构造成一个干净、紧凑的上下文。这样既省钱又提升效果。

3.3 工具调用、MCP与Agent记忆

Agent的能力强弱取决于工具多不多、工具描述写得好不好，而不是模型本身多聪明。每个工具定义里必须把功能、入参、出参、适用场景、失败时可能返回什么错误写清楚。工具描述是给模型看的说明书，写得太含糊，模型就会猜，一猜就容易用错。

今年以来MCP把工具调用标准化又推了一步。这里要区分清楚：MCP是模型上下文协议，解决的是Agent如何统一发现、连接和调用外部工具的问题，它是一个协议层；RAG解决的则是知识检索问题，是数据层。这俩不是替代关系，而是配合关系，MCP可以暴露一个RAG检索服务，让Agent像调用其他工具一样调用它。简单的理解，MCP统一了“连工具”的动作，RAG统一了“找知识”的动作。

Agent记忆也要区分内部记忆和外部记忆。短期记忆放在会话上下文里，记录当前的对话轨迹和中间状态；长期记忆用向量库存储，沉淀历史决策、用户偏好、常见问题处理方式等。长期记忆积累到一定量之后，Agent会越来越“懂你”，它给你推荐方案时会把历史偏好带进来。这个体验非常关键，用户会明显感觉到这个系统不是套壳聊天机器人。

3.4 Agentic RAG：几种常见的编排模式

先别急着追求复杂编排，从简单的模式开始逐步迭代才是正道。

第一种是Router模式，意图分类器决定走纯大模型回答、RAG检索回答还是工具调用通道。这种模式最简单，适合任务边界清晰的场景。

第二种是Corrective RAG模式，检索结果先做质量打分评估，不够格就自动改写查询词重新检索，或者直接让模型调用Web搜索补充信息。这个模式适合知识库覆盖不全的场景，能在一定程度上减少答非所问。

第三种是Self-RAG模式，模型先生成答案，再针对答案自评几个维度：是否忠实地基于文档回答，是否覆盖了用户隐含需求，是否需要进一步追问。如果自评不通过，就重新走检索和生成流程。这个模式效果最好，但Token消耗也最大。

我自己的建议是，第一版用Router模式跑通，然后再升级成Self-RAG，不要一上来就全量上复杂架构，否则问题出了你都不知道是知识库的问题还是编排的问题。

4. 从Demo到工程化：安装、配置与扩展

4.1 一个最小可运行版本怎么搭

既然要落地，就得有个能跑的骨架。我自己搭过得最快的一套RAG+Agent最小版本是用LangChain加LangGraph，向量库用的Milvus，嵌入和重新排序模型用BGE系列，大模型走OpenAI兼容接口，整体可以跑在单机容器里。

核心编排代码大致是这样：

from langgraph.graph import StateGraph, END from langchain_core.messages import HumanMessage, AIMessage def agent_node(state): # 规划：判断是否需要检索 plan = llm.invoke(f"根据用户问题判断是否需要进行知识检索：{state['question']}") if "需要检索" in plan.content: state["need_retrieval"] = True else: state["need_retrieval"] = False return state def retrieve_node(state): # 检索知识库 docs = retriever.invoke(state["question"]) state["context"] = format_docs(docs) return state def generate_node(state): # 基于检索结果生成回答 prompt = f"基于以下资料回答问题：\n{state['context']}\n问题：{state['question']}" response = llm.invoke(prompt) return {"answer": response.content} graph = StateGraph(AgentState) graph.add_node("agent", agent_node) graph.add_node("retrieve", retrieve_node) graph.add_node("generate", generate_node) graph.add_edge("agent", "retrieve") graph.add_edge("retrieve", "generate") graph.add_edge("generate", END)

一个Alpaca风格的工作流就出来了。别小看这个骨架，很多正式项目的业务逻辑版本跟这个差别不大，区别只是每个节点内部塞入了更多的错误处理和状态管理。

4.2 关键参数怎么调

网络上到处是“照着配就行”，但实际参数没调好，系统照样难用。我给几个重要的默认基线，你用的时候根据自己场景微调。

temperature建议设0.1到0.3之间，太高的随机性会让你连工具调用的参数都开始乱写。top_k建议20到50之间，既保证召回量又控制噪声。最大迭代轮次必须限制，初始阶段给5轮就足够，超过就熔断并转人工兜底。超时设置也不能忘，每个工具调用建议控制在15秒到30秒，整轮Agent任务控制在60秒内没完成就返回中间结果，不要让用户干等。

这些参数不是拍脑袋，背后逻辑是两个约束：一是大模型本身响应延迟叠加工具调用会产生雪崩效应，二是用户能接受的等待时间有限。控制好参数就是控制住用户体验的下限。

4.3 从单机到分布式：多路检索与多Agent协同

业务规模一大，单机服务肯定扛不住。分布式化通常从两个方向做。

知识检索侧，如果企业有多个部门、多套知识体系，不要全部塞进一个向量集合，而是按业务域拆分成多个Collection，由路由层按问题意图分发到不同的检索单元，再对各路结果做统一融合排序。这种方法能避免跨域检索互相污染，也能让每个检索单元独立索引更新。

Agent侧，复杂任务可以拆给多个子Agent协作。一个主管Agent负责任务拆解和结果汇总，几个子Agent分别负责知识问答、数据分析、工单处理。每个子Agent可以独立部署、独立扩容，主管Agent则要保证全局状态同步。LangGraph里GraphState的设计，就是服务于这类多Agent协作场景。

5. 常见问题与排查技巧实录

5.1 检索不准确、回答幻觉

这个是最多人问的，我通常会反问他三个问题。是不是只用了向量检索？查一下知识库分块有没有对表格内容做破坏？嵌入模型和业务语言匹不匹配？

解决方法顺着来就行：加上BM25做混合检索，把分块策略改成按版面元素切割，再换一批领域句子去做嵌入模型的选型评测。如果幻觉还出现，就在提示词里强制要求“没有检索到相关内容时直接说不清楚，禁止编造”。

5.2 Agent死循环或执行超时

Agent卡死通常不是程序Bug，而是规划路径里有个工具总在报错，模型又不断尝试重试，形成循环。我发现一个有用的排查方法：打开LangGraph的完整轨迹回放，把每一步的模型输入输出、工具调用参数、返回结果全部拉出来看，大概率一眼就能找到是哪个环节出了问题。

解决办法有两条腿。第一是给工具调用加重试开关和失败分支，工具报错两次就停止重试，转成人工提示；第二是给整个执行流程增加兜底节点，Agent循环超过N轮自动转人工接管。

5.3 知识更新与评估闭环

知识库不更新，系统过两周就凉了。我做了三件事，供你参考：一是文档录入即触发向量增量更新，不搞全库重建，省时省力；二是设置定时任务扫描源文档目录，检测到文件变更自动重新解析更新对应分片；三是每周抽一批真实用户问题跑一遍评估脚本，监控召回率、答案准确率和忠实度三个指标，指标低于阈值时自动告警。

关于评估补充两点。答案准确率可以人工标注评估，也可以让更强大的模型当评审员打分；忠实度指的是回答内容是否严格基于检索材料，这个指标防止模型套用内部知识编答案。

5.4 常见问题速查表

5.5 小成本试错的心得

最后说一个很实际的体会。不是每个团队都适合一开始就冲LangGraph加Milvus的大全套，我自己在另一个轻量项目里，单机版用FastAPI加Chroma加一个检索函数和一个生成函数，没有完整Agent框架，也撑住了几百个内部用户的使用。重点是先把知识库建好、把检索质量调好，再考虑编排复杂度。

把RAG和Agent组合做扎实，关键不在于框架多先进，而在于知识拆分得够不够细，意图路由够不够准，工具执行的反馈闭环够不够稳。工作流编排上去之后，再陆续把多Agent协作和分布式检索加上去，系统走到生产环境就没有那么慌了。

这套组合目前在我们内部已经稳定跑了近一年的时间，我最重要的收获就是：技术选型永远服务于业务目标。RAG+Agent架构的价值不是概念的炫技，而是它真实地解决了一个问题——让大模型不只是会说话，更能在企业业务里真正干成事。