在開發 AI Agent（AI 代理）系統時，許多開發者容易陷入一個誤區，認為最關鍵的決定是選擇哪一個 LLM 模型。然而，從系統架構的角度來看，真正的分水嶺在於你決定將功能實作為 Skill（技能）還是 Sub-Agent（子代理）。如果架構選擇錯誤，即便使用了最強大的模型，也無法解決系統維護困難或使用者體驗不佳的問題。
理解 Skill 與 Sub-Agent 的核心差異
簡單來說，Skill 與 Sub-Agent 是兩種不同的交付形式，它們解決的問題維度完全不同。
Skill 指的是在一個持續的對話流程中運作的功能模組。它的特點是具備互動性，能夠在對話過程中讀取檔案、向使用者詢問更多資訊，並在過程中讓人類參與（Human-in-the-Loop）來修正方向。Skill 是對話的一部分，它共享當前的對話上下文。
Sub-Agent 則像是一個獨立的任務執行單元。它接收一個明確的提示詞（Prompt），獨立運行直到任務完成，最後交付一個最終結果。它不與使用者進行中間過程的互動，而是採取一種一次性交付的模式。
選擇決策的四個維度
要決定使用哪一種形式，可以從以下四個維度進行權衡。
首先是迭代模式。如果你需要與使用者反覆確認需求或逐步調整結果，應該選擇 Skill；如果你只需要一個確定的輸入並得到一個最終輸出，則適合 Sub-Agent。
其次是人類介入點。Skill 允許在流程中隨時插入人類的審核或修正，而 Sub-Agent 則是在結果產出後才由人類檢查。你需要衡量讓人類參與迭代所增加的時間成本，與強行將複雜流程壓縮成一次性輸出而導致錯誤率增加的風險。
第三是語音或風格的一致性。這涉及到 AI 在執行任務時是否需要維持與主代理一致的對話語調。
最後是執行頻率，這是最容易判斷的指標。如果該任務是像手工藝品一樣、每次需求都略有不同的單次任務，建議使用 Skill；如果該任務是可重複、標準化的批次處理工作，則應設計為 Sub-Agent。
實務上的深層考量：上下文與權限
除了上述維度，工程實務中還需要考慮 Context Window（上下文視窗）的污染問題。Sub-Agent 的優勢在於它擁有獨立的運行環境，開始時是乾淨的，不會被主對話中冗長的歷史紀錄干擾，這能有效降低模型產生幻覺的機率。
此外，當任務需要完全不同的權限設定、獨立的知識庫（Knowledge Source）或隔離的執行環境時，Sub-Agent 是更好的選擇。
然而，引入 Sub-Agent 會增加編排層（Orchestration Layer）的複雜度。在像 Copilot Studio 這樣的系統中，規劃器（Planner）會根據描述和上下文動態決定呼叫哪個模組。這種非決定性（Non-determinism）意味著即使面對類似的輸入，系統不一定每次都會觸發同一個 Skill 或 Sub-Agent，這在測試與除錯時會增加難度。
建議的心理模型與分層設計
為了方便理解，我們可以將 AI 系統類比為一家公司： Agent（代理）是總導演，負責掌控大方向。 Sub-Agent（子代理）是部門經理，負責獨立完成特定專案。 Skill（技能）是專業員工，負責執行具體的操作步驟。 Tool（工具）是專用機器，提供精確的功能（如計算機或 API 呼叫）。 MCP（模型上下文協定）則是公司的治理規則與政策。
在成熟的設計中，Skill 與 Sub-Agent 並非互斥，而是可以組合使用。最理想的架構往往是分層的：你可以建立一個 Skill 作為對外的互動介面，而這個 Skill 的內部實作則是呼叫一個或多個 Sub-Agent 來處理複雜的後端邏輯。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。