企业官网建设流程全解析

1. 从"能跑通"到"敢上线"：这套应用到底在解决什么问题

大模型应用最尴尬的阶段，不是Demo跑不起来，而是Demo跑起来之后没人敢用。我见过太多团队花两周搭出一个能对话、能查知识库的原型，演示时效果惊艳，一旦要接入真实业务，问题全冒出来了：模型记不住上一轮说过什么，工具调用没有权限边界，谁在什么时候调了什么接口完全没记录，出了事连回溯都做不到。这套基于RAG、记忆、API和MCP构建的带鉴权审计应用，要解决的就是从"能跑通"到"敢上线"之间那段最难走的路。

先把四个核心件的关系理清楚。RAG负责让模型"知道"——把外部知识库的内容检索出来塞进上下文，解决模型知识陈旧和幻觉问题。记忆负责让模型"记得"——跨轮次、跨会话保留关键信息，解决对话断裂和个性化缺失。API负责让模型"能做"——通过函数调用去操作外部系统，比如查订单、发邮件、写数据库。MCP负责让模型"接得上"——用一套标准化协议把上面这些能力统一暴露给模型，避免每接一个工具就写一套胶水代码。

但光有这四个还不够。真正让应用能上生产的是鉴权和审计这两层。鉴权决定"谁能让模型做什么"，审计决定"模型到底做了什么、能不能查"。很多教程讲到RAG和工具调用就停了，鉴权审计一笔带过，结果就是应用永远停在内部试用阶段。这篇内容我会把这两层当成一等公民来讲，因为它们才是决定应用能不能交付的关键。

适合谁看？如果你已经用LangChain、LlamaIndex或者类似框架搭过RAG原型，能调通大模型API，但对"怎么加权限""怎么记录工具调用""MCP到底怎么落地"还比较模糊，那这篇就是写给你的。如果你是完全零基础，建议先把RAG的基本检索流程跑通再回来，因为这里会涉及不少工程细节。

提示：本文所有方案都基于常见工程实践推导，具体参数和选型需要根据你的业务规模、合规要求和现有技术栈调整，不要照搬。

2. RAG不是"塞进去就行"：检索质量决定应用下限

2.1 为什么你的RAG总是答非所问

RAG的原理听起来简单：用户提问，去知识库检索相关片段，拼进提示词，让模型基于片段回答。但实际做下来，十有八九会遇到"检索出来的东西跟问题不相关"或者"相关的内容没被检索到"。这不是模型的问题，是检索环节的问题。

最常见的坑是切分粒度。很多人把文档按固定字数切，比如每500字一块。结果一个完整的操作步骤被切成两半，检索到上半段却丢了关键的下半段。我的经验是，切分要跟着文档的语义结构走：Markdown按标题层级切，代码按函数切，FAQ按问答对切。如果文档结构混乱，那就用递归切分，先按段落，段落太长再按句子，尽量保证每块内容是语义完整的。

第二个坑是只用向量检索。向量检索擅长语义相似，但对精确匹配很弱。用户问"错误码401怎么解决"，向量检索可能返回一堆讲"权限问题"的段落，但真正包含"401"这个精确字符串的段落反而排在后面。解决办法是混合检索：向量检索加关键词检索（BM25），两路结果用倒数排名融合（RRF）合并。实测下来，混合检索的命中率比纯向量检索能高出20到30个百分点。

2.2 检索参数怎么调才不玄学

检索有几个关键参数，调不好就是玄学。我列一下我的常用起点和调整逻辑：

这里有个容易被忽略的点：重排（Rerank）。向量检索是"粗筛"，重排模型是"精排"。粗筛召回20条，用重排模型（比如bge-reranker这类）对每条打分，取前3到5条。重排模型比向量模型慢，但只对少量候选打分，总体开销可控，效果提升明显。我试过在同一个知识库上，加不加重排，答案准确率能差15%以上。

还有一个实战技巧：给检索结果加上来源标注。每块内容带上文档名、章节、更新时间。这样模型回答时能引用来源，审计时也能追溯"这个答案是从哪来的"。这在需要合规的场景里几乎是必须的。

2.3 知识库更新与失效处理

知识库不是建好就完事。业务文档会更新，旧内容会失效。如果知识库不更新，模型就会拿着过时的信息一本正经地胡说。

我的做法是给每块内容打上版本和时间戳，检索时优先返回新版本。同时维护一个失效标记，旧版本不删除但标记为失效，检索时过滤掉。这样既保留了历史可追溯，又不会让旧内容污染答案。

更新策略上，小规模知识库可以全量重建索引，大规模的要走增量更新。增量更新的关键是内容指纹：对每块内容算一个哈希，内容没变就跳过，变了才重新向量化。这样能把更新成本降下来。我见过一个团队每次更新都全量重跑，几万条文档要跑几个小时，改成增量后几分钟搞定。

3. 记忆系统：让模型记住该记的，忘掉该忘的

3.1 短期记忆和长期记忆要分开设计

记忆这块最大的误区是把所有历史对话都塞进上下文。这么做有两个问题：一是上下文很快被撑爆，二是无关信息会干扰模型判断。正确的做法是短期记忆和长期记忆分开。

短期记忆是当前会话的上下文，保留最近几轮对话。但不是原样保留，而是要做摘要压缩。比如每5轮对话做一次摘要，把摘要加最近2轮原文一起放进上下文。这样既保留了连贯性，又控制了长度。我常用的策略是：最近3轮保留原文，更早的用摘要替代。

长期记忆是跨会话的，需要持久化存储。这里的关键是记什么。不是所有信息都值得记。我的筛选标准是：用户明确表达的偏好（"我喜欢简洁的回答"）、重要的实体信息（"我的项目叫XX"）、未完成的任务（"下次继续讨论XX"）。这些信息抽取出来后存进向量库或结构化存储，下次会话开始时检索相关记忆注入上下文。

3.2 记忆的评分与衰减机制

长期记忆如果只增不减，很快就会变成垃圾场。我参考了一套记忆评分加时间衰减的机制，效果不错。

每段记忆有一个分数，初始分基于重要性（用户明确说的偏好分数高，随口一提的分数低）。每次被检索命中并实际使用，分数加一点。同时分数随时间衰减，衰减公式类似半衰期模型：score = score * 0.5^(days / half_life)。半衰期设成7到30天，看业务场景。这样久未使用的记忆会自然沉底，常用的记忆会浮上来。

检索时按分数排序，只取前几条。这样既控制了注入上下文的信息量，又保证了最相关的记忆优先。实测下来，这套机制比"全部保留"或"只保留最近"都要好，尤其在长期使用的场景里。

3.3 记忆与RAG的边界在哪

很多人会混淆记忆和RAG。简单说：RAG是公共知识，记忆是个人上下文。RAG查的是所有人都能访问的知识库，记忆存的是这个用户自己的历史。两者检索路径可以复用，但存储要分开，权限也要分开——A用户的记忆绝不能被B用户检索到。

在实现上，记忆检索和RAG检索可以走同一套向量检索流程，但记忆的命名空间要按用户ID隔离。查询时带上用户ID过滤，确保只检索到自己的记忆。这一点在鉴权章节还会展开，因为它是权限边界的一部分。

4. 工具调用与MCP：把能力标准化地接进来

4.1 从函数调用到MCP的演进逻辑

早期让模型调用工具，是直接在提示词里描述函数签名，模型输出JSON，代码解析后执行。这种方式能用，但每接一个新工具就要改提示词、改解析逻辑，工具一多就乱。后来有了函数调用（Function Calling），模型原生支持输出结构化的调用请求，省去了提示词工程，但工具的定义和注册还是各框架各搞一套。

**MCP（Model Context Protocol）**要解决的就是这个标准化问题。它定义了一套协议，工具、资源、提示词都按统一格式暴露，模型侧按统一格式调用。好处是工具提供方和模型使用方解耦：工具写一次，任何支持MCP的客户端都能用。你可以把它理解成"AI工具界的USB接口"——以前每个设备一个专用接口，现在统一成USB-C。

MCP的核心概念有三个：Tools（可调用的函数）、Resources（可读取的数据）、Prompts（预定义的提示模板）。实际落地时，Tools用得最多，Resources次之，Prompts看场景。

4.2 一个MCP Server的落地要点

写一个MCP Server，核心是把你的能力包装成标准接口。以查询订单为例，你需要定义工具名、描述、参数schema，然后实现执行逻辑。描述很重要，模型靠描述判断什么时候调用这个工具。描述要写清楚"这个工具做什么""什么情况下用""参数是什么意思"。

几个实战要点：

• 参数校验要在服务端做。不要信任模型传来的参数，类型、范围、必填项都要校验。模型偶尔会传错类型或者漏参数。
• 超时要设。工具执行可能卡住，必须设超时，超时后返回明确的错误信息让模型知道。
• 错误要结构化返回。不要直接抛异常，返回{success: false, error: "订单不存在"}这样的结构，模型能理解并据此回复用户。
• 幂等性要考虑。如果工具是写操作（比如下单），要防止模型重复调用导致重复下单。可以用请求ID做幂等。

MCP Server可以本地跑（stdio传输），也可以远程跑（HTTP/SSE传输）。本地适合个人工具，远程适合团队共享。远程的话鉴权就特别重要，不能让任何人都能调你的工具。

4.3 工具编排：多个工具怎么协同

单个工具好办，难的是多个工具协同。比如用户问"帮我查一下上个月的订单，如果有未发货的帮我催一下"，这需要先查订单，再筛选未发货，再调催单工具。模型能不能自己编排好，取决于工具描述是否清晰、上下文是否给足。

我的经验是把复杂流程封装成高层工具。与其让模型自己串联三个底层工具，不如提供一个"查询并催单"的高层工具，内部逻辑自己实现。这样模型只需要调一次，成功率和稳定性都高。底层工具留给需要灵活组合的场景。

另外，工具返回结果要控制长度。有的工具返回一大坨JSON，直接塞进上下文会挤爆窗口。做法是在工具层做裁剪，只返回模型需要的关键字段，或者返回摘要加一个引用ID，模型需要详情时再查。

5. 鉴权：谁能让模型做什么

5.1 鉴权要覆盖的三个层面

鉴权不是加个API Key就完事。在这类应用里，鉴权要覆盖三个层面：

第一层是用户鉴权：谁在跟这个应用对话。这决定了这个用户能访问哪些知识库、哪些记忆、哪些工具。用户A不能查用户B的订单，这是最基本的隔离。

第二层是工具鉴权：这个用户有没有权限调用某个工具。比如普通用户能查订单，但只有管理员能调退款工具。工具鉴权要在MCP Server侧做，不能只靠前端隐藏按钮。

第三层是数据鉴权：工具执行时能访问哪些数据。比如查订单工具，只能查当前用户的订单，不能查别人的。这层要在数据访问层做过滤，通常是在查询里强制加上用户ID条件。

三层缺一不可。我见过只做了第一层、工具层裸奔的应用，结果用户通过构造提示词让模型调用了管理员工具，直接越权。

5.2 权限模型怎么设计

权限模型不用一上来就搞RBAC那么复杂。小规模应用，一个简单的权限表就够：用户ID到工具列表的映射，加上数据范围。比如：

工具调用前先查这张表，没权限直接拒绝，返回明确的错误。拒绝信息不要泄露太多细节，比如不要说"你没有退款权限"，而是说"该操作不可用"，避免信息泄露。

权限判断要在服务端做，而且要在工具执行前做。不要等工具执行到一半才发现没权限，那样可能已经产生了副作用。

5.3 密钥与凭证的管理

应用要调大模型API、要连数据库、要调外部服务，这些都需要凭证。凭证管理最容易出的问题是硬编码——直接写在代码里，提交到仓库，泄露风险极高。

正确做法是用环境变量或密钥管理服务。本地开发用.env文件（记得加进.gitignore），生产环境用专门的密钥管理。凭证要定期轮换，尤其是怀疑泄露时立即轮换。

还有一个细节：日志里不能打印凭证。我见过日志把完整的API Key打出来，日志一泄露全完了。打印时要做脱敏，只显示前几位和后几位，中间用星号代替。

注意：调用外部API时如果遇到401错误，先检查凭证是否正确、是否过期、是否有空格或换行混入。这类问题排查起来很费时间，但原因往往很简单。

6. 审计：模型做了什么必须查得到

6.1 审计日志要记什么

审计的核心是可追溯。出了问题能查到"谁在什么时候让模型做了什么，模型调了哪些工具，返回了什么"。所以审计日志至少要记：

• 请求信息：用户ID、会话ID、时间戳、原始输入
• 检索信息：检索了哪些知识库、命中了哪些片段、相似度分数
• 模型信息：用的哪个模型、输入token数、输出token数、耗时
• 工具调用：调了哪个工具、参数是什么、返回什么、成功还是失败
• 最终输出：模型给用户的回复

这些信息串起来，就是一次完整的调用链路。出问题时按会话ID或用户ID一查，全流程清清楚楚。

日志的存储要考虑量和成本。全量存原始输入输出，量会很大。我的做法是：结构化字段全存，原始文本按需存（比如只存摘要，或者存一段时间后归档）。敏感信息要脱敏后再存。

6.2 审计与鉴权的联动

审计不只是事后查，还能实时风控。比如某个用户在短时间内大量调用敏感工具，或者频繁触发权限拒绝，这可能是异常行为，可以实时告警甚至临时封禁。

实现上，审计日志写入后可以接一个规则引擎，匹配到异常模式就触发动作。规则不用太复杂，几条就够：单位时间调用次数超阈值、敏感工具调用、连续权限拒绝。这些规则能挡住大部分明显的滥用。

审计日志本身也要保护。不能让普通用户看到别人的审计日志，也不能让用户删改自己的日志。日志写入应该是只追加的，不允许修改和删除。这在合规场景里是硬要求。

6.3 排查问题的完整链路

线上出问题时，排查链路是这样的：用户反馈"回答不对"，先拿会话ID查审计日志，看这次请求检索了什么、模型看到了什么、调了什么工具。常见的问题定位：

有了完整审计，这些问题都能快速定位。没有审计，就只能靠猜，效率差十倍不止。

7. 把这些拼起来：一个可运行的架构骨架

7.1 请求的完整流转

把前面几块拼起来，一次用户请求的流转是这样的：

1. 用户发消息，带上身份凭证
2. 鉴权层验证身份，确定用户权限
3. 记忆层检索该用户的相关长期记忆
4. RAG层检索知识库，重排后取top片段
5. 组装上下文：系统提示 + 记忆 + 检索结果 + 最近对话
6. 调用大模型，模型可能返回工具调用请求
7. 工具调用前做鉴权，通过后执行MCP工具
8. 工具结果回填上下文，再次调用模型生成最终回复
9. 全程写审计日志
10. 更新短期记忆，必要时抽取长期记忆

这个流程里，鉴权和审计是横切的，贯穿每一步。任何一步都要能回答"谁在做、有没有权限、做了什么"。

7.2 技术选型的取舍

选型上没有银弹，看你的团队和场景。几个常见组合：

• 轻量起步：LangChain/LlamaIndex + 向量库（如Chroma）+ 自建MCP Server。上手快，适合验证。
• 中等规模：LangGraph做编排 + 专业向量库（如Milvus/Qdrant）+ 独立MCP服务。可控性和扩展性更好。
• 大规模：自研编排层 + 分布式向量库 + 服务化MCP + 独立鉴权审计服务。灵活但成本高。

我的建议是从轻量起步，但把鉴权和审计的接口预留好。这两块后期补的代价很大，一开始就设计好边界，后面替换实现就行。

7.3 上线前必须过的检查项

上线前对照这份清单过一遍，能避开大部分坑：

• 检索命中率是否达标（用真实问题测，别只用构造的问题）
• 记忆是否会串用户（多用户并发测试）
• 工具鉴权是否在服务端强制执行（尝试绕过前端直接调）
• 审计日志是否完整（随机抽几次调用，看能否还原全流程）
• 凭证是否脱敏（检查日志和错误信息）
• 超时和降级是否处理（模拟工具超时、模型超时）
• 上下文超长是否处理（构造超长输入，看是否优雅降级）

这份清单里的每一项，我都见过因为没做而翻车的案例。尤其是工具鉴权和审计，出问题就是安全事故。

8. 几个我踩过的坑和对应的解法

8.1 上下文窗口被撑爆的连锁反应

有一次线上突然大量报错，提示上下文超长。排查发现是某个工具返回了超大JSON，加上检索片段和记忆，直接把窗口撑爆。模型调用失败，用户看到的是莫名其妙的错误。

解法是在每一层都做长度控制：工具返回裁剪到关键字段，检索片段限制总长度，记忆只取top几条。同时加一个总长度检查，组装完上下文后算一下token数，超了就按优先级裁剪（先裁记忆，再裁检索，最后裁历史）。这样即使某层失控，也不会直接崩。

8.2 记忆串用户的惊魂一刻

测试环境一切正常，上线后有个用户反馈"看到了别人的信息"。查下来是记忆检索时忘了加用户ID过滤，向量检索把别人的记忆也召回了。幸好发现得早，没有造成大范围影响。

这个坑的教训是：凡是涉及用户数据的检索，必须强制加用户ID过滤，而且要在数据访问层做，不能靠调用方记得传。我后来的做法是把用户ID作为检索函数的必填参数，不传直接报错，从接口层面杜绝遗漏。

8.3 工具重复调用的幂等处理

模型有时候会重复调用同一个工具。比如查订单，模型可能连续调两次。查询类工具无所谓，但写操作就麻烦了。有次测试退款工具，模型重复调用导致重复退款，虽然测试环境金额小，但暴露了问题。

解法是给写操作加幂等键。每次工具调用生成一个唯一ID，服务端记录已处理的ID，重复的ID直接返回上次结果，不重复执行。幂等键可以由会话ID加工具名加参数哈希生成，保证同一请求重复调用只执行一次。

8.4 审计日志写入失败的降级

审计日志很重要，但如果日志服务挂了，不能因此让整个应用不可用。我的做法是审计写入异步化加本地缓冲：日志先写本地队列，后台异步刷到存储。存储挂了就暂存本地，恢复后补写。这样审计不阻塞主流程，同时尽量保证不丢日志。

但要注意，鉴权不能降级。鉴权失败必须拒绝请求，不能因为鉴权服务挂了就放行。这是安全底线，宁可不可用也不能不安全。

9. 后续可以继续深化的方向

这套骨架跑通之后，还有不少可以深化的地方。GraphRAG可以处理需要多跳推理的问题，把知识图谱和向量检索结合，适合关系复杂的知识库。Agentic RAG让模型自己决定检索策略，什么时候检索、检索几轮、要不要换查询词，适合问题类型多变的场景。多模态把图片、表格也纳入检索，适合文档类型丰富的知识库。

但我的建议是不要一上来就追新。把基础的RAG、记忆、鉴权、审计做扎实，比堆一堆花哨功能更有价值。我见过太多应用功能列表很长，但基础体验一塌糊涂，用户用两次就跑了。先把核心链路做稳，再考虑锦上添花。

最后分享一个我自己的体会：这类应用的质量，八成取决于工程细节，两成取决于模型能力。模型再强，检索不准、记忆串号、权限裸奔，应用就是不可用。反过来，模型一般但工程扎实，应用反而稳定可靠。所以别把精力全花在换模型上，多花点时间打磨检索、记忆、鉴权、审计这些"不性感"但决定成败的环节。