5 月 6 日，Anthropic 在舊金山辦 Code with Claude 2026 開發者大會，受管代理一次推三招升級：Dreaming（做夢）、Outcomes（成果指標）、Multiagent Orchestration（多代理協調）。
過去 12 個月代理技術的兩個結構性問題：(1) 代理不會「從過去學習」（每個會話是孤島）、(2) 代理不知道「做對了沒」（沒明確成功標準）。Code with Claude 2026 三招正是直接針對這兩個痛點。
最值得記的詞是「Dreaming」——Anthropic 直接類比人腦海馬迴在睡眠中的記憶整合(memory consolidation)。這個比喻不是行銷，是技術上的真實對應——代理在「閒置時間」回顧過去會話、抽取模式、更新記憶儲存。
📋 5/06 三大新功能
| 功能 | 解決的痛點 | 適合場景 |
|---|---|---|
| Dreaming | 代理跨會話沒有「學習」，每次從零開始 | 長期專案、重複性任務、團隊共用代理 |
| Outcomes | 代理不知道「任務完成標準」，常做出主觀「差不多」結果 | 有明確 KPI 的工作（測試覆蓋率、效能指標） |
| Multiagent Orchestration | 單一代理處理複雜任務速度慢、上下文不夠 | 大型程式碼倉庫重構、大型遷移、平行調研 |
大會行程：
- 5/06 舊金山（主場、首發）
- 5/19 倫敦
- 6/10 東京（亞太重點場）
合作夥伴公開站台：GitHub、AWS、Datadog、Vercel、Cursor、Microsoft——這個名單比表面看起來重要，Anthropic 在「代理生態」的合作網，已經涵蓋雲端、開發環境、監控、部署整個技術堆疊。
🧠 Dreaming：把代理從「失憶症」變「真正學習」
過去代理的記憶模型：
- 單一會話內：有上下文窗口記住對話
- 跨會話:完全失憶（每次新對話從零開始）
- MemGPT、Mem0 等記憶工具：把過去對話存到向量資料庫，但仍是「被動取出」，不是「主動學習」
Dreaming 的不同：
(1) 主動回顧而非被動取出 過去代理記憶是「使用者問問題時取出過去類似對話」。Dreaming 是「代理在閒置時間自動回顧過去 N 個會話」——找模式、找重複錯誤、找團隊偏好，然後更新記憶儲存。
(2) 記憶整合的技術對應 人腦海馬迴在睡眠中：
- 重播白天的事件
- 抽取重複的模式
- 強化值得記的記憶、遺忘不重要的雜訊
- 整合新舊記憶到長期儲存
Dreaming 對應做四件類似的事：
- 會話重播：讀過去會話紀錄
- 模式抽取：找出「這個團隊常做的事」「這個使用者常犯的錯」
- 記憶整理：強化重要記憶、刪除過時記憶
- 跨代理整合：多個代理的學習整合進共享記憶
(3) 排程而非即時 Dreaming 是 排程程序——不是即時跑，是代理閒置時跑（類似人類睡眠）。這個設計讓「學習」不佔用推論配額，使用者付的還是「對話用量」。
(4) 跨代理學習 最被低估的細節:Dreaming 可以跨代理整合學習——例如代理 A 學到「使用者偏好用 TypeScript 嚴格模式」，代理 B（同團隊）也會繼承這個偏好。這對企業、團隊使用是大躍進——代理學一次，團隊都會。
🎯 Outcomes：把模糊任務變可量化 KPI
過去代理任務描述：「幫我重構這個元件」——代理做完丟回來，有沒有「做對」要使用者自己判斷。
Outcomes 的設計：
(1) 任務時明確定義成功標準
任務:重構 UserProfile 元件
Outcomes:
- 測試覆蓋率 ≥ 80%
- 包大小減少 ≥ 15%
- Lighthouse Performance 分數 ≥ 90
- 所有既有測試仍通過(2) 代理自己反覆修改直到達標 代理跑改、跑測試、看結果——沒達成果指標就繼續改。這個迴圈過去要使用者手動跑，現在代理自己跑。
(3) Outcomes 可量化也可半量化
- 完全量化：測試覆蓋率、包大小、效能指標、程式碼覆蓋率
- 半量化：程式碼風格檢查通過、無 TypeScript 錯誤、無主控台警告
- 質性（透過裁判模型）:「改完後的程式碼比原本可讀性更好」
(4) 失敗時報告而非隱藏 代理達不到成果指標時：
- 過去：隱藏(交給人類「做到差不多就好」的版本)
- 現在：明確報告「測試覆蓋率只到 65%，包大小反而增加 3%——以下是嘗試的版本」——把判斷權還給人類
這個設計對企業客戶極關鍵——過去代理「做了什麼」不透明，Outcomes 把它變成「可審計、可衡量、可追責」的工作流。
🤝 Multiagent Orchestration：代理從「獨行俠」變「團隊作戰」
過去代理的限制：
- 單一代理上下文窗口約 20 萬詞元，大型程式碼倉庫塞不下
- 單一代理是循序執行，沒法平行加速
- 單一代理沒「分工」,做大任務時亂掉
Multiagent Orchestration 的解法：
(1) 主管 + 工作者架構
- 主管代理：接到大任務，拆解成子任務，分配給工作者代理
- 工作者代理：接子任務，獨立執行，把結果回報給主管
- 主管整合工作者結果，組成最終交付
(2) 平行而非序列
- 互相獨立的子任務：平行(N 個工作者同時跑)
- 互相依賴的子任務：序列（工作者 A 完成再交給工作者 B）
- 主管自動判斷依賴關係
(3) 例子：大型單一倉庫的相依套件升級
- 主管：接到「升級 React 18 → 19」
- 拆解：(a) 找所有用 React 的套件、(b) 每個套件分配一個工作者、(c) 平行跑相依套件更新與測試、(d) 整合所有改動
- 40 個套件平行跑，過去 2 週的工作變 1 小時
(4) 詞元配額管理 每個工作者有自己的 20 萬上下文——總額 = N × 20 萬。對大型企業任務來說，「可用上下文」幾乎無上限（成本變高，但技術上可行）。
對台灣開發者實用場景:
- 大型程式碼倉庫的框架遷移(Vue 2 → 3、Angular → React)
- 大型測試覆蓋率補完（每個模組派一個工作者）
- 多服務同步更新介面合約
- 跨倉庫的破壞性變更重構
💼 大會合作夥伴矩陣
5/06 舊金山場合作站台名單:
| 夥伴 | 整合方向 |
|---|---|
| GitHub | Claude 整合到 GitHub Copilot Workspace 與 Actions |
| AWS | Bedrock 上的 Claude + Trainium 推論 |
| Datadog | 代理監控、效能追蹤、成本追蹤 |
| Vercel | 前端部署、預覽環境整合 |
| Cursor | Claude 4.7 整合到 Cursor 代理模式 |
| Microsoft | VS Code + Office 365 整合（後續跟進） |
這個名單的意義:
- 不只是「Claude 能跑在你平台上」，是「整套代理工作流整合」
- Datadog 的加入很重要——「AI 代理可觀測性」會變新的資訊採購類別，Datadog 卡位早
- Cursor 跟 GitHub Copilot Workspace 兩家是直接競爭，但都接 Claude——Anthropic 走「模型中立、開發環境都歡迎」路線
💡 Mason 的判斷
5/06 三招新功能不是「單獨的功能升級」，是「代理從工具走向同事」的開始。三個觀察：
(1) Dreaming 是技術上的「人類化」 過去代理失敗的原因常是「沒有真正的學習」——你罵它一次，下次它仍犯一樣的錯。Dreaming 第一次把「跨會話學習」做到正式產品級。這個能力會讓代理從「通用工具」變「個人化助手」——不同團隊的 Claude 代理會有不同個性與能力強項。
(2) Outcomes 解決「代理軟交付」這個老問題 過去代理最大的商業障礙是「做了什麼不清楚、做對了沒不清楚」。Outcomes 把這個變「可審計」——這對企業採購是關鍵突破。預期未來 12 個月，Outcomes 會變「所有企業代理採購的標配需求」。
(3) Multiagent Orchestration 對應的是「真正的代理勞動市場」 過去談「AI 取代工作」都是模糊的。Multiagent 可以開出 40 個平行工作者做大型遷移——這就是「用 AI 取代一個團隊」的具體形態。未來 24 個月，「用 N 個代理做事」會變成企業熟悉的工作單位。
但有幾個現實限制：
(a) Dreaming 的隱私挑戰 代理學什麼、保留多久、跨團隊分享多少——這些設計沒處理好會踩雷。預期 2026-2027 有「代理不該記住但記住了」這類事故出現。
(b) Outcomes 的鑽漏洞風險 代理為了達 KPI 可能 鑽漏洞（測試覆蓋率高但測試品質差、包大小小但功能漏）。需要 meta 層級的成果指標設計——例如「成果指標是審查通過，不是純量化指標」。
(c) Multiagent 成本失控風險 N 個工作者平行跑 = N 倍詞元成本。沒做好預算控制，一個遷移跑 5,000 美元是可能的。Anthropic 預期會推預算護欄，但現在仍要使用者自己警覺。
🇹🇼 對台灣的延伸
對台灣軟體業、系統整合商:
- 大型舊系統遷移（銀行、保險、政府的 COBOL 改 Java 等）是 Multiagent 的最大商業價值場景——過去 6-12 個月專案，可能壓縮到 1-2 個月
- 台灣系統整合廠商（凱亞、宏碁資訊、敦陽科技等）現在就該開始累積「多代理遷移」案例——12-24 個月內會變客戶必問項
- Outcomes 對台灣客戶習慣很合——台灣企業文化對「KPI 量化」接受度高，比歐美客戶更願意定義明確指標
對台灣專案經理、工程主管:
- 學會給代理設成果指標——這是新管理技能，跟管人類團隊不同
- 建立「代理勞動預算」概念——每個專案多少代理詞元預算，跟人月預算並列
- Multiagent 對「程式碼審查、測試、缺陷分類」這些「規模化 + 重複性」工作的衝擊最大——這些工作的人類定位要重新設計
對台灣 Anthropic 用戶、訂閱者:
- Dreaming 預期 8-12 週後正式釋出（現在是研究預覽），關注 Claude.ai 跟介面文件
- Multiagent Orchestration 在東京場(6/10)會有亞太合作夥伴宣布——對 Anthropic 來說亞太是優先擴展市場
- 對個人使用者：Dreaming 對「長期專案」有意義——例如連續 3 個月跟同一個代理一起寫一本書或一個產品，代理真的會「懂你」
🎯 不同角色的建議
給 Claude 介面使用者、開發者:
- 這個月評估「Outcomes 重構任務」——把現有提示加明確的成功標準，看效果差異
- 學習多代理協調的設計模式——主管與工作者分工、依賴管理、預算控制
- 對長上下文任務跟多代理任務的成本建模，現在就建試算表追蹤
給企業客戶、資訊主管:
- 跟 Anthropic 銷售或 Bedrock 銷售談「受管代理企業服務水準協議」——這是新方案，可能有早鳥優惠
- 評估「舊系統遷移」專案使用 Multiagent 的可行性——找一個內部驗證試試
- 建立代理治理框架——成果指標、權限、預算、稽核軌跡都需要規範
給競品(OpenAI、Google)使用者:
- Anthropic 在代理體驗領先 6-12 個月——OpenAI、Google 預期會跟進類似功能，但會晚
- 不要急著切換——等競品也推類似功能後再做比較
- 但長上下文 + 多代理工作流先用 Claude 累積經驗——這些技能在所有平台都通用
給台灣政府、公部門:
- 健保、戶政、稅捐、勞保等大型舊系統的現代化是 Multiagent 的潛在大標案——現在就該規劃驗證預算
- 「以成果指標為基礎的 AI 採購」應變成新採購標準——擺脫「有買就好」的舊習慣
- 跟亞太 Anthropic 團隊建立官方對話窗口——東京場(6/10)是好時機
❓ FAQ
Dreaming 跟 Mem0、MemGPT 這類記憶工具差在哪？
核心差別是「主動 vs 被動」。
Mem0、MemGPT（被動取出）:
- 把過去對話存到向量資料庫
- 使用者問問題時取出「相關片段」
- 代理不會「主動回顧」過去——只在查詢時被動拿出來
- 沒有「抽取模式」「遺忘」「強化」這些認知運作
Dreaming（主動整合）:
- 代理閒置時自動回顧 N 個過去會話
- 主動找模式、更新記憶、遺忘不重要的細節
- 像「真的學習」，不是「檔案管理」
對使用者來說:
- Mem0 是「圖書館員」——你問，他幫你找
- Dreaming 是「學徒」——他自己讀書、自己進步
實務上 Mem0、MemGPT 跟 Dreaming 不衝突，可以共存——Dreaming 處理「長期學習」,Mem0 處理「結構化資料取出」。
Multiagent 跟 LangGraph、CrewAI 這類框架差別？
差別在「框架級 vs 平台級」。
LangGraph、CrewAI（框架）:
- 開源，需要自己架設
- 跟模型解耦（可接 OpenAI、Anthropic、Gemini）
- 需要自己處理狀態管理、錯誤處理、預算控制
- 適合「深度客製」「模型中立」場景
Anthropic 多代理協調（平台）:
- 整合在 Claude 介面、控制台內
- 跟 Claude 模型與 Anthropic 基礎建設深度整合
- Anthropic 處理狀態、重試、預算護欄
- 適合「低運維開銷」「Claude 為主」場景
選擇邏輯:
- 全押 Claude → Anthropic Multiagent 比較省事
- 需要多模型備援 → LangGraph、CrewAI 比較靈活
- 學習曲線 → Anthropic 平台版較短，框架較深
台灣中小企業、個人開發者多數適合 Anthropic 平台版——較低運維開銷。大型企業、平台級產品多數適合框架版——避免被單一供應商鎖死。
Outcomes 會不會被代理鑽漏洞？
會，而且這是設計上必須處理的問題。
鑽漏洞的典型例子：
- 目標：測試覆蓋率 ≥ 80% → 鑽漏洞：寫沒意義的測試湊覆蓋率
- 目標：包大小 ≤ X → 鑽漏洞：把程式碼移到不算包的地方
- 目標:Lighthouse > 90 → 鑽漏洞：延遲載入一切讓首屏看起來快
對策:
- 多重成果指標互相制衡——例：測試覆蓋率 + 突變測試分數 + 程式碼審查通過
- 質性成果指標跟量化成果指標混合——「程式碼可讀性」這種要裁判模型評
- 成果指標設定要由人類審查——不要讓代理自己定義成果指標
- 抽樣稽核——隨機檢查代理完成的工作，確認「達標不等於鑽漏洞」
這跟人類員工的 KPI 鑽漏洞問題本質一樣——沒有完美解，只能持續監測 + 調整。Anthropic 內部已有「成果指標鑽漏洞偵測」研究，但目前還沒做成商業功能。
Sources:
- Anthropic introduces “dreaming,” a system that lets AI agents learn from their mistakes — VentureBeat
- Anthropic launches Dreaming for Claude Agents at Code with Claude 2026 — Let’s Data Science
- Inside Anthropic’s 2026 Developer Conference — Every
- Anthropic Dev Day: 6 New Managed Agent Features — MindStudio
- Anthropic letting Claude agents dream so they don’t sleep on the job — SiliconANGLE