讓 AI 管 AI，用主代理指揮多個子代理的開發技巧（GitHub Copilot 實戰分享）

身為一個每天和 AI 打交道的開發者，我相信大家現在對 GitHub Copilot、Claude、Cursor 這類工具已經不陌生了。但說真的，大多數人還是停在「問 AI 一個問題、AI 給一個答案」這個層次，頂多是讓 AI 幫你補全程式碼或解釋錯誤訊息（別笑，這個比例高得有點出乎意料，只少在我面試的時候就遇到好幾個了）。雖然大部分的人確實已經開始用 AI Agent 來協助開發了，但「不太信任、不敢全交給它做」的比例也還是相當高。

說實話，上述這兩種情況我都能理解，但如果你也還在這個階段，這篇文章可能對你有幫助。 

今天我想分享一個我實際在用的工作模式：主代理（Orchestrator）指揮多個子代理（Sub-Agent）。這套架構讓我可以把一整個開發流程丟給 AI 去協調，自己只需要在最後確認結果，幾乎就像有一組虛擬工程師團隊在幫你跑，還不會遲到也不會請假。😎

什麼是「主代理 + 子代理」？

概念其實很簡單，就是職責分離：

• 主代理（Orchestrator）：只負責「指揮」，不執行任何實際業務，也就是只要負責任務拆解、工作分派、整合回報，對專案團隊來說，你可以想像他是一位指出一張嘴的 PM（這篇千萬不能讓我公司的 PM 看到 🤣）。
• 子代理（Sub-Agent）：負責實際幹活，搜尋資料的 SA、開發程式的 PG、執行測試的 PG、跑 Code Review 的資深工程師 等等。

這樣的架構有一個關鍵好處，每個子代理只需要背負自己那塊任務的 context，不用把整個專案塞進同一個腦袋裡，讓每個環節都能在自己負責任務的上下文中運作，這正是後面會提到的 Context Engineering 核心概念。

用個流程圖來說明：

為什麼需要這個架構？真正的核心是 Context Window

先講最根本的問題，Context Window 不夠用，這正是多代理架構真正要解決的核心痛點，其他的都是衍生好處。

AI 模型在處理任務時，有一個固定大小的「記憶視窗」（Context Window），當你的專案越來越複雜，程式碼越來越多，AI 能同時「記住」的東西就越來越少。一個大型專案可能有幾十個檔案、幾萬行程式碼，你不可能把所有東西都塞進同一個 context，否則 AI 要嘛記憶力爆炸、要嘛開始胡說八道。

這就是 Context Engineering 的概念，如何聰明地管理、分配、傳遞 context，讓 AI 在有限的記憶空間內發揮最大的效益。如果你對這個概念還不熟，台大李宏毅教授有一部專門講 Context Engineering 的影片，解釋得很清楚，推薦去拜讀一下。

多代理架構本質上就是 Context Engineering 的一種實踐

每個子代理只需要處理自己負責那塊任務的 context，不需要知道其他子代理在做什麼，這樣每個代理都能在最乾淨、最精準的上下文裡運作。就像一個大型軟體團隊，前端工程師不需要把後端的所有資料庫邏輯都裝進腦袋，各司其職反而效率更高。

除了 context 管理這個核心優勢，這個架構還帶來幾個實際的好處，例如

• 平行化執行：前端 Live Server 和 Android 模擬器可以同時啟動，不同的子代理各跑各的，不需要排隊等前一個任務完成。
• 整合不同 AI 工具的強項： 你可以讓 Gemini 子代理負責 UI、Copilot 負責後端邏輯，每個環節用最適合的工具，而不是把所有事情硬塞給同一個 AI。

主代理架構就是為了解決這些問題而生的。

關鍵：System Prompt 的設計

這套架構好不好，取決於你怎麼要求你的主代理。以我慣用的 GitHub Copilot 來說，System Prompt 不是在對話框裡輸入的，而是放在專案根目錄的 .github/copilot-instructions.md。Copilot 每次啟動 Agent 模式時，都會自動讀取這個檔案作為背景指示，所以把主代理的調度規則寫在這裡，它就會一直記住自己的角色。

當然網路上大神一大堆，隨便一個範例都比我的精緻，這裡我只是分享我自己用得順手的 Prompt，不一定是最佳解，所以不要戰我

你是一個負責指揮和協調子代理進行工作的開發代理人，當你發現資訊不夠時，請務必呼叫另外一個子代理協助。

**請記住，"無論如何" 你都 "不允許" 直接執行搜尋、調查、開發、建置等任何需要執行業務的步驟**。
你只要負責指揮代理完成作業並回報給我即可，目前我需要你協助我進行底下任務的分配。

同時如果調度許可，每一項需求都請呼叫不同的子代理，並且若可以平行處理的也請不同的子代理平行處理。

看起來很簡單對吧，但裡面幾個措辭我是刻意為之的，例如 

• 「無論如何」、「不允許」這種強烈語氣是必要的，少了這個，主代理很容易自己偷跑，你叫它調度子代理去執行，它卻直接把答案打給你。
• 「資訊不夠時請呼叫另一個子代理補充」，是為了避免主代理遇到盲點時開始自己猜。
• 「每一項需求都請呼叫不同的子代理」是在強迫它做任務拆解，不然它的本能反應是把所有事情都交給同一個子代理處理，context 又全部擠在一起了。
• 「可以平行處理的請不同子代理並行」，它才不會乖乖排隊一個一個跑。

實戰：User Prompt 範例

直接看我的真實使用案例，底下是我一個 Android 部署流程的 Prompt。

1. 我已經安裝好 C:\Program Files\Android\Android Studio\bin\studio64.exe，
   同時我也安裝好模擬器了，請務必使用子代理，並參考 Readme.md 和 package.json
   內的設定，幫我完成 Android 的佈署，讓我可以到 Android 模擬器內進行驗證。

2. 請注意前端 live mode 可能會需要另外一個站台執行，因此你可能會需要兩個子代理
   合作才能完成，一個開啟前端站台，另外一個建置並開啟 Android 模擬器。

3. 若有 UI 需求請協助指派 Gemini 子代理完成任務。

4. 若有改動到程式，務必通過單元測試。

5. 同上，若有改動到程式，也要進行 code review 相關安全性，若未通過請回報，並通知主代理通知對應負責的子代理完成任務。

6. 完成後請回報，並修改 Readme.md 檔案。

我實際的主代理是 Claude Sonnet 4.6，但 UI 相關的任務我覺得 Gemini 做得比較好（個人主觀意思，僅供參考就好），所以就在這裡指定讓主代理另外請 Gemini 子代理來處理。不同的 AI 各有強項，善用調度就好，不用硬要一個模型包辦全部。

主代理調度中心的完整流程

把上面的 Prompt 執行起來，Copilot 主代理實際調度的流程大概長這樣

整個流程自動閉環（當然你可以更變態的要求做完整合測試），你只需要在最後確認結果。

副作用

當然這套架構不是沒有代價的。最明顯的就是很燒 Token，而且有點花時間。以前一個代理從頭打到尾，遇到不知道的就瞎猜然後給你一個自信滿滿的錯誤答案 XD，現在改成多個子代理協作，每個代理都要初始化、各自跑、再把結果回傳給主代理彙整，整體的 Token 消耗和等待時間確實都會增加。

不過好在 GitHub Copilot 的計費方式是算請求數，不是直接算 Token，所以用這套架構相對來說沒那麼心疼，這也算是用 Copilot 跑多代理的一個小優勢吧。

另外補充一點，實務上這套架構通常還會搭配 Skill 一起用，讓子代理在執行特定任務時有更明確的行為規範，效果會更好。不過這個又是另外一個故事了，之後有機會再分享。

參考資料

• VS Code v1.109 與 Agent Orchestration 的登場 — 遊戲規則的改變