国内大多数人还在讨论模型、MCP、Skills 和 Agent Harness。

但 Google 最近正在推动另一件更底层的事情：

知识应该以什么格式存在，才能被人和 Agent 共同读取、维护、交换与验证？

真正重要的标准，刚出现时往往显得异常朴实无华。

HTML 刚出现时，不过是一套标签。

JSON 不过是括号、冒号和字符串。

Agent Skills 的核心，也只是一个包含 SKILL.md、脚本和参考资料的目录。

而 OKF 看起来更加“简单”：一组 Markdown 文件，加上一点 YAML 元数据。

但标准的魅力，从来不在于它有多复杂。

标准真正改变世界的地方，是让整个行业不再重复发明同一个轮子。

2026 年 6 月，Google Cloud 发布了 Open Knowledge Format，也就是 OKF。

它试图把此前已经出现的“LLM Wiki”模式，正式定义成一种开放、厂商中立、可移植的知识格式。

最近几天 OKF 更新到 V0.2，开始加入来源、验证、时效性和可信度等机制。

这件事目前在国内几乎没有引起足够讨论。

但我认为，OKF 触碰到的，可能是 Agent 时代最底层的问题之一：

不是 AI 如何回答问题，而是一个组织的知识，究竟应该以什么形式存在。

/模型有了，工具有了，但知识仍然没有统一接口/

过去两年，Agent 基础设施正在快速分层。

模型负责提供通用智力。

MCP 负责让 AI 应用连接数据库、工具、服务和外部系统。

Skills 负责封装“如何完成一类任务”。

那么，OKF 负责什么？

它试图回答：

Agent 到底应该以什么形式，读取并维护一个组织“知道的东西”？

可以简单理解：

换一个更形象的说法：

MCP 给 Agent 接上手脚，Skills 教给 Agent 招式，而 OKF 试图给 Agent 一套可以长期维护、跨系统迁移的组织记忆。

当然，Skills 和 OKF 的边界并不是绝对的。

Skill 也可以携带知识。

OKF 也可以描述执行方法。

但二者关注的核心不同：

Skill 更偏向程序性知识：

怎么做。

OKF 更偏向陈述性知识：

什么是真的，为什么是真的，它来自哪里，现在是否仍然有效。

这正是 OKF 可能成为基础设施的原因。

未来企业真正需要的，不只是一个会执行任务的 Agent。

而是一个知道：

• 公司规则是什么；
• 业务定义是什么；
• 哪些信息可信；
• 哪些知识已经过期。

的 Agent。

/让知识成为可交换的产物/

OKF 的设计非常克制。

一个 OKF Knowledge Bundle，本质上就是一个 Markdown 文件目录。

例如，一个企业知识库可以长成这样：

1company-knowledge/
2├── index.md
3├── log.md
4├── metrics/
5│   ├── revenue.md
6│   └── active-users.md
7├── policies/
8│   └── revenue-recognition.md

其中，每一个 Markdown 文件，代表一个独立的知识概念。

它可以是一张数据库表。

一项公司政策。

甚至一个业务流程。

文件路径就是这个概念的身份。

文件头部通过 YAML 描述结构化信息，正文继续使用普通 Markdown。

例如：

1type: Metric
2title: Revenue
3description: 公司财务口径下的已确认收入
4status: stable
5sources:
6  - revenue-policy

这里最重要的，其实不是文件格式。

而是：

生产者和消费者被分开了。

任何人、Agent、或者知识平台，都可以基于该格式生产 OKF。

任何模型、搜索引擎、或者 Agent，也都可以基于该格式消费 OKF。

知识不再必须被锁在：

• 某个向量数据库；
• 某个 Agent 框架；
• 某家模型公司的 Memory。

它首先是一组：

你能打开、能审查、能版本管理、能迁移的文件。

这就是 OKF 与 HTML 类比真正成立的地方。

HTML 没有替代浏览器、搜索引擎、服务器和数据库。

它只是让整个互联网围绕“网页是什么”形成最低限度的共识。

同样：

OKF 也不会替代 RAG、向量数据库、搜索引擎或者 Agent Runtime。

它试图定义的是：

这些系统共同操作的那个知识产物，究竟应该长什么样？

是的，OKF 标准构建的其实也只是新时代的共识。

/知识不仅要可读，还要可信/

如果只是 Markdown 加元数据。

OKF 可能只是一个更规范的 Wiki。

但真正值得关注的是：

它开始尝试解决 Agent 时代最难的问题：

当大量知识由 Agent 自动生成时，我们为什么要相信它？

这是一个非常非常关键的问题。

过去，人类写文档。

我们默认：

作者知道自己写了什么。

企业内部也有审批流程。

但未来，大量知识可能来自 Agent。

那么：

这条知识是谁生成的？

来自什么来源？

现在是否仍然有效？

这些问题都会变得越来越重要。

因此，OKF 开始加入一些关于来源、验证、状态和时效性的描述能力。

它希望 Agent 在读取知识时，不只是看到内容。

还知道：

这是什么知识。

谁产生的。

可信程度如何。

这意味着 OKF 正在从：

“让 Agent 能读文档”

走向：

“让 Agent 在使用知识之前，先判断这条知识是否值得相信。”

这已经不只是知识管理。

它逐渐接近一种：

组织知识治理协议。

未来企业真正需要的，可能不是一个“知道很多”的 Agent。

而是一个能够区分：

哪些来自正式政策；

哪些经过业务负责人审核；

哪些已经过期；

模型能力越强，这种可信知识层反而越重要。

因为：

一个能力极强、但使用错误组织知识的 Agent，只会以更高效率制造错误。

/OKF 生态/

现阶段，OKF 目前非常早期，毕竟也才发布短短两个月。

它还没有达到 HTML 那样成熟的生态。

但一个标准开始有价值时，往往会出现几个角色：

有人定义规范。

有人生产知识。

有人维护知识。

有人消费知识。

围绕 OKF，目前已经开始出现这样的雏形。

Google 提供了规范、示例知识库和相关工具。

开源社区开始出现知识创建、校验、索引和可视化工具。

一些项目也开始尝试把 OKF 和 Agent、MCP、GitHub 工作流结合起来。

其中，OpenWiki 是一个比较值得关注的案例。

更准确地说：

OpenWiki 不是 OKF 标准本身。

而是一个快速采用 OKF 的上层应用。

它可以读取代码库或者个人资料，由 Agent 生成并持续维护相互链接的 Wiki。

加入 OKF 支持后，这些知识不必永远留在 OpenWiki 自己的系统中，而可以被其他兼容工具读取。

这正是开放标准开始产生价值的信号：

标准不需要亲自完成所有事情。

它只需要让整个生态都可以围绕同一种知识产物独立生长。

HTML 没有规定浏览器应该怎么实现。

它只是给浏览器提供了共同输入。

OKF 如果成功，也会沿着类似路径发展。

/Harness 会变薄，但企业知识层会变厚/

最近我越来越确定一件事情：

未来 Agent Harness 最核心的价值，可能并不只是定义 Agent 如何执行任务。

而是：定义企业自己的知识。

今天很多团队都在搭建 Harness 框架。

里面包含：

• System Prompt；
• 规划；
• 工具选择；
• 上下文管理；
• 任务拆解；
• 状态管理；
• 多 Agent 协作。

这些东西现在非常重要。

但随着模型和 Agent 平台继续发展，其中相当一部分通用能力，很可能会逐渐被基础设施吸收。

模型会越来越擅长规划。

平台会原生提供 Memory、工具路由、上下文管理、权限和工作流。

大量今天需要团队自己编写的 Agent 代码，未来可能会逐渐商品化。

这并不意味着 Harness 会消失。

安全、审计、权限、确定性流程和可观测性，依然需要企业自己控制。

但 Harness 很可能不再是企业最核心的差异化资产。

真正不会被通用模型吸收的，是企业自己的知识。

比如：

哪些客户属于高风险客户；

某个系统曾经发生过什么事故；

这些东西不属于任何通用大模型。

它们只属于一家具体企业。

而且每天都在变化。

模型可以越来越聪明。

Agent 可以越来越会做事。

但它不可能凭空知道：

你所在的组织此时此刻相信什么、遵守什么、如何做出判断。

因此，我认为未来企业 Agent 的真正护城河，会逐渐从：

我们用了哪个模型、哪套 Agent 框架、怎样写 Prompt

迁移到：

我们是否拥有一套结构化、可验证、持续更新、可以被不同 Agent 使用的组织知识。

换句话说：

Harness 可能会被 Agent 平台不断吸收，但企业知识的定义不会。

模型是租来的。

Agent 框架可以替换。

工具接口可以迁移。

但经过长期沉淀的企业知识，才是真正属于组织自己的资产。

/OKF 的意义/

这或许才是 OKF 最值得关注的地方。

不是因为它现在已经足够强大。

而是因为它第一次尝试为 Agent 时代最稀缺的东西，定义一个开放接口。

那个东西不是模型。

不是工具。

而是：

知识本身。

> 作者：贾克斯的平行世界