知识库不是把文档塞进向量库就完事。真正决定智能体好不好用的，是记录的粒度和检索的路径。
做智能体知识库，第一步是区分「现象知识」和「原理知识」。
现象知识：设备报什么错、屏幕上显示什么、有什么异常声音、什么情况下出现。这类知识用来定位问题。
原理知识：这个部件是干什么的、为什么会坏、坏了会影响什么。这类知识用来解释和给建议。
两者混在一起存，检索效果会很差。正确做法是分开建，检索时先查现象、再补原理。
一条好的故障记录长这样：
· 现象描述（用户会怎么描述这个问题，用他们的原话）
· 可能原因（按概率排序，通常两到四个）
· 判断方法（怎么区分这几个原因）
· 处置步骤（分「现场可做」和「需要报修」两档）
· 关联设备（哪些设备型号会出现这个问题）
粒度太粗（一条记录覆盖十几种情况）检索不准；太细（每个螺丝一条）检索不到。经验上一条记录对应「一个用户可以描述清楚的故障现象」最合适。
这是最容易被忽略的一点。
工程师写的记录是「主控板通信超时」，但现场人员会说「屏幕黑了」「不动了」「一直转圈」。
如果知识库只存工程师的说法，现场人员描述现象时检索不到。
做法是每条记录都带一组「别名」：技术说法 + 三到五种用户说法。检索时两条路径都走。
简单的向量检索在故障场景下不够用，因为故障描述往往很短（「不动了」三个字），向量相似度区分不出来。
更可靠的是「关键词 + 向量」双路：
· 关键词路：现象别名做精确匹配，命中就直接给结果
· 向量路：关键词没命中时，用语义相似度找最接近的几条
两路结果合并后按置信度排序，低于阈值的直接说「没找到，建议联系厂家」——这比给一个错误的建议好得多。
知识库不是一次建完的。它必须在使用中生长。
做法是每次智能体给了建议后，让使用者反馈「解决了 / 没解决」。
没解决的记录会被标出来，定期由工程师复核，补充进知识库。
这样跑一年，知识库的质量会明显高于初始版本。反过来，如果不做反馈闭环，知识库会一直停留在初始状态，半年后就过时了。
402 条听起来不多，但如果这 402 条覆盖了 80% 的常见故障，就足够用。
判断覆盖率的方法：统计过去一年的报修记录，看有多少能对应到知识库里的记录。
如果覆盖率低于 60%，说明记录的粒度或分类有问题，不是数量不够。
盲目堆数量到几千条，但都是低频问题，实际价值不如精修 400 条高频的。