OKF vs Skill：AI Agent 知识表示范式的分与合

如果你在构建 AI Agent，迟早会撞上同一个问题：怎么把"领域知识"喂给 Agent，让它能准确、高效地理解你的系统？

想象一个场景：Agent 需要回答"怎么从我们的事件流里算 weekly active users？"——它得从元数据目录、Wiki、代码注释、共享网盘、几个资深工程师的脑子里拼凑答案。每个团队都在独立重复这个"上下文组装"的工作。

直到 2026 年 6 月 12 日，Google Cloud 发布了一个看起来不起眼的规范——Open Knowledge Format（OKF）v0.1 ^{[google2026okf]}。这个只有 14KB 的 SPEC 文件，把 Andrej Karpathy 提出的 "LLM Wiki" 模式正式标准化了 ^{[karpathy2025llmwiki]}。

与此同时，AI 编码 Agent 生态中另一套约定——Skill——已经悄悄成为事实标准：从 OpenCode 的 .opencode/skills/ 到 Google 自家 ADK 的 .agents/skills/，Skill 作为一种"程序化知识"的载体已经无处不在 ^{[google2026adk]} ^{[vercel2025skills]}。

这篇文章把两套范式放在一起看：它们从共同的基础出发，走向了不同的方向，但正在加速合流。

Skill：程序化知识的约定俗成

Skill 的核心语义是"告诉 Agent 怎么做"。

打开任何一个 Skill 文件（SKILL.md），你会看到这样的结构：

---
name: adk-git
description: Use for any git operation — commit, push, pull, rebase, ...
---

后面跟着的就是针对特定任务的指令、规则、范例。比如 Google ADK 的 adk-git Skill 详细规定了 Commit Message 怎么写、分支怎么命名、pre-commit hook 怎么跑。

Skill 有几个鲜明的特征：

1. 程序化知识 (Procedural Knowledge)。 Skill 描述的是流程、规则、最佳实践——本质上是一套发给 Agent 的 SOP。

2. 约定俗成而非正式规范。 虽然 OpenCode、Google ADK、Vercel Skills CLI 都采用了相似的 SKILL.md + frontmatter 结构，但各家对 frontmatter 字段的定义并不统一。OpenCode 用 name + description，有些用 triggers 描述触发条件，没有一个叫"Skill Spec"的公开文档。

3. 与 Agent 运行时紧耦合。 Skill 被 Agent 框架在对话启动时加载到 system prompt 中——它天然依附于特定的 Agent 运行时。

以 Google ADK 为例，它的 .agents/skills/ 目录下放了十来个 Skill：adk-architecture、adk-style、adk-git、adk-review……每个都是对 ADK 项目开发流程的专门指引。Agent 被激活时加载它们，立刻就"懂"了这个项目的编码规范。

Skill 解决了一个非常实际的问题：让 Agent 获得领域上下文，无需每次都口头交代。但它有一个内在局限：Skill 是"写给自己 Agent 看的"，跨团队、跨工具的流通性并非设计目标。

OKF：声明式知识的开放标准化

OKF 的核心理念恰好相反——它关心的是"告诉 Agent 有什么"。

OKF 的设计极简到一屏幕就能讲完 ^{[google2026okfSpec]}：一个 Bundle 就是一个 Markdown 文件目录。每个 .md 文件代表一个"概念"（Concept），文件路径就是概念的身份标识。概念之间用标准 Markdown 链接互联，整个目录天然形成一张知识图谱。

sales/
├── index.md
├── datasets/
│   └── orders_db.md
├── tables/
│   ├── orders.md
│   └── customers.md
└── metrics/
    └── weekly_active_users.md

每个概念文档有一小块 YAML frontmatter，唯一必填字段只有 type：

---
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
---

OKF 的 SPEC 全文只有 11 节，核心约束仅三条：

每个非保留 .md 文件必须有 YAML frontmatter
frontmatter 中必须包含非空的 type 字段
index.md 和 log.md 是保留文件名

除此之外，一切由生产者决定。Type 值不限枚举、body 结构不限章节、消费端遇到未知字段必须容错。

OKF 的三个设计原则精准表达了它的定位：

最小主张 (Minimally opinionated)： 规范只定义互操作边界，不定义内容模型。
生产者/消费者独立： 手工编写的 Bundle 可以被 AI 消费，自动生成的 Bundle 可以在可视化工具中浏览——格式是合约，两端的工具独立可替换。
格式，不是平台： 不绑定云厂商、数据库、模型提供商或 Agent 框架。

随规范一同发布的是 Google Cloud 提供的参考实现：一个 Enrichment Agent（自动遍历 BigQuery 数据集生成 OKF 文档）、一个静态 HTML 可视化器（自包含单文件，无后端），以及三个示例 Bundle。

关键对比：同源，异流

OKF 和 Skill 从同一个技术基座上走出来——Markdown + YAML frontmatter + 文件系统目录——但走上了截然不同的演化路径：

维度	Skill	OKF
知识类型	程序化知识（怎么做）	声明式知识（有什么）
核心语义	给 Agent 的指令/流程 SOP	对数据资产/业务概念的描述
必填字段	不统一（`name`/`description` 等）	`type`（唯一必填）
标准化程度	约定俗成，无正式 Spec	公开规范 v0.1
消费方式	Agent 框架加载到 system prompt	任意 Agent/工具通过文件系统读取
流通性	团队内、同框架	跨团队、跨组织、跨工具
关联资产	无——Skill 本身即最终产物	`resource` 字段链接底层数据资产
层级组织	扁平目录	树形层级 + `index.md` 渐进发现
版本历史	依赖 Git	内置 `log.md`

但最值得注意的不是差异，而是它们共享了什么：

都以 Markdown 为 body 格式——人类无需工具即可阅读
都以 YAML frontmatter 承载结构化元信息——Agent 无需 SDK 即可解析
都以文件系统目录为组织形式——版本控制友好，git diff 即变更审计
都遵循"可人类阅读 + 可机器解析"的设计哲学

合流：殊途同归

Google 同时维护着 ADK 的 Skill 体系和 OKF 规范，这件事本身就很有象征意味。

在 ADK 中，.agents/skills/ 下的 Skill 文件用的是和 OKF 完全相同的 Markdown + frontmatter 结构。区别仅在于 Skill 的 frontmatter 用 name 标识身份，OKF 用 type 标识概念类型——这不是技术上的分野，而是语义上的分工：

当你想告诉 Agent 怎么提交代码，写一个 Skill。
当你想告诉 Agent 订单表长什么样，写一个 OKF Concept。

两者在同一个 Agent 运行时中共存、互补、互相引用。

更进一步看，这种"Markdown + YAML frontmatter 作为 Agent 知识载体"的模式已经不只是 Google 一家的选择。Obsidian vault 作为 AI Agent 的知识底座、Vercel Skills CLI 的 SKILL.md 规范、AGENTS.md / CLAUDE.md 上下文文件约定——独立演化的方案正在向同一个形态收敛。

Karpathy 在 LLM Wiki gist 中把核心洞察说得很直白：与其让模型反复搜索同样的文档找同样的事实，不如给 Agent 一个共享的 Markdown 库，让它随时间越来越有用。"LLM 不会无聊，不会忘记更新交叉引用，可以一次性改 15 个文件"——那些让人类放弃维护个人 Wiki 的琐事，恰恰是大模型擅长的 ^{[karpathy2025llmwiki]}。

OKF 的意义不在于发明了什么新技术——Markdown 已经用了二十年，YAML 也已经用了二十年。它的意义在于把这套已经遍地开花的实践，提升到了互操作规范的层面。当知识格式有了正式 Spec，跨团队、跨组织、跨工具的知识流动就不再是愿景。