讓 agent 自我學習的 Memory 與 Dreaming（第 1/2 段）

🧑‍🏫 這支影片是 Anthropic 介紹 Claude managed agents 新推出的 memory（記憶）功能。影片講了三件事：agent 為什麼需要記憶、為什麼選用「檔案」來存記憶，以及多個 agent 共用記憶時要怎麼管理。如果你想知道 AI agent 要怎樣才會越用越聰明，這一段講得很清楚。

• 00:15 講者 Ravi 在 Anthropic 的 platform 部門帶 API knowledge team，負責打造讓 agent 能使用各種知識的基礎元件，例如 context window、skills、files、網路內容
  ↳ 講者 Ravi 在 Anthropic 帶一個團隊，負責做讓 agent（能自己分步驟完成任務的 AI）取用知識的底層零件，例如 context window（模型一次能看到的內容範圍）、skills、檔案和網路資料。
• 00:45 最近推出兩個新功能：memory 與 dreaming。有了這些基礎元件，agent 可以隨時間學習，一次任務比一次做得更好
  ↳ 這次推出 memory 和 dreaming 兩個功能，目的是讓 agent 不用每次從零開始，而是能累積經驗、越做越好。dreaming 在這一段還沒細講，下一段才會說明。
• 01:15 背景：模型持續進步，agent 已經能完成耗時好幾個小時、越來越複雜的任務
  ↳ 背景是模型越來越強。agent 已經不只是一問一答，而是能自己連續工作好幾個小時，處理步驟很多的複雜工作。
• 01:15 2024 年推出 Model Context Protocol（MCP），讓模型有系統地存取外部工具與資料
  ↳ MCP（Model Context Protocol）是一套共通規格，讓模型用統一的方式接上外部工具和資料，例如資料庫或各種服務，不用每接一種就重寫一套接法。
• 01:15 2025 年推出 Claude Code 與 Agent SDK，降低使用和打造 agent 的門檻
  ↳ Claude Code 是讓 Claude 在電腦上寫程式、操作檔案的工具。Agent SDK 是給開發者的工具包，可以用現成零件組出自己的 agent。兩者都讓 agent 更容易上手。
• 01:45 2025 年稍晚推出 skills：一種通用的抽象層，讓模型可以「外掛」新能力，用來完成特定任務
  ↳ skills 像是可以替模型加裝的能力包：把某類任務的做法和資料先打包好，模型需要時再拿出來用，不必每次重新教一遍。
• 01:45 上個月推出 Claude managed agents：一個能穩定執行 agent 的平台，負責處理其中困難的部分
  ↳ Claude managed agents 是 Anthropic 代管的平台。要讓 agent 長時間穩定地跑，背後有很多麻煩的技術細節，這個平台會幫你處理。
• 02:16 這條發展主線是：agent 能做的事越來越多，能運作的時間跨度也越來越長
  ↳ 把前面幾項串起來看，方向很一致：agent 能做的事越來越多，能連續工作的時間也越來越長。
• 02:16 Meter 在 2025 年發表研究，指出 agent 能完成的任務長度每 7 個月翻倍，Anthropic 也看到這個趨勢正在發生
  ↳ 研究機構 Meter 在 2025 年的研究指出，agent 能完成的任務長度大約每 7 個月翻倍。Anthropic 也說自己看到同樣的趨勢。
• 02:47 長時程任務的 context 管理還在發展中，memory 就是用來解決這個問題：讓 agent 把先前任務學到的東西帶到下一個任務
  ↳ 任務一拉長，要管好 agent 工作中掌握的資訊（context）就變難了。memory 的用處，是讓 agent 把這次學到的心得帶進下一次任務。
• 02:47 沒有 memory 的基本情況下，每個 agent 都從同一個起點出發，所以每次任務的表現差不多
  ↳ 沒有 memory 的話，agent 每次上工都像第一天上班的新人，之前的經驗全部歸零，所以每次表現都差不多。
• 03:18 理想情況下，表現會從任務一到任務二、任務二到任務三逐步提升；學習也能跨環境、跨 agent
  ↳ 理想狀況是像資深員工一樣越做越熟：第二次比第一次好，第三次又更好。學到的東西也能帶到別的環境，或分享給別的 agent。
• 03:18 有了 memory，agent 可以從常用策略、過去的錯誤、手上的工具、程式碼庫和檔案中學習
  ↳ agent 能學的東西很多：哪些做法常常有效、以前踩過哪些坑、手邊有哪些工具可以用，還有它處理過的程式碼和檔案內容。
• 03:50 agent 也能和其他 agent 互相傳遞學到的東西。願景是一群 agent 共同建立並維護對所屬組織的共同理解
  ↳ agent 之間也能互傳心得。最終的目標是讓一整群 agent 一起累積、維護對公司的共同認識，像大家共用的一份內部知識庫。
• 03:50 最近為 Claude managed agents 推出 memory，是朝這個願景邁出的一大步
  ↳ 這次替 Claude managed agents 加上 memory，就是往「agent 會累積經驗、還能彼此分享」這個目標跨出的一大步。
• 04:21 這套 memory 系統設計成開箱即用就能發揮最大智能，支援 multi-agent 系統，並提供企業等級的控管與可觀測性（observability）
  ↳ 設計目標有三個：不用另外調整就能發揮最好的效果；支援 multi-agent（多個 agent 分工合作）；讓企業能管控，也能看清楚記憶的狀況（observability，可觀測性）。
• 04:21 memory 是和多個正在使用 managed agents 的團隊合作打造的
  ↳ 這個功能是和好幾個已經在用 managed agents 的團隊一起磨出來的，不是 Anthropic 自己關起門來做的。
• 04:21 案例：Rakuten 在正式環境部署的 agent，first pass errors（第一次就出錯）減少了 97%
  ↳ Rakuten（日本樂天）把 agent 放進實際營運後，first pass errors（第一次產出就出錯的情況）減少了 97%。
• 04:51 案例：WiseDocs 在文件驗證流程中使用跨 session 的 memory，減少了常見問題
  ↳ WiseDocs 在審核文件的流程中，讓 agent 跨 session（每一次獨立的工作階段）保留記憶，常見的問題就比較少重複發生。
• 04:51 團隊最常給的回饋：有了這個 memory primitive，可以專心打造產品而不是基礎設施，同時享有 memory 變好帶來的智能提升
  ↳ 團隊最常給的回饋是：有了現成的 memory primitive（可以直接拿來用的基本元件），就不用自己蓋記憶系統，能專心做產品；memory 變強時，自己的產品也會跟著變聰明。
• 05:21 memory 這個概念本身不算新，但 Anthropic 為 agent 設計 memory 的做法已經大幅改變
  ↳ 讓 AI 有記憶不是新點子。新的是 Anthropic 替 agent 設計記憶的思路，已經和以前很不一樣。
• 05:21 以前的 memory 著重在 harness 層的功能，例如 Claude Code 的 Claude.md，或 SDK 裡專門的 memory 工具
  ↳ 以前的做法是放在 harness（包在模型外面、負責執行和管理的那一層程式）裡，例如 Claude Code 會讀的 Claude.md 說明檔，或 SDK 裡專用的記憶工具。
• 05:52 觀察到的趨勢：模型越強，越應該「讓開，別擋 Claude 的路」，就像當初設計 skills 時的做法
  ↳ 他們觀察到：模型越強，人越不該替它規定太多細節，留空間讓它自己判斷，效果反而更好。當初設計 skills 就是這個思路。
• 05:52 skills 是非常基本但彈性極高的格式，可能性無窮，模型也懂得怎麼使用。memory 延續同樣方向，採用「檔案」形式
  ↳ skills 的格式很簡單，但正因為簡單，可以裝的東西很多，模型也看得懂怎麼用。memory 沿用這個思路，直接用「檔案」來存記憶。
• 06:24 設計依據一：Claude 很擅長在虛擬環境和檔案系統中移動，也很會用 bash、grep 等熟悉的工具讀取、更新、整理檔案
  ↳ 選用檔案的理由：Claude 本來就很會在檔案系統裡找東西，也很熟 bash（用指令操作電腦的方式）、grep（在大量文字中搜尋關鍵字的指令），可以用它們讀寫、整理檔案。
• 06:24 上個月推出的 Opus 4.7，在以檔案系統為基礎的 memory 上是 state-of-the-art 模型
  ↳ 上個月推出的 Opus 4.7，在「用檔案系統當記憶」這件事上，是目前表現最頂尖（state-of-the-art）的模型。
• 06:24 Opus 4.7 越來越能判斷哪些 context 最值得留給未來的自己，也知道該用什麼結構、什麼形式來記錄
  ↳ 記憶的難處在取捨。Opus 4.7 越來越會判斷哪些資訊值得留給之後的自己，也知道要怎麼分類、用什麼格式記下來。
• 06:55 因此 memory 對 Claude 來說就是一個檔案系統。核心原則是別擋 Claude 的路，讓它用本來就很強的能力，也就是「let it cook」
  ↳ 所以對 Claude 來說，memory 就是一堆它能自己管理的檔案。原則是不要綁手綁腳，讓它發揮本來的強項，也就是「let it cook」（放手讓它做）。
• 07:25 memory 不只要在單一 agent 裡運作，還要在同時處於同一環境、甚至跨環境的多個 agent 之間運作，這帶來新需求
  ↳ 難的地方在於 memory 不只給一個 agent 用。多個 agent 可能同時在同一個環境、甚至不同環境工作，大家都要讀寫記憶，就冒出新的需求。
• 07:25 新需求之一：讓多個 session 同時共用同一個 memory store，而且可以設定不同 scope（read-only 或 read-write）
  ↳ 需求之一：讓多個 session 同時共用一個 memory store（記憶的儲存區），並設定 scope（權限範圍）：有的只能讀（read-only），有的能讀也能寫（read-write）。
• 07:25 例子：組織層級的 memory 設為 read-only、不常更新，所有 agent 都能讀；同一批 agent 也能自由讀寫更細的 memory store
  ↳ 例如組織層級的記憶就像公司規章，設成唯讀、很少改，所有 agent 都能看；各組 agent 另外有自己更細的記憶區，可以隨時讀寫。
• 07:55 這樣形成一種階層結構，讓 memory 系統能真正擴大規模
  ↳ 這樣就形成上下層級：上層是全體共用、穩定的知識，下層是各組自己的筆記。分層之後，agent 變多，記憶系統也不會亂掉。
• 07:55 為了避免寫入衝突、防止某個 agent 覆蓋另一個 agent 的修改，採用了 optimistic concurrency control 模型
  ↳ 多個 agent 同時改同一份記憶，可能會互相蓋掉。optimistic concurrency control 的做法是先讓大家改，存檔時再檢查有沒有人先改過，避免直接覆蓋別人的修改。
• 08:29 memory 必須能用在真實的正式環境 agent，所以需要企業等級的控管
  ↳ memory 要用在真正上線營運的 agent 上，企業會要求能管控、能查核，所以需要企業等級的管理功能。
• 08:29 版本控制：agent 每次修改都會留下 audit trail，開發者可以看到 memory 怎麼演變，也能比對（diff）不同版本
  ↳ 版本控制：agent 每改一次記憶都會留下 audit trail（修改紀錄）。開發者可以回頭看記憶怎麼演變，也能用 diff 比對兩個版本差在哪裡。
• 08:29 attribution：可以查到 memory 的哪一部分是哪個 agent 寫的
  ↳ attribution（來源標記）：可以查出記憶裡的哪一段是哪個 agent 寫的，不會變成來路不明的內容。
• 08:29 講者認為最重要的一點：memory 有獨立的 API，開發者可以從任何地方管理 memory
  ↳ 講者最看重的一點：memory 有自己獨立的 API（讓程式跟程式溝通的接口），開發者從任何地方都能直接管理記憶。
• 09:02 團隊會在各種不同環境建置系統，都可以透過這些 API 使用 memory。API 提供標準 CRUD 操作，以及匯出（exports）、遮蔽（redactions）等企業導向操作
  ↳ 各團隊的系統架在不同環境，都能透過 API 接上 memory。除了 CRUD（新增、讀取、修改、刪除）這些基本操作，還有匯出，以及 redaction（遮掉敏感內容）這類企業需要的功能。
• 09:02 memory 架構三大元件之一：storage layer，負責資料本身怎麼管理、修改怎麼追蹤
  ↳ memory 的架構分三塊。第一塊是 storage layer（儲存層），負責資料本身怎麼存放，以及每次修改怎麼被記錄、追蹤。
• 09:34 元件之二：memory 的結構，用 Claude 最能發揮的格式來設計。元件之三：由 Claude 主導的處理流程，負責更新 memory
  ↳ 第二塊是記憶的結構，照 Claude 最擅長處理的格式來設計。第三塊是處理流程，由 Claude 自己決定什麼時候、怎麼更新記憶。
• 09:34 processing layer 的關鍵是 agent 邊工作邊寫 memory，就像做事時順手做筆記
  ↳ processing layer（處理層）的關鍵是：agent 不是做完才回想，而是邊做邊寫，就像工作時順手記筆記。
• 10:05 這個模式擴大到更複雜的 multi-agent 使用情境後，跨 session 出現了一些限制和共同模式
  ↳ 但這個做法放大到多個 agent、多個 session 一起跑之後，開始出現一些限制，也反覆看到幾種共同的狀況。
• 10:05 問題一：agent 容易犯很多相同的錯，而且各自獨立地從錯誤中學習
  ↳ 問題一：不同 agent 常犯同樣的錯，卻各自摸索、各自學到教訓，一個 agent 踩過的坑，別的 agent 沒有因此少踩。
• 10:05 問題二：agent 也會出現相同的低效率模式
  ↳ 問題二：不同 agent 也會重複出現同樣沒效率的做法，同樣的浪費在好幾個地方發生。

為了避免多個 agent 同時寫入 memory 時互相覆蓋修改，講者說他們採用了什麼機制？