跟 AI 說「幫我記住這個」的時候，背後發生了什麼事？

跟 AI 說「幫我記住這個」的時候，背後發生了什麼事？

答案讓我滿意外的 — LLM 根本沒有記憶。

每一次送出訊息，對 AI 來說都是全新的世界 — 它不記得我上一句說了什麼 — 我以為的「對話」，其實是把之前的對話紀錄重新塞進去，讓 AI「看起來」好像記得。

所以我說「幫我記住」的時候，背後其實是 memory system 在幫我把這個資訊寫進 external storage。下次對話開始前，再根據我的問題去「撈」相關的記憶，塞回 AI 的 input 裡。

這整套機制，就是現在 AI agent 架構的核心。

一個 agent 背後通常有幾類設定檔

Agent 端：

• identity — 我是誰（角色、persona）
• soul — 我怎麼思考（價值觀、決策原則）
• agent — 我怎麼行動（行為規範、工作流程）
• tools — 我能做什麼（可用工具、API）

User 端：

• user — 使用者是誰（profile、偏好）
• memory — 互動中累積的記憶

這些概念在 CoALA（Princeton, 2023）、Letta（前 MemGPT）、OpenClaw 等框架裡都有對應的實作。

Memory 的分類

Memory 的部分，認知科學的經典分類有三種，但在研究 Meta HyperAgent 中似乎還多出現了一種：

1. Semantic memory — 我知道什麼事實、知識、偏好

「喜歡看電影」、「偏好簡短回覆」。Knowledge base 和 RAG 本質上就是 semantic memory 的實作。

2. Episodic memory — 發生過什麼有時間戳的具體事件

「上週在國賓看了一場電影」、「在 last commit 嘗試 演算法 ABC」。

3. Procedural memory — 怎麼做執行流程、SOP、learned workflows

「從第三個路口直走右轉走到電影院」、「程式碼完成流程：驗證 → Peer Review → 通知」。Agent 的 system prompt 和行為規則本質上就是procedural memory。

4. Strategic memory（operational knowledge）— 學到了什麼

做了實驗後記錄哪些可行、哪些不可行的決策知識。「實作 A 在 Y 條件下會遇到 Z 問題，不可行」。

第四種目前學界還沒有正式分類，Meta 的 HyperAgents（2026）研究裡，agent 在自我改進過程中自發產生了 persistent memory 來儲存 causal hypotheses — 就是 strategic memory 的行為模式，只是論文沒有給它命名。

Context Window

接下來，是我覺得最重要的一個概念 — Context Window。

Context window 不是 AI 的記憶體上限，它是「一次 API call 能傳過去的 token 總量」。傳完就沒了，下次要重新傳（就是真的重傳，一直要送部份跟前一次一樣的東西過去）。

所以每次跟 AI 對話，背後其實是這樣組裝的：

【Context Window Layout】 📌 固定區：identity / soul / agent / tools / user → 可 cache 🔄 動態區：retrieved memories + conversation history → 每次不同 ✉️ 當前：我的訊息 + AI 回覆 → 全新的

越穩定的放越前面，越動態的放越後面 — 這就是為什麼 prompt caching 有效，前面那些不變的部分可以被 cache，省錢又省時。

現在主流 model 的 context window：

• Claude Opus 4.6 / Sonnet 4.6 是 1M tokens
• GPT-5.4 標準 272K（可擴到 1M）
• Gemini 3.1 Pro 是 1M

1M tokens 大概是 75 萬字英文，或一整個中型codebase，但重點來了：塞越多不代表 AI 用得越好。研究顯示 model 對 context 開頭和結尾的資訊處理最好，中間容易漏掉（lost in the middle）。

所以，model 把 context window 撐大是一回事，memory system 決定塞什麼進去是另一回事。

日常跟 AI 互動的底下

我說「幫我記住 XXX」→ 我在觸發 memory 的 write（AI 背後把這個資訊寫進 semantic 或 episodic memory）。

我說「你記得 XXX 嗎」→ 我在手動觸發 retrieval（讓 AI 先去 memory 裡撈相關資訊，再基於這些回答；這比直接問問題效果更好，因為我幫 AI 把正確的 context 拉回 window 裡了）。

經典的問題就來了 — 為什麼聊到後面 AI 回答越來越不對？（生成圖片也是，有時候越生越爛）conversation history 越來越長，擠壓了 context window 裡其他內容的空間，搭拉🌟嘎秋👉。

到了上限就觸發 compaction — AI 自動把前面的對話摘要壓縮（Context Summarization)，過程中丟失了nuance 跟 edge cases。

怎麼「洗白」回來？→ 開新 session，手動把關鍵 context 重新餵進去。等於自己當了一次 memory manager — 從 external storage（大腦或筆記）retrieve 最重要的資訊，inject 到新的 context window。

實務中發現的缺口

最後一個是在實務中發現的缺口：用 Claude Code 開發時，debug 了三種方法，前兩種失敗了，第三種成功。但下次遇到類似問題，agent 不記得之前試過什麼。

這些 findings — 哪些方法有效、哪些不可行、在什麼條件下 — 裝在現有的三種 memory 分類裡似乎都不適合，需要第四種：strategic memory / operational knowledge。

實務上，可以讓 coding agent 在每次測試後把結果寫入 strategic memory：

• approach：試了什麼
• outcome：成功或失敗
• condition：在什麼條件下

下次遇到類似情境，先 retrieve 這些 lessons learned 再動手。

遺忘是正常的 — 但學到的教訓應該被保留 （後續延伸就很多了 — HyperAgent、AutoResearch 的基礎）。

Memory 系統的本質就一句話：

「在有限的桌子上，決定每次放什麼上去」

OpenAI、Google、Anthropic 會幫我們把桌子撐大，但是放對東西到桌上，就要靠我們自己了。

不然有三公尺的書桌，東西還是一直掉啊😂😂😂