讓 agent 自我學習的 memory 與 dreaming（第 1/2 段） ☕ Buy me a coffee

🧑‍🏫 這支影片是 Anthropic 的產品經理在講，怎麼讓 AI agent 記住經驗。AI agent 指能自己連續做事、呼叫工具完成任務的 AI 助理。前半段說明他們的 memory（記憶功能）照哪三個原則設計，後半段介紹新功能 dreaming：讓 agent 在工作空檔回頭整理大家的經驗。如果你好奇 AI 助理怎麼越用越聰明、企業又怎麼放心讓它上線，這段很值得看。

• 00:08 講者 Mahesh 是 Anthropic platform team 的產品經理，參與過 MCP 和 skills 等 primitive，這次要談他最期待的下一個 primitive：memory
  ↳ 講者 Mahesh 是 Anthropic 平台團隊的產品經理，做過好幾個 primitive。primitive 就是 Anthropic 提供給 agent 的基礎能力積木。這次他要談最期待的下一塊：memory。
• 00:39 同時發表全新產品 dreaming，當天以 research preview 形式在 managed agents API 推出
  ↳ 同場發表新功能 dreaming，當天以 research preview（搶先試用的研究版）上線。上線地點是 managed agents API，也就是開發者用程式串接，來建立和執行 agent 的 Anthropic 服務。
• 00:39 模型能力近幾年進步很快，agent 可以執行花好幾個小時的任務，甚至連續跑好幾小時到將近好幾天
  ↳ 這幾年模型進步很快，agent 已經能接下要做好幾個小時的工作，甚至連續跑好幾個小時、接近好幾天都不停。
• 01:10 Anthropic 持續打造更高層的 primitive，讓模型接觸更多環境：MCP 讓 agent 存取外部工具與資料；也推出 Claude Code、agent SDK 這類強大的 harness
  ↳ MCP 讓 agent 接上外部工具和資料。Claude Code（寫程式的 agent）和 agent SDK（開發套件）則屬於 harness，也就是包在模型外面、讓它真的能動手做事的框架。
• 01:10 10 月推出 skills，讓 agent 取得新能力，這些能力可能由其他 agent 設計分享，也可能由互動的人類／使用者設計
  ↳ 10 月推出的 skills，是一包包可以裝進 agent 的能力說明，裝上就多一項技能。這些技能可以由別的 agent 設計來分享，也可以由使用者自己設計。
• 01:40 還沒解決的問題：長時間任務中的持續自我學習（continuous self-learning）與 context management
  ↳ 還有兩個難題沒解決。一是長時間工作時能不能邊做邊學。二是 context management：模型一次能看的內容有限，要決定哪些留著、哪些丟掉。
• 02:11 memory 是下一個 primitive，目標是做出能從任務和自身經驗中演進、進步的 self-learning agent
  ↳ 所以 memory 是下一塊積木，目標是做出 self-learning agent：能從做過的任務和自己的經驗累積心得、越做越好，不必每次從零開始。
• 02:11 agent 可以透過 memory 學到任務本身的事，例如成功標準、常見錯誤、哪些策略有效或無效
  ↳ agent 第一個能學的是任務本身：怎樣才算做好、哪裡最常出錯、哪些做法有效或沒用。就像新人上手後，會記下主管最在意哪些細節。
• 02:11 agent 也能學到所處環境的事，例如接觸的 code base，以及它持續更新的檔案與素材
  ↳ 第二個能學的是工作環境，例如它負責的 code base（整個程式碼庫），還有它一直在修改的那些檔案和資料。
• 02:42 agent 能向同環境的其他 agent 學習：分享學到的東西、找出系統其他地方的問題，再寫進自己的 memory
  ↳ 第三個是向同事學：同一環境的其他 agent 會分享心得，或發現系統別處出了問題，這些都能寫進自己的 memory。
• 02:42 講者最期待的是：在大型複雜的 multi-agent 系統裡，一群 agent 各做各的任務，隨時間建立對所處世界的理解，自我管理的 memory 會非常重要
  ↳ 講者最期待的是 multi-agent system，也就是很多 agent 分工的系統。大家各做各的，久了累積對整個環境的理解，這時 agent 能不能自己管理記憶就很關鍵。
• 03:15 幾週前 managed agents 的 memory 進入 public beta，定位是開箱即用的 frontier memory system
  ↳ managed agents 的 memory 幾週前已進入 public beta，也就是公開測試：大家都能用，但還在調整。它的定位是不用自己組裝、拿來就能用的最先進記憶系統。
• 03:15 設計目標有三個：預設就把智慧發揮到最大、支援多個 agent 在同一環境同時執行、給企業和開發者在正式環境需要的彈性與控制
  ↳ 設計目標有三個：不用特別設定就夠聰明；很多 agent 同時在同一個環境跑也不會亂；企業和開發者正式上線時，有足夠的彈性和掌控權。
• 03:48 案例 Rakuten：內部知識 agent 的第一輪錯誤（first pass mistakes）降低 90%，因為 agent 能抓到錯誤並傳給下一輪 agent
  ↳ 樂天（Rakuten）的內部知識 agent，第一輪就做錯的情況少了 90%。因為前一輪 agent 犯的錯會被記下來、交給下一輪，下一輪就不會再犯。
• 03:48 Rakuten 導入 memory 後，也得到更好的 token efficiency、更低成本和更好的 latency
  ↳ 樂天用了 memory 之後，token（模型處理文字和計費的單位）用得更有效率、成本更低，latency（等回應的時間）也變短了。
• 04:22 需求一：memory 預設就要把智慧發揮到最大
  ↳ 第一個需求：memory 預設就要夠聰明，不必靠開發者一條條規定怎麼記，模型自己就能把記憶用到最好。
• 04:22 大約一年半前隨 Claude Code 推出的 Claude.md 是早期、限制較多的 memory：agent 在檔案裡留筆記給自己，使用者有時也會在同一個檔案留筆記
  ↳ 早期的做法是 Claude.md：約一年半前隨 Claude Code 推出的筆記檔。agent 在裡面寫筆記給自己看，使用者有時也會在同一個檔案加註，形式比較受限。
• 04:53 SDK 裡也推出過 memory tool，是參數和輸出格式都有明確規格的 tool call，給 API 開發者使用
  ↳ SDK 裡也推出過 memory tool。它是一種 tool call（模型呼叫工具的動作），要填哪些參數、回傳什麼格式都事先規定好，給用 API 的開發者使用。
• 04:53 隨著 agent 變強，方向是盡量不擋 Claude 的路，把更多決策交給 Claude，不過度限制 harness 設計；和 skills 的思路一樣
  ↳ 模型越強就越該放手：少替 Claude 訂死規矩，也別把 harness 設計綁太緊，讓 Claude 自己決定怎麼記。這跟 skills 的設計思路一樣。
• 05:24 既然 agent 能管理虛擬環境和自己的檔案系統，managed agents 就把 memory 設計成檔案系統：一組有特定階層與格式的檔案，由 Claude 自己管理和更新
  ↳ 既然 agent 本來就會管理自己的虛擬電腦和檔案，managed agents 乾脆把 memory 做成一組檔案，有固定的層級和格式，由 Claude 自己整理和更新。
• 05:24 Claude 用 bash、grep 這些熟悉的工具更新 memory、保持整齊，並在處理任務時持續修改
  ↳ Claude 用 bash（在命令列下指令操作電腦）和 grep（在檔案裡搜尋文字的指令）這些熟悉的工具更新記憶、保持整齊，邊做任務邊修改。
• 05:54 上個月推出的 Claude Opus 4.7 在 file system-based memory 上達到 state-of-the-art
  ↳ 上個月推出的 Claude Opus 4.7，在「用檔案系統當記憶」這種做法上達到 state-of-the-art，也就是目前業界最好的水準。
• 05:54 Opus 4.7 更會判斷什麼值得記、該用什麼結構、memory 要拆成幾個檔案、怎麼在檔案系統裡保持整齊，而且只靠 Bash 和 grep 工具
  ↳ Opus 4.7 更會判斷哪些事值得記、該怎麼分類、要拆成幾個檔案、怎麼讓資料夾保持整齊，而且只靠 Bash 和 grep 兩種基本工具。
• 06:24 需求二：memory 要能隨 multi-agent 系統擴展。已經有創作者同時開 10 或 15 個 Claude Code session
  ↳ 第二個需求：memory 要撐得住很多 agent 一起用。已經有創作者同時開 10 到 15 個 Claude Code session（每個 session 是一段獨立的工作對話）。
• 06:24 企業（包括 Anthropic）有數百甚至數千個 agent 平行執行，共用同一份狀態和同一份 memory
  ↳ 企業的規模更大，包括 Anthropic 自己在內，有幾百甚至幾千個 agent 同時在跑，共用同一份工作狀態和同一份記憶。
• 06:55 agent 要能自由搭配 session、手上的工作，以及可存取的 memory store
  ↳ 所以要能自由搭配：哪個 session 做哪件事、能打開哪幾個 memory store，都可以分開設定。memory store 就是一組記憶資料，像共用資料夾。
• 06:55 特性一 permission scopes：agent 可以對某個 memory store 只有 read-only 權限，例如全組織的知識、最佳實務、處理常見任務的 runbook
  ↳ 特色一是 permission scopes（權限範圍）：某些 memory store 只給 read-only（只能看），例如全公司的知識、最佳做法、處理常見任務的 runbook（作業手冊）。
• 07:26 同一個 agent 可以對另一個 memory store 有 read-write 權限，例如跟目前工作相關、更新更頻繁的 working memory
  ↳ 同一個 agent 對另一個 memory store 可以 read-write（能看也能改），例如 working memory，也就是跟手上工作有關、常更新的筆記。就像公司手冊只能看，工作筆記可以隨時改。
• 07:26 特性二 concurrency：數百、數千個 agent 同時存取同一份 memory 時，要確保不會互相覆蓋（clobber／overwrite）
  ↳ 特色二是 concurrency（同時存取）：幾百、幾千個 agent 同時改同一份記憶，要避免 A 剛寫好的內容被 B 蓋掉，就像多人同時編輯同一份文件。
• 07:56 做法是 optimistic concurrency：agent 更新前先用 content hash 檢查，確認不會覆蓋到其他 agent 的 memory
  ↳ 做法是 optimistic concurrency：先假設大家不會撞車，但每次改之前先比對 content hash（用內容算出的指紋）。確認檔案沒被別人改過，才寫進去。
• 07:56 需求三（跟客戶聊下來最重要）：正式環境 agent 需要開發者與企業的控制權
  ↳ 第三個需求，也是跟客戶聊下來最重要的：agent 正式上線後，開發者和企業要能掌控它。
• 08:27 最多人要的是 version history：開發者能看到每次 memory 更新的完整 audit log，未來也能讓 agent 讀這份 log，追蹤什麼時候改了什麼
  ↳ 最多人要的是 version history（版本紀錄）：每次記憶的修改都留下完整的 audit log（稽核紀錄），開發者查得到。未來 agent 也能讀，知道什麼時候改了什麼。
• 08:27 attribution metadata：記錄是哪個 agent、什麼時間、哪個 session 做了修改，做到很細的粒度，讓行為可預期、由開發者掌控
  ↳ attribution metadata（修改者資訊）會記下是哪個 agent、在什麼時間、從哪個 session 改的，記得很細。這樣行為比較可預期，也由開發者掌控。
• 08:57 standalone API：很多客戶在 managed agents 之外自建系統，管理和整理 memory
  ↳ standalone API（獨立 API）：很多客戶在 managed agents 之外有自己的系統，要在那裡管理和整理記憶，所以記憶不能只在 Anthropic 的環境裡才碰得到。
• 08:57 客戶用例：做 PII 掃描避免 memory 裡有敏感內容、用自己的 pipeline 清理 memory、把 memory 複製到外部系統
  ↳ 客戶的實際用法：做 PII 掃描，檢查有沒有電話、身分證字號這類個資，確保記憶裡沒有敏感內容；用自己的流程清理記憶；把記憶複製到外部系統。
• 09:27 為了不把客戶綁死在只有 managed agents 能用的系統，做了可攜的（portable）API，讓客戶自己控制這些流程
  ↳ 為了不把客戶綁死在 managed agents，這套 API 做成 portable（可攜的）：記憶可以帶出去，要怎麼處理由客戶自己決定。
• 09:27 frontier memory system 分三層，第一層是 storage layer：資料存在哪、旁邊附帶哪些 metadata 和 attribution 資料
  ↳ 講者把最先進的記憶系統拆成三層。第一層是 storage layer（儲存層）：記憶存在哪裡，旁邊附帶哪些 metadata（描述資料的資料）和修改者資訊。
• 09:57 第二層是 structure and content layer：例如把 memory 做成檔案系統裡的檔案；skills 則是一種 procedural memory，規格很輕量
  ↳ 第二層是 structure and content layer（結構與內容層）：記憶長什麼樣子，例如做成一個個檔案。skills 也算一種 procedural memory，也就是教「怎麼做」的記憶，規格很輕。
• 09:57 第三層是 process layer：memory 多久更新一次、什麼會觸發更新、依據哪些來源決定要改什麼、學什麼
  ↳ 第三層是 process layer（流程層）：記憶多久更新一次、什麼事會觸發更新，以及根據哪些資料決定要改什麼、學什麼。
• 10:28 agent memory API 只解決一部分問題。規模擴大到複雜 multi-agent 系統後，發現有些 session 漏掉了其他 agent／session 已經自己摸索出來的東西
  ↳ memory API 只解決一部分問題。系統變大後團隊發現，有些 session 沒拿到其他 agent 早就自己摸索出來的心得，等於重踩別人踩過的坑。
• 10:28 也發現同一環境的多個 agent 之間，存在共同的錯誤和共同的模式
  ↳ 團隊也發現，同一環境裡的多個 agent，常犯同樣的錯、有同樣的做事模式。
• 10:59 agent 無法以全面、有效率的方式維護大規模 memory store，因為它們各自只專注在自己的任務上
  ↳ 問題在於每個 agent 都埋頭做自己的任務，沒辦法全面又有效率地整理一個大型記憶庫。就像每個員工都在忙，沒人整理公司共用的知識庫。
• 10:59 過去幾個月實驗了幾種補強流程，最後選定一種，稱為 dreaming，當天在 managed agents API 以 research preview 推出
  ↳ 團隊這幾個月試了幾種補強做法，最後選定一種，取名 dreaming，當天在 managed agents API 以 research preview 推出。
• 11:29 dreaming 的定義：從近期 agent session 和 transcript 找出模式與錯誤，自動產出整理好、最新的 memory 內容
  ↳ dreaming 會回頭看最近的 agent session 和 transcript（完整的工作紀錄），找出常見的模式和錯誤，自動整理成最新、有條理的記憶內容。
• 11:29 案例 Harvey：在一個模擬真實法律情境的 legal benchmark 導入 dreaming 後，其中一個法律情境的任務完成率提升 6 倍
  ↳ Harvey 在一個模擬真實法律工作的 benchmark（評分用的標準測試）上用了 dreaming，其中一種法律情境的任務完成率提升到原本的 6 倍。
• 12:01 接下來要說明為什麼對 dreaming 感到興奮，以及設計和 harness 上的考量；dreaming 是一種 batch……（這段字幕到此截斷）
  ↳ 接下來講者要說明為什麼對 dreaming 感到興奮，以及設計和 harness 上的考量。他說 dreaming 是一種 batch……字幕在這裡斷掉，後面的內容要看下一段。

根據影片，Harvey 在 legal benchmark 導入 dreaming 後，其中一個法律情境有什麼變化？