上一頁展示了工具如何讓代理人員行動——呼叫函式、查詢 API、搜尋網頁。 但隨著你打造更多代理，一個模式逐漸浮現：同一組工具、說明書和參考資料不斷出現。 「申報費用報告」功能不僅僅是一個工具——它包含驗證腳本、一套政策文件、逐步填寫表格的指示，以及對支出上限的了解。 你最後會把這個套件從一個代理人複製貼上到另一個代理人，結果就不同步了。
技能 解決了這個問題。 技能是一種可攜式套件，將指令、參考資料及可選腳本打包成單一單元，任何代理都能隨時發現並載入。 技能遵循 開放規範 ，因此能在代理人、團隊甚至產品間重複使用。
何時使用
在以下情況下，為你的經紀人增添技能：
- 你會有一 組相關知識 ——說明書、參考文件和腳本——理應歸於一組（例如「費用報告」或「程式碼審查指引」）。
- 多位客服 人員需要相同的領域專業知識，而你想要的是單一的真實來源，而不是重複的指示。
- 你希望將代理能力以自成一體的套件形式，在團隊、專案或組織 間分享與分發 。
- 你需要 有效率地管理情境 ——技能會利用漸進式揭露，讓客服人員只在需要時載入他們需要的細節。
考慮事項
| 考量事項 | 詳細資料 |
|---|---|
| 重複使用性 | 技能是一個自成一格的套件。 一旦建立，任何代理程式都能接手，不需要手動複製貼上，也不會出現版本之間的差異。 |
| 情境效率 | 技能採用漸進揭露：代理人會先看到簡短描述（~100個代幣），並僅在相關時載入完整指令。 這樣即使不需要技能，上下文視窗也能保持精簡。 |
| 抽象成本 | 技能在工具之上加了一層抽象層。 對於單一獨立功能工具來說，加入技能包裝是不必要的。 |
| 設計努力 | 你需要事先思考技能界限：什麼該在技能內，什麼留在外面。 界線不明確會導致技能範圍過於寬泛（浪費上下文）或過於狹窄（失去捆綁的好處）。 |
技能與工具的差異
工具與技能是互補的，而非競爭。 了解這些差異可以幫助你決定何時選擇使用哪一個。
工具是一個可呼叫的單一動作——一個具有名稱、描述和參數結構的函式。 當模型決定需要某個工具時，會產生一個結構化呼叫，Agent Framework 執行，結果會回傳給模型。 工具是代理行為的原子。
技能是一套領域專業知識的組合。 它可以包括：
- 說明 — 逐步指引、決策規則，以及告訴代理 如何 接近領域的範例。
- 參考資料 — 政策文件、常見問題、範本及其他代理人可隨時查閱的知識。
- 腳本 — 代理可執行的可執行程式碼，用於執行特定操作（例如，驗證腳本用來核對費用資料與政策規則）。
關鍵差異在於範圍：工具賦予代理人執行 一項行動的能力;技能賦予代理人處理 整個領域所需的知識與資源。
| Tool | 技能 | |
|---|---|---|
| 它所提供的是什麼 | 一個可呼叫的動作 | 說明 + 參考資料 + 可選腳本 |
| 代理人如何使用它 | 需要行動時會呼叫它 | 當遇到相關任務時載入，閱讀指令，並可能呼叫腳本或參考資源 |
| 情境成本 | 工具結構總是出現在提示中 | 提示中只有技能名稱和描述（~100個代幣）;完整內容可隨選載入 |
| 可攜性 | 與登記的代理人綁定 | 任何相容代理都能發現的自包含套件 |
| 適用對象 | 個別動作（查詢資料庫、發送電子郵件） | 領域專業知識（費用政策、程式碼審查指引、入職程序） |
小提示
把工具想像成 動詞 （搜尋、預訂、驗證），技能則是 專業知識 （旅遊訂位知識、費用政策知識）。 代理人使用工具來行動，並具備知道如何行動的技能。
技能運作方式：漸進式揭露
技能的設計旨在提高情境中的效率。 技能不是將所有東西一開始就注入提示中，而是使用三階段模式：
┌──────────────────────────────────────────────────────────────────┐
│ Stage 1: Advertise │
│ Agent sees skill names and descriptions (~100 tokens each) │
│ in its system prompt at the start of every run. │
└──────────────┬───────────────────────────────────────────────────┘
▼ (task matches a skill's domain)
┌──────────────────────────────────────────────────────────────────┐
│ Stage 2: Load │
│ Agent calls load_skill to get the full instructions │
│ (< 5000 tokens recommended). │
└──────────────┬───────────────────────────────────────────────────┘
▼ (agent needs more detail)
┌──────────────────────────────────────────────────────────────────┐
│ Stage 3: Read resources │
│ Agent calls read_skill_resource to fetch supplementary files │
│ (FAQs, templates, reference docs) only when needed. │
└──────────────────────────────────────────────────────────────────┘
這種模式意味著一個註冊技能為 10 個的客服，大約要支付 1,000 個上下文開銷，而不是 50,000。 當當前任務需要時，代理人才會加深知識。
此外，技能也建立在工具基礎之上。 代理框架會在代理的系統提示中宣告可用技能，然後以工具呼叫的形式公開 load_skill 和 read_skill_resource，代理會呼叫這些工具以逐步載入內容。
小提示
關於技能結構、設定及程式碼範例的完整細節，請參閱 Agent Skills 參考文獻。
何時使用技能與其他模式
隨著你的代理人能力提升，你有多種方式來組織其行為。 技能與工具的比較如下：
| 樣式 | 最適合用於 | 範例 |
|---|---|---|
| 個別工具 | 一次性行動，不需要共享上下文 | 函 get_weather 式工具 |
| 技能 | 具備指導、參考資料及可選腳本的領域專長 | 一款「報銷管理」功能，包含政策文件、驗證腳本及逐步報告提交說明 |
常見陷阱
| 潛在問題 | 指導 |
|---|---|
| 過於廣泛的技能 | 一項名為「財務全方位」的技能，試圖涵蓋會計、稅務、費用報表和薪資，但指示會過於冗長且不集中。 保持技能專注在單一領域。 |
| 跳過安全審查 | 技能指令會注入代理的上下文中，腳本執行程式碼。 將技能視為第三方依賴——部署前先檢視。 請參閱技能參考中的 資安最佳實務 。 |
| 忽略漸進式揭露 | 如果你 SKILL.md 的技能有 2,000 行，代理在載入技能時會付出沉重的上下文成本。 保持指示簡潔，並將詳細參考資料移至獨立資源檔案，以充分利用漸進揭露的優勢。 |
下一步
一旦你的客服人員擁有工具和技能，下一步就是加入 中介軟體 ——像是護欄、日誌和內容過濾等跨領域行為，適用於每一次互動，且不改變客服核心邏輯。
深入探討：