跳轉到主要內容
這個單元解決什麼問題三個專案問同一個問題：「這個 agent 學到的東西，我能看見、能版控嗎？」但切入角度不同。OpenClaw 是一套以 TypeScript 寫成的個人 AI 助理框架，把每一個 Skill 寫成 skills/<name>/SKILL.md，讓 agent harness 可讀、可版控、可審查；Hermes-Agent 是 Nous Research 以 Python 打造的自我改進 agent，用 skills/ 目錄存放可累積的程序性知識，並透過 prompt_builder 的三層 system prompt 組裝（stable, context, volatile）把人格、指令、記憶有紀律地注入；NemoClaw 是 NVIDIA 在 2026-03 開源的 reference stack，包覆 OpenClaw 或 Hermes，在 OpenShell 沙箱內提供 YAML 藍圖、網路政策、SSRF 驗證、managed inference 等硬化層，把個人 agent 變成可被企業環境接受的常駐服務。本單元對照三者的差異、能力與特點，談該從中學什麼、該反問自己什麼、日後趨勢。NemoClaw 的深度解析見 05-3。

​
學習目標

  • 能用一張對照表說出三者在定位、核心語言、Skill/harness 設計、記憶機制與企業就緒程度上的關鍵差異
  • 能說出三者共同的設計取向：把 agent 的「規劃與人格」外顯成可讀、可版控的 .md 檔
  • 能具體講出從這三個框架可以學什麼，以及落地時該問自己哪些反問
  • 能評估這類 agent 外殼標準化趨勢與自己目前的落點
  • 能說出 NemoClaw 與 OpenClaw / Hermes 的角色差異：agent 本體 vs 硬化外殼

​
1. 對照表：定位、技術、Skill 設計、記憶與社群

​
1.1 三條路線的一句話定位

專案一句話定位角色
OpenClaw「在 20+ 個通訊管道上替你做事的個人 daemon」agent 本體（個人）
Hermes-Agent「每天早上重組一次人格的自我改進 agent」agent 本體（個人）
NemoClaw「把上述任一 agent 包進 OpenShell 沙箱的硬化外殼」硬化外殼（企業）
OpenClaw 與 Hermes-Agent 解決「agent 怎麼做事」，NemoClaw 解決「企業怎麼接受 always-on agent」。三者不是競爭關係，是疊加關係：NemoClaw 包 OpenClaw 或 Hermes，提供硬化層。

​
1.2 全維度對照

維度OpenClaw (05-1)Hermes-Agent (05-2)NemoClaw (05-3)
角色agent 本體（個人）agent 本體（個人）硬化外殼（企業）
核心語言TypeScript (Node.js)Python（uv 管理）TypeScript + YAML + Bash
授權MITMITApache 2.0
推論後端多家（Anthropic、OpenAI 等）任何 OpenAI-compatible APImanaged inference + model-specific-setup registry
沙箱可選（agents.defaults.sandbox）6 種 terminal 後端強制（OpenShell）
網路政策工具層級工具層級blueprint + policy engine
Skill 存放skills/<name>/SKILL.mdskills/<name>/SKILL.md.agents/skills/（三層分眾）
Skill 載入整體載入漸進揭露（Level 0 / Level 1）透過 nemoclaw-skills-guide skill 取得決策樹
記憶精煉層MEMORY.mdMEMORY.md（凍結快照）沿用內部 agent
詳細日誌memory/YYYY-MM-DD.mdSQLite + FTS5沿用內部 agent
心跳HEARTBEAT.md + Gateway 排程（需確認原始出處）沿用內部 agent + blueprint 控制
人格檔SOUL.md + IDENTITY.mdSOUL.md沿用內部 agent
使用者檔USER.mdUSER.md（volatile）沿用內部 agent
工具慣例TOOLS.md併入 AGENTS.mdblueprint 宣告
多管道路由20+ 平台Telegram、Discord 等（adapter 形式）透過 OpenClaw 內部 agent 繼承
子代理委派透過 cron / ACPdelegate_task（預設 3 個並發）沿用內部 agent
企業就緒否（local-first 個人）否（local-first 個人）是（policy-as-code + 漏洞揭露流程）
政策表達md 檔md 檔YAML blueprint + policies/
升級上游自託管自託管plugin 而非 fork，無需 rebase
為什麼 NemoClaw 列「沿用內部 agent」很多欄NemoClaw 不是另起爐灶，是把 OpenClaw 或 Hermes 整包放進 OpenShell 沙箱。所以 OpenClaw 的 SOUL.md 機制、Hermes 的 SQLite 記憶、心跳排程這些都「繼承」自內部 agent；NemoClaw 自己的強項在「外殼」：藍圖、政策、推論路由、漏洞揭露流程。

​
2. 共同點：把規劃與編排外顯成可讀、可版控的 md 檔

三個專案在技術選擇上看起來南轅北轍（TypeScript vs Python vs TypeScript+YAML），但底層設計哲學高度一致：把 agent 的「人格、規劃、編排」從隱性字串或閉源二進位拉出來，放進人類可讀、可 diff、可版控的 .md 檔。 具體表現：
  • 三者都以 SKILL.md 作為技能的主要表達媒介（前綴 YAML frontmatter，內文 Markdown 指令）
  • 三者都把人格（SOUL.md）獨立成檔，不混在 system prompt 字串裡
  • 三者都把使用者側（USER.md）與專案側（AGENTS.md）分開管理
  • NemoClaw 進一步把「企業政策」也外顯成 YAML（blueprint、policies、model-specific-setup），讓硬化層也走版控與審查流程
這個共同點的工程意義：把通常埋在 system prompt 或程式碼裡的設定層拉到 repo 後，agent 行為就可以被 PR review、可以被 diff、可以移交給下一個人。人不是固定的，設定檔是固定的；設定檔可版控，agent 行為就可在不同 session、不同機器、不同人之間可重現。
同一段「如何使用新工具」在三個框架的形狀假設你要給 agent 一條「讀 PDF 報告並摘要」的技能：
# SKILL.md（OpenClaw / Hermes 通用）
---
name: pdf-summarize
description: 讀 PDF 報告並產生 5 點摘要
---

## 何時用
使用者給了 PDF 檔案路徑且要求摘要時。

## 怎麼做
1. 用 pdfplumber 把每頁文字抽出
2. 用 tiktoken 計算 token 數
3. 超過 8k tokens 時先 chunk 再摘要
4. 用條列格式輸出 5 點

## 不要做
- 不要把 PDF 內容上傳到任何外部 API
- 不要假設使用者的研究領域
這份檔在三個框架都能讀懂、都能版控、都能在 PR review 裡被討論。差別在於 NemoClaw 還會多一份 blueprint 宣告「這個 skill 允許呼叫哪些內網 API、不能呼叫哪些外網 host」。

​
3. 該學什麼：harness 外顯化、可重現、可審查

從這三個框架可以提煉出五個值得內化的設計：
  • Skill as code：把 agent 的操作程序寫成 .md 並加入版控，就像把測試寫成 .spec 一樣，是工程化 agent 行為的最小可行實踐。SKILL.md 是「agent 的 unit test」這層次的東西
  • 記憶有 lifecycle：Hermes-Agent 的 curator 只 archive 不刪除、pinned Skill 豁免自動 transition，這套設計防止 agent 靜默遺忘關鍵知識。OpenClaw 的 MEMORY.md + memory/YYYY-MM-DD.md 分層也是同樣的 lifecycle 思路
  • 工具白名單隔離背景任務：Hermes-Agent 的 background_review.py（需確認原始出處：是否仍為當前實作，骨架未確認）fork 出的評估 agent 只能呼叫記憶與 Skill 管理工具；NemoClaw 的 SSRF validation + network policies 是同樣的隔離哲學：把「能動什麼」與「在動什麼」分開審計
  • .plans/ 或 blueprint 作為決策日誌：功能規劃文件留在倉庫裡，後人（包括 agent）可以看見「為什麼這樣設計」而不只是「實作了什麼」。NemoClaw 的 nemoclaw-blueprint/blueprint.yaml 是這個思路的硬化版
  • 外殼即政策：NemoClaw 把「能不能打外網」這類安全決策從 agent 程式碼搬到外殼（YAML blueprint）強制執行，agent 邏輯與安全政策徹底解耦。這是給「agent 邏輯頻繁升級、但企業政策不能動」的場景的最乾淨解法
不要照抄別人的 .md 反映別人的工作流。OpenClaw 的 SOUL.md 是 OpenClaw 團隊的，Hermes-Agent 的 MEMORY.md 凍結快照假設是 Hermes-Agent 的。照抄常常引入你不需要的約束，甚至安全風險（見 03-3 安全、隱私與供應鏈風險）。先理解「為什麼這樣設計」再決定要不要學這個設計。

​
4. 該反問自己什麼：你的 agent 設定是隱性散落還是外顯成檔

把這三個框架的共同設計翻成自我檢核問題：
  • 你目前的 agent 行為，是散落在 system prompt 字串裡，還是有版本化的 SKILL.md？
  • 你能在 Pull Request diff 裡看到「agent 學到了什麼新行為」嗎？
  • 背景記憶更新是否有可稽核的邊界，還是隱性吃掉了主流程的上下文？
  • 你的 agent 設定如果移交給另一個人，他能在五分鐘內看懂整套 harness 嗎？
  • 你的 agent 升級上游時，硬化層或客製化設定會被原樣保留還是必須 rebase？
  • 你的「能不能打外網」「能不能讀某個目錄」是程式碼層級還是政策層級（policy-as-code）？
如果前三題有兩題以上答「否」，你正處在「agent 行為不可重現、不可審查」的狀態，這正是 OpenClaw / Hermes / NemoClaw 想解決的問題。

​
5. 日後趨勢：agent 外殼標準化、md 檔作為人格與編排載體

幾個值得觀察的趨勢（截至 2026-05 / 2026-06）：
  • SKILL.md + YAML frontmatter 正在成為事實格式。OpenClaw、Hermes-Agent、Claude Code skills、agentskills.io 規範都在收斂這個方向（agentskills.io specification 截至 2026-05；需確認原始出處：是否有跨框架的正式標準化組織或 RFC，骨架未確認）。短期看起來會出現「跨框架相容的最小 SKILL.md 子集」
  • 決策文件成為 agent 可讀的 RAG 輸入。.plans/ 類的文件讓 agent 可以被問「為什麼這樣設計」，這是給 agent 自我解釋能力的最簡單來源
  • NemoClaw 把趨勢往前推一步。把「企業政策」也外顯成可版控的 YAML（blueprint、policies、model-specific-setup），硬化層從「每個 agent 各自為政」推向「reference stack + policy-as-code」。NemoClaw 採 plugin 而非 fork 的方式升級上游 OpenClaw，這個模式（升級上游時硬化層不必 rebase）很可能成為其他個人 agent 框架進入企業環境的範本
  • 未來的基礎建設方向：agent 行為的 CI 測試（像 OpenClaw 已有 .github/codeql/ 做邊界品質掃描）、Skill lifecycle 自動化（curator 模式）、政策測試（NemoClaw 的 preflight）、安全審計單位（OpenShell 沙箱邊界）
這是觀察，不是預言「事實格式收斂」與「升級時硬化層不必 rebase」是目前能驗證的兩件事；其他趨勢仍在演進。把它們當作你設計自己的 agent 設定時的方向感，不要當作不可違背的命運。

​
6. 一句生活比喻

三個框架像三種養寵物的風格：
  • OpenClaw 像一本隨身帶的工作手冊：你把每套 SOP 寫進去，它按照上面做。手冊是你的（可版控），它只是執行者
  • Hermes-Agent 像一個帶著學習日記的實習生：每天早上從家裡的三份文件重組自己（SOUL.md + MEMORY.md + USER.md），做完事會寫日記，明天才看得到。日記在寫但不是即時生效，紀律換成本
  • NemoClaw 像把上述兩種機器人放進強化玻璃展示間：機器人本身沒換（OpenClaw 還是 OpenClaw、Hermes 還是 Hermes），但展示間決定了它能碰什麼、不能碰什麼、看得到誰、誰看得到它。展示間的政策（YAML blueprint）是可版控的，機器人的人格（SOUL.md）也是可版控的，兩層分開管理
你選哪一種取決於你的場景：要 SOP 紀律、要可成長性、還是要企業可接受性。多數人會從 OpenClaw 或 Hermes 開始，撞到企業或 always-on 的需求時再疊 NemoClaw。

​
選型指引

​
動手做

  • 跨框架比較 Skill：分別 clone OpenClaw 與 Hermes-Agent，找出各自 Skill 目錄，比較一個現有 SKILL.md 的 frontmatter 結構與主體風格，回答：「這兩個框架的 Skill，能互相移植嗎？」實驗：在 OpenClaw 的 skills/ 與 Hermes 的 skills/ 互放一份最簡單的 SKILL.md，看啟動時會不會讀到。
  • 外顯化你自己的 agent 設定：挑出三個你目前用 system prompt 字串表達的操作程序，嘗試改寫成一份 SKILL.md 草稿（YAML frontmatter + Markdown 主體）。把它加入版控，送進 PR 給自己 review，看 diff 是不是你預期的那種「小而明確的變更」。
  • 讀 NemoClaw 的 blueprint：直接 clone NemoClaw 倉庫，讀 nemoclaw-blueprint/blueprint.yaml 與 nemoclaw-blueprint/policies/ 一個範例，體會 policy-as-code 的形狀。問自己：你的企業（或研究室）有沒有等效的「政策外顯成檔」實踐？

​
常見誤區

  • 以為「有 .md 就等於有版控」：寫了 SKILL.md 但沒有加入 Git，或者每次覆蓋不留 diff，等於沒有外顯化。沒進版控的 .md 跟 system prompt 字串沒有差別
  • 混淆「記憶（個人偏好與事實）」與「Skill（可重現的操作程序）」：Hermes-Agent 的記憶管理明確分開評估這兩類，不應合併。個人偏好寫進 MEMORY.md / USER.md，操作程序寫進 SKILL.md
  • 把 Hermes-Agent 的自我改進能力誤解為「agent 會自主改變自己的行為而難以預測」：實際上 SOUL.md 凍結快照、curator 只 archive 不刪除、工具白名單隔離，這些設計是主動限制意外突變的護欄。自我改進 ≠ 不可預測
  • 以為 NemoClaw 取代了 OpenClaw 或 Hermes：NemoClaw 是硬化外殼，沒有自己的 AIAgent 主迴圈。沒有 OpenClaw 或 Hermes 跑在裡面，NemoClaw 沒有意義
  • 照搬別人的 SOUL.md 或 SKILL.md：見第 3 節 warning，別人的設定反映別人的工作流與約束

​
自我檢核

通過本單元的標準
  1. 不看文件，能否用一張三欄表（OpenClaw、Hermes-Agent、自己目前的 agent）填出：Skill 存放位置、記憶 lifecycle 設計、背景評估機制？
  2. 能說出 OpenClaw、Hermes-Agent、NemoClaw 三者的角色差異嗎？（提示：哪幾個是 agent 本體，哪個是硬化外殼）
  3. 你能在 Pull Request diff 裡看到「agent 學到了什麼新行為」嗎？答「否」的話，最不透明的那塊是技術債還是有意為之？
  4. 你的工作流是「個人實驗」「always-on daemon」「企業 production」中的哪一種？這個判斷會導向哪個組合（裸 OpenClaw / 裸 Hermes / OpenClaw + NemoClaw / Hermes + NemoClaw）？

​
來源與延伸閱讀

事實主張依官方文件，快變動項標註截至 2026-05。