VS Code 多個 Agent 協作任務實戰
VS Code 多個 Agent 協作任務實戰
簡介
在 VS Code 的 GitHub Copilot Chat 中，Custom Agent 可以讓我們把不同類型的工作拆成明確角色。例如有的 agent 負責規劃，有的 agent 負責提出反對意見，有的 agent 則專門整理文件。當任務變得複雜時，比起只讓單一 agent 從頭做到尾，更適合透過多個 agent 協作，讓每個角色各自處理自己擅長的部分，再由統籌者整合成最終成果。
這次影片示範的是一個「多 agent 協作任務」：使用者要求 Copilot 幫忙設計一款符合現代玩法的貪食蛇遊戲，並將企劃輸出到 plans 資料夾底下。整個過程不是直接請單一 agent 產生一份企劃，而是透過 commander agent 統籌，先理解工作區、確認限制，再把任務交給不同角色審視，最後整合成一份可審閱的遊戲企劃文件。
為什麼需要多個 Agent 協作？
單一 agent 很適合處理明確、範圍小的任務，例如修改一段程式、補一個測試，或整理一份文件。但當任務同時包含「需求釐清、創意發想、風險檢查、範圍控管、文件輸出」時，單一視角容易出現幾個問題：
- 容易一開始就跳進實作，忽略需求與限制條件
- 產出的內容可能完整，但缺少不同專業角度的質疑
- 任務過程不容易追蹤，不清楚目前正在做哪一段
- 最後成果可能混合了太多想法，沒有經過收斂
多 agent 協作的重點，就是把這些不同性質的工作拆開。以影片中的範例來看，commander agent 不直接取代所有專業角色，而是扮演統籌者：它會先確認目前工作區狀態，再決定要委派哪些 agent，並把不同 agent 的輸出整理成一致的企劃方向。
影片中的 Agent 角色分工
影片中的工作區準備了多個自訂 agent，放在 .github/agents 底下，包含：
| Agent | 角色定位 |
|---|---|
commander |
統籌任務、拆解工作、分派 agent、整合輸出 |
game-designer |
從遊戲設計角度提出玩法、核心循環與內容規劃 |
project-mgr |
從專案管理角度檢查範圍、時程、MVP 與交付方式 |
devil's-advocate |
從反方觀點檢查風險、過度設計與可能失敗的地方 |
這樣的分工很接近真實團隊協作。game-designer 負責讓點子有趣，project-mgr 負責讓計畫可執行，devil's-advocate 負責挑出盲點，而 commander 則負責把這些意見收斂成最後的交付成果。
Commander Agent 的設計
影片一開始開啟的是 commander.agent.md。這個 agent 的定位不是單純回答問題，而是「總指揮代理人」。它的描述中明確寫到，適用於需要統籌多位代理人、拆解複雜任務、分派工作、整合輸出與追蹤決策的場景。
從設定可以看到，commander 被賦予了讀取、搜尋、編輯、呼叫其他 agent，以及維護 todo 的能力：
1 | tools: [read, search, edit, agent, todo] |
這個設定很關鍵。若要讓一個 agent 負責協作，它不能只會回答問題，還需要能夠理解目前工作區、拆分任務、委派角色、追蹤進度，並在必要時修改或產出檔案。
在行為準則上，commander 也被要求避免把協調變成空泛口號。它需要明確列出任務目標、輸入資料、限制條件與期待交付物，並且只有在需要專業判斷時才委派 agent。這讓整個流程比較像有節奏的任務管理，而不是單純把問題丟給多個模型各說各話。
實際任務：建立現代化貪食蛇遊戲企劃
在影片中，使用者輸入的任務大意是：
1 | 請遵行你的團隊幫我建構一個符合現代玩法的貪食蛇遊戲，並將企劃輸出到 ./plans/ 底下讓我進行審閱，有問題可以向我提問 |
這個任務表面上是「產生一份企劃」，但其實包含多個子任務：
- 確認目前專案是否已有
plans資料夾或既有企劃格式 - 理解工作區中的 Copilot instructions，避免輸出格式與專案慣例衝突
- 判斷這款現代化貪食蛇遊戲的核心玩法與 MVP 範圍
- 找出可能過度設計或不可行的地方
- 最後把內容整理成可審閱的 Markdown 企劃文件
commander 收到任務後，先檢查目前工作區與規則，確認 plans 資料夾狀態，並閱讀 .github/copilot-instructions.md，避免企劃文件格式或專案慣例和既有設定衝突。
委派任務與整合回饋
確認基礎資訊後，commander 開始委派不同角色。影片中可以看到它把任務交給 game-designer 與 project-mgr，分別從遊戲設計與專案管理的角度產出可審閱的企劃意見。
game-designer 的重點放在玩法本身，例如現代化貪食蛇應該如何保留經典核心，又能加入更有節奏感的變化。project-mgr 則會關注範圍是否可控，像是哪些功能應該放入 MVP，哪些內容應該延後，避免企劃一開始就變得過大。
接著，commander 又把初步方向交給 devil's-advocate 做反向審查。這一步很重要，因為多 agent 協作不只是「多叫幾個角色幫忙補內容」，更有價值的是讓不同角色互相制衡。反方審查會刻意挑出可能失敗的地方，例如 MVP 是否同時塞進太多系統、風險道具是否會讓玩法失焦、每日挑戰與敵對單位是否應該延後處理等。
透過這種流程，最後產出的企劃不是單一視角的直覺答案，而是經過「設計發想、範圍整理、風險修正」後的收斂版本。
最終輸出：可審閱的企劃文件
影片最後，commander 將多個 agent 的回饋整合成 plans/modern-snake-gdd.md。從畫面中可以看到，文件內容已經整理出清楚的章節，例如核心玩法、MVP 必做項目、MVP 暫不做項目，以及驗收條件。
這份文件不是單純的靈感清單，而是比較接近可以拿來審閱與討論的遊戲設計文件。以 MVP 功能範圍為例，文件會把功能、規格與驗收條件放在同一張表中，讓後續實作時比較容易判斷完成標準。
例如影片中的企劃包含以下類型的內容：
| 分類 | 內容方向 |
|---|---|
| 核心玩法 | 移動、轉向、成長、碰撞與死亡 |
| MVP 功能 | 快速局、核心蛇系統、普通食物、基礎 HUD、結算畫面等 |
| 延後項目 | 關卡、敵對單位、每日挑戰等較容易擴張範圍的功能 |
| 驗收條件 | 玩家可以完成一局、死亡或時間到時進入結算、紀錄能被保存 |
這也是多 agent 協作最明顯的好處：產出不只是「更多內容」，而是更容易被檢查、拆分與落地的內容。
實際操作影片示範
多 Agent 協作的操作重點
從這次影片可以整理出幾個實務上的重點。
1. 先定義統籌角色
如果每個 agent 都直接對使用者輸出，對話很容易變得鬆散。因此多 agent 協作最好先有一個統籌角色，負責理解目標、拆解問題、決定要委派誰，並在最後整合結果。
commander 的價值就在這裡。它不是所有事情都自己做，而是讓任務流動起來，並確保每次委派都有明確目的。
2. 不同 Agent 要有明確邊界
多 agent 並不是數量越多越好。如果角色邊界不清楚，最後只會得到多份重複的建議。比較好的做法是讓每個 agent 有明確專長，例如設計、專案管理、風險審查、文件整理，讓它們從不同角度補足彼此的盲點。
3. 委派後仍要收斂
多個 agent 產出的內容通常會有重疊或衝突，因此統籌者必須負責收斂。以影片中的例子來說，devil's-advocate 提醒 MVP 不要過度膨脹後，commander 就需要把部分功能移到延後項目，而不是把所有建議照單全收。
4. 用 Todo 追蹤流程
影片右下角可以看到工作進度被拆成多個待辦項目，例如確認工作區脈絡、委派設計與專案管理、執行反向審查、撰寫企劃文件、驗證輸出檔案。這能讓使用者清楚知道目前進度，也讓 agent 自己比較不容易漏掉步驟。
5. 最終成果要落到檔案
多 agent 協作最終還是要交付具體成果。這次示範把企劃寫入 plans/modern-snake-gdd.md，讓使用者可以直接打開審閱。比起只停留在聊天紀錄中，輸出成檔案更適合後續版本控制、修改與團隊討論。
適合使用多 Agent 協作的情境
多 agent 協作特別適合以下任務：
- 需要先規劃再實作的功能開發
- 需要不同角色共同審視的產品或遊戲企劃
- 需要同時考慮技術、時程、風險與使用者體驗的任務
- 需要先產出文件，再交給使用者審閱的工作流
- 需要把大型任務拆成多個可追蹤步驟的情境
相對地，如果只是要修一個小錯字、改一個設定值，或補一段簡單文件，就不一定需要啟動多 agent 流程。多 agent 的價值在於處理複雜度，而不是讓每個小任務都變得更隆重。
小結
這次影片展示了 VS Code 中多個 Custom Agent 協作的完整流程：使用者提出一個較複雜的企劃需求，commander 先確認工作區與規則，再委派 game-designer、project-mgr 與 devil's-advocate 進行不同角度的分析，最後整合成一份可審閱的 modern-snake-gdd.md。
這種工作方式的關鍵不在於「讓 AI 回答更多內容」，而是讓 AI 以更接近團隊協作的方式工作。當每個 agent 都有明確角色，統籌者又能負責收斂與交付，複雜任務就能從一段模糊需求，逐步變成可討論、可審查、可執行的成果。