Agent 為什麼會越用越順手？技能沉澱、自我改進與複用機制

摘要

Agent 越用越順手，不是因為它在背後神秘地自動升級，而是因為兩類東西被有結構地保留下來：穩定事實進入 Memory，可複用方法沉澱為 Skill，並在合適的場景被重新加載。Memory 讓它知道發生過什麼——被 query 命中就召回；Skill 讓它知道下次遇到同類問題該怎麼做——場景匹配就裝載。二者的觸發方式、表達形式與演化速度都不同，因此不能合併。Hermes 提供 /learn 讓 Agent 把會話中值得沉澱的流程提煉成 SKILL.md，並通過 /skills pending 審批，避免"無邊界自改"。一份合格的 Skill 必須寫清四件事：何時使用、按什麼步驟執行、成功標準是什麼、哪些邊界不能越過。真正的關鍵不在於沉澱得多，而在於它可審查、可複用、可在產品變化時被更新。

引子：經驗如果不能複用，就只是一次聊天

回想一次配合得特別好的協作。你和 Agent 一起排查了一個問題，或者產出了一篇質量不錯的發佈説明。過程中你糾正了它三四次：範圍要收窄、格式要統一、某個檢查項不能漏。最後結果令人滿意。

一週後同類任務再來。如果那些糾正只留在上次的聊天記錄裏，你會發現自己在重複同樣的話——上次的調優沒有變成資產，只變成了一次性的消耗。

這就是"越用越順手"這件事的核心命題：不是讓 Agent 變得神秘地更聰明，而是讓已經驗證過的東西被結構化地留下來。留什麼、怎麼留、留在哪裏，決定了它是真的在積累，還是每次從零開始。

一、兩類積累，不能混為一談

Agent 的積累分兩類，它們的性質完全不同。

舉一對具體例子來對照：

• "這位用户偏好結論先行" → 這是 Memory。它是一條關於你的事實。
• "寫發佈説明前先核對版本號與鏈接是否有效" → 這是 Skill。它是一段遇到某類任務就該執行的流程。

兩者不能合併，原因至少有三條：觸發方式不同（query 命中 vs 場景匹配）、表達形式不同（短句條目 vs 步驟流程）、演化速度不同（每天變 vs 幾個月不動）。把穩定的流程和高頻變化的事實混在一處，穩定的部分會被沖刷掉。完整論證見《Memory 不是 Skill：Hermes Agent 的事實記憶與程序性記憶有何不同？》。

理解這個區分有直接的實踐價值：當你發現自己在重複糾正同一類做法時，需要沉澱的是 Skill，不是往記憶裏再加一條事實。

二、Skill 長什麼樣

Hermes 裏一份 Skill 通常是一個 SKILL.md，頭部帶 YAML frontmatter 聲明觸發條件與配套信息。它的形態大致是：

---
name: release-note-format
trigger:
  when: "user asks to write release notes"
---

# 寫發佈説明的標準流程

1. 確認版本號與發佈日期
2. 按「新增 / 修復 / 變更」三類歸集
3. 核對每個外部鏈接可訪問
4. 檢查是否包含內部項目名或端口，若有則替換為佔位名
5. 輸出前確認長度符合發佈渠道限制

關鍵在於 trigger：它讓 Skill 不需要你每次手動調用，而是在識別到匹配場景時被自動裝載成高優先級提示，指導本次行動。

Hermes 還提供兩層組織能力：

• Skill Bundle：把相關 Skill 打包成一組整體啓用、停用或分享。例如"發佈流水線"這個 bundle 可以包含發佈前檢查、變更日誌格式、回滾步驟三份 Skill。
• fallback_for_toolsets：Skill 可以聲明"當某個工具集調用失敗時兜底"，讓異常路徑也有明確的處理流程。

這兩層讓 Skill 從單點 SOP 變成可組合的工作方法論。

三、/learn：把一次成功的流程變成方法

沉澱 Skill 不需要你離開對話去寫文件。Hermes 提供 /learn 命令，讓 Agent 把當前會話裏"值得沉澱成 Skill 的一段流程"提煉成新的 SKILL.md。

這個設計的價值在於沉澱發生在記憶最清晰的時刻。剛剛完成一次協作，你和 Agent 都清楚哪幾步是關鍵、哪個糾正是必要的。如果等到一週後再補寫，細節已經流失。

但自動提煉帶來一個必須解決的問題：如果 Agent 能隨意給自己增加行為規則，它的行為就會變得不可預期。 Hermes 的處理方式是引入審批環節——通過 /skills pending 查看待確認的 Skill，由你決定是否採納。這與 Memory 側的 /memory pending 是同一種設計思路。

自我改進不等於無邊界自改。 可靠的改進路徑是：新方法先變成一條可審查的規則，經過確認後才生效。這樣 Agent 的能力增長才是可解釋、可複用、可糾正的。

四、一份合格的 Skill 必須寫清四件事

這是決定 Skill 有用還是有害的關鍵。四要素缺一，Skill 就會在實際使用中失效或產生副作用。

第一，何時使用。 觸發場景要具體。"處理文檔時"太寬，會導致在不該觸發的場景被裝載；"用户要求撰寫發佈説明時"足夠具體。觸發條件過寬的 Skill 比沒有 Skill 更糟，因為它會干擾其他任務。

第二，按什麼步驟執行。 步驟要有順序、可執行。"注意質量"不是步驟，"核對每個外部鏈接可訪問"是步驟。判斷標準：另一個人拿着這份 Skill 能不能做出大致一致的結果。

第三，成功標準是什麼。 沒有成功標準，Agent 無法自檢，你也無法判斷這次執行是否合格。成功標準應該是可驗證的，比如"三類歸集齊全且每類至少一條，或明確寫明該類無內容"。

第四，哪些邊界不能越過。 明確禁止事項。比如"不得在示例中出現真實內部項目名與端口"。邊界是 Skill 裏最容易被忽略、但事故率最高的部分。

四要素齊全的 Skill 有一個共同特徵：它對人和 Agent 同樣可讀。 你能看懂它在做什麼，因此能在它出錯時精確修正——這是"可糾正"的前提。

五、讓積累真正產生價值的三個階段

沉澱不是一次性動作，而是一個有順序的過程。跳過任何一步都會降低質量。

階段一：先在真實任務中驗證流程。 不要憑想像寫 Skill。一段沒有在真實任務裏跑通的流程，寫成 Skill 只會把錯誤固化。先做一次，把過程中的糾正記下來。

階段二：把穩定且可複用的步驟沉澱為 Skill。 注意兩個限定詞——穩定（不會下週就變）和可複用（不只適用於這一個特例）。只用一次的流程不值得沉澱，它帶來的維護成本高於收益。

階段三：在產品、工具或政策變化時更新 Skill。 這一步最容易被忽略。一份寫於半年前的 Skill，如果引用的功能入口已經改了、限制已經調整了，它會持續給出過時指導。舊經驗無限沿用比沒有經驗更危險，因為它帶着"已驗證"的可信度。

一個可操作的維護習慣：當你發現某個 Skill 的輸出需要你反覆手動修正時，説明它已經過期，應該更新而不是繼續將就。

六、常見誤區

其中第四行值得強調：Skill 庫的價值不與數量成正比。 一份過期的 Skill 造成的損失，可能超過十份好 Skill 帶來的收益，因為它會被自動裝載、並且看起來很可信。

七、LightVela 的做法：把方法也變成用户資產

Hermes 已經把 Memory / Skill 的分層做到工程可用，但它仍然是面向直接編輯 Markdown 的使用者。LightVela 採用雲端託管模式，不提供面向用户的文件系統操作，這兩類積累的使用方式如下：

• 技能來自公開市場：所有技能來自 Skills.sh 與 ClawHub —— OpenClaw 與 Hermes 共享的技能市場，不需要你從零編寫。
• 通過對話安裝與刪除：告訴 Hermes 要安裝哪個技能即可完成安裝，刪除同理；安裝後在對話中驗證是否可用。管理枱面板安裝即將推出。
• 記憶在管理台可查看：記憶頁用於查看 Agent 記住了什麼，並可調整容量上限；增刪則通過對話完成。
• 跨模型與跨通道穩定：切換模型不會清除技能與自動化設置；多個通道共享同一套技能與記憶。
• 異常可追溯：技能行為異常時，可在診斷中心查看並導出近期日誌（可選 1、3、6、12 或 24 小時範圍）定位問題。

也就是説，在 LightVela 上使用 Agent 時，你積累的是兩類東西：一份關於你的 Memory，一套已安裝並驗證過的 Skill。這兩類積累比某個具體模型更長期地服務於你。

小結

• "越用越順手"來自有結構的積累，而不是模型的神秘自我升級。
• 兩類積累不可混淆：Memory 存事實（query 命中即召回），Skill 存方法（場景匹配即裝載）。
• 發現自己在重複糾正同一類做法時，該沉澱的是 Skill，而不是再加一條事實。
• /learn 在記憶最清晰時沉澱方法；/skills pending 提供審批，確保自我改進不等於無邊界自改。
• 合格的 Skill 必須寫清四件事：何時使用、執行步驟、成功標準、不可越過的邊界。
• 沉澱分三階段：真實任務驗證 → 沉澱穩定可複用步驟 → 變化時更新。過期 Skill 比沒有 Skill 更危險。