会话结束知识就清零？Google 这个规范想让 Agent 记住团队真正知道的事

作者：王大少

本文给您深度解读Google Open Knowledge Format（OKF）这个Agent开放知识规范。 2026 年 6 月 Google Cloud 发布的 Open Knowledge Format（OKF） v0.1，是一个用「文件夹 + Markdown + YAML 头」来表示团队知识的开放规范。 它不需要服务端、不用云、不用 SDK，用一句话来解释，OKF 就是把「这个系统是怎么回事」写进文件，让任何 Agent 都能按同一套格式读取、更新、和版本追踪。

大家在vibe coding时应该都试过，昨天花一小时讲清楚的东西，今天一开新会话，Agent 全忘了，又要重新开始。

目前的解决办法多数是把重要的事情写在 CLAUDE.md 或 AGENTS.md中，但项目一大，上下文窗口会被塞爆。

OKF 填补的就是这个痛点：团队要知道什么，而不是 Agent 该怎么表现。

OKF 是什么：不是平台，是格式

不要误会 Google 又发布了一个知识管理平台？

OKF 整份规范一页纸能看完，但强制字段只有一个：每个概念文件 YAML 头里的 type。其余全是可选的，由用户自己定义。

从形态来说，OKF就是一个目录（叫 Bundle，知识包），里面全是 .md 文件：

.okf/
├── index.md              ← 入口，按需往下钻
├── log.md                ← 变更日志，最新在前
├── services/
│   ├── index.md
│   └── auth-api.md
├── datasets/
│   └── orders-db.md
├── metrics/
│   └── weekly-active-users.md
└── decisions/
    └── why-we-use-postgres.md

文件路径就是概念 ID。 例如 services/auth-api.md 说的就是 Auth API 这件事，不需要额外的说明。

OKF 这种形态可能也借鉴了一些 Karpathy 的 LLM wiki中的经验，index.md / log.md 这种分层也是LLM Wiki中的模式。

结构拆解：一个文件夹，一张知识图谱

概念文件长什么样

每个 Concept（概念） 对应一个 Markdown 文件，可以是解释一张表、一个指标、一个 API、一条架构决策等。

头信息示例：

---
type: Service
title: "Auth API"
description: "签发和校验短期 access token"
resource: https://github.com/acme/auth
tags: [auth, platform]
timestamp: 2026-06-14T10:00:00Z
---

正文并没有固定模板，但通常会写接口、schema、示例查询。规范推荐用 # Schema、# Examples 这类标题，方便人和 Agent 扫读。

唯一必填的是 type。 你们可以自定类型：Metric、Decision、Runbook、BigQuery Table 都行。OKF 管互操作，不管你的分类体系。

链接把目录变成图

OKF 像Obsidian一样，概念之间可以用 Markdown 链接相互关联。 示例 auth-api.md：

## 为什么单独拆 auth
见 [decisions/why-we-separated-auth.md](../decisions/why-we-separated-auth.md)。

用户范围关联 [datasets/orders-db.md](../datasets/orders-db.md)。

这样读 auth-api.md 的 Agent 可以顺着链接跳到决策文档，再跳到订单表 schema——不用图数据库，顺着链接就能遍历。

两个特殊文件

index.md：渐进式入口。Agent 先读根目录 index，比如看到「metrics 目录下有周活跃定义」，任务相关再打开 metrics/周活跃.md。这和 Claude Skills 的分层加载是同一思路，不需要一次性把整个 wiki 装进上下文。

log.md：按 ISO 日期倒序记录变更，人和 Agent 都能维护。审计、排错、判断知识是否过期，都有据可查。

例子：「周活怎么算？」

新人问 Agent：「我们的周活跃用户怎么算？」

没有 OKF 时，答案散在四处，Agent 每次会话重新拼装，还容易漏。

有 OKF 后，.okf/metrics/周活跃.md 写清定义、SQL 示例，并链接到 datasets/events-stream.md 和 datasets/users-db.md。 在CLAUDE.md 里一行：「做分析任务前先读 .okf/metrics/」。Agent 从 index 钻进去，只加载需要的两三份文件。

为什么要用 OKF：它补的是哪一块

这里有几个容易混的概念：

它们可以叠在一起：CLAUDE.md 指向 .okf/；OKF 描述 MCP 连出去的那些数据源；RAG 的语料也可以从 OKF 目录切片喂进去，但 OKF 本身解决的是「语料从哪来、谁改的、能不能 git diff」。 OKF最大的特点是：记忆可携带、可版本化，与 Agent 平台无关。

结语

最简单、最不需要许可的东西，才最容易变成基础设施。

Karpathy 的观察是：Agent 比人更适合维护 wiki，因为它不会烦。OKF 补上的另一半是：wiki 只有可携带、可版本、可互操作，价值才会复利。