Hy Memory 2.0 登場：騰訊一口氣開源了記憶寫入器、框架與 Mac 應用程式

腾讯混元本週一次推出了三樣東西，但其中只有兩樣今天可以安裝。 Hy-Memory-30B-A3B是一個 300 億參數的混合專家模型，它的全部工作就是撰寫記憶——決定代理保留什麼、如何措辭，以及新證據如何覆寫舊內容。 Hy Memory 2.0是圍繞它的框架：一個名為 hy-memory 的 Python 套件，涵蓋聊天、工作與程式設計記憶。而 MemHub是那個應用程式——一款本機優先的 CLI 與 macOS 產品，能把十種不同 AI 工具的對話歷史與程式設計軌跡萃取到你自已磁碟上的一個記憶儲存庫。公告貼文的標題是 Hy-Memory-30B-A3B 擊敗 Claude Opus 5在多個主要記憶框架上。就其所及而言這是真的，而有趣的地方在於它究竟及到哪裡：在四個框架中的三個上，領先幅度不到零點六分，而且整個比較只跑了每個基準的五分之一。我們追蹤過的每一次供應商中斷與回復，都記錄在 Orca AI Incident Archive，其中載有完整紀錄集，以及這起事件前後相鄰的條目。

以下所有內容，若不是讀取自 Tencent 自家的程式碼倉庫、套件註冊表及技術報告，就是標示為 Tencent 自身的說法。這裡沒有任何內容曾被其他人重現，因為截至撰寫本文時，尚未有其他任何人執行過它。

實際發布了什麼，以及何時發布

這三層在彼此相隔約 24 小時內相繼落地，而發行說明對於其中哪些已完成異常具體：

• 該模型——tencent/Hy-Memory-30B-A3B 已於 2026 年 10 月 15 日（09:52 UTC）以 Apache 2.0 授權發佈至 Hugging Face，並隨附同日提交的技術報告 arXiv 2610.22196。

• 該框架 — hy-memory==2.0.1 已於 2026 年 10 月 15 日 17:24 UTC 上傳至 PyPI，而該 monorepo 也在同日開源。GitHub v1.0.0 發行標籤於 10 月 16 日 08:44 UTC 建立。

• 此應用程式 — MemHub 的發行資產已存在：一個經公證的 macOS arm64 磁碟映像檔，在 GitHub 的計算中為 303 MB，另有 Linux arm64 與 x64 執行階段套件，分別為 245 MB 和 251 MB。Windows 被列為不支援。

• 落差——該專案自己的變更記錄指出，MemHub「尚無公開發布版本」，其原始碼版本為 1.0.0（建置 4），而且 npm 發布與 GitHub Release 成品均仍待處理。它打算使用的 npm 套件 memhub-cli，在登錄庫中回傳 404。磁碟映像檔已附加於該發布版本；而原本應該負責取得它們的命令列安裝程式並未發布。

最後這一點值得讀兩次，因為這是正式推出與發行候選版之間的差別。Apple 版本已簽署並公證，這是實打實的工作，而發佈頁面也已累積了寥寥幾次下載。但文件記載的安裝途徑，始於一個在撰寫本文時還不存在的 npm 套件。如果你打算這週試用 MemHub，請預留時間從原始碼簽出，而不是一行安裝。

Hy-Memory-30B-A3B，該模型

設定檔是整個發行版中最不浪漫、卻最實用的一份文件。它描述的是一個標準且廣為理解的 MoE 形態，而不是任何奇特罕見的東西：

• 參數 — 總計 30B，每個 token 約啟用 3B，A3B 後綴指的就是這個。

• 架構 — 48 層，其中 1 層為稠密層，47 層為稀疏 MoE；每個區塊 128 個專家，採用 top-8 路由，外加 1 個共享專家；隱藏大小 2,048；專家中間寬度 768；32 個注意力頭對應 4 個鍵值頭，並使用查詢鍵正規化；一個帶有專家偏置項與縮放因子 2.826 的 sigmoid 路由器。

• 上下文 — 262,144 個位置，RoPE 基底為 11,158,840。

• 佔用空間——51 個 safetensors 分片，BF16 格式約 60.1 GB。這是騰訊唯一發布的精確度。

• 服務 — 這張模型卡是圍繞 vLLM 撰寫，並針對 v0.31.0 測試，且透過 OpenAI 相容端點提供服務，同時也將 SGLang 與 Docker Model Runner 列為支援的執行環境。它未由任何推論供應商部署，而 Hugging Face 搜尋索引也找不到任何 GGUF、任何 FP8 或 NVFP4 建置，以及任何微調。

那種缺席才是實務上的障礙。供應商只釋出一個 60 GB 的 BF16 檢查點，其他什麼都沒有，這等於在告訴你它預期模型要在哪裡執行，而答案就是你已經擁有、或在資料中心租用的機器。沒有任何量化版本能讓人在工作站上評估。

該模型在騰訊自家的快速入門指南中，以 reasoning_effort: "no_think" 和 temperature 0.0 來驅動。記憶寫入器會在每次對話輪次觸發，以決定要保留什麼，因此深思熟慮是錯誤的取捨：它需要是確定性的、輸出簡短且成本低廉。這個設計選擇也是該模型之所以存在的最強論據，因為它正是前沿聊天模型最浪費的工作負載。

55.49，用它該有的讀法來讀

Tencent 在三個記憶框架——Mem0、MemOS 以及自家開發的 Hy-Memory——上訓練了這個寫作者，接著在第四個框架 EverMemOS 上進行評估，而後者完全被排除在訓練之外。把其中一套測試框架保留下來，正是檢驗遷移主張的正確做法，而跨框架遷移正是這篇論文的核心論點。

這些結果是 T​encent 自家的，且未經重現：

• Hy-Memory-30B-A3B — 四個測試框架的巨集平均為 55.49。

• Claude Opus 5 — 54.62.

• DeepSeek V4.1 Flash — 53.64。

• Tencent Hy3 — 51.63.

• Qwen3.6-35B-A3B — 50.37.

• Hy3-A3B Base — 47.66，這是同一個模型在記憶專項訓練之前的結果，而這正是備受矚目的 7.8 分訓練增益來源。

• Qwen3-30B-A3B — 44.37。

按評測框架拆解後，勝幅就變得更薄。對上 Claude Opus 5，差距分別是 Mem0 上的 54.02 對 53.43、Hy-Memory 上的 60.55 對 60.53、MemOS 上的 50.51 對 50.50，以及 EverMemOS 上的 56.89 對 54.04。這四項中有三項是披著桂冠的統計雜訊——在 Hy-Memory 評測框架上領先零點零二個百分點，根本算不上領先。一個 3B 活躍參數的專用模型與前沿模型之間的全部差距，都落在唯一被排除於訓練之外的評測框架上；在那裡差距是 2.85 分，而該主張也最不可能曾針對它進行調校。

有兩個設計細節和數字本身同樣重要。主矩陣中的每一個數字都跑在固定的 20% 子樣本上，而非完整的基準測試；而且評估只改變寫作者，將測試框架、提示、檢索配置、答案模型與評審都固定不變。第二個選擇是良好的實驗衛生——它隔離了受測變數——但那是 T​encent 的測試框架和 T​encent 的評審。把這張表當成一個附帶儲存庫的假設：這比大多數發布日的宣稱所附帶的來得多，卻比一個結果來得少。

框架數字才是更大的主張

模型比較是騰訊放進貼文裡的那段引述。框架比較則是那種一旦成立、就會改變讀者架構的比較。

在該公司自家網站上，Hy Memory 2.0 於四項基準測試中，在開源記憶框架裡排名第一——領先 Mem0、MemOS、EverOS、OpenViking、RepoMemory，以及一個單純的滑動視窗 RAG 基線——並橫跨其涵蓋的三個場景：

• 聊天 — 在 LoCoMo 上達到 72.6%，涵蓋 1,527 個非對抗性問題。

• Working — 在 MemoryArena（一套旅遊規劃與套裝購物套件）上平均達到 55.31%，領先下一個框架 10.2 個百分點。

• 程式設計 — 在 CodeMemoryBench 問答上達 64.2%，解決率為 35.6%，另外在 SWE-ContextBench 上的解決率為 28.3%。

• 記憶體佔用量 — 記憶體儲存為輸入 token 的 6.06%，而與其比較的框架則為 31.9% 至 41.2%。

佔用量那個數字才是真正值得偷學的。記憶系統在正式環境中會失敗有兩個原因：它們忘掉了不該忘的東西，而且會無止境地增長。一個只花費其所摘要對話百分之六的記憶庫，與一個花費百分之四十的，在營運上是截然不同的命題，而這正是關注路由與成本的讀者應該在意的面向，無論準確度的排序是否能禁得起檢驗。評估協定也一併公布：記憶模型為 DeepSeek V4.1 Flash，回答與評判模型為 GPT-5.6-sol，儲存量以記憶庫符元數除以輸入符元數來衡量，且記憶庫僅計入生成的記憶。

Tencent 也列出內部部署——一項股票助理召回測試，在多跳任務上提升了 40 分；一個知識庫外掛；以及一項新聞應用程式偏好評估，平均 91.68 分（滿分 100）——橫跨金融、新聞、知識管理、辦公代理、社群與遊戲。那些是該公司自家的產品指標，而非基準測試；應將它們解讀為該系統確實在某處真實運作的證據，而不是它能勝過任何東西的證據。

MemHub 是多數讀者真正用得到的那個部分

模型需要 GPU。框架需要一支工程團隊。MemHub 需要一台筆電。

它是一款本地優先的桌面與命令列產品，可將您已授權的 AI 工具歷史整合至單一受管理的執行環境與單一資料目錄——因此您在其中一個編碼代理中設定的偏好，可供下一個使用。T​encent 列出十項支援的整合：WorkBuddy、Cursor、Codex、C​laude Code、OpenCode、OpenClaw、Q​wen Code、Pi、Hermes 及 D​eepSeek Harness。所述資料路徑為 ~/.one-memory，以 SQLite 儲存工作與編碼中繼資料，並以 ChromaDB 加上 Kuzu 作為預設儲存庫；安全性文件明確指出，本產品不會收集螢幕內容、無障礙樹、OCR、剪貼簿或背景音訊。

值得懷疑的說法是關於刪除的那些說法。CLI 區分了三個層級：解除安裝 npm 套件只會移除 CLI，memhub uninstall 會移除服務、受管理的執行環境與 CLI 連結，但會保留你的記憶，而只有另一個獨立的 memhub delete-data 指令會刪除儲存區——在停止執行環境並確認確切路徑之後。這比這個類別中大多數工具的設計更好，而且它也是在一個安裝程式尚未發布的版本中對預期行為的描述。任何將它用於重要工作的人，都應該先自行驗證刪除路徑，再放心讓它處理任何他們不想被保留的內容。

尚未確認之事，直白地說。

• 沒有任何形式的獨立基準測試。沒有第三方測試框架的執行、沒有競技場排名，也沒有任何在 Tencent 之外重現的結果。

• 未重現跨測試框架的表格，尤其是留出的 EverMemOS 結果——該結果僅憑單一供應商的單次執行，便承載了整個遷移論證。

• 未經量化，因此沒有低於 60 GB 的實測記憶體佔用量，也沒有工作站規模的評估途徑。

• 沒有託管端點，且模型卡上未註明推論供應商。

• MemHub 尚未發布 npm 套件，因此文件所述的安裝方式目前仍無法端到端運作。

• 沒有每次對話的成本數字。記憶寫入是高頻、短輸出的工作負載；沒有人公布過每次寫入的 token 數，或具備記憶功能的助理實際上每位使用者每月要花多少成本來運行。

路由器適用與不適用的時機

這件事要說得精確，因為很容易誇大。Hy-Memory-30B-A3B 並不在 OrcaRouter 的目錄中，我們也沒有託管它。通往該寫作者的途徑，就是 Hugging Face 上的檢查點和你自己的硬體。路由層的任何設計都不會改變這一點。

路由器所涵蓋的，是這套測試框架的另一半。記憶系統由寫入路徑與讀取路徑組成，而 Tencent 公開的評估直白說明了讀取路徑通常是什麼模樣：由寫入端決定要儲存什麼，再由另一個前沿模型把記憶庫讀回來並作答。在 Tencent 自家的配置中，記憶模型是 DeepSeek V4.1 Flash，作答與評判則是 GPT-5.6-sol。OrcaRouter 用一組金鑰、以定價提供這兩者，不加收任何費用，因此供應商調價當天我們這邊就會同步生效，而不是等到下一次合約續約才反映。

路由 DSL 正是專門契合這套架構的那一塊。它把一個自架端點和一個託管端點組成單一呼叫，而這正是記憶系統的形狀——寫入路徑上是你自己執行、便宜專精的專門模型，讀取路徑上則是你租用的前沿模型。同樣的配置讓風險最高的部分得以承受：把寫入端指向你自己部署的 Hy-Memory-30B-A3B，讓一般模型置於自動容錯移轉之後，這麼一來，寫入路徑出錯只會讓答案品質變差，而不會拖垮整個應用程式。這個模式值得在你讓寫入端跑起來之前就先建好，因為無論寫入路徑是專門的檢查點，還是帶有記憶提示的一般模型，它都一模一樣。

誰應該行動，誰應該等待

如果你要運行具備長期記憶的代理，而且手上已經有 GPU，那麼寫入路徑就是值得你老老實實花上一週的地方：檢查點採用 Apache 2.0，而記憶寫入器則是罕見的模型，它的價值可以靠你自己的流量衡量，而不是看別人的基準測試表。如果你是使用者而非營運者，MemHub 才是值得注意的那個，而且也是該先等等的一個，等到安裝程式問世、且 T​encent 以外有人實際走過刪除路徑之後再說。而如果你是衝著發表公告的氣勢在挑選模型，正確的姿態正是這份發布本身所邀請的那種：55.49 對 54.62，在三套評測框架上是平手，在第四套上則是實質差距，而第四套正是沒有人查過的那一套。