你可能已經聽過 Agent、Sub-agent、Multi-agent 這三個詞，但它們到底差在哪？用一個真實的 GitHub Copilot 開發情境，你就能立刻看出差異——而且會想馬上動手試試。
先用一句話區分三者
| 概念 | 角色比喻 | 自主程度 | 適合場景 |
|---|---|---|---|
| Agent | 全能工程師，一個人包辦 | 中 | 單一任務、快速執行 |
| Sub-agent | 專案小組成員，接受主管分派 | 中（受主導） | 任務可拆分、需分工 |
| Multi-agent | 跨部門特攻隊，各自帶著權責合作 | 高（平等協作） | 複雜、跨領域任務 |
User Story：用 GitHub Copilot 開發一個登入功能
假設你要開發一個「使用者登入功能」，包含：後端 API、單元測試、程式碼審查、以及安全性檢查。下面分別用三種架構示範整個流程。
🟢 情境一：單一 Agent 模式
你直接對 GitHub Copilot 說：
「幫我寫一個 Express 登入 API，包含 JWT 驗證、密碼 bcrypt 加密，並附上單元測試與安全性建議。」Copilot 作為單一 Agent，一個人包辦所有工作：寫 API → 加密邏輯 → 測試 → 安全建議，全部在同一個對話 context 裡完成。
✅ 優點：快速、直接，適合任務範圍明確。
⚠️ 限制：任務複雜度增加時，context 容易過載，輸出品質下滑；無法「同時」處理多件事。
🔵 情境二：Sub-agent 模式
你在 .github/agents/ 資料夾建立三個專職子代理：
api-writer.agent.md：專門撰寫 Express API 程式碼test-writer.agent.md：專門生成 Jest 單元測試security-reviewer.agent.md：專門檢查 JWT / SQL Injection / XSS 風險
再建立主代理 login-feature.agent.md，負責協調流程：
---
name: login-feature
agents: [api-writer, test-writer, security-reviewer]
---
Step 1：由 api-writer 建立登入 API
Step 2：由 test-writer 針對 Step 1 的程式碼撰寫測試
Step 3：由 security-reviewer 審查 Step 1 的輸出主代理依序呼叫子代理，每個子代理只專注自己的任務，context 彼此隔離、不互相干擾，最後主代理整合所有輸出回報給你。
✅ 優點：分工明確、品質穩定、容易 debug。
⚠️ 限制：子代理之間無法直接溝通，協調全靠主代理轉達，溝通成本較高。
🟣 情境三：Multi-agent 模式
在 Multi-agent 架構中，每個 Agent 都有完整的自主權與決策能力，可以互相溝通、協商，不再只靠主代理轉達。
以 GitHub Copilot 的多代理場景為例：
- 架構 Agent：設計整體登入流程架構，決定要用 JWT 還是 Session
- 實作 Agent：根據架構 Agent 的輸出撰寫 API 程式碼
- 測試 Agent：直接讀取實作 Agent 的程式碼，自動生成對應測試
- 安全 Agent：全程監看其他 Agent 的輸出，主動標記風險
這四個 Agent 可以並行執行，也可以互相觸發，效率比 Sub-agent 更高，輸出結果也更全面。
✅ 優點：高度並行、跨領域整合、容錯性強（單個 Agent 失敗不影響整體）。
⚠️ 限制：架構複雜、Token 成本高，適合規模較大的任務或團隊。
三種模式的架構示意
單一 Agent：
你 ──→ [Copilot Agent]（包辦一切）
Sub-agent：
你 ──→ [主 Agent]
├──→ [api-writer]
├──→ [test-writer]
└──→ [security-reviewer]
Multi-agent：
你 ──→ [架構 Agent] ↔ [實作 Agent]
↕ ↕
[安全 Agent] ↔ [測試 Agent]我應該用哪一種？
選擇架構的原則很簡單：任務越複雜、越需要並行，架構就要越分散。以下是實用的選型建議：
- 🟢 單一 Agent：任務明確、步驟少、需要快速驗證想法時首選
- 🔵 Sub-agent：任務可以清楚拆分成多個階段，且每階段有標準輸出格式
- 🟣 Multi-agent：任務橫跨多個專業領域、需要並行執行、或規模大到單一 Agent 無法負荷
對大多數個人開發者而言，從單一 Agent 搭配 Skills 開始是最低門檻的起點；當專案規模成長、任務複雜度增加，再逐步引入 Sub-agent 分工架構，就能在不增加太多架構複雜度的前提下，大幅提升 AI 輔助開發的效果。
常見問題 FAQ
Sub-agent 跟 Multi-agent 最大的差別是什麼？
最關鍵的差別在於「溝通方式」。Sub-agent 只能跟主代理溝通，彼此之間不能直接對話，所有資訊流通都需要主代理轉達。Multi-agent 中每個 Agent 都有完整自主權，可以直接與其他 Agent 溝通、協商，更像一個真正的跨部門團隊。
GitHub Copilot 要怎麼設定 Sub-agent？
在專案根目錄的 .github/agents/ 資料夾建立 .agent.md 檔案，在 YAML frontmatter 定義名稱、描述與可用工具，再建立一個主代理並在 agents 欄位列出可呼叫的子代理名稱即可。VS Code 搭配 GitHub Copilot 擴充功能會自動掃描並載入這些代理。
Multi-agent 的 Token 成本很高嗎？
是的，Multi-agent 因為有多個 Agent 並行運作，Token 消耗比單一 Agent 高出許多。不過由於每個 Agent 的 context 是獨立的，每個 Agent 只需要處理自己負責的部分，反而可以避免單一 Agent 因 context 過長而品質下滑的問題。高 Token 成本換來的是更好的輸出品質與並行效率。
Skills 和 Sub-agent 可以同時使用嗎？
完全可以，而且這是最推薦的組合。Skills 定義「怎麼做」（SOP 與方法論），Sub-agent 定義「誰來做」（分工與角色）。例如讓 test-writer 子代理載入你的「單元測試撰寫 Skill」，就能確保每次測試輸出都符合你的團隊規範。
沒有工程背景可以用 Multi-agent 嗎？
Multi-agent 設定需要一定的技術基礎（了解設定檔格式、工作流邏輯），對非工程師來說門檻較高。建議從單一 Agent 搭配 Skills 入門，掌握 AI 工作流的基本概念後，再視需求學習 Sub-agent 分工，循序漸進地提升 AI 協作的複雜度。