企业官网建设流程全解析

1. 从"金鱼脑"到"老搭档"：Agent 记忆与知识库到底在解决什么

做 Agent 开发的人，大概都经历过这样一个阶段：Demo 跑得飞起，一旦进入真实场景就原形毕露。用户第一轮说"帮我查一下上个月华东区的销售数据"，Agent 干得漂亮；第二轮说"那把它按品类拆一下"，Agent 一脸茫然——"它"是什么？上个月？华东区？全丢了。这就是典型的无状态 Agent，每一轮对话对它来说都是全新的世界，像一条只有七秒记忆的金鱼。

这个问题的本质，不是模型不够聪明，而是上下文没有被工程化地管理起来。大模型的上下文窗口再大，也架不住多轮对话的累积、跨会话的延续、以及海量私有知识的注入。于是就有了两条主线：一条是记忆（Memory），解决"记住对话和历史"的问题；另一条是知识库（Knowledge Base / RAG），解决"知道外部专业知识"的问题。这两条线经常被混为一谈，但它们的定位、实现方式、失效模式完全不同。

我写这一章实战笔记，就是想把这套东西从概念到落地讲透。适合谁看？如果你正在做 Agent 开发，被"它记不住""它答不准""它胡编"这三座大山压着，那这篇就是给你准备的。我会从记忆的分层模型讲起，拆到短期、长期、永久记忆各自怎么实现；再讲知识库和 RAG 的工程细节，包括分块、检索、重排、以及 RAG 和 MCP 这类容易混淆的概念边界；最后落到选型和避坑上，把我在真实项目里踩过的坑一个个摊开。

先给一个总纲，方便你建立心智模型：

这张表是我整个实战笔记的骨架。接下来每一块我都会展开，讲清楚"为什么这么设计"以及"实际怎么落地"。

2. 记忆的分层设计：短期、长期、永久到底怎么切

很多人一上来就问"用哪个记忆框架"，这其实是个伪命题。框架是结果，不是起点。你得先想清楚：你的 Agent 需要记住什么？记多久？以什么形式记？想清楚这三个问题，选型自然就出来了。我习惯把记忆切成三层，这个切法不是教科书规定，而是从工程实践中总结出来的——因为这三层的存储介质、更新频率、检索方式天然不同。

2.1 短期记忆：对话缓冲区的三种压缩策略

短期记忆就是"当前这轮会话"的上下文。最朴素的做法是把所有历史消息原封不动塞进 prompt，但这在几轮之后就会撑爆窗口，而且成本飙升。所以短期记忆的核心命题是：如何在有限窗口里保留最相关的信息。

我实测下来有三种策略，各有适用场景：

• 滑动窗口（Sliding Window）：只保留最近 N 轮对话。实现最简单，缺点是会丢掉早期的关键信息。适合任务导向、上下文依赖短的场景，比如客服问答。
• 摘要压缩（Summary Buffer）：当对话超过阈值时，把早期对话交给模型总结成一段摘要，保留摘要 + 最近几轮原文。这是我最常用的方案，兼顾了信息保留和窗口控制。
• 关键信息抽取（Entity Memory）：不保留原文，而是实时抽取对话中的实体和事实，存成结构化键值对。适合需要精确记住"用户叫张三、预算 5 万、截止日期 3 月"这类硬信息的场景。

这里有个容易忽略的细节：摘要压缩的触发时机。如果你每轮都触发摘要，成本高且容易累积误差；如果等到快撑爆才触发，又可能来不及。我的经验是设置一个"水位线"，比如窗口占用到 70% 时触发一次摘要，把最老的一半对话压缩掉。这样既平滑又可控。

注意：摘要压缩是有损的，多次压缩会像复印件的复印件一样越来越模糊。所以关键事实一定要单独抽出来存进长期记忆，不能只依赖摘要。

2.2 长期记忆：向量检索与结构化档案的配合

长期记忆要解决的是"跨会话"的问题。用户今天说了一次偏好，明天再来，Agent 应该还记得。实现上主流是两条路：向量化存储和结构化存储，而且往往是配合使用。

向量化存储的思路是把每一条记忆（一句话、一个事实、一段对话）转成 embedding，存进向量库，需要时用语义相似度检索出来。它的优势是能处理模糊的、语义相关的召回，比如用户问"我之前提过的那个预算"，向量检索能匹配到"我的预算是 5 万"。

但向量检索有个硬伤：它不精确。如果你要查"用户的确切生日"，向量检索可能给你返回一堆语义相近但事实错误的记忆。所以对于确定性事实，我强烈建议用结构化存储——直接存成 JSON 或数据库记录，用 key 精确查询。

我的实践方案是"双写"：一条重要记忆同时进向量库（用于语义召回）和结构化档案（用于精确查询）。检索时先走结构化拿硬事实，再用向量补充软上下文。这套组合拳打下来，长期记忆的准确率会明显高于单用任何一种。

2.3 永久记忆：系统提示与配置文件的固化

永久记忆是那些"永远不该变"的东西：Agent 的人设、核心规则、安全边界、领域常识。这部分不需要检索，直接固化在系统提示或配置文件里，每次请求都带上。

为什么单独拎出来？因为它和长期记忆的更新逻辑完全相反。长期记忆是"越用越多"，永久记忆是"基本不动"。如果你把核心规则也放进可检索的记忆库，就会出现"规则被检索遗漏"或"被新记忆覆盖"的风险。我见过有项目把"不能透露内部价格"这条规则放进向量库，结果某次检索没召回，Agent 就把价格说出去了——这是设计层面的失误。

永久记忆的维护要点是版本化。规则变更时不要直接改，而是保留版本记录，方便回溯"为什么某天 Agent 的行为变了"。这个习惯在排查线上问题时能救命。

3. 知识库与 RAG：从"能查到"到"答得准"的工程细节

记忆解决的是"记住交互"，知识库解决的是"知道世界"。这两件事经常被一起提，但知识库的工程复杂度其实更高，因为它涉及非结构化文档的处理链路。RAG（检索增强生成）是当前最主流的方案，但很多人对它的理解停留在"把文档切块、向量化、检索"这三步，真做起来才发现效果惨不忍睹。问题往往出在细节里。

3.1 分块策略：为什么你的检索总是召回垃圾

分块（Chunking）是 RAG 里最被低估的环节。我见过太多项目用固定的 512 字符切块，然后抱怨检索不准。分块的本质是在语义完整性和检索粒度之间找平衡：块太大，检索到的内容包含太多无关信息，稀释了相关性；块太小，语义被切断，检索到的片段答非所问。

我的分块原则是"结构优先，语义兜底"：

• 如果文档有天然结构（标题、章节、段落），优先按结构切，让每个块是一个完整的语义单元。
• 如果没有结构，用递归切分：先按段落切，段落太长再按句子切，句子还长才按字符切。
• 块之间保留一定的重叠（Overlap），通常是块大小的 10%~20%，避免关键信息正好卡在边界上被切断。

还有一个进阶技巧：给每个块加上下文头。比如一个块本身是"该季度增长 15%"，单独看不知道说的是什么。如果在块前面加上"文档：2024 年 Q1 财报 / 章节：营收分析"，检索和生成的质量都会明显提升。这个做法在业界叫"上下文增强检索"，实测对准确率提升很可观。

3.2 检索与重排：两阶段召回的必要性

单靠向量相似度检索，效果往往不够。原因是 embedding 模型擅长捕捉"语义相近"，但对"精确匹配"和"逻辑相关"不够敏感。比如用户问"退款流程第三步是什么"，向量检索可能召回一堆讲退款的段落，但未必精准命中"第三步"。

所以成熟的 RAG 都是两阶段的：

1. 召回阶段（Recall）：用向量检索 + 关键词检索（如 BM25）混合召回一批候选，比如 top 20。这一步追求"不漏"，宁可多召回。
2. 重排阶段（Rerank）：用一个专门的重排模型（Cross-Encoder 类）对候选重新打分排序，取 top 3~5 喂给大模型。这一步追求"精准"。

混合召回是关键。纯向量检索对专有名词、编号、代码这类"字面匹配"需求很弱，而 BM25 恰好补上这块。两者结合，召回率会明显好于单用其一。重排模型虽然增加了一次推理开销，但它把"相关性判断"从粗筛变成了精算，对最终答案质量的提升是值得的。

3.3 RAG 与 MCP 的边界：别把两件事混着做

这里必须澄清一个高频混淆点：RAG 和 MCP 不是一回事，也不该互相替代。

RAG 是一套"知识注入"的方法论，核心是检索 + 生成。MCP（Model Context Protocol）是一套"工具调用"的协议标准，核心是让模型能标准化地调用外部能力（查数据库、调 API、读文件）。一个是"给模型喂知识"，一个是"让模型用工具"。

实际项目里，两者经常配合：Agent 通过 MCP 调用一个"知识库查询工具"，而这个工具内部实现的就是 RAG 流程。所以正确的理解是——RAG 可以是 MCP 工具的一种实现，但 MCP 本身不等于 RAG。把这两个概念混着讲，会导致架构设计上的混乱，比如有人试图用 MCP 协议去解决分块和检索问题，那是南辕北辙。

4. 记忆框架选型：别被"框架"两个字带偏

聊完原理，回到大家最关心的选型。市面上记忆框架不少，但我必须先泼一盆冷水：没有哪个框架能开箱即用地解决你的记忆问题。框架提供的是"存储和检索的脚手架"，真正决定效果的是你的记忆抽取策略、更新策略和检索策略。选框架之前，先想清楚你的场景。

4.1 选型的四个判断维度

我通常从这四个维度评估：

• 记忆类型支持：是否同时支持短期缓冲、长期向量、结构化档案？只支持一种的，后期大概率要自己补。
• 检索能力：是否支持混合检索和重排？只给向量检索的，准确率天花板有限。
• 可控性：记忆的写入、更新、删除是否透明可干预？黑盒式的自动记忆，出问题时你无从下手。
• 集成成本：和你现有的技术栈（向量库、数据库、模型服务）是否好对接？

把这四个维度列成表，对着候选框架打分，比听别人说"某某框架最好用"靠谱得多。

4.2 自建 vs 用框架：一个务实的判断

我的建议是：原型阶段用框架快速验证，生产阶段按需自建或深度定制。原因很简单，框架帮你省的是"搭架子"的时间，但记忆策略是高度场景化的，通用框架很难刚好贴合你的需求。等你摸清楚自己需要什么样的记忆抽取和检索逻辑，往往会发现自建一个轻量模块比改造框架更省心。

自建的核心其实不复杂：一个向量库（存语义记忆）+ 一个关系库或文档库（存结构化记忆）+ 一套抽取和检索逻辑。难点不在存储，而在抽取逻辑的设计——什么时候该记、记成什么形式、什么时候该忘。这部分我后面会专门讲。

5. 实战踩坑：那些文档里不会写的教训

前面讲的都是"应该怎么做"，这一节讲"实际会怎么翻车"。这些坑都是我一个个踩出来的，写出来希望能帮你少走弯路。

5.1 记忆污染：错误信息一旦写入就很难清除

最坑的一类问题是记忆污染。用户随口说了一句错误信息，或者模型自己幻觉出了一个"事实"，被当成记忆写进了长期库。之后每次检索都会把它召回，Agent 就一本正经地胡说八道，而且你很难定位——因为从检索结果看，它"有据可依"。

我的应对方案有三层：

• 写入前校验：不是所有对话都值得记。只抽取明确的、用户主动陈述的事实，对模型推断出来的内容保持警惕。
• 来源标记：每条记忆都记录来源（哪次对话、哪句话），出问题时能追溯。
• 定期清理：给记忆加"新鲜度"和"置信度"字段，低置信度的记忆在检索时降权，长期未被验证的可以淘汰。

5.2 检索到了但没用上：上下文注入的位置很关键

另一个隐蔽的坑是：检索明明召回了正确内容，但模型就是不用。排查下来，问题往往出在上下文注入的位置和格式。

如果你把检索结果随便塞在 prompt 中间，模型可能"看不见"或者"不重视"。我的做法是：

• 把检索到的知识放在系统提示之后、用户问题之前，并用明确的分隔标记（如"以下是参考资料"）标出。
• 在系统提示里明确指示："优先基于参考资料回答，参考资料没有的再凭常识，并说明来源。"
• 如果检索结果之间冲突，明确告诉模型"以最新/最权威的为准"，而不是让它自己纠结。

这些细节看起来琐碎，但对最终效果的影响是决定性的。

5.3 成本失控：记忆和检索都是烧钱的

最后一个坑是成本。记忆抽取要调模型，检索要算 embedding，重排要跑模型，每一环都在烧钱。我见过项目上线后成本是预估的三倍，就是因为没做分层缓存。

我的优化手段：

• embedding 缓存：相同文本的 embedding 结果缓存起来，避免重复计算。
• 检索结果缓存：高频相同查询直接返回缓存结果。
• 记忆抽取降频：不是每轮都抽取，而是按需触发（比如检测到用户陈述了事实才抽）。
• 重排按需启用：候选数量少时直接跳过重排，省一次推理。

提示：成本优化一定要在架构设计阶段就考虑，事后补救往往要动大手术。

6. 把记忆和知识库串起来：一个可落地的组合方案

讲了这么多分散的点，最后我把它们串成一个完整的方案，你可以直接参考这个结构去搭自己的 Agent。

整体数据流是这样的：用户输入进来，先经过短期记忆模块组装当前上下文；同时触发长期记忆检索，把相关的历史事实召回；再触发知识库检索，把相关的专业知识召回；三路信息合并后注入 prompt，交给大模型生成；生成完成后，记忆抽取模块判断这轮对话有没有值得长期保存的内容，有则写入长期库。

这个流程里有几个关键设计点值得强调：

• 三路检索并行：短期、长期、知识库的检索互不依赖，可以并行执行，降低延迟。
• 统一的相关性排序：三路召回的内容最终要合并，需要一个统一的排序逻辑决定谁进 prompt、谁被截断。
• 写入的异步化：记忆抽取和写入不要阻塞主流程，异步处理，避免拖慢响应。

这套方案我在几个项目里跑过，稳定性不错。当然它不是银弹，具体参数（召回数量、重排阈值、摘要水位线）都需要根据你的场景调。我的建议是先跑通，再拿真实数据做 A/B，用数据说话，别凭感觉调参。

最后分享一个我个人的体会：记忆和知识库的价值，不在于"记得多"，而在于"记得准、取得对"。很多团队一上来就追求记忆量，结果召回一堆噪音，反而拖累了效果。先把检索精度做上去，再考虑扩大记忆规模，这个顺序不能反。