Google OKF、Hermes与Gbrain：将文件夹作为知识图谱使用。

安德烈·卡帕西提出的“LLM-Wiki”理念，即让大型语言模型能够自主读写Markdown格式的维基文档以完成工作，引发了众多人的兴趣。越来越多的个人和小型团队开始尝试这一方案。当把任务交给人工智能时，难点往往不在于模型本身，而在于如何为它提供所需的背景信息。

如果要求它总结上个月的订单数据，除非它知道哪些表格存储了这些数据、各列的含义以及表格之间的关联方式，否则它无法给出正确答案。开放知识格式（OKF）正是为填补这类缺陷而设计的。它的主要挑战是信息孤岛，而非规模问题。

诸如表结构、指标定义、故障处理指南以及系统连接路径等内部知识，都存储在元数据目录、维基页面、代码注释以及经验丰富人员的头脑中。每一个新的智能体项目都需从零开始收集并重新学习这些知识。Google Cloud在关于OKF的论述中将这一问题称为“上下文整合问题”。

OKF的用途

智能体所需的大部分内容都是特定于公司的：表定义、指标计算方式、操作流程、API规范。这些资料分散在各处。OKF的思路是将它们整理成Git可以管理的Markdown文件，这样智能体和人员就可以依据这些整合好的资料，而无需每次都从头开始搜索。index.md以及相关联的概念文件便成了可供导航的资料来源。

在与人工智能协作时将上下文记录下来，就能积累可重复使用的资源。这与每次会话都重新输入提示词截然不同。

智能体如何使用它

仅调用模型往往难以达到实际所需的精确度。智能体需要业务背景、正确的数据定义以及以往的决策记录。OKF为它们提供了一个精心整理的查询场所，让智能体在自行生成答案之前能够从中获取所需信息。

OKF、MCP与RAG

围绕智能体的多种技术常与OKF混淆，其实它们的功能各不相同。

• OKF用于存储预先编写好的知识：定义、规范和操作手册。
• MCP能在运行时将智能体与实时工具及系统相连。
• RAG则能在查询时从大规模非结构化数据中检索相关内容。

它们并非竞争对手。每周活跃用户的定义可以在OKF中实现，而实际的BigQuery查询则通过MCP执行。OKF打包文件也可以作为RAG索引中的搜索目标。实际问题在于您已经覆盖了哪些领域，还存在哪些缺口。

Hermes、Wiki LLM与Gbrain

一种常见的做法是运行如Hermes这样的智能体环境，默认配备Wiki LLM，然后再添加Gbrain作为记忆层。由Garry Tan开源的Gbrain以智能体日后可重复使用的方式存储信息。它更接近于LLM的外部记忆系统，而非面向人类的维基平台，这体现了Karpathy提出的LLM-Wiki理念。保存的条目会被嵌入其中，以便后续检索时能找到语义相关的历史上下文：类似的决策、相关的业务约束等，而不仅仅是完全匹配的关键词。

一旦环境准备就绪，便可在Hermes内部自动完成Gbrain的配置及相关检查，包括嵌入配置文件。可选的技能包还能进一步提升智能体的功能。

典型的部署流程是将智能体部署在反向代理后的VPS上，从而实现从任何地点访问，随后通过控制面板确认首次启动情况。此后，工作重点就从安装软件转向为维基和内存提供真实语境信息。

OKF捆绑包在实践中的表现

一个 bundle 是包含 YAML 前置信息的 Markdown 文件目录。每个文件代表一个概念：表格、指标、API 或操作手册。前置信息中包含需要可查询的字段，如类型、标题、描述、标签和时间戳。文件正文则包含人类和模型实际会阅读的文字、公式和示例。文件间的链接将这个目录转化为图结构而非单纯的树结构，这样智能体就可以从某个指标追溯到其对应的表格，再从表格找到相关的事故处理指南。

由于采用纯文本文件格式，同一个 bundle 可以存储在 Git 中，以 tarball 形式分发，或放在静态服务器上。拉取请求便成了知识审核的流程，而责任归属记录和历史记录则能显示是谁在何时修改了流失率计算公式。工程师无需依赖任何专有 SDK 即可查看内容，只需使用 cat 命令即可查看某个概念的内容。

这种简洁性是刻意为之的。谷歌的设计说明强调采用极简的契约机制：仅需类型字段，其余部分由生成方自行决定。人类可以手动创建数据包，导出流程则可从现有目录中生成它们。一个智能体可以编写概念，供另一个智能体后续使用。该格式本身就是契约，两端的工具始终可以互换。

让 Hermes 和 Gbrain 发挥作用

一旦 Hermes 开始运行，日常操作更偏向知识工作而非基础设施管理。只需将笔记、决策和定义放入维基层，Gbrain 便会将其嵌入并支持按含义搜索。当智能体日后遇到类似问题时，它可以调取这些历史上下文，而无需从空白提示开始处理。

一些习惯能让这个循环发挥效用。撰写定义时，要假设六个月后会有陌生人阅读它们。每个文件最好只包含一个概念，这样检索效率才能保持较高。应通过链接关联概念，而非重复文本。当决策发生变化时，应更新相关概念，而非在其他地方留下矛盾的说明。要把维基视作一种产品，而非杂乱的信息堆放地。

围绕Gbrain开发的可选技能包能够在不改变核心内存模型的情况下扩展智能体的功能。关键在于内存与工具必须保持分离：内存用于存储已知信息，而工具则在需要采取行动时与外部系统交互。这种分离方式与上文提到的OKF与MCP的分工方式类似。

选择起点

如果您的团队已经拥有整理完善的指标与架构维基，将其转换为符合OKF格式的包是自然而然的第一步。如果主要问题是“智能体无法访问我们的数据库”，那么可以先在这些系统前端部署MCP服务器。如果问题是“答案淹没在Slack的海量消息中难以查找”，那么基于聊天记录和工单的RAG索引可能是合适的解决方案。许多团队最终会希望拥有这三种方案，但从最紧迫的问题入手才能让项目保持务实性。

无论选择哪种方案，都要衡量智能体是否不再反复询问相同的问题。这比包中文件的数量更能体现成功的程度。

在知识整理之前

审视OKF就能明确一个限制：只有当知识被整理好之后，OKF和RAG才能发挥作用。在此之前，有用的上下文仍隐藏在会议记录、聊天日志、疑问以及未完成的讨论中。像OKF这样的工具是在知识经过筛选整理之后才使用的，而那些能指向原始来源的链接则用于整理之前的阶段。与其直接给模型一个完整的答案，不如为其提供一条回到原始上下文的路径。

从长远来看，不仅模型和提示词重要，信息的存储方式以及向AI展示信息的方式同样至关重要。