如果你今天問任何一個 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自行判斷。
