GBrain：从 Agent 记忆到组织知识库的选型

内容截至 2026 年 7 月。

结论

MEMORY.md、OpenClaw/Hermes 记忆和 GBrain 分别解决“长期规则”“Agent 跨会话连续性”“带关系与来源的知识问答”。它们应分层协作，而非互相替代。对于组织知识库，选型首先取决于权限与数据源，其次才是 RAG 或知识图谱。

GBrain 是什么

GBrain 是 Garry Tan 开源的、面向个人与团队的 Markdown/Git 知识底座。它将知识库同步到 PGLite 或 Postgres，提供混合检索、实体关系图、MCP 工具和带来源的综合回答；项目把“答案中还缺什么证据”也作为输出的一部分。

它特别适合“会前我需要知道什么”“某项目与哪些客户、决策和待办有关”这类跨人物、会议、公司和文档的提问。项目声称其图谱在写入时自动抽取实体及类型化关系，并提供定时摄取、引用修复与记忆合并等维护任务。应将这些视为产品能力与待验证的工程假设，而非已普遍成立的事实。

GitHub 项目 · 官方的 Brain / Memory / Session 分层说明

三种“记忆”并不在同一层

层	`MEMORY.md`	OpenClaw / Hermes	GBrain
主要对象	稳定事实、偏好、项目规则、关键决策	Agent 的用户事实、近期任务状态、会话连续性	人、团队、公司、会议、项目、资料和它们的关系
事实源	人工维护的 Markdown	Agent 工作区和持久化记忆存储	Git/Markdown 知识库；数据库为检索与图谱索引
读取方式	启动时或按需读入全文	自动召回：关键词、向量或混合检索	混合检索、图谱遍历、跨文档综合与引文
写入方式	人或 Agent 明确编辑	Agent 自动记录、提炼或晋升长期记忆	摄取资料、写知识页、实体/关系抽取、维护任务
人类可审阅性	极高	中等：取决于记忆后端与日志	较高：保留 Markdown/Git；但生成的摘要和关系需复核
典型风险	遗漏、膨胀、全文注入占用上下文	错误记忆被自动固化、跨 Agent 隔离不足	摄取权限、图谱/摘要幻觉、后台任务与模型成本

`MEMORY.md`：最小、可控的长期记忆

适合保存不常变化、错误代价高、需要每次任务都被遵守的信息：用户偏好、项目边界、固定约束、已确认决策和常见坑。优点是 Markdown + Git 让变更透明、容易审阅和回滚；缺点是不会自动回答跨几十份文档的问题，增长后还可能挤占上下文。

因此，MEMORY.md 应是“压缩后的稳定真相”，不是资料仓库，更不该承载会议原文或大量项目细节。

OpenClaw：以 Agent 为中心的记忆闭环

OpenClaw 将长期记忆放在 MEMORY.md，把当天观察写入 memory/YYYY-MM-DD.md，并可用 SQLite 的关键词/向量混合检索；其 dreaming 流程会将多次被召回、且跨查询有价值的内容候选提升为长期记忆。它还支持多种后端和每个 Agent 的独立工作区。

优势是既保留 Markdown 的可审阅性，也提供自动索引、检索和“短期 → 长期”的整理机制；适合长期驻留、持续与人协作的 Agent。弱点是组织知识治理不是它的主要边界：数据连接器、跨系统 ACL、主数据与证据管理仍需外部系统承担。

OpenClaw Memory 概览 · 内置记忆引擎 · 晋升与 Dreaming 命令

Hermes：以个人 Agent 为中心的持久状态

Hermes 将会话、持久记忆、技能、定时任务和身份配置保存在本地 ~/.hermes/。它把“记忆”定义为关于用户、项目与偏好的事实，将“Skill”定义为可复用的程序性步骤；两者都跨会话保留。

相较 OpenClaw，Hermes 更适合把一个常驻个人 Agent 的状态、工具和技能放在同一运行时管理。其优势是本地优先、部署直观；局限是该数据目录不适合并发写入，且其内建记忆并不等于有来源、ACL 和组织治理的共享知识库。

Hermes 记忆与技能说明 · Hermes Docker 持久化状态说明

GBrain：面向“世界事实”的可查询知识层

GBrain 的定位不是替 Agent 保存“我偏好什么”或“当前任务做到哪一步”，而是维护外部实体与事件的可查询知识：某人、某公司、某次会议、一个项目或一个待办之间发生了什么。其强项是将跨文档答案与原始来源、关系路径和知识缺口放在同一次查询中。

代价是明显增加：需要规划摄取范围、文档规范、嵌入/重排模型、后台维护频率、敏感信息边界和人工纠错流程。个人 Obsidian 库或小型团队不应因为它“能建图谱”就先引入；只有当跨材料综合问答成为高频刚需时才值得试点。

组织内部知识库：四条路线

1. 文档事实源 + 轻量 Agent 记忆

形态：Obsidian/Markdown/Confluence 等文档作为事实源，Git 或平台版本历史管理；MEMORY.md/OpenClaw/Hermes 只保存 Agent 的稳定规则和任务状态。

适用：小团队、技术团队、重视可迁移与可审阅文本的知识库；也是多数团队最应先做的基础层。

关键治理：统一文档位置与负责人、明确哪些内容应进入长期记忆、为决策和项目页面建立链接。没有这些，后续 RAG 只会更快地检索混乱。

2. 权限感知的企业搜索与问答

形态：在 Confluence/Jira、Google Drive、SharePoint、Slack、GitHub 等已有系统之上接入企业搜索/问答，例如 Atlassian Rovo 一类产品。

适用：资料已分布在多个 SaaS，且“用户只能看到原本有权限看到的内容”是第一约束的组织。

优势：连接器、身份和 ACL 同步是产品能力；Rovo 的搜索、Chat 和 Agents 会依照原系统权限返回内容，删除或收紧权限也会同步生效。

代价：依赖供应商、连接器覆盖范围和授权模型；答案质量仍受原文质量限制。对机密资料，必须验证每一类连接器的实际授权语义，而不能只看宣传页。

Rovo 搜索与来源权限 · 连接器权限同步 · 连接器类型与索引边界

3. 自建 RAG / GraphRAG 知识服务

形态：把内部文档经过解析、切分、嵌入与检索后接入聊天或 Agent；需要时用 Microsoft GraphRAG 等框架抽取实体、关系、主张与社区摘要。

适用：需要自托管、特定领域召回、复杂跨文档分析，且有工程团队能持续维护数据管道、权限过滤、评估与观测。

优势：模型、存储、提示词、索引和评测均可控。GraphRAG 对“全库主题是什么”或“实体关系如何”这类全局问题比纯向量 RAG 更有潜力。

代价：它是索引与查询框架，不是现成的组织知识库；ACL、增量更新、删除同步、引文、评测与成本控制都需要自行实现。GraphRAG 的建索引会消耗大量 LLM 资源，应先用小语料验证收益。

Microsoft GraphRAG 索引机制 · 查询模式 · 成本提示

4. GBrain 式“知识图谱 + Agent”层

形态：用 Git/Markdown 保存可审阅页面，数据库承担图谱和检索，Agent 负责摄取、归档、纠错和综合回答。

适用：人员、客户、会议、项目和外部资料之间的关系是核心工作对象，且团队愿意维护结构化知识页与证据链。

优势：比普通企业搜索更接近“情报分析”——不仅找文档，还能回答关联、脉络和未知点；比纯 GraphRAG 更强调日常知识维护与 Agent 接入。

代价：仍需自行设计权限、多租户边界、信息生命周期和人工审阅。若组织首要问题是“跨 SaaS 的受权限保护检索”，应优先考虑第二条路线。

选择建议

是否先要统一文档、负责人和决策记录？
  是 → 先做路线 1
  否 → 资料是否分散在多个 SaaS，且 ACL 是首要约束？
         是 → 路线 2
         否 → 是否需要自托管、领域化检索或全库关系分析？
                是 → 路线 3；若实体/事件型知识与持续 Agent 维护很重要，再评估路线 4
                否 → 路线 1 + OpenClaw/Hermes 已足够

对个人 Markdown 知识库的建议

一个已有 Markdown、目录、双链和 Git 作为事实源基础的个人库，应继续保持它为第一真相源：

将个人偏好、长期协作规则和常见操作沉淀为简短、可审阅的 MEMORY.md/AGENTS.md。
将项目进展、决策、原始资料和读书笔记保留在对应 Markdown 文档，不塞入 Agent 记忆。
若未来需要让常驻 Agent 自动从每日记录中提炼长期偏好，可试点 OpenClaw 或 Hermes 的记忆机制。
若出现大量“某人/公司/项目的历史关系、未决事项和证据是什么”的问题，再以小范围、非敏感资料试点 GBrain，并设立来源、删除、权限和人工校验验收标准。