Skill 生命週期引擎

從原始對話到精煉可重用技能的六個階段。

比喻：學徒成為大師

一位武術學徒透過階段性學習：

啟動 — 師父開啟訓練場。學徒到場。
壓縮 — 同一招寫成三種長度：招名、一句口訣、完整拆解。想得起最短的那版就夠用。
萃取 — 每次對練後，學徒回顧哪些有效、哪些無效。
蒸餾 — 多年的練習壓縮成少數幾條可以傳授他人的原則。
診斷 — 師父看的是一次失手，並說出原因：是拳架的問題，還是這招你根本沒學過？
缺口分析 — 「你防守很強但反擊偏弱。我們來加強這塊。」

DuDuClaw 的 skill 生命週期反映這個過程，將原始對話經驗轉化為結構化、可重用、可分享的技能。

運作方式

階段 1：啟動

Agent 啟動時，skill loader 讀取 SKILLS/ 目錄並啟用已安裝的技能：

Agent 啟動
     |
     v
掃描 SKILLS/ 目錄
     |
     v
對每個 skill 檔案：
  - 解析 skill 定義
  - 驗證格式和依賴
  - 註冊到 SkillRegistry
     |
     v
技能現在可供 Agent 的 runtime 使用

階段 2：壓縮（三層漸進式載入）

壓縮處理的是注入成本，不是去重。每個技能都存成三層，prompt 建構時注入「還夠用的最便宜那層」：

技能檔（SKILLS/complaint-handling.md）
     |
     v
Layer 0 — 只有名稱標籤      約 5 tokens
Layer 1 — 1-2 行摘要        約 30 tokens
Layer 2 — 完整 markdown     約 200+ tokens
     |
     v
由相關度決定哪一層進到 prompt

這一輪大概用不到的技能，留在視野裡只要 5 tokens 而不是 200。技能多的 Agent 不必每一輪都為整座技能庫付錢，靠的就是這件事。

階段 3：萃取

成功對話後，系統可以自動萃取可能成為新技能的模式：

對話成功完成
     |
     v
分析對話模式：
  - 這是新穎的做法嗎？
  - 使用者表達了滿意嗎？
  - 這個模式可重複嗎？
     |
  +--+--+
  |     |
 是     否 → 不萃取技能
  |
  v
產生候選技能：
  - 識別觸發條件
  - 萃取回應模式
  - 定義成功標準
     |
     v
寫入前先過安全掃描與 vetting 閘

2026-09 移除：「階段 4 — 重建」。 本頁舊版描述過一個「逆向工程出技能意圖、從原則重建」的階段。負責做這件事的模組（skill_lifecycle/reconstruction.rs）從來沒有呼叫端——連自己的測試都沒有——所以從沒重建過任何東西。程式碼已刪除，而不是留著當空頭承諾。技能壞掉時，誠實的做法是：退役它，讓萃取產生新的。同批刪除的還有兩個同樣零呼叫端的姊妹模組（recommender.rs、dependency_resolver.rs），這也是為什麼技能清單沒有「為你推薦」介面、技能之間也沒有宣告相依。

階段 4：蒸餾

蒸餾將技能壓縮到其本質規則（有效應用所需的最小可行知識）：

完整技能（500 行，詳細範例）
     |
     v
識別核心規則：
  - 核心原則（5-10 條規則）
  - 關鍵限制
  - 關鍵決策點
     |
     v
蒸餾後技能（50 行，純粹原則）

蒸餾後的技能載入更快、消耗更少上下文視窗、更容易在 Agent 間分享。

階段 5：診斷

診斷師不替技能打分數。它讀的是一次預測誤差，並說出原因——零 LLM 成本，純規則跑在 PredictionError 訊號上：

PredictionError（Significant / Critical）
     |
     v
歸類原因：
  - StyleMismatch       — 語氣／長度不合使用者
  - DomainGap           — 這個主題 Agent 沒有知識
  - PrecisionIssue      — 答得不夠準
  - ExpectationMismatch — 使用者要的是別種行為
  - Unknown             — 判斷不出來
     |
     v
DomainGap 且沒有任何已安裝技能對得上
     |
     v
產生一筆 SkillGap { suggested_name, suggested_description, evidence }

只有「現有技能都涵蓋不到的 DomainGap」才會變成 SkillGap。這筆紀錄就是階段 6 要累積的東西。

階段 6：缺口分析

最後階段審視 Agent 的整體技能組合，找出缺失的部分：

分析對話歷史
     |
     v
識別 Agent 掙扎的模式：
  - 滿意度分數低的主題
  - 需要降級到雲端 API 的查詢
  - 被放棄的對話
     |
     v
缺口報告：
  「Agent 處理客訴很好（已有對應技能），
   但在技術產品問題上掙扎。
   建議：從上週 5 次成功的技術對話中萃取技能。」

缺口分析形成閉環。它回饋到階段 3（萃取），指出哪裡需要新技能；同一領域反覆出現的缺口就是技能合成的觸發條件。

Skill 市集

除了自我產生的技能，Agent 還可以從社群發現和安裝技能：

GitHub 即時索引

市集使用 GitHub 的 Search API 即時搜尋 skill 儲存庫：

搜尋查詢："customer-support skill duduclaw"
     |
     v
GitHub Search API
     |
     v
結果（快取 24 小時）：
  1. zhixuli0406/skill-customer-support (★ 45)
  2. community/duduclaw-skills-pack (★ 120)
     |
     v
加權排名：
  - Stars
  - 近期活動
  - Skill 格式有效性
  - 安全掃描結果

安全掃描

安裝前，每個技能都通過 Rust-native 的 Skill 安全掃描器（skill_lifecycle::security_scanner）檢查：

來自市集的候選技能
     |
     v
安全掃描：
  - Prompt injection 模式？
  - 嘗試修改系統檔案？
  - 參照外部 URL？
  - 混淆內容？
     |
  +--+--+
  |     |
乾淨    標記
  |     |
  v     v
安裝   警告 + 需人工審查

要搜哪裡

技能有三個來源——GitHub、策展過的技能 hub、以及這台部署自己學會的 skill bank——但只有一個工具負責搜尋。skill_search 吃一個 source 參數：

`source`	搜尋範圍	什麼時候用
`all`（預設）	hub 加上學會的 skill bank，依技能名稱去重	你還不知道這個技能在哪裡。規則就一句：除非你知道，否則不要動 `source`。
`github`	只查 GitHub hub	你預期這個技能在公開的 GitHub repo 裡
`hub`	只查策展過的 registry（anthropic-skills / clawhub / lobehub / skills-sh）	你只要經過審核、有排名的結果
`bank`	只查學會的 skill bank	你要找的是這台部署自己學會的東西

skill bank 目前仍是空的 in-memory stub，所以 source="bank" 會誠實回報「空的」，不會偷偷拿 hub 結果充數。skill_bank_search 原本是 source="bank" 的棄用別名，已在 v1.69.0 移除，請改呼叫 skill_search 並帶 source="bank"——見棄用與移除。

MCP 工具

市集可透過 MCP 存取：

工具	用途
`skill_search`	搜尋所有技能來源（hub ＋學會的 bank），加權排名；用 `source` 縮小範圍
`skill_list`	列出這位員工實際載入的技能（公司、部門、自己三層）；替這位員工關掉的技能不列出。未指定時預設為呼叫者本人（尚未發版；以前預設是主要員工，而且漏掉部門層）

技能庫頁面（尚未發版）

儀表板的「技能」頁有四個分頁：市集、團隊技能、我的技能、排行榜。目前開著的分頁會寫進網址（/skills?tab=shared、?tab=mySkills、?tab=leaderboard），分享連結或重新整理都會回到同一頁。

排序。 清單在瀏覽器端依介面語言的排序規則排列：不分大小寫，step-2 排在 step-10 前面，中文名稱照語言慣用的順序，不再照位元組。排序選單可以選依名稱、最近使用、最常使用、最近新增，選擇會記在這個瀏覽器。排在同一位的項目順序固定。閘道回傳的員工也改成依名稱排序，重啟後不會換順序。

搜尋。 團隊技能和我的技能的搜尋框會比對名稱、說明、標籤，我的技能另外比對員工名稱。輸入多個詞時，每個詞都要對得上。

誰在用。 我的技能每一列的選單有「誰在用」，列出擁有這個技能的每位員工、各自是否開啟、系統為他啟用了幾次、最近一次是什麼時候。次數來自 skill_activate 事件，也就是演化迴圈判斷某位員工這次對話需要這個技能時寫下的紀錄。技能內容平常就會放進每次對話，那不算在次數裡。使用紀錄讀不到時，頁面會註明，次數顯示 0。

替一位員工關掉技能。 關掉之後，這個技能不會再放進這位員工的提示，skill_list 不列出，這位員工不能執行它的辦公文件腳本，自動化規則不能替他執行，也不能把它釘進工作流程。其他員工不受影響。公司與部門共用的技能只能逐位員工關掉；在「全部 AI 員工」檢視裡，公司技能那一列有「為所有員工關掉」。開關存在 <home>/skill_state/<agent_id>.json，不在員工自己的資料夾裡，員工沒辦法自己把開關打開。這個檔案存在卻讀不到時，這位員工一個技能都不載入，直到檔案修好或刪掉，頁面會顯示紅色提示。名稱比對不分大小寫。關掉只是縮小員工載入的範圍，不會把技能檔案藏起來，能讀自己資料夾的員工還是讀得到檔案，也擋不住從那個資料夾把技能升級或分享出去。開關已存檔但員工重新載入失敗時，請求會回「已儲存，但重新載入失敗，請重試」，不會回成功。

移除員工自己的技能。「移除」會把技能從員工自己的 SKILLS/ 資料夾拿出來，保留在 <home>/skill_archive/<agent_id>/。員工設定的「技能」分頁列出已移除的技能，可以按「復原」；如果原位置又出現同樣的檔案，復原會拒絕，不會覆蓋。移除和復原都不會經過連結搬檔：SKILLS/ 或途中任何一層資料夾是符號連結時，什麼都不搬。復原做到一半失敗時，已經搬回去的檔案會放回封存。

誰能做什麼。 員工的檢視者（Viewer）看得到技能、開關和已移除的技能；員工的負責人（Owner）或管理員才能改。每次呼叫都重新從帳號資料庫讀權限；一次請求裡只要有一位員工沒有權限，整筆拒絕（全有或全無只針對權限；實際寫入逐位員工進行，每一項的結果都會回報）。市集分頁的搜尋和排行榜也只把員工自己的技能顯示給看得到那位員工的人（行為變更）。管理員可以勾選多列，一次關掉、開啟或移除。把技能分享到團隊、從團隊採用技能，現在也要是那位員工的負責人（行為變更）。每次變更都寫稽核事件：skill_switched_off、skill_switched_on、skill_removed、skill_restored。

安全掃描結果改成依層級與擁有者分開記。兩位員工的同名技能不再共用一個結果。這次之前記下的結果只有名稱，現在不再顯示，該技能會顯示「未掃描」，重新安裝後才有結果。

員工編輯頁的「技能」分頁有同一份清單（只看這位員工），在「這位員工的技能」區塊。

為什麼這很重要

複合學習

每次對話都教會 Agent 一些東西。Skill 生命週期捕捉這些學習並將其形式化。隨時間推移，Agent 真正變得更有能力：關鍵在技能庫持續增長，而非單純的模型改進。

知識轉移

技能可以在 Agent 間分享。從客服 Agent 萃取的技能可以安裝到銷售 Agent。這是自動化的組織知識管理。

品質控管

診斷與缺口分析確保技能不只是累積。寫入磁碟的 markdown 會過安全掃描與 vetting 閘；缺失的能力被主動識別。

社群

市集意味著你不需要從零開始。別人久經考驗的客服技能可以在幾分鐘內引導你的 Agent。

與其他系統的互動

演化引擎：技能為預測引擎提供資訊。技能完善的 Agent 預測錯誤更少。
GVU 迴圈：技能萃取通常在成功的 GVU 迴圈後觸發；人格的改進揭示了值得捕捉的新模式。
記憶系統：技能補充記憶。記憶記住發生了什麼，技能記住該做什麼。
CONTRACT.toml：技能必須在契約邊界內運作；真正寫進磁碟的 markdown 會過安全掃描與 vetting 閘。
Dashboard：技能市集、已安裝技能和缺口分析報告都在 Web 介面中可見。

總結

技能是原始經驗和可靠能力之間的橋樑。6 階段生命週期把一次成功的對話變成可重用技能，把一次反覆的失敗變成一個有名字的缺口：萃取、掃描、分享。Agent 不只是處理今天的對話，也在為明天的對話變得更好。