記憶啊，你去哪兒了？

當我問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)

不想錯過另一篇部落格文章？

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

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