如果你今天问任何一个 AI Agent：“昨天你帮我做了什么？”不用说，它大概率会“一脸茫然”，然后开始胡言乱语。
这是因为绝大多数基于 LLM的智能体都受困于“无状态困境”（Stateless Dilemma）：会话一旦结束，记忆即刻清零。下一次对话，永远是从零开始的冷启动。你反复解释过的项目背景、合作伙伴的性格偏好、你曾经表达过的观点，对 Agent而言都是一片虚无。这也是阻挡 Agent从“好用的工具”进化为“真正的助手”的障碍之一。
近日，Y Combinator（以下简称 YC）总裁兼 CEO Garry Tan宣布将自己日常使用的个人知识系统“GBrain”开源。他在 X上写道：“我希望所有人都能拥有自己的‘个人迷你AGI’。”截至目前，该项目在 GitHub上已获得超过5,000颗星。
这并非 Garry Tan近期的唯一动作。一个月前，他发布的基于 Claude Code的结构化提示词工作流 gstack曾在一周内斩获超69,000颗 Star。尽管有人批评那“本质上只是文件夹里的一堆提示词”，但此次推出的 GBrain瞄准的是一个更底层、更核心的问题：不仅要让 Agent更好地执行单次任务，更要赋予其持续积累、不断进化的长效记忆。
按照 GBrain的 README文档描述，整个系统的核心思路可以用一句话概括：让 Agent经历读取—对话—写入的闭环。
每当有新信号进入系统：可能是一封邮件、一段会议录音、一条推文，甚至是日历上的某个行程变动……Agent会先查询已有知识库（读取），在充分理解上下文之后作出回应（对话），然后将这次交互产生的新知识写回知识库（写入），供下一次查询使用。
Tan在文档中把这称作“大脑-Agent循环”，他认为这个循环的意义在于：每走一圈，Agent就比上一圈更懂你。
这套循环到底解决什么问题？可以设想一个具体场景。作为 YC的 CEO，Tan每周可能要与数十位创始人、投资人和合作伙伴打交道。假设他周二下午和某位创始人开了一场产品评审会，会议录音被自动转录后流入 GBrain，Agent会做几件事：首先识别出会议中提到的所有人名和公司名（实体检测），然后去知识库查找这些人和公司是否已有对应页面。
如果已有，比如这位创始人三个月前在另一场会议上已经见过。Agent就把新的会议要点追加到那个人的时间线里，同时更新页面顶部的综合判断：这个人目前在做什么、关心什么、上次和你讨论过什么。如果是第一次出现的陌生面孔，Agent则会创建新页面，并通过 Web搜索、LinkedIn数据、甚至 X上的公开发言来填充背景资料。
这样一来，两周后当 Tan再次见到这位创始人时，他不需要翻邮件、查日历、回忆上次聊了什么。Agent已经把所有上下文打包好了。
这种能力在处理复杂检索时尤为显著。例如，当你询问“去年3月那次晚宴都有谁参加”时，传统方式需要手动拼凑日历、邮件和聊天记录；而在 GBrain体系下，由于每次交互都已被结构化并关联至对应人物页面，查询可快速返回完整名单。
简言之，GBrain解决的核心痛点是：让每一次对话都建立在过往所有积累的基石之上，而非每次都从零开始。
（来源：GitHub）
GBrain是基于 Tan真实生产环境部署总结而来。其知识库包含14,700多个“大脑页面”（Markdown文件）、40多个 Agent技能以及20多个持续运行的定时任务。这些数据跨度长达13年，涵盖日历、Apple Notes、邮件、会议纪要及社交关系。
当数据规模增长至约3,000个人物页面和5,800条笔记时，传统的文本搜索工具（如 grep）已彻底失效，这正是 GBrain诞生的直接动因。
技术实现层面，GBrain选择了一条相当务实的路线。它默认使用 PGLite，一个通过 WebAssembly运行的嵌入式 Postgres17.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 Bush1945年发表在《大西洋月刊》上的经典论文《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 Opus4.6或 GPT-5.4 Thinking）才能正常运行，使用较小模型可能导致系统崩溃。这意味着，如果未来 LLM的输出一致性出现波动，这种高度依赖模型行为的架构能否保持稳定，仍是一个未知数。
对于前一个问题，或许从更宽容的角度去解读。随着 LLM能力的跃升，“用自然语言取代部分硬编码逻辑”可能正成为一种合理的架构选择。正如 Karpathy所言，在这个时代，分享想法比分享代码更有意义。因为每个人的Agent可以根据同一个“想法文件”，自行构建适合自身的实现。
从这个角度看，GBrain的 SKILLPACK文档或许更像是一本“模式手册”。它告诉 Agent在何种情境下该做什么，而具体如何执行，则交由对话当下的 LLM自行判断。
