代理技能 (Agent Skills) 是什麼? 解決了什麼問題?

過去幾個月，在 AI 工程領域中，受到最多討論的話題之一是代理技能 (Agent Skills) 這個由 Anthropic 推出的代理模式 (agentic pattern)。

從宏觀角度來看，大致可以整理出以下的時間軸

Anthropic 在 2025 年 10 月 16 號推出 Skills (連結)
社群在 10 月底左右陸續有 Skills 相關的開源專案 (連結)
OpenAI 在 12 月 12 號把 Agent Skills 加入 ChatGPT 與 Codex (連結)
Anthropic 在 12 月 18 號，進一步推出跨平台的標準化 Agent Skills (連結)

從上述時間軸可以看到，代理技能從推出到被 AI 工程社群採納，僅花了約兩個月的時間。這不禁讓人問，究竟代理技能是什麼、解決了什麼問題，讓社群會如此快速地採用這個新模式。

在這篇文章，我們會試著從開發與使用代理的痛點出發，然後一步步帶著讀者們，解決這些痛點，進而能夠理解代理技能的價值。

什麼是代理技能 (Agent Skills)?

在 Anthropic 團隊公開給的第一個有關代理技能的講座(連結) 中，代理技能的提出者 Barry Zhang 談到一個相信大家都有過的挫折，那就是明明 AI 模型的能力很強，也能解決博士等級的難題，但為什麼有時候要 AI 做事時，AI 卻沒有辦法做好?

Barry Zhang 的觀點是，就像一個通用能力很強的人，如果缺乏專業領域的知識與技能，在解決某個特定領域的問題時，可能也會無法有效做好，AI 代理有同樣的問題。而代理技能就是通過賦予 AI 代理專業技能與知識，讓 AI 代理能夠更有效完成任務。

具體來說，代理技能的官方定義是「Skills are folders containing instructions, scripts, and resources」，意即一個包含指令、腳本與資源的資料夾。，這個資料夾能夠讓 AI 代理根據所面對到的情境，來選擇並使用。

舉例來說，Anthropic 的 Claude 最近新增了文件編輯功能，使用者可以上傳 PDF，然後讓 Claude 來編輯。在往下讀之前，大家或許可以先暫停一下，思考一下假如你要實作的話，會如何讓 Claude 這類 AI 代理編輯 PDF 檔案?

Claude 的 PDF 編輯功能正是透過代理技能來做到，假如看到 PDF Skills 這個 Anthropic 團隊公開的代理技能 (連結)，有以下結構：

.
├── SKILL.md
├── forms.md
├── reference.md
└── scripts/
    ├── check_bounding_boxes.py
    ├── check_bounding_boxes_test.py
    └── ...

可以看到在資料夾當中有 SKILL.md 這個 Markdown 檔案 (連結)，該檔案直接註明假如要處理 PDF 文件，可以使用哪些套件、如何使用那些套件。除此之外，在該資料夾中也有 /scripts子資料夾，而該資料夾中帶有很多處理 PDF 文件的客製化腳本，讓 AI 代理可以直接呼叫來使用。

在有了這個資料夾後，未來 AI 代理如果有遇到要處理 PDF 的情境，就可以直接進到該資料夾，按照 SKILL.md 的規範來處理 PDF，並且可以直接呼叫 /scripts 當中的腳本來做某些 PDF 的處理操作。

從概念上來說，代理技能就是上面談到的這樣，非常的簡單。不過這樣看似簡單的設計，背後其實有不少精闢之處，以下讓我們更詳細地討論。

為什麼代理技能會被提出? 代理技能解決了什麼問題?

在初步理解完代理技能是什麼後，相信讀者們腦中應該有不少疑問。接著讓我們來進一步談代理技能被提出的脈絡，從中解答一些常見問題。我們會從不同的情境切入，來談假如沒有用代理技能，在實作 AI 代理或使用 AI 代理時，會遇到什麼問題，然後再透過回推可以如何解決這問題，來讓大家一步步理解代理技能。

解決 AI 代理執行結果不冪等的問題

在代理技能解決的眾多問題中，讓我們最有感的是「讓 AI 代理的執行結果冪等」這一點。眾所皆知，大型語言模型是現代 AI 代理背後的大腦，而大型語言模型帶有不確定性 (non-deterministic) 的特性，會讓每次的生成結果都可能有不同的結果。

從比較技術的角度來看，這意味著如果沒有特別處理，AI 代理針對任務的執行結果，往往是非冪等的 (備註：所謂的冪等或常聽到的 idempotent，是指某個操作，不論做多少次，都會是相同的結果。這對軟體開發或某些特定類型的任務來說，能夠確保穩定性，是很重要的特性。我們在要能夠做到穩定，冪等 (idempotent) 是很關鍵的要點。所謂的冪等性，是指 API 的呼叫或者操作，不論做多少次，都會是相同的結果；或者換個角度說要做到不論請求幾次，API 都不會產生副作用。當能夠做到冪等性，就能夠確保在重試時，不論重試幾次，都能確保只有執行一次，這樣能避免當遇到各類狀況，導致的不必要重複。我們在這篇文章有談及相關概念有談過這個概念，推薦不熟的讀者可以回顧)。

因為有這種不確定性，從大型語言模型興起後，工程師會透過提示詞工程 (prompt engineering) 來規範模型的輸出，例如透過給予人設、風格等設定，讓模型的回覆能夠更貼近預期。

不過，進到代理時代，因為代理開始會有行動與操作，除了提示詞外，需要有方法來規範代理的行動，讓代理的執行結果能更貼近冪等。代理技能就是進一步的拓展，讓提示詞跳脫指令，拓展到腳本與資源等其他形式，這能讓代理在行動時更加貼近使用者想要的。

舉例來說，如果 AI 代理要處理 PDF，如果純下「幫我根據以下需求修改這份 PDF (附上詳細需求)」這個提示詞，AI 代理可能有幾種不同做法，例如自己從頭寫相關的函式，包含解析 PDF、解截取文字、將改寫內容轉回 PDF 格式等等的函式然後執行 (但每次從頭實作的函式，可能寫法不同，也不保證每次都會寫對)；也可以選用開源套件 (但因為能用的開源套件很多，所以每次選的不一定是同一個)。

因為多元的可能性，讓僅用指令型的提示詞時，最終的結果會變得很不穩定，即使同一個提示詞，每次可能有不同結果。但假如透過代理技能，預先把要用的套件與腳本等資源都放在技能資料夾，當代理要處理 PDF 檔案時，每次都會執行同樣的腳本，就會讓成果變得很穩定。

解決脈絡窗口有限的問題

在代理技能推出時，Anthropic 團隊有附上一些範例，其中有一個是在技能的資料夾中，只有放 SKILL.md 這個帶有指令的 Markdown 檔案。這個範例讓社群中有不少人感到困惑，畢竟假如 Skills 的資料夾中只放 SKILL.md 檔案，這樣跟一般的提示詞 (prompt) 有什麼不同?

畢竟早在兩年前，Cursor 就有推出 Cursor Rules (詳見 2-1 提示詞是什麼? 如何透過 .cursor/rules 設置提示詞? )，甚至 Anthropic 的 Claude Code 本身也有斜線命令 (Slash Commands)，也是單純放 Markdown 檔案。

在 Anthropic 的官方回覆中，有提到兩個主要區別點。第一個是斜線命令是由人指定的，所以如果人沒有指定，AI 代理不會主動用；不過代理技能則會由 AI 代理根據情境自行使用。

看到第一個區別，相信大家可能會問「那為什麼不讓 AI 代理也能自動用斜線命令就好? 何必額外創造代理技能這個新名詞呢?」。

這是因為斜線命令在載入時是一次全部載入整份 Markdown 檔，不只是 Anthropic 的 Claude，許多社群中熱門的 AI 工具也有同樣的設計。這會導致的問題是，假如要讓 AI 自動挑選使用，AI 就需要掃過所有的 Markdown 檔案。換句話說，如果這麼做，AI 代理在實際做任何事之前，已經消耗大量 tokens 並佔據極大部分的脈絡窗口 (context window)。

消耗大量 tokens 並佔據極大部分的脈絡窗口的問題在於，一來會導致成本提高 (每多消耗 tokens 就會多花錢)，二來精準度會下降。不過，假如原本的設計會導致這問題，為什麼自動載入代理技能就不會有這兩個問題呢?

這是因為代理技能採用了漸進式揭露 (progressive disclosure) 的模式，這是代理技能設計絕妙的地方。在每個技能的 SKILL.md 檔案中都需要標注 name 與 description 來註明該技能用途為何，當代理載入技能時，會先掃過這兩個欄位，而不會載入整份 SKILL.md，所以大幅降低 tokens 消耗，也只會佔據極小部分的脈絡窗口。

事實上，代理技能採用資料夾的方式，也能貫徹漸進式揭露的模式。當把腳本拆到獨立的檔案，SKILL.md 中只需要註明在什麼情況下要用哪個腳本，而不用把完整腳本寫出來，這也讓 tokens 消耗小上不少。

漸進式揭露 (progressive disclosure)

在上面提到，代理技能透過漸進式揭露這個設計模式，來減少 tokens 的消耗與佔用更少的脈絡窗口。事實上，這個設計模式不僅用在代理技能上，在代理的其他面向也看得到其身影，因此我們特別拉出一個段落來談。

雖然漸進式揭露這名詞聽起來有點艱澀，但相信多數前後端工程師，在工作上早已接觸過這個設計模式。常見的分頁 (pagination) 就是基於這種模式。比起一次載入所有資料，先載入部分資料，等使用者需要更多資料時，再透過到下一頁來載入更多資料。

除了代理技能外，目前業界也陸續把漸進式揭露用在 MCP 的加載上 (備註：不熟 MCP 的讀者可以回顧 Agent 實作 — 工具 (tools) 與 MCP 伺服器。

舉例來說，AI 代理的脈絡窗口中，過去佔據最大空間的，多半是 MCP 相關的東西。舉例來說，像 Cursor 這類 MCP 客戶端，會在最開始加載所有工具，導致往往還沒用任何 MCP，脈絡窗口就已經消耗數萬個 tokens。

大家可能會問，在加載 MCP 時，可以先加載名稱與描述就好，不用載入完整的工具，這樣不就能減少 tokens 消耗嗎?

這樣想沒有錯，可惜現實沒那麼單純。以社群中有名的 GitHub MCP 來說，整個 MCP 有 35 個工具，加起來的工具名稱與描述就高達 2.6 萬個 tokens。這導致 Cursor 一開始支援 MCP 時，在當時的版本中，Cursor 為了避免脈絡窗口被吃光，限制最多只能載入 40 個工具。

因此 Cursor 的做法之一 (連結)，是不再一開始就載入 MCP 工具描述，而是把 MCP 的工具描述視為可延遲載入的檔案，並在代理執行過程中依需求搜尋並載入特定工具，而不是一開始就全部加載。這種只在需要的時候載入的做法，讓 tokens 用量大幅降低高達 46.9%。

無獨有偶，Anthropic 在《Introducing advanced tool use on the Claude Developer Platform》一文 (連結) 中有提出幾乎一樣概念的方法，不在一開始加載需要上萬個 tokens 的所有 MCP 工具，而是一開始僅加載約 500 tokens 的搜尋工具，然後在代理運行期間，再根據需求去搜尋需要的 MCP，每次可能找個兩三個工具，頂多消耗幾千個 tokens，而不是幾萬個。

上面這種做法，也是漸進式揭露的體現，在實務上能幫上非常大的忙。

閱讀更多

如果對代理技能這個主題感興趣，除了這篇文章談的內容外，我我們在 E+ 成長計畫中的主題文有談到其他更深入的內容。

對更深入了解這個主題，以及其他前後端開發、軟體工程、AI 工程主題感興趣的讀者，歡迎加入 E+ 成長計畫一起成長 (連結)。