Memory vs Skill：陳述性記憶與程序性記憶
摘要
Memory 和 Skill 都是長期記憶，但性質完全不同：Memory 是"陳述性記憶"（Declarative Memory），存事實、事件、結論、偏好，形態是短句/條目，被 query 命中就召回（MEMORY.md + memories/）；Skill 是"程序性記憶"（Procedural Memory），存"遇到 X 場景該怎麼做"的 SOP，形態是帶觸發條件的 YAML + 流程，場景匹配時高優先級裝載（skills/ 目錄 + SKILL.md）。兩者不能合併的三條硬約束是：觸發方式不同（query 命中 vs 場景匹配）、表達形式不同（條目 vs 步驟流程）、演化速度不同（Memory 每天變、Skill 幾個月不動）。一個"兩條腿走路"的 Agent，才既懂你、又有方法。
引子：為什麼這兩個概念老被搞混
如果説 Hermes Agent 有一個特別容易被誤解的設計，那大概就是它把 Memory 和 Skill 明確分成了兩件事。
很多人的第一反應是三個疑問：
- "這倆不都是長期記憶嗎？為什麼要分？"
- "都是 Markdown，直接塞一起不行嗎？"
- "我記住'agent-demo 前端使用本地開發端口'和記住'寫 PR 描述時先總結再列變更'，本質上不是一回事嗎？"
答案很短：因為人腦本來就分。
一、認知心理學裏就分好了：陳述性 vs 程序性
心理學早就區分過兩類長期記憶：
| 類型 | 定義 | 例子 | 調用方式 |
|---|---|---|---|
| 陳述性記憶（Declarative） | 可以説出來的事實 | "我住在北京"、"React 18 引入了併發渲染" | 被講出來 |
| 程序性記憶（Procedural） | 會做但未必説得清楚的技能 | 騎自行車、盲打、寫一封結構合理的 PR 描述 | 被執行出來 |
這兩類記憶的存儲方式、調用方式、更新方式都不同：陳述性記憶可以被"講出來"（言語通道），程序性記憶更多是被"執行出來"（動作通道）。心理學實驗裏，海馬體損傷的病人陳述性記憶嚴重受損，但程序性記憶（比如鏡面書寫）依然可以學會——這是兩條獨立的通路，不是一條通路的兩種表現。
Hermes Agent 直接把這個區分搬進了系統設計：
- Memory（
memories/、MEMORY.md）：Agent 的陳述性記憶。 - Skill（
skills/）：Agent 的程序性記憶。
二、Memory：Agent 會"講"的東西
Memory 系統裏存的是事實、事件、結論、偏好：
- "Jasmin 在做 agent-demo 項目的國際站。"
- "上週把 hero 區改成了動態漸變。"
- "該項目跑在 Next.js 上，前端 dev server 使用本地開發端口。"
它的特點：
- 陳述性：以短句、條目形式存在，能直接被引用進 prompt。
- 按需召回：Agent 遇到相關話題時，由 FTS5 命中把匹配的條目拉進來。
- 易變：新條目會追加，舊條目會被
replace或remove。
你可以把 Memory 想成 Agent 的"筆記本"——桌上攤開的一本，寫滿了具體的事。
三、Skill：Agent 會"做"的事
Skill 存的是做某類事的標準流程。Hermes 裏一個典型 Skill 通常是一份 SKILL.md，頭部帶 YAML frontmatter 聲明觸發條件與配套工具集：
---
name: pr-description-format
trigger:
when: "user asks to write a PR description"
fallback_for_toolsets: [git, code-review]
---
# 寫 PR 描述的標準流程
1. 一句話總結變更目標
2. 變更點清單（按模塊）
3. 影響範圍
4. 測試情況
5. 關聯 issue / rollback plan它的特點：
- 程序性：以"何時觸發 + 怎麼做"的形式存在，接近一段可複用的 SOP。
- 按場景觸發：Agent 識別到匹配場景時，Skill 會被自動裝載成高優先級 prompt，指導本次行動。
- 相對穩定：Skill 一旦沉澱，通常長期不變；變的是 Memory 裏綁定它的場景與素材。
你可以把 Skill 想成 Agent 的"肌肉記憶"——不用去"回憶"，動作就出來了。
Hermes 用户還可以通過 /learn 命令讓 Agent 把當前會話裏"值得沉澱成 Skill 的一段流程"提煉成新的 SKILL.md——就像師傅口傳給徒弟。
四、"為什麼不合成一份？"—— 三條硬約束
有人會想："都是 Markdown，都是長期記憶，直接塞一起不行嗎？"
不行，理由和《為什麼 Hermes Agent 要把記憶分成兩類？USER.md 與 MEMORY.md 的職責》裏 USER.md / MEMORY.md 不能合併的三條約束類似，但更強一些：
理由 1：觸發方式不同
- Memory 是"被 query 命中就召回"（FTS5 + 語義摘要）。
- Skill 是"被場景匹配就裝載"，通常帶觸發條件（
trigger.when: "user asks to write a PR description"）。
合併之後，Agent 會分不清"是要引用一條事實"還是"是要按照一段流程去做"。
理由 2：表達形式不同
- Memory 是短句、事實、條目（"[2026-07-30] agent-demo 前端本地開發端口"）。
- Skill 是流程、模板、約束，往往包含 YAML frontmatter + "步驟 1 / 2 / 3"這類順序結構。
塞在一起，Agent 無法判斷"這段話是背景，還是我此刻要照着執行"。
理由 3：演化速度不同
- Memory 每天都在變（一次會話可能追加 1-2 條）。
- Skill 一旦定型可能幾個月不動（一份 PR 描述格式的 SOP，寫好了半年也沒必要改）。
放在一起會讓"穩定的 SOP"被高頻變化的事實條目沖刷掉——就像把憲法和日曆表訂在同一本子上。
五、一個真實場景：/learn + Memory 一起用
假設你和 Agent 説：
"以後我們團隊寫 PR 描述都按這個格式：一句話總結、變更點、影響範圍、測試情況。另外你要記住，這次的項目叫 agent-demo，前端使用本地開發端口。"
一個訓練良好的 Hermes Agent 應該這樣處理：
- 前半句 → 走
/learn分支，寫入一個新的 Skill：pr-description-format.md，觸發條件是user asks to write a PR description。 - 後半句 → 走
add原子操作，寫入一條 Memory：- [2026-07-30] agent-demo 項目：前端 dev server 使用本地開發端口。
下次你説"幫我寫個 PR 描述"，Agent 會：
- 場景匹配 Skill：裝載
pr-description-format.md到高優先級 prompt。 - query 命中 Memory：知道當前項目叫 agent-demo，使用本地開發端口。
- 二者結合：輸出一個既符合團隊規範、又貼合具體項目的 PR 描述。
"記住事實" + "記住流程" 一起用，效果才會 1 + 1 > 2。
六、Skill Bundle 與 fallback_for_toolsets
Hermes 還給 Skill 加了兩層組織能力：
- Skill Bundle：把相關 Skill 打包成一組，比如"發佈流水線"這個 bundle 裏可能有
pre-release-checklist、changelog-format、deploy-rollback三份 Skill，可以整體啓用/停用/分享。 fallback_for_toolsets：Skill 可以聲明"當調用某個工具集失敗時兜底"。例如git工具集報錯時，觸發一份"手動 rebase 修復步驟"的 Skill。
這兩個能力讓 Skill 從"單點 SOP"變成"可組合的工作方法論"——用户帶給 Agent 的一整套工作方式，都能沉澱成可分享的資產。
七、這不是新概念，但很少被真正落地
事實記憶 + 程序性記憶的分層，其實 AI 圈很早就在談。但真正在工程上做出來，並且讓用户可以看到、可以編輯、可以複用，Hermes 是走得比較靠前的一個——它把每一層都對應到了具體的目錄、字段、命令：
| 能力 | Memory 系 | Skill 系 |
|---|---|---|
| 主存目錄 | ~/.hermes/memories/ | ~/.hermes/skills/ |
| 提示層入口 | MEMORY.md、USER.md | 場景匹配後按需裝載 SKILL.md |
| 沉澱命令 | add / replace / remove（Agent 自動 + /memory pending 審批） | /learn（Agent 自動 + /skills pending 審批） |
| 組織形式 | 條目 + FTS5 全文索引 | 單份 SOP + Bundle + fallback_for_toolsets |
| 演化節奏 | 每天變 | 幾個月不動 |
如果我們把這個分層帶到產品語境，就會得到一個非常有想像力的形態：
- Memory 是"你和 Agent 的共同檔案"。
- Skill 是"你帶給 Agent 的工作方法論"。
這兩樣東西加起來，Agent 才真正成為一個"懂你 + 有方法"的搭檔，而不是一個記性還行的聊天機器人。
八、LightVela：把 Memory 和 Skill 都做成"用户資產"
Hermes 已經把 Memory / Skill 分層做到了工程可用，但它仍然是給開發者的 Markdown。LightVela 的思路，是把這一層從"技術特性"抬升為"用户資產"：
- 個人 Skill 庫：用户可以像收藏 prompt 一樣收藏、編輯、分享自己的 Skill（工作流），並綁定觸發場景。你的寫作套路、評審 SOP、翻譯規範，都可以變成 Skill。
- 個人 Memory 庫：Agent 關於你的一切事實性記憶都對你透明，可以查看、修正、刪除，無需去改
~/.hermes/MEMORY.md。 - 團隊級複用：Skill 和 Memory 都支持團隊維度沉澱——新人一進團隊，就自動擁有團隊的"共同記憶"和"共同方法"，而不需要靠口口相傳。
- 最短路徑：如果你被"兩條腿走路"這套模型打動，但不想自己去搞 Ollama、SSH、systemd、
~/.hermes/備份，LightVela 是把這套模型直接產品化後端給你的最短路徑。
也就是説，你在 LightVela 上"訓練一個 Agent"，本質上是在同時積累兩份資產：一份是關於你的 Memory，一份是你的 Skill 集合。這兩份資產才是長期屬於你的東西，比模型本身更重要。
小結
- Memory ≠ Skill。前者是陳述性記憶（能被講出來的事實），後者是程序性記憶（會做的方法）。
- 分開設計的三條硬約束：觸發方式不同 / 表達形式不同 / 演化速度不同。
- 一個成熟的 Agent 一定要"兩條腿走路"——記事實，也記方法。
- LightVela 把這兩類都做成用户資產，讓"訓練自己的 Agent"從一句口號變成能長期積累的產品體驗。
結語
下一代 Agent 的護城河，不在模型有多大，而在它是否真的"認識你"（Memory），並且"有方法"（Skill）——而這兩者能不能長期穩定跑起來，最終歸結為它是不是一直活着。這正是 LightVela 存在的意義。