企业知识库越用越乱，通常不是文档不够，而是缺少四条治理规则：一个主题一个现行入口；每份现行知识有完整元数据；动态业务事实回业务系统；旧文档保留历史但写清替代关系。适合已经有大量制度、项目资料和历史文件的企业；如果只是少量稳定资料，先做好目录与责任人即可，不必上复杂平台。
先判断知识到底乱在哪里
| 症状 | 根因 | 正确处理 | 不该做什么 |
|---|---|---|---|
| 搜出多份“最终版” | 没有现行入口 | 指定唯一现行文档，其他转历史 | 靠文件名猜最新版 |
| 文档内容看似完整却没人敢信 | 无状态、Owner 或批准人 | 补齐元数据并确认责任 | 默认上传即生效 |
| 客户与项目数字很快过期 | 动态事实被手抄 | 文档只留查询入口与口径 | 定期复制业务表 |
| 新旧规则互相冲突 | 没有替代关系 | 保留历史，标适用截止与替代项 | 静默覆盖旧证据 |
| Agent 引用过时答案 | 无复核日和事实截止日 | 到期降级或转人工核验 | 让模型自行判断新旧 |
这也是知识治理与 RAG 项目的分界：RAG 能改善检索，但不能替企业决定哪份制度现行、谁有权批准、哪个系统保存当前状态。想先理解检索边界，可看企业知识库与 RAG 的适用场景和什么是 RAG。
规则一：一个主题只保留一个现行入口
“差旅制度”“产品价格政策”“项目交付规范”这类主题，都只能有一个默认入口。新版未批准时必须标为草案，不能与现行版并列。历史文件可以保留，因为它们可能是当时决策、合同或项目的证据，但默认搜索和导航应先把员工带到现行入口。
Agent 可以维护主题索引、发现重复文档并提出合并建议，却不能把语义相近的文件擅自合并。是否属于同一主题、哪份生效，仍由业务 Owner 判断。
规则二：现行知识至少有六项元数据
每份会影响工作的文档至少写清：状态、Owner、批准人、事实截止日、复核日、替代关系。状态可区分当前有效、草案、历史、待核验或停用；Owner 负责维护，批准人决定生效；事实截止日告诉读者内容反映到哪天；复核日防止长期失养；替代关系说明它替代谁、又是否已被替代。
涉及动态数据时，再增加实时查询入口；涉及案例数字时，再增加证据链接与核验日期。缺少 Owner 或无法确认的内容，应标为待核验，而不是包装成公司规则。
规则三：动态业务事实必须回业务系统
客户负责人、商机阶段、订单、回款、库存、项目进度和员工状态，都应由 CRM、ERP、项目或人事系统保存当前真值。知识库负责解释字段、口径、权限和“去哪里查”，不再维护一份手抄镜像。
判断很简单：如果员工每次查看都期待它是“此刻最新”，就优先回业务系统；如果内容解释“应该怎么做、为什么这样做”，才适合进入现行知识。Agent 回答动态问题时应调用实时系统并附对象与时间，不能拿旧周报或会议纪要补空。
规则四：更新要保留替代关系和证据
事实变化但旧文档仍有历史价值时，新建或发布新版，写清生效日和替代对象；旧版转入历史并保留原文。完全重复的副本只保留一个现行入口。过程文件完成使命后进入项目档案，不混进制度导航。遇到冲突时，先分类为现行规则、动态状态、历史证据或讨论材料，再查对应事实源，无法确认就交给 Owner。
Agent 的作用是巡检，不是替组织拍板
治理型 Agent 可以定期扫描无 Owner、已过复核日、重复标题、断链、互相冲突的版本和被高频引用的过期内容，生成待处理队列；也可以在批准后更新索引、状态和替代关系。人审负责确认主题边界、批准生效和敏感权限。
真正的终态不是“已生成治理报告”，而是再次查询同一主题只进入一个已批准现行入口；旧版明确显示历史与替代对象；动态业务问题能回到有权限的业务系统；所有变更有批准人和审计记录。进一步建设可从企业知识中枢开始；若还要让 Agent 据此执行系统动作，再对照企业上下文工程和企业 AI 落地工程。
从一次清理变成日常机制
首次治理可以从高频主题开始：制度、产品、客户项目方法和交付模板分别选一组，先做主题清单，再为每个主题指定现行入口和 Owner。不要一开始搬完所有历史文件；先把员工最常查、答错代价最高的内容管住。
之后按复核日和变化事件维护。制度批准、产品规则调整、系统字段变化时，由 Owner 发起修订；Agent 生成旧新差异、受影响链接和待更新索引，批准人确认后发布。定期巡检只把新增、复开或已逾期的问题送入队列，避免每次扫描都产生同一批提醒。
治理指标也不应只数文档量。更值得观察的是：无 Owner 的现行知识、复核逾期、同主题多入口、动态事实手抄、旧版误引用、查询无答案后转人工的比例。指标最终要指向“员工和 Agent 能否拿到当前、可追溯、权限正确的答案”。
