LLM 知识库

最近我发现一个很有用的做法：利用 LLM 为各种研究兴趣主题构建个人知识库。这样，我近期大量的 token 消耗不再主要用于操作代码，而是更多地用于操作——

你的 AI 代理为何总在上下文理解上出错

AI 代理的瓶颈往往不是推理能力，而是找到正确的上下文。Google 的 Open Knowledge Format 提出了一种可移植的组织知识标准。

6 分钟内你将了解：AI 代理为何在碎片化的组织知识中挣扎、OKF 的工作原理，以及 Google 为何认为格式而非平台将定义下一层 AI 基础设施。

表的 schema 存在于一个拥有专有 API 的数据目录中。指标的业务定义存在于一个没人更新的 Confluence 维基里。

两个系统之间的连接路径存在于一位三月份离职的高级工程师的头脑中。

当代理需要回答“如何从事件流计算周活跃用户”时，它必须从这些分散、互不兼容的信息源中拼凑答案。

知识是存在的。但共享知识的格式却不存在。

Google 刚刚发布了一个解决此问题的提案。

它被称为 Open Knowledge Format (OKF)。目前大多数团队仍在从头解决这个问题。OKF 的主张是：他们本不必如此。

问题在于格式碎片化

知识存在于大多数组织中：表的 schema、指标的业务定义、系统间的连接路径、事件复盘手册、旧 API 的废弃通知。

这些上下文原子，正是区分一个代理给出通用答案与给出正确答案的关键。

问题在于它们存放在哪里。

带有专有 API 的数据目录。Confluence 或 Notion 中的维基。代码注释和文档字符串。高级工程师的头脑中。每个系统都使用自己的格式、自己的 schema、自己的访问模型。

每个构建代理的团队都独立地解决这种拼凑问题。知识被创建它的系统锁死在特定格式中。

在 OKF 出现之前，团队们已经在趋同于同一种非正式解决方案。

Andrej Karpathy 在一篇被广泛引用的 gist 中阐述过：给 LLM 一个共享的 markdown 库，它会随着时间推移越来越有用；让代理读取并更新自己的文件；像管理代码一样管理内容。

Andrej Karpathy @karpathy · 4月3日
LLM 知识库
最近我发现一个很有用的做法：利用 LLM 为各种研究兴趣主题构建个人知识库。这样，我近期大量的 token 消耗不再主要用于操作代码，而是更多地用于操作…
2.8K 9.3K 59K 21M

这种模式反复独立出现：与编码代理相连的 Obsidian 知识库、AGENTS.md 和 CLAUDE.md 约定文件、数据团队内部的元数据即代码仓库。

每个实例都是定制的。它们看起来都很相似（markdown、YAML 前置元数据、交叉链接），但没有一个是为了协作而设计的。没有统一的字段、统一的保留文件名、没有互操作性。

OKF 正是对这种模式的正式化。

OKF 究竟是什么

一个 bundle 是一个 markdown 文件目录。每个文件代表一个概念：一张表、一个数据集、一个指标、一本手册、一个 API 端点，任何值得记录的东西。文件路径即为概念的标识符。

每个概念都有一个 YAML 前置元数据块和一个 markdown 正文。前置元数据有一个必填字段：

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---

type 是必填的。其他所有字段都是可选的。

生产者可以添加任意额外的字段。消费者必须容忍未知字段，不能拒绝整个文档。

概念之间通过标准的 markdown 链接相互关联，将目录转换成一个可遍历的关系图。

两个保留文件名有特殊含义：index.md 用于目录列表，log.md 用于变更的按时间顺序的历史记录。

这就是整个格式。完整的 v0.1 规范只占一页篇幅。

三个值得理解的设计选择

1. 只有一个必填字段。

OKF 对每个概念只要求一件事：一个 type 字段。存在哪些类型、包含哪些其他字段、正文包含哪些章节，全部交给生产者决定。

该规范定义了互操作性的表面，而不是内容模型。这是一个刻意的赌注：最小的共享表面优于一个没人完全采纳的全面 schema。

2. 生产者与消费者独立。

由人类手写的 bundle 可以被 AI 代理消费。由元数据导出管道生成的 bundle 可以在可视化工具中浏览。由一个 LLM 合成的 bundle 可以被另一个 LLM 查询。

格式就是契约。各端的工具可以独立替换。

3. 格式，而非平台。

没有 schema 注册中心。没有中央权威。没有必需的工具。如果你能 cat 一个文件，你就能读取 OKF。如果你能 git clone 一个仓库，你就能分发它。

知识格式的价值在于有多少方使用它，而不在于谁拥有它。

Google 的赌注

就像 JSON 为数据提供了通用的交换格式一样，OKF 认为组织知识也需要同样的东西。

JSON 之所以能赢，是因为它简单到几乎任何地方都能采用。格式本身就是贡献。生态系统随之而来。

OKF 对知识提出了同样的论点。不是另一个平台。不是另一个目录服务。不是另一个带有专有 API 的知识图谱。

而是一种任何人都可以在没有 SDK 的情况下生成、任何人都可以在没有集成的情况下消费的格式。

这个论点是否正确，取决于采纳度。OKF 是一个来自单一供应商的 v0.1 草案。

这个领域已有先例：DataHub、Amundsen、OpenMetadata、DCAT、Schema.org。

它们与 OKF 不完全相同，但这个领域并非空白。不同之处在于 OKF 的极简主义和 git 原生的分发模型。之前的目录格式需要基础设施。

OKF 只需要一个文本编辑器和一个目录。这对于采纳门槛来说是显著差异。

Google 随规范一同发布了参考富化代理、静态可视化工具和三个示例 bundle。

它还更新了 Google Cloud 的 Knowledge Catalog，使其能够导入 OKF 并将其提供给代理。

这表明 Google 不仅在发布一个希望别人采纳的标准，而且内部也在使用它。

如果你正在构建代理，这为什么重要

上下文拼凑问题不会消失。随着代理能力越来越强，其输出质量越来越依赖于它所能获取的上下文质量。

前沿模型之间的能力差距正在缩小。组织知识之间的差距却没有。

如果 OKF 获得采纳，知识将在团队、工具和组织之间变得可移植，无需自定义集成工作。

上下文拼凑将变成一个格式问题，而不是一个定制的工程问题。如果这个论点成立，那么将是格式——而非平台——定义代理生态系统如何共享上下文。

每个代理框架最终都会遇到同一个问题：

在代理能够推理之前，它必须找到正确的上下文。

大部分工程工作并不在推理步骤上。

而是在于拼凑推理所需的知识。

OKF 是一个标准化这一层的提案。