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

🧑‍🏫 這段接著上半場，介紹 Anthropic 的 dreaming 功能。agent 是能自己動手完成任務的 AI 助理，memory 是它累積下來的工作筆記；dreaming 就是在 agent 下班後，另外找時間幫它整理這些筆記。後半段用一個處理系統警報的示範，實際展示一群 agent 怎麼靠整理過的記憶越做越好。

• 12:14 dreaming 是一種批次、非同步的流程，和特定 session 裡正在處理特定任務的工作分開執行
  ↳ dreaming 就像人睡覺時整理白天的記憶。它是批次（一次處理一大批）、非同步（不用等它做完）的背景作業，和 agent 正在進行的 session（單次工作階段）分開跑。
• 12:14 觸發方式有兩種：透過 console 或 API 像 cron 一樣定期啟動，或用 API 接進既有流程
  ↳ 啟動有兩種方式：在 console（網頁管理介面）或用 API（程式之間溝通的接口）設定排程，像 cron（定時執行工具）那樣固定時間跑；或是接進你現有的工作流程，在需要時觸發。
• 12:14 例子：有些客戶會在 agent 完成任務、準備關閉時啟動 dreaming，把學到的東西存進 memory state
  ↳ 例如 agent 一做完任務、準備收工時，就順手跑一次 dreaming，把這次學到的東西寫進 memory state（記憶內容的最新版本）。有點像下班前寫交接筆記。
• 12:44 dreaming 會全面檢視近期的 transcripts，找出常見錯誤（例如失敗的 tool call）和有效的策略，並找出可以改善 memory state 的地方
  ↳ 它會回頭讀近期的 transcripts（agent 工作過程的完整紀錄），找出常犯的錯，例如 tool call（agent 呼叫外部工具）失敗，也找出有效的做法，再判斷記憶哪裡該改。
• 12:44 dreaming 會產出更新後的 memory state，可以直接套用到 memory store，也可以先透過 API 做檢查和人工審查
  ↳ 整理好的新版記憶可以直接寫進 memory store（掛在 agent 身上的記憶庫），也可以先透過 API 拿出來，讓人看過再套用，避免錯誤的內容被記下來。
• 12:44 dreaming 的最終目標是持續自我學習、自我改進，讓隔天的 agent 根據前一天的經驗自動變得更好
  ↳ 目標是讓 agent 從自己的經驗裡學，不用人一直手動調教：今天踩過的坑，明天的 agent 就知道要避開。
• 13:15 特性一：跟前面介紹的 memory APIs 比起來，dreaming 是 out of band，在 agent 處理特定 session 或任務的情境之外進行
  ↳ 前半段講的 memory APIs 是 agent 做事時邊做邊讀寫；dreaming 則是 out of band，意思是在任務之外另外進行，不會插手當下的工作。
• 13:46 好處一：很適合 multi-agent 系統。單一 agent 只有自己的 context 和任務視角，dreaming 可以同時看多個 agent，找出單一 agent 注意不到的共同模式
  ↳ multi-agent 系統就是多個 agent 分工合作。每個 agent 只看得到自己的 context（手上的資訊）和任務；dreaming 能同時看所有 agent，才抓得到大家共同的問題。
• 13:46 從 harness 設計的角度，他們一再發現 agent 開始任務時需要明確、單一的目標
  ↳ harness 是包在模型外面、讓 agent 能運作的那套架構。團隊在設計上一再發現：agent 開工時最好只有一個明確的目標。
• 14:16 dreaming 能把「memory 品質」這個目標，和 agent 原本就有的「完成任務、任務表現」目標分開
  ↳ 所以把兩件事拆開：做任務的 agent 專心把事情做好，dreaming 專心把記憶整理好，不用把兩個目標都塞給同一個 agent。
• 14:16 講者認為接下來幾個月，memory 對 agent 的實際成果和工作會越來越重要、越來越關鍵
  ↳ 講者認為接下來幾個月，agent 能不能做出好成果，會越來越取決於它記得什麼、記得準不準。
• 14:47 因為 dreaming 在背景執行，不會增加 agent 既有任務 hot path 的延遲
  ↳ hot path 是 agent 處理任務時最講求速度的那條主線。dreaming 在背景跑，所以不會拖慢 agent 的回應。
• 14:47 特性二：支援大規模 memory 系統，並有效運用運算資源來建立和整理這些系統
  ↳ 第二個特性：它撐得起很大的記憶系統，而且把運算資源花在刀口上，專門用來建立和整理這些記憶。
• 14:47 現在多數 memory 部署都侷限在特定使用者、特定任務，或一起工作的小團隊
  ↳ 目前大多數人用 memory 的範圍都很小：只記某一個使用者、某一類任務，或一個小團隊的事。
• 15:18 Anthropic 內部和合作企業已經有數百到數千個 agent 同時執行並共享狀態，memory 因此變成大型知識庫，而不只是存放任務工作情境的簡單 memory store
  ↳ 但在 Anthropic 內部和合作企業，已經有數百到數千個 agent 同時執行、共用資料，記憶就從個人筆記本變成全公司的 knowledge base（知識庫）。
• 15:18 要讓 Claude 把 memory 系統擴展到很大，同時保持內容最新，也不會太耗 token
  ↳ 難處在於：記憶變得這麼大，內容還要保持最新，又不能讓 agent 每次讀取都用掉大量 token（AI 計算文字量和費用的單位）。
• 15:48 dreaming 遵循類似 scaling laws 的原則：投入更多運算和心力，讓 memory 系統保持有條理
  ↳ scaling laws 是 AI 領域的經驗法則：投入越多運算，效果通常越好。dreaming 也是同樣思路：多花點運算去整理，記憶就更有條理。
• 15:48 可以用 test time compute 或幾年前的 thinking models 來理解：讓模型探索、花更多 token，會得到更好的結果；dreaming 也是讓 agent 花更多 token 整理 memory
  ↳ test time compute 指讓模型在回答時多花運算去思考，幾年前的 thinking models（先推理再回答的模型）就是這樣變強的。dreaming 同理，讓 agent 多花 token 整理記憶。
• 16:19 另一個類比是搜尋系統：先花心力建立高品質、最新的 index，檢索時就能快速取得結果。dreaming 也先建立並整理 index 給下游 agent 使用
  ↳ 搜尋引擎會先花力氣建好 index（索引，類似書後面的索引頁），你一搜就能馬上找到結果。dreaming 也是先把索引整理好，給後面要用的 agent 查。
• 16:19 這樣可以把整理 memory 的成本攤提（amortize）到所有讀取同一個 memory store 的 agent 身上
  ↳ amortize 是攤提、分攤的意思。整理一次的成本，由所有讀這個記憶庫的 agent 一起分攤；用的 agent 越多，每個 agent 分到的成本就越低。
• 16:49 在 managed agents API 裡，memory 加上 dreaming 構成他們目前所說的 frontier memory system
  ↳ managed agents API 是 Anthropic 幫你代管 agent 運作的服務。在這個服務裡，memory 加上 dreaming，就是他們目前所說的 frontier memory system（最前沿的記憶系統）。
• 16:49 memory 是讓 agent 在任務中即時讀寫、記住事情的 primitive；dreaming 建立在 memory 之上，負責驗證、組織 memory，並依照 agent 當天的任務補充（enrich and backfill）資訊
  ↳ primitive 是最基本的積木。memory 讓 agent 做事時隨時記、隨時查；dreaming 建立在它上面，負責檢查對錯、整理歸檔，並依當天的任務補上缺的資訊（enrich and backfill）。
• 17:21 dreaming 是中型 memory 系統和大型知識庫之間的橋樑，講者認為大型知識庫接下來幾個月會很重要
  ↳ 中型記憶系統像部門共用的筆記，大型知識庫像全公司的資料中心。dreaming 就是讓前者能長成後者的那座橋。
• 17:52 Demo：一個 SRE agent 監看進來的 alerts，依 alert 啟動特定 agent 做 triage，有時也會啟動 agent 去提交 PR
  ↳ SRE 是負責讓網站和系統穩定運作的工程角色。demo 裡的 SRE agent 盯著系統 alerts（警報），有警報就派 agent 做 triage（初步判斷問題），必要時送出 PR（程式修改申請）。
• 17:52 每個 agent 都配有幾個 memory stores：org-wide knowledge、SRE，還有 code base 的 memory store
  ↳ 每個 agent 身上掛了三個記憶庫：全公司共用的知識（org-wide knowledge）、SRE 團隊的經驗，還有程式碼本身相關的記憶。
• 18:22 org-wide knowledge memory store 是 read-only，內容是 runbooks、SLO guidelines，也會告訴 agent 該找哪些負責人；很少更新，也不希望 agent 在工作時去改它
  ↳ 全公司知識庫是 read-only（只能讀不能改），放 runbooks（出事時的處理手冊）、SLO guidelines（服務穩定度標準）和該找的負責人。它很少更新，也不讓 agent 工作時去改。
• 18:22 SRE memory store 是 read-write，SRE agents 會在回應環境、從中學習時不斷更新它
  ↳ SRE 記憶庫是 read-write（能讀也能寫），SRE agents 每處理一次狀況、學到新東西，就會回來更新它。
• 18:22 dispatch service 傳來一個 P1 alert，系統啟動 SRE agent 開始調查
  ↳ dispatch service（負責分派警報的服務）送來一個 P1 警報，P1 一般代表最高優先的緊急事件，系統馬上派一個 SRE agent 去調查。
• 18:53 這個 agent 調查了 CPU utilization、traffic patterns，也查了最近部署的 PR，然後把發現寫進 SRE memory store，形成一筆新的 diff
  ↳ 這個 agent 查了 CPU 使用率、流量變化和最近上線的程式修改，再把發現寫進 SRE 記憶庫，形成一筆 diff（這次新增或修改的內容差異）。
• 18:53 幾分鐘後同一個 alert 再次觸發，另一個 SRE agent 啟動，並能存取同一個 memory store
  ↳ 幾分鐘後同一個警報又響了，系統派出另一個 SRE agent，而它也讀得到同一個記憶庫。
• 19:23 新的 agent 先看到 memory 裡的筆記，知道之前的調查和結果，可以直接 short-circuit，省下重複調查的時間
  ↳ 新的 agent 先翻筆記，就知道前一個 agent 查過什麼、查到什麼，可以 short-circuit（直接跳過重複的步驟），不用從頭再查一次。
• 19:23 結果是立即提升 token 效率，也提升了智慧：它知道接下來還能調查什麼
  ↳ 好處有兩個：省下重查的 token，馬上變便宜；它也會更聰明，因為已經知道接下來還有哪些方向可以查。
• 19:23 要在企業裡部署，需要可靠性，也要能看到是哪些決策導致某個結果
  ↳ 企業要真正上線使用，系統必須穩定可靠；出了結果，也要能追查是哪些判斷一步步造成的。
• 19:54 memory store 有 version history：每次更新都能回溯查看改了什麼、由哪個 agent 修改、什麼時候寫的
  ↳ memory store 有 version history（版本紀錄），有點像 Google 文件的版本記錄，每次修改都查得到改了什麼、是哪個 agent 改的、什麼時候改的。
• 19:54 每次更新都附有 precondition hash，用來做 optimistic concurrency：覆寫之前先確認內容沒被改過
  ↳ 每次寫入都附一個 precondition hash（內容指紋），用來做 optimistic concurrency：寫入前先比對指紋，確認沒人搶先改過，避免 agent 互相蓋掉對方的內容。
• 20:26 切換到 console，畫面反映的就是 API 的實際狀態，裡面是已建立的 memory stores；點進 team SRE memory store 可以看到最新寫入的內容
  ↳ 切到 console 看，畫面和 API 裡的實際狀態一致，列出已建好的記憶庫；點進 team SRE 記憶庫，就能看到剛才 agent 寫進去的筆記。
• 20:26 在 dreaming 分頁可以啟動 dreaming job，並指定要更新、建立哪個 memory store
  ↳ console 裡有個 dreaming 分頁，可以在這裡啟動一次 dreaming job（整理作業），並指定要更新哪個記憶庫，或建立新的記憶庫。
• 20:57 Demo 中選擇回顧過去 7 天所有接觸過這個 memory store 的 sessions
  ↳ demo 設定的範圍是：回頭看過去 7 天內，所有用過這個記憶庫的 sessions。
• 20:57 dreaming 會列出要檢視的 input sessions，並在 console 裡啟動一個實際的 session，可以看到它正在做什麼
  ↳ dreaming 會先列出要讀哪些 sessions，接著在 console 開一個真正的 session 來做事，你能即時看到它每一步在忙什麼，不是黑箱。
• 20:57 它會啟動一批 subagents 讀 transcripts、找出 learnings，再產出更新後的 memory state
  ↳ 它會派出一批 subagents（分工合作的小幫手 agent）分頭讀紀錄、整理心得，最後彙整成新版記憶。
• 21:28 完成的 dreaming job 會產出一份 diff，也就是一組要套用到 memory store 的更新檔案
  ↳ 跑完後會交出一份 diff，也就是準備套用到記憶庫的一組修改，有點像一份改稿建議。
• 21:28 第一項更新是 demo 裡的 dispatch latency 筆記：很多 agent 都剛好在上游 CPU 飆高後 60 秒被觸發
  ↳ 第一項更新和 dispatch latency（警報分派的延遲）有關：很多 agent 都剛好在上游 CPU 飆高後 60 秒才被派出去。
• 22:00 dreaming 從這個模式推斷，可能有低效的 retry logic 被觸發，讓 triage 浪費很多時間
  ↳ dreaming 從這個規律推測，可能是某段效率不好的 retry logic（失敗後自動重試的機制）被觸發，讓初步排查浪費很多時間。
• 22:00 個別 agent 不知道其他 agent 也每次都遇到 60 秒的模式，所以看不出來；dreaming 發現後留下筆記，讓未來的 agent 能更有效率地處理
  ↳ 每個 agent 只看到自己那一次晚了 60 秒，不知道其他 agent 也一樣；dreaming 把紀錄放在一起看才發現這個規律，並留下筆記讓之後的 agent 處理得更快。
• 22:00 dreaming 也會去重與整併：發現之前的 agent 留下五筆相同條目，就合併成一筆
  ↳ 它也會做 deduplication（去重）：之前幾個 agent 寫了五筆一模一樣的筆記，它合併成一筆，記憶庫就不會越堆越亂。
• 22:32 它會移除已經失效、不再相關的過時條目
  ↳ 過時的 stale entry（已經失效、不再適用的舊筆記）會被刪掉，免得 agent 照著舊資訊做出錯誤判斷。
• 22:32 它會加上 verification note：根據剛讀過的 transcript，確認這筆 memory 正確，隔天的 agent 可以放心依賴
  ↳ 它還會加上 verification note（查證註記），註明這筆記憶已經對照剛讀過的工作紀錄確認過，隔天的 agent 可以放心照用。
• 22:32 講者認為 memory 和 dreaming 很適合做這幾件事：驗證、補充（backfill）、整理
  ↳ 講者總結，memory 加上 dreaming 最擅長三件事：查證內容對不對、把缺的補上、把雜亂的整理好。
• 23:03 這個 demo 展示了如何用 managed agents API 裡的 memory 和 dreaming APIs 打造 production agents
  ↳ 這個 demo 要示範的是：用 managed agents API 裡的 memory 和 dreaming，可以做出真正上線運作（production）的 agent。
• 23:03 講者預期接下來幾個月會出現連續執行好幾天或很多小時的 agent，而 memory 是讓這件事成為可能的關鍵
  ↳ 講者預期幾個月內會出現連續跑好幾個小時、甚至好幾天的 agent；要撐這麼久，關鍵就在記憶。

在 demo 的 dreaming 結果中，dreaming 發現許多 SRE agent 都在上游 CPU 飆高後多久被觸發，並推測可能有低效的 retry logic？