模型廠商自己做的記憶，與第三方記憶框架解的是同一個問題但在不同的位置：框架在 agent 層加記憶，廠商在模型與產品層加記憶。這帶來兩個對架構設計有直接影響的後果——第一，有些記憶能力你不需要自己做了；第二，廠商的記憶行為是你控制不到的變數，必須納入設計。
這一篇處理 Anthropic 的 context engineering 框架與 memory tool，以及 ChatGPT 的兩層記憶與 Dreaming 機制。兩者的設計哲學差異很大，而差異的位置正好標示出這個問題的核心張力。
Anthropic：把問題定義為 context engineering
Anthropic 的官方框架不叫「記憶」，叫 context engineering，並給出一個明確的目標函式：尋找「能最大化目標結果機率的、最小的高訊號 token 集合」。
這個定義值得逐字讀。它把記憶從「存了多少」重新框定為「這一次推理該放什麼進去」——是一個每輪都要重新解的最佳化問題，而不是一個資料庫問題。它同時解釋了為什麼「context window 變大就不需要記憶」是錯的：官方文件明確指出 context rot（上下文衰退）在所有模型上都存在，效能隨 token 量增加而下降。放得進去不代表放進去有好處。
框架給出四個技術：
Compaction（壓縮）——接近 context 上限時把對話歷史摘要，然後用壓縮後的內容重新初始化。官方對調校順序有明確建議：先把召回率（recall）拉滿，確保壓縮 prompt 抓到所有相關資訊，再迭代改善精確率。這個順序不能顛倒——壓縮階段丟掉的資訊無法在後續恢復。tool result clearing 是同一技術最輕量的應用。
Structured note-taking（結構化筆記，也就是 agentic memory）——agent 在外部維護持久化筆記並在需要時取回。官方舉的例子是 Claude 玩 Pokémon 時跨數千步維持戰術筆記，而且沒有被指示要怎麼組織記憶結構——這是一個值得注意的觀察：在給定工具與需求後，模型會自己發展出記憶組織方式。
Sub-agent architectures（子代理架構）——專門的子 agent 用乾淨的 context 處理特定任務，回傳約 1,000–2,000 token 的濃縮摘要給主 agent。這是一種空間上的 context 隔離，與壓縮的時間上壓縮互補。
Just-in-time retrieval（即時取回）——不預先載入資料，而是持有輕量識別符（檔案路徑、URL）並在執行中用工具動態載入，官方稱之為 progressive disclosure（漸進揭露）。
官方同時給了一個誠實的限制：執行時探索是用速度換自主性，而且「結合預先取回與自主探索的混合策略往往最有效」。這句話值得記住，因為它反駁了「just-in-time 一律優於預載」的簡化結論。
Memory tool 則是把上述第二項做成 API 原語：模型透過工具呼叫在一個記憶檔案目錄中讀寫，跨對話持久化。它與 compaction、tool-result clearing 一起構成三個 context 管理原語。這條路線的設計選擇很清楚——記憶是檔案，模型用工具操作它，與 OpenClaw 與 Hermes 的檔案原生路線同源。
OpenAI：兩層記憶與背景綜合
ChatGPT 的記憶是兩層，而且這兩層的設計哲學不同：
Saved memories（已儲存的記憶）——明確的、條目化的持久事實：名字、職業、語氣偏好。它們會在對話中自動更新，也可以由使用者說「記住這件事」觸發。關鍵性質是可逐條檢視、新增與刪除——這是產品與法規上的必要條件。
Reference chat history（參考對話歷史）——不是固定的事實清單，而是模型從過去對話的整體內容中推斷出的興趣與偏好。這些推斷會隨時間漂移，因為系統持續更新它認為值得保留的東西。
到 2026 年中，底層由一個名為 Dreaming 的背景程序產生（Dreaming V3 於 2026-06-04 開始推出）：它非同步地跨大量歷史對話閱讀，維護一份綜合後的記憶狀態，並在每個新對話開始時注入模型 context。
這個設計的意義在於它把 sleep-time compute 做到了消費級產品規模。 Letta 用它處理單一 agent 的記憶整理，OpenAI 用它處理數億使用者的畫像綜合——機制相同，只是規模與投入不同。這是「背景記憶整理」這個模式最有力的存在性證明。
同時它也示範了兩層設計的必要性：條目式記憶負責可控與可刪除，推斷式記憶負責覆蓋率。只有前者則覆蓋不足（使用者不會主動告訴你所有偏好），只有後者則無法被檢視與刪除。這與 LangMem 的「條目式 vs 畫像式」取捨是同一個結論。
對架構設計的三個實際影響
一、有些事不要自己做。 如果你的產品建立在某個模型 API 上，而那個 API 已經提供 memory tool 與 compaction 原語，自己再實作一層對話壓縮通常是重複工。該自己做的是領域特定的記憶（這個使用者在你的產品裡的狀態、這個專案的規則），而不是通用的 context 管理。
二、廠商的記憶是你控制不到的變數。 消費級產品的記憶（saved memories、reference chat history）會影響模型行為，而你的系統看不到也改不了它。在需要可重現性的場景（測試、稽核、批次處理）必須確認這些機制是關閉的，否則同樣的輸入會得到不同的輸出，而原因在你的系統之外。
三、「最小的高訊號 token 集合」應該直接當成驗收標準。 它把記憶品質變成一個可量測的目標：同樣的任務成功率下，誰用的 token 少。這比「召回了幾條相關記憶」有意義得多——見 評測。
可抽取的模式
Smallest high-signal token set（最小高訊號 token 集合）——把記憶的目標函式明確寫成「在達成結果的前提下最小化 token」。這是本專欄採用的記憶品質定義。
Recall-then-precision tuning for compression（壓縮先調召回、再調精確）——任何有損壓縮步驟的調校順序：先確保不漏，再減少冗餘。因為漏掉的無法補回，冗餘的可以再修。
Progressive disclosure via lightweight handles（用輕量識別符做漸進揭露）——context 裡放的是路徑、ID、查詢字串，實際內容用工具按需取回。它把 context 成本從「資料量」解耦成「識別符數量」，是處理大型記憶庫最有效的結構。
Spatial context isolation via sub-agents（用子代理做空間隔離）——用獨立 context 的子 agent 處理會產生大量中間 token 的任務，只回傳濃縮結果。與壓縮互補：壓縮處理已經發生的膨脹，隔離避免膨脹發生。
Two-tier user memory（雙層使用者記憶）——條目式（可檢視、可刪除、精確）＋ 推斷式（覆蓋率高、會漂移）並存，兩者用不同的儲存與治理規則。