過去一年 AI 開發，不論是 AI 研究員、工程團隊、甚至社群會出現的獨立開發者，「多代理系統」（Multi-Agent System，縮寫成 MAS）是共同的熱潮，開發者們競相設計越來越複雜的 AI Agent 架構，像是拆分成「規劃 Agent」、「執行 Agent」、「驗證 Agent」等多個角色，期待透過分工與協作來處理複雜任務。
而在 2026 年初，一篇來自加拿大 UBC 的研究論文、以及 Anthropic 工程團隊在 AI 論壇的經驗分享，共同指向了一個不同以往的結論：簡化 Agent 架構，搭配豐富的「Agent Skill」機制，反而能讓 AI 效能大幅提升。
這篇文章是我閱讀論文《When Single-Agent with Skills Replace Multi-Agent Systems and When They Fail》以及 Anthropic 工程團隊 演講 後的學習筆記。我將帶你理解什麼是可擴展且高效的「技能型代理人系統」、這個新趨勢的核心邏輯、實際效能提升數據與使用限制，也分享論文研究員給出的 AI Agent 設計建議。
Anthropic 建議的新架構：簡化 Agent 搭配 Skill 技能庫#
Anthropic 工程團隊提出三層協同架構，可以想像成「一個」通用 Agent 構成的生態系：
- 底層：AI 模型（運算核心）
- 中層：通用 Agent Runtime（協調工作的作業系統）
- 頂層：Skill Library（應用知識的專業技能庫）
當你給 AI 一個任務時，通用 AI 代理會先從 Skill 技能庫的「目錄」中找到相關的技能、透過 MCP 連接到需要的外部系統（如資料庫或 API），最後按照 Skill 定義的工作流程執行任務。而 AI 模型是每個動作的運算核心，不論是 Agent 的協調、或是 Skill 的工作執行都仰賴 AI 模型運算。
這個架構是單一代理的系統（Single-Agent System、以下簡稱 SAS），原本應該分散在多個不同 AI Agent 的複雜任務，現在是「一個」通用 Agent 負責管理與協調，把任務分配給 Skill 來執行。
在這個三層架構中，頂層的 Skill 技能庫取代了過去一群各司其職的「小 Agent」。與其聘請 10 個只會做一件事的人，不如培養一個天才（通用 Agent），給他 10 本專業操作手冊（Skill）。
我們來個應用場景舉例：企業財務分析與報告
- 過去：多代理系統（MAS）做法
- 設計「資料檢索 Agent」（連接資料庫）+「財務分析 Agent」（計算數據指標）+「合規報告 Agent」（格式化輸出）
- 各個 Agent 間需要交換複雜的試算表數據與知識脈絡（Context）
- 現在：單一代理（SAS）+ Skill 做法
- MCP 伺服器連接到資料庫，提供數據訪問
- 估值方法論 Skill 教導 AI 如何計算 IRR 等指標
- 報告規範 Skill 定義企業標準的輸出格式
- 單一個通用 AI Agent 在統一的上下文中完成所有步驟，無需跨 Agent 溝通
我相信你開始有疑惑了：這裡的「三層架構」只是從 10 個 Agent，改成 1 個擁有 10 個 Skill 的 Agent，好像換湯不換藥啊？其實 AI 能達成任務的複雜度確實差不多，但這項改變帶來的工程技術優勢卻能讓 AI 執行效率大提升，因此我們接著來詳談技術優勢。
補充：MCP / Skill / MAS / SAS 名詞解釋（點擊展開 ▼）
- Multi-Agent System (MAS) / 多代理系統：將任務拆分給多個專門的 AI 代理執行，各代理人之間需要互相溝通協調
- Single-Agent System (SAS) / 單一代理系統：由一個通用 AI 代理處理所有任務，透過切換不同「技能」來完成專門工作
- Agent Skill / 技能：封裝專業知識與工作流程的檔案結構。就像給 AI 一本「操作手冊」，教它如何執行特定任務（詳細介紹可參考 這篇 Skill 教學文章）
- MCP (Model Context Protocol) / 模型上下文協定：連接 AI 與外部系統（如 Google Drive、資料庫）的標準化接口，負責「連接性」
（延伸閱讀：白話解釋什麼是 MCP）
為什麼簡化的 Agent 更好？三大技術優勢#
1. 漸進式揭露#
傳統多代理系統或 MCP 工具會在對話開始時，將所有工具定義一次性塞入上下文視窗（Context Window），可能一次就佔用數萬個 Token，導致 Context Rot、模型將因為資訊量太多而變笨。
Skill 機制則採用漸進式揭露（Progressive Disclosure），平時只載入約 100 個 Token 的技能描述（名稱與簡介），只有當 AI 自動判斷某個 Skill 與任務相關時，才會動態載入完整的指令或程式碼腳本。這讓 AI（理論上）可以攜帶無限多的專業能力，卻不會因為「背包太重」而忘東忘西、甚至失去智能。這正是多 Skill 的運算資源運用效率會優於多 Agent 的主要理由。
（延伸閱讀：什麼是 Skill 與漸進式揭露？）
2. 省 Token 又省時#
Skill 漸進式揭露能讓 AI 效能大提升，這項好處是有論文研究數據支持的。
根據 UBC 的研究實驗，將多代理系統改寫為「單一代理 + Skill」的架構後，在數學推理、程式碼生成、問答等任務中：
- 平均減少 54% 的 Token 消耗
- 降低 50% 的延遲時間
- 將原本需要 3～4 次的 API 調用減少為 1 次
- 關鍵是效率提升絲毫不犧牲 AI 回答準確率：準確率保持不變或甚至提升
（詳細數據來源請參照 下個小節）
3. 程式碼作為數位世界的通用介面#
還記得前面提到，Skill 裡面除了提示詞、還可以包含程式碼腳本嗎？Skill 讓 AI Agent 透過程式碼與多元的工具溝通，更適合解決 Agent 的穩定性與擴充性。這說明了「單一」通用 Agent 如何能夠擁有靈活運用技能的能力、讓 AI 大腦不會因為「單一」而死板。
Anthropic 在 經驗分享 中強調，與其為每個任務設計複雜的 UI 或架構（Scaffolding），不如讓 AI 直接透過「寫程式」的方式與外部系統互動。因為 LLM 本來就被很多程式碼訓練過、它超會寫程式啊！讓 AI 寫程式去調用工具，比強迫它遵循嚴格的 JSON Schema 更可靠且強大。
與其為搜尋、編譯、格式化等每個操作都設計專門的工具介面，不如給 Agent 一個 Bash 權限。它能寫程式、執行程式、查看輸出、並在出錯時自我修正。這讓 Agent 能直接呼叫現有的 Unix 工具（grep 或 ffmpeg 等等）或第三方 SDK，而不需要開發者手寫複雜的工具封裝。
因此，Anthropic 認為開發者應專注於設計確定性（deterministic）的工具（程式碼腳本），而讓模型負責判斷「何時」以及「如何」組合這些工具。這讓 Agent 能像工程師一樣操作電腦，而不是像一個只能按固定按鈕的自動化程式。
補充知識：Skill 會取代 MCP 嗎？（點擊展開 ▼）
Skill 不會取代 MCP。兩者是互補關係，而非替代關係。
- MCP 負責「連接性」：它是 AI 與外部世界（Google Drive、Slack、資料庫）之間的「萬用插頭」，提供 AI 脈絡數據（Context）取用權限
- Skill 負責「專業知識」：它是「操作手冊」，教導 AI 該如何使用這些脈絡數據、遵循什麼流程、產出什麼格式
MCP 就像五金行的貨架，讓你拿得到工具；Skill 則是工程師傅的老道經驗，教你如何正確組裝。
而目前 AI 開發社群的現況是 Skill 替代「一部分」的 MCP。當你的 MCP 伺服器工具數量極多時，可以將其封裝成 Skill，利用漸進式揭露機制來最佳化 Token 使用效率。但對於簡單且預測性強的單一工具調用，傳統的函式調用（Function Calling）仍然更快速可靠。
（延伸閱讀：MCP + AI Agent 將讓手機在五年內消失？）
對比：多代理 vs. 單一代理#
在 2024～2025 年，多代理系統（Multi-Agent System、縮寫成 MAS）成為 AI 開發的主流。既然人類團隊是透過分工協作來完成複雜任務，那麼設計多個專門的 AI 代理（如「UI 設計師 Agent」+「後端工程師 Agent」+「測試工程師 Agent」）應該也能發揮類似效果，滿合理吧？
但是實務上，大家逐漸注意到多代理系統暴露出嚴重的效能問題：
- Token 消耗爆炸：每個 Agent 之間需要反覆傳遞任務描述、中間結果和脈絡數據（Context），導致大量重複而冗贅的運算
- 延遲時間持續累積：每個步驟都需要發起新的 API 調用，等待時間不斷累加
- 溝通成本高昂：Agent 之間用自然語言交換複雜數據結構，容易出錯且效率低落
這些 MAS 的效能問題，改成單一代理（SAS）與 Skill 的架構後，都能顯著改善。根據研究數據，從多代理改成單一代理後：
- Token 消耗：節省超過 50%
- 延遲時間：減少將近 50%
- API 調用次數：從多次減少到只需要一次
新架構並不完美：簡化 Agent + Skill 的限制#
AI 也會「選擇障礙」：Skill 不能無限上綱！#
研究發現，單一 AI 代理在選擇技能時存在認知極限。當 Skill 技能庫規模在某個臨界值以下時，AI 的選擇準確率還能保持穩定；但一旦超過臨界值門檻（實驗顯示約在 50～100 個技能 之間），Skill 技能選擇準確率會發生斷崖式下跌。
以下研究論文中的 Figure 2 給出真實的實驗數據支持，圖中展示了針對 GPT-4o-mini 模型的實測曲線，隨著橫軸 Skill 技能數量增加、縱軸的技能選擇準確率會因此下降。我們可以簡化地總結：如果你給 Claude Code 超過 50 個 Skill，AI 會超級容易選錯技能使用！
導致準確率崩潰的主因不單純是技能數量，也可能是語義混淆（Semantic Confusability），常發生在多個技能的描述（description）過於相似或廣泛時。
如果要你到蝦皮或 PChome 搜尋「筆電」，你會面對著 100 款難以一眼看出有啥不一樣的筆電，然後陷入「選擇障礙」，對吧？
AI 也會！你要是給 AI 多個內容相似的 Skill，要求 AI Agent 自己決定該挑哪個 Skill 技能，AI 也會陷入「選擇障礙」而拿錯工具。想像一下你的 Agent 如果同時有「理財 Skill」+「財務 Skill」+「賺錢 Skill」這幾個描述模糊的技能放在眼前，挑錯工具也無可厚非吧。
不適用單一代理（SAS）的情境#
並非所有多代理系統都能被簡化為單一代理 + Skill 架構。仍然有些情況更適合多個代理 MAS，關鍵是你需要「多個獨立上下文（context）」的情境：
- 需要多個 Agent 獨立進行多次嘗試：例如你需要同時研究多種解決方案，然後挑出一個最好的
- 對抗性目標：如辯論或對手分析，需要不同立場的衝突意見
- 私有狀態資訊：各 Agent 間需要擁有不可完全共享的隱藏狀態，例如不同公司部門間的資料權限隔離
專家建議：如何成功運用簡化 Agent + Skill 架構#
為了防止單一代理人在 Skill 技能數量增加時效能崩潰，研究論文內提出多個 AI 設計準則：
- 監控技能庫規模：持續追蹤 Skill 數量，避免超過臨界閾值（姑且記得是 50 個技能），否則你的技能準確率會變超糟
- 盡力避免語義混淆：換言之，把 Skill 的
description寫清楚！增加新技能前要仔細審核描述是否重疊，優先合併相似技能、而不是無腦堆疊新技能；並且避免使用通用的詞彙，例如將「處理數據」改為更明確的「計算七天移動平均值」 - 採用多層級 Skill 結構：當 Skill 技能真的極多時，建立「大分類 → 細項技能」的兩階段選擇機制（Hierarchical Routing），確保每次決策的選項都少於臨界閾值
- 根據任務複雜度挑選模型：能力更強的模型（如 Claude Opus 4.5）具有更高的技能容量閾值與抗混淆能力，真的需要很多技能在手的情況、就選用更強的 AI 模型
- 考慮替代架構：你真的真的很需要超級多 Skill 同時在手？那還是回去考慮多代理系統 MAS 吧！
其實我看起來，這堆建議可以濃縮成一句話：盡量別讓一個 Agent 扛下超過 50 個 Skill！
（來自電影《少林足球》截圖）
結語#
多代理系統（MAS）與單一代理系統（SAS）+ Skill 技能，兩種架構沒有絕對的高下之分。MAS 在需要私有狀態資訊處理或對抗性目標等等獨立上下文情境仍然不可或缺，而 SAS + Skill 架構則在大多數線性的工作流中展現了驚人的效率優勢。
終究，你需要親自實驗，才能知道哪個架構最適合你的應用場景。
但無論選擇哪種架構，理解什麼是 Agent Skill 以及如何設計高品質的 Skill 都是 2026 年 AI 開發者的必修課。如果你還不熟悉 Skill 機制，推薦從 這篇 Skill 實戰教學 開始。
參考資料：
- 研究論文：When Single-Agent with Skills Replace Multi-Agent Systems and When They Fail (Xiaoxiao Li, UBC, 2026 Jan.)
- Anthropic 演講：Don’t Build Agents, Build Skills Instead
- Anthropic 官方文章：Extending Claude’s capabilities with skills and MCP servers
- Anthropic 官方文章：Equipping agents for the real world with Agent Skills
如果這篇文章有幫助到你，歡迎追蹤好豪的 Facebook 粉絲專頁 、 Instagram 與 Threads 帳號，我會持續分享 Claude Code 新知與趨勢；也可以點選下方按鈕，分享給同樣熱愛 AI 的朋友們。