再见 RAG？谷歌 OKF 重新定义 AI Agent 的知识接口标准
云朵君约 18 分钟过去三年，企业内部做 AI 应用，架构讨论常常会在一句话里结束：
“上个 RAG。”
把 PDF 切成 chunk，灌进向量数据库，再用语义相似度把相关片段捞回来。这套流程处理模糊搜索、历史资料和长文档时确实好用，也因此逐渐变成了企业 AI 的默认答案。
但到了 2026 年，问题已经不再是 RAG 好不好用，而是我们开始让它处理一些它并不擅长的问题。
比如，让一个企业 AI Agent 回答：
“公司的 Revenue 到底怎么计算？”
听起来只是查一个指标定义。真正跑起来，Agent 却可能找到三份答案：
财务系统里是一套口径；
两年前的战略 PPT 里是另一套；
某个数据工程师留在 Confluence 上的 SQL，又是第三套。
Agent 不是找不到材料。
恰恰相反，它找到的材料太多了。
它不知道哪一份还在生效，哪一份经过审核，哪一份已经废弃；更不知道自己最后报出的数字，是否真的按照公司批准的 SQL 计算。
这正是 “RAG everything” 开始失效的地方。
Chunk 可能把一张复杂表格切碎，向量检索可能把三年前的旧版本排到最新定义前面，频繁变化的业务数据又要求 embedding 和索引不断重建。对于“帮我找出所有提到 Revenue 的材料”，这套机制没有问题；但当问题变成“告诉我公司唯一有效的 Revenue 定义”，相似度检索就开始承担一份它本来不该承担的责任。
因为这时候，企业需要的已经不是“最相关的片段”，而是一个明确答案：
它来自哪里，谁维护，谁审核，何时失效，以及本次计算有没有真正执行被批准的逻辑。
2026 年 6 月 12 日，Google Cloud 发布了 Open Knowledge Format（OKF）v0.1。
它没有再造一个数据库，也没有推出新的 Agent 框架，只定义了一套很薄的开放格式：用 Markdown、YAML frontmatter、目录和链接来组织知识。
43 天后的 7 月 25 日，OKF v0.2 又补上了来源追踪、审核状态、生命周期、时效信号与可验证计算。
我更愿意把这件事理解为：
MCP 正在解决 Agent 如何连接工具，OKF 则开始解决 Agent 连接之后，应该以什么契约读取知识。
这不是 Google 对 RAG 宣战，也不是 Markdown 突然战胜了向量数据库。
OKF 真正挑战的，是企业 AI 中一个已经习以为常、却越来越危险的做法：
把所有上下文都当成可以搜索的文档，却没有为那些不能答错的关键知识，建立明确、可审计、可移植的接口。
01先说结论：OKF 不是检索系统，而是知识交换格式
OKF 的官方定义很克制：它是一种面向人类与 Agent 的开放知识格式，用来表示围绕数据和系统存在的元数据、上下文与经过整理的知识。
翻译成工程语言，它更像一份知识层的数据契约。
一个 OKF Bundle 可以放进 Git 仓库、压成 zip、挂载到文件系统，也可以由知识目录、Agent 或搜索系统消费。格式本身不负责存储服务、查询 API、权限系统和运行时调度。
因此，OKF 不是：
更轻量的向量数据库； RAG 框架； MCP 的替代品； 新的知识图谱数据库； 一套必须绑定 Google Cloud 的 SDK。
它做的事情要小得多，也基础得多：
规定一份知识如何被打包、标识、链接、追踪来源，并向消费者暴露可信度与生命周期信号。
这种“小”反而是它最值得关注的地方。
Agent 工程目前并不缺平台，缺的是不同平台都能读懂的知识接口。
02为什么 Agent 需要“知识接口”
软件系统早就习惯用接口隔离复杂性。
API 不要求调用方理解服务内部如何存储数据；数据库 schema 不要求分析师先阅读所有业务代码；OpenAPI、Protobuf、Avro 也都在做类似的事：把一套内部实现，压缩成稳定、明确、可交换的契约。
但到了 Agent 的知识层，我们经常退回到一种相当原始的状态：
把文档集中起来； 切成 chunk； 做 embedding； 根据相似度召回； 希望模型自己判断哪个片段可信。
对于“找出所有提到退款的客服记录”，这套方法很好用。
对于“退款金额在财务口径中到底如何确认”，它就不够了。
因为后者需要的不是更多相关片段，而是五个非常具体的答案：
这份定义从哪里来？ 谁生成了它？ 谁确认过它？ 它是否仍然有效？ 这次计算是否真的执行了批准的逻辑？
这五个问题，正是 OKF v0.2 试图放进格式层的内容。
03OKF 的最小模型：Bundle、Concept 和 Link
OKF 的结构并不复杂。
1. Bundle：一个目录就是一个知识包
一个 Bundle 是可独立分发的知识目录，例如：
company_knowledge/
├── index.md
├── log.md
├── metrics/
│ ├── index.md
│ ├── weekly-active-users.md
│ └── revenue.md
├── tables/
│ ├── customers.md
│ └── orders.md
└── runbooks/
└── data-freshness-alert.md
这里没有专用二进制格式，也没有中心化注册服务。
目录本身承担第一层信息架构：
metrics/放指标；tables/放数据表；runbooks/放操作手册；子目录还可以继续拆分。
规范推荐使用 Git 分发 Bundle，因为 Git 天然提供历史、归因与 diff；但它同样允许使用 tar、zip，或者作为更大仓库中的一个子目录存在。
2. Concept：一个 Markdown 文件就是一个知识单元
Bundle 中除保留文件外，每个 .md 文件都是一个 Concept。
它可以描述：
一张表； 一个 API； 一个指标； 一份 Runbook； 一条业务政策； 一个可验证计算； 任何可以独立理解的知识单元。
每个 Concept 由两部分组成：
YAML frontmatter； 自由 Markdown 正文。
规范永远只强制一个字段：type。
---
type: Metric
title: Weekly Active Users
description: 过去 7 天内至少触发一次核心事件的去重用户数
resource: https://console.cloud.google.com/bigquery/...
tags: [metrics, engagement]
status: stable
---
OKF 没有中心化的类型注册表。生产者可以写 Metric、BigQuery Table、API Endpoint 或自己的领域类型；消费者遇到不认识的类型时，也不应直接拒绝，而应退化为普通 Concept 处理。
这是一种很典型的“最小互操作面”设计：
标准只管大家必须共同理解的部分； 领域语义继续由生产者扩展； 消费者必须宽容未知字段和未知类型。
3. Link：普通 Markdown 链接组成显式关系图
Concept 之间使用普通 Markdown 链接：
客户维度定义见 [customers](/tables/customers.md)。
订单通过 `customer_id` 与
[customers](/tables/customers.md) 关联。
路径既是地址，也是 Concept ID 的基础。规范把 Concept ID 定义为文件相对 Bundle 的路径，并去掉 .md 后缀。
与向量相似度不同，这种链接不是“模型认为两段内容可能相关”，而是知识生产者明确写下的关系。
不过这里需要避免一个过度解读：
OKF 的链接是显式的，但 v0.2 中的边仍然是无类型关系。
“依赖”“引用”“可连接”“由……计算”等具体语义，仍然由链接周围的自然语言表达。消费者通常可以把链接构造成有向图，但不能仅凭链接本身判断边类型。
这也是 OKF 当前有意留下的扩展空间。
04index.md：Agent 不必一口吞下整个知识库
OKF 保留了两个特殊文件名：
index.md：目录入口；log.md：变更记录。
它们都是可选的，但用途非常关键。
index.md 负责渐进式披露
一个目录下的 index.md 可以先告诉 Agent：
这里有哪些 Concept； 每个文件大致讲什么； 还可以进入哪些子目录。
例如：
# Metrics
- [Weekly Active Users](weekly-active-users.md)
- 过去 7 天内核心事件的去重用户数
- [Revenue](revenue.md)
- 财务认可的收入定义与计算入口
Agent 可以先读索引，再决定是否打开具体文件，而不是每次都把整个知识库塞进上下文窗口。
这和现代 Agent 系统强调的 progressive disclosure 是同一件事：先暴露地图，再按任务加载细节。
log.md 负责解释“知识为什么变了”
log.md 按日期记录更新：
## 2026-07-20
- Update：Revenue 定义增加 30 天退货窗口。
- Deprecation：旧版 Gross Margin 公式停止用于新报表。
Git 已经能记录文件 diff，为什么还要 log.md？
因为 diff 告诉你“哪几行发生了变化”，而日志更适合告诉 Agent“这次变化的业务含义是什么”。
一个是代码级历史，一个是知识级历史。
05OKF 和 RAG 的关系：不是替代，而是分工
原稿最容易写过头的地方，是把 OKF 描述成“确定性检索”，再把 RAG 描述成“概率猜测”。
这个对比有启发性，但不够准确。
OKF 本身不提供完整检索系统，也没有规定 Agent 必须从根目录逐层走到目标文件。一个真实消费者仍然可能使用：
关键词搜索； 向量检索； 图遍历； 规则路由； LLM 规划； 预先构建的索引。
OKF 改变的不是“搜索一定如何发生”，而是搜索命中之后，Agent 拿到的知识是否具有明确结构与治理信号。
更合理的分工是：
因此，一个更现实的架构不是 OKF vs. RAG，而是：
┌──────────────────┐
用户请求 ──────────▶│ Query / Context Router │
└─────────┬────────┘
│
┌──────────────┴──────────────┐
│ │
▼ ▼
探索与召回通道 权威知识通道
RAG / Search / Graph OKF Bundle
历史材料、长文档 指标、Schema
工单、会议、反馈 Runbook、政策
│ │
└──────────────┬──────────────┘
▼
Agent 组合与执行
RAG 可以负责“发现”，OKF 可以负责“确认”。
甚至，向量索引完全可以建立在 OKF Bundle 之上。区别是，召回结果不再只是脱离上下文的 chunk，而是可以回到完整 Concept，继续读取它的来源、状态、链接和审核信息。
所以 OKF 真正反对的不是 RAG。
它反对的是：
把未经治理的文档召回结果，直接当成企业知识的最终答案。
06v0.2 的重点不是更多字段，而是让 Agent 先判断“能不能信”
OKF v0.1 主要解决知识如何包装。
v0.2 开始处理一个更棘手的问题：当知识越来越多由 Agent 自动生成时，另一个 Agent凭什么相信它？
为此，v0.2 增加了四组核心机制。
1. Provenance：记录信号，而不是制造一个“可信分”
sources 字段记录 Concept 从哪些材料中产生：
sources:
- id: revenue-policy
resource: /policies/revenue-recognition.md
title: Revenue Recognition Policy FY2026
author: human:finance-director
usage_count: 1240
last_modified: 2026-06-15
一条来源可以带上：
author；usage_count；last_modified；指向内部或外部材料的 resource。
OKF 在这里做了一个很成熟的选择：它不规定统一可信度分数。
因为“0.87 的可信度”看起来客观，实际上往往只是某个产品内部的一套主观权重。换一个组织、换一个任务，分数就失去可移植性。
OKF 只保存客观信号，判断权留给消费者。
例如：
财务 Agent 可以要求来源必须由财务团队维护； 研究 Agent 可以优先选择最近更新且被大量使用的来源； 测试环境可以接受未审核草稿； 高风险报表只允许使用经过人工确认的定义。
格式负责提供证据，策略由消费端决定。
2. Trust：区分“谁写的”和“谁确认的”
v0.2 把生成与审核拆成两个字段：
generated:
by: reference_agent/gemini-2.5-pro
at: 2026-06-30T14:00:00Z
verified:
- by: human:finance-owner
at: 2026-07-01T09:00:00Z
generated 回答内容由谁、在何时产生或实质更新。
verified 回答谁独立确认过内容。
根据 verified，消费者可以推导三种信任层级：
unverified | verified |
machine-confirmed | |
human-reviewed | human:<id> 确认 |
这些层级是建议信号，不是权限控制。
这一点很重要。
human-reviewed 并不自动等于“绝对正确”，unverified 也不等于“禁止读取”。它们只是让 Agent 在读取正文之前，先做一次成本很低的风险判断。
3. Lifecycle：知识也需要 draft、stable 和 deprecated
OKF v0.2 使用两个字段描述生命周期：
status: stable
stale_after: 2026-12-31
status 有三种状态：
draft → stable → deprecated
字段缺省时按 stable 处理。
stale_after 使用绝对日期，而不是“30 天后过期”这种相对 TTL。这样任何消费者都能用一次普通日期比较判断内容是否已经陈旧，不需要知道它何时首次被读取。
这套设计解决了企业知识库里一个非常常见的问题：
旧定义不能直接删除，因为历史报表还需要复现；但它也不能继续出现在新任务的默认路径上。
deprecated 允许旧知识继续存在，同时告诉消费者不要再用于新的工作。
它比“把旧页面标题前面加上【已废弃】”可靠得多，因为机器不需要先读正文才能发现状态。
4. Attested Computation：不只保存答案，还保存被批准的计算方式
v0.2 最有野心的设计是 Attested Computation。
普通知识文档可以告诉 Agent：
Revenue 是已交付并超过 30 天退货窗口的订单净额。
但真正执行时，Agent 仍然可能：
漏掉退货窗口； 换了一张表； 删除一个 JOIN； 私自增加过滤条件； 输出的数字与实际查询结果不一致。
Attested Computation 试图把“定义正确”和“这一次真的按定义执行”分开验证。
一个 Concept 可以声明：
---
type: Attested Computation
title: Revenue for a fiscal year
runtime: bigquery
parameters:
- name: year
type: integer
required: true
executor:
resource: /skills/run-on-bq.md
receipt: [job_id, executed_sql, result]
attester:
resource: /attesters/sql-equality.py
status: stable
---
正文中的 # Computation 保存批准的 SQL：
SELECT SUM(net_amount) AS revenue
FROM `acme.sales.orders`
WHERE order_status = 'delivered'
AND DATE_DIFF(CURRENT_DATE(), DATE(order_ts), DAY) >= 30
AND EXTRACT(YEAR FROM order_ts) = @year
执行流程大致是：
Agent 只能填入声明过的参数； executor 执行计算； executor 返回 receipt，例如 job_id、实际 SQL 和结果；非 LLM 的确定性 attester 检查 receipt； 实际执行内容与批准逻辑不一致，就返回失败。
这里最值得注意的不是 SQL 对比，而是职责拆分：
verified检查这份定义是否仍符合政策；attestation 检查某一次运行是否真的执行了这份定义。
一个负责“规则对不对”，另一个负责“这次有没有照做”。
同时也必须明确：OKF 自己不执行计算。
它只记录：
应该运行什么； 由什么执行； receipt 应该包含什么； 用什么确定性程序检查。
真正的执行环境、权限、沙箱和运行协议仍然需要外部系统提供。
07一个最小 OKF Bundle 长什么样
下面是一份可以直接理解的最小示例：
demo_bundle/
├── index.md
├── metrics/
│ └── weekly-active-users.md
└── tables/
└── customers.md
metrics/weekly-active-users.md：
---
type: Metric
title: Weekly Active Users
description: 过去 7 天内至少触发一次核心事件的去重用户数
generated:
by: human:data-team
at: 2026-07-28T09:00:00Z
verified:
- by: human:analytics-owner
at: 2026-07-28T10:00:00Z
status: stable
stale_after: 2026-10-01
sources:
- id: event-spec
resource: /policies/core-event-definition.md
title: Core Event Definition
author: team:analytics
last_modified: 2026-07-20
---
# Definition
统计过去 7 天内至少触发一次核心事件的去重用户。
# Exclusions
排除内部测试账号与自动化监控账号。
# Dependencies
用户身份映射见 [customers](/tables/customers.md)。
[^event-spec]: Core Event Definition
从文件内容看，它仍然只是 Markdown。
但对 Agent 来说，它已经不再是一段孤立说明，而是一份带有：
类型； 唯一地址； 依赖关系； 来源； 生成者； 审核者； 生命周期； 过期时间
的知识契约。
08用 40 行 Python 做一个最小校验器
OKF 不要求使用特定 SDK。为了说明它究竟有多薄，下面这个 Python 脚本就能完成最基础的检查：
Concept 是否带 YAML frontmatter； 是否包含必填的 type；Markdown 文件链接是否存在。
运行环境：
python 3.10+
pip install pyyaml
代码：
from __future__ import annotations
from pathlib import Path
import re
import sys
import yaml
LINK_RE = re.compile(r"\[[^\]]+\]\(([^)]+\.md)\)")
def parse_concept(path: Path) -> tuple[dict, str]:
text = path.read_text(encoding="utf-8")
if not text.startswith("---\n"):
raise ValueError(f"{path}: missing YAML frontmatter")
try:
_, raw_meta, body = text.split("---", 2)
except ValueError as exc:
raise ValueError(f"{path}: malformed frontmatter") from exc
meta = yaml.safe_load(raw_meta) or {}
if not isinstance(meta.get("type"), str) or not meta["type"].strip():
raise ValueError(f"{path}: required field 'type' is missing")
return meta, body
def resolve_link(bundle: Path, source: Path, target: str) -> Path:
if target.startswith("/"):
return bundle / target.lstrip("/")
return source.parent / target
def validate_bundle(bundle: Path) -> int:
errors: list[str] = []
reserved = {"index.md", "log.md"}
for path in bundle.rglob("*.md"):
if path.name in reserved:
continue
try:
_, body = parse_concept(path)
for target in LINK_RE.findall(body):
resolved = resolve_link(bundle, path, target).resolve()
if not resolved.exists():
errors.append(f"{path}: broken link -> {target}")
except ValueError as exc:
errors.append(str(exc))
if errors:
print("\n".join(f"ERROR: {item}" for item in errors))
return 1
print("OK: bundle passed basic validation")
return 0
if __name__ == "__main__":
root = Path(sys.argv[1] if len(sys.argv) > 1 else ".").resolve()
raise SystemExit(validate_bundle(root))
执行：
python validate_okf.py ./demo_bundle
预期输出：
OK: bundle passed basic validation
这不是完整的 v0.2 conformance checker。
规范甚至明确要求消费者容忍断链，因此“断链即失败”只是我们自己的工程策略，不是 OKF 的强制规定。
但这个例子说明了一个关键点：OKF 的知识资产没有被锁进专用平台。你可以使用普通脚本、Git Hook、CI、静态站点生成器或 Agent 来读写和验证它。
09为什么是 Markdown，而不是更“专业”的格式
看到这里，一个自然问题是：既然要做知识标准，为什么不用更严格的 JSON Schema、RDF、OWL 或专用图模型？
答案不是 Markdown 表达能力最强，而是它在 Agent 工程里拥有一个很实际的平衡：
人可以直接读
不需要打开专用后台，也不需要写查询。GitHub、VS Code、Obsidian 和普通文本编辑器都能查看。
Agent 可以直接改
模型擅长生成和维护结构化 Markdown，也能在一次任务中更新多个文件、链接和日志。
Git 可以直接审
每次业务定义变化都能进入 PR：
谁改了； 改了哪一行； 为什么改； 谁审核通过。
现有工具可以直接接
搜索、静态站点、CI、脚本、代码 Agent 都已经原生理解文件、路径和 Markdown。
OKF 不是在追求最强语义表达能力，而是在追求最低互操作成本。
这也是它与复杂知识图谱方案最明显的差别：先让知识可以被任何工具读写，再逐步增加必要的治理信号，而不是先建立一整套庞大本体。
10OKF 最值得关注的变化：知识库从“只读资料”变成“Agent 共同维护的状态”
传统企业 Wiki 有一个长期无解的问题：刚上线时内容很完整，半年后就开始腐烂。
不是因为团队不知道文档重要，而是持续维护太琐碎：
schema 改了，忘记更新说明； 指标换了口径，旧链接还在； Runbook 调整了，变更日志没写； 一个概念被拆成三个文件，交叉引用全部过期。
Google 在 OKF 的发布文章中直接引用了 LLM Wiki 的思路：人类会厌倦这些维护工作，模型却不怕重复，也可以一次更新多个文件。
这意味着 OKF 的理想使用方式并不是：
人把知识写完，Agent 只负责读取。
而是：
人和系统定义规则，Agent 持续生成、补充和维护 Concept，人类审核高风险知识，其他 Agent 再消费这些结果。
一旦知识库变成了多 Agent 共同写入的“活系统”，来源、审核、时效和生命周期就不再是锦上添花，而是最低治理要求。
从这个角度看，v0.2 才真正暴露了 OKF 的长期方向。
v0.1 是文件格式。
v0.2 开始像知识供应链协议。
11现在还不能对 OKF 期待过高
OKF 值得关注，但它仍然是非常早期的标准。
官方规范明确把以下问题留给后续版本：
receipt 与 verdict 的完整线协议； attester 的 ABI、可移植性与沙箱； attestation 缓存； Looker、dbt 等语义层的等价性验证模板。
除此之外，实际落地还会遇到一些规范没有替你解决的问题。
1. 它没有权限模型
Markdown 可读，不代表所有 Agent 都应该读取。
真正进入企业环境后，仍然需要仓库权限、数据权限、密钥管理和消费侧策略。
2. 它没有规定完整查询协议
OKF 告诉消费者知识长什么样，却没有规定用户问一句话后，必须如何找到目标 Concept。
Router、搜索索引、图遍历和上下文装配仍然要自己实现。
3. 它没有统一领域 taxonomy
type 只有格式约束，没有中心注册。
这保证了灵活性，也意味着两个组织可能分别使用 Metric、Business Metric 和 KPI Definition 表达相近概念。跨组织互操作仍然需要约定或映射。
4. 显式链接也会腐烂
规范要求消费者容忍断链，但容忍不等于断链没有成本。
要让 Bundle 真正可靠，团队仍然需要 CI 检查、自动索引、所有者机制和定期复核。
5. Attested Computation 目前更像协议草图
它给出了很有价值的职责边界，但完整生产运行时还没有被标准化。不同团队仍然要自己实现 executor、receipt、attester 和阻断逻辑。
因此，OKF 目前更适合进入技术评估队列，而不是直接被宣布为企业知识基础设施的最终答案。
12值不值得在下一个 Sprint 试一下
我的判断是：值得，但不要从“建设公司级知识标准”开始。
最合理的做法，是挑一个已经被 RAG 处理得很别扭的小问题。
例如数据团队可以选择：
5 个核心指标； 3 张关键事实表； 1 份事故 Runbook； 1 条财务或合规政策。
总共做 10 个 Concept，放进一个独立 Git 仓库。
第一步：只做 v0.1 的骨架
先建立：
目录结构； type、title、description；index.md；Concept 之间的显式链接。
不要一开始就实现 Attested Computation。
第二步：给高风险知识补 v0.2 信号
对 Revenue、Churn、Active User 这类核心定义增加：
sources；generated；verified；status；stale_after。
第三步：接一个最简单的 Agent
让 Agent 完成三个任务：
找到指标定义； 沿链接读取表结构和 join key； 输出引用的 Concept 路径、状态和审核信息。
第四步：和现有 RAG 做同题对照
重点不是比较“回答看起来谁更聪明”，而是检查：
是否引用了当前定义； 是否错误使用废弃知识； 能否追溯来源； 能否识别未审核内容； 业务口径变更后需要更新几套系统； Agent 消耗了多少上下文。
第五步：只为一个高风险计算做 Attestation
选一条最关键、最稳定的 SQL，验证：
Agent 是否只能填参数； 实际 SQL 能否回收到 receipt； 确定性 attester 能否阻断被修改的查询。
做完这一轮，你才会知道 OKF 对团队究竟是标准、文件约定，还是又一套没人维护的文档目录。
13写在最后
Agent 时代缺的不是更多知识，而是知识的边界。我们一直在努力给 Agent 更多上下文。
更大的窗口、更多文档、更快的向量库、更复杂的 GraphRAG，都在解决“Agent 能不能看到足够多”。
OKF 提出了一个相反的问题：
Agent 看到之后，能不能知道什么是定义，什么是历史，什么经过审核，什么已经过期，以及这次执行有没有照章办事？
这是一个比“召回率再提高几个百分点”更接近生产系统的问题。
RAG 仍然会继续存在，搜索也不会消失。真正可能改变的，是企业不再把所有知识都混成一池可检索文本。
历史材料可以继续被搜索。
讨论过程可以继续被召回。
但那些决定 Agent 是否会算错钱、连错表、执行错误流程的核心知识，应该拥有更明确的接口。
OKF 现在还很年轻，也远没有证明自己会成为行业标准。
但它至少把一个长期被忽略的问题摆到了台面上：
工具调用已经开始标准化，Agent 的知识输入也该有契约了。
参考资料
Google Cloud：Introducing the Open Knowledge Format Google Cloud：Open Knowledge Format v0.2 tackles agentic trust GoogleCloudPlatform / knowledge-catalog：OKF v0.2 SPEC GoogleCloudPlatform / knowledge-catalog：OKF README 与参考实现