Agent 有了 session、工具、權限,還有一種東西沒有著落:方法。你的團隊部署服務有一套固定流程、review 程式碼有一份檢查清單、寫報告有慣用的結構 — 這些「怎麼做事」的知識,要怎麼交給 agent?
寫進 system prompt 是一條路,Day 7(Prompt 的極限)看過 HolmesGPT(CNCF 的 SRE 事故調查 agent)把整套調查方法論寫死在 prompt 裡的極致版本。但那條路有天花板:方法一多,prompt 爆炸,而且每次呼叫都為用不到的方法付 token。Skills 是另一條路:把方法寫成獨立的文件模組,需要時才載入。
Skill 的本體通常就是一個資料夾,核心是一份 SKILL.md。先看一份最小可用的長相:
---
name: deploy-service
description: 部署服務到 staging,含 rollback 流程
---
# Deploy Service
1. 跑 `make test`,全綠才繼續
2. 執行 `deploy.sh staging`,等健康檢查通過
3. 失敗時:跑 `rollback.sh`,並貼出最後 50 行 log
(環境變數的完整說明見 config-reference.md)
它的載入分三層,這正是 Day 8(窗口經濟學)講過的 progressive disclosure 落到實作的樣子:
這個結構的帳很好算:系統可以掛上幾百個 skill 而不動窗口預算,決定載入什麼的是 agent 自己,新增或修改一個 skill 不用改任何程式碼。
這是 skills 最值得想清楚的設計決策。傳統的「能力擴充」直覺是寫 plugin、寫 function,skills 卻選擇了 markdown 文件。理由有三個。
讀者是模型。 Skill 的內容是給 LLM 讀的操作指引,自然語言就是它的原生格式。「先跑測試,失敗的話檢查 fixture 路徑」這句話寫成文件一行搞定,寫成程式碼要處理無數分支。
維護者不一定是工程師。 領域專家可以直接把自己的工作方法寫成 SKILL.md,不用等工程排程。方法知識的擁有者和維護者第一次可以是同一個人。
它跟工具互補,替代不了彼此。 工具劃定 agent「能做什麼」的邊界(Day 17 的主題),skill 提供「該怎麼做」的方法。一個部署 skill 不會給 agent 部署的能力,它教 agent 怎麼組合手上已有的工具完成部署。能力的邊界歸權限和工具管,方法的知識歸 skill 管,兩邊各自演化。
對照 Day 7 的 HolmesGPT 就能看到兩種策略的分工:把方法論寫死在 system prompt,適合「每一次執行都需要同一套方法」的專用 agent;skills 適合通用 agent:方法很多、每次只用到一兩種,常駐成本必須趨近於零。
存放與分發。 這個模式不是 Claude Code 的專利,已經接近 agent 系統的標配:Claude Code 把 skills 放在專案或家目錄的資料夾;HermesAgent 存在 ~/.hermes/skills/ 並自動注入 system prompt,它甚至會在複雜任務完成後提醒 agent「這次的做法值不值得存成新 skill」(這個自我累積的迴路是最後一層 Loop Engineering 的伏筆);OpenClaw(小龍蝦)也支援在 workspace 掛入 skill 文件。跨團隊、跨 provider 的環境則需要集中管理,例如 LiteLLM(開源的 LLM gateway)把 skill 整包存進 PostgreSQL,metadata 可搜尋、內容整包下載,讓不同 runtime 的 agent 共用同一批方法。
品質與腐化。 Skill 是文件,文件會過時。指引裡寫的指令改版了、引用的路徑搬家了,agent 照著做就出錯。這個問題今天先掛著,它的完整解法(把 skill 當成可以被驗證、被優化的資產)是 Loop Engineering(這系列的 L4)自我改進主題的一部分,Day 6(自動優化)講過的「文件當參數優化」到時候會回來。
盤點一下:session 給了時間軸、工具給了手腳、loop 讓手腳動起來、權限畫了圍欄、skills 裝上了方法。一個 agent 的裝備到此齊全。但有些任務單兵打不動 — 要同時探索三個方向、要一邊寫程式一邊跑驗證,單一模型的注意力和窗口都不夠分。明天講 multi-agent:什麼時候該分工、分工的帳單長什麼樣,以及為什麼 production 系統把它當第二檔而不是預設檔。