公司文档散在网盘、群聊、邮件和本地硬盘里，想找一份模板或者确认一条口径，最快的办法竟然是「问一下同事」。这种状态下上再强的模型也没用——它不是不知道答案，是根本没见过你的资料。
让 OpenClaw 接一个内部知识库，解决的就是这件事：把散落的文档收进一个可检索的库，问一句就能拿到答案，而且答案要能点回原文。这篇按落地顺序走一遍：收什么、怎么清、怎么切、怎么检索、怎么答、怎么维护。
第零步：先定边界，不是所有文档都该进库
这一步跳过，后面全是坑。入库前对每份文档问三个问题：它还有效吗（过期制度进了库，Agent 会拿旧口径当真话讲）、谁负责它（没有责任人的文档没人更新）、谁能看它（人事、薪资、合同这类必须做权限隔离，不能和公共制度放在同一个库里）。
建议先做一个小而准的库——比如某个业务线的两百份现行有效文件，跑通再扩。上来就把几十 GB 历史资料全塞进去，结果只会是检索质量奇差、而且查不出原因。
第一步：收集与清洗，脏数据是检索的头号杀手
四个要点：
（1）格式统一。PDF、Word、Excel、扫描件混在一起，解析质量差别很大。扫描件必须先做 OCR，否则等于入库了一堆空白。（2）去掉页眉页脚和水印。这些重复文字会污染检索，让每一份文档看起来都很像，召回结果自然就乱。（3）只留现行版本。历史版本可以留着做溯源，但必须打上「已废止」标记并排除在检索范围之外——这正是 知识库陈旧内容怎么巡检 要长期盯的事。（4）补齐元数据。每份文档至少带：标题、编号、发布日期、生效日期、责任部门、密级、来源路径。元数据是后面做筛选和权限的依据。
各类文件的解析差异，可以对照 OpenClaw 怎么读取文件，那篇专门讲 PDF、Word、Excel 和图片扫描件怎么读。
第二步：切片策略，直接决定检索准不准
切片是这类项目里最被低估的一步。切太大，一片里塞了十个话题，命中之后模型抓不到重点；切太小，一句半句没有上下文，答案容易断章取义。
实操建议：（1）按标题层级切，不按固定字数切。文档本身的结构就是最好的切分线，一节就是一片，超长节再按段落细分。（2）表格整块保留。表格被拦腰切开等于报废，宁可让这一片大一点。（3）每片都带元数据头——来自哪份文档、第几章、什么版本、什么日期。缺了这个，后面的引用溯源就做不了。（4）条款类文档按条切。制度、规范、合同适合一条一片，因为用户的问题往往精确到某一条。
更细的切片与召回调参方法，可以参考 知识库检索怎么做才准确，那篇把切片、召回、排序、改写四个环节拆得很细，这里不重复。
第三步：索引与检索怎么配
三条经验：
（1）混合检索，别只靠向量。纯向量检索在「说法不同、意思相近」的问题上很强，但遇到编号、型号、专有名词经常跑偏。向量和关键词各出候选、再统一重排，效果通常比单一路线稳。
（2）重排这一步值得加上。召回二十条、重排出前五条，比把二十条全丢给模型效果好，也更便宜。
（3）按密级和部门分库做隔离。关键点是：权限过滤不能发生在检索之后——检索时就不该把无权访问的内容取出来。权限体系怎么设计，参考 AI Agent 权限管理怎么做。
第四步：回答必须带引用，查不到就认
这一步是内部知识库和通用聊天机器人最大的区别。三条硬要求：
（1）每个结论后面跟来源——文档标题加章节或条款号，最好能给页码。用的人点一下就能回到原文核对。
（2）检索不到就明确说检索不到，并提示「可以在哪个目录里找」，绝不允许模型凭常识补一个像样的答案。内部知识库最怕的不是答不出，而是答得像真的。
（3）引用范围收紧到白名单内。只允许引用已入库且现行有效的文件，不允许引用网页、群聊、历史废止版本。这个思路和 引用白名单怎么设 完全一致。
第五步：接到 OpenClaw 上，让它自己维护
库建好之后，把三件事挂上去：
（1）增量入库。指定一个「待入库」目录，新文件放进去就自动解析、切片、入库，并提示元数据是否齐全。别指望每次都人工手动导。
（2）定时重建与巡检。建议每周跑一次，重点找三类文件：已废止但仍在库里的、三个月没有人引用过的、解析异常（切片数为零或异常少）的。这三类就是知识库的异常清单。
（3）问答入口加留痕。让 OpenClaw 在群里或工作台上提供问答，并对每次回答留痕：问了什么、命中了哪些片段、给了什么答案。留痕不是为了监控，是为了迭代——回答不准的时候，你能看清是检索错了，还是文档本身写得含糊。
如果你希望 Agent 还能记住「上次讨论的结论」而不是每次都重新查库，可以看看 OpenClaw 长期记忆怎么用。两者互补：知识库管正式文件，长期记忆管过程结论。
优缺点
优点：口径统一，新人上手快；答案可溯源，比问同事更可靠；数据留在自己手里；文档维护第一次有了抓手。
缺点：前期整理文档的工作量躲不掉，而且是最费人力的部分；文档本身写得差，检索再好也救不回来；需要有人长期负责更新，否则半年后就开始答旧口径。
适合人群
适合：有大量制度、规范、手册、历史项目文档的组织；客服、售后、交付这类高频查询场景；对数据不出域有要求的团队。不适合：文档总量很小、几份文件就能记住的场景——那种情况让人维护一份常问问题清单更省事。
六个坑
坑一：把历史资料全塞进去。新旧口径混在一起，Agent 会自信地讲错版本。坑二：按固定字数切片。把一个完整条款切成两半，引用出来没法用。坑三：不做 OCR 就把扫描件入库。等于入库了一堆空白页。坑四：检索不到时让模型自由发挥。这是内部知识库最危险的行为。坑五：权限过滤放在检索之后。敏感内容已经进了上下文，只看输出有没有显示是不够的。坑六：没有责任人。文档半年不更新，知识库会从资产变成负债。
总结
OpenClaw 搭内部知识库，一条主线：先划边界（有效、有主、有权），把文档清洗成带元数据的现行版本，按结构切片，用混合检索加重排，回答必须带引用、查不到就认，最后用定时巡检维持新鲜度。一句心法：知识库的价值不在「收了多少」，而在「答得对不对、能不能点回原文」。
