會記憶的 Agents（第 1/2 段） ☕ Buy me a coffee

🧑‍🏫 這支是 Anthropic 工程師 Kevin 開的實作課第一段，主題是怎麼讓 Claude 的 agent（能自己用工具完成任務的 AI 助手）「記得事情」。平常每開一次新對話，AI 都會從零開始。這段示範加上「記憶庫」之後，上次講過的事下次也找得回來，也先預告了會自動整理記憶的 dreaming 功能。

• 00:21 講者 Kevin 是 Anthropic 的工程師，這場 workshop 教大家怎麼打造「會記憶」的 agents
  ↳ 講者 Kevin 是 Anthropic 的工程師。workshop 是邊講邊動手做的實作課，這場教大家讓 agent 能把學到的東西記住、下次繼續用。
• 00:21 現況的問題：agent 彼此隔離，限制了它在很多真實工作流程中的用處
  ↳ 目前 agent 每次工作都是各做各的，做完就忘。這就像每次都換一個新同事，得從頭交代一遍，所以很多需要延續的真實工作沒辦法交給它。
• 00:21 解法是新推出的 agent memory stores 功能：讓 agent 使用一個即時的 memory store，可以在多個 session 之間讀寫
  ↳ 新功能 memory store 就是 agent 專用的記憶庫。agent 可以隨時寫進去、讀出來，而且換到下一次對話，裡面的東西也還在。
• 00:51 之後會介紹 dreaming 這個新功能，用來讓 memory store 隨時間改善；最後會用 CLI 和 console 介面示範整個流程
  ↳ 之後會介紹 dreaming，讓記憶庫越用越整齊。示範會用兩種方式：CLI 是打指令操作的文字介面，console 是網頁版的管理後台。
• 00:51 之前的 workshop 介紹過 Claude Managed Agents 的三個概念：agent、environment、session
  ↳ Claude Managed Agents 是 Anthropic 幫你代管 agent 的平台，有三個基本元件：agent 是助手本身的設定，environment 是它工作的執行環境，session 是一次獨立的工作或對話。
• 01:21 本場新增兩個概念，第一個是 memory store：像檔案系統一樣的持久儲存，以 resource 的形式附加到 session 上，讓 agent 跨 session 讀寫資訊
  ↳ memory store 就像一個不會消失的資料夾。開 session 時把它當成 resource（附加給這次工作用的外部資源）接上去，agent 就能在不同次對話之間存取。
• 01:21 第二個是 dream：在背景執行的非同步工作，會讀取一個輸入的 memory store 和以 transcript 形式呈現的過往 session
  ↳ dream 是在背後自己跑的工作，你不用在旁邊等。它會讀記憶庫，也會讀過去對話的 transcript（完整的逐字紀錄），兩邊一起分析。
• 01:53 dream 會用 harness 處理這些資料，萃取原本 agent 可能漏掉的新資訊，並做事實查核
  ↳ harness 是包住模型、讓它照流程使用工具的執行框架。dream 用它回頭翻舊紀錄，把當時 agent 漏存的重點補進記憶庫，也順便檢查內容對不對。
• 01:53 dream 也會整理、合併、去除重複的資訊，避免 memory store 隨時間無限膨脹
  ↳ 它也會像整理筆記本一樣，把相關的內容合併，把重複的刪掉（deduplicate 就是去重複），不讓記憶庫越塞越大、越來越難找。
• 02:25 問題示範：一般一次只建立一個 session，各 session 互相隔離，agent 不記得過去的資訊，也不會傳給之後的 session
  ↳ 先示範問題：平常每次只開一個 session，彼此互不相通。agent 不記得上次聊過什麼，也不會把資訊帶到下一次。
• 02:56 先執行 workshop repository 裡附的 bootstrap script，建立種子資料：一個 agent、一個 environment，以及幾個過往 session（內容是第一天的 keynotes 和先前的 workshop）
  ↳ bootstrap script 是一鍵建好初始資料的腳本，放在課程的程式碼庫（repository）裡。它會先建好 agent、environment 和幾筆舊對話，內容是第一天的主題演講和之前的課程，當作示範素材。
• 03:26 步驟一：用先前建立的 agent 和 environment ID 建立 session，標題是「write test with no memory」
  ↳ 第一步：用剛建好的 agent 和 environment 的 ID（每樣東西的專屬編號）開一個新 session，取名叫「沒有記憶的測試」。
• 03:56 console 裡看得到剛建立的 session，狀態是 idle，還沒有任何東西在執行
  ↳ 在 console 後台可以看到這個 session，狀態是 idle，意思是閒置中，還沒開始做任何事。
• 03:56 對這個 session 送出第一則使用者訊息，內容是昨天的 CMA 演講，提到 multi-agent orchestration、outcomes、memory 等關鍵字，並附上筆記的範例 URL
  ↳ 接著傳第一則訊息，告訴它昨天 CMA（Claude Managed Agents 的縮寫）演講的重點，像是多個 agent 分工合作、outcomes、記憶等功能名稱，並附上筆記連結。
• 05:03 模型只回覆「好，謝謝你提供這些資訊」；講者說這個 agent 用的應該是 Sonnet
  ↳ 模型只回了一句「好，謝謝你提供這些資訊」。講者推測這個 agent 用的是 Sonnet，也就是 Claude 系列裡的一種模型。
• 05:33 步驟二：建立第二個 session 做 retest，問它剛剛告訴它的內容；agent 回答自己沒有這些資訊，只能提供其他協助
  ↳ 第二步：另開一個新 session 重測，問它「我剛剛跟你說了什麼」。它回答自己沒有這些資訊，只能改幫別的忙。
• 06:04 小結：在一個 session 講了某件事，之後到另一個 session 問，資訊不會在 session 之間傳遞
  ↳ 結論很直接：在 A 對話講過的事，到 B 對話去問就不見了，每個 session 都是從一張白紙開始。
• 06:04 解法跟人類一樣，引入「記憶」；Claude Managed Agents 平台裡的 memory store 是類似檔案系統的儲存
  ↳ 解法跟人一樣，就是要有記憶。平台上的 memory store 是一個像電腦資料夾、可以放檔案的儲存空間。
• 06:04 memory store 想建幾個都可以，不必一個組織只用一個，可以依使用者、依 workspace 等切分，邊界由你自己定義
  ↳ 記憶庫可以開很多個，例如每位使用者一個、每個團隊工作區（workspace）一個。哪份記憶給誰共用，由你自己決定。
• 06:35 底層運作：memory store 會以檔案系統的形式掛載到 session container 上，模型有工具可以讀寫它
  ↳ 實際運作上，記憶庫會接到 session 的 container（agent 執行時用的獨立小電腦環境）上，看起來就像裡面多了一個資料夾，模型有工具可以讀寫。
• 06:35 之所以掛載成檔案系統，是因為這對模型來說是很強大的介面：可以用 bash 探索、用 grep 搜尋關鍵字、讀取檔案
  ↳ 做成資料夾的原因是模型本來就很會操作檔案：可以用 bash（下指令操作電腦的工具）逛目錄、用 grep（關鍵字搜尋工具）找內容、直接打開檔案讀。
• 07:07 建立 memory store 主要只需要一個 name（示範取名 CWC memory），也可以加上簡短的 description
  ↳ 建立記憶庫很簡單，基本上只要取個名字（示範時叫 CWC memory），想的話可以再加一句說明（description），寫這個記憶庫的用途。
• 07:37 建立後可以在 console 的 Managed Agents → Memory stores 看到它，狀態是 active，點進去有檔案系統檢視器（目前是空的）
  ↳ 建好後，在 console 的「Managed Agents → Memory stores」頁面就看得到，狀態是 active（啟用中）。點進去可以像看資料夾一樣瀏覽，目前還是空的。
• 08:09 console 也可以手動新增記憶，例如在指定路徑建立檔案並填入內容
  ↳ 你也可以不透過 agent，直接在 console 手動加記憶，例如指定一個檔案位置，自己把內容打進去。
• 08:40 建立後要在 session 中使用：在 sessions API 的請求裡傳入 memory store ID
  ↳ 要讓 session 用這個記憶庫，就在開 session 的 API 請求（程式對平台下的指令）裡，附上這個記憶庫的 ID。
• 08:40 可以加上 prompt 參數，引導 agent 讀寫特定資訊；例如做投資 agent 時，可以指定它要記住哪些東西供之後使用
  ↳ 還可以加一段 prompt（給 agent 的文字指示），告訴它該記什麼。例如做投資助手時，可以指定它要記住哪些資訊，留著之後用。
• 09:10 另有 access 欄位，預設是讀寫；可以改成 read only，這樣 session 和 agent 只能讀取該 memory store，不能更新
  ↳ access 欄位管權限，預設可讀可寫。改成 read only（唯讀）以後，agent 只能看、不能改，適合放不希望被動到的資料。
• 09:40 建立附加了 memory store 的新 session，再送一次同樣的 CMA 演講資訊
  ↳ 接著開一個接上記憶庫的新 session，把同樣的 CMA 演講內容再傳一次。
• 10:16 模型會先查看記憶，確認有沒有需要知道的東西；發現是空的後，就把內容直接存進 memory store 的 sessions.md 檔案
  ↳ 模型先翻記憶庫，看有沒有需要知道的東西。發現是空的，就把這次的內容寫進記憶庫裡一個叫 sessions.md 的文字檔。
• 10:50 再建一個使用同一個 memory store 的新 session，問它從 CMA 演講學到了什麼
  ↳ 然後再開一個新 session，接同一個記憶庫，問它「你從 CMA 演講學到了什麼」。
• 11:23 模型先查 memory store，用 grep 搜尋關鍵字「CMA」，找到上一個 session 存的資訊並成功回答
  ↳ 模型先到記憶庫用 grep 搜尋「CMA」，找到上一個 session 存下的內容，所以答得出來。跨對話的記憶就這樣生效了。
• 11:23 講者表示這雖然是很簡單的例子，但展現了記憶的威力，這在過去是很難做到的
  ↳ 講者說這個例子雖然簡單，但看得出記憶的威力：以前要讓 agent 記住上一次對話的事，是很難做到的。
• 11:53 平台另外提供 endpoints 可以手動檢查 store，例如用 CLI 列出 memory store 裡的所有記憶檔案
  ↳ 平台也提供 endpoints（API 上各個功能的專屬入口），讓你自己檢查記憶庫，例如用 CLI 一次列出裡面所有記憶檔案。
• 12:23 memory store 裡的記憶檔案有版本控管：每次修改檔案都會產生新版本，也有一組對應的 endpoints
  ↳ 記憶檔案有版本紀錄，每改一次就多一個版本，類似 Google 文件的版本記錄，也有對應的 endpoints 可以查這些版本。
• 12:54 在 console 的檔案系統檢視中可以看到建立的檔案；如果 Claude 建了子目錄來整理記憶檔案，這裡也會顯示目錄結構
  ↳ console 的資料夾畫面會顯示 agent 建的檔案。如果 Claude 自己開了子資料夾來分類記憶，這裡也會照樣呈現。
• 12:54 可以直接編輯記憶檔案，例如修正 Claude 寫錯的內容或補充資訊，也能新增記憶
  ↳ 你可以直接改記憶檔案：Claude 記錯了就幫它修正，漏了就幫它補上，也可以自己新增一條記憶。
• 13:28 小結：建立 memory store，再掛到想用的 session 上；哪些 session 用記憶、哪些不用，由你自己決定
  ↳ 整理一下：先建記憶庫，再把它接到你要的 session 上。哪些對話要用記憶、哪些不用，完全由你決定。
• 13:59 dreaming 的動機：agent 長期讀寫 memory store 時，常常會把資訊一股腦倒進去，例如每個任務都記錄一次，store 就會越長越大
  ↳ 為什麼需要 dreaming：agent 長期使用記憶庫時，常把所有東西一股腦丟進去，例如每做一件事就記一筆，記憶庫會越長越大。
• 13:59 在這之前，並沒有機制可以整理這些記憶，或檢查有沒有過時的內容
  ↳ 在這之前，沒有辦法幫這些記憶做整理，也沒辦法檢查哪些內容已經過時、不再正確。

將 memory store 掛載到 session 時，access 欄位的預設值是什麼？