让 Agent 检索代码库文档更高效，告别反复翻查与无效 token 消耗。
核心内容：
1. OpenWiki 0.2 接入 OKF 标准的意义与背景
2. LLM Wiki 模式如何革新传统 RAG 的文档管理方式
3. 这一整合如何为编程 Agent 带来效率提升

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

先把来龙去脉捋一捋：这事得从 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 当然有它的用武之地，可一碰上简单查询，它往往又慢又费钱。有了结构化元数据打底，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