最近，Y Combinator的CEO Garry Tan发了一份比较详细的设计文档，名字就叫GBrain。这东西一出来，圈子里不少人都在看。

Garry本人既是YC的掌门，也是Initialized Capital的联合创始人，所以他写的这份spec，产品感和投资视角都很重。核心关注点只有一个：个人知识库的底层架构，到底应该怎么搭。

这份文档读起来已经非常接近一份可以直接拿来开发的构建说明书了。开头就把目标列得清清楚楚：

• 做一个personal knowledge base
• 底层用一份SQLite数据库
• 上面同时跑全文检索、向量检索和结构化查询
• 命令行只作为一个入口
• 工作流和规则尽量放到markdown skills里

乍一看，你会觉得“哦，又一个人知识库项目”。但顺着文档往下读，就会明白，他要动刀的是个人知识管理最底层的存储层。

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

Garry自己手上已经有一套非常大的知识库：

• 1,222 份人物档案
• 7,471 个 markdown 文件
• 总大小大约 2.3GB

这些内容目前都还放在Git仓库里维护。他直接在文档里下了结论：

Git到这个规模，已经开始力不从心了。

到了这个体量，问题通常会集中在这么几件事上：

• 文件数量太多，管理混乱
• 组织成本越来越高
• 检索速度开始变慢
• wiki的结构在文件系统里越来越难维护

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

为什么选SQLite，不选Postgres

Gist里对选择SQLite的理由说得非常直接：

• 单文件
• 不需要服务器
• 不用搞连接字符串
• 不用Docker
• 不需要托管数据库服务

最后你拿到手的就是一个：

• 可以scp、rsync
• 可以备份到S3
• 甚至可以直接拷进U盘

的brain.db文件。

背后的判断也很清晰：

• 这是一个人的知识库
• 不是高并发的写入系统
• 不是多租户的数据库
• 不需要数据复制
• 不需要行级安全控制

这套选型面对的就是“一个人的长期知识大脑”这种场景，考虑的根本不是企业级数据库那套约束。在这种场景下，SQLite反而最顺手。

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

接下来一个有意思的判断是：

FTS5和向量嵌入（vector embeddings）要放在同一个数据库里。

Garry写得很明确：

• 不要Pinecone
• 不要Chroma sidecar
• 不要再起一个Qdrant容器

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

这样一来，一次查询可以同时做三件事：

• 用FTS5找关键词
• 用embedding做语义召回
• 用结构化字段做筛选过滤

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

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

“编纂的真相”与“时间线”

Garry把知识库的结构分成了两层：

• above the line（线上）
• below the line（线下）

换个更容易理解的说法，就是：

• compiled truth（编纂的真相）
• timeline（时间线）

对应关系是：

• 上面一层：当前状态的整理结果
• 下面一层：按时间追加的证据和事件记录

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

• compiled truth 可以被重写
• timeline 只追加，不回改

换句话说：

• 上面一层负责“现在怎么看这个人、公司、项目”
• 下面一层负责“事情是怎么一步步发生的”

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

瘦CLI，胖Skills

整份gist还有一个非常鲜明的设计取向：

thin CLI, fat skills

Garry直接把GStack那套方法论搬了过来。他的判断是：

• CLI只负责入口
• 智能和工作流尽量放进SKILL.md文件
• 启发式规则、边界情况、用户流程都放到markdown里维护

这样做有几个直接的好处：

• 不用每次改逻辑都重新编译应用
• Claude Code这类agent读一份skill文件就能知道工作流
• 不用把数据摄取、查询、检查的所有逻辑都写死在应用代码里

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

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

简单说，GStack管“怎么做事”，GBrain管“怎么存知识”。

从第一天起就支持MCP

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

MCP from day one

Garry的判断很直接：以后不管是Claude Code、Wintermute、Cursor、Windsurf，还是别的MCP客户端，都需要能读写这份知识库。

所以GBrain更像是一个：

• 能serve
• 能暴露tool
• 能对接MCP客户端

的通用知识底座。

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

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

Gist里放出了很长的SQL schema。把它压缩一下，核心表大概是这些：

• pages（页面）
• page_fts（全文搜索索引）
• page_embeddings（向量嵌入）
• links（链接关系）
• tags（标签）
• raw_data（原始数据）
• timeline_entries（时间线条目）
• ingest_log（数据摄取日志）
• config（配置）

这些表放在一起，已经能说明GBrain想做的，远超“把Markdown搬进SQLite”。它还想把下面这些关系一起结构化：

• 页面之间的链接
• 标签
• 原始的sidecar JSON
• 时间线事件
• 以及数据摄取过程本身

其中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的知识后端。

无损迁移与可往返

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

lossless migration / round-trippable（无损迁移 / 可往返）

也就是说：
• 迁移到SQLite后不能丢内容
• 还要能导回原来的markdown结构

这条要求说明他不想做一套“进来就别想再出去”的新系统。他想保留的是：
• 数据库更适合日常使用
• markdown仍然作为逃生舱保留

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

这份Gist真正在讨论什么

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

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

Garry给出的答案很明确：
• wiki的结构可以保留
• “编译的真相+时间线”这套模式也可以保留
• 但底层需要换成数据库

这已经是在重新设计个人知识管理的存储层了。

这份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可接入

如果你也在做以下几件事，那这份gist值得细读：
• 个人知识库
• 本地agent的记忆层
• Wiki + RAG + MCP的混合系统

它里面的很多选择，已经触及了“这层基础设施到底该怎么搭”这个核心问题。