上週我讓一個在 Telegram 裡跑的 Agent 幫我跟進一位老客戶。我以為萬事俱備：對話都留著、模型上下文夠大、甚至在 ChatGPT 裡還開過 Memory。
三週後，它要給客戶發跟進郵件，突然來了一句：
「請問您是哪家公司來著？方便再介紹一下專案背景嗎？」
客戶截圖甩進群裡，場面一度很尷尬。那一刻我才確定：Agent 記得聊天，不等於 Agent 有記憶。 後來我們把同一套邏輯拆給幾位試點客戶看，幾乎人人點頭——大家虧的不是模型不夠聰明，而是把「聊天紀錄」當成了「Agent Memory」。
下面是我和團隊在 OpenClaw 上踩坑、改方案的過程。不講百科定義，只講你會遇到的場景，以及我們最後怎麼區分 AI Memory（系統怎麼存）和聊天視窗裡那堆 history。若你在選型記憶棧，可對照 OpenHuman vs ChatGPT Memory 四層棧；若做 IDE Agent，可延伸 Karpathy 的上下文分層。
場景一：聊天紀錄都在，客戶規則還是丟了
一家做 B2B 服務的團隊跟我們吐槽過幾乎一模一樣的事。
客戶在第三週明確說過：「以後報價只要 PDF，不要 Excel。」 Agent 當場回覆「好的，已記錄」。團隊去後台翻——聊天紀錄一字不少，甚至還能搜到「PDF」關鍵字。
三個月後，同一位客戶收到一封帶 Excel 附件的報價。客戶直接炸毛：你們到底有沒有在跟？
問題不在模型「笨」，而在：那句話從未進入可被檢索、可被強制執行的 Memory。 它躺在幾萬字對話中間，和寒暄、貼圖、一次錯誤的副本名單混在一起。新會話啟動時，Agent 沒有義務、也沒有穩定機制把「客戶 A = 僅 PDF」拎到 prompt 最前面。
聊天紀錄是留痕，適合稽核回放；Agent Memory 是下次決策時要用的狀態。前者像會議錄音，後者像 CRM 裡那條「勿發 Excel」——你絕不會指望業務每次簽單前重聽三小時錄音。
場景二：百萬 Token 的上下文，救不了 Claude Code 重複勞動
我自己在 Claude Code 裡吃過另一種虧。
某次讓它分析一個單倉 monorepo，產出架構說明，前後折騰了兩天，產出還不錯。我以為「反正視窗夠大，下次接著聊就行」。
兩週後換新會話，我只說了一句：「繼續上次那個倉庫的文件工作。」
它又重新梳理思路、重新掃目錄、重新寫一版結構相近的文件。聊天歷史？部分在，但任務狀態不在：上次分析到哪個子模組、哪些結論已寫入 docs/、哪些待人工確認——這些躺在工具輸出和檔案系統裡，不在「你和模型的閒聊紀錄」裡。
那時我才認同 Karpathy 那套說法裡很刺耳的一句：別把無限上下文當硬碟。 真正該進 AI Memory 的，是「上次做到哪」這種可更新的一行狀態，而不是兩萬行 tool stdout。
框架文件也在往這走——例如 LangGraph 把執行緒狀態和持久化 store 分開。我們落地時沒有照抄框架，但認同同一件事：訊息列表 ≠ 記憶庫。
Agent 其實只需要記住三種東西
跟客戶、跟同事解釋時，我盡量不用一排英文名詞。通常只說三句，對方就能對齊預期：
- 用戶是誰、有什麼硬規矩——客戶 A 只收 PDF；老闆討厭長語音；我們團隊用 UTC 排程。
- 上次做到哪——Issue #482 卡在等法務；昨晚告警已 ack 未 root cause；文件寫到第三章。
- 以後怎麼做——發布 checklist、審批鏈、on-call 先打誰。
聊天紀錄對這三類的覆蓋極不均匀：偶爾蹭到第 1 條，幾乎幫不上第 2、3 條。
寫方案、跟研發對齊時，我們才會補一句產業叫法：上面三條大致對應 Semantic（穩定事實）、Episodic（發生過什麼）、Procedural（標準流程）。名詞可以後學，缺哪一類，Agent 就會在哪個場景出醜——這比背定義有用得多。
我們踩過的一個坑：把聊天紀錄全灌進向量庫
去年測 OpenClaw 早期方案時，團隊圖省事：所有會話原文 embedding 進向量庫，以為「先存進去，檢索總會命中」。
一個月後，品質反而變差。Agent 會把半年前已廢棄的發布流程當成現行 SOP；有時從閒聊裡檢索到「上次好像說過不用 PDF」和「客戶又要 Excel 範本」兩條矛盾片段，然後自信地選錯一條。
我們當時的判斷是錯的：Memory 最難的不是存不進去，而是刪不掉、改不動、分不清。
後來給每條寫入的 Agent Memory 強制帶：來源、建立時間、過期時間或版本號。檢索時先按客戶 / 專案過濾，再按時間衰減排序。同樣規模的庫，胡編亂造的機率明顯下降。這事沒有銀彈，但這是我們在試點裡唯一願意寫進交付清單的經驗。
若你也在用 Cursor / Claude Code 接 MCP，工具回傳往往比聊天更長——更要把「結論」寫進 Memory，而不是把 stdout 塞進索引。MCP 本身只是管道，見 Model Context Protocol 官網。
ChatGPT Memory 夠不夠？看你怎麼用 Agent
我不會說 ChatGPT Memory 沒用。重度在 ChatGPT 裡寫文案、改郵件的人，開 官方 Memory 很省事——它擅長記住「你喜歡 bullet」「你在灣區」這類聊天偏好。
但一旦 Agent 跑到 Slack、Telegram、Cron、IDE，Memory 就卡在 OpenAI 那個 App 裡。你在 Chat 裡訂的規則，不會自動變成 OpenClaw 閘道上的硬約束。
我們現在的分工（細節見 AI Memory Stack 選型文）：ChatGPT Memory 管語氣；本機 vault / OpenHuman 管工作事實；OpenClaw + MCP 讀 Memory、執行任務。只聊天，Memory 夠；要 Agent 幹活，必須單獨做 AI Memory 層。
當 Agent 開始長期工作：記憶只是第一步
不少團隊把 Memory 修好後，第二個打擊來得很快：Agent 活不過一晚上。 筆電合蓋、Wi-Fi 抖一下、本機 MCP 被系統殺掉——早上 Cron 該發的提醒沒發。你會得到：記憶庫裡有紀錄，但 Agent 像從沒存在過。
所以我們把問題拆成三層：記憶層（記什麼、誰可讀、何時過期）、執行層（OpenClaw Gateway 在 VPS 上 7×24）、工具層（重 MCP、xcodebuild 別和 Memory 同步搶同一台合蓋筆電）。
我們的習慣：Memory 在主力 Mac 或 NAS；閘道在 Linux VPS；編譯和重工具丟雲 Mac——因為避免一次 Archive 把昨晚剛 sync 完的 vault 卡死，這種事我們真遇到過。閘道部署可參考 Linux VPS 上的 OpenClaw Gateway。
你可能還想問
聊天紀錄保存了，為什麼還會忘？
因為保存的是原文，不是規則。沒有提煉、檢索入口、沒有過期策略，新會話不會穩定載入那條約束。
只堆 PDF 做 RAG 行不行？
RAG 擅長「文件裡有什麼」。它不會自動回答「上次工單處理到哪」「這條流程是否已廢棄」。我們用 RAG 當 AI Memory 的一層，而不是全部。
個人開發者最小配置？
只在 ChatGPT 裡玩 → 開 Memory 即可。要 Telegram/IDE Agent → 加本機 Memory + OpenClaw。要 Cron 不斷 → 再加 VPS。順序別反。