我们组的知识库接入大模型问答已经有一段时间了。同事在群里问“某个服务的配置变更要走哪些审批”，机器人能从几百篇文档里找到相关段落，给出一个像样的回答，附上链接。对人来说，这已经比翻目录方便很多。

问题出在我想让 Agent 也用这套知识库干活的时候。我做平台侧的工作，经常让 Agent 起草配置变更方案：读服务的现状，查变更规范，列出步骤和回退方式。我原以为把同一套知识库接给它就够了，结果它拿到的东西总是差一点。有一次它引用的变更流程是旧版，新版在另一篇文档里，两篇都没下线；还有一次它从一份从协作平台导出的页面里读到了大段导航栏和评论区内容，起草的方案里混进了一句评论里的玩笑话；更常见的是它知道某个服务的配置项叫什么，却不知道这个配置归哪个组管，变更前该找谁确认。

人读这些内容时会自己补全：这篇看起来很旧，评论区的话不算数，配置归属问一下就知道。Agent 通常做不到，它会把召回内容当作当前有效的依据。

换一个标准看知识库

这件事让我换了个角度看知识库。问答好不好用，看的是能不能找到；给 Agent 用，要看的是它怎么处理删除、失效和冲突。新增内容几乎所有系统都能处理，麻烦的是退出。

我们这套知识库擅长归档、目录浏览和关键词搜索，政策查阅、手册阅读这类场景至今离不开它。它的短板集中在维护上：文档质量取决于编写者；代码和流程变了，文档常常滞后，功能下线后对应说明还留在库里继续被搜到。根源在于知识库靠人建设和维护，建成之后缺少持续更新的机制。

同步这一侧我们之前已经下过功夫，索引定时重建，删除能跟着生效。我这次卡住的是另外三件事：文档本身质量参差，同一件事有几份说法互相打架，以及知识没有围绕业务对象组织起来。衡量这些问题，入库文档数和问答的满意度都帮不上忙。我更关心的是：源端一篇规范改了、废了，或者两篇说法冲突了，要过多久、经过谁的手，Agent 拿到的上下文才会跟着变对。按这个问题去看，我们的知识库在质量和冲突这两项上基本没有机制，全靠人发现。

自己先做的几件事

导出页面里的导航、页脚和评论区，我写了一个清洗脚本，剥掉再入库。这个脚本对我们最常见的那种页面模板有效，换一种模板就要加规则，前后改了好几版。

结构混乱的文档，我试过在入库前让模型重写一遍。重写后的文档检索效果确实好一些，但我抽查时发现，有一篇变更规范里“仅限工作日执行”这个限定在重写后不见了，另一篇里“建议”被改写成了“必须”。更麻烦的是，我只保留了重写版本，后来 Agent 引用出错时，我分不清错误来自原文还是改写。

冲突这边，我和几位文档作者约定，过时的文档在标题前加“已废弃”。约定执行得不太稳定，有的人记得，有的人不记得，而且被废弃的文档还在索引里，只是标题变了。

业务对象的问题，我手写了一份 yaml，记录服务、配置项和负责的组之间的对应关系，让 Agent 在起草方案前先读一遍。这份表在我写的时候是对的，两个月后就有几行过时了。

几件事都管用一阵，也都需要我持续维护。清洗脚本要跟着页面模板改，重写要有人抽查，废弃标记要靠作者自觉，归属表要我隔一阵手动对一遍。一个人维护这四样，任何一样落下一段时间，Agent 那边就会有所反映。而且每一步都是我在知识库外面另外搭的，知识库本身并不知道哪篇文档质量差、哪两篇在打架、哪个服务归谁管。

查资料时碰到的

我后来专门去找“入库前做质量检查”的现成方案，在一份 Agent Context 的帮助文档里看到了知识入库的 AI 质量评审。

吸引我的是它把质量处理放在了入库这一环：AI 按逻辑性、噪音比、矛盾度多维评分，可以智能重写，由人决定入库还是驳回。这几乎就是我那几件事的合集，区别在于它在知识库里面，评审结果和文档放在一起。

文档里的整体描述，我也顺带读了一遍。它把上下文分成三类资产：私有的 Memory 记录任务经验和用户偏好，Knowledge 可以共享也可以私有，Skill 放方法和工具。知识库这一侧，可以从控制台、自然语言或 CLI 创建，文件可以直接上传，也能从钉钉、飞书同步。我这次只关心入库质量和检索，同步那部分没有动。

CLI 按帮助文档的脚本装好，我建了一个测试用的知识库，挑了二十来篇平时最容易出问题的文档往里放。

入库评审：先看分数，再看改写

上传用的是 kb upload-file：

ctxdb kb createctxdb kb upload-file <kb> <path> --waitctxdb kb review settings getctxdb kb review list

评审相关的配置用 kb review settings get 查看，待评审的内容用 kb review list 列出，对单条用 kb review get 看详情，再用 kb review action 做决定，同类的一批可以用 kb review batch-action。我在测试库里基本是一篇一篇过的。

batch-action 我只用过一次，处理的是几篇纯粹的格式问题，改写只动了标题层级和列表缩进，看一眼就能确认。凡是改写涉及条件、数字、角色名称的，我都不放进批量里。评审的配置我看过一遍，没有改，测试阶段我想先看清它默认情况下会标出什么、漏掉什么，再决定要不要调。

那篇混着评论区的导出页面，在评审里噪音比这一项明显有问题，系统给了改写建议。另一篇和新版流程冲突的旧规范，矛盾度这一项被标了出来。我没有记录每篇的具体分数，这里只说我的处理方式：改写建议我都会和原文逐段对照，重点看限定条件和语气强弱有没有被改动。对照下来，大部分改写是在整理结构、删掉噪声，我通过了；有一篇把一个条件句改成了陈述句，我驳回了改写，回去让作者自己改原文。

关于改写，我仍然坚持一点：涉及业务依据时，要能回到原文。重写能改善召回，也可能丢掉限定条件、改变表述强弱，甚至引入原文没有的推断。我还没在文档里确认改写通过后原文是怎么保留的，所以测试阶段我在本地另存了一份原始文件，等弄清楚再决定要不要继续这么做。

图谱增强检索：围绕业务对象组织知识

我那份手写的服务归属表，想解决的是知识没有围绕业务对象组织的问题。单纯切块能做局部语义匹配，却很难表达“某条规则适用于哪个服务版本”“某个配置归哪个组管”。经过实体识别和关系构建，知识可以围绕业务对象重新组织，Agent 先找到关联对象，再按需下钻原文，不必一次塞进大段文本。

检索时用的是 kb search：

ctxdb kb search "某服务的配置变更流程" --kb=<name> --top-k=6 --verbose

返回里除了 chunks，有时还会带一段 graph_context，里面是和查询相关的实体和关系。加了 --verbose，每个 chunk 会带上 doc_name、kb_id、doc_id 这些字段。

抽出来的实体和关系也不总是完整。有两个服务名字相近，被当成了同一个对象；有些归属关系文档里根本没写，图谱自然也抽不出来。这些要靠人工补，补多少合适，我还在摸索。领域建模在这里有用，也最容易被做过头。对象少、关系简单的部分，花几周设计一套模型只会推迟交付；等跨系统的对象对齐真成了瓶颈，再往深里做更划算。模型如果不能跟着源系统变化，几个月后它本身也会变成陈旧知识，我那份 yaml 就是现成的例子。

三类东西别混在一个索引里

试图谱的时候我顺便想清楚了一件事。Agent 起草变更方案时，需要的东西其实有三种：规范和服务现状这类可以共享的知识，我个人偏好的方案格式这类私有记忆，以及“配置变更怎么一步步做”这种方法。过去我把它们都塞进同一个知识库，按相似度取前几条，Agent 经常拿到大量相关却用不上的内容，比如方案格式的说明被当成了变更规范的一部分。

按 Agent Context 的划分，这三样分别是 Knowledge、Memory 和 Skill，召回时可以各取各的。我目前只把规范类文档放进知识库，个人偏好留给记忆，变更步骤还没有做成 Skill，因为它依赖的审批规则还在调整。执行中得出的新结论，按它的设计先成为候选，评估后才更新资产，这一点让我比较放心：Agent 在某次方案里自己推断出来的做法，不会直接变成别人检索到的知识。

用控制台助手做整理

控制台里有一个内置的智能助手，可以用自然语言管理资产：整理知识、解决记忆冲突、基于上下文生成报告、处理数据和文件，背后有对话、代码与工具调用、定时任务和沙箱运行这些能力。

我主要拿它做知识整理。比如让它找出测试库里描述同一个变更流程的几篇文档，说明它们之间哪里不一致，再起草一份合并后的版本。它给的结果我都当作草稿，是否替换原文档、旧的那篇怎么处理，由我和文档作者决定。

另一次我让它把测试库里没有写明适用范围的文档列出来，比如没说适用于哪些服务、哪个时间之后生效的那种。它给出了一份清单和每篇的理由，我逐篇点开核对。这份清单我拿去和作者沟通时很好用。它省掉的主要是“把几篇长文档并排读一遍、找差异”这部分活，哪个版本有效还是人来判断。

材料里提到，未来会考虑通过 API 开放这种助手能力。如果能通过 API 调，我会想把“定期找出互相矛盾的文档”这件事接进我们自己的巡检里，不过这目前属于规划，我没有据此做任何安排。

用下来的感受

最直接的变化在入库这一环。以前质量问题要等 Agent 引用出错了才暴露，现在一部分在入库时就被评审标了出来，噪声和矛盾有了分数和改写建议，每一篇通过还是驳回也都留了记录。清洗脚本我还留着，但需要它处理的情况少了一些。

Agent 那边，我能感觉到的是它起草方案时引用的段落更集中了，配置归属这类信息有时能从图谱上下文里拿到线索，再去读对应的原文。我没有做过严格对比，说不出改善了多少。退出机制这件事，也只解决了一部分：冲突能在评审时暴露出来，可有一类失效它和我都还发现不了。

我也意识到，判断一篇文档该不该退出，比判断它该不该入库难。最容易想到的信号是使用情况，可这些信号都不能单独用。“页面没人点开”不等于没价值，Agent 可能一直通过知识片段在用它，页面访问量反映不了机器侧的使用。高频召回也可能只是因为库里有重复内容，或者某段宽泛的文字恰好和很多查询相似。只凭一个信号自动下线，迟早会误伤那些只在年度审计时才用到的低频规则。我现在的想法是，来源有没有变化、召回情况、Agent 执行结果和人工复核，至少要看两三样再下结论。

接下来的安排和一个没想明白的问题

近期我打算先把测试库里那二十来篇文档的评审结果和作者过一遍，尤其是被驳回改写的那几篇，看是否需要改原文。

没想明白的是这样一类失效：源系统里的文档没有被删除，也没有被修改，只是它描述的功能已经下线，或者它引用的流程已经被另一个组的新规定取代。同步链路和入库评审都看不出它有什么问题，对 Agent 来说，它却是一条随时可能被召回的错误依据。按时效降权能缓解一部分，但旧文档未必都过时，新文档也未必都正确。这种“源端没有变化的失效”该由谁来声明？文档作者、业务负责人，还是从 Agent 执行出错时反推，我还没找到答案。眼下我能做的，是在组里试一个约定：功能下线时，负责人要一并列出相关文档，交给知识库那边处理。这个约定能不能坚持下来，我心里也没底。