記憶啊，你去哪兒了？

當我問Claude為什麼沒有使用我提供給它的記憶工具時，它的回答比預想中更坦誠。

“我默認使用MEMORY.md，因為它始終被加載：零延遲、零工具調用、保證在上下文中。當主要記憶存儲已經存在時，沒有理由去調用外部工具。”

這是Engram收到的第一份真實產品評價。

Claude和我已是老朋友。作為一名產品經理，Claude Code已融入我的日常工作——研究分析、設計原型、項目與需求規劃。但使用時間越長，我越能感受到會話“冷啓動”帶來的隱形摩擦：每次都需要重新陳述上週的決策或問題框架。這正是我們在《循環中的極限》一文中指出的需要一流基礎設施的記憶問題，也是我們基於Weaviate核心向量搜索技術構建Engram（目前處於私有預覽階段）的原因。

打造產品是一回事，證明其價值是另一回事。於是我決定測試Engram能否彌補我日常工作中的一些短板，並贏得我的青睞。

早期結果令人鼓舞：使用Engram加載記憶的會話，不再像從零開始向同事介紹情況，更像與親歷者繼續對話。但達到這一效果並非一帆風順。

我構建了一個封裝Engram SDK的MCP服務器，暴露檢索和保存工具，並指示Claude在需要時使用。我曾粗略聽説某個記憶插件因保存每一條消息而消耗過多CPU，便自作聰明地讓Claude自主決定何時使用Engram。

結果Claude完全忽略了Engram。

“隨機應變”的問題

Claude Code已有內置記憶系統：一個名為MEMORY.md的文件，自動加載到每個會話中。它包含約200行手動精選的上下文，始終存在且零開銷——足以記錄穩定事實，但無法容納所有推導過程。Engram需要顯式工具調用，若無明確使用標準，Claude默認保持當前狀態而不調用工具。

Claude沒有理由使用Engram。我的集成需要給它一個理由。

尋找節奏

我需要回答一個更基本的問題：既然MEMORY.md已經存在，Engram到底用來做什麼？

MEMORY.md存儲結論——那些足夠穩定、可永久保留的事實。但它無法記錄所有推導過程：決策背後的推理、被否決的備選方案、框架轉變的會話、文檔寫作意圖的筆記……這些內容無法容納在200行內，也不應永久保留。

這些正是我們需要Engram的原因。

Engram與MEMORY.md的配合方式

Engram圍繞主題組織記憶：語義類別讓檢索能精確過濾相關項，而非搜索雜亂堆砌。我梳理了典型工作，確定了四個有實際意義的類別：

• 溝通風格：輸出格式偏好、語氣、詳細程度、厭惡點
• 領域背景：持續的角色、公司和產品知識
• 工具偏好：語言、框架、工具、技術棧選擇
• 工作流：與Claude合作的方式

明確了“存儲什麼”後，自然出現了“何時存儲”的問題。我設計了以下交互模式：

• 會話開始時，用寬泛的項目查詢召回，讓Claude在第一個問題前獲得跨會話上下文，而非冷啓動；
• 會話中，在關鍵節點觸發保存：做出決策、方向改變、產出交付物；
• 每隔幾個提示，輕量保存以防/clear中途清空會話；
• 會話結束時，保存完整摘要。

由於每次召回都會消耗往返時間和上下文窗口空間，我讓中間召回僅在特定觸發條件下啓動：跨項目引用、決策考古、中斷後恢復工作。

會話生命週期：Engram何時保存和召回

一個實際限制塑造了方案：大型保存會超時，因此我們傾向於2-4句的短話題保存。結果證明這對檢索也更有利——聚焦的記憶比需要解析的段落更容易找到。

有興趣在自己的編程助手工作流中試用Engram嗎？註冊Engram預覽版。

現場記錄

經過兩週在日常Claude Code會話中運行Engram——涵蓋產品策略、規格編寫、活動策劃和設計——我進行了一次結構化評估：比較兩個Claude會話執行相同任務，使用相同的MEMORY.md、CLAUDE.md和任務提示。唯一區別是是否接入Engram。由獨立Claude實例評判記錄，評估結果幾乎一分為二：“這正是Engram的用途”和“這仍是需要解決的問題”。

評估場景 | 無Engram | 有Engram --- | --- | --- 決策考古 | 從文件中重建：正確的框架和結論 | 召回推理鏈和文檔意圖；首次交流快30% 不完整上下文（早期單會話測試） | 兩次用看似合理的URL填補空白 | 有根據的召回防止了虛構 活動策劃 | 基於提示制定強計劃 | 同樣忽略Engram，同樣強計劃

有效之處

最明顯的勝利在決策考古：接手一份持續數週的產品願景文檔，讓Claude回顧我們上次的進展。無Engram時，感覺像閲讀詳盡的會議記錄：準確、有條理，但只是重建。有Engram時，就像與親歷者繼續對話——它重現了關鍵定位決策背後的推理弧線、項目中期重新定位Engram本身的故事，以及文檔正文中未包含的意圖筆記。而且首次交流快了30%，因為需要重建的上下文更少。

區別不在事實本身，而在框架質量——這正是推理鏈召回本應彌補的差距。

早期單會話評估中一個一致發現：當Claude沒有足夠基於實際的上下文時，它會用聽似合理的細節填補空白。無Engram的Claude在兩次獨立運行中虛構了同一個URL，而有Engram的Claude每次都能召回足夠上下文避免虛構。

不足之處

一個引人注目的結果來自一次規劃會議，我們希望接手之前的活動工作。Engram中存有相關記憶：設計決策、先前活動軌跡、PLG上下文，CLAUDE.md明確指示在會話開始時從Engram檢索。

但接入Engram的Claude沒有檢索。兩個會話都沒有搜索額外上下文，都將任務視為前瞻性工作，完全依據提示執行。文件和Engram中的先前上下文未被使用。

這證實了我們的懷疑：在規劃任務中，Claude將“幫我思考”視為向前推進的邀請，而非核查已有內容。CLAUDE.md中的顯式指令不足以覆蓋這一偏好。失敗是無聲的——沒有錯誤，沒有跡象表明相關上下文被跳過。

會話開銷

寫入Engram給會話增加了明顯開銷。一次早期測試記錄了一次運行19秒的啓動成本，使用Engram的會話總體慢約10%。這不是固有方法問題，但卻是日常使用中的真實摩擦點：如果保存記憶會明顯暫停會話，用户會注意到。

有興趣在自己的編程助手工作流中試用Engram嗎？註冊Engram預覽版。

回到工作室

與工程團隊分享這些發現後，幾件事變得清晰。

保存性能

會話時長問題原來是集成使用不當，而非根本限制。集成在等待記憶處理完成時阻塞，但Engram是最終一致性，無需等待。保存應該即發即忘，頻繁保存不應累積資源開銷。

記憶捕獲

“每五個提示保存一次”的模式將被更穩健的方案取代：每條消息自動流入管道緩衝區，無需工具調用，會話提前結束時不會丟失上下文。

檢索掛鈎

更重要的改變是放棄“Claude決定何時檢索記憶”的模型，轉而創建確定性的基礎設施級觸發器，在會話生命週期的特定點觸發，無論Claude如何決策。會話啓動鈎子可在Claude看到第一條消息前注入相關記憶。每次用户提示前的鈎子可按輪次進行，並配以相關性過濾，僅注入與當前上下文強匹配的記憶。Claude無需決定召回；上下文已經就緒。

值得注意的是，Anthropic也在朝同一方向努力。一項悄然推出的Claude Code功能/dream，運行後台代理，通過反思性掃描記憶文件，將學習內容綜合為有條理的條目並執行行數限制，從而整合會話記憶。截至本文寫作時，該功能尚未文檔化且處於功能標誌後，但方向明確。/dream操作的也是Claude內置的文件型記憶。它有效處理MEMORY.md層——穩定事實、整合、保持整潔。但無法捕獲推理鏈、被否決的備選方案或決策跨會話演化過程。

協作範圍

對個人有效的記憶在團隊環境中會迅速複雜化。個人對輸出風格的偏好不應顯示給同事，但共享產品決策很可能需要。目前集成未明確區分：哪些主題屬於個人範圍，哪些屬於團隊共享範圍，Claude Code集成需要顯式定義，而非繼承非專為協作設計的默認設置。任何方向的錯誤都會帶來真實後果——過度共享削弱信任，共享不足則失去意義。

冷啓動

當前管道專為增量捕獲設計，即記憶在對話發生時提取。但這留下了空白——我們需要從現有內容開始，而非從零積累。對於我的集成，這意味着從已有會話歷史引導，而非等待數週積累有效記憶庫。對於另一個內部支持代理用例，則是導入大量產品文檔作為知識基礎。管道目前無法乾淨處理這些情況，而這正是我們正在構建的方向。

所以，值得嗎？

我起初期望證明Engram的價值，卻發現了更有用的東西：Engram有效工作的具體條件，以及阻礙它有效工作的具體機制。及早發現並快速迭代，為我們的預覽版在邁向正式發佈時提供了更多優勢。

可以肯定的是，到正式發佈時，將有一個真正的Claude Code集成可用，且比我粗糙的自制版本好得多。屆時你們都可以親自嘗試，並告訴我們其他不足之處。

準備好開始構建了嗎？

查看快速入門教程，或免費試用Weaviate Cloud (WCD) 構建精彩應用。

GitHub | 論壇 | X (Twitter)

不想錯過另一篇博客文章？

訂閲我們的雙週通訊，保持更新！

提交即表示我同意服務條款和隱私政策。