如果你今天问任何一个 AI Agent：“昨天你帮我做了什么？”不用说，它大概率会“一脸茫然”，然后开始胡言乱语。

这是因为绝大多数基于 LLM 的智能体都受困于“无状态困境”（Stateless Dilemma）：会话一旦结束，记忆即刻清零。下一次对话，永远是从零开始的冷启动。你反复解释过的项目背景、合作伙伴的性格偏好、你曾经表达过的观点，对 Agent 而言都是一片虚无。这也是阻挡 Agent 从“好用的工具”进化为“真正的助手”的障碍之一。

近日，Y Combinator（以下简称 YC）总裁兼 CEO Garry Tan 宣布将自己日常使用的个人知识系统 “GBrain” 开源。他在 X 上写道：“我希望所有人都能拥有自己的‘个人迷你AGI’。”截至目前，该项目在 GitHub 上已获得超过 5,000 颗星。

（来源：X）

这并非 Garry Tan 近期的唯一动作。一个月前，他发布的基于 Claude Code 的结构化提示词工作流 gstack 曾在一周内斩获超 69,000 颗 Star。尽管有人批评那“本质上只是文件夹里的一堆提示词”，但此次推出的 GBrain 瞄准的是一个更底层、更核心的问题：不仅要让 Agent 更好地执行单次任务，更要赋予其持续积累、不断进化的长效记忆。

（来源：GitHub）

按照 GBrain 的 README 文档描述，整个系统的核心思路可以用一句话概括：让 Agent 经历读取—对话—写入的闭环。

每当有新信号进入系统：可能是一封邮件、一段会议录音、一条推文，甚至是日历上的某个行程变动……Agent 会先查询已有知识库（读取），在充分理解上下文之后作出回应（对话），然后将这次交互产生的新知识写回知识库（写入），供下一次查询使用。

Tan 在文档中把这称作“大脑-Agent 循环”，他认为这个循环的意义在于：每走一圈，Agent 就比上一圈更懂你。

这套循环到底解决什么问题？可以设想一个具体场景。作为 YC 的 CEO，Tan 每周可能要与数十位创始人、投资人和合作伙伴打交道。假设他周二下午和某位创始人开了一场产品评审会，会议录音被自动转录后流入 GBrain，Agent 会做几件事：首先识别出会议中提到的所有人名和公司名（实体检测），然后去知识库查找这些人和公司是否已有对应页面。

如果已有，比如这位创始人三个月前在另一场会议上已经见过。Agent 就把新的会议要点追加到那个人的时间线里，同时更新页面顶部的综合判断：这个人目前在做什么、关心什么、上次和你讨论过什么。如果是第一次出现的陌生面孔，Agent 则会创建新页面，并通过 Web 搜索、LinkedIn 数据、甚至 X 上的公开发言来填充背景资料。

这样一来，两周后当 Tan 再次见到这位创始人时，他不需要翻邮件、查日历、回忆上次聊了什么。Agent 已经把所有上下文打包好了。

这种能力在处理复杂检索时尤为显著。例如，当你询问“去年 3 月那次晚宴都有谁参加”时，传统方式需要手动拼凑日历、邮件和聊天记录；而在 GBrain 体系下，由于每次交互都已被结构化并关联至对应人物页面，查询可快速返回完整名单。

简言之，GBrain 解决的核心痛点是：让每一次对话都建立在过往所有积累的基石之上，而非每次都从零开始。

GBrain 是基于 Tan 真实生产环境部署总结而来。其知识库包含 14,700 多个“大脑页面”（Markdown 文件）、40 多个 Agent 技能以及 20 多个持续运行的定时任务。这些数据跨度长达 13 年，涵盖日历、Apple Notes、邮件、会议纪要及社交关系。

当数据规模增长至约 3,000 个人物页面和 5,800 条笔记时，传统的文本搜索工具（如 grep）已彻底失效，这正是 GBrain 诞生的直接动因。

技术实现层面，GBrain 选择了一条相当务实的路线。它默认使用 PGLite，一个通过 WebAssembly 运行的嵌入式 Postgres 17.5 数据库。在本地即可完成初始化，无需 Docker、无需云服务账号，官方声称数据库就绪时间约 2 秒。检索方面，GBrain 采用混合搜索策略：关键词精确匹配搭配基于 pgvector 的向量语义搜索，再通过 RRF（Reciprocal Rank Fusion，一种排序融合算法）将两路结果合并。

GBrain 中最吸引人的环节当属它的“梦境循环”（Dream Cycle）机制。

Tan 在README 中这样描述这个机制：“Agent 在我睡觉的时候运行。梦境循环会扫描当天每一段对话，充实缺失的实体信息，修复损坏的引用，合并冗余记忆。我早上醒来，大脑已经比我睡着前更聪明了。”在 Tan 的配置中，他使用的是 OpenClaw，因此通过一个 DREAMS.md 的文件承载这一逻辑。但他也补充，对于使用 Hermes Agent等其他框架的用户，则可以通过设定夜间定时任务来实现类似效果。

GBrain 的知识模型还采用了一种“编译真相”（Compiled Truth）架构：每个人物页、公司页或概念页的顶部放置当前最佳判断的综合摘要，底部则是不可修改的时间线条目，记录原始证据。随着新证据不断涌入，Agent 会自动重写顶部的综合判断，但底部的证据链永远不会被篡改。

在 SKILLPACK 文档的开篇，Tan 聊到了这个“第二大脑”的灵感来源——Vannevar Bush 1945 年发表在《大西洋月刊》上的经典论文《As We May Think》中描述的 Memex 设想：一台能够存储个人所有书籍、记录和通信，并通过“关联索引”进行极速灵活检索的设备。

（来源：The Atlantic)

但 Tan 指出了关键区别：Bush 的 Memex 是被动的，需用户手动建立关联；而 GBrain 是主动的，Agent 会自动检测实体、创建交叉引用并维护真相。“你不需要去建造 Memex，”Tan 写道，“Memex 自己会建造自己。”

这一思路与 Andrej Karpathy 近期关于“LLM 知识库”的工作异曲同工。Karpathy 主张用 LLM 充当“全职研究馆员”，取代传统 RAG（检索增强生成）管道中低效的即时拼凑模式。在 4 月 10 日的推文中，Tan 明确提及了 Karpathy 的工作对他的启发。

尽管愿景美好，但围绕 GBrain 的质疑同样存在。DEV Community 上一篇由 Penfield Labs 发表的分析文章在仓库上线六天后就对代码进行了审查，得出了不太乐观的结论：GBrain README 中宣传三个重要功能：编译真相重写、梦境循环维护、以及每条消息上的实体检测，在代码库中均无对应的程序逻辑实现。

文章认为，这些功能本质上是写在 Markdown 文档中的 Agent 指令，依赖 LLM 去解读和执行，而非通过确定性代码实现。此外，项目 Issue #22 中记录了 12 个关键 Bug，包括竞态条件、NULL 嵌入覆盖等，安全审计甚至标注其 S3 后端“未达到生产就绪”状态。

这些质疑触及了一个更深层的争论：当一个系统的核心功能是通过自然语言指令让 LLM 代为执行，而非通过确定性代码实现时，它究竟算不算一个“软件产品”？还是更接近于一套精心编排的提示词工程？

此外，GBrain 文档承认，系统需要前沿级别的模型（如 Claude Opus 4.6 或 GPT-5.4 Thinking）才能正常运行，使用较小模型可能导致系统崩溃。这意味着，如果未来 LLM 的输出一致性出现波动，这种高度依赖模型行为的架构能否保持稳定，仍是一个未知数。

对于前一个问题，或许从更宽容的角度去解读。随着 LLM 能力的跃升，“用自然语言取代部分硬编码逻辑”可能正成为一种合理的架构选择。正如 Karpathy 所言，在这个时代，分享想法比分享代码更有意义。因为每个人的Agent 可以根据同一个“想法文件”，自行构建适合自身的实现。

从这个角度看，GBrain 的 SKILLPACK 文档或许更像是一本“模式手册”。它告诉 Agent 在何种情境下该做什么，而具体如何执行，则交由对话当下的 LLM 自行判断。

1.https://x.com/garrytan

2.https://github.com/garrytan/gbrain