2025年12月版：MCP、子代理、技能… 為那些無法跟上層出不窮的代理擴展技術的用戶提供的指南

MCP、子代理 (Subagent)、技能 (Skills)、代碼執行 (Code execution)、進階工具使用 (Advanced tool use)… 在過去一年左右，擴展代理技術不斷出現。許多人可能聽過這些名字，但對它們的差異仍不太清楚。

本文將基於Anthropic的官方部落格，按時間順序整理各項技術誕生的背景。了解「它們是為了解決什麼問題而誕生的」，或許能幫助我們看出整體的輪廓。

2024年11月: MCP 誕生

2024年11月，Anthropic 在 Introducing the Model Context Protocol 這篇文章中宣布了 MCP (模型上下文協定)。

在MCP出現之前，雖然大規模語言模型 (LLM) 變得更加智能，但每次連接內部數據庫、檔案、SaaS、開發工具等時，仍然需要重新進行客製化整合。結果，根據產品的不同出現了許多不同的連接器，根據服務的不同出現了眾多插件，導致整合維護與擴展都陷入困境。

MCP 將此重新整理為「將 AI 助手與外部系統（數據源、工具、工作流程）連接的開放標準」。AI 方面為 MCP 客戶端（主機），外部系統方面為 MCP 伺服器（檔案、數據庫、SaaS、API 等），透過將「連接到哪個部分」改為共通協定來試圖擺脫個別整合的困境，這就是 MCP 的出發點。

參考：Introducing the Model Context Protocol

2024年末〜2025年前半: 代理實作和子代理

雖然 MCP 讓工具和數據連接變得可行，但隨之而來出現了另一個問題。當一個代理負責制定計劃、依次調用各種工具、閱讀長文檔或搜索結果時，提示詞和上下文會不斷膨脹，導致設計與調試變得相當困難。

Anthropic 提出的解決方案是多代理結構（Subagent）。一個「領導者」代理負責整體方針和任務分配，多個子代理則從不同觀點和工具進行研究。各子代理只在自己的上下文窗口中工作，並將摘要回傳給領導者。這樣便形成了由「可能過於龐大的代理」組合而成的「職能分工的小型代理」系統，從而分散上下文負荷與設計的複雜性。

參考：Building effective agents / How we built our multi-agent research system / Building agents with the Claude Agent SDK

2025年9月: 上下文工程

隨著 MCP 和工具的增多，代理的複雜度也隨之加深，這時上下文窗口的壓力問題開始明顯化。填充上下文的不僅是提示詞，還包括過去的對話歷史、MCP 工具的定義、執行結果、子代理的報告等，這些信息會不斷累積，導致模型在達到「用戶的最新問題」之前需處理大量的標記。

因此，Anthropic 提出了「上下文工程」的概念。與處理「如何寫、寫什麼」的提示工程不同，上下文工程著眼於「什麼應該進入上下文、什麼應該排除、怎麼壓縮」。具體而言，就是透過摘要 (壓縮) 過去信息，將其寫入結構化的外部筆記 (記憶)，或乾脆通過子代理將「入口」分開，避免將所有信息塞進一個上下文中。

MCP 將世界連接起來的結果，使得設計模型「展示什麼、隱藏什麼」變得極其重要，此時這一認識被正式表述出來。

參考：Effective context engineering for AI agents

2025年10月: 代理技能

即使上下文管理得當，仍然會出現新的問題。在實際業務中，許多模型的參數中沒有的「程序性知識」，例如這個公司的特定流程、這個團隊的運作規則以及這個領域的特有注意事項，都需要大量的知識。將這些資訊全部寫入系統提示中，會導致提示過長難以處理、案件更換困難，以及更新與審核變得繁瑣。

因此，代理技能 (Agent Skills) 應運而生。一個技能 (Skill) 是由資料夾、SKILL.md（核心的說明和流程）以及必要的附加檔案或代碼組成的「知識包」。代理一開始只將每個技能的「名稱和簡短說明」置於上下文中，當察覺需要時，才會讀取 SKILL.md，如有必要則進一步閱讀附加檔案，這是一種逐步吸收知識的風格。

重點在於「知識可以隨意提供，但上下文中只需讀取必要的部分」。與MCP將「連接外部工具」標準化不同，Skills則是「如何使用這些工具和工作流程的專業知識」的包裝，使上下文的節省得以實現。

參考：Equipping agents for the real world with Agent Skills

2025年11月4日: 通過 MCP 的代碼執行

在技能的管理上取得進展後，隨著 MCP 伺服器和工具持續增加，出現了另一個問題。單是工具定義就可能超過 5 萬至 10 萬個標記，當多次調用工具時，中間結果在歷史中不斷堆積，造成用戶的問題被工具相關信息淹沒的情況。

針對這個問題的解決方案是 通過 MCP 的代碼執行 (Code execution with MCP)。不改變 MCP 協定或 MCP 伺服器本身，而是通過改進代理側調用 MCP 的方法來提升效率。傳統上，工具是作為「自然語言直接調用的對象」，而現在將其視為可以通過代碼（如 Python）調用的 API。具體而言，生成可以從代碼中調用的 MCP 工具文件（可由開發者事先生成，或由代理動態查找發現）。代理只讀取所需工具的文件並編寫代碼，然後通過 MCP 調用這些工具以獲取和匯總數據。這樣做不再需要一開始就把所有工具定義展開到上下文中，同時也使得大量數據的處理在代碼中完成，最終結果只返回給模型。

參考：Code execution with MCP: building more efficient agents

2025年11月24日: 進階工具使用

在通過 MCP 的代碼執行推出約三週後，Anthropic 發表了 進階工具使用 (Advanced tool use)。這是一種針對工具定義和中間結果引起的上下文膨脹問題的更系統性方法。

主要有三個要點。第一個是 工具搜尋（Tool Search），不再一開始就傳遞所有工具定義，而是搜索並加載所需的工具定義，藉此減少由工具定義引起的上下文壓力。第二個是 程式化工具呼叫（Programmatic tool calling），模型可以編寫 Python 代碼，並在代碼中調用多個工具進行處理。中間結果在代碼內部處理，最終結果才進入模型的上下文，從而防止工具執行結果引起的上下文膨脹。第三個是 附帶範例的工具定義（Tool use examples），提供具體範例來輔助說明不易傳達的「正確用法」。這樣可以減少由工具誤用導致的無謂交流，增進工具的使用效率。

這樣，針對工具定義和中間結果造成的上下文膨脹問題的具體方法相繼被整理出來。這是截至2025年12月的情況。

參考：Introducing advanced tool use on the Claude Developer Platform

總結

當MCP問世時，任何外部系統的連接可能性隨之展開。然而，隨著連接點的增加和工具的不斷添加，代理卻因上下文的負擔而無法正常運作。

這促使人們對如何管理上下文展開了研究。要考慮何者應進入上下文、何者應移出、如何壓縮以及何者應如何提取。針對這些挑戰，Subagent、Skills、Code execution 和 Advanced tool use 等手法接連被提出。

代理技術依然處於發展階段，未來還必然會出現新的方法。雖然趕上這些變化比較困難，但如果從「各自試圖解決什麼問題」的視角出發，或許會更易掌握整體的情況。

最後，本文提及的技術出現的時間整理如下：

時期	技術	概要
2024年11月	MCP	外部系統連接的標準化
2024年末〜2025年前半	子代理 (Subagent)	任務分配以分散上下文負擔
2025年9月	上下文工程 (Context engineering)	設計輸入上下文的內容
2025年10月	代理技能 (Agent Skills)	將程序性知識打包為分階段讀取的模式
2025年11月4日	通過 MCP 的代碼執行	通過代碼呼叫工具以提高效率
2025年11月24日	進階工具使用 (Advanced tool use)	通過工具搜尋/程式呼叫/範例定義來系統化