今日總覽
「Agent 記憶該多複雜」聽起來像一個問題，但今天三篇論文告訴你這其實是三個不同的問題，答案也不一樣。對話記憶：Naive RAG 這個只做檢索加重排的簡單基線，打贏了 12 種設計過的 agentic 記憶系統——複雜的記憶管理在這裡大多是在浪費工程。任務規劃記憶：MemPlan 走相反方向，證明純靠 LLM 自己記對話歷史不夠，得把記憶編譯成符號規劃器看得懂的正負約束才行——這裡複雜的結構化設計才是贏家。多 Agent 協調記憶：Muffin 示範介於兩者之間的答案——不需要像傳統多 agent 辯論那樣交換完整思考過程，輕量的共享筆記緩衝就能拿到更好的準確率，還省下七成以上的 token。三篇合起來：不存在一個通用答案叫「記憶要簡單」或「記憶要複雜」，先搞清楚你的記憶是在扮演哪一種角色，才知道該往哪個方向設計。
簡化示意：三篇論文各自測試同一個記憶角色下的複雜方案與簡單方案，贏家（標色方框）因角色而不同。
讀這篇前該知道的詞
| 詞 | 白話解釋 |
|---|---|
| Agentic Memory（代理式記憶系統） | 不只做檢索，還會對記憶做擷取、摘要、整理、建圖甚至修改的記憶系統，跟單純的檢索增強生成是不同層級的設計 |
| RAG（檢索增強生成） | 查詢時先用檢索找出相關文字片段，再交給語言模型根據這些片段作答的基本架構 |
| PDDL（規劃領域定義語言） | 描述物件、動作的前置條件與效果的符號化規劃語言，古典 AI 規劃器（如 Fast Downward）靠它搜尋一串可行動作 |
| 正／負記憶（Positive/Negative Memory） | MemPlan 把過去互動拆成兩種記憶：正記憶標記「哪個假設比較值得先試」，負記憶標記「哪個假設已經被環境證明錯了，別再試」 |
| 共享記憶緩衝（Shared Memory Buffer） | 多個 agent 之間只交換精簡的中間發現筆記，而不是完整的推理過程或對話紀錄 |
論文一｜對話記憶不用太複雜：Naive RAG 打贏 12 種 Agentic 記憶系統
Is Complex Agentic Memory Always Needed? Naive RAG Is Stronger Than We Thought Zhengye Bao, Shengtao Zhang, Haokai Zhang et al.（Xi'an Jiaotong University） · arxiv: 2610.30755
TL;DR
一個只做密集檢索加重排的簡單基線 Raw-RAG，在 LoCoMo、LongMemEval、MEME、MemoryAgentBench 四個長期對話 benchmark、七組 benchmark-model 設定中六次排名第一，打贏 EverMemOS、Mem0、MemOS 等 12 種設計過的 agentic 記憶系統；追加記憶管理（事實抽取、摘要、建圖）反而讓準確率下降。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint（未經同行審查） |
| 引用速度 | 發布 4 天；Semantic Scholar API 本次執行持續回傳 429（rate limit，未帶 key），依發布時間推定尚無引用資料 |
| 機構 | Xi'an Jiaotong University |
| 社群反應 | HF Daily Papers 收錄（8 個讚，2026-10-23）；Papers with Code 已收錄 |
| 可信度 | 通過 — 4 個 benchmark × 12 個對照記憶系統，附 20,000 次 bootstrap 重抽樣與 Holm 校正的消融實驗，並有 oracle 控制組拆解原因 |
| 證據成熟度 | 較完整 — 核心結論跨四個 benchmark 一致，且有 coverage/utilization 拆解與 complete-store oracle 雙重驗證支撐，但僅限離線對話任務 |
| 可復現性 | 部分產物 — 62 頁含完整 appendix 公開實驗設定、prompt 範本與逐項數據，但未見獨立公開程式碼庫連結 |
| 為什麼選這篇 | 直接 — 直接挑戰「agent 記憶需要複雜管理」這個目前業界預設的假設，任何在評估記憶架構的團隊都該先看這篇 |
| 方向新意 | 實質增量 — 把「記憶管理到底有沒有在幫忙」變成可檢驗的系統性問題,而不是順著既有敘事假設複雜架構一定更好 |
| 今日重要性 | 高 — 目前多數 agent 記憶產品的賣點就是複雜記憶管理，這篇用 12 個對照系統的數字直接質疑這個賣點的必要性 |
| 實務連結 | 明確 — Raw-RAG 的做法（dense retrieval + cross-encoder rerank）是任何團隊都能先上線測試的最低成本基準 |
| 編輯信心 | 高 — 文章採用的「六/七設定排名第一」直接對應 Table 3/4 的原始數字，沒有外推到論文未測的場景 |
| 閱讀建議 | 必讀 — 正在設計或採購 agent 長期記憶系統的團隊 |
| 主要限制 | 僅評估離線對話 benchmark，未涵蓋互動式、多模態或涉及隱私刪除限制的真實部署場景 |
領域背景
近年 agent 長期記憶研究的主流方向是把記憶做得更「聰明」——用 LLM 抽取事實、做摘要、建知識圖、學習何時更新或刪除記憶（如 Mem0、MemOS、A-MEM 等系統）。這篇論文回頭質疑一個更基本的問題：這些複雜操作，真的比最簡單的「把原始對話歷史做檢索加重排」更有效嗎？
中階導讀
- 問題：想像一個記憶系統要處理跨好幾個月、好幾千則訊息的對話歷史。常見直覺是「資訊這麼多，一定要先整理、濃縮、建立結構才找得到重點」——但整理的過程本身可能就在丟失東西。
- 方法：作者先做兩個診斷實驗：審計 Mem0 在 LoCoMo 與 LongMemEval 上的寫入行為，發現「更新」和「刪除」只占全部寫入決策的 2.46–4.39%，把這兩種操作換成「純新增」反而讓準確率從 67.36% 升到 69.42%；接著在 MEME 的動態任務上測試，發現只要給模型足夠的原始證據，複雜的狀態追蹤多半能被模型自己解決。基於這兩個發現，他們提出 Raw-RAG：不做任何 LLM 抽取或結構化，只用密集檢索取出 128 個候選片段、交叉編碼器重排取前 15 個，交給模型回答。
- 為什麼重要：關鍵診斷是「覆蓋率」（檢索到的證據夠不夠）比「利用率」（拿到證據後答不答得對）更能解釋表現差異——Raw-RAG 在覆蓋率上領先（45.29%/76.35%，兩個 benchmark 都最高），而利用率的落差相對小。換句話說，各系統真正輸的地方是「有沒有把需要的原始資訊找出來」，不是「模型會不會用」。
深入要點
- Raw-RAG 在 LoCoMo 領先 0.65–0.95 分、LongMemEval 領先 0.13 分、GPT-4o-mini 版 MEME 領先 2.24 分、MemoryAgentBench 領先 4.48–5.53 分；唯一輸的設定是 DeepSeek-V4-Flash 版 MEME，被 MemMachine 領先 1.52 分
- 追加三種記憶管理操作全部讓 MemoryAgentBench 總分下降：事實抽取 -19.62 分、摘要增強 -5.81 分、圖擴展 -5.78 分，其中事實抽取讓「測試時學習」能力從 47.68% 掉到 15.37%
- 效率差距巨大：在 MEME 子集上 Raw-RAG 完成 add+search 只要 305.91 秒，比次快系統快 5.1 倍、比 EverMemOS 快 30.4 倍；在接近百萬 token 的 BEAM-1M 串流測試中，Raw-RAG 累計寫入僅 0.33 小時，次快的 MemOS 要 3.25 小時，Memora 要 26.95 小時 ⚠️（這些效率數字為作者自測，尚待外部複現）
- Raw-RAG 在 MEME 追蹤/連鎖任務上的「路徑覆蓋率」（連同推導所需的依賴關係一起拿到）達 62.34%，是所有對照系統最高，MemU 只有 9.62%
- 落地門檻：先用 dense retrieval + rerank 的基準線量化現有記憶系統的真實增益，再決定要不要投資複雜記憶管理，不要預設複雜一定更好
- Limitation：證據僅限離線對話任務，未測試互動式、多模態場景，也未評估隱私與刪除限制下的行為
Reviewer 一句話評
用 12 個對照系統、4 個 benchmark 做系統性比較，方法論的覆蓋面是這類質疑型論文少見的扎實程度；但論文討論的記憶複雜度集中在檢索與結構化這一層，還沒涉及真實產品常見的隱私刪除、多租戶權限等治理需求，這部分的複雜性是否也能用簡單方案打發，仍待後續驗證。
給你的 take-away
- 如果你在設計或採購長期對話記憶系統：先上線一個 dense retrieval + rerank 的 Raw-RAG 基準線，拿它去對照任何打著「複雜記憶管理」賣點的方案，看增量到底值不值得多付的工程成本
- 如果你的團隊已經在用 Mem0/MemOS 類系統：檢查一下系統裡「更新」「刪除」操作的實際占比與有效率，這篇顯示這類操作往往占比很低，卻可能是不穩定性的來源
論文二｜任務規劃記憶該怎麼設計：MemPlan 把記憶變成規劃的正負約束
MemPlan: Memory-Conditioned PDDL Planning for Partially Observable Text Environments Tengwei Song, Robert Hoehndorf（KAUST + Åbo Akademi University, Finland + ELLIS Institute Finland） · arxiv: 2610.30379
TL;DR
NeurIPS 2026 接受的 MemPlan 把 LLM 限定成觀察解析與動作接地的介面，把互動記憶拆成「正記憶」（候選假設的優先順序）與「負記憶」（已被環境否定的假設排除），編譯進固定的 PDDL 規劃問題，在 TextWorld、ALFWorld、Robotouille 三個環境上都勝過純語言記憶代理與多個 PDDL 輔助基線。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | NeurIPS 2026（已接受，非單純 preprint） |
| 引用速度 | 發布 5 天；Semantic Scholar API 本次執行持續回傳 429（rate limit），依發布時間推定尚無引用資料 |
| 機構 | KAUST + Åbo Akademi University（Finland）+ ELLIS Institute Finland |
| 社群反應 | Papers with Code 已收錄；官方 GitHub 公開程式碼與資料（github.com/tewiSong/MemPlan） |
| 可信度 | 通過 — 三個互動環境（134 個 ALFWorld episode、7 個 TextWorld 任務、151 個 Robotouille task-seed run）的完整實驗，加六項消融拆解各元件貢獻，並經 NeurIPS 2026 同行審查 |
| 證據成熟度 | 較完整 — 三個環境、多組基線與消融齊全，但 TextWorld 記憶代理比較僅 7 個任務實例，作者自行提醒該設定下的證據不宜過度外推 |
| 可復現性 | 完整產物 — 官方 GitHub 公開程式碼與資料，appendix 詳列訓練資料量與超參數敏感度分析 |
| 為什麼選這篇 | 直接 — 跟入選的 Naive-RAG 形成對照：同樣是質疑記憶複雜度，這篇卻證明規劃型任務的記憶需要更結構化的設計才贏得過純語言記憶代理 |
| 方向新意 | 實質增量 — 把記憶直接編譯成 PDDL 的動作成本與排除約束，而不是當成 LLM 決策時的額外文字上下文，這個記憶使用方式與既有 LLM-memory agent 不同 |
| 今日重要性 | 高 — 對需要長程、部分可觀測任務規劃的 agent（機器人、流程自動化）而言，這是少見同時有同行審查與公開程式碼的結構化記憶方案 |
| 實務連結 | 明確 — 正負記憶機制與固定領域、線上重建問題的設計可直接套用到任何已有 PDDL 領域描述的規劃型 agent |
| 編輯信心 | 高 — 文章採用的「三環境勝出、消融驗證各元件必要性」直接對應論文的 Table 1-4 與演算法描述 |
| 閱讀建議 | 必讀 — 正在做長程任務規劃型 agent（機器人、流程自動化）的團隊；略讀 — 只處理短程、全可觀測任務的場景 |
| 主要限制 | 假設已有涵蓋完整的 PDDL 領域描述，MemPlan 本身不自動產生或線上修補領域規則；負記憶採硬性排除，回饋有誤時可能過早排除掉正確候選 |
領域背景
把 LLM 當成長程任務的主要規劃者容易產生幻覺動作或忘記早期觀察，而古典符號規劃器（如 Fast Downward）雖然搜尋可靠，卻需要一個完整的符號狀態才能運作——但部分可觀測的文字環境往往缺了這塊。既有做法要麼讓 LLM 猜一個完整狀態再規劃（一旦猜錯就要反覆試錯），要麼讓 LLM 線上重寫 PDDL 檔案（容易產生格式錯誤或幻覺事實）。MemPlan 選了第三條路：domain 固定不變，只讓記憶機制決定每一步該怎麼重建 problem。
中階導讀
- 問題：想像一個 agent 要在陌生房子裡找一把鑰匙開一個箱子，但它看不到全貌，只能一步步探索。每次它猜鑰匙可能在某個抽屜卻猜錯，傳統做法很容易一直重複猜同一批已經被排除的地方，或者因為不知道該去哪裡猜而亂走。
- 方法：MemPlan 固定一個 PDDL domain，每一步從觀察解析出的事實、未解決的候選假設、正記憶、負記憶重建出一個封閉的 PDDL problem 丟給規劃器。正記憶用 mContriever 嵌入算出候選假設跟目標的相關性，轉成規劃器的動作成本——相關性越高、檢查成本越低，規劃器自然會優先試這些候選；負記憶則把已經被環境證實錯誤的候選直接變成排除約束，不會再被規劃器考慮。整個系統只用一個凍結的語言-符號介面做觀察解析和動作接地，不讓 LLM 自己規劃或重寫 domain。
- 為什麼重要：消融實驗顯示拿掉「佔位符」機制會導致規劃直接失敗（因為還沒觀察到的必要物件沒辦法表示在 PDDL problem 裡），拿掉負記憶則讓 agent 反覆嘗試已被推翻的假設；比起把記憶當成丟給 LLM 看的額外上下文，把記憶編譯成規劃器能直接使用的成本與約束，在這三個環境上都拿到更好的任務完成率與更短的互動步數。
深入要點
- ALFWorld（134 episode）：MemPlan 的互動步數比 GPT-5.1 ReAct 與兩個 PDDLEGO+ 變體都短，線上 token 用量也更低；但 LLM-DP 的線上 token 成本仍是最低
- TextWorld 記憶代理比較（7 個任務實例）：MemPlan 在 Full History、Summary、RAG、Reflexion、Simulacra、AriGraph 六種記憶代理基線中拿到最高的標準化分數 ⚠️（樣本僅 7 個任務實例，作者明確註明應視為該設定下的證據而非廣泛宣稱）
- Robotouille 同步/異步任務：MemPlan 對 ReAct 與 LLM-DP 的領先幅度在異步設定（動作效果延遲出現）比同步設定更明顯，符合「記憶編碼的排除約束在觀察容易過時時更有價值」的直覺
- TextWorld 的 PDDL domain 由 GPT-5.1 離線草擬，5/7（71.4%）一次就有效，剩下 2 個經一輪離線修補後可用——domain 生成全程不接觸測試實例的地圖、物件配置或標準答案
- 落地門檻：需要先有（或能離線產生）涵蓋完整的 PDDL 領域描述，且負記憶的硬性排除機制在回饋含糊或解析錯誤時可能誤傷正確候選，需要額外的穩健性設計
- Limitation：MemPlan 本身不自動產生或線上修補 PDDL domain；評估限於模擬文字環境，未測試安全關鍵的真實部署場景
Reviewer 一句話評
把記憶直接編譯成規劃器能用的成本與約束，而不是丟給 LLM 當額外上下文，是一個方法論上乾淨且經同行審查驗證的設計；但 TextWorld 記憶代理比較的樣本量偏小，且系統高度依賴一個預先給定且正確的 PDDL domain，這個前提在真實、領域描述不完整的場景下能撐多久仍待觀察。
給你的 take-away
- 如果你在做需要長程規劃的 agent（機器人、流程自動化、複雜多步工具呼叫）：評估能不能把任務的核心約束寫成 PDDL domain，再用 MemPlan 式的正負記憶機制處理不確定性，而不是把所有決策都丟給 LLM
- 如果你已經在用 LLM 記憶代理處理互動任務：注意「記憶當成上下文」跟「記憶編譯成規劃約束」是兩種本質不同的使用方式，這篇的消融結果顯示後者在長程、部分可觀測任務上更穩健
論文三｜多 Agent 協調不用全部分享：Muffin 用輕量共享緩衝取代辯論
Muffin - A Shared Memory Buffer for Asynchronous AI Agents Ping-Lin Kuo, Suman Navaratnarajah, Christian Frey et al.（University of Technology Nuremberg, Germany） · arxiv: 2610.31355
TL;DR
Muffin 讓多個 agent 透過一個異步共享記憶緩衝交換精簡的中間發現，而不像傳統多 agent 辯論那樣同步交換完整推理軌跡，在四個推理 benchmark、四個模型的 20 組設定中拿到 17 次最佳準確率，比最強的多 agent 辯論基線多 19.2 個準確率百分點，同時少用 77.4% 的 token。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint（代碼庫匿名，疑似雙盲審稿中，venue 未定） |
| 引用速度 | 發布 4 天；Semantic Scholar API 本次執行持續回傳 429（rate limit），依發布時間推定尚無引用資料 |
| 機構 | University of Technology Nuremberg（UTN）, Germany |
| 社群反應 | 未見 HF Daily Papers 或 Papers with Code 收錄 |
| 可信度 | 通過 — 4 個 benchmark × 4 個模型的 20 組設定、三次重複實驗取平均，附 95% 信賴區間與明確的假設驗證流程（H1-H3），並有消融拆解共享筆記數量與 summarizer 的貢獻 |
| 證據成熟度 | 初步 — 量化比較扎實，但僅限問答與推理型任務，未涵蓋工具使用、規劃或長程執行場景，venue 尚未確認 |
| 可復現性 | 部分產物 — 匿名程式碼庫公開（anonymous.4open.science/r/Muffin），reproducibility statement 詳列 prompt 範本與實驗設定 |
| 為什麼選這篇 | 直接 — 跟入選的另外兩篇形成第三種記憶角色的對照：多 agent 之間要交換多少記憶才夠，答案是「比完整分享少很多」 |
| 方向新意 | 實質增量 — 把「異步共享精簡發現」跟「同步分享完整軌跡」直接做量化對照，而非只提出新架構卻不跟現有辯論範式比效率 |
| 今日重要性 | 中 — 對正在用多 agent 辯論或投票處理複雜推理任務的團隊，這是一個有具體替代方案與量化成本節省的參考 |
| 實務連結 | 明確 — orchestrator 先依推理需求分流、共享緩衝僅傳摘要筆記、summarizer 彙整最終答案的三段式設計可直接套用到其他多 agent 協作場景 |
| 編輯信心 | 中 — 「異步共享筆記勝過同步全軌跡辯論」的主張有四組基準支持，但任務類型較窄、venue 未定，信心不到高 |
| 閱讀建議 | 必讀 — 正在用多 agent 辯論/投票處理複雜推理任務、擔心 token 成本的團隊；略讀 — 只做單一 agent 任務的場景 |
| 主要限制 | 評估僅限問答與推理型 benchmark，未測試工具使用、規劃或長程執行場景；受計算資源限制，未能覆蓋所有閉源與開源模型組合 |
領域背景
多 agent 辯論（multi-agent debate）是目前常見的推理增強手法：讓多個 agent 各自作答，再互相看對方的完整輸出修正自己的答案。但「看對方完整輸出」意味著同步等待與大量 token 開銷，而且論文指出單/多 agent 系統在目標導向推理任務上的效能提升往往打平——問題常常不是「要不要多 agent」，而是「agent 之間該怎麼交換資訊」。
中階導讀
- 問題：想像三個人一起解一道數學題，傳統辯論式作法是每個人把完整的解題過程念給其他兩人聽，再各自修改——這樣資訊量很大、也很花時間；Muffin 想測試的是：如果每個人只分享「我剛發現的一個關鍵線索」這種精簡筆記，而不是整段解題過程，能不能一樣有效、甚至更有效率。
- 方法：Muffin 先用一個 orchestrator 依問題的推理需求分流，簡單問題直接回答，複雜問題才送進多 agent 協作；協作時，agent 把私有推理留在本地，只把中間發現寫進一個共享緩衝讓其他 agent 異步讀取，不用等所有人同一輪結束才交換；最後由一個 summarizer 彙整各 agent 的精簡摘要（不是完整推理軌跡）產生最終答案。
- 為什麼重要：拆解分析顯示，分享的中間發現在早期步驟最有價值——第一輪的發現有 51.6% 的機率把一個錯誤答案糾正成正確答案，只有 14.2% 的機率把對的答案帶偏；到後面幾輪，隨著共享緩衝累積的資訊增加，糾錯與帶偏的比例逐漸拉近到 34.8% 比 21.9%。這代表精簡分享的邊際價值集中在早期，不需要持續用完整軌跡去堆疊後續輪次。
深入要點
- 四個模型（gemma-4-E4B-it、gemma-4-31B-it、Qwen3.8-27B、Qwen3.5-4B）在 Chess Move Validity、MMLU-Pro、GPQA-Diamond、OlymMATH 四個 benchmark 共 20 組設定中，Muffin 拿到 17 次最佳、3 次次佳
- 在 OlymMATH-Easy 上，Muffin 比最強多 agent 辯論基線多 19.2 個準確率百分點，同時少用 77.4% 的 token；summarizer 彙整步驟讓最終準確率從 44.9% 跳到 59.2%
- Agent 數量消融：2→3 個 agent 讓準確率從 50.6% 提升到 59.3%，但再加到 4 個或 5 個只剩 59.7%／58.7%，token 用量卻持續增加 ⚠️（這是收益遞減、而非線性擴展的訊號，團隊規模不該無限加碼）
- 跟完整軌跡分享的對照：最終步驟，完整軌跡把準確率從 85.0% 推到 87.3%，但要多用 73.9% 的 token（160.6K vs 41.9K），顯示大部分的分享收益用精簡筆記就能拿到
- 共享筆記數量不是越多越好：對小模型（gemma-4-E4B-it）而言 k=10 比 k=5 多拿 5.0 個百分點，但再加更多反而掉分；大模型（gemma-4-31B-it）對這個參數的敏感度低很多（僅 ±2.0 個百分點）
- 落地門檻：先確認你的任務是否真的需要多步協作（orchestrator 分流這一步能先篩掉不需要協作的簡單問題），再決定 agent 數量與共享筆記預算，別預設「agent 越多、分享越完整」就一定更好
- Limitation：評估集中在問答與推理型任務，作者明確指出未來需要在工具使用、規劃、長程執行的場景驗證共享緩衝的效果；也因計算資源限制未能覆蓋所有模型組合
Reviewer 一句話評
用「異步精簡分享 vs 同步完整分享」做直接的量化對照，而不是只提出新架構就宣稱更好，是這篇在方法論上的加分；但目前的任務類型集中在問答與推理，venue 也還未確認，共享緩衝能不能延伸到工具使用或長程執行的多 agent 場景，仍是作者自己點名的下一步。
給你的 take-away
- 如果你的多 agent 系統目前用同步辯論或完整軌跡分享：先測一版只分享精簡中間發現的異步版本，這篇顯示大部分準確率收益不需要完整軌跡就能拿到，可以先省下大量 token
- 如果你在設計多 agent 的 agent 數量與協作深度：不要假設「更多 agent、更多分享」單調提升效果，先用小規模消融找出你任務的收益遞減點，再決定資源配置
今日收穫
之前以為「agent 記憶該多複雜」有一個放諸四海皆準的答案，今天發現答案其實取決於記憶在扮演哪一種角色：對話記憶（Naive RAG 打贏 12 種複雜系統）跟多 agent 協調記憶（Muffin 用輕量共享緩衝勝過全軌跡辯論）都指向「簡單夠用」，但任務規劃記憶（MemPlan 把記憶編譯成 PDDL 正負約束才贏過純語言記憶代理）卻指向「需要結構化設計」。三篇放在一起最有意思的不是哪一篇對哪一篇錯，而是它們一起說明了：「記憶」從來不是單一問題，設計前先問清楚是哪一種角色,比直接套用「越複雜越好」或「越簡單越好」的口號更重要。
參考資料
- Is Complex Agentic Memory Always Needed? Naive RAG Is Stronger Than We Thought (arXiv:2610.30755)
- Naive RAG vs Agentic Memory — alphaxiv
- Naive RAG vs Agentic Memory — Hugging Face Daily Papers
- MemPlan: Memory-Conditioned PDDL Planning for Partially Observable Text Environments (arXiv:2610.30379)
- MemPlan — alphaxiv
- MemPlan — official repository
- Muffin - A Shared Memory Buffer for Asynchronous AI Agents (arXiv:2610.31355)
- Muffin — alphaxiv
- Muffin — anonymous code repository