GBrain：Garry Tan 想把个人知识库从一堆 Markdown，收成一个单文件数据库

最近 Garry Tan 发了一份很长的 gist，名字叫 GBrain。

Garry Tan 是 Y Combinator 的 CEO，同时也是 Initialized Capital 的联合创始人。 这份 spec 也带着很强的产品和投资视角，关注点落在个人知识库的底层结构到底该怎么搭。

它读起来已经很接近一份可以直接落地的 build spec。 开头直接把目标写出来了：

• 做一个 personal knowledge base

• 底层是一份 SQLite 数据库

• 上面同时跑全文检索、向量检索和结构化查询

• 命令行只保留入口

• 工作流和规则尽量放进 markdown skills

表面上看，它像“又一个个人知识库项目”。 顺着整份 spec 往下读，会更清楚它在改的是个人知识的存储层。

这个项目是从一个现实问题开始的

Garry 手上已经有一套很大的知识库：

• 1,222 份人物档案

• 7,471 个 markdown 文件

• 大约 2.3GB

这些内容现在都还放在 Git 目录里维护。 他在文里直接写了结论：

Git 到这个规模已经开始吃力了。

到了这个规模，问题主要会落到下面几件事上：

• 文件数量太多

• 组织成本上升

• 检索开始变慢

• wiki 结构在文件系统里越来越难维持

所以这份 spec 的第一步，就是把“文件系统上的知识库”改成“数据库里的知识库”。

为什么底层选 SQLite，不选 Postgres

gist 里对 SQLite 的理由讲得很直接：

• 单文件

• 没有 server

• 没有 connection string

• 没有 Docker

• 没有 managed database

最后你得到的是一份：

• 可以 scp

• 可以 rsync

• 可以备份到 S3

• 甚至可以直接拷进 U 盘

的 brain.db。

这背后的判断也很明确：

• 这是一个人的知识库

• 不是高并发写入系统

• 不是多租户数据库

• 不需要 replication

• 不需要 row-level security

这套选型面对的是“一个人的长期知识脑”这类场景，考虑的也不是企业应用数据库那套约束。

在这种场景里，SQLite 反而顺手。

全文、向量和结构化查询，都要收在同一层

第二个关键选择是：

FTS5 + vector embeddings 一起放进同一个数据库。

Garry 写得很明确：

• 不要 Pinecone

• 不要 Chroma sidecar

• 不要再起一个 Qdrant container

全文搜索和语义搜索，最好在同一个连接、同一份库、同一套命令里完成。

这样以后，一次查询可以同时做三种事：

• FTS5 找关键词

• embedding 做语义召回

• 结构化字段过滤做筛选

再把这些结果合并成一份回答。

这里的取向很清楚： GBrain 从一开始就是按统一查询层在设计。

compiled truth + timeline

Garry 把知识库结构写成了：

• above the line

• below the line

翻成更容易理解的话，就是：

• compiled truth

• timeline

对应关系是：

• 上面一层：当前状态的整理结果

• 下面一层：按时间追加的证据和事件记录

这套结构真正有用的地方，在更新方式不同：

• compiled truth 可以被重写

• timeline 只追加，不回改

也就是：

• 上面一层负责“现在怎么看这个人 / 公司 / 项目”

• 下面一层负责“事情是怎么一步步发生的”

这套设计很像把 wiki 和日志拼在了一起。 你既能得到一份当下的压缩认知，也不会丢掉历史证据链。

thin CLI, fat skills

整份 gist 还有一条很鲜明的取向：

thin CLI, fat skills

Garry 直接把 GStack 那套方法搬了过来。

他的判断是：

• CLI 只负责入口

• 智能和工作流尽量放进 SKILL.md

• heuristics、edge cases、用户流程都放在 markdown 里维护

这样做有几个直接好处：

• 不用每次改逻辑都重新编译应用

• Claude Code 这类 agent 读一份 skill 就能知道工作流

• 不用把 ingest / query / lint 的所有逻辑都写死进应用代码

这也解释了为什么他把 GBrain 定位成：

• GStack 的 coding layer 下面，再垫一层 knowledge layer

换句话说，GStack 管“怎么做事”，GBrain 管“怎么存知识”。

MCP from day one

这份 spec 里还有一个很值得注意的点：

MCP from day one

Garry 的判断很直接：

以后不管是：

• Claude Code

• Wintermute

• Cursor

• Windsurf

• 还是别的 MCP client

都需要读写这份知识库。

所以 GBrain 更像一个：

• 能 serve

• 能暴露 tool

• 能接 MCP client

的通用知识底座。

这意味着它不只是给“Garry 自己查笔记”用的。 它在设计上已经把“被多个 agent / client 访问”这件事考虑进去了。

从 schema 看，它想做的已经超出笔记库

gist 里放了很长的 SQL schema。

把它压一下，核心表大概是这些：

• pages

• page_fts

• page_embeddings

• links

• tags

• raw_data

• timeline_entries

• ingest_log

• config

这些表放在一起，已经说明 GBrain 想做的已经超出“把 Markdown 搬进 SQLite”。

它还想把下面这些关系一起结构化：

• 页面之间的链接

• tag

• 原始 sidecar JSON

• 时间线事件

• ingest 过程本身

其中 raw_data 和 ingest_log 两张表特别关键。

它们说明系统要保留的，除了“整理后的知识”，还包括：

• 原始来源数据

• 知识是怎么进来的

这样后面的：

• 回溯

• 再加工

• 导出

• 校验

都会更容易做。

CLI 设计也很完整

Garry 把 CLI 命令基本全列出来了：

• gbrain get

• gbrain put

• gbrain search

• gbrain query

• gbrain ingest

• gbrain link

• gbrain timeline

• gbrain list

• gbrain stats

• gbrain export

• gbrain import

• gbrain embed

• gbrain serve

这套设计的取向很清楚：

• 保留 Unix 风格 CLI

• 同时把 MCP / tool use 准备好

所以它既能当人类命令行工具，也能当 agent 的知识后端。

lossless migration / round-trippable

整份 spec 里还有一条特别重要，但容易被忽略：

lossless migration / round-trippable

也就是：

• 迁移到 SQLite 后不能丢内容

• 还要能导回原来的 markdown 结构

这条要求说明他不想做一层“进来就别想再出去”的新系统。 他想保留的是：

• 数据库更适合日常使用

• markdown 仍然保留逃生舱

这点很重要。 因为个人知识库一旦要长期用，最怕的就是被某种工具和某种存储结构锁死。

这份 gist 真正在讨论什么

如果只看表面，它像是一份新工具 spec。 再往下一层看，它讨论的是：

个人知识库到了几千、上万文件规模之后，底层还该不该继续停留在文件系统。

Garry 给出的答案很明确：

• wiki 结构可以保留

• compiled truth + timeline 这套模式也可以保留

• 底层需要换成数据库

这已经是在重做个人知识管理的存储层。

这份 spec 值得看的几处

如果你打算认真读，可以先看这几段：

1. Why SQLite over Postgres

2. Why FTS5 + vector in the same DB

3. compiled truth + timeline

4. thin CLI + fat skills

5. MCP from day one

6. What Makes This Different

这几段读完，GBrain 的形态基本就立住了。

最后一段

GBrain 在搭一层个人知识库的数据库底座：

• 单文件

• 可查询

• 可导出

• agent 可读

• skill 可编排

• MCP 可接入

如果你也在做：

• 个人知识库

• 本地 agent 记忆层

• Wiki + RAG + MCP 的混合系统

这份 gist 值得细读。 它里面很多选择，已经到了“这层基础设施到底该怎么搭”这一层。