什么是 OKF，知识库如何利用它
OKF v0.1 是一种面向人和 Agent 的知识包格式：用目录里的 Markdown 文件表示知识单元，用 YAML frontmatter 放 type、title、description、resource、tags、timestamp 等元数据，用 index.md 做渐进式目录。知识库可以把制度、流程、FAQ、话术和案例整理成 OKF 知识包，再把目录和摘要暴露给检索系统与 Agent，命中后读取完整正文，并通过变化发现持续维护。
企业知识库接入 AI 之后，模型读到哪份知识经常决定回答能否可靠。销售政策改了，客服话术没跟上；费用报销规则更新了，项目群里还在传旧版本；新人入职时，能搜到十篇文档，却不知道该按哪一篇执行。
Google Cloud 在 2026 年 6 月 12 日发布的 Open Knowledge Format v0.1，处理的是知识进入检索系统和 Agent 之前的形态。OKF 位于原始文档和知识库索引之间，把制度、流程、FAQ、话术、案例这些材料整理成一组可交换的知识文件。知识库可以继续负责搜索、权限、问答和门户体验，OKF 负责把知识整理成稳定、可读、可迁移的包。
OKF 是一种知识包格式
OKF 的核心对象叫 Knowledge Bundle，可以理解成一个知识包。一个知识包就是一棵目录树，里面主要放 Markdown 文件。
普通 .md 文件是一个知识单元，规范里叫 concept document。它可以表示一条制度、一段流程、一个 FAQ、一份销售话术、一次案例复盘，也可以表示数据表、指标、接口、运行手册这类更技术的对象。
每个知识单元由两部分组成：顶部的 YAML frontmatter 放元数据，下面的 Markdown 正文放内容。index.md 用作目录，让人和 Agent 先看到这个目录下有哪些知识。log.md 记录变化。普通 Markdown 链接把相关知识串起来，# Citations 放外部来源或内部依据。
官方规范把 OKF 设计得很轻。知识单元强制字段只有 type，表示这份知识的类型。title、description、resource、tags、timestamp 是推荐字段。生产者可以加自己的字段，消费者也要容忍未知字段、缺失目录和暂时断掉的链接。
放到知识库里看，这个取舍很实用。企业制度、客服经验、销售口径和项目交接本来就很难放进同一套复杂分类。OKF 先要求知识可识别、可链接、可遍历，后面的分类和治理规则留给企业自己扩展。
知识单元是带元数据的 Markdown
一个企业知识库里的 OKF 文件可以这样写：
---
type: Policy
title: 差旅报销规则
description: 员工出差时交通、住宿、餐补和审批的报销边界。
resource: https://wiki.example.com/hr/travel-expense
tags: [HR, finance, expense]
owner: 人力行政
status: current
timestamp: 2026-06-16T10:00:00Z
---
# 适用范围
适用于正式员工的国内出差报销。
# 关键规则
- 高铁默认二等座。
- 酒店标准按城市等级执行。
- 超标准费用需要部门负责人审批。
# 关联流程
超标准住宿审批见 [费用审批流程](/processes/expense-approval.md)。
# Citations
[1] [人力行政部差旅制度](https://wiki.example.com/hr/travel-expense)这份文件做了三件事。type 告诉知识库这是一条制度，title 和 description 让检索系统和 Agent 能先看摘要，resource 和 # Citations 指回正式来源。owner、status 这类字段属于企业自己的扩展，用来支持负责人确认、过期标记和治理流程。
正文保持 Markdown，就能被人直接审阅，也能被版本管理系统做 diff。知识库可以把正文切块做索引，也可以直接把整份文件作为可审查的知识单元保存。
index.md 是知识库入口
知识库用 OKF 时，index.md 很关键。它让人和 Agent 在打开具体正文之前，先看到目录、主题和入口。
一个最小的企业知识包可以这样组织：
knowledge/
index.md
policies/
index.md
travel-expense.md
customer-discount.md
processes/
index.md
expense-approval.md
customer-escalation.md
playbooks/
index.md
enterprise-sales.md
new-employee-onboarding.md
cases/
key-account-renewal.md
log.md根目录 index.md 可以这样写：
# 企业知识目录
## 制度口径
* [差旅报销规则](policies/travel-expense.md) - 交通、住宿、餐补和超标准审批规则。
* [客户折扣规则](policies/customer-discount.md) - 不同客户级别的折扣边界和审批要求。
## 业务流程
* [费用审批流程](processes/expense-approval.md) - 从提交申请到财务打款的处理步骤。
* [客服升级流程](processes/customer-escalation.md) - 普通问题、重点客户问题和投诉问题的升级路径。
## 工作手册
* [企业客户销售手册](playbooks/enterprise-sales.md) - 重点客户跟进、报价、合同和交付交接的常用口径。
* [新员工入职手册](playbooks/new-employee-onboarding.md) - 入职前 30 天需要完成的账号、培训和流程事项。
## 案例复盘
* [重点客户续约复盘](cases/key-account-renewal.md) - 一次续约项目里的决策记录、风险点和后续动作。index.md 只列入口，细节放在具体文件里。子目录里的 index.md 也类似，比如 policies/index.md 只列制度，processes/index.md 只列流程。
知识库可以用这些目录生成导航页，也可以把它们作为 Agent 的第一层上下文。这样 Agent 先知道有哪些知识，再决定打开哪一份。
知识库先暴露目录和摘要
OKF 暴露给 Agent 的方式，可以参考 skills 的加载方式：Agent 一开始只看到 skill 的 name 和 description，命中后再加载完整说明。知识库用 OKF 时，也可以先暴露两类轻量信息：index.md 里的目录说明，以及每个知识文件 frontmatter 里的 type、title、description、tags、timestamp。
对 Agent 来说，第一层看到的可以是这样：
policies/customer-discount.md
type: Policy
title: 客户折扣规则
description: 不同客户级别的折扣边界和审批要求。
tags: sales, finance
processes/customer-escalation.md
type: Process
title: 客服升级流程
description: 普通问题、重点客户问题和投诉问题的升级路径。
tags: customer-service, escalation当用户问“这个重点客户能不能给 15% 折扣”时，Agent 先从这些摘要里选中 policies/customer-discount.md，再打开正文。如果正文里链接到审批流程或历史续约案例，它再继续读取 processes/... 或 cases/...。
这套方式对知识库也有价值。检索系统可以先索引 frontmatter 和 index.md，把它们作为召回和预览层；命中以后再读取正文和引用来源。上下文按问题逐步加载，既省空间，也减少拿错资料的概率。
现有知识库如何转成 OKF
企业很少从一套干净知识库开始。历史文档可能散在网盘、企业 wiki、群文件、邮件附件、项目空间、CRM 备注和客服工单里。一开始就重写所有文档，成本太高，也很容易把旧口径误当成当前口径。
第一轮先找入口。每发现一份文档，先记录它的标题、来源位置、所属部门、负责人、更新时间、当前状态和一句话说明。状态可以先粗一点：current 表示当前有效，stale 表示疑似过期，duplicate 表示和别的文档重复，unknown 表示还没人确认。
这张清单本身就可以是第一版 OKF 索引：
# 存量知识盘点
## 待确认制度
* [2024 版差旅报销规则](raw/hr/travel-expense-2024.md) - 来源：网盘；状态：unknown；负责人：人力行政。
* [销售折扣审批口径](raw/sales/discount-approval.md) - 来源：销售群公告；状态：stale；负责人：销售运营。
## 可直接整理
* [客服投诉升级说明](raw/support/escalation.md) - 来源：客服知识库；状态：current；负责人：客服主管。
* [新员工入职流程](raw/hr/onboarding.md) - 来源：企业 wiki；状态：current；负责人：HRBP。清单稳定后，再按使用频率和风险排序。先处理报销、折扣、客服升级、入职、项目交接这类最常被问、最容易答错的内容。每处理一类，就确认唯一事实源，把重复文档合并或标记废弃，再抽出 type、title、description、tags、owner、status、timestamp 这些字段。
没有成体系原始文档时，流程也类似。先建目录和几个核心类型，再为制度、流程、FAQ、话术各建一个文件。每个文件先写清三件事：它是什么，对应哪份正式来源，和哪些知识有关。正文用表格、步骤、适用范围、例外情况和引用依据来写，后面再补负责人、评审和废弃标记。
持续维护靠变化发现和低成本确认
知识库转成 OKF 以后，维护对象变成一组可审查的文件和元数据。系统可以定时从企业 wiki、网盘、CRM、客服工单和项目空间里发现变化，把变化整理成候选知识单元或候选差异，再用 owner、status、timestamp 标出谁需要确认、当前是否有效、上次什么时候更新。
这条发现链路会消耗资源。系统要扫增量、去重、抽摘要、比对旧版本，还要判断变化是否值得进入知识包。日常发现可以交给小参数模型加规则来做：抽标题、摘要、负责人、时间和差异类型，小参数模型通常够用。复杂判断再交给负责人确认。
比如差旅制度变了，自动化流程可以更新 policies/travel-expense.md，把状态标成 needs_review，交给人力行政确认。销售折扣口径变了，只生成折扣边界和审批要求的差异，让销售运营看一眼。客服工单里反复出现同一类投诉，系统可以生成一条 FAQ 候选项，客服主管确认后再进入正式目录。
知识管理和文档治理是长期工程，后面会不断调类型、目录、确认流程和过期规则。没有银弹。OKF 提供一个约定俗成的文件格式，让知识库围绕同一组文件和元数据持续优化。