Anthropic 的 Claude Relations 負責人 Alex Albert 與 Multi-Agent 研究員 Erik Schluntz 進行了一場深度對談，探討如何打造更有效的 AI Agent。從 Claude 為何擅長 Agent 任務、Claude Code SDK 與 Skills 的實務應用，到 Workflow of Agents 與 Multi-Agent 的架構演進，以及 MCP 工具設計的最佳實踐，全面剖析了 AI Agent 開發的現狀與未來方向。

原影片連結：https://www.youtube.com/watch?v=uhJJgc-0iTQ

影片重點

• Claude 透過大量 RL 訓練成為優秀的 Agent，coding 能力是基礎技能，可遷移到各種任務
• Claude Code SDK 提供開箱即用的 Agent Loop，開發者只需專注自己的業務邏輯
• Skills 是 CLAUDE.md 的進化版，可以注入模板、腳本、圖片等資源，讓 Claude 瞬間具備特定專業能力
• Agent 已經在大多數需要高品質輸出的場景中超越了傳統 Workflow
• Workflows of Agents 是新趨勢：將 Workflow 中的每個步驟替換為一個完整的 Agent Loop
• Multi-Agent 讓多個 Claude 並行工作，用於搜尋、程式碼撰寫和 Test-time Compute
• MCP 工具設計應對應 UI 而非 API，減少模型的工具呼叫次數
• 未來 Agent 將結合 Computer Use 能力，自行驗證和測試產出

詳細內容

[00:18] 為什麼 Claude 擅長 Agent 任務

Alex 與 Erik 開場討論了 Claude 為何在 Agent 任務上表現出色。Erik 解釋，在訓練過程中，團隊讓 Claude 大量練習作為 Agent 的角色——給它開放性問題，讓它透過多步驟使用工具、探索環境，最終給出答案。透過在 coding、搜尋等多種環境中進行大量的強化學習（RL），Claude 累積了豐富的 Agent 經驗。

Alex 提到外界可能認為 Claude 只是 coding 很強，但 Erik 指出 coding 其實是一項非常基礎的 Agent 技能。一旦有了出色的 coding Agent，它就能透過撰寫程式碼來完成各種非程式相關的任務——例如透過 API 進行網頁搜尋、建立行程規劃等。團隊的策略是「先訓練最困難的技能，其他一切就會變得容易」。

[02:30] Code 作為通用加速器

Erik 舉了一個實際例子：他用 Claude 製作簡報圖表。對於簡單的圖，Claude 可以直接寫出 SVG；但當需要大量重複細節的複雜圖表時，Claude 會改為撰寫程式碼來生成 SVG，速度遠快於逐行撰寫。這展現了 coding 不只是寫程式，而是一種能讓 Agent 獲得「for loop」能力的加速工具——這種重複性操作的速度是人類透過滑鼠點擊無法比擬的。

[03:52] Claude Code SDK：開發者的 Agent 基礎架構

Erik 介紹了 Claude Code SDK 的核心價值。過去開發者要建構 Agent，需要從零開始打造——自行建構迴圈、工具、檔案互動和 MCP 整合。而 Claude Code SDK 已將這些全部封裝好，提供一個經過大量打磨和優化的核心 Agent Loop。

雖然名為「Claude Code」，但它本質上是一個通用型 Agent，只是最常被用於 coding。開發者可以用它作為 Agent 的核心，移除 coding 相關的部分，插入自己的 prompt 和工具——透過 MCP 加入自訂業務邏輯，就像把零件放入預製的骨架一樣。Erik 甚至用 Claude Code 來規劃約會行程，包括搜尋活動和餐廳推薦，完全不涉及程式碼。

[05:35] Skills：讓 Claude 瞬間習得新能力

Alex 提到從 CLAUDE.md 檔案演進而來的 Skills 功能。CLAUDE.md 是在專案中定義程式風格和目錄結構等資訊的設定檔，而 Skills 則更進一步——不只是指令文字，還可以包含 PowerPoint 模板、輔助腳本、圖片和其他資源。

Erik 用了一個精彩的比喻：這就像《駭客任務》中 Neo 被注入功夫知識後瞬間成為武術大師。當你給 Claude 一個「如何建立試算表」的 Skill，它就瞬間變成了能建立財務模型的銀行家。Skills 不只是說明書，更是裝備庫——就像電影中載入一整架武器和工具供角色使用。

[07:10] 從 Workflow 到 Agent 的演進

Alex 回顧了過去幾個月的變化。之前的做法是用 Workflow 將 prompt 串接起來，現在已經轉向以 Agent Loop 為主的架構。Erik 表示，Claude 已經變得非常擅長回應反饋和自我修正，Agent Loop 在大多數追求高品質輸出的場景中大幅超越了 Workflow。不過 Workflow 仍然適用於需要低延遲、讓 Claude 一次性給出最佳答案的場景。

更進一步的演進是「Workflows of Agents」——在過去的 Workflow 中，每個步驟可能只讓 Claude 嘗試一次（例如寫一條 SQL 查詢），如果失敗就會導致後續步驟出問題。現在每個步驟本身就是一個封閉的 Agent Loop：Claude 寫 SQL、執行、檢視結果、持續迭代直到確認正確，才進入下一步。

[09:10] Observability 的挑戰與簡單性原則

討論轉向 Agent 的可觀察性（Observability）。Erik 強調，隨著系統變得更加複雜，可觀察性會越來越困難。即使模型比一年前強大得多，也能支持更複雜的架構，但「簡單性仍然非常重要」。

Erik 建議：永遠從最簡單的方案開始，只在確實需要時才增加複雜度。先嘗試 single-shot，再試 Claude Code SDK 的簡單用法，只有在必要時才逐層增加複雜度——因為每一層複雜度都會讓可觀察性變得更困難。

[10:08] Multi-Agent：多個 Claude 並行協作

Erik 介紹了他目前的主要研究方向——Multi-Agent 系統。他區分了兩個概念：

• Workflows of Agents：Agent 依序運作，一個完成後將輸出傳給下一個
• Multi-Agent：多個 Agent 或多個 Claude 同時運作。例如一個 Parent Agent 將任務分配給五個 Sub-Agent 並行處理

Deep Research 產品就是 Multi-Agent 的實例：主要的 Orchestrator Agent 會建立多個 Sub-Agent 同時執行搜尋，讓使用者更快獲得結果。Claude Code 中也使用了 Sub-Agent——當某個子任務需要大量 token（例如搜尋某個 class 的實作），但結果只是很小的資訊時，可以在 Sub-Agent 中完成這項工作，保護主要 context 不被這些不必要的 token 佔據。

[12:20] Sub-Agent 作為工具呼叫

在技術實現上，Sub-Agent 對 Claude 來說就像一個工具（Tool）。Claude 將 prompt 作為參數傳遞給 Sub-Agent，Sub-Agent 去執行工作後回傳結果。Erik 透露他的研究正在訓練 Claude 成為更好的「管理者」——學會如何給出清晰的指令，確保從 Sub-Agent 獲得所需的結果。

有趣的是，Claude 初期會犯和新手主管一樣的錯誤：給出不完整或不清楚的指令，期望 Sub-Agent 擁有它實際並不具備的上下文。透過訓練，Claude 開始學會給 Sub-Agent 提供更詳盡的整體背景資訊，讓它們能更好地完成各自的工作。

[14:07] Multi-Agent 的應用場景與 Test-time Compute

Multi-Agent 的應用場景包括：

1. 搜尋與研究：並行搜尋大量資料來源
2. 程式碼開發：大量使用 Sub-Agent 處理子任務
3. 可並行化的任務：如果輸出有 10 個部分，可以分配給 10 個 Sub-Agent 同時處理
4. Test-time Compute：讓多個 Claude 同時研究同一個問題，就像一群人集思廣益，最終得到比單一 Agent 更好的答案

對於 Agent 的角色分化，Erik 認為兩種方式都有效：可以給多個 Agent 相同的任務看各自的答案，也可以讓不同 Agent 從不同角度切入同一問題。一個常見的做法是將大量工具（可能多達一兩百個）分配給不同的 Sub-Agent，讓主 Agent 只需知道要用哪一組工具，而 Sub-Agent 各自只需理解自己負責的 20 個左右的工具。

[15:53] Agent 常見的失敗模式

Erik 指出，和任何複雜系統一樣，Agent 系統最容易犯的錯誤就是過度建構。他見過過度設計的 Multi-Agent 系統花太多時間在 Agent 之間互相溝通，而沒有在主要任務上取得實際進展。他類比了人類組織：隨著公司規模擴大，溝通開銷增加，真正在做實事的比例反而下降。

[16:30] 開發者最佳實踐：工具設計哲學

Erik 提出了一個非常重要的工具設計原則：MCP 或工具應該與 UI 一一對應，而不是與 API 一一對應。因為模型本質上是這些工具的「使用者」，而非傳統程式。

他以 Slack 為例：如果你的 API 有三個獨立的 endpoint（載入對話、將 User ID 轉換為用戶名、將 Channel ID 轉換為頻道名），而你直接把這三個 API 做成三個工具，模型每次理解一則 Slack 訊息就需要三次工具呼叫。但使用者在 UI 上看到的是所有資訊一次性呈現。因此，工具設計應該模擬 UI 的體驗：一次性提供完整的資訊，盡量減少互動次數。

[17:50] Agent 的未來展望

Erik 預測在未來 6 到 12 個月，Agent 將從可驗證的領域（如軟體工程）開始變得更加普及。一個令人興奮的方向是讓 Agent 能自行驗證產出——例如用 Computer Use 寫完 Web App 後，自己打開來測試、找出 bug，而不需要使用者充當 QA 工程師。

Computer Use 也將打開許多目前 Agent 無法觸及的領域。例如在 Google Docs 中工作時，目前使用者需要在 Claude 和文件之間來回複製貼上，但有了 Computer Use，只要說「幫我整理這份 Google Doc」，Claude 就能直接在文件中捲動、點擊、編輯。這代表無論使用者在哪裡工作，Claude 都能陪伴在側。

我的想法

這場對談最讓我印象深刻的是 Erik 關於 MCP 工具設計的觀點：「工具應該對應 UI 而非 API」。這個觀點在實務開發中極具價值——很多開發者（包括我自己）的直覺反應是把現有的 REST API 直接包成 MCP Tool，但這其實是在強迫模型像程式一樣思考，而非像使用者一樣使用服務。

另一個值得深思的點是 Multi-Agent 的「管理者困境」。Claude 會犯新手主管的錯誤（給出不完整指令、假設 Sub-Agent 已有上下文），這不僅是技術挑戰，更反映了一個普遍的組織管理問題。隨著 Agent 系統規模擴大，如何控制溝通開銷、避免「開會比做事多」的困境，可能會成為 Agent 架構設計的核心課題。

最後，「Workflows of Agents」這個演進路徑非常務實。不是一步跳到完全自主的 Multi-Agent，而是先把 Workflow 中每個脆弱的 single-shot 步驟升級為有自我修正能力的 Agent Loop。這種漸進式的方法降低了複雜度，同時大幅提升了系統的可靠性。