YC掌門人開源他的第二大腦：13年記憶，15000份文件，可接入龍蝦

如果你今天問任何一個 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