截至 2026 年 6 月。本文整理自 Karpathy 的 LLM Wiki gist、Mem0 開源項目資料，以及實務界對 context 上限的討論，資料以官方來源為準。
過去一年，做 AI Agent 的人都在比同一件事：誰的 context 視窗更長。從 8K 到 128K，再喊到 100 萬 token。聽起來像是把記憶問題解決了。但真正每天在用 Claude Code、Codex CLI 這類工具的人都知道一個尷尬的事實：跑久一點，畫面右下角就會冒出「context 接近上限」，然後你的 AI 就把三小時前一起定好的決定忘得乾乾淨淨。視窗再長，它還是金魚腦。
於是 2026 最值錢的問題，從「視窗能塞多長」變成了「怎麼讓 AI 真的記得住」。最有意思的是，圈子裡兩個分量很重的答案，方向幾乎相反。一邊是前 OpenAI 創始成員 Andrej Karpathy，他的答案是一個只有一個畫面大、卻被 5,000 多人 fork 的 markdown 檔。另一邊是一個衝上 4 萬多星的開源項目 Mem0，它把記憶做成了一整套可以插在任何 Agent 上的基礎設施。
一句話結論：給 AI Agent 裝記憶有兩條路 —— Karpathy 的 LLM Wiki 是「DIY 一份會自己長大的 markdown 檔」，適合個人、零代碼、想自己掌控內容；Mem0 是「可插任何 Agent 的記憶層基礎設施」，適合要做產品、要自動記住每個用戶的人。
為什麼你的 AI 每次都失憶？
因為大部分 AI 工具根本沒有「記憶」這個東西，它有的只是「context」。你開一個新對話，等於請了一個失憶症患者：你這次塞給它多少資料，它就只知道這些；視窗滿了，最早講的就被擠出去；關掉視窗，全部歸零。下次再來，又是一張白紙。
把視窗加長只是把這張白紙變大一點，沒有改變「每次都重來」的本質。資料每次都要重讀，上一次辛苦整理出來的結論沒有沉澱下來，全部蒸發。記憶跟 context 是兩件事：context 是它這一刻看得到的桌面，記憶是它跨越多次對話、能持續累積的腦。問題從來不是桌面不夠大，是它根本沒有腦。
context 視窗一直加長，不就解決了嗎？
不行，而且越來越多在第一線跑長任務的人發現這條路會撞牆。視窗塞越滿，模型反而越容易在中段資料上「分心」，抓重點的能力下降，這就是大家常說的「lost in the middle」。再加上長 context 的成本和延遲是實打實往上跳的，每多塞一萬 token，你都在多付錢、多等時間。
真正的解法不是「全部塞進去」，而是「只在需要的時候，把對的那一小塊調出來」。這就是記憶層要做的事：把該記的東西整理、存起來，要用的時候精準取回幾條相關的，而不是把整本書攤在桌上讓模型自己慢慢翻。兩個答案——Karpathy 的和 Mem0 的——其實都在解這同一件事，只是一個交給你自己整理，一個交給系統自動化。
第一條路：Karpathy 的 LLM Wiki，一個會自己長大的檔案
Karpathy 的想法簡單到有點反高潮：讓 AI 增量維護一份結構化、互相連結的 markdown 知識庫。你讀的每篇文章、每段筆記，都讓 AI 消化進這份檔案，寫成條目，跟舊條目拉上連結。知識「編譯一次、之後持續更新」，而不是每次提問都從生資料重算一遍。
就是這份「一個畫面就放得下」的 gist，成了 2026 最有影響力的 Agent 記憶文件之一：5,000 多個 star、5,000 多次 fork。一個 markdown 檔，沒有任何花俏的架構。
它的好處是你完全看得懂、完全掌控。記憶就是一份你能直接打開來讀、來改的文字檔，AI 怎麼整理你一目了然，不爽就自己動手調。壞處也很明顯：它是「個人手工藝」，沒有自動判斷一條新訊息該更新還是丟棄的機制，規模一大、條目一多，這份 wiki 會開始「腐化」——重複、過時、互相矛盾的東西堆積起來。社群後來補的 v2 版本，加的也正是這些「在規模下會壞掉」的補丁。
第二條路：Mem0，把記憶做成可以插的基礎設施
Mem0 走的是完全相反的方向。它不要你手寫任何檔案，而是提供一個「記憶層」：一個 API，背後同時跑三種儲存——向量嵌入做語義相似、知識圖譜做關係、key-value 做結構化事實。每進來一條訊息，它自動判斷要 ADD（新增）、UPDATE（更新）、DELETE（刪除）還是 NOOP（什麼都不做），然後在你提問時把最相關的幾條記憶取回來餵給模型。
關鍵字是「可插」。它跟框架無關，LangChain、CrewAI、AutoGen 或裸 API 都能接，記憶還分 user（用戶層）、session（單次對話層）、agent（Agent 自身層）三種範圍。翻成白話：你做一個客服機器人或 AI 助理，接上 Mem0 之後，它就會記得每個用戶上週說過什麼、有什麼偏好，不用你自己寫一套記憶系統。這個項目衝到 4 萬多星不是沒原因的——2025 年 10 月拿了 2,400 萬美元 A 輪，官方整合文件已經覆蓋 21 個框架與平台。它解決的是「做產品的人不想重造記憶輪子」這個痛點。
那我該選哪一條？
看你是「為自己整理知識」還是「做給別人用的產品」。先看下面這張表，再用底下那個小工具點兩下，幫你定方向。
| Karpathy LLM Wiki | Mem0 | |
|---|---|---|
| 本質 | 一份你維護的 markdown 檔 | 可插任何 Agent 的記憶層 API |
| 要不要寫代碼 | 幾乎不用，會用 AI 助手即可 | 要，是給開發者接的 |
| 最適合誰 | 個人做研究、追行業、自媒體、知識沉澱 | 做 AI 產品、要自動記住每個用戶 |
| 內容掌控 | 完全透明，自己看得到改得到 | 系統自動管理，較難逐條手調 |
| 規模一大 | 容易腐化，要人手維護 | 自動去重、更新，為規模而設計 |
| 成本 | 幾乎零，就一個檔案 | 自架免費，託管版按用量計費 |
🧭 你該走哪條路？點一下你的情況
你主要想做什麼？
你今天就能動手：LLM Wiki 的最小可行版
如果你是上面那個小工具指向 Karpathy 這條路的人，好消息是門檻低到誇張。你不需要會 Python，不需要懂向量資料庫，只要一個能讀檔案、能寫檔案的 AI 助手（Claude 桌面版、ChatGPT 桌面版，或任何能存取本地資料夾的 Agent）就夠。三步：
- 建三個資料夾：一個放原始材料（你蒐集的文章、PDF、筆記，越雜沒關係）；一個放 wiki（讓 AI 把整理好的條目寫進這裡）；一個放問答（你問過的問題和它整理的答案）。
- 給 AI 一條規則：請它讀「原始材料」，把內容拆成一篇篇主題條目寫進「wiki」，相關條目之間互相用連結串起來，重複或矛盾的地方標出來。最重要的一句是叫它「增量更新」——新材料進來只補新的，不要每次重寫整個庫。
- 之後只做兩件事：持續把新讀到的東西丟進「原始材料」；要用的時候去問它，讓它根據已經整理好的 wiki 回答。久了你會發現問題越來越能一句話命中，因為這顆腦被你養起來了。
先別追求完美。挑一個你最近在追的主題，丟十來份材料試一次，跑通了再擴大。想看完整的個人知識庫玩法，可以接著讀我們之前那篇 Karpathy 的「第二大腦」用法。
Tony 的看法：這場「DIY vs 基礎設施」之爭，跟你想的不一樣
很多人把這當成「散戶玩具 vs 開發者神器」的高下之分，我覺得這個框架錯了。真正的分野是「誰來扛維護成本」。Karpathy 那條路把維護成本丟給你自己——好處是透明可控，壞處是你一鬆手它就腐化。Mem0 那條路把維護成本交給系統——好處是自動、能擴張，壞處是你比較難看清它到底記了什麼、為什麼這樣記。
對絕大多數不寫程式的人，我的建議很直接：從 LLM Wiki 開始，而且現在就開始。不是因為它技術上更先進，而是因為「會自己長大的知識庫」這件事本身的回報，遠比大家盯著的「AI 會不會取代程序員」更貼近你的日常。你做投資研究、追一個行業、經營自媒體，本質上都是在把雜亂材料變成可用知識，這跟 Karpathy 在做的事一模一樣。記憶這個東西的價值是複利的，越早開始那顆腦越值錢。等你真的要把它變成一個產品、要服務成千上萬個用戶了，再去碰 Mem0 也不遲。
常見問題
Q：這跟 RAG（檢索增強生成）是同一件事嗎？
不完全是。RAG 偏向「把外部文件切塊、要用時檢索丟給模型」，重點在取回原始片段。記憶層更進一步：它會把資訊消化、整理、判斷該更新還是丟棄，存的是「整理過的知識」而不只是「原始片段」。LLM Wiki 和 Mem0 都比單純 RAG 多了這層「消化與維護」。
Q：我只是用 ChatGPT 聊天，需要搞這些嗎？
如果只是偶爾問問題，不用。但只要你開始長期追某個主題、需要 AI 記得你的脈絡和偏好，「每次重來」就會變成最浪費時間的環節，這時候 LLM Wiki 的三資料夾做法會幫你省回大量重複輸入。
Q：Mem0 要付費嗎？
它是開源的，自己架（self-host）免費；官方也有託管版（managed），按用量計費。想先試水溫，自架版就能跑。
本文為資訊整理與個人觀點分享，不構成任何投資或技術採購建議。文中工具的星數、融資與功能資訊截至 2026 年 6 月，AI 項目更新極快，實際以官方最新公告為準。
發表迴響