1. AI Agent为什么绕不开知识管理：先把"记性"这件事想清楚

1.1 从"有问必答"到"有据可循"：Agent的能力边界取决于知识层

我做了两年多企业级的AI Agent项目，最常被客户问到的一句话是："为什么我给它喂了几百份文档，它还是答不对问题？"

这个问题的本质，不在于模型不够聪明，而在于知识管理这一层没有设计好。很多人把Agent想象成一个"什么都知道的超级大脑"，这是个大误会。大模型本身的参数记忆是有限的，它的训练数据截止到某个时间点，它也不可能记住你们公司内部的请假流程、产品规格、故障处理手册。你真正要做的，是给这个大模型接一个"外挂记忆库"，让它在回答问题之前，先去这个记忆库里翻一翻资料，再基于资料组织答案。

这个过程在业内叫RAG（检索增强生成），但很多人不知道的是，RAG只是Agent知识管理体系里的一个环节。AI Agent架构里的知识管理，远不止"文档存进去、向量检索出来"这么简单。它涉及文档从入库、分块、索引、检索、重排，到上下文注入、知识引用、反馈回写的一整条链路。

这一层做得好不好，直接决定Agent在真实场景里是"看起来聪明"还是"真的靠谱"。如果你的Agent要处理的是开放域的闲聊，那知识管理可能无所谓；但如果它要处理的是企业知识库问答、客服工单处理、运维故障诊断这类任务，知识管理就是整个系统的地基。

这篇文章，我从实际项目里总结了一套Agent知识管理的落地方案，从文档存储一路讲到智能检索，中间会穿插我踩过的坑和验证过的参数。适合正在做Agent应用开发、想搞清楚RAG怎么做才不"看起来智障"的技术同学，也适合刚接触这一块、想建立整体认知的产品和技术负责人。

1.2 先把知识分分类：不同知识用不同方式管，别混在一锅炖

我见过非常多的团队，一上来就拿着几千份PDF往向量数据库里灌，灌完之后效果稀烂，然后开始怀疑模型不行。实际上问题通常出在：他们没有对知识做分类。

Agent在真实业务中需要处理的知识，大致可以分成三类。

第一类是事实型知识，比如数据库里的用户信息、订单记录、设备状态。这类知识的特点是正确的、标准的、高频变更的，它不太适合放在文档型知识库里，更适合通过API调用或结构化数据库查询来获取。Agent在回答"我的订单到哪了"这类问题时，应该去查数据库，而不是检索一份物流说明文档。

第二类是过程型知识，比如操作手册、工单流程、规章制度。这类知识是文档化的，相对稳定，最适合做RAG的流程：切分文档、向量化、检索召回。企业知识库问答主要处理的就是这一类。

第三类是经验型知识，比如历史工单的解决方案、用户反馈的常见问题、专家处理过的疑难案例。这类知识散落在工单系统、聊天记录、邮件里，数量大、质量参差不齐，需要经过提炼、清洗后才能进入知识库，它的维护成本最高，但价值也最高。

我在实际项目里强烈建议，先把这三类知识拆开，分别设计存储和检索方案，而不是一股脑全塞进向量库里。原因很简单，向量库擅长做"语义匹配"，但它不擅长做"精确计算"和"条件过滤"。你让向量库去查"上个月销售额超过十万的客户有哪些"，它一定给你瞎编一个答案。这种任务就该让SQL去干。

2. 文档存储层：从"文件堆"到"知识库"的第一步

2.1 文档解析与清洗：入库之前，先把"脏数据"处理干净

假设你要做一个企业知识库Agent，第一步当然是收集文档。但你需要先想清楚一个问题：你的文档是以什么形式存在的？

绝大多数企业里的存量文档，是Word、PDF、Excel、PPT，甚至还有扫描件。这里面的第一道坎，就是文档解析。我在项目里见过太多让人崩溃的情况：PDF里表格被拆得七零八落，扫描件里的文字识别出来一堆错别字，Excel里合并单元格直接读不到内容。这些东西一旦入库，检索效果就是灾难。

所以在做向量化和索引之前，你必须先做文档清洗。这一步我建议分三个层次来做。

第一层是格式解析。纯文本和Markdown最好处理，直接用工具读取就行。PDF要分情况：文字版PDF用解析器直接抽文本，扫描版PDF得走OCR。Excel和PPT要特别小心格式问题，建议先转成结构化数据再转化成文本，而不是直接把原始内容粗暴拼接。

第二层是内容清洗。把页眉页脚、重复的目录、无水印的水印文字、无意义的表格边框符号全部去掉。很多人在这一步偷懒，结果检索的时候出来一堆"第X页共Y页"这种垃圾片段，白白占据上下文窗口。

第三层是结构标记。文档里的小标题、章节标题、表格标题，这些信息非常宝贵。如果你能在切分之后保留"这篇内容来自操作手册第三章第二节"这样的结构信息，检索阶段就能做结构化过滤，精度会提升一个档次。

这一步的产出质量，决定了整个知识库的上限。我见过有人用便宜的批量OCR工具一口气处理几千份扫描件，结果识别率不到70%，后面做再多优化都补不回来。文档清洗没有捷径，建议按文档类型分别处理，分批验收。

2.2 分块策略：切得好不好，直接决定检索准不准

文档清洗完之后，紧接着就是切块。这一步听起来简单，实际上藏着的坑最多。

先说为什么必须切块。大模型的上下文窗口有限，你不可能把一份50页的手册整个灌进Prompt里让模型去读，代价太高，而且模型读到最后早就忘了前面讲什么。所以你需要把文档切成适当大小的片段，建立索引。用户提问的时候，先把最相关的几个片段找出来，再拼到一起喂给模型。

切块的大小，我的经验是有一个安全区间：512到1024个token左右，中文大概就是三四百到七八百字。切得太小，片段里信息不完整，常常断在一句话中间，语义支离破碎；切得太大，一次召回的内容太多，里面有效信息被稀释，模型不知道该重点看哪，还会浪费上下文空间。

但这个数值不是死的，它取决于你的文档类型。操作手册这类强结构文档，更合适的切法不是"按长度切"，而是"按语义切"，也就是按章节、小节来切。这样切出来的每个块，主题完整、语义内聚，检索效果远好于生硬按字数切。

实际操作中，我常用的是滑动窗口加重叠。比如目标块大小是512个token，那我会让相邻块之间有50到100个token的重叠。这样做的好处是，关键内容如果恰好落在切分边界上，不会因为被拦腰截断而消失，它在上一个块的末尾和下一个块的开头都会出现，至少保证一边是完整的。

还有一种情况需要特别处理：表格和代码。表格如果被切成两块，检索出来的内容就是两个莫名其妙的半截表格。代码同理，函数定义和注释被切散了，模型根本没法理解。我之前处理技术文档库时，对这类内容一律单独走一套切分逻辑，表格按行和列语义保留整体结构，代码块整体作为一个块。

2.3 向量化的选择：Embedding模型和索引类型怎么定

切完块，下一步就是把每一块文本变成向量。

这一步首先面临的是Embedding模型选型。市面上的模型很多，有的开源有的商用，它们之间的差异主要在于：向量维度、语义理解能力、对中文的支持程度、以及跨语言能力。

我的建议是别一味追求参数量大，而是用小样本实测来选。拿你的真实业务文档抽个二三十个问题出来，分别用不同的Embedding模型跑一遍检索，看哪个模型的召回结果最准。我自己实测下来的感受是，在纯中文企业文档场景里，专门针对中文优化的模型往往比通用大模型用起来更顺手，而且更便宜。

向量化之后，这些向量要存到哪里，用什么索引结构。这里我最想强调一点：别在项目早期就上非常重型的分布式向量数据库。很多人一上来就部署一套分布式集群，配置复杂不说，小规模数据下性能优势根本体现不出来，反而给运维增加负担。

按数据量选型是更务实的思路。百万级向量以下，单机的向量索引就够用了。常用的索引类型是HNSW（一种基于图的近似最近邻检索算法），它有几个关键参数：M，控制每个节点的最大连接数，影响内存占用和查询速度；efConstruction，建索引时的动态候选集大小，影响索引质量；efSearch，查询时的候选集大小，影响召回精度。

以我自己的经验，M设在16到32之间，efConstruction设在200到400之间，efSearch设在50到150之间，是一个比较稳的起点。参数越大，召回越准但越慢；参数越小，越快但越容易漏掉相关结果。你可以在实测中微调，核心标准是P99延迟和召回率都能接受。

还有一个细节容易被忽略：embedding模型训练数据的截止日期。如果你的知识库里有大量近期出现的新词、新品牌名，而Embedding模型不认识这些词，那你无论怎么调参数，它都召不回含有这些词的文档。这种情况下的务实方案是：在切分文档时给新词做同义词扩展，或者定期用增量数据微调一个专属Embedding模型。后者开销大，前者见效快。

3. 智能检索层：从"搜得着"到"搜得准"的三级跳

3.1 关键词检索没有过时：BM25为什么仍然值得保留

有了向量索引之后，很多人就开始忽视关键词检索，这是我在多个项目里看到的一个普遍误区。

关键词检索的核心算法是BM25，它本质上是一个"词频加权"的打分模型。一篇文档里，某个词出现得越多，包含这个词的文档越短，那它跟你的查询就越相关。这里的细节在于，它会给罕见词更高的权重，给常见词更低的权重，避免了"的、了、是"这种无意义词霸榜。

为什么在有了语义检索的时代，BM25仍然有价值？因为它处理的恰恰是语义检索不擅长的问题：精确匹配。

想想你的实际业务场景：用户在知识库问"HP-3000打印机报错E02怎么解决"，这里的"HP-3000"、"E02"就是精确标识符。语义检索这时往往会失效，因为这些词在向量空间里离什么都很远，你不知道它跟哪个概念相近。但BM25能精确匹配到含有这个型号、这个报错码的文档片段，一找一个准。

类似的场景还包括：工单编号、错误码、API函数名、配置项名称。凡是"代码和专有名词"型的查询，BM25都是主力。凡是"描述性、概念性、模糊表述"型的查询，比如"打印机经常卡纸怎么办"，语义检索更擅长。

所以我的检索层，从来不是"只用一个"，而是把两个都保留，后面再用融合和重排把它们结合起来。

3.2 语义检索的实用认知：它到底在算什么，又容易错在哪

讲清楚语义检索的原理，其实一句话就能概括：把文本变成向量，然后在向量空间里找距离最近的邻居。它假设语义相近的文本，在向量空间里的位置也靠近。检索的过程，就是计算查询向量和库里所有向量的相似度，然后返回TopK个最接近的。

这听起来很美好，但实际操作里有几个经常翻车的地方。

第一个是"语义漂移"。向量模型在把文本映射到空间的时候，会把不同粒度的信息混在一起。比如你查"公司团建政策"，它可能召回了"公司年会策划方案"，这两者语义上沾边但实际需求差之千里。模型相似度排序时，往往把泛泛的关联排在前面，把精确的匹配排到后面。

第二个是"常见词干扰"。如果用户的查询里有几个高频词，比如"系统、服务、故障"这些在企业文档里随处可见的词，相似度计算时这些词会拉高很多无关文档的得分，导致噪声大量涌入。

第三个是"长查询的稀释"。用户一次性问了太长的一段话，里面真正的关键信息可能只有一两个词，但在向量化的时候，整个句子的信息被平均了，关键信息反而被稀释掉了。

所以，在做检索方案时，我把语义检索定位为"召回候选集"的角色，而不是"最终答案"的角色。它先把可能相关的内容都捞出来，比如Top 50，但最终回答用户，还要经过后面的重排和高精度把关。如果你只依赖向量检索一次定生死，那精确性大概率是不够的。

3.3 混合检索与重排：工程上最划算的精度提升手段

真正让检索效果产生质变的，是"混合检索"和"重排"这两步。

混合检索的思路非常简单：把BM25的结果和向量检索的结果都取出来，合并去重，得到一个更大的候选集，然后用一套融合规则进行打分排序。最常见也最好用的融合规则是RRF，也就是取每个文档在多个检索结果里的排名，求排名的倒数然后求和。排名考前，贡献的分数就高。这个方法最大的好处是不用调权，也不用统一分数量纲，直接拿各自排名算就行，实战中非常稳。

用公式表达就是：对于每个文档，在BM25结果里的排名是r1，在向量检索里的排名是r2，那么它的融合得分就是两个1/(r1+60)加1/(r2+60)的和，常数60是为了平滑。这个值越大，文档在融合后的排名越靠前。

但RRF本身也不完美。它只能把两种信号拼在一起，并不能真正判断"哪些片段才是用户想要的"。这时候就需要最后一道工序：重排。

重排和向量检索的区别在于，它在给两个片段算相关性的时候，用的是"让两个文本进行深度交互"的方式，而不是只做一次粗粒度的语义映射。你可以简单理解成：粗检索是把全文过一遍，找出有可能相关的候选；重排是把候选里的每一对"问题片段"单独送进一个打分模型，让模型仔细对比之后给出一个精确的相关性分数。

我项目的做法是：粗检索阶段，BM25和向量检索各召回50条，RRF融合后取前20条，再送进重排模型精排，最终取前5条作为上下文。这个链路下来，整体准确率比单独用向量检索能提升二三十个百分点，而且响应延迟只增加几百毫秒。对于准确性敏感的场景，这几百毫秒的代价完全可以接受。

这里还要提醒一句：重排模型一定要选交互式的，不能用普通的Embedding模型去算相似度替代。那种做法本质上还是语义检索，精度提升有限。另外重排模型的输入长度有限，太长的片段要先截断再送进去。

4. 检索之外的关键工程：元数据、评测与框架选型

4.1 元数据设计先行：给每一块知识打上"档案标签"

很多团队的Agent知识管理做不好，不是检索算法不行，而是从一开始就没设计元数据。

元数据最简单的理解，就是给每一块知识打上档案标签：来源文档是什么，属于哪个部门，是什么类型，最后更新时间是什么时候，适用的产品线是哪个。这些东西在入库的时候不起眼，但到了实际使用中，价值巨大。

最直接的用处是过滤。企业内部文档往往有多个产品线、多个部门、多个时间版本。如果检索的时候不按元数据做前置过滤，一个用户问"路由器调试指南"，向量库可能把老版本路由器、其他产品线的文档都召回来，因为它们在语义上太像了。但如果你通过元数据限制"只在这款产品线的文档里检索"，精度立刻就不一样了。

第二个用处是溯源。Agent回答问题的时候，如果只能给出答案，用户很难信任。如果你能附带"这个答案来自《XX产品手册》第X章第X节"，用户就能自己打开原文核对，这样可信度完全不同。要做到这一点，就必须在向量化的同时，把来源文档、章节号、页码这些信息一并存进去，检索到哪一块，就知道它的出处。

第三个用处是权限控制。企业知识库场景里这个尤其重要。不同角色能看的内容不同，比如普通员工不能检索薪酬制度文档，研发人员不应看到核心客户名单。你要么在检索前就根据用户角色过滤掉无权访问的文档，要么在检索后对结果做权限标注。这个如果不在元数据层设计和实现，后面基本只能推倒重来。

4.2 检索评测：没有指标，优化就是瞎调

我在做Agent项目时，最常提醒团队的一件事是：在你动手调检索参数之前，先建一套评测集。

没有评测集，你就只能靠一两个问题人工看效果，改一版参数、肉眼看一次，看起来好像在优化，其实完全是随机游走。稍微换几个问题，效果就现出原形。

建评测集的方法其实不复杂。从你的知识库里整理出50到100个真实用户可能问的问题，每个问题配上期望召回的知识片段编号和标准答案，做成一个测试集。每次调完检索参数，跑一遍这个测试集，统计几个关键指标。

最基础的是"召回命中率"，也就是正确答案对应的知识片段，有没有出现在检索结果的前N条里。这个指标代表你"找没找到对的材料"。第二个值得关注的是"答案可溯源率"，也就是模型给出的答案有没有引用真实存在的知识库来源。第三是"端到端准确率"，整个Agent链路下来的答案跟标准答案比，是否正确。这三个指标分别卡住了检索、溯源和生成三个环节。

做评测集这件事本身，也是浓缩业务知识的绝佳机会。你和业务专家一起标注答案的过程，就是在逼自己理解"到底什么样算答对了"。这个过程省不了，而且越早做越好。如果你连评测集都没有，后面就算换了再好的模型，你也没法判断是变好还是变差。

4.3 工程落地：轻量方案先行，别一上来就上全家桶

到了工程落地环节，我见到最多的一个问题就是过度设计。

我接触过很多团队，项目刚启动，连文档都还没整理清楚，就开始部署分布式向量数据库、上完整的Agent编排框架、配置监控告警。结果一个月过去了，系统搭了一堆，一问"检索效果怎么样"，还停留在"看起来能跑"的程度。

我的建议恰好相反：先用轻量方案把全链路跑通，再逐步替换重型组件。

具体来说，初期只需要三个东西：一个文本解析处理的Python脚本库用来做文档清洗和切分，一个开源的向量检索组件用来存向量和查相似度，一个重排模型的API服务用来精排候选集。这些组件加起来，几百行代码就能搭出一套可用的知识检索链路。

在这个轻量方案的基础上，你先验证两件事：第一，文档清洗和切分的质量是否达标；第二，检索+重排的精度是否能满足业务要求。这两件事验证过了，再考虑要不要换更强的分布式存储、多副本、水平扩展这些能力。很多中小规模项目，其实轻量方案就能一直跑到底，根本不需要升级。

框架选型的另一个原则是"边用边换"而不是"一步到位"。Agent技术栈迭代很快，你今天选型的最佳实践，半年后可能就有更好的方案。只要你的代码在存储层、检索层、模型层之间做了清晰的接口隔离，中间替换某一层的时候成本就完全可控。

5. 知识管理在Agent编排层如何真正用起来

5.1 三种知识注入姿势：一次性、按需检索、长期记忆

知识管理做完之后，下一个问题就是：这些知识怎么被Agent真正用起来。我在实践中归纳出三种注入方式，各有适用场景。

第一种是一次性注入。适用于知识总量小、上下文窗口放得下的场景。比如让Agent模仿某个产品的风格写文案，把几篇样例一次塞进系统Prompt里就行。这种方式简单粗暴，不需要检索，也不会漏召。它的天花板在于知识量，超出窗口就塞不下了。

第二种是按需检索注入。这是最主流的RAG方式。用户提问后，系统先用这个问题去检索知识库，把Top几的片段取出来，再连同用户问题一起拼成Prompt喂给模型。它适合知识库大、问题杂的场景，也是这篇文章讲的主要内容。它的关键在于检索质量，检索不准，后面全白搭。

第三种是长期记忆注入。适用于跨会话的场景。用户上周问过某个问题，这周再来问，Agent应该记得上次聊了啥，不用用户重复背景。这种记忆一般以摘要的形式存在，每次会话开始时把历史对话摘要检索出来注入上下文。

实际项目里，这三者是组合使用的。我有一个做运维知识库Agent的经验：系统Prompt里注入全局性的行为规范（一次性），每次问答按需检索故障处理手册（按需检索），同时将近期处理过的工单摘要存成记忆（长期记忆）。三种方式各司其职，效果是只靠单一RAG链路比不了的。

5.2 上下文窗口的管理：知识段的引用与溯源

知识检索出来之后，怎么把它组织进Prompt，这里面的门道很深。

首先是上下文窗口的预算。一个Agent的完整Prompt通常包含四部分：系统指令、历史对话、检索到的知识片段、用户的当前问题。系统指令和当前问题占一小部分，历史对话越大越占空间，真正留给知识片段和模型思考的预算有限。我习惯的做法是，给知识片段划定一个明确的预算，比如最多占窗口的40%。超过就直接截断，不拖泥带水。

其次是知识片段的引用格式。我建议在知识片段前面加上来源标记，比如"知识片段1，来源《XX手册》第3章"，让模型在回答时能引用这个标记。最终生成答案的时候，模型会说"根据《XX手册》中的说明…"，用户点一下就能看到原文档。这样做还有个额外的好处：模型在引用来源时必须依赖检索到的片段，而不是自己编造，这能显著降低幻觉率。

再补充一个容易踩的坑：不要把当前问题和所有知识片段一股脑全倒给模型。正确的做法是给模型明确的指令，先判断检索到的知识片段跟问题是否真的相关，再决定用不用。如果不相关，就让模型直接承认"知识库中没有相关信息"，而不是强行凑答案。这个指令的存在，大幅减少了答非所问的情况。

5.3 多轮对话中的知识维护：让知识库活起来

知识库不是建完就完事的静态系统，它需要跟用户对话产生反馈，形成闭环。

我见过一个最常见的死法：知识库里的文档是半年前更新的，用户问了一个新政策，Agent还在拿旧文档回答，答完还信誓旦旦地说这是最新规定。这就是知识更新机制缺失导致的。

要避免这个问题，有两个层面要做。

第一是定时刷新。给每份文档设定有效期，到了时间就提醒管理员重新上传或确认。对于高频变动的业务政策，比如员工福利、价格政策，更新周期要短；对于稳定的技术手册，半年甚至一年刷新一次也行。这个机制未必很智能，但它能保证知识库不会在不知不觉中腐烂。

第二是用户反馈回写。用户对Agent的回答点了"这个答案不对"，这个信号非常宝贵。比较完善的做法是：当用户纠错时，把错误的回答和纠正后的信息记录下来，经过审核之后，以新的知识条目追加进知识库。这样每跑一段时间，知识库就在自动生长。我做知识类Agent项目时，一定会建一个"纠错汇入"队列，哪怕只是人工定期处理这个队列，效果也比从不回写强十倍。

6. 实操避坑与排查实录：我整理的一份速查表

6.1 文档入库了但检索不到：按这四条路径去查

这是被问得最多的问题。整理了知识库，文档也切了、也向量化了，但用户问问题的时候，相关的内容就是不出现，或者排名特别靠后。

按我的经验，九成的情况出在四个环节。

第一个环节是文档解析质量。先抽查文档进库后的文本内容，是不是有乱码、错字、段落丢失。扫描件特别容易翻车，我之前处理一份技术图纸的扫描件，OCR把关键参数识别成了完全无关的字符，这种文档无论怎么改检索参数都不可能被正确召回。排查起来也简单，直接搜索文档里的原文，看看能不能搜到。

第二个环节是切分策略。如果文档是大段大段地切，导致每个片段都包含很多不相关内容，那检索时模型算出来的相似度就被稀释了。比如一篇混合了产品介绍、安装步骤、故障排查三种内容的长文档，硬生生按512字切块，你查"怎么安装"时，召回的块里可能一大半在讲故障排查。解决思路是换成按章节语义切分。

第三个环节是embedding模型的能力边界。如果文档里全是新出现的专有名词、缩写、品牌名，而模型不认识，那语义检索一定会漏。排查方法是用几个含这些词的问题去手动检索，看召回结果里有没有包含这些词的片段，没有就说明embedding模型认不出来。补救手段是同义词扩展或换模型。

第四个环节是过滤条件过严。很多人会在检索时加上一堆元数据过滤，比如只查某个月份发布的文档。如果过滤条件设置错了，比如日期格式不对、字段值对不上，检索结果直接为空。查这个问题的最快路径是，先手动去掉全部过滤条件，看能不能召回，能召回就是过滤条件的问题。

6.2 片段召回了但答案不相关：问题出在重排和指令上

文档检得到，但模型给出来的回答还是不对，这种现象也很常见。它通常说明，不是"找没找到"的问题，而是"找对了却没用对"。

第一种情况是混合检索只做了召回没做重排。粗召回的候选集里有正确答案，但它的融合排名可能比较靠后，没有被选进上下文里。如果你只取Top 3，而正确答案在Top 10，那模型根本看不到。这种情况加上重排环节，基本上能解决一大半。

第二种情况是查出来的片段太长了。一个被召回的块可能有800字，里面真正管用的只有一句话。模型被大量的冗余信息干扰，抓不住重点。解决方式是把上下文里塞给模型的片段做"关键句提取"，或者切分时控制块大小。我在项目里试过在重排之后增加一个"压缩"环节，用轻量模型把片段里的冗余句子删掉，实测对答案质量的提升非常明显。

第三种情况是Prompt指令太弱。有些Agent的Prompt写得很简单，没有告诉模型"只依据检索片段回答、不要联想、不要编造"。模型面对一个它不太确定的问题时，很容易调用它自己的参数记忆去"脑补"，产出一个听起来有道理但跟知识库无关的答案。这就要回到指令设计上，明确的约束可以极大减少"强行凑答案"的现象。

6.3 几个高频运维问题：权限、增量更新与并发

最后分享几个我在长期运维中经常遇到的坑。

权限一致性问题是个隐形炸弹。检索接口对用户开放后，一定要确保用户只能看到自己有权限的文档。我见过一个项目，文档权限在业务系统里做了严格隔离，但同步进知识库时权限字段丢了，结果所有用户检索时都共享同一套文档，相当于把内部信息全部暴露了。这个问题的排查，要从数据入库时同步保留权限字段做起。

增量更新也是一个容易被忽略的点。知识库的文档不是一次性导入就完事，业务文档会持续新增、修改、废止。如果只做全量重建，成本高、周期长，而且在重建窗口内用户的查询可能全部失败。更稳妥的方案是维护一个"文件指纹"表，记录每份文档的哈希值和最后处理时间。每次同步时，先比对指纹，只处理有变化的文档，删除失效的文档。增量更新做好之后，知识库的维护成本会大幅下降。

并发和延迟问题通常在业务跑起来之后暴露。检索链路的延迟大头往往不在向量查询，而在重排模型推理上。我实测过，如果没有做并发控制，重排接口在QPS稍微上来之后延迟会指数级恶化。可以做的优化包括，把重排模型批量推理打开、在缓存里保存高频问题的检索结果、对用户查询做相似度去重直接返回缓存。这些手段加在一起，能扛住的并发量翻倍问题不大。

最后，我愿意分享的一点个人体会

做Agent知识管理做了这么久，我最大的体会是：这个领域没有银弹，不存在一个模型、一个框架、一个参数能一劳永逸解决所有问题，工程上的"笨功夫"才是真正的护城河。那些看起来运转得很好的Agent系统，背后无一例外是文档清洗切分做得细、元数据建得全、评测集维护得好、知识更新闭环跑得勤。如果让我给后来者一条建议，那就是：先花力气把你的知识库整理明白，再把精力投入到检索质量和评测优化上，这比换更大的模型、更炫的框架要踏实得多。另外，我强烈建议你在项目初期就动手建评测集，哪怕只是50个问题，它会成为之后所有优化决策的判断基准，帮你在迷茫时找到方向。