AI Agent 真正難的地方,不是只會不會呼叫工具,而是能不能在長時間、多任務、多 agent 的環境裡越做越好。MCP 解決的是工具與資料接入,Skills 解決的是可重複使用的能力封裝,但如果 agent 每次醒來都像第一次接觸專案,它就很難成為真正可靠的工作夥伴。
這也是 memory 和 dreaming 這兩個概念重要的原因。Memory 是 agent 的可讀寫經驗庫;Dreaming 則像一個離線整理程序,會在任務之外回看多個 session 的 transcript,找出共同錯誤、成功策略、重複資訊與過期記憶,再把它們整理成更可靠的記憶狀態。
內容目錄
為什麼 Agent 需要 Memory?
現在的 agent 已經可以跑很久,有些任務會持續數小時甚至接近數天。問題是,時間拉長後,上下文管理就會變成瓶頸。Agent 需要知道任務成功條件、常見錯誤、哪些策略行不通、專案檔案怎麼組織、以前有哪些調查結果,也要能從其他 agent 的經驗中學到東西。
這一點和我之前整理 Claude Code Workflow 時看到的問題很像:當你同時開多個 agent 或多個工作階段,真正會拖慢效率的,往往不是模型不夠聰明,而是每個 agent 都在重複摸索同一批上下文。
Memory 的設計:把記憶當成檔案系統
這套 memory 設計最有意思的地方,是它沒有把記憶包成一個過度抽象的黑盒工具,而是把 memory model 成一組檔案。Agent 可以像管理專案檔一樣,用熟悉的 bash、grep、檔案讀寫去整理記憶。這和 Claude Code 擅長操作檔案系統的能力剛好接上。
從實務角度看,這比單純塞一段「長期記憶摘要」更適合大型專案。記憶可以拆成不同檔案、不同層級、不同權限:有些是組織層級的 runbook 和最佳實務,應該只讀;有些是某個團隊或某個任務的 working memory,需要 agent 持續更新。
多 Agent 系統裡,記憶不能只有「我記得」
單一 agent 記得自己的工作經驗已經有幫助,但真正的難題在多 agent。當企業裡同時有數百甚至上千個 agent 在跑,它們會接觸同一套程式碼、同一批告警、同一組 runbook。如果每個 agent 都各自學一次,成本會很高,錯誤也會一直重複。
這裡需要兩種能力。第一是權限範圍:有些 memory store 只允許讀取,有些允許讀寫。第二是並行控制:多個 agent 同時更新同一份記憶時,不能互相覆蓋。用 content hash 做 optimistic concurrency,可以讓 agent 在寫入前確認自己沒有覆蓋別人的更新。
如果把這件事放進更大的 AI 工作流來看,它其實和 用 AI 組一家公司 的概念很接近:當 AI 不再只是單一助手,而是多個角色一起工作,組織記憶就會變成基礎設施。
Dreaming 是什麼?
Dreaming 可以理解成「離線記憶整理」。它不是 agent 正在執行任務時的熱路徑,而是一個非同步 batch process。它會回看最近的 agent sessions、transcripts 和工作結果,找出共同模式、重複錯誤、有效策略,再產生一組更新後的 memory diff。
這個設計很重要,因為單一 agent 在任務中只看得到自己的局部視角。Dreaming 則可以站在更高一層,同時看多個 agent 的工作紀錄。它能發現某個錯誤是不是很多 agent 都遇到過,某個 retry pattern 是不是固定在 60 秒後發生,或某份記憶是不是已經過期。
Memory 與 Dreaming 的差別
| 項目 | Memory | Dreaming |
|---|---|---|
| 運作時間 | 任務進行中即時讀寫 | 任務外的非同步整理 |
| 主要目標 | 讓 agent 記得當前與過去經驗 | 驗證、去重、回填與組織記憶 |
| 視角 | 單一 agent 或單一 session 為主 | 跨多個 sessions 與多個 agents |
| 適合解決 | 避免重複調查、保留工作脈絡 | 找共同錯誤、萃取模式、清理 stale memory |
| 對效能影響 | 在任務路徑上,要注意 token 與延遲 | 離線執行,不增加 hot path latency |
早期案例透露了什麼?
早期案例有兩個數字值得注意。Rakuten 在內部 knowledge agents 裡導入 memory 後,first-pass mistakes 降低 90%。Harvey 在法律場景 benchmark 中導入 dreaming 後,其中一個 scenario 的 task completion rate 提升 6 倍。
這些數字不能直接解讀成所有 agent 系統都會有同樣改善,但方向很明確:memory 先降低重複犯錯,dreaming 再把多個 agent 的經驗整理成更乾淨、更可用的知識庫。對企業來說,這會同時影響正確率、token 效率、延遲和維護成本。
SRE Agent 的例子最容易理解
假設一個 SRE agent 收到 P1 alert,它開始查 CPU utilization、流量模式、最近部署的 PR,最後把調查結果寫進 SRE memory store。幾分鐘後同樣 alert 又出現,另一個 SRE agent 啟動時,第一件事不是從零開始查,而是先讀到前一個 agent 留下的調查結果,直接避開重複工作。
這就是 memory 的即時價值:省 token、省時間、也讓後續 agent 站在前一個 agent 的肩膀上。再往下一層,dreaming 會回看過去 7 天相關 sessions,找出多個 agent 都沒有單獨注意到的模式。例如很多 alert 都剛好在上游 CPU spike 後 60 秒發生,那可能代表 retry logic 或排程邏輯有問題。
這種模式非常適合 自我進化 AI Agent 架構。但重點不是讓 agent 無限制亂寫記憶,而是要有版本歷史、attribution metadata、審核流程和可回滾能力。
實作時最該注意的三件事
第一,記憶要可審計。誰寫了什麼、什麼時候寫、基於哪個 session 寫,這些資訊必須留下來。否則 memory 一旦被污染,後續 agent 會把錯誤經驗當成事實。
第二,記憶要分層。組織層級 best practices、團隊 runbook、專案知識、個別任務 working memory,不應該全部混在同一個檔案。這和寫 AI 開發紀律 很像:越是長期會被重複使用的規則,越要整理成穩定結構。
第三,dreaming 不應該完全無人監督。它產生 memory diff 後,可以直接套用,也可以先走檢查、PII scanning、人工 review 或外部 pipeline。對企業 production agent 來說,這種控制權比單純「模型會自動學習」更重要。
我的判斷:Memory 會成為 Agent 系統的資料庫層
如果把 MCP 看成工具層,把 Skills 看成能力層,那 memory 很可能會變成 agent 系統的資料庫層。它不只是「記住使用者喜好」這麼簡單,而是把 agent 的工作歷史、錯誤模式、成功策略與環境知識變成可管理、可審計、可演進的資產。
Dreaming 則讓這個資料庫不只是被動儲存,而是能定期整理索引、刪除過期內容、回填驗證結果、把多個 agent 的經驗濃縮成明天可以直接使用的知識。未來真正強的 agent 系統,可能不是單一模型最聰明,而是整個系統能不能把每天做過的事變成明天的能力。
FAQ
AI Agent memory 是什麼?
AI Agent memory 是讓 agent 保留工作經驗、任務策略、環境知識與常見錯誤的記憶系統。它可以幫 agent 在長任務或多 session 工作中避免每次都從零開始。
Dreaming 和一般 memory 有什麼不同?
Memory 偏向任務進行中的即時讀寫;Dreaming 則是離線整理流程,會回看多個 agent sessions,找出共同模式、去重、驗證記憶並回填更好的內容。
Memory 會不會讓 agent 學到錯誤資訊?
會有這個風險,所以 production memory 需要版本歷史、attribution metadata、權限控管、PII scanning、人工 review 或自動檢查流程。記憶不是越多越好,而是要可靠、可追溯、可清理。
什麼情境最適合導入 agent memory?
最適合長任務、多 agent、重複問題多、環境複雜的場景,例如 SRE triage、程式碼維護、企業知識問答、法務研究、客服流程與內部自動化。
近期留言