6 倍。

Harvey——一家用 AI 處理法律文件的公司——在 Managed Agents 上啟用了一個叫 Dreaming 的功能。他們的 agent 本來每次碰到特定檔案格式都會卡住，換個 session 又忘記上次怎麼繞過去的。啟用 Dreaming 之後，agent 自己記住了 workaround，任務完成率直接翻了六倍。

這不是 prompt 變強了，也不是模型換代了。是 agent 學會從自己的失敗裡萃取經驗。

2026 年 5 月 6 日，Anthropic 在舊金山的 Code w/ Claude 開發者大會上一口氣丟出三個新功能：Dreaming、Outcomes、Multi-agent Orchestration。如果你之前跟著基礎篇設定好了 Managed Agents，這三個功能是讓它從「能跑」變成「能自己變強」的關鍵升級。

Dreaming：讓 agent 在背景「做夢」

你睡覺的時候，大腦在幹嘛？

神經科學有個詞叫「記憶鞏固」——白天的經驗在睡眠期間被重新播放、篩選、壓縮，重要的存進長期記憶，不重要的丟掉。你不會記得今天午餐第三口飯的味道，但你會記得第一次 deploy 到 production 然後服務炸了的那個下午。

Dreaming 做的事情一模一樣，只是對象換成了 AI agent。

它是一個排程背景程序。你設定好之後，Claude 會在 agent 閒置時自動回頭檢視過去的 sessions——哪些任務成功了、哪些失敗了、失敗的 pattern 是什麼、成功的捷徑長什麼樣。然後它把這些發現整理成一份策展過的記憶庫（curated memory store），下次 agent 醒來工作的時候自動載入。

技術層面怎麼運作

Dreaming 不是讓 agent 把所有 session log 塞進 context window——那樣 token 爆炸，而且噪訊太多。它的流程比較像這樣：

  1. 回顧：排程觸發後，一個獨立的 Claude 實例讀取過去 N 個 sessions 的執行紀錄
  2. 萃取：從失敗的 sessions 裡找出重複出現的問題模式，從成功的 sessions 裡找出有效的解法
  3. 策展：把萃取結果壓縮成結構化的記憶條目——不是原始 log，是「遇到 X 問題時用 Y 方法」的精煉知識
  4. 載入：下次 agent 開工時，這些記憶條目被注入 context，agent 直接帶著經驗上場

等等，這跟 CLAUDE.md 有什麼不同？

差別在於 CLAUDE.md 是你寫的，Dreaming 記憶是 agent 自己從實戰中萃取的。你寫的規則是「不要用 rm -rf」，agent 自己學到的是「這個客戶的 PDF 檔頭有非標準 BOM，要先 strip 再解析」。前者是通用知識，後者是特定任務的踩坑經驗——你根本不會知道要寫這條規則，直到 agent 自己撞上去。

Harvey 的案例

Harvey 是最早採用 Dreaming 的企業用戶之一。他們的 Managed Agents 負責處理大量法律文件——合約審閱、條款比對、合規檢查。問題是法律文件的格式千奇百怪：有的 PDF 是掃描檔、有的 Word 文件用了自訂字型、有的 Excel 表格裡混著嵌入式圖片。

每次 agent 碰到新的格式怪癖，它會花時間找出 workaround。但下個 session 開始時，這個經驗就消失了——又要重新踩一次坑。

啟用 Dreaming 之後，agent 把「.docx 檔案如果包含 ActiveX 控制項要先 sanitize」「這家事務所的 PDF 是 PDF/A-1b 標準，用標準解析器會丟失 annotation」這類 pattern 記進記憶庫。內部測試結果：任務完成率提升約 6 倍。

六倍不是模型變聰明了。是同樣的模型，但不再每次都從零開始。

Outcomes：用評分標準讓 agent 自我修正

你寫了一個 prompt，agent 跑完了，輸出看起來… 還行？但「還行」到底是 70 分還是 90 分？你說不準，agent 也說不準。

Outcomes 解決的就是這個問題。它在 5 月 6 日進入公開測試。

概念很簡單。你曾經改過作文嗎？不是寫作文，是改作文。老師手上有一份評分標準：結構佔 20%、論點佔 30%、文法佔 20%、創意佔 30%。學生交卷，老師對著標準逐項打分，不及格的打回去重寫。

Outcomes 的架構一模一樣：

  1. 你寫 rubric：用自然語言描述「成功長什麼樣」。不是 prompt，是評分標準——比如「輸出必須包含完整的錯誤處理」「程式碼必須通過所有測試」「報告必須引用至少三個原始資料來源」
  2. agent 執行任務：跟平常一樣跑
  3. grader 評分：一個獨立的 Claude 實例（不是執行任務的那個）拿著你的 rubric 逐項檢查 agent 的輸出。它有自己的 context window，不受 agent 的偏見影響
  4. 不及格就重來：grader 指出哪些項目沒過、具體要改什麼，agent 拿著反饋再跑一輪
  5. 循環直到通過：或者達到你設定的最大重試次數

這件事有趣的地方在於：grader 和 agent 是兩個不同的 Claude 實例。agent 可能覺得自己做得不錯，但 grader 用你的標準一看——「你漏了邊界條件的測試」。這種分離很重要，因為自我評估有盲點，讓另一個實例用明確標準來判定，準確度高很多。

實際效果

Anthropic 的內部測試和早期採用者的數據顯示，使用 Outcomes 比單純用 prompt 指令，任務成功率平均提升 10 個百分點。

10 個百分點聽起來不多？換個角度想。如果你的 agent 每天跑 100 個任務，成功率從 75% 提升到 85%，等於每天多搞定 10 個任務。一個月多 300 個。而你只是多寫了一份 rubric。

Rubric 怎麼寫

Rubric 不是 prompt engineering——它不是在教 agent 怎麼做，是在定義什麼算「做好了」。好的 rubric 長這樣：

1
2
3
4
5
6
成功標準：
1. 生成的程式碼必須通過所有現有測試（零失敗）
2. 新增功能必須有對應的單元測試，覆蓋率 > 80%
3. 不得引入新的 lint 警告
4. commit message 必須符合 conventional commits 格式
5. 如果修改了 API 介面，必須更新對應的文件

關鍵在於每一條都是可驗證的——grader 能明確判定「過」或「沒過」，不是「程式碼品質要好」這種模糊標準。

Multi-agent Orchestration：一個主管帶一群工程師

你有一個複雜任務，拆成五個子任務。以前你要自己拆、自己分配、自己追進度。現在可以讓一個 lead agent 來做這件事。

Multi-agent Orchestration 讓 Managed Agents 具備「主管」能力：

  • 任務拆解：lead agent 分析你的需求，判斷需要幾個子任務、每個子任務的範圍
  • 分配執行：每個子任務派給一個獨立的 sub-agent，並行跑
  • 結果彙整：sub-agents 完成後，lead agent 收集所有結果，合併輸出

這跟你在公司裡看到的沒什麼不同。工程主管拿到一個大 feature，拆成五張 ticket，分配給五個工程師，每天 standup 追進度，最後 merge 成一個 release。差別只是主管和工程師都是 Claude。

什麼時候該用 Multi-agent？當你的任務有明顯的平行性——比如「同時分析五個不同市場的數據」、「同時把十份文件翻譯成不同語言」、「同時在五個不同的 repo 裡搜尋某個 pattern」。如果任務是線性的（B 依賴 A 的結果），single agent 就夠了。

三個功能怎麼搭配

最強的組合是三個一起用：

Dreaming 讓 agent 帶著歷史經驗上場，不從零開始。Outcomes 確保每次輸出都有品質保證，不合格就重做。Multi-agent 讓複雜任務可以拆開並行，不用排隊等。

一個實際的場景：你的 Managed Agent 負責每天生成一份市場研究報告。

  1. Lead agent 收到任務，拆成「蒐集數據」「分析趨勢」「撰寫摘要」「格式化輸出」四個子任務（Multi-agent）
  2. 每個 sub-agent 帶著 Dreaming 記憶上場——記得上次蒐集數據時哪個 API 回傳格式變了、記得分析趨勢時哪個指標的計算方式要調整
  3. 最終報告交給 grader，用 rubric 檢查「數據來源是否都有引用」「趨勢分析是否包含風險評估」「格式是否符合模板」（Outcomes）
  4. 不及格的部分重做，直到全部通過

這整套跑完，你只定義了一份 rubric 和一個任務描述。剩下的是 agent 自己搞定的。

接下來學什麼

如果你還沒設定過 Managed Agents，先回去看基礎篇。

設定好之後，建議的學習路徑：

  1. 先開 Outcomes——寫一份簡單的 rubric，觀察 grader 怎麼評分、agent 怎麼修正。這是最快看到效果的功能
  2. 再開 Dreaming——讓 agent 跑幾天累積 session 紀錄，然後觀察記憶庫裡萃取出什麼。第一週的效果可能不明顯，但隨著記憶累積，你會開始注意到 agent 不再重複犯同樣的錯
  3. 最後試 Multi-agent——等你對單一 agent 的行為夠熟了，再引入多 agent 協作。一次管太多 agent 比一次管太多工程師還混亂

背後就兩條線：一條是「agent 的輸出品質怎麼保證」（Outcomes），另一條是「agent 怎麼隨時間變強」（Dreaming）。Multi-agent 是規模化的手段，但規模化的前提是單一 agent 先夠可靠。

先把一個 agent 調到你滿意，再複製。

參考來源：Anthropic is letting Claude agents ‘dream’ so they don’t sleep on the job — SiliconANGLE
參考來源：Code w/ Claude 2026 — Anthropic
參考來源：Claude Managed Agents Dreaming Explained — BuildFastWithAI