iT邦幫忙

2026 iThome 鐵人賽

DAY 20
0

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 落到實作的樣子:

  • 第一層:metadata,常駐。 上面的 frontmatter(name 加一行 description)永遠在 system prompt 裡。幾十個 skill 也只佔幾十行,agent 知道每個 skill 的存在和適用時機,不知道細節
  • 第二層:完整指引,按需。 agent 判斷任務需要部署了,才把整份 SKILL.md 載入 context。那三個步驟、踩坑提醒可以寫得很長,因為只有用到才付費
  • 第三層:附帶資源,指名才讀。 最後一行引用的 config-reference.md,要等 agent 真的需要環境變數細節才會去讀

這個結構的帳很好算:系統可以掛上幾百個 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 系統把它當第二檔而不是預設檔。


上一篇
Day 19|錯誤即體驗:Agent 的錯誤哲學與三條信任邊界
系列文
模型動不了,那你能動什麼?AI Engineering 四層工程觀:Prompt、Context、Harness、Loop20
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言