Claude Code 推出了全新的實驗性功能「Agent Teams」，讓多個 AI 代理能夠在同一個程式碼庫上即時協作。不同於傳統的 Sub Agents 只能各自獨立工作，Agent Teams 的代理之間可以真正溝通協調、共享任務清單，實現前端、後端、資料庫代理之間的無縫合作。本影片深入介紹了 Agent Teams 的設定方式、與 Sub Agents 的差異、目前的限制，以及一個能讓 Agent Teams 更穩定的自訂 Skill 模板。

---

原影片連結：https://www.youtube.com/watch?v=-1K_ZWDKpU0

影片重點

• Agent Teams 是 Claude Code 的新實驗性功能，支援多個 AI 代理即時協作
• 主代理（Lead Agent）會根據請求自動決定團隊組成，並建立共享任務清單
• 代理之間可以真正溝通，例如「等我完成這部分你再開始那部分」
• 需要安裝 Tmux 或 iTerm 2 才能看到分割畫面的即時工作狀態
• Agent Teams 與 Sub Agents 的核心差異：協作（Collaboration）vs 隔離（Isolation）
• Sub Agents 適合研究任務（Token 用量低），Agent Teams 適合實作任務（需要協調）
• Agent Teams 的 Token 用量大約是一般用法的 2-4 倍
• Anthropic 曾用 16 個代理協作，以 $20,000 的 API 成本打造了一個完整的 C 編譯器
• 目前 Agent Teams 存在穩定性問題：有時需要非常具體的指令才能正確建立團隊
• 作者提供了一個「Contract First Spawning」的 Skill 模板，可顯著提升 Agent Teams 的可靠性

詳細內容

00:00 Agent Teams 功能展示

影片一開始展示了四個 Claude Code 實例同時運作的畫面，這些代理共同對程式碼庫進行 Code Review。左側是主代理（Lead Agent），它即時啟動了三個 Tmux 終端機，分別建立了安全性審查、程式碼品質審查和文件審查三個代理。

這個功能的關鍵創新在於兩點：第一，主代理會根據使用者的請求自動決定要組建什麼樣的團隊；第二，所有代理在底層共享同一份任務清單，這讓它們能夠真正協調工作，遠遠超越了傳統的 Sub Agents 模式。代理之間能夠互相溝通，例如「讓我先完成這部分，你再處理那部分」，這種協調能力讓平行代理的概念被推到了一個新的高度。

02:30 Anthropic 的 C 編譯器案例

Anthropic 在官方文章中展示了 Agent Teams 的極限能力——他們用 16 個代理同時協作，打造了一個完整的 C 編譯器。如果請一個開發團隊來做這件事，成本可能高達數十萬美元，但 Agent Teams 只花了約 $20,000 的 API 費用。

雖然這個金額聽起來仍然很高，但這也凸顯了 Agent Teams 的一個重要特性：它非常消耗 Token。不過，Anthropic 強調這種級別的任務是單一代理無論如何都無法完成的，即使使用最強的 Opus 4.6 模型也不行。它們透過一個循環流程，讓代理們寫了數十萬行程式碼才完成。

03:40 如何設定 Agent Teams

設定 Agent Teams 的步驟相當簡單：

1. 啟用實驗性功能：在環境變數中設定，或者在 settings.json 中加入 experimental agent teams 的設定。這個設定可以放在全域的 .claude 層級，也可以放在專案的 .claude 目錄中，讓你只對特定專案啟用。
2. 安裝 Tmux 或 iTerm 2：這兩個終端應用程式支援分割畫面模式，讓你能即時看到所有代理的工作狀態。作者推薦使用 Tmux。Windows 使用者需要先安裝 WSL。
3. 開始使用：設定完成後，只要在 Claude Code 中告訴它你想使用 Agent Team 功能，Claude 就會知道你的意思。例如：「創建一個 Agent Team 來審查我的程式碼庫，一個代理負責安全性，一個負責程式碼品質，一個負責文件。」

06:10 Agent Teams 即時運作過程

當主代理接收到請求後，它會先進行分析、決定團隊組成，然後在 Tmux 中一個接一個地啟動代理。每個代理都會收到包含其角色描述的 Prompt，以及共享任務清單的存取權限。

在運作過程中，使用者可以用 Ctrl+B 加方向鍵在不同的 Tmux 終端之間切換，與任何一個代理互動，詢問它當前的工作狀態或與其他代理的協作情況。也可以向主代理詢問整體任務進度。所有代理完成後，主代理會自動關閉那些終端，使用者回到單一畫面繼續工作。

不過，作者坦言目前代理之間的協作可見性不足——很難直觀地看到代理們是如何互相溝通的，大多時候只能信任它們確實在協作。

08:30 Agent Teams vs Sub Agents

這是影片中最重要的技術比較環節：

Sub Agents（子代理） 的核心概念是「Context Isolation（上下文隔離）」。當你將一個可能耗費數萬甚至數十萬 Token 的任務交給 Sub Agent 時，主代理只會收到一個摘要回來。這樣做的好處是保護了主代理的 Context——而 Context 是 AI 編程助手最珍貴的資源。但缺點是 Sub Agents 之間完全無法協調，整個過程對主代理來說是個黑盒子。

因此，Sub Agents 最適合用於「研究型任務」，例如分析程式碼庫或搜尋網頁——因為我們只關心最終的研究結果。如果讓 Sub Agent 去寫程式碼，主代理會失去對實作細節的掌握。

Agent Teams（代理團隊） 則提供了真正的「Peer-to-Peer Coordination（點對點協調）」。代理之間共享任務清單、互相更新進度、互相溝通。例如，後端代理修改了 API Endpoint 後，可以通知前端代理更新對應的元件。在過去使用 Sub Agents 時，這種跨代理的變更經常導致 Bug，因為它們互不知情。

但 Agent Teams 的代價是 Token 用量顯著增加——大約是一般使用或 Sub Agents 的 2-4 倍，因為維持任務清單和代理間通訊需要額外的 Token。

簡單的經驗法則：Sub Agents 用於研究，Agent Teams 用於實作。一個常見的工作流程是：先用 Sub Agents 研究和分析程式碼庫，形成計畫，再將計畫交給 Agent Team 來執行。

12:20 Agent Teams 目前的兩大問題

問題一：指令必須非常具體。 如果只是簡單地說「用 Agent Team 做這件事」，Claude 有時會產生幻覺——建立奇怪的團隊組合，或無法正確處理 Tmux 終端。你需要明確告訴它要幾個代理、每個代理的職責是什麼。

問題二：真正的平行執行有時會出問題。 作者舉了一個例子：資料庫代理和後端代理同時啟動，資料庫代理還在定義 Schema 時，後端代理已經快完成了——結果後端基於完全錯誤的 Schema 建構。雖然代理間的通訊機制最終讓它們自我修正了，但這浪費了大量 Token。更好的做法是讓資料庫代理先完成，再啟動後端代理。

13:30 Contract First Spawning 策略

為了解決上述問題，作者開發了一個自訂 Skill，核心策略叫做「Contract First Spawning（合約優先生成）」。

這個策略的運作方式是：

1. 給 Claude Code 一份計畫（可以是透過 Sub Agent 研究產生的）
2. Skill 中的指令會引導 Claude 判斷最佳的團隊組成
3. 不是所有代理同時啟動，而是先建立「合約鏈」——例如先讓資料庫代理啟動並定義 Schema
4. 資料庫代理完成「合約」後（不需要全部做完，只要 Schema 定義好即可），再啟動後端代理
5. 後端代理完成合約後，再啟動前端代理
6. 這樣在保持部分平行工作的同時，確保了上下游的依賴關係

作者實際示範了這個流程：從一個全新的空專案開始，用三個代理團隊來建構。主代理動態分析計畫後，決定先啟動資料庫代理，等它發送 Schema 合約回來後，再依序啟動後端和前端代理。整個過程仍然有平行工作，但避免了因為依賴關係混亂而浪費 Token 的問題。

16:20 自訂 Skill 的使用方式

安裝這個 Skill 非常簡單：

1. 按照 README 安裝 Tmux 並啟用實驗性功能
2. 將 Skill 複製到 .claude/skills 目錄（全域或專案層級都可以）
3. 使用 /build with agent team 指令，指定計畫檔案路徑和代理數量

作者鼓勵使用者根據自己的需求調整這個 Skill。例如，可以修改協調策略——不一定要用 Contract First 的方式，可以根據具體情境設計自己的協調模式。

17:30 展望與總結

作者表示 Agent Teams 讓他感覺自己正在窺探 Agentic Development 的未來，但目前這個功能離完美還有不小的距離。他計畫在 Anthropic 持續改進這個功能、正式脫離實驗階段後，繼續分享更多關於 Agent Teams 的內容和最佳實踐。

我的想法

Agent Teams 的「Contract First Spawning」策略特別值得注意——它揭示了一個重要洞察：AI 代理的平行化不能簡單地「全部同時啟動」。就像真實的軟體團隊一樣，不同角色之間存在依賴關係，需要先確定介面合約（Interface Contract），才能讓各代理安全地平行工作。這其實就是軟體工程中「契約設計」（Design by Contract）思想的延伸。

另一個值得深思的點是 Token 成本。Agent Teams 的 2-4 倍 Token 用量意味著在選擇使用它之前，需要認真評估任務是否真的需要代理間的協調。對於大多數日常開發任務，Sub Agents 可能仍然是更經濟的選擇。Agent Teams 更適合那些真正需要跨模組協作的大型任務——例如同時涉及資料庫、API 和前端的全端功能開發。

最後，目前 Agent Teams 仍處於實驗階段，穩定性不足是實際使用中需要面對的現實。搭配作者提供的 Skill 模板或開發自己的協調策略，可以顯著降低失敗率。但在生產環境中，建議還是保持謹慎，將 Agent Teams 用於可以容忍重試的開發場景。

進階測驗