Google OKF 发布：AI Agent 的知识标准化方案，游戏开发者为什么要关注

AI Agent 最大的瓶颈不是模型能力，而是找不到上下文

2026年6月，Google Cloud 悄悄发布了一个名为 Open Knowledge Format（OKF） 的开放规范 v0.1。没有盛大的发布会，只有一篇博客文章和一个 GitHub 仓库。但这个看似不起眼的规范，正在解决一个几乎所有 AI Agent 开发者都踩过的坑：模型越来越聪明，但它需要的知识散落在无数个互不兼容的系统里。

这个问题在游戏开发领域尤为突出。一个游戏项目的知识分布在 Confluence 文档、Jira 任务、代码仓库的 README、内部 Wiki 的设计文档、美术资产命名规范、关卡设计 Excel 表格中。当你的 AI Agent 需要回答"如何给新角色添加一套符合项目规范的攻击动画"时，它需要从至少四五个不同格式、不同系统的数据源中拼凑答案。每个 Agent 构建者都在从头解决这个上下文拼装问题。

OKF 的核心思路很简单：把知识放在版本控制中，与代码共存，让人和 Agent 可以读同一份文件。

OKF 是什么：用 Markdown 给 AI Agent 写说明书

OKF v0.1 将知识表示为一个 Markdown 文件目录，每个文件带有 YAML frontmatter 元数据。每份文档就是一个"概念"——可以是数据表、API 接口、设计规范、操作手册、关卡配置说明。文件路径本身就是概念的标识符。

一个典型的 OKF 文档长这样：

---
type: Character Animation Config
title: Melee Attack System
description: 近战攻击动画的状态机配置规范
resource: https://wiki.example.com/melee-attacks
tags: [animation, combat, state-machine]
timestamp: 2026-06-15T10:00:00Z
---

# 状态机结构
| 状态 | 触发条件 | 动画资产 | 混合时间 |
|------|----------|----------|----------|
| Idle | 无输入 | AM_Melee_Idle | 0.15s |
| WindUp | 按下攻击键 | AM_Melee_WindUp | 0.2s |
| Strike | WindUp结束 | AM_Melee_Strike | 0.1s |
| Recovery | Strike结束 | AM_Melee_Recover | 0.25s |

就是这么简单。没有复杂的压缩方案，没有新的运行时，不需要专有 SDK。只需要 Markdown、YAML frontmatter 和一个文件夹。

三大设计原则：为什么 OKF 值得游戏开发者关注

1. 最小意见原则——你决定怎么写，OKF 只负责互操作

OKF 只要求每个概念有一个 type 字段。其他所有内容——用什么类型、要哪些额外字段、正文分哪些章节——完全留给生产者自己决定。这意味着你的游戏项目可以用 OKF 描述角色配置、关卡蓝图、材质参数、UI 交互规范等任何内容，而不需要适配某个固定的数据模型。

对于游戏开发来说，这一点尤其重要。每个项目的文档结构差异巨大——RPG 项目需要角色属性表和剧情分支文档，FPS 项目需要武器参数和地图布局说明，休闲游戏可能只需要简单的关卡配置。OKF 的最小意见原则让每种项目都能找到适合自己的知识组织方式。

2. 生产/消费分离——人写的知识，AI 能读

OKF 清晰地分离了"谁写知识"和"谁用知识"。策划手写的游戏设计文档可以被 AI Agent 直接消费；美术导出的资产命名规范可以自动索引；程序生成的 API 文档可以在可视化工具中浏览。一个 LLM 合成的 bundle 可以被另一个 Agent 查询。

在游戏开发中，这意味着你的策划团队用他们习惯的方式写文档（Markdown + YAML），技术团队用代码仓库管理版本，而 AI Agent 可以直接读取这些文档来辅助开发。不需要额外的格式转换，不需要维护两套文档系统。

3. 格式不是平台——永远不需要专有账号

OKF 不绑定任何特定云、数据库、模型提供商或 Agent 框架。不需要开通任何服务，不需要任何 API Key。一个文件夹，一堆 Markdown 文件，你的 Agent 就能开始读懂你的项目。

这与当前游戏行业流行的 MCP（Model Context Protocol）形成了有趣的互补关系。MCP 解决的是 Agent 如何连接外部工具和数据源的问题，而 OKF 解决的是知识本身的格式标准化问题。两者结合，就能构建一个完整的 AI Agent 知识生态。

OKF 与 MCP 的关系：游戏开发 AI 工具链的新拼图

如果你一直在关注 MCP 协议在游戏开发中的应用，OKF 的出现正好填补了一个关键空白。MCP 定义了 Agent 与外部系统的通信协议——比如 UE5 编辑器如何暴露 API 给 AI Agent、Unity 项目如何通过 MCP Server 共享场景信息。但 MCP 本身不定义知识应该如何表示和存储。

OKF 可以作为 MCP 生态中的知识层：

• MCP Server 负责连接数据源（UE5 编辑器、Git 仓库、Jira 等）
• OKF 文档 负责标准化知识的表示格式
• AI Agent 通过 MCP 读取 OKF 格式的知识，理解项目上下文

举个例子：你的 UE5 项目有一个 MCP Server 暴露了关卡编辑器的 API，同时项目根目录下有一组 OKF 格式的文档描述了关卡设计规范。当 AI Agent 需要帮你生成一个新关卡时，它既可以通过 MCP 调用编辑器 API 执行操作，也可以读取 OKF 文档了解"这个项目的关卡应该遵循什么设计原则"。

游戏开发者如何开始使用 OKF

OKF 目前还是 v0.1 版本，但它的设计足够简单，游戏团队可以立即开始尝试。以下是一个实用的上手路径：

第一步：在项目仓库中创建 knowledge 目录

在你的游戏项目根目录下创建一个 knowledge/ 文件夹，按主题分子目录：

knowledge/
  characters/     # 角色配置和动画规范
  levels/         # 关卡设计原则和布局模板
  gameplay/        # 玩法机制说明
  assets/         # 美术资产命名和规范
  api/             # 编辑器/工具 API 文档

第二步：用 OKF 格式编写核心文档

从最重要的文档开始，比如项目的核心玩法机制文档。用 YAML frontmatter 定义类型和标签，用 Markdown 正文描述内容。建议先写 3-5 个核心文档，验证格式是否满足需求。

第三步：配置 AI Agent 读取 OKF 文档

如果你在使用支持 MCP 的 AI 工具（如 Claude Desktop、Cursor、MiMo Code 等），可以配置 MCP Server 指向你的 knowledge 目录。这样 AI Agent 在工作时就能自动读取项目知识，不再需要你反复粘贴文档内容。

第四步：将 knowledge 目录纳入版本管理

OKF 文档应该和代码一起提交到 Git，享受版本管理的便利。每次策划更新设计文档、每次程序修改 API 接口，对应的 OKF 文档也同步更新。这样 AI Agent 始终能读到最新、最准确的项目知识。

OKF 的局限与展望

作为 v0.1 版本，OKF 目前还有一些明显的局限：

缺乏游戏行业专用类型定义。OKF 目前只定义了基础框架，没有针对游戏开发的预置类型（如 Character Blueprint、Level Layout、Material Parameter 等）。这需要社区或行业组织来补充。

多媒体内容支持有限。OKF 基于 Markdown，对于游戏开发中大量存在的图片、视频、3D 模型预览等内容的引用方式还没有标准化方案。

实时同步问题。当 UE5 编辑器中的场景发生变更时，对应的 OKF 文档如何自动更新？这需要额外的工具链支持，目前还需要手动维护。

但 OKF 的价值不在于它当前的功能有多完善，而在于它提出了一个正确的问题：AI Agent 时代，我们需要一种让机器和人都能理解的知识表示方式。如果 OKF 被广泛采用，它将成为 AI Agent 生态的基础设施之一，就像 JSON 成为 Web API 的通用数据格式一样。

总结

Google OKF 的发布，标志着 AI Agent 生态正在从"连接协议"（MCP）走向"知识标准化"（OKF）。对于游戏开发者来说，这意味着：

• 你的项目文档不再只是给人看的，也可以成为 AI Agent 的知识源
• OKF + MCP 的组合，为构建游戏开发 AI 工作流提供了完整的标准化方案
• 现在就开始用 OKF 格式整理项目知识，是在为未来的 AI 辅助开发打基础

建议游戏开发团队关注 OKF 的发展，并在新项目中尝试使用 OKF 格式管理项目知识。当 AI Agent 真正成为游戏开发的标准工具时，拥有标准化知识库的团队将拥有明显的效率优势。