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

🧑‍🏫 這段是 Claude 官方介紹 Dreaming 的後半部。agent 是會自己分好幾個步驟把事情做完的 AI 助手，Dreaming 就是讓它在背景把累積的記憶查核過、補齊、整理好。如果你用 AI 常遇到開新對話就忘記，或記憶越積越亂，這段在講官方打算怎麼解決。

• 14:22 memory store 需要檢查過時資訊、合併重複內容，Dreaming 就是用來處理這件事
  ↳ memory store 是 agent 存放和讀取記憶的地方。用久了會堆滿過時資料和重複內容，就像越寫越亂的筆記本。Dreaming 就是專門來整理它的功能。
• 14:22 Dreaming 是非同步執行的批次流程，可以透過 API 或 console 啟動，背後是一套新做的 multi-agent harness
  ↳ Dreaming 是非同步的批次作業：丟一批工作給它在背景跑，不用守著等結果。用 API（程式呼叫）或 console（網頁後台）就能啟動。背後是一套多個 agent 分工合作的新架構，叫 harness。
• 14:22 輸入要指定一個 memory store，再加上一組你認為能補充這個 memory store 的對話紀錄（transcripts）
  ↳ 你要給它兩樣東西：一個要整理的 memory store，加上一些過去的對話紀錄（transcripts）。這些紀錄是用來補充記憶的素材。
• 14:52 它會逐一看過每個 session，做事實查核，並補上日期、特定識別碼等細節，同時整理檔案、修掉重複
  ↳ 它會一場一場看過去的 session（每一次獨立的 agent 對話），核對事實，補上日期、編號這類細節，同時整理檔案、刪掉重複的內容。
• 14:52 最後產出 output memory store，之後掛到新的 session 上，希望能讓資訊檢索更有效率，agent 也更聰明
  ↳ 整理完會產出一份新的 memory store。之後開新對話時把它掛上去，agent 找資料會更快，回答也更到位。
• 15:25 開始使用前要先建立 dream job；示範用的模型字幕寫作 Claude Opus 47，也可以選 Sonnet 46，依想要的品質和 token 成本決定
  ↳ 開始前要先建立 dream job，也就是一次整理任務。示範用 Opus（字幕寫作 47），也可以選 Sonnet 46。品質越高，花的 token（AI 的計費單位）越多。
• 15:55 dream job 有兩個必要輸入：要整理的 memory store，以及一串 session ID
  ↳ 建 dream job 一定要給兩樣：要整理的 memory store，和一串 session ID（每場對話的編號），讓它知道要讀哪些對話。
• 15:55 要處理幾個 session 由你決定，例如每天跑一次、一次 10 或 20 個，最多到約 100 個，官方也在研究擴充到更多
  ↳ 一次處理幾場對話由你決定，例如每天跑一次、每次 10～20 場。目前上限大約 100 場，官方說正在研究放寬。
• 15:55 可以另外給額外指示（additional instructions）；系統本身有一份會做很多事的預設 prompt
  ↳ 你可以加上自己的額外指示。不加也沒關係，系統內建的預設 prompt（給 AI 的工作說明）本身就會做很多整理。
• 16:26 指示的例子：在很講究細節的領域，要求它特別補齊某些細節；或要求它把 memory store 整理成特定結構
  ↳ 例如你的工作很講究細節，可以要求它一定要補齊某些資訊；也可以指定記憶要照某種結構分類整理。
• 16:26 執行建立指令後會拿到一個 dream ID
  ↳ 下完建立指令，系統會給你一個 dream ID，就像取件單號，之後查進度、拿結果都靠它。
• 16:56 在 console 的 Managed Agents → Dreams 可以看到 dream job，狀態一開始是 pending，不久就會開始執行
  ↳ 在 console 的 Managed Agents（Claude 代管 agent 的服務）→ Dreams 頁面可以看到任務。一開始顯示 pending（排隊中），很快就會開始跑。
• 16:56 job 狀態在 console 和 API 都能查；console 會顯示輸入的 memory store 和 token 數
  ↳ 任務狀態在網頁後台或用 API 都查得到。後台還會列出這次用的是哪個 memory store，以及已經花了多少 token。
• 16:56 依資料大小或 transcript 數量不同，一個 dream job 可能要幾分鐘到幾小時
  ↳ 資料越大、對話紀錄越多，就跑越久。短的幾分鐘，長的可能要好幾個小時。
• 17:26 非同步的好處是：這種工作不該在 agents 正在工作時即時跑
  ↳ 這種整理不需要馬上有結果，所以放在背景跑，不必擠在 agent 正在幫你做事的時候同時進行。
• 17:26 執行過程中 token 數會持續更新，方便追蹤進度
  ↳ 執行中 token 數會一直往上跳，看數字變化就知道它還在做事、大概做到哪了。
• 17:26 Dreaming 直接建立在 Managed Agents 的 primitives 上，dream job 本身也是一個 session，可以點進去看它在做什麼
  ↳ Dreaming 是用 Managed Agents 原有的基本元件（primitives）做出來的，所以一次 dream job 本身也是一場 session，可以點進去看過程。
• 17:56 能看到 dream 的 session 內容，觀察性（observability）很好，方便診斷問題，也看得到給它的 prompt
  ↳ 能看到它內部在做什麼，這叫 observability（可觀察性）。出問題時比較好追原因，也看得到系統給它的指示原文。
• 17:56 harness 底層會啟動 subagents 去看所有 transcripts，每個 subagent 都有 system prompt 告訴它要做什麼
  ↳ 底層會派出多個 subagent（子助手）去讀所有對話紀錄。每個子助手都有 system prompt，也就是事先寫好的任務說明，告訴它該做什麼。
• 17:56 orchestrator 只負責確保所有 agents 都在跑，並依序把它們啟動
  ↳ orchestrator 是總指揮，自己不讀內容，只負責依序把子助手叫起來，並確認大家都有在跑。
• 18:58 過程不會破壞原資料：輸入的 memory store 完全不會被動到，系統會先複製一份成 output memory store，所有修改都寫在新的那份
  ↳ 原本的 memory store 完全不會被動到。系統會先複製一份，所有修改都寫在複本上，就算改壞了，原檔也還在。
• 18:58 這次示範大約跑了一分鐘左右，實際時間看 job 跑多快
  ↳ 這次示範大約一分鐘就跑完，實際要多久看任務大小。
• 19:47 用程式執行時，有 API 可以查詢 dream job 的狀態，並輪詢（poll）直到完成
  ↳ 用程式操作的話，可以透過 API 每隔一段時間問一次「好了沒」，這叫 poll（輪詢），一直問到顯示完成為止。
• 19:47 完成後，console 會顯示這次 Dreaming 改了什麼的 diff
  ↳ 跑完後，console 會用 diff（前後對照）列出新增了什麼、改了什麼，一眼就看得出差別。
• 19:47 Dreaming 建了一個 index 檔，用 slug 對應各個記憶檔，讓未來的 agent 先看索引就知道要找什麼，比大範圍 grep 更有效率
  ↳ 它建了一個索引檔（index），用 slug（簡短代號）對應每個記憶檔，像書的目錄。agent 先看目錄就知道去哪找，不必用 grep（全文搜尋關鍵字）整批翻。
• 20:17 它還補上前幾個 session 沒有的資訊，例如建立 event logistics 檔，記錄 Code with Claude 的完整議程、人名和第二天的時程
  ↳ 它也補上前幾場對話沒整理到的資訊，例如新建一個活動行程檔，記下 Code with Claude 活動的完整議程、相關人名和第二天的時程。
• 20:50 它重新整理了先前 session 建立的記憶檔格式，加上 slug、活動描述、額外 metadata 與更多細節
  ↳ 前面對話留下的記憶檔也被重新整理格式，加上代號、活動描述、metadata（描述資料本身的資訊，例如類型、日期）和更多細節。
• 20:50 講者表示，資訊多通常真的有助於未來的 session：agent 做事當下很難預測以後需要什麼，所以多記一點比較好
  ↳ 講者認為記多一點通常有幫助：agent 做事的當下猜不到以後會用到什麼，先留著比較保險。
• 20:50 不再需要的內容，之後隨時可以再用 Dreaming 刪掉
  ↳ 記太多也不用擔心，之後哪些用不到，可以再跑一次 Dreaming 刪掉。
• 21:21 可以直接打開 output memory store 查看檔案；如果需要人工審查（human in the loop），人可以檢查 harness 有沒有出錯
  ↳ 新的 memory store 可以直接打開看檔案。如果需要 human in the loop（由人把關），就由人檢查它有沒有整理錯。
• 21:56 架構圖：multi-agent harness，由 orchestrator 負責啟動 subagents，每個輸入 session 各配一個 subagent
  ↳ 架構圖：orchestrator 當總指揮，每一場輸入的對話各派一個子助手負責，一對一處理。
• 21:56 這樣設計是希望 Dreaming 本身就做到完整覆蓋（exhaustive），確保 Claude 看過所有資訊、不漏掉任何東西
  ↳ 一場對話配一個子助手，是為了做到 exhaustive（完整覆蓋）：每份紀錄都一定有人讀過，不會漏掉。
• 22:26 完成後，用 dream ID 取回 dream 資源，再從 JSON 中拿到 output memory store 的 ID
  ↳ 跑完後用 dream ID 把結果抓回來，再從回傳的 JSON（一種結構化的資料格式）裡找到新 memory store 的 ID。
• 22:57 建立新的 session 並掛上 Dreaming 產出的 output memory store，重做先前的測試
  ↳ 接著開一場新的 session，掛上整理好的 memory store，把之前問過的測試題再問一次，比較前後差別。
• 23:40 測試問題：我參加了哪些場次、手上有哪些資源連結、我標記了哪些待辦（follow-ups）
  ↳ 測試題有三個：我參加了哪些場次？我手上有哪些資源連結？我記下了哪些待辦？
• 23:40 從 console 可以看到 agent 讀到 Dreaming 建立的 index 和 event logistics，而且先讀 index，再直接去讀 sessions 檔
  ↳ 從 console 看得到，agent 先讀了索引檔和活動行程檔，接著直接打開記錄場次的檔案，沒有東翻西找。
• 24:43 這次的回答資訊多很多：參加場次的摘要、第二天所有場次的時間、資源連結，顯示 Dreaming 能充實跨 session 傳遞的資訊
  ↳ 這次回答豐富很多：有參加場次的摘要、第二天所有場次的時間和資源連結。可見整理過的記憶能讓新對話接收到更多資訊。
• 25:13 如果滿意 output memory store，可以選擇把舊的 memory store 淘汰（retire），不會影響先前的 session，也能讓組織內的 memory store 數量維持在合理範圍
  ↳ 滿意新版的話，可以把舊的 memory store 停用（retire）。以前的對話不受影響，也能避免組織裡的記憶庫越積越多。
• 25:43 三層可組合的架構之一：session 是一個獨立執行的 agent 實例，通常是單一對話串，而且通常是短暫的（ephemeral）
  ↳ 整體分成三層。第一層是 session：一次獨立的 agent 對話，通常就是一串聊天，而且是 ephemeral，也就是用完就結束、不會保留下來。
• 25:43 第二層 memory store 補強 session，讓資訊能在多個 session 之間串連
  ↳ 第二層是 memory store：替 session 補上記憶，讓這次聊過的東西，下次對話也接得上。
• 25:43 第三層 Dreaming 持續整理、充實、改善 memory store，讓 session 數和資訊量變多時，記憶仍然好管理、不會爆量，並檢查過時資訊
  ↳ 第三層是 Dreaming：持續整理、補充、修正 memory store，讓對話和資料變多時也不會爆量失控，同時抓出過時的資訊。
• 26:13 觀眾問 token 用量：因為設計上要完整覆蓋，預期會用很多 token
  ↳ 有觀眾問會不會很花 token，答案是會。它的設計就是每份紀錄都要讀完，用量自然大。
• 26:44 因為大部分處理是 agentic 的，多數 token 會被快取，預期大多數 dream session 的 cache hit rate 約 95%
  ↳ 不過大部分工作是 agent 自己反覆操作，多數 token 會被快取（重複的內容不用重新計算）。預期 cache hit rate（快取命中率）大約 95%。
• 26:44 官方在研究更便宜的方式，例如比照 batch API，安排在不同時段執行，提供 50% 折扣
  ↳ 官方也在研究更便宜的做法，例如像 batch API（不求即時的批次呼叫）那樣，排到其他時段跑，換取 50% 折扣。
• 26:44 其他控制 token 用量的方法：換模型、調整 prompt，以及一般性的 token 預算控管
  ↳ 其他控制 token 用量的方法：換成較便宜的模型、調整 prompt，以及一般的 token 預算控管。
• 27:15 總結：agent 的共同難題是怎麼跨 session 記住資訊，memory 是解決的第一步，讓 agent 有地方寫入和讀取資訊
  ↳ 總結：agent 的共同難題是換一場對話就忘記。memory 是第一步，先給 agent 一個能寫下資訊、之後再讀回來的地方。
• 27:45 但 memory store 會無限制成長、變得雜亂、資訊過時；Dreaming 用另一組專門改善 memory store 的 agents 來緩解這個問題
  ↳ 但記憶庫會無限長大、變亂、過時。Dreaming 就是另外派一組專門整理記憶的 agent，來減輕這個問題。

講者表示，大多數 dream session 預期的 cache hit rate 大約是多少？