从 RAG 到 LLM Wiki面向 Agent 的知识组织与消费方式正在变得多样化。上个月Google 发布了 Open Knowledge Format简称 OKF目前版本 0.2。它没有再造一个数据库也没有发明新的检索算法只是在 LLM Wiki 基础上提出了一种朴素的知识格式一组带元数据、互相链接、可以被 Git 管理的 Markdown 文件。本篇我们来深入了解 LLM Wiki、OKF、Obsidian 等知识新概念及其工程关系。试图探索Agent 时代企业需要构建怎样的知识底座全文分两篇一篇侧重概念与方法一篇侧重应用与案例。一、检索很容易但知识没有变得更可靠先说一个常见的软件开发中的场景。公司里有几百份架构与设计文档、几十类软件接口说明、多年的会议纪要还有很多只有资深员工才说得清的业务规则。为了让 AI 使用这些知识我们解析文档、精心切块Chunks、Embedding、入向量库构建了一条典型的 RAG Pipeline。当问题是“系统有哪些模块”或者“这个 API 规格是怎样的”时它通常能用 — 因为这类问题的目标很明确语义检索也很擅长从大量文档中快速找到相关片段。但是当问题变成“如何准确设计一个查询来计算我们上个季度的客户流失率”情况就不同了 —AI 必须先弄清楚本公司的流失率是怎么定义的最新的计算口径是什么退款客户是否包含在内数据来自哪里哪些字段已经废弃这不再是一个简单的事实问题而需要一次“知识探索”。如果依赖经典的 RAG 管道它的工作过程大致如此向量数据库把你的查询转换为向量嵌入召回一批语义相似的需求、设计、会议记录这些知识中可能有并不真正相关的内容、一份两年前的方案、过时的接口与数据说明、冲突的口径等LLM 再揉合成一个非常自信的、但很可能是错误的答案借助一些 RAG 优化如查询重写、融合检索等或 Agentic RAG或许能够提高精确度但基于相似度的概率检索机制以及知识本身并没有质的变化。这里的根本问题是无法提供面向开放任务的探索能力。Agent 像刚接手任务的工程师 — 它需要的不是一堆相似片段而是一张可以不断展开的知识地图。RAG 把一堆“可能相关的原始知识” 搬到 AI 面前但没有替它整理出一套可理解、可导航、可持续维护以确保有效的知识体系。而这正是 Wiki 式知识体系的价值 —RAG 解决的是如何从大量材料中召回候选的“相似”材料。Wiki 式知识体系解决的是在问题之前把有用知识整理成一层带有元数据、相互链接、能够持续维护、能够被 Git 管理的确定性资产。两者解决的重点并不相同。这也是后续理解 LLM Wiki / OKF 的第一把钥匙RAG 给知识增加了一个“搜索框”解决“怎样找到”Wiki 把知识整理成带有“地图”的体系解决“能找到什么”当然Wiki 并非一定取代 RAG它们完全可以有效协作我们将在后续介绍。二、从“搜索框”到持续治理的 LLM WikiWiki 式知识体系的代表是大神 Andrej Karpathy 在 4 月提出的 LLM Wiki 构想。Karpathy 注意到普通 RAG 在每次查询时基于相似度做检索和组装知识块再合成答案但是下一周再问相似问题它从头再来一遍。研究过程中发现的矛盾、建立的联系、形成的结论随着聊天窗口关闭而消失。而 LLM Wiki 的思路则不同它在原始资料与知识消费者之间构建一层持续生长的知识体系与制品Wiki。新资料进入时不是给它做向量索引而是阅读、整理、并融入到现有知识体系 —更新相关知识单元、补上交叉引用链接、发现冲突并解决、更新导航索引与日志把知识“编译成”一组结构化、相互链接的 Wiki 页。 这一切都是由 LLM 来完成。其整体构思如下在这个架构中有几个关键区域通常映射为目录RAW/人类整理的原始文档集供 LLM 读取但不可修改Wiki/LLM “编译”后的 Wiki 知识库SchemaAGENTS.md约定 Wiki 维护的工作流程与规则这样当 Agent 需要探索知识时它可以优先读取这层整理过、结构清晰的 Wiki而不是到原始资料里去“考古”。继续上一节的例子现在“客户流失率”不再只是某份需求文档中的一个片段而可能形成了一张独立的 Wiki 页面。其中明确记录客户流失的计算口径、统计周期、需要使用哪些数据表和字段、当前生效的是哪个版本这些规则分别来自哪些原始材料。与它相关的“客户信息”、“数据表”等知识则通过 Wiki 链接进行引用。在这个知识体系中上述问题的探索过程变成从知识库的根目录读取 index.md根索引了解到在 crm/metrics/ 下有计算指标的方法读取 crm/metrics/index.md二级索引发现 crm/metrics/客户流失率.md读取其中经过审核的 SQL 或 查询脚本文档中有链接到的表结构文档如 crm/tables/customers 等继续读取基于这些知识最终生成完全准确且有效的查询这是一种重要的变化知识不再是临时检索而是被提前整理、持续维护并在使用过程中不断完善。尽管 LLM Wiki 的想法很诱人却有一个现实障碍每个人都能创造自己的 “方言”。比如有的人元数据用tags有人用categories有人从README.md进入有人从 Overview.md进入有人用双向链接有人不用。虽然你看一眼也能明白都是文本但如果 Agent 才是生产者和消费者那你就可能需要经常为 Agent 编写不同的适配层。Google Cloud 发布的 OKF就是为这类知识包定义最低限度的互操作规则。三、OKF让 LLM Wiki 具有互操作性OKF 是 Google 发布的、针对 LLM Wiki 知识形态的一套开放约定。OKF 不规定企业的 LLM Wiki 必须采用哪一种目录和分类而只是统一知识文件、元数据和链接等基本表达规则让一套知识包Knowledge Bundle可以在不同的厂商、不同的 Agent、不同的知识管理工具之间流动减少重复适配。一个 OKF 知识包本质就是一个目录。包含一组 UTF-8 编码的 Markdown 文件每个知识单元被称作概念Concept对应一个文件文件顶部带标准化的 YAML Frontmatter 元数据。如果把规范压缩到最小OKF 目前的约定只有寥寥几条用目录表达层级关系用 Markdown 链接表达知识关系用 index.md 做知识入口为 Agent 提供导航log.md记录知识的变更时间线每个 Markdown 知识单元都要有可解析的 YAML FrontmatterYAML Frontmatter 中唯一必须的元数据字段是type表示本知识单元的类型除此之外规范非常宽松。有title、description、resource、tags、timestamp 等推荐元数据字段而知识正文没有严格限制。OKF 这种宽松设计很适合早期生态却不等于企业可以放弃质量要求。企业仍需有自己的命名约束、断链检查、元数据规则和发布门禁等。换句话说OKF 只是保证互操作的底线但不是知识的质量证明。另外OKF 还处于早期阶段未来可能还会有更多约定加入。这是一个遵循 OKF 约定的知识包其中一个知识单元概念页的内容可能是这样--- type: API Contract title: 创建订单接口 description: 创建普通订单时使用的内部服务契约 resource: repo://order-service/src/api/create-order.yaml tags: [order, api, write] timestamp: 2026-07-20T10:30:0008:00 owner: order-platform --- # 使用条件 仅用于已经完成客户身份核验的订单请求。 # 关键约束 调用前必须执行[订单资格检查](../checklists/order-eligibility.md)。 跨域客户信息通过[客户查询接口](../apis/customer-query.md)获取。 # 证据 - 服务定义order-service/src/api/create-order.yamlcommit - 集成测试order-service/tests/create-order-it.mdcommitOKF 约定每个知识单元的 IDConceptID就是文件路径并使用普通 Markdown 链接表示知识间的关系其含义由周围文字表达。比如跨域客户信息通过[客户查询接口](../apis/customer-query.md)获取。OKF 不做什么OKF 本身是一个知识格式约定但以下不在它的范围不定义和替代领域专用协议如 OpenAPI 、数据库 Schema不定义知识摄入、存储、消费的形式与协议不要求特定的 SDK /工具来写入、读取与发布知识为什么几份 Markdown 到了 Agent 时代反而变得重要Markdown、YAML、目录和链接显然都不是新发明。但 LLM Wiki OKF 把这些熟悉零件组合成了一种更适合 Agent 的知识体系人和 AI 都可以直接读写 — 使用任何你擅长的方式以目录与文件组织而非数据库分发、复制甚至与 Obsidian 协作都简单借助多级的 index.md 实现“渐进式知识加载”无需全部塞进上下文最后总结一下LLM Wiki 是方法关心原始材料怎么被整理成知识层OKF 是格式约定关心知识层怎么被表示、携带和交换。四、如何构建符合 OKF 约定的 LLM Wiki正如上文所说OKF 强调通用且厂商中立 — 你可以使用任何方式读写符合约定的 Wiki 知识库无论生产端还是消费端比如手工编写 OKF 的知识单元让 Coding Agent 扫描代码生成自己编写数据知识导出管道基于框架比如 Google ADK/LangChain开发知识维护 Agent借助 MCP 工具、独立的知识工具如 Obsidian我们来看 Google 公布的一个知识生产 Agent 的参考实现该 Agent 包含了具有通用性的六步流程先发现知识单元逐页建立知识骨架再补充关系链接、生成索引最后审核发布阶段核心动作主要产物1. 圈定来源明确知识范围、权威来源和读取权限Source Manifest2. 发现概念从文件、API 和人工规则中识别知识单元Concept 清单3. 知识写入逐页生成写入元数据、各类知识事实Concept 草稿4. 创建关系补充链接、例外、冲突与共用 Reference知识网络5. 生成导航自底向上生成index.md与log.md渐进索引6. 审核发布校验、生成 Diff、Owner 审核后合并发布的知识包参考这个方法现在假设企业要建设 CRM 客服 Wiki。知识来源包括客户数据模型、投诉流程文档、SLA、CRM OpenAPI、通知和历史工单等。规范负责业务规则API 与数据模型负责系统事实通知必须带有效期工单用于发现知识缺口。先识别稳定的知识单元概念比如business/customer-identity processes/complaint-handling rules/service-level apis/create-service-ticket playbooks/complaint-escalation references/ticket-status-codes起草知识页比如生成“投诉升级规则”时Agent 负责加载 SLA、投诉流程、有效通知和知识单元清单组织内容并链接客户身份、工单状态与升级流程。整体处理的伪代码如下source CRMSource() concepts source.list_concepts() # 生成知识单元概念页 建立链接 for ref in concepts: raw source.read_concept(ref) draft enrich(raw, existing(ref), concepts) validate_and_write(draft, statusdraft) # 构建index.md与log.md rebuild_indexes() publish_after_owner_review()在整个过程中用代码负责检查路径、格式、来源与断链用 LLM 组织语义整理知识CRM 管理者决定什么可以发布。最终得到的是一套可追溯、可导航、能持续维护的 LLM Wiki。