Agent记忆与知识库搭建：从文件到RAG与知识编译实战

做 Agent 开发的人迟早会在同一堵墙上撞一次模型的上下文窗口撑爆追问不到历史信息回答开始靠猜。我早期做过一个客服类 Agent对话超过三轮之后它就开始忘记用户刚说过的需求更别提调用之前沉淀的业务知识。问题不在模型在记忆和知识库的设计。那之后我把精力从调 prompt转向了搭记忆体系摸清了文件、数据库、RAG 和知识编译这四件事各自该扮演什么角色。这篇文章就围绕 Agent 记忆与知识库展开从最基础的文件存储、结构化数据库到当下最热门的 RAG 检索增强生成再到很多人忽略但价值极高的知识编译环节每一步的选择逻辑、实操细节和踩坑记录我都会讲。适合正在做 Agent 开发的人也适合想搭建个人或团队知识库的朋友参考读完你会对整套体系有一个可以落地复现的完整认知。1. 先理清楚Agent 的记忆到底是什么1.1 别把记忆和上下文混为一谈很多人一上来就买大上下文窗口的模型恨不得一次塞进 20 万 token以为这样 Agent 就有记忆了。这是个典型的误区。上下文只是一次对话中临时加载的信息它是易失的会话一结束就没了。而记忆是跨会话、跨任务持续存在的信息结构。你要的是一个能对用户说我记得你上周提过那个需求的 Agent而不是一个只在这轮对话里不失忆的聊天机器。用上下文硬扛记忆代价是成本和延迟双高而且信息一多模型注意力分散召回质量反而下降。从工程角度看Agent 的记忆一般拆成三层工作记忆当前任务里必须握在手里的状态和数据、情景记忆历史对话、用户偏好、事件记录、语义知识事实、规则、概念通常来自知识库。工作记忆靠上下文窗口解决情景记忆靠存储系统解决语义知识靠知识库解决。三者用途不同技术选型也完全不同。1.2 记忆的四种实现形态顺着上面的分层实际项目里记忆大致有四种落地形态内存态跑在进程里存当前会话的临时状态用字典、Redis 之类进程一重启就没了。文件态把历史对话和行为记录落成 Markdown、JSON、JSONL 文件适合永久保存、人工审阅也方便接入 Obsidian 这类知识管理工具。数据库态用 SQLite、MySQL、PostgreSQL 存结构化数据适合记录用户档案、任务状态、统计信息查询能力强、一致性好。语义态把文本向量化之后放进向量库配合 RAG 在对话时检索最相关的历史片段和知识条目这是目前 Agent 记忆的主流实现。我在实际项目里很少只用单一形态。最稳的组合是文件做原始存档数据库做结构化索引和状态管理向量库做语义召回三层相互配合。别指望一个组件解决所有问题。1.3 记忆设计的核心指标写得到、查得着、读得对记忆系统的设计目标可以浓缩成三个能力写入场景覆盖全查询路径足够快读取内容足够准。写得到指的是 Agent 和用户交互的每个重要节点都要有落盘动作不能只靠日志要在业务逻辑里显式调用存储。查得着指的是检索入口要对齐业务场景比如按用户 ID、按时间范围、按知识分类。读得对最关键也最难检索出来的内容必须和当前问题语义相关不能拿一堆噪音塞给模型。后面讲 RAG 的时候我会专门展开读得对怎么做。2. 文件、数据库、RAG三种载体到底怎么选2.1 文件系统最原始也最灵活的底座文件是知识库的第一层地基。我见过不少团队一上来就上向量库结果原始文档散落在各种群聊和网盘里根本没有人维护源头。文件承载的应该是事实的原始形态产品文档、会议纪要、操作手册、爬取到的网页正文。纯文本、Markdown 优先PDF 和 Word 在解析阶段会带来大量格式噪音能转 Markdown 就转。以 Obsidian 为代表的个人知识库工具天然适合这种用法本地文件、双向链接、文件夹 Tag 组织加一个 Git 仓库就能做版本管理。文件的好处是透明、可控、离线可用出问题能用文本编辑器直接排查。缺点也很明显检索效率低、无法做复杂条件查询、容易产生大量重复副本。所以文件只适合做底座不适合做查询层。2.2 数据库结构化信息的可靠容器当记忆内容开始出现明确的字段结构时就该上数据库了。比如用户档案有姓名、邮箱、偏好任务表有状态、优先级、截止时间会话记录有 session_id、user_id、时间戳。这类数据塞进 Markdown 里就是灾难塞进 SQLite 里就是一条 SELECT 的事。SQLite 是我在中小型 Agent 项目里的首选单文件、零配置、支持标准 SQLPython 标准库 sqlite3 直接可用部署几乎无成本。数据量到几百万行之前它的性能足够。团队级项目再考虑 MySQL 或 PostgreSQL配合数据库同步工具把结构变更和备份链路管起来。PostgreSQL 还有 pgvector 扩展能在一个数据库里同时搞定关系数据和向量检索少维护一套系统这个优势在中小项目里非常明显。数据库解决的是精确查询解决不了模糊语义匹配。你想查用户上次抱怨过什么数据库得靠 LIKE 模糊匹配效果差还费资源。要处理这类需求就得把 RAG 请上场。2.3 RAG让 Agent 学会按语义找资料RAG检索增强生成的核心逻辑不复杂用户提问时先从知识库里检索出最相关的片段拼进 prompt 里喂给模型让模型基于检索结果作答。它解决的核心痛点是模型知识时效性差和专业领域知识缺乏的问题也顺带让答案可以溯源。我在项目里落地 RAG 时链路通常是这样文档切块 → Embedding 模型转向量 → 向量库存储 → 查询时向量相似度检索 关键词检索混合 → Rerank 重排 → 拼装上下文喂给模型。其中最容易出问题的两个环节是切块和重排后面实操部分细说。值得提醒的是RAG 不是把文档扔进向量库就完事。它需要持续维护文档更新了要重新切块和向量化检索效果变差要调参数甚至要换 Embedding 模型。那些把 RAG 当一次性工程的团队最后多半会得到一堆看起来像那么回事但答案经常不对的 Agent。2.4 三种载体的分工架构把三种载体拼在一起会得到一个我常用的分层架构原始层文件系统里的原始文档人工可读、可追溯是知识源头的唯一事实标准。结构化层数据库中的实体、关系、状态、统计为业务逻辑提供精确数据支撑。语义层向量库中的语义索引用于模糊问题和自然语言提问的快速召回。编译层经过知识编译后生成的工具描述、规则集、图谱结构直接喂给 Agent 决策。这套架构的好处是各层职责清晰某一层出了问题可以在不推倒重来的前提下单独修复。我见过只用向量库的全都要方案也见过只用数据库的结构化狂魔方案实测下来前者回答飘后者答非所问架构冗余一点反而更稳。3. 知识编译把零散信息变成 Agent 能真正用起来的知识3.1 知识编译到底是什么知识编译这个词听起来学术其实说的是一个很朴素的事把自然语言形态的原始知识转化成 Agent 运行时可以直接消费的紧凑结构。原始文档是给人读的段落有铺垫、有废话、有隐含前提。但 Agent 的上下文窗口有限、推理时对长文本的注意力有限直接塞原文既浪费 token 又容易引入噪音。知识编译要做的是信息提纯从文档里抽出实体、关系、规则、操作步骤、判断条件重新组织成结构化的、可直接调用的形式。3.2 知识编译的四种形态我实践中常用四种形态技术含量递增适用场景也不同规则集把如果……那么……类型的业务规则写成结构化规则文件YAML/JSON 或决策表Agent 在决策阶段直接读取。比如客服场景的退款规则、风控场景的拦截规则。工具描述把怎么做的过程编译成函数的 schema 描述name、description、parameters让 Agent 通过函数调用 API 来获取答案。这相当于把知识封装成了可执行动作。知识图谱把实体和关系抽取成三元组实体-关系-实体存入图结构。适合关联关系复杂的领域比如故障排查场景中现象-原因-解法的网状知识。提示词资产把高价值回答逻辑沉淀成 system prompt 片段或 few-shot 示例随请求动态组装。这是成本最低的编译形态也最容易被维护者偷懒放任变质。知识编译和 RAG 不是二选一。我的习惯是RAG 负责召回相关资料知识编译负责把资料变成决策依据。比如让 Agent 做故障诊断RAG 负责从手册里找出相关章节知识编译输出的决策表负责告诉 Agent 先查什么、后查什么、什么条件下判定为根因。没有编译层RAG 召回了一堆内容Agent 仍然不知道怎么组织推理回答就容易散。3.3 知识编译的落地动作与工具落地知识编译不需要额外引入重型系统。第一步是盘点知识类型哪些知识适合写成规则、哪些适合写成函数、哪些必须保留原文。第二步是写转换脚本用 LLM 做半自动抽取人工审核后入库这一步可以用 Dify 的流水线或 LangChain/LlamaIndex 的 extractor 能力辅助。第三步是关键建立知识更新的回写机制业务规则一变编译层必须同步更新否则 Agent 会用旧规则回答新问题。4. 实操从零搭建一套 Agent 记忆与知识库4.1 需求场景与工具选型我以一个典型场景为例做一个个人知识库问答 Agent让它能回答你 Obsidian 笔记里的内容同时记住你的偏好和最近关注的话题。项目规模不大适合用轻量工具。工具清单如下文件层用 Obsidian 仓库 Git数据库层用 SQLite装 sqlite3 标准库即可向量库用 Chroma 或 SQLite 的 vec 扩展个人项目别上 Milvus太重了RAG 编排用 LangChain 或 LlamaIndex也可以直接用 Dify 搭流水线省去自己写胶水代码Embedding 模型优先用本地的 bge 系列或 OpenAI 的 embedding 接口看预算和对隐私的要求。4.2 数据采集与清洗这一步决定了知识库的天花板但我发现绝大多数人在这里偷懒。原始笔记里往往有大量无关内容空行、无意义标签、过期的 TODO、重复粘贴的片段。直接切块向量化垃圾进垃圾出。我的流程是先写脚本把仓库里所有 Markdown 文件读出来过滤掉模板文件和配置目录然后做统一格式处理把标题层级规范化、压缩连续空行、去掉 HTML 残留再用正则或 LLM 做首轮粗清洗把明显噪音段落标记出来。清洗完的文件落到一个干净的目录这个目录才进入后续的切块管线。文件级的 Git 提交建议按清洗前后分两次方便回溯。4.3 分块策略与参数选择分块是最影响 RAG 效果又最容易被忽视的环节。块太大检索出来内容相干性差token 浪费严重块太小语义信息被切断模型缺乏上下文无法作答。我从项目中总结的经验值通用文本块大小 512~1024 token重叠 100~200 token。技术文档类可以适当放大到 1500 token因为技术描述前后依赖强短小的笔记条目按条切别硬拼成一个大块。切块时尽量按 Markdown 标题层级做边界切分保持标题和正文同块这样检索到的块自带上下文回答准确率明显更高。写代码时注意切块函数要幂等同样的输入必须产出同样的输出块否则增量更新时会出现重复向量。这个坑我踩过费了半天排查才发现是正则切块对同一文档不同文件结尾处理不一致导致的。4.4 向量化、检索链路与 Rerank清洗和切块完成后调用 Embedding 接口逐块向量化并写入向量库。注意记录每个块对应的文件路径、标题路径、块序号这是定位能力的基础没有元数据的向量库就是黑盒。检索链路上我强烈建议做混合检索向量检索召回语义相近内容BM25 关键字检索召回术语精确命中的内容把两路结果合并后做 Rerank。个人项目里 Rerank 可以用 bge-reranker 这样的轻量模型效果提升非常明显。别看只多了一步实测混合检索加 Rerank 比纯向量检索的答案可用率能高出二三十个百分点。Agent 集成部分检索到的知识块拼成固定格式的上下文和用户问题一起发给模型。同时把 SQLite 里的用户偏好、历史会话摘要一并注入。上下文里要明确告诉模型优先基于知识库内容作答知识库没有覆盖就明确说不知道不要编造。4.5 记忆写入与知识编译的落地记忆写入不能靠模型自觉要在代码里显式编排。对话结束后把结构化信息写入 SQLite用户 ID、时间戳、对话摘要、提取出的偏好标签把原始对话存成 JSONL 文件落盘。定期任务把前 N 条对话压缩成摘要存入长期记忆表可以在 SQLite 里用单独的表。知识编译这一步我用脚本加 LLM 抽取把 Obsidian 里的高价值笔记编译成工具描述和规则集。比如把每周笔记模板编译成 create_weekly_note 函数描述把会议记录规范编译成规则集。实测之后你会发现Agent 调用编译层知识时的稳定性和准确性远高于让它临时去检索原文再自己发挥。5. 常见问题速查与避坑记录5.1 检索召回质量差症状问一个明确的问题检索出来的知识块文不对题。排查顺序先看切块是否跨标题、块内是否信息残缺再看 Embedding 模型是否和领域文本匹配中文内容用通用英文模型效果会明显变差最后检查是否缺少 Rerank。我遇到最多的场景是切块时把标题切丢了模型拿到一段没有上下文的正文语义和原问题天然对不上。5.2 数据同步不一致文件层、数据库、向量库三份数据经常各改各的。解决方案是建立单一入口所有文档变更都必须经过同一个导入脚本更新文件、数据库索引和向量库。这需要一个简单的文件监听脚本也建议给向量库加一个内容哈希字段每次导入时对比哈希变了才重新向量化。不这么做RAG 就会一直答旧内容。5.3 上下文窗口被撑爆上下文里同时塞了检索结果、历史摘要、规则集、用户档案很快触顶。我的习惯是给每一类内容设预算检索结果占总预算四成历史摘要占两成规则和任务指令占三成留一成给当前问题。超出时先砍历史摘要再砍低分检索结果。与其用超长上下文硬扛不如让检索更精准、让编译层更浓缩。5.4 增量更新成本高知识库一更新全量重新向量化既慢又费钱。正确姿势是增量更新新文档只对它切块向量化变更文档用内容哈希判断后只重嵌入变更块删除文档时先去向量库删除对应 metadata 的记录。个人知识库这个规模一套增量脚本配合定时任务完全够用。6. 多模态与多 Agent 场景的扩展思考如果只是单一 Agent 问答上面的体系已经够用。但知识库一旦面向多 Agent 协作就要考虑共享存储的访问控制和命名空间设计。不同 Agent 用同一套知识库时要给每个知识条目加上 scope 字段区分归属避免 A 场景的 Agent 检索到 B 场景的敏感数据。多模态内容也得提前规划。笔记里的图片、PDF 扫描件里的文字很早就被切开向量化但视觉信息结构图、表格在纯文本切块里会丢失。稳妥做法是先做 OCR 和表格识别转成结构化文字再进入同一套切块管线文档扫描件如实测下来先转文字再向量化的问答准确率比直接丢原始文件高很多。Agent 之间共享记忆还有一个常见问题同一个用户在不同 Agent 里的上下文互相不通。解决思路是把会话历史统一存在一份带 user_id 和 agent_id 的会话表里各 Agent 按需读取而不是各自维护一份私有的对话文件。这一点在项目早期设计好后面不用返工。7. 站在实践角度的几条经验说几个我在真实项目里的体会给正准备动手的朋友参考。第一别一上来就追求全自动。知识库系统里自动采集、自动清洗、自动向量化听起来很美但每个环节都需要人工兜底。我给 Agent 团队的建议是先让文件层干净再考虑自动化先手工跑通一遍流水线再写自动化脚本。自动化是流程跑顺之后的奖励不是项目初期的目标。第二知识编译的投入产出比比大多数人想象的高。同样是回答一个复杂问题走检索原文 堆上下文路线的 Agent回答质量波动很大走编译规则 精准调用路线的 Agent即使换底层模型输出稳定性都很好。知识编译是在给 Agent 做肌肉记忆这个投入值得专门排期。第三任何记忆和知识库设计都要考虑忘记的能力。存了海量过期信息却不知道清理会让检索噪音越来越大。我在维护流程里加了定期归档任务超过一年未引用的知识块自动降级超过两年未引用的进入待删除清单。知识库不是仓库堆太多不如存的精。最后分享一个小技巧所有检索问题排查的第一步都是打开知识库的原始文件用肉眼确认信息真的在里面。很多所谓RAG 失效的案例根因是知识源头文件压根没更新或者更新在另一个分支里没合并。先查源头再查链路能省下大量的排查时间。Agent 的记忆和知识库设计没有银弹但有清晰的工程方法和足够多的实践样本。把这套体系跑通一遍之后你会对 Agent 的能力边界有一个更准确、更踏实的判断。