Anthropic 替 Claude 加上做夢功能

Anthropic 為 Claude Managed Agents 加入 dreaming、outcomes 和 multiagent orchestration，讓代理能記憶、評分與分工。

說真的，這波更新很像在補作業。Anthropic 才在上個月推出 Claude Managed Agents，這週就把三個新功能端上來。重點不是炫技，而是把 agent 從「能跑」推到「能管、能評、能協作」。

這次加的三個東西很直白。dreaming 負責整理記憶，outcomes 負責打分，multiagent orchestration 負責分工。講白了，就是讓 Claude 不只會做事，還會回頭檢討、接受考核，然後找同事一起做。

Dreaming 像是幫 agent 做記憶整理

Anthropic 的 dreaming，核心就是回頭看。它會檢查過去的 sessions，找出重複出現的模式，再把有用的東西寫回記憶系統。你可以把它想成排程版的復盤工具，不是每做一步就學一次，而是定期整理一次。

這設計其實很務實。LLM 很會即興回答，但記憶很常亂掉。今天記住，明天忘記，後天又自己補故事。dreaming 的目的，就是把這種散掉的資訊重新收斂，讓下一輪執行更像真的有經驗。

更實用的是控制權。Anthropic 說，dreaming 可以自動更新記憶，也可以先給開發者看過再套用。這點很重要。很多團隊不是不想讓 agent 學習，而是不想讓它自己亂改行為。

• Dreaming 不是即時學習。
• 它會定期回看歷史 session。
• 它能自動更新，也能人工審核。
• Anthropic 把它列成 research preview。

這裡可以看出 Anthropic 的思路。它不是只想做一個會聊天的模型，而是想做一個會累積經驗的系統。對做客服、內部知識庫、或流程自動化的人來說，這種記憶整理比單次回答漂亮多少，更有價值。

“A separate grader evaluates the output against your criteria in its own context window, so it isn’t influenced by the agent’s reasoning.”

Outcomes 把模糊目標變成可測標準

Outcomes 這個功能，說白了就是把「你自己看著辦」變成「照這個規格打分」。Anthropic 讓開發者先寫 rubric，也就是成功標準，再交給獨立 grader 去評估結果。這種做法很像把 prompt 工程往評測工程推了一步。

我覺得這點比 dreaming 更接近產品需求。因為很多 agent 專案死掉，不是因為不會做，而是因為沒辦法穩定驗收。今天看起來對，明天又歪掉。沒有評分系統，團隊根本不知道是模型爛，還是 prompt 爛。

Anthropic 還特別把 grader 和 agent 的思考過程切開。grader 在自己的 context window 裡評分，不看 agent 的推理鏈。這樣比較不會被 agent 的長篇大論帶偏。講難聽一點，就是少一點嘴砲，多一點結果。

另外，outcomes 也支援 webhook。這代表你可以把 agent 丟出去跑，完成後再通知你。對做非同步流程的人來說，這比一直盯著 console 方便太多。尤其是內部工具、資料處理、報表產生這類工作，很適合這種模式。

• 先定 rubric，再讓 agent 跑。
• grader 和 agent 分開，降低互相干擾。
• 支援 webhook，適合非同步流程。
• 比起 demo，這更像正式驗收流程。

這邊的方向很明顯。Anthropic 想把 agent 開發，從「寫 prompt」拉到「設計評測」。這對台灣開發者很有感，因為很多團隊現在卡住的不是模型選哪個，而是怎麼驗證它真的有用。

Multiagent orchestration 讓工作真的能分工

如果說 dreaming 是記憶，outcomes 是考試，那 multiagent orchestration 就是開會分工。Anthropic 的設計是，主 agent 先拆解任務，再把子任務丟給不同專長的 subagents。每個 subagent 有自己的 model、prompt 和 tools。

這種架構很適合複雜工作。像事故排查、支援分析、程式碼偵錯，都不是單一路徑能解完。你要看 deploy history，要翻 error logs，要比對 metrics，還要查 support tickets。讓一個 agent 來回切換，常常只會越看越亂。

Anthropic 的做法是讓專家並行工作。主 agent 負責統整，子 agent 負責挖資料。它還提到 shared filesystem 和 persistent events。意思是大家能共用工作區，主 agent 也能中途回來看進度。這比一次性對話更像 workflow engine。

• 主 agent 負責拆解與統整。
• 子 agent 各自處理不同資料源。
• shared filesystem 讓工作成果能共用。
• persistent events 讓流程可中途回查。

Anthropic 還提到 Netflix 已經在用 Claude Managed Agents 做平台工作。這不代表每家公司都該照抄，但至少說明一件事：這套東西不是只給 demo 用，而是瞄準真的有流程壓力的團隊。

這次更新跟其他 agent 平台比起來怎樣

如果拿市場上的 agent 平台來看，Anthropic 這次走得很像「先把底層工具補齊」。OpenAI 的方向比較偏模型能力和工具呼叫。OpenAI Assistants 早就把檔案、工具、對話流程整合進去。Anthropic 則更明確地把記憶、評分、分工拆成三層。

這種拆法有好處，也有代價。好處是清楚。你知道哪個功能管記憶，哪個管驗收，哪個管協作。代價是系統會更複雜。你不是在養一個 agent，而是在養一整組 agent。這對小團隊來說，門檻不低。

如果看 OpenAI Agents、Google 的 agent 工具，或 LangChain 這類框架，大家都在往同一個方向走：讓 agent 不只是對話，而是能接流程、接評測、接多步驟任務。差別只在誰先把哪一塊做得比較完整。

我自己的判斷是，Anthropic 這次比較像在補生產環境缺口。它不是在跟你說 agent 多神，而是在說：你要上線，就得有記憶、要有評分、還要能分工。這三件事少一件，系統都很難穩。

• Anthropic：重視記憶、評分、協作三層。
• OpenAI：工具整合和模型生態較強。
• LangChain：彈性高，但要自己拼很多元件。
• 對小團隊來說，Anthropic 的整合度更省事。

如果你在做產品，差異會很直接。你要的是一個能 demo 的 agent，還是一個能每天跑、還能被驗收的系統？這次 Anthropic 明顯是把答案往後者推。

這代表 agent 開發開始走向工程化

Claude Managed Agents 的這波更新，透露出一個很現實的趨勢。大家已經不太滿足於「模型會回答」。現在更在意的是，它能不能記住、能不能評分、能不能跟別的 agent 協作。這些都不是聊天機器人的語言，而是工程的語言。

這也解釋了為什麼 Anthropic 要把功能拆得這麼細。dreaming 處理長期記憶，outcomes 處理驗收，multiagent orchestration 處理分工。這三個拼起來，才像一個能上線的系統。單靠一個大 prompt，真的撐不久。

更大的變化是，agent 開發開始像資料管線。你要管輸入、管中間狀態、管輸出、管回饋。這跟以前做 API 串接很像，只是現在多了一層 LLM 的不確定性。也因為這樣，評測和回饋機制會越來越重要。

我會建議台灣團隊先想清楚一件事：你的 agent 是要處理單一任務，還是長流程工作？如果是後者，那 dreaming 和 outcomes 這類功能就不是花俏配件，而是基本盤。少了它們，agent 很容易只停在展示階段。

接下來該看什麼

接下來我會盯兩件事。第一，dreaming 會不會從 research preview 變成更穩定的正式功能。第二，outcomes 和 multiagent orchestration 會不會被更多開發者拿去做真實工作流，而不是只留在產品簡報裡。

如果你現在就在做 Claude 上的 agent，我的建議很直接。先挑一個可量化任務，寫出 rubric，再試著把工作拆成兩到三個角色。不要一開始就做超大系統。先把評分和分工跑順，才知道哪裡真的有價值。

講白了，Anthropic 這次不是在賣夢想。它是在把 agent 變成一個能被管理的軟體系統。這條路很務實，也很難走。你如果正在做 AI 產品，現在就該想：你的團隊，準備好把 agent 當成系統來管了嗎？