OpenWiki 0.2 接入 OKF：把代码库文档整明白，让 Agent 检索少走弯路、少烧 token

如何让编程 Agent 检索代码库文档更高效，避免反复翻查和无效 token 浪费？今天就来拆解 OpenWiki 0.2 接入 OKF 标准背后的逻辑，以及它如何实实在在地改变 Agent 的工作方式，为开发者节省时间与成本。

先把来龙去脉捋一捋：这事得从 Karpathy 的"LLM Wiki"说起

要理解 OpenWiki 0.2 这次更新的分量，得先往前追溯几步。

今年 4 月，Andrej Karpathy 在 GitHub 上发布了一份 gist，提出了"LLM Wiki"的构想，悄然改变了许多人对“如何用大模型管理知识”的认知。他的出发点很直接：目前大多数人使用 LLM 的方式本质上是 RAG——你丢入一堆文档，每次提问时系统从原始资料中检索相关片段，再拼凑出答案。这种方法虽能工作，但有一个明显短板：模型每次都要从零开始“重新发现”知识，无法沉淀任何内容。当遇到需要串联多份文档的复杂问题时，它每次都得重新翻查、重新组合。

Karpathy 建议换个思路：让模型先通读原始资料，将其整理成一套结构化、相互交叉引用的 Markdown wiki，之后所有查询都针对这份“编译好”的知识库。原始资料是生食材，wiki 是做好的熟菜——RAG 相当于每次饿了都从头做菜，而 LLM Wiki 则是搭建一个越用越顺手的厨房。而且这套 wiki 会随着你不断投喂资料、不断提问而逐渐丰富，那些繁琐的维护工作（记录变更、维护交叉引用）全部交给模型，人只需挑选资料、提出好问题。人类维护 wiki 往往半途而废，就是因为这些琐碎记账工作太累，而模型恰恰擅长做这些事。（顺便一提，Karpathy 6 月已加入 Anthropic 的预训练团队，但该模式本身具有很强的独立性，与他所在的公司无关。）

思路火了之后，新问题也浮出水面：大家各自编写 wiki，字段不统一、文件名混乱，你的 wiki 和我的 wiki 无法互通。于是 6 月 12 日，Google Cloud 正式将这套"LLM Wiki"模式标准化，发布了 OKF（Open Knowledge Format，开放知识格式）。简而言之，OKF 是一套厂商中立的开放规范：将知识表示为一个包含 Markdown 文件的目录，每个文件带有 YAML front matter，任何人都可以编写和读取，不绑定任何云平台、模型或 Agent 框架。能 cat 就能查看，能 git clone 就能分发。

而 OpenWiki，正是 LangChain 前段时间基于 Karpathy 的 LLM Wiki 思路开源的 CLI 工具——专门用于为代码库生成和维护文档。此次的 0.2 版本，核心工作可以用一句话概括：将 OpenWiki 与 OKF 新标准对接。

OpenWiki 会为你的仓库生成一份 wiki，将这份 wiki 接入你的编程 Agent，并随着代码变动持续更新文档。初版 OpenWiki 已经能够基于代码库生成和组织 Markdown 文档。但问题在于，大型代码库自然对应大型 wiki——文件数量一多（几百个），结构就会变得混乱，无论是查找、更新、搜索还是评审，没有良好的结构都难以处理。此次接入 OKF，就是为了“把结构理清楚”：wiki 有了更规整的结构，编程 Agent 浏览起来更顺畅，查找信息不再绕路，翻阅文档所花费的时间和 token 自然也就减少了。

OpenWiki 0.2 到底加了啥

在 0.2 版本中，所有由 OpenWiki 生成或更新的 wiki 都遵循 OKF 格式。每个 wiki 文件开头都会包含一段 YAML front matter，其中包含 title、description、tags、categories、资源 URL 等字段。

除了 front matter，OKF 还约定了两个特殊文件：一个是 index.md，为每层目录建立索引，概括该层下的文件和子目录；另一个是 logs.md，记录 wiki 的历次变更，相当于一份 changelog。

这份 changelog 在更新时尤其有用。以前每次运行完一轮，你需要重新扫描整个 wiki 才能知道改了什么；现在只需看一眼 logs.md 就能清楚——改了什么、动了哪些文件、想深入了解该去哪里找，一目了然。

拿 OKF 举个实际例子

OKF 规范的内核非常简单，因此集成到 OpenWiki 中并不费力。YAML front matter 只包含几个关键字段，加起来毫无负担：

---
type:<类型名>                      # 必填 —— 这份文档的核心概念，比如 "BigQuery Schema"
title:<可选，展示用名称>
description:<可选，一句话摘要>
resource:<可选，底层资产的规范URI>
tags:[,,…]            # 可选
timestamp:          # 可选，最后修改时间
# …其他由生产方自定义的键值对
---

每个 wiki 文件都带上这段 front matter 后，index.md 就能“确定性地”自动生成——只需提取各文件 front matter 中的 description 并拼接即可：

# 章节 / 分组标题
* 标题 1 —— 条目 1 的描述
* 标题 2 —— 条目 2 的描述
# 另一个章节
* 子目录 —— 该子目录的描述

至于 log.md，OpenWiki 会在每次运行后自动生成，记录它本次执行的操作。支持 log.md 的工作量并不大，只需在提示词中多补充几句，让 OpenWiki 更新完 wiki 后顺手将 log.md 一并更新：

# 目录更新日志
## 2026-05-22
* **更新**：为 [Customer Metrics](/tables/customer-metrics.md) 新增 BigQuery 表引用。
* **新建**：建立 [Dataplex Playbook](/playbooks/dataplex.md)。
## 2026-05-15
* **初始化**：搭建基础目录结构。
* **更新**：在根 [index](/index.md) 里加入渐进式披露的相关规范。

对 Agent 来说，检索这块儿明显更好使了

OpenWiki 通过 AGENTS.md、CLAUDE.md 等文件将仓库 wiki 暴露给编程 Agent，使它们能够从中检索到所需的上下文。

由于 OKF 为每份文档增加了结构化元数据，OpenWiki 后续的工具可以基于 tags、categories、descriptions 等字段进行“确定性检索”。例如，Agent 可以直接筛选出 BigQuery tables 分类下的所有文档，或者一次性拉取所有带有 billing 标签的文档，而不必完全依赖漫无目的的 agentic search。

Agentic search 当然有其用武之地，但在处理简单查询时往往既慢又耗费 token。有了结构化元数据作为基础，OpenWiki 就能走一条更干净、更快速的检索路径。

顺带接入了整个 OKF 生态

正因为 OKF 是一种开放格式，OpenWiki 生成的 wiki 可以直接对接社区开发的各种查看器、渲染器、linter 等工具，无需逐一单独集成。近期涌现出一批开源生态项目，这篇文章有整理：https://www.owox.com/blog/articles/okf-ecosystem-tools。

这样一来，OpenWiki 用户今天就能获得一个更标准的 wiki 格式，同时也为 LangChain 后续要开发的工具打下了更坚实的地基。

Google 还开源了一个 OKF wiki 可视化工具，可用于查看你的 wiki，并直观展示文档之间的相互关联。下面这张图是用 OpenSWE 仓库跑出来的效果：

想上手 OpenWiki 0.2

老用户直接升级即可，之后生成和更新的 wiki 都会自动采用 OKF 格式。如果是第一次使用，安装后几分钟就能为自己的仓库生成一套 wiki。

仓库地址：https://github.com/langchain-ai/openwiki

在本地运行只需两行命令：

npm install -g openwiki@latest
openwiki --init