前一天我們談 Subagent。
Subagent 的價值，不是單純增加 Agent 數量，而是建立更乾淨的 Context、責任、權限與結果邊界。
今天要處理另一個很常見的問題：
Agent 需要很多知識和操作方法時，要不要全部塞進 System Prompt？
直覺上，好像應該。
如果 Agent 可能需要：
那我們是不是應該把所有規則、範例、流程和最佳實踐都放進 Prompt？
這樣模型什麼都看得到，看起來也最完整。
但實際上，這很容易變成另一種問題：
Context hoarding。
Agent 把所有可能有用的知識都帶在身上，但真正執行任務時，只需要其中很小一部分。
結果就是：
Skills 提供的是另一種思路：
不要預先載入所有能力細節，而是讓 Agent 先知道「有哪些能力」，需要時再載入對應內容。
這就是 Progressive Disclosure
最簡單的 Skill，可以理解成一個可被發現與載入的能力模組。
它通常包含：
例如：
Skill: database-migration
Purpose:
安全規劃與執行資料庫 Schema Migration
Use when:
需要新增欄位、修改索引、搬移資料
Contains:
Planning rules
Rollback strategy
Validation checklist
Allowed tools
Approval requirements
Agent 一開始不需要看到完整內容。
它只需要知道：
系統裡存在一個 database-migration Skill，而且它適合處理這類任務。
當任務真的涉及 Migration，再把詳細內容載入 Context。
這和把所有規則永久放在 System Prompt 裡是完全不同的策略。
Progressive Disclosure 的核心概念是：
先暴露最少資訊，只有在需要時才逐步展開更多細節。
在 Agent 中，可以分成幾層：
Level 1
Skill 名稱與一句描述
Level 2
使用條件與能力摘要
Level 3
完整 Skill 指令
Level 4
必要的範例、文件與資源
模型一開始只需要 Level 1 或 Level 2。
如果判斷這個 Skill 相關，再載入 Level 3。
真的需要深入細節時，再取得 Level 4。
這樣做的目的不是節省幾個 Token 而已。
它也在控制模型當下的注意力。
Agent 必須先知道有哪些 Skill 可以使用。
但這不代表要把所有 Skill 的全文放進 Context。
可以只提供一份 Skill Index：
database-migration
安全規劃與執行 Schema Migration
incident-response
分析 Production Incident 並建立處理流程
github-pr-review
Review Pull Request 並檢查風險
release-checklist
準備 Release 前的驗證與發布步驟
這一層的任務只有一個：
讓模型知道有哪些能力存在。
Skill 描述要足夠清楚，讓模型能判斷是否相關。
但不要在 Discovery 階段就塞入完整教學。
知道 Skill 存在之後，下一步是判斷哪一個 Skill 適合目前任務。
這裡有幾種方式。
把 Skill Index 提供給模型，讓模型判斷。
優點：
缺點：
由程式根據任務類型、工具或關鍵事件選擇。
例如：
如果涉及 Production Deployment
→ 載入 release-checklist
如果涉及 Schema Migration
→ 載入 database-migration
優點是穩定。
缺點是規則可能變多。
先用程式處理明確條件，再讓模型選擇模糊部分。
這通常最實用。
確定性的選擇交給程式。
需要語意判斷的部分交給模型。
選到 Skill 後，系統才把內容加入 Context。
這裡最重要的是：
Loading 應該是可追蹤的事件。
系統最好記錄：
因為 Skill 會改變模型接下來看到的規則。
如果 Debug 時不知道 Skill 是否被載入，很難判斷問題來自：
Skill 被載入後，不代表 Agent 就一定要逐字照做。
Skill 更像一組任務專屬的操作知識。
例如一個 Incident Response Skill 可能要求：
這些規則會影響 Agent 的執行策略。
但真正的 Tool Permission、Approval 和 Sandbox，仍然應該由 Harness 強制執行。
Skill 可以告訴模型：
在部署前要取得批准。
Permission System 則負責保證：
沒有批准就真的不能部署。
Skill 是操作知識。
Policy 是執行邊界。
兩者不能混在一起。
這兩個概念很容易混淆。
提供一個可以執行的能力。
例如：
告訴 Agent 在某類任務中，應該如何組合工具、判斷步驟與驗證結果。
例如：
Tool:
run_sql
Skill:
database-migration
Skill 可能會告訴 Agent：
先建立 Migration Plan
檢查資料量
確認 Lock Risk
建立 Rollback
執行 Staging 驗證
取得 Approval
最後才執行 Production Migration
Tool 是能力。
Skill 是使用能力的方法。
昨天我們談 Subagent。
Skill 不是另一個 Agent。
它沒有自己的 Loop。
它也不會自己執行任務。
Skill 只是被載入到目前 Agent Context 的能力模組。
可以這樣區分：
Tool
做一個操作
Skill
告訴目前 Agent 如何處理一類問題
Subagent
建立另一個獨立 Loop 處理子問題
如果只需要新的操作方法，Skill 通常比 Subagent 更便宜。
如果需要獨立 Context、Budget 與責任，才考慮 Subagent。
Skill 是通用能力。
Memory 是從過去經驗或使用者互動中保留下來的資訊。
例如：
Skill
公司標準 Deployment 流程
Memory
這個使用者偏好每次 Deploy 前先看完整 Diff
Skill 通常可以被多個使用者、任務重複使用。
Memory 通常與特定使用者、專案或過去執行有關。
兩者都會進入 Context，但來源和生命週期不同。
之後談 Memory 時，我們會再深入。
假設系統有 50 個 Skills。
每個 Skill 平均 1,500 Tokens。
如果全部放進 Context：
50 × 1,500
=
75,000 Tokens
Agent 甚至還沒開始處理使用者任務，就已經消耗大量 Context。
更糟的是，這 50 個 Skill 可能互相包含不同規則。
例如：
Debug Skill
優先快速嘗試
Production Incident Skill
先收集證據，不要急著修改
Prototype Skill
可以接受快速實驗
Security Review Skill
所有外部輸入視為不可信
每個規則單獨都合理。
全部一起存在時，模型卻必須判斷哪一套現在最重要。
Context 越多，不代表判斷越準。
Context Cost 至少有四種：
所以 Context Engineering 的目標不是：
把能找到的資訊都塞進去。
而是：
讓模型在這一輪只看到做出下一個正確決定需要的資訊。
如果 Skill 數量從 10 個成長到 1,000 個，就算每個 Skill 只放一句描述，Index 也會很大。
這時 Discovery 本身也需要分層。
可以加入：
Coding
Data
Security
Communication
Operations
Research
先選 Category，再看 Skill。
根據任務語意搜尋最相關的 Skill。
根據：
縮小候選範圍。
根據過去相似任務中有效的 Skill 進行 Ranking。
Progressive Disclosure 不只是 Skill 內容的載入策略。
連 Skill Discovery 本身也可以逐層縮小。
如果模型一直選錯 Skill，系統並不可靠。
可以評估：
這些指標可以用真實任務建立 Dataset。
例如：
Task
修正 Kubernetes Deployment 一直 CrashLoopBackOff
Expected Skills
kubernetes-debugging
incident-response
Not Needed
email-writing
database-migration
frontend-review
這樣就可以測 Skill Router。
Skill 本身也是程式的一部分。
如果 Deployment Skill 更新了流程，可能直接改變 Agent 行為。
所以 Skill 應該有：
尤其 Production Skill，不應該偷偷更新而完全沒有 Trace。
當 Agent 行為改變時，你需要知道：
是模型更新了，還是 Skill 更新了？
Skill 不應該永遠有效。
例如 Agent 載入 database-migration 後，任務後半段可能已經進入報告階段。
如果 Skill 仍然一直存在 Context 裡，它可能繼續影響不相關決策。
所以 Skill 可以有 Scope：
載入之後，也要考慮何時 Evict。
這就是 Context Management 的一部分。
很多系統只考慮：
什麼時候載入 Skill？
卻沒有考慮：
什麼時候移除？
如果每次找到新的 Skill 都只加不減，Context 最後仍然會膨脹。
所以完整 Lifecycle 應該是：
Discover
↓
Select
↓
Load
↓
Use
↓
Evaluate
↓
Keep or Evict
例如：
Progressive Disclosure 不只是延遲載入。
它也包含適時卸載。
假設某個 Skill 需要使用 Deployment Tool。
這不代表載入 Skill 後就自動得到部署權限。
仍然要經過 Day 4 的 Permission System。
可以把它分成：
Skill
宣告需要 deploy capability
Permission System
判斷目前 Agent 是否真的可以 deploy
Approval
判斷這一次 deploy 是否需要人類確認
Skill 可以描述需求。
它不能提升權限。
內容完整，但每一輪都付出全部 Context 成本。
模型不知道什麼時候應該選。
Selection 沒有真正降低 Context。
Progressive Disclosure 最後又變回 Context Hoarding。
操作知識不應該取代系統權限。
行為改變後無法追蹤原因。
固定 Tool 操作不需要 Skill。
固定 Workflow 也不一定需要模型讀一份 Skill 再決定。
Selection 正確不代表真的改善完成率。
可以問四個問題。
如果只會用一次，不一定值得抽象化。
如果只是單一操作，Tool 可能就夠。
如果所有任務都必須遵守，可能應該放在 System Policy 或 Harness。
如果沒有可觀察效果，就只是增加 Context。
所有任務都必須遵守
→ System / Policy
單一固定操作
→ Tool
特定任務才需要的操作知識
→ Skill
需要獨立 Context 與 Loop
→ Subagent
從過去使用者或任務保留的資訊
→ Memory
固定且強制的流程
→ Graph / Workflow
這能避免把所有東西都塞進 Prompt，或把所有能力都叫做 Skill。
Day 7 我們加入 Subagent 與 Delegation Boundary。
今天加入：
因此，Agent 不再需要一開始就知道所有細節。
它只需要先知道：
哪些能力存在，以及什麼時候值得載入。
Skills 的價值不是把 Prompt 拆成很多檔案。
真正的價值是：
讓 Agent 在需要時才取得需要的操作知識。
完整流程是：
Discover
↓
Select
↓
Load
↓
Use
↓
Evaluate
↓
Evict
最重要的原則是：
Context 不是能力倉庫，而是當下決策的工作空間。
不要因為某些知識可能有用，就讓模型每一輪都重新讀一次。
下一篇會進入 Context Management：
當 Context 真的開始變長，我們應該刪掉什麼、保留什麼，又如何避免把最重要的 Observation 一起壓縮掉？
完整系列與範例收錄於：https://github.com/hardness1020/awesome-agent-architecture
iThome鐵人賽
看影片追技術