从 RAG 到 OKF 0.2：让会议助手用对知识（下）

1. 背景

最近在做会议模块的 Agent 开发，调研了不少技术方案。老板让我准备一场内部技术分享，我觉得只讲某一个框架，能覆盖的内容还是有限，于是把从传统 RAG 到 OKF 0.2 的技术脉络整理了一遍，作为这次分享的内容，希望大家能从整体上理解这些方案分别解决什么问题、又可以怎样组合使用。

整理下来内容比较长，所以分成上、中、下三篇。三篇都从同一个会议场景出发，逐步讨论检索、关系、时序、文档导航，以及知识的维护与交付。

完整文档和配套数据示例已经上传到 GitHub：rag-knowledge-lab。可以把仓库拉到本地，按照 README 启动数据实验室，结合文章对照原文、文本切块、检索结果和知识关系，理解起来会更直观。

比如，我们的会议模块就面临下面三个问题：

1. 怎样根据会议内容实时检索？ 会议中会不断推送文档、任务和项目目标，怎样根据当前对话或用户的问题，及时找到相关资料？
2. 怎样避免上下文爆炸？ 如果把所有文档、任务、项目目标和会议内容都放进 LLM，上下文很快就会膨胀。怎样让模型只读取当前需要的内容，同时保留必要的背景和依据？
3. 怎样处理不断变化的结论？ 会议开到第三个小时，可能推翻第一个小时的决定；下一周的会议，又可能调整上一周的方案。怎样保留这些变化，并在用户提问时给出当前适用的结论？

前两篇介绍了怎样检索资料、追查关系，以及处理时间变化和多轮查询。这一篇继续看整理好的知识怎样保存、更新和共享，主要介绍 LLM Wiki 和 OKF 0.2。最后把这些方案放在一起对比，再回到会议场景，看看可以怎样组合使用。

2. LLM Wiki：把整理好的知识保存下来

同一个问题，为什么每次都要重新整理资料

资料按时间或来源保存，问题却常常围绕某个项目、概念或决定。回答一个问题，往往要拼几份材料。

例如，一份接口更新说明和一份故障复盘都涉及支付回调丢失。回答“为什么会丢失、怎样补偿”，需要把两份材料中的现象、原因和处理办法整理到一起。如果这些解释只留在当次回答里，下次遇到相近问题，系统仍可能重新做一遍。

把解释保存成带来源的知识页

LLM Wiki 用 LLM 把资料整理成知识页，并持续更新。可以用 Markdown 给项目、概念或规则各建一页，写清解释，保留原文来源，链接相关页面。

人和 Agent 都可以阅读、查找和修改这套 Wiki。Karpathy 的原始说明将维护过程组织为摄取、查询和检查等活动。

一个类比：RAG 像解释器，LLM Wiki 像编译器

这个类比看的是整理时机：RAG 常在提问后综合资料，Wiki 提前整理好知识页，后面直接复用。

比如提前建一页“支付回调丢失与补偿”，写清原因、处理流程和条件，并链接两份原文。以后再问，就能复用这份 “编译产物” 。

提前整理能减少重复工作，但错误和过时结论也可能被反复使用，所以页面要持续检查、更新。

这个类比有边界： 微软 GraphRAG 的标准流程会预先生成社区报告，Wiki 查询也仍需检索和推理，必要时回查原文。 两者可以结合；这里强调的是把跨资料的解释长期维护成知识页。

LLM Wiki 怎样工作

一套 Wiki 可以区分三类内容：

知识编译与更新：把新材料整理进已有页面

下面是一种可采用的维护流程。“知识编译”生成的是外部知识文件，不涉及训练模型参数。

第 1 步：保存原始材料，定位受影响的页面。

先保存原文和来源，再按目录、命名规则找相关页面。已有页面就更新，避免同一个概念换个名字又建一页。

第 2 步：提取新增内容，比较已有说法。

模型对照新旧内容，找出新增事实、条件和矛盾。分不清是补充还是替代时，先保留差异和依据，别直接覆盖。

第 3 步：修订知识页面，补齐来源和关联。

修改对应主题页，补上来源，检查关联页面是否也要改。原有条件和人工修正要保留。

第 4 步：检查修订，再保存新版本。

核对重要结论是否有来源、链接是否有效、相关页面是否一致，再保存页面与目录的更新。原始材料继续保留，便于发现遗漏后回查或重建。

持续更新比首次生成更难。多份资料并行进入时，有两类问题需要分别处理：

• 并发写入： 多份资料可能同时修改一页。页面版本锁能识别并发修改；AWS 的实践以 Parse、Plan、Generate 分工，讨论了规划串行推进、页面并行生成，以及保留人工确认修正的机制。
• 概念去重： 不同资料也可能各自新建了同一概念的页面。“两个不同文件其实在讲同一个概念”，还需要语义层面的去重。

查询与维护：复用已有解释，再按需补查

第 1 步：通过目录或检索找到知识页。

根据问题定位相关主题，取得已经整理好的页面及关联入口，缩小需要阅读的范围。

第 2 步：读取解释，补查缺失证据。

读取页面中的事实、条件和来源；证据不足时，继续打开关联页面或回到原文。材料足以支持结论后，再组织回答，避免把整理时的遗漏带进答案。

第 3 步：检查知识缺口，按更新流程修订。

查询中发现新信息，可以提交修订建议，检查后再写回。平时也要检查缺少来源、断链、重复概念和冲突说法。

解释可以复用，修订责任也会持续存在

LLM Wiki 适合反复使用的背景、术语、规范和跨资料解释。整理成果可以跨查询复用，人和 Agent 也能直接检查和修订页面。

代价是写入和维护更复杂：来源变化后要定位受影响页面，错误摘要也可能被后续内容继续引用。实时库存、任务状态等高频数据，通常仍应回到业务系统查询。

Wiki 保存整理后的知识，RAG 找相关页面，原文用来核查。换工具后怎样继续用这些知识，就要看 OKF 这样的格式约定。

3. OKF 0.2：让知识成为可共享、可维护的标准文件

知识整理好了，换一个工具还能继续用吗

企业知识往往分散在技术 Wiki、数据目录、代码注释、接口手册和共享文档中。同一个指标的定义、计算口径和注意事项，还可能散落在不同位置。

即使已经用 LLM 整理过，也会出现新的兼容问题：一个 Agent 使用自定义 JSON，另一个使用 Markdown，第三个把知识放在自己的数据库里。它们对类型、来源、更新时间和关联关系的表达各不相同。

结果是，新接入一个工具，就要重新理解和转换一遍；更换平台，还可能丢失原先维护的引用和人工修正。

换工具时，正文、类型、来源、状态和关联关系都要留下来。OKF 为它们约定统一的文件格式，让不同工具能继续读取和使用。

用开放的文件约定连接生产端和消费端

OKF（Open Knowledge Format，开放知识格式）由 Google Cloud 于 2026 年 6 月推出。 它将 LLM Wiki 一类实践中的共同约定，整理成开放规范，让不同工具生产的知识，可以被其他工具和 Agent 读取、交换与复用。

具体来说，知识以 Markdown 文件保存，头部用 YAML 描述类型等信息，页面之间用链接关联。规范约定这些内容怎样组织和交付，读取、检索与维护则由使用它的工具完成。

OKF 怎样组织和使用知识

基本结构：一个目录、一组概念文件、少量组织约定

一组 OKF 文件称为一个知识包（Bundle）。下面是一个简化示例：

业务知识包/
├── index.md                    总目录
├── log.md                      变更记录
├── 接口/
│   ├── index.md                接口目录
│   └── 支付结果查询接口.md
├── 指标/
│   └── 订单支付成功率.md
└── 运维/
    └── 支付异常排查.md

概念文件：按知识对象组织内容

一个接口、一项指标、一张表或一份操作规程，都可以作为一个 Concept，单独写成 Markdown 文件，放入定义、条件、示例和注意事项。

例如，“订单支付成功率.md”应集中说明这个指标的分子、分母、统计范围和例外情况。其他页面需要解释这个指标时，直接引用它。

文件头部：供程序识别和筛选的说明卡

每份概念文件开头使用 YAML frontmatter，也就是由两行 --- 包围的元数据。正文仍然是普通 Markdown。示例文件可以这样写：

---
type: APIEndpoint
title: 支付结果查询接口
description: 按订单号查询支付结果，用于补查和故障排查
tags: [支付, 接口]
---

# 用途
支付回调未及时到达时，可通过此接口核对订单支付状态。

# 关联说明
故障处理步骤见[支付异常排查](../运维/支付异常排查.md)。

程序通过头部知道文件属于哪类知识、主要讲什么，再决定是否读取正文。这里的 APIEndpoint 是示例类型名，普通概念文件始终必填的字段只有 type，可以按业务补充其他字段。

目录、日志与链接：让文件组成可导航的知识包

index.md 列出本层目录的内容和简介，log.md 记录更新，两者都是可选的。页面之间使用普通 Markdown 链接，表达引用、依赖或补充说明。目录提供层次，链接连接不同目录中的知识。

一种实际用法：构建并消费知识包

下面是一种可采用的使用流程。OKF 约定文件格式，构建、校验和读取由生产工具与消费应用完成。

第 1 步：整理知识对象，写成概念文件。

从文档、Wiki 或业务说明中整理概念，写入类型、正文、条件和来源。已有概念文件尽量复用，减少重复维护。

第 2 步：建立关联，检查后交付。

用链接连接相关概念，按需补充目录和日志，再检查字段、引用与内容。检查后的知识包可以保存到 Git 仓库、文件系统或文件服务，由其他工具读取。

第 3 步：按问题选择文件，检查元数据。

应用先通过目录或检索找文件。比如问“支付成功率如何计算”，先找到指标文件，再检查类型、来源、状态和时效，判断能不能用、要不要复核。

第 4 步：读取正文，按需补查引用。

读取指标定义和条件，需要核对时再打开关联页面。证据不够就补查或说明缺口，不能只凭目录和元数据下结论。

同一份文件，分别满足人工阅读与程序处理

文件头部适合程序处理分类、过滤和索引，正文则保留人能理解的定义、规则和解释。人工维护者可以直接打开文件修订，Agent 也可以读取相同内容。

这减少了“给人写一份文档，再给机器单独维护一份数据”的重复工作。例如，指标口径发生变化，维护者可以同时修改正文定义和头部描述，让阅读界面、检索索引和 Agent 都从同一份源文件取得内容。

这里的共同基础是 Markdown 和 YAML；展示、索引和校验仍可由不同工具完成。

先读目录和简介，再展开正文

OKF 的目录与简介支持 渐进式披露（Progressive Disclosure） ：先知道有哪些知识，再逐步打开相关内容。

先选相关文件，再读详细内容，能少占一些上下文。知识包很大时，也可以先用关键词或向量检索缩小范围，再沿链接补读。

知识变更怎样评审、追踪和回滚

知识采用纯文本文件，就可以接入 Git 的版本管理。一个指标从“包含取消订单”改成“排除取消订单”，差异可以直接显示在变更记录中，由相关负责人评审后合并。

在这种基础上，团队还可以建立自动检查：字段能否解析、内部链接是否存在、关键知识是否保留来源。错误修改可以回滚，也更容易定位哪次变更引入了问题。

这些检查和回滚需要团队或工具执行。log.md 看变更摘要，Git 查具体差异和历史。

更换工具时保留知识，复用时保留链接

一个知识包可以放在 Git 仓库、文件系统或文件服务上，也可以直接打包传输。用一个模型生成的文件，可以由另一个模型读取；自动导出的内容，也可以由人继续维护。

页面链接还支持知识复用。多个业务说明可以引用同一份指标定义，减少各自复制一份后逐渐产生不同口径的问题。

Google Cloud 发布的参考 Agent 和可视化工具只是实现示例。采用 OKF 不要求使用这些工具，也不绑定某个云、模型或 Agent 框架。

新字段出现后，旧工具怎样继续读取

OKF 没有规定企业必须采用同一套知识分类。研发团队可以定义接口类型，数据团队可以定义指标类型；需要项目名、业务域等额外信息时，也可以增加字段。

规范要求读取工具容忍可选字段缺失、未知类型、额外字段和未补齐的链接。旧工具可以先读认识的部分，不必遇到新字段就报错。

这种兼容性保证的是内容能够继续被处理。缺失的证据和失效的链接，仍应由应用识别和提示。

0.2 新增的重点：来源、信任、时效与计算核验

知识一旦开始由 Agent 持续生成，目录清晰还不够。接收方还需要判断：这条内容从哪里来，是谁整理的，有没有被确认，现在是否仍然适用？

OKF 0.2 为这些问题补充了明确的记录方式：

这些信息放在文件头部，使应用能先检查来源和状态，再决定如何使用正文。

来源与确认分开记。 比如 Agent 根据产品文档整理指标，再由负责人核对。生成记录说明“怎么来的”，确认记录说明“检查过什么”，方便区分草稿和已核实内容。

废弃和到期复核也要区分。 废弃接口的说明可以留着解释旧系统；到了复核时间的内容可能仍然正确，只是要再检查。这些字段提供线索，不会自动发现变化或解决冲突。

计算核验：检查数字是否按约定产生

以“订单支付成功率”为例：分母按订单数还是支付尝试次数计算，是否排除取消订单，都会影响结果。仅在正文里写一句“统计支付成功率”，容易让不同 Agent 各自生成不同逻辑。

Attested Computation 允许把批准的计算定义及核验方式一起保存。使用它的应用可以按以下流程执行：

第 1 步：审定口径和计算定义。

先明确分子、分母、统计范围与例外，再审定对应的计算逻辑及核验方式，形成后续执行需要遵守的定义。

第 2 步：由 Agent 填入允许的参数。

Agent 根据问题填写声明允许的参数，例如统计时间区间，形成执行请求。可调整的范围由计算定义约束。

第 3 步：执行计算，返回结果与凭据。

外部执行器运行计算，返回数值及执行凭据，供后续核验实际执行情况。

第 4 步：核对执行与展示结果。

确定性的核验程序检查实际执行是否符合批准的定义，以及展示值是否对应执行结果。应用取得核验结果后，再决定如何使用这次计算。

计算由外部程序执行，OKF 保存计算和核验约定，应用负责调用。计算定义是否还符合业务要求，也要单独复核。

与 LLM Wiki、RAG 的关系

可以这样分工：LLM Wiki 整理和修订，OKF 约定文件格式，检索和 Agent 按问题读取。

文件可以迁移，内容仍需要维护

OKF 适合解决知识被平台绑定、工具反复适配、修改难追踪等问题。采用它的投入，主要在概念整理、字段映射、引用维护和内容校验；检索遗漏、错误原文和复杂事实冲突，仍需要相应的检索与维护机制。

4. 技术方案对比与选型

选型先看缺什么：检索找证据，Agent 决定下一步查什么，Wiki 维护知识，OKF 约定交付格式。这些能力可以组合，下面按做法、收益、成本和场景比较。

回到开头：会议助手该怎样用这些能力

会议助手要解决三件事：找相关资料、控制读取量、用当前有效的结论。下面是一种组合方式。

上下文爆炸：用 Wiki 整理知识，按 OKF 结构逐层读取

先看目录，再按需展开。 LLM Wiki 整理项目背景、术语和设计依据，OKF 用目录、简介和链接组织这些页面。index.md 就是这种读取方式的入口。

会议中可以分三层加载：

例如讨论“支付接口延期”，先找到支付项目的资料入口；问到补偿机制，才读取“支付回调丢失与补偿”页面；问到接口是否验收，再查询任务系统。目录很大时，可以先用检索缩小候选范围，避免把完整目录也塞进提示词。

展开由 Agent 或应用控制。 每轮为近期对话、当前结论和证据预留上下文预算，对召回内容去重、重排，只加载需要的部分。旧字幕保留在外部，通过时间位置回查；压缩后的会议摘要也要链接原始发言，方便纠错。

OKF 0.2 的来源、确认记录和 stale_after 可以提示应用复核，但仍需检查来源是否更新。任务状态直接查业务系统，过时知识页再安排修订。

时序冲突：会内维护当前结论，会后保留变更历史

开会时，先维护一份轻量的议题状态：确认了什么、有哪些建议、哪些问题没解决。 发言和修订记录另外保存。新发言只更新受影响的议题，不用每句话都重建 Wiki。

以支付接入方案为例：

这里需要保留三类信息：

• 确认依据： 谁提出、谁按业务规则确认、对应哪段发言。无法判定时，保留“待确认”或冲突状态。
• 适用范围与替代关系： 改的是哪个项目、客户范围或任务，替代哪条旧结论。后来的一句话不能覆盖所有旧决定。
• 有效时间与记录时间： 结论何时开始适用，以及系统何时获知。周二补录“周一起执行新方案”，这两个时间就不同。

会内回答“现在采用什么方案”，读取当前已确认且适用的结论；问“第一小时为什么选择直连”，则回查当时的决定与依据。下周会议再次变更时，延续同一项目的历史，明确新决定从何时、对哪些对象生效。

关系简单时，事件表加一份当前状态视图就能实现这套逻辑；跨会议、跨项目的关系演变较复杂时，可以用 Graphiti 一类时序知识图谱保存有效区间和来源。确认规则仍由业务定义，模型抽取出的矛盾需要核对。

会后将确认后的决议、设计依据和可复用经验同步到长期知识页，保存来源及历史。临时上下文可以释放，会议证据按留存策略归档；任务状态仍由任务系统维护。

实时检索与关联搜索：从当前议题出发，把证据找齐

实时推送资料时，先记录对象标识、版本、所属项目和来源，再增量更新检索索引。 收到资料到可以检索之间存在处理延迟。 本场会议刚收到的材料可以先进入临时可查询集合；最新任务状态通过业务接口读取，避免等待索引更新。

触发检索可以依据用户提问、议题切换，或新材料与当前议题的相关性。先限定项目、权限、时间与版本，再通过关键词和向量召回找到入口，减少无关资料进入上下文。

例如有人问：“支付结果查询接口延期，会影响谁的工作和哪个目标？”需要沿着关系找到：

支付回调改造 ──依赖──→ 支付结果查询接口
支付回调改造 ──负责人──→ 李明
支付回调改造 ──属于──→ 商城支付升级项目
商城支付升级项目 ──支撑──→ 降低支付漏单率

负责人、项目归属和依赖，优先用任务系统已有字段；文档和会议里的关系再抽取，并保留原文。沿关系找齐任务、人员、目标和资料，过滤、去重、重排后交给模型。关系只能指出可能受影响的对象，具体影响还要核对最新进度和条件。

LightRAG 可以提供实体与关系两路检索；涉及整批资料的共同风险归纳时，可考虑微软 GraphRAG 的社区报告。多轮补查由 Agentic RAG 安排，关系是否当前有效则依赖前面的时序与业务状态检查。

让一个问题走完这条链路

当用户问“按今天的决定，这批新客户该怎么接入、目前卡在哪里”，系统先读取本场会议中已确认的网关接入决定，再通过关系找到依赖的支付结果查询接口，调用任务系统检查验收状态；需要解释技术原因时，按目录展开对应 Wiki 页面，最后附上决定与任务来源。

这样， 渐进式读取控制上下文，时序状态确定采用哪条结论，关联检索补齐证据，实时接口核对当前进展。 Wiki 和 OKF 承担可复用知识的整理与交付，会议中的即时变化通过工作状态、事件记录和业务数据处理。

参考资料

整理这次分享时，我参考了《Agent 知识库这些年：从 RAG 到 OKF 0.2》的议题顺序，再结合会议模块的问题展开。下面只列本篇用到的资料。业务数据是教学示例，流程图做了相应简化。

1. LLM Wiki 原始说明
2. 解释器与编译器类比
3. 知识编译与查询
4. OKF 官方项目
5. Google Cloud 发布说明
6. OKF 规范：概念文件
7. OKF 0.2 官方介绍
8. 传统 RAG
9. GraphRAG
10. LightRAG 项目与查询模式
11. 时序知识图谱
12. PageIndex
13. Agentic RAG
14. GraphRAG 局部检索
15. 《Agent 知识库这些年：从 RAG 到 OKF 0.2》

资料核对日期：2026 年 9 月 16 日。