Agent知识管理：为何结构化Wiki比向量检索更可靠

大多数 Agent 技术栈在模型需要的事实超出其训练数据时，第一时间就会想到向量数据库。当答案埋藏在多年的工单和遗留的 Wiki 页面中时，这种直觉是合理的。但当答案是一个你的团队早已达成共识、已经写下来、却每次有人"改进"它时仍在 Slack 上争论的定义时，这种直觉就很奇怪了。

以周活跃用户为例。有人问 Agent 如何计算它。你知道答案存在于一份指标文档中——它指向 orders 表，还有一份关于仓库延迟天的数据新鲜度操作手册。Agent 不知道这些。如果按常规方式接入了，它根本没有机会知道。文档被送入分块器，分块器把 WAU 段落和它所依赖的 schema 切开了，查询时检索器返回几个看起来相关的片段，模型由此推断连接关系。有时候它推断对了，有时候它把"签到"当成了"活跃用户"（因为某个入职页面用了"活跃用户"这个词）。你从它返回的流畅段落里，无法判断是模型推理有问题还是检索器给了它错误的切片。

这就是检索增强生成（RAG）在做它被设计做的事情——搜索。你有一堆干草，不知道哪份文档重要。你把这一堆向量化，按相似度排序，让模型拼凑出答案。麻烦始于你用同一套机制去存储一个你已经能命名的事实。把一个已知定义拆成碎片然后指望正确的切片能回来，这是浪费功夫，而且丢弃了指标、表和操作手册之间的链接。

2026 年 4 月，Andrej Karpathy 写下了一种不同的模式。与其每次提问时都从原始文档中重新发现相同的事实，不如维护一份 Agent 可以读取和更新的 Wiki。新来源到来时，模型不只是索引它，而是把有用的部分归档到已有页面中、更新交叉引用，并记录新材料与旧材料的矛盾之处。知识编译一次并保持最新。Google Cloud 在 2026 年 6 月 12 日采纳了这个模式，当时 Sam McVeety 和 Amir Hormati 发布了 Open Knowledge Format。OKF 是这份 Wiki 的共享契约。它是一种格式。你不需要安装它，也不需要向量产品来使用它。

文件夹实际上是什么

一个 OKF 束（bundle）就是一个 Markdown 文件目录。每个文件是一个概念，概念可以是表、指标、API、策略或操作手册。路径即身份。metrics/weekly_active_users.md 既是磁盘上的文件名，也是其他文件引用它时使用的地址。

每个概念文件以 YAML frontmatter 开头。v0.2 规范要求一个字段：type。title、description、tags 和资源 URI 是推荐的，其余都是可选的，包括你的团队想在文档上附加的任何额外键。概念之间用普通 Markdown 链接相互关联，所以这个文件夹是架在目录树之上的一张图。两个保留名称处理导航。index.md 列出目录内容，使 Agent 不用把整个束加载到上下文中就能浏览一层。log.md 是变更日志。你可以把目录作为 git 仓库、tarball 或磁盘文件夹来分发。只要你能 cat 一个文件，你就能读取 OKF。

Google Cloud 的 Knowledge Catalog（原 Dataplex）可以摄入一个束并提供给 Agent 使用。这是众多消费者之一。格式不关心读者是 Knowledge Catalog、Obsidian、GitHub、MkDocs 还是 Agent 循环中的文件读取工具。

一个早晨问题和四个文件

假设你卖一个产品，有人问 Agent 如何计算周活跃用户。回答这个问题的束可以小到这样：

sales/
  index.md
  tables/orders.md
  metrics/weekly_active_users.md
  playbooks/orders_freshness.md

index.md 是地图。规范把 frontmatter 排除在 index 文件之外，束根目录上有一个可选的 version 键除外。

# Sales

* [Orders](tables/orders.md) - One row per completed customer order.
* [Weekly active users](metrics/weekly_active_users.md) - Unique customers with a delivered order in the last 7 days.
* [Orders freshness](playbooks/orders_freshness.md) - What to do when `orders` lags the SLA.

指标文件陈述事实并指向它所依赖的表。

---
type: Metric
title: "Weekly active users"
description: "Unique customers with a delivered order in the last 7 days."
tags: [sales, activation]
verified:
  - { by: human:finance@acme, at: 2026-07-01T09:00:00Z }
stale_after: 2026-12-31T00:00:00Z
---

# Definition

A weekly active user is a distinct `customer_id` on [orders](/tables/orders.md) with `order_status = 'delivered'` and `order_ts` in the last 7 days.

# Notes

Do not count accounts that only signed in. Activity here means a completed order. If `orders` is late, stop and follow the [freshness playbook](/playbooks/orders_freshness.md).

表文件保存了细节和连接。操作手册保存了分类步骤。这些都没有埋在一份冗长的 Confluence 页面里。

Agent 读取 index.md，打开指标文件，循着链接到 orders，只有在数据新鲜度有疑问时才打开操作手册。路径解析就是遍历。没有嵌入步骤，没有排序步骤，因为关系已经作为链接写好了。外键、指标源表和同时用到两者的操作手册都放在文件里。向量检索会把这些相同的关系拍平成分散文本，然后让模型去猜它本应直接拿到的结构。

现在用 RAG 的方式跑同样的早晨场景。你把仓库文档、财务策略和去年的事故记录一股脑倒进向量存储。分块器把 WAU 段落和 orders schema 切开，把"仅限已发货"规则和下面两个标题处的说明切开。检索器返回碎片，模型写出一段自信的段落。如果段落错了，你有两个嫌疑人——推理者和检索器——而且没有办法干净利落地分辨他们。直接读取文件只留一个。

同样的文件对人类也适用。你可以 cat 它们、在 GitHub 上预览、在 Obsidian 中打开、在有人把"活跃"改成"仅签到"那天运行 git blame。你和事实之间没有 SDK。过时的 WAU 定义变成一个 PR，而不是一次静默的重新索引。回滚是 git revert。审查就是你已经有的代码审查习惯。

成本也遵循这种形态。对于 Agent 在几乎每个任务中都会读取的一小组事实，你跳过嵌入、向量数据库和重排器，只为它实际打开的概念支付文件读取的 token。index.md 是防止账单变成"加载整个 Wiki"的方式。如果你往上下文中倾注数千个概念文件，你就会故意重建那堆干草。精心策划的核心必须保持小规模，否则你就发明了第二个搜索问题并把它叫做知识库。

当 Agent 编写 Wiki 时

v0.1 是文件夹和链接。2026 年 7 月 24 日发布的 v0.2，是把文件夹当作机器会持续写入的知识库来对待的部分。人写的页面附带了隐含的保证。你可以走到走廊下去问。一夜之间生成的万个概念不会给你那种保证，所以规范把信任问题放在 frontmatter 中，消费者无需在正文上花 token 就能读到。

新字段是可选的，它们的缺失本身就有含义。未经验证的概念和已验证的概念可区分。sources 记录一个概念构建自什么。generated 记录当前文本是谁写的以及何时写的。verified 是一个单独的确认列表，由人或机器确认，消费者由此得出信任层级：未验证、机器确认或人工审核。status 让概念经历草稿、稳定和弃用的流程。stale_after 是一个绝对日期，所以陈旧性是一个可以在代码中运行的比较。

OKF 记录这些信号。它不计算可信度分数，因为分数是主观的、在消费者之间不能迁移、而且在你写下的瞬间就过时了。谁读取束谁决定这些信号的价值。

另一个新增是 Attested Computation（可验证计算），它存在于比"这句话从哪里来"更棘手的时刻。Agent 报告了一个美元数字。它是按财务规定的方式产生那个数字的，还是自己编了 SQL？可验证计算本身就是一个概念。它携带批准过的查询或 API 调用、Agent 可以填充的参数、一个执行器和一个不含语言模型的确定性验证者。Agent 提供值。它不编辑计算。执行器返回收据，验证者检查运行的东西与磁盘上的东西是否匹配。被替换的表名会通过检查失败。这是从向量索引中检索相似查询的另一种工作。

裸 RAG 可以把这些作为块元数据螺栓上去。每个团队发明自己的模式，下一个消费者必须学习它。OKF 写一次字段，任何读者都以相同方式解释它们。

干草堆仍然是干草堆

OKF 不替代检索。Google 没有这么声称，规范对拒绝的工作有明确说明。它不规定存储、服务或查询引擎。它不吞并 OpenAPI 或你的仓库目录。它指向那些东西。

当语料库庞大且你无法预测哪份文档重要时使用 RAG。工单、Slack 帖子、多年积累的 Confluence 和零散的 PDF 属于检索，因为你无法策划你无法命名的东西，而且你不应该试图手工塑造一个变化速度快于你阅读速度的堆。难题只是移了位置。RAG 的难题是检索质量。知识库的难题是陈旧性。如果仓库或财务策略改变时没有任何东西重写文件，OKF 就变成了一个自信的错误答案。选择你实际能解决其难题的那种方案。

两个问题有帮助。你是否已经知道这个事实何时会改变？错误答案代价高昂吗？如果两者都是yes，精心策划它。如果任一者是no，检索它。大多数生产环境 Agent 两者都需要。已命名、高风险的事实进入束。"大概在里面某处"进入向量存储。你甚至可以索引束，因为单概念 Markdown 比原始源转储产生更干净的分块，但周活跃用户的真相来源仍然是 Markdown 文件，而不是索引。

OKF 一侧的失败模式是过度策划。如果你把一切都倒进束并称之为平台，你就会得到第二个无人维护的 Wiki。当 Agent 在几乎每个任务中都读取一个事实且错误答案造成实际损害时，这个事实才值得有一个概念文件。其余的留在检索中。

从你已有的文件开始

你不需要 Google Cloud 来尝试这个。把一个概念放在每个文件中，给它一个 type、一个 title 和一行描述，像人类点击浏览那样链接文件。把束放在 git 中。如果你的文档已经以带稳定路径的版本化 Markdown 形式存在，你已经完成了大部分。如果同一事实出现在三个页面上而页面之间没有链接，没有任何生产者能把那堆乱码变成干净的束。先修文档。

规范很短。仓库附带了 GA4 电商、Stack Overflow、比特币公开数据和一个名为 acme_retail 的虚构零售商的全套示例束，还有一个静态 HTML 可视化器，把任何束转换成一个文件中的图。在把这些名称当作固定之前重新检查规范。knowledge-catalog/okf 下的旧拷贝是一个快照。根据当前仓库来构建。

如果你能命名这个事实，就把它写下来，让 Agent 读取文件。别再让检索器去重新发现它。