借鑑 Hermes 優化 OpenClaw：讓你的 AI 學會記、會覆盤、會巡檢
整理版優先睇
本文比較 OpenClaw 同 Hermes Agent 嘅設計哲學，並提供六個具體步驟，教你可以點樣借鑑 Hermes 嘅記憶治理、技能沉澱同自動巡檢嚟優化 OpenClaw，令 AI 越用越聰明。
作者嬌姐係一個 40+ IT 從業者，前榮耀員工，而家專注 AI 效率工具研究。佢發現自己對住「又出新工具」嘅情況感到疲憊，但冷靜分析後，決定唔盲目跟風，而係搞清楚兩個工具嘅本質區別。
OpenClaw 嘅核心係一個「AI 交換機」，透過 Node.js 網關路由將廿幾個平台嘅消息統一處理，社區有超過四萬四千個 Skill，生態成熟。但運維負擔好大——插件越多越易壞，記憶文件會無上限膨脹，需要用戶手動修剪，而且曾經有大規模安全漏洞紀錄。Hermes Agent 就唔同，佢係一個「AI 學徒」，用硬性記憶上限迫使系統自動壓縮提煉，任務完成後會自動生成 Skill 文檔並不斷優化，仲有用戶建模功能越用越瞭解你。
作者嘅整體結論係：與其追逐工具，不如投資可遷移嘅底層能力。佢提供咗一個決策框架幫你揀適合自己嘅工具，仲有六個具體步驟，教你喺 OpenClaw 上加入記憶治理協議、技能沉澱協議、心跳巡檢、Skill 模板同 cron 任務，令你嘅 AI 學會記、會覆盤、會巡檢。
- Hermes 嘅記憶系統用硬性上限迫使 AI 做優先級排序，OpenClaw 嘅無限記憶需手動修剪，呢個係關鍵差異。
- Hermes 會自動將複雜任務嘅成功步驟抽象成 Skill 文檔並持續優化，OpenClaw 需要用戶手動創建。
- 作者提供六個步驟優化 OpenClaw：加記憶治理協議、技能沉澱協議、準備記憶文件、心跳巡檢、創建 Skill 模板、設定 cron 任務。
- 核心問題係你要一個「AI 交換機」定係一個「AI 學徒」，揀工具要揀匹配場景嘅，唔係最新嘅。
- 最重要係投資可遷移嘅底層能力（Prompt 工程、工具設計、記憶架構等），框架會過時，能力唔會。
記憶治理協議（追加到 AGENTS.md）
每次任務結束前，按規則處理記憶：只保留長期有效信息，一次性內容寫到當天文件，過時內容歸檔。
技能沉澱協議（追加到 AGENTS.md）
當任務反覆出現且步驟固定時，整理成 Skill，必須寫明什麼時候用、具體步驟、常見失敗點、點驗證。
Heartbeat 巡檢配置
設定 heartbeat 每 30 分鐘檢查 Gateway、日誌、MEMORY.md 長度、重複任務，用 isolatedSession 避免歷史包袱。
review_memory Skill 模板
整理長期記憶、當天記憶和歸檔內容，步驟包括打開 MEMORY.md、移動內容、驗證。
開頭：跟唔上嘅疲憊，同一個更深嘅問題
作者嬌姐話，佢三個月前先折騰好 OpenClaw，由 npm install 到網關配置，再到 Telegram 聯通，點知 Hermes Agent 就出咗。社區一片叫好聲，但佢嘅第一反應係疲憊。
佢認為「換定唔換」呢個問題，本質係要搞清楚兩個工具係咪解決同一個問題。如果唔係，噉「換」就係個偽命題。呢篇文章唔係評測，而係一次誠實嘅技術思考同決策框架。
「停止追逐工具，開始投資能力」
OpenClaw 同 Hermes 嘅核心差異
OpenClaw 嘅核心係路由與控制，架構似一個 AI 交換機，Node.js 網關管理多平台訊息。佢嘅優勢係渠道覆蓋極廣（22+ 平台），社區 Skill 超過四萬四千個，但痛點係插件系統易出問題、記憶文件無限膨脹需手動修剪、安全紀錄有 CVE。
OpenClaw 係一個你配置嘅工具
Hermes Agent 由 Nous Research 開發，Python 編寫，核心係記憶與自我進化。佢用硬性記憶上限（Agent 2200 字符、用戶畫像 1375 字符）迫使系統做信息優先級排序，舊對話會被 LLM 壓縮提煉再寫入長期存儲。自動 Skill 生成係最大亮點：完成複雜任務後會自動將成功步驟抽象成 Markdown 文檔，下次直接複用。
Hermes 係一個隨你成長嘅隊友
- 核心哲學：OpenClaw 路由與控制 vs Hermes 自我進化
- 記憶系統：OpenClaw 無上限 Markdown 需手動修剪 vs Hermes 硬性上限自動壓縮
- Skill 來源：OpenClaw 手動創建 vs Hermes 任務完成後自動生成
- 用戶建模：OpenClaw 無 vs Hermes Honcho Dialectic 持續建模
- 運維負擔：OpenClaw 高（插件+記憶+網關） vs Hermes 低（自維護）
借鑑 Hermes 優化 OpenClaw：六個步驟
- 1 加「工作規矩」：喺 AGENTS.md 追加記憶治理協議同技能沉澱協議，明確定義點樣處理記憶同整理 Skill。
- 2 準備記憶文件：建立 MEMORY.md（長期記憶）、memory/YYYY-MM-DD.md（當日記錄）、memory/archive.md（歸檔），形成三層結構。
- 3 加一個最小 heartbeat：建立 HEARTBEAT.md，每次心跳檢查 Gateway、日誌、記憶長度、重複任務，異常時直接報告。
- 4 建立 Skill 模板：例如 review_memory（整理記憶）同 diagnose_gateway（排查網關），每個 Skill 要寫明咩時候用、步驟、常見失敗點、點驗證。
- 5 打開 heartbeat 配置：設定 every 30 分鐘，isolatedSession 為 true，指定活躍時段。
- 6 加兩個每週自動整理任務：用 cron 每週整理記憶同技能，清理過時內容，補充常見失敗點。
## 記憶治理協議
每次任務結束前，按呢個規則處理記憶：
1. `MEMORY.md` 只保留長期有效的信息：
- 用戶長期偏好
- 反覆出現的工作方式
- 最近 14 天內仍有效的重要決定
2. 下面呢啲內容不要長期留在 `MEMORY.md`：
- 一次性任務過程
- 臨時背景
- 已經過期的信息
3. 一次性內容寫到當天文件：
- `memory/YYYY-MM-DD.md`
4. 過時但又不想徹底刪掉的內容，移動到：
- `memory/archive.md`
5. 當一個任務已經完成：
- 在當天記憶裏寫一條結果摘要
- 不要把全部過程塞進 `MEMORY.md`遷移定留低？同埋「跟唔上」嘅真正解藥
如果決定由 OpenClaw 遷移到 Hermes，作者提供咗六步指引：備份數據、一行命令安裝、dry-run 預覽、正式遷移、CLI 驗證、並行跑一個禮拜。佢特別提醒，複雜 Skill 有條件分支嘅需要手動檢查。
唔使急住卸載 OpenClaw —— 並行跑一週，睇下自己打開邊個多啲
但作者最後話，最重要嘅唔係揀邊個工具，而係理解底層模式。無論 OpenClaw 定 Hermes，Prompt 工程、工具設計、記憶架構、Agent 調試呢啲能力係可遷移嘅。框架會過時，能力唔會。所以與其焦慮「跟唔上」，不如專注投資呢啲底層能力。
先關注後閲讀，嬌姐怕失去上進嘅你
文末嬌姐整理咗 openclaw 所有文章連結
想了解嬌姐，㩒文末連結
講一個好多人唔敢講出口嘅感受：我跟唔上了。唔係跟不上某一個工具嘅更新日誌，而係跟不上「又出咗個新嘢，你要睇下」呢件事本身。
三個月前搞 OpenClaw，由 npm install 到網關配置，由插件調試到 Telegram 聯通，好不容易先砌到一套用得嘅個人 AI 助手工作流程——然後 Hermes Agent 就出咗。Nous Research 出品，GitHub star 數飆升，社區裏面一片「呢個先係終極形態」嘅聲音。
你第一個反應係咩？我第一個反應係疲憊。
但係攰完之後，仲係要諗清楚呢件事。因為「換唔換」呢個問題，本質上係一個更深嘅問題：呢兩個工具到底係咪解決緊同一個問題？如果唔係，咁「換」本身就係個偽命題。呢篇文章唔係產品評測，唔係教學，而係一次誠實嘅技術思考，同一個幫你做決策嘅框架。
一、OpenClaw 到底做緊乜
好多人將 OpenClaw 理解成「一個聊天機械人框架」，呢個理解太淺層。OpenClaw 嘅核心唔係傾偈，係路由。
佢嘅架構係一個 Node.js 網關守護進程（Gateway），透過 WebSocket 管理曬所有會話、權限、頻道同技能調度。你可以將佢想像成一個「AI 交換機」——WhatsApp、Telegram、Discord、Slack、iMessage…… 22 個以上平台嘅訊息入嚟，經過統一嘅路由邏輯，分發俾唔同嘅 Agent 實例處理。發展到今日，OpenClaw 嘅社區 skill 數量已經超過 44,000 個，係真實嘅生態積累。
呢個設計嘅優勢好明顯
- 多渠道統一入口：
一套 Agent 邏輯覆蓋曬你所有通訊平台，喺 Telegram 叫佢幫你查嘢，轉去 Slack 佢仲記得返上文下理。 - 插件生態豐富：
瀏覽器控制、定時任務（cron）、Canvas 可視化工作區，甚至語音喚醒（macOS/iOS）應有盡有。 - 模型可插拔：
換模型供應商唔影響網關，係好好嘅工程解耦。
但三個月用落嚟，痛點都好真實
插件系統係把雙刃劍。社區有個帖嘅標題好說明問題——「You don't need a lot of plugins (and they're bad for your system)」。作者砍走大部分插件之後，啟動速度快咗 40%，內存降咗 60%，四個月冇遇過一次 breaking update。插件嘅問題唔係功能唔得，而係每一個插件都係一個潛在嘅故障源。
記憶系統係另一個慢性痛點。OpenClaw 嘅記憶係基於無上限嘅 Markdown 檔案加可選向量嵌入。聽落靈活，但「無上限」即係你要自己管理。用咗三個月，記憶檔案脹到幾萬字，入面充滿咗過時嘅偏好同重複嘅上文下理——你需要定期手動修剪，否則 Agent 嘅注意力會被垃圾資訊沖淡。
安全警示：2026 年 3 月嘅 Shodan 掃描發現超過 13.5 萬個 OpenClaw 實例暴露喺公網而且唔使認證，相關 CVE 漏洞嘅利用代碼喺 GitHub 上出現得好快。呢個係生態擴張太快嘅代價，自託管用戶要特別注意認證配置。
本質上，OpenClaw 俾咗你一個非常強大嘅基礎設施，但係運維負擔落咗喺用戶身上。佢比較似一個你需要持續維護嘅伺服器，而唔係一個越用越省心嘅助手。
二、Hermes Agent 到底賭緊乜
Hermes Agent 由 Nous Research 開發，MIT 協議開源，Python 編寫。呢個團隊同時做緊 Hermes 模型系列（Hermes 4 喺 2025 年引入咗混合推理同大規模合成數據生成）同 Atropos RL 訓練框架。Hermes Agent 係佢哋將「訓練更強嘅模型」同「讓模型持續運行並自我進化」呢兩條線合併嘅產物。
如果話 OpenClaw 賭嘅係「路由同控制」，Hermes 賭嘅係一個完全唔同嘅命題：記憶同自我進化。
持久記憶：有限制先有紀律
Hermes 嘅記憶系統同樣用 SQLite + FTS5 全文檢索，但做咗一個關鍵嘅設計決策：硬性字符上限——Agent 記憶 2200 字符，用戶畫像 1375 字符，得咁多，唔可以無限擴展。
呢個睇落係限制，實際上係一個極之聰明嘅工程選擇。因為空間有限，Agent 被迫做「資訊優先級排序」——佢必須判斷乜嘢值得記住、乜嘢可以遺忘，好似人類嘅工作記憶咁。舊嘅對話唔係就咁掉咗，而係俾 LLM 壓縮提煉成關於你嘅關鍵洞察，再寫入長期儲存。
類比：OpenClaw 嘅記憶好似一個無限容量嘅筆記簿，乜都塞入去，最後你要自己整理。Hermes 嘅記憶好似一個嚴格限制頁數嘅手帳——正因為得咁幾頁，每一條都經過深思熟慮。
自動 Skill 生成：Agent 自己寫 SOP
呢個係 Hermes 最得意嘅特性。當你完成一個複雜任務（涉及多次工具調用）時，Agent 會自動評估操作流程，將成功嘅步驟抽像成一個 Markdown 格式嘅「Skill 文檔」儲存落嚟，記錄完整嘅操作步驟、踩過嘅坑同驗證方法。下次遇到類似任務，直接重用，而且每次執行之後仲會自動優化呢個 Skill。
OpenClaw 都有 Skill，但係需要用戶手動創建同維護。Hermes 嘅做法更接近一個「會寫工作手冊嘅實習生」——你帶住佢做一次，佢自己將流程記低，下次唔使你教。值得留意嘅係，兩者嘅 Skill 檔案格式兼容（都係跟 agentskills.io 開放標準），呢個為遷移留咗個入口。
用戶建模：越用越明你
Hermes 仲有一個最容易被忽略嘅模塊——用戶建模（Honcho Dialectic）。佢會慢慢建立一個關於你係邊個、你點樣工作嘅模型：你嘅格式偏好、你成日做邊類任務、你喺咩情況下會否定佢嘅輸出。普通 Agent 將每個用戶都當陌生人對待，Hermes 就用真實使用數據建立「你」嘅畫像。
極致嘅部署靈活性
模型切換係一條命令嘅事——OpenAI、Anthropic、OpenRouter（200 + 模型）、本地 Ollama/vLLM，隨時換，唔使改代碼。執行後端支援六種：本地、Docker、SSH、Daytona、Singularity、Modal。重計算任務可以掟去 Serverless 度執行，空閒時休眠，唔燒錢。48 個內置工具開箱即用，原生支援 MCP 協議。訊息平台支援 Telegram、Discord、Slack、WhatsApp、Signal、Matrix、飛書、企微等 14 個以上平台，而且強調跨平台會話連續性。
三、正面對比：兩種哲學嘅碰撞
唔想做模糊嘅「各有千秋」式總結。以下係每個關鍵維度嘅直接對比：
核心差異一句話：OpenClaw 係一個你配置嘅工具，Hermes 係一個隨你成長嘅隊友。OpenClaw 今日係點樣，六個月後仲係嗰個樣。Hermes 今日係點樣，六個月後取決於你點樣用佢。
四、你真係需要諗清楚嘅問題
對比表格容易做，但真正嘅決策唔喺表格入面。你需要回答嘅唔係「邊個好啲」，而係：你想要一個「AI 交換機」，定係一個「AI 學徒」？
繼續用 適合繼續用 OpenClaw 嘅場景
核心訴求係多平台訊息自動化，需要接入 10 個以上 IM 渠道
需要 iMessage 或語音喚醒等 Hermes 未支援嘅特定能力
喜歡 Canvas 可視化操作界面，或已建立成熟插件工作流程
工作流係一次性、冇規律嘅任務，唔需要 Agent 累積經驗成長
考慮遷移 適合遷移到 Hermes 嘅場景
核心訴求係 Agent 越用越聰明，有重複性嘅結構化工作流程
重度使用 CLI，係開發者或研究者，想成日切換模型或行本地模型
對安全性有更高要求，唔想花時間運維記憶同插件
需要 Serverless 執行重計算任務，或正在做 AI 模型訓練研究
注意：將「更新」等同於「更好」係最常見嘅誤區。Hermes 比 OpenClaw 遲出、star 升得快——但呢個唔代表佢對你更好。揀工具要揀匹配你場景嘅，而唔係揀最新嘅。
五、搞咗幾個月，你到底收穫咗乜
好多嘅焦慮本質上係：「我花咗咁多時間喺一個工具度，而家換咗係咪全部白費？」唔係。你得到嘅嘢比你以為嘅多。
- 你理解咗 AI Agent 嘅核心架構。
網關、路由、會話管理、工具調用、權限控制——呢啲概念唔屬於 OpenClaw，佢哋屬於整個 Agent 領域。你喺 OpenClaw 度踩過嘅坑，喺 Hermes 度、喺未來任何一個框架度都係可以重用嘅經驗。 - 你積累咗可遷移嘅資產。
Skill 檔案格式兼容，記憶可以導入，API Key 通用。呢個唔係由零開始，而係喺已有嘅地基上面起新樓。 - 你建立咗調試 Agent 嘅直覺。
幾時係 prompt 嘅問題，幾時係工具調用嘅問題，幾時係上文下理窗口溢出——呢種直覺只有喺實際使用先會生出來，睇一百篇教學都唔及自己 debug 三日。 - 你知道咗自己真正需要乜。
三個月前你可能覺得「22 個平台全覆蓋」好重要，而家你可能發現自己 90% 嘅使用只喺 Telegram 同終端。知道自己唔需要乜嘢，本身就係巨大嘅收穫。
六、如果決定遷移，點樣做
好消息係：Hermes 係目前極少數主動為競爭對手用戶鋪好遷移路嘅工具之一，呢個本身就說明咗態度同自信。
01備份 OpenClaw 數據
遷移工具唔會修改 OpenClaw 嘅檔案，但備份係好習慣。
cp -r ~/.openclaw ~/.openclaw_backup_$(date +%Y%m%d)02一行命令安裝 Hermes
自動處理 Python 3.11、依賴同配置，唔需要 sudo，大約 60 秒完成。
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash03先做 dry-run 預覽，唔實際執行
重點檢查：Skill 檔案、MEMORY.md、SOUL.md 人格設定、訊息平台配置、API key。
hermes claw migrate --dry-run04確認後正式執行遷移
導入內容：記憶檔案、用戶畫像、Skill 文檔（格式自動轉換）、API key、訊息平台配置。
hermes claw migrate05CLI 驗證後再接訊息平台
首先喺終端行幾個任務，確認 Skill 加載正常、記憶可以召回，再重新接入 Telegram 等訊息平台。問題排查用 hermes doctor。
06唔一定要卸載 OpenClaw——並行行一個星期
Hermes 用 Python，OpenClaw 用 Node.js，兩者喺同一部伺服器上唔衝突。並行行一個星期之後問自己：我打開邊個多啲？答案就係你嘅答案。
遷移提示：簡單 Skill（單步驟操作）幾乎無縫轉換；複雜 Skill（有條件分支）要手動檢查；引用了 OpenClaw 特有 API 嘅 Skill 需要重寫。遷移之後唔好急住手動優化 Skill——讓 Hermes 嘅 learning loop 自動做呢件事。
七、借鏡 Hermes 嘅設計理念點樣優化 OpenClaw
目標：首先令 agent 變成會記、會覆盤、會巡檢，唔搞複雜自動化，按順序執行
第 1 步：幫 agent 加「工作規矩」
打開 AGENTS.md，喺最後加上以下內容：
## 記憶治理協議 每次任務結束前，按這個規則處理記憶：1. `MEMORY.md` 只保留長期有效的信息： - 用戶長期偏好 - 反覆出現的工作方式 - 最近 14 天內仍有效的重要決定 2. 下面這些內容不要長期留在 `MEMORY.md`： - 一次性任務過程 - 臨時背景 - 已經過期的信息 3. 一次性內容寫到當天文件： - `memory/YYYY-MM-DD.md` 4. 過時但又不想徹底刪掉的內容，移動到： - `memory/archive.md` 5. 當一個任務已經完成： - 在當天記憶裏寫一條結果摘要 - 不要把全部過程塞進 `MEMORY.md` ## 技能沉澱協議 當一個任務滿足下麪條件時，整理成 Skill： - 這個任務以後還會反覆做 - 步驟比較固定 - 做錯的地方比較類似 - 有明確的檢查方法 滿足條件後，創建文件： - `skills//SKILL.md` Skill 裏必須寫清楚 4 件事： 1. 什麼時候用 2. 具體步驟 3. 常見失敗點 4. 怎麼驗證有沒有成功 下面這些不要做成 Skill： - 一次性探索 - 每次步驟都不一樣的任務 - 強依賴臨時上下文的任務
第 2 步：準備記憶檔案
1）長期記憶檔案
文件：MEMORY.md
# MEMORY.md ## 用戶長期偏好 - 喜歡直接、簡潔、能落地的建議 - 不喜歡空話和大段鋪墊 - 優先看可執行步驟和模板 ## 長期工作原則 - 不清楚的需求先問清楚 - 交付前自己驗證 - 重要結論儘量多方確認 - 原則性要求要長期記住 ## 當前有效習慣 - 技術問題先查本地資料，再查外部資料 - 做完任務後記錄到 `memory/YYYY-MM-DD.md`2）當天記憶目錄
創建目錄：memory/
文件：memory/2026-04-09.md
# 2026-04-09 ## 今天做了什麼 - 給 agent 增加了記憶治理協議 - 給 agent 增加了技能沉澱協議 ## 今天得到的結論 - 長期記憶要瘦身 - 重複流程適合做成 Skill3）歸檔檔案
文件：memory/archive.md
# archive ## 已歸檔 - 2026-04-01：一次性測試過程，已完成 - 2026-04-03：臨時討論內容，已失效記憶三層結構：
第 3 步：幫 agent 一個最小可用嘅 heartbeat
作用：巡檢，只檢查異常，唔做複雜操作
文件：HEARTBEAT.md
# heartbeat 工作清單 每次收到 heartbeat 時，按順序檢查： 1. 檢查 Gateway 是否正常 2. 檢查最近日誌裏有沒有新的嚴重報錯 3. 檢查 `MEMORY.md` 是否明顯變長、變亂 4. 檢查最近有沒有適合整理成 Skill 的重複任務 5. 如果沒有需要處理的事，回覆：HEARTBEAT_OK 6. 如果發現異常，直接說清楚： - 問題是什麼 - 影響是什麼 - 建議怎麼處理第 4 步：創建第一個 Skill 模板
創建目錄：skills/review_memory/skills/diagnose_gateway/
模板 1：整理記憶
文件：skills/review_memory/SKILL.md
name: review_memory description: 整理長期記憶、當天記憶和歸檔內容，避免上下文越來越亂 # 什麼時候用 當出現下面情況時使用： - `MEMORY.md` 變長了 - 有很多一次性內容混進長期記憶 - 任務做完後需要整理結論 # 步驟 1. 打開 `MEMORY.md` 2. 找出不適合長期保留的內容 3. 把一次性內容移動到 `memory/YYYY-MM-DD.md` 4. 把過期但還想保留的內容移動到 `memory/archive.md` 5. 保證 `MEMORY.md` 裏只剩長期有效的信息 # 常見失敗點 - 把任務過程全塞進 `MEMORY.md` - 把已經失效的信息繼續長期保留 - 歸檔了，但沒有在當天記憶裏寫摘要 # 怎麼驗證 檢查這 3 件事： 1. `MEMORY.md` 裏只剩長期有效信息 2. 當天發生的事寫進了 `memory/YYYY-MM-DD.md` 3. 舊信息被移動到了 `memory/archive.md`模板 2：排查 Gateway
文件：skills/diagnose_gateway/SKILL.md
name: diagnose_gateway description: 排查 OpenClaw Gateway 是否異常，檢查監聽、日誌和恢復情況 # 什麼時候用 當出現下面情況時使用： - 消息沒有正常發送 - heartbeat 異常 - cron 沒執行 - 用戶懷疑 Gateway 掛了 # 步驟 1. 檢查 Gateway 端口是否監聽 2. 查看最近日誌裏的 error、fail、exception 3. 判斷問題屬於哪一類： - 進程沒啓動 - 配置錯誤 - 權限或認證問題 4. 給出修復動作 5. 修復後再檢查一次 # 常見失敗點 - 只看報錯表面，不看日誌上下文 - 修完後不驗證 - 把配置問題誤判成服務掛了 # 怎麼驗證 至少確認下面兩件事： 1. 相關端口恢復監聽 2. 實際觸發一次相關功能，確認恢復第 5 步：將 heartbeat 配置開啟
{ id: "sysmon", heartbeat: { every: "30m", target: "last", lightContext: true, isolatedSession: true, activeHours: { start: "08:00", end: "22:00", timezone: "Asia/Shanghai" } } }第 6 步：加兩個每星期自動整理任務
任務 1：每星期整理記憶
openclaw cron add \ --name "memory-review" \ --cron "30 10 * * 0" \ --session isolated \ --message "檢查 MEMORY.md、memory/YYYY-MM-DD.md、memory/archive.md，清理過時內容，只保留長期有效信息，並把結果寫入當天記憶。" \ --no-deliver任務 2：每星期整理技能
openclaw cron add \ --name "skill-review" \ --cron "0 10 * * 0" \ --session isolated \ --message "檢查 skills 目錄，合併重複技能，刪除明顯過時的技能，補充常見失敗點和驗證方法，並把結論寫入當天記憶。" \ --no-delive八、關於「跟不上」呢件事
2026 年嘅 AI 工具生態，有啲似 2012 年嘅前端框架大戰。每個月都有新嘅「顛覆性」項目，每個社區都話「今次唔同」。Backbone、Ember、Angular、React、Vue……當年嘅前端開發者都經歷過完全一樣嘅焦慮。
返轉頭睇，嗰場戰爭嘅贏家唔係押啱咗某個框架嘅人，而係理解咗底層模式嘅人。組件化、單向數據流、虛擬 DOM——呢啲概念超越咗任何一個具體框架，喺每一個新框架度都可以快速上手。
AI Agent 領域都係一樣。唔理框架點變，有啲能力係唔會過時嘅：
- Prompt 工程
——點樣俾 Agent 落精確嘅指令 - 工具設計
——點樣定義好嘅工具接口（MCP 正在成為標準） - 記憶架構
——點樣管理上文下理、做資訊壓縮同檢索 - Agent 調試
——點樣定位「Agent 做咗蠢事」嘅根因 - 安全邊界
——點樣讓 Agent 有足夠權限做嘢，但又唔會失控
呢啲能力，喺 OpenClaw 度鍛煉過嘅，喺 Hermes 度直接用得返，喺未來任何一個 Agent 框架度都同樣適用。所以我嘅建議唔係「快啲換 Hermes」，亦唔係「守住 OpenClaw」，而係：
停止追逐工具，開始投資能力。揀一個目前最適合你場景嘅框架，深度使用佢，但將注意力放喺啲可遷移嘅底層能力上面。框架會過時，能力唔會。
關於 OpenClaw 資料包同系列文章
配套資料包
私信 kekohu 獲取，內容不定期持續更新。
注意：付費社羣包含資料包全部內容，唔使重複購買。
OpenClaw 系列文章
持續更新，建議每篇認真閲讀
配置與理解
咪俾人呃，OpenClaw 可以 24 小時開工——但你要先做啱呢 6 件事
紅咗三個月嘅「龍蝦」，普通人裝咗真係有用咩？
用 OpenClaw 醫好 AI 失憶：開關、精簡、外掛三步走
多 Agent 與協作
技能與工具
實戰與案例
排錯與安全
關於嬌姐
40+ IT 從業者，前榮耀員工，而家專注 AI 效率工具研究與實踐。持續輸出 OpenClaw 及 AI 工具嘅乾貨教學同落地案例，間中分享職場思考同生活感悟。
提示：覺得有用，俾 like、關注、轉發，係我持續創作嘅動力。
先關注後閲讀，嬌姐怕失去上進的你
文末嬌姐整理openclaw所有文章連結
想了解嬌姐點擊文末連結
說一個很多人不敢說出口的感受：我跟不上了。不是跟不上某一個工具的更新日誌，而是跟不上「又出了一個新東西，你得看看」這件事本身。
三個月前折騰 OpenClaw，從 npm install 到網關配置，從插件調試到 Telegram 聯通，好不容易搭出一套能用的個人 AI 助手工作流——然後 Hermes Agent 來了。Nous Research 出品，GitHub star 數飆漲，社區裏一片「這才是終極形態」的聲音。
你的第一反應是什麼？我的第一反應是疲憊。
但疲憊之後，還是要想清楚這件事。因為「換不換」這個問題，本質上是一個更深的問題：這兩個工具到底在解決同一個問題嗎？如果不是，那「換」本身就是個偽命題。這篇文章不是產品評測，不是教程，是一次誠實的技術思考，和一個幫你做決策的框架。
一、OpenClaw 到底在做什麼
很多人把 OpenClaw 理解成「一個聊天機器人框架」，這個理解太淺了。OpenClaw 的核心不是聊天，是路由。
它的架構是一個 Node.js 網關守護進程（Gateway），通過 WebSocket 管理所有的會話、權限、頻道和技能調度。你可以把它想象成一個「AI 交換機」——WhatsApp、Telegram、Discord、Slack、iMessage…… 22 個以上平台的消息進來，經過統一的路由邏輯，分發給不同的 Agent 實例處理。發展到今天，OpenClaw 的社區 skill 數量已經超過 44,000 個，這是真實的生態積累。
這個設計的優勢很明顯
- 多渠道統一入口：
一套 Agent 邏輯覆蓋你所有的通訊平台，在 Telegram 上讓它幫你查東西，切到 Slack 上它還記得上下文。 - 插件生態豐富：
瀏覽器控制、定時任務（cron）、Canvas 可視化工作區，甚至語音喚醒（macOS/iOS）應有盡有。 - 模型可插拔：
換模型提供商不影響網關，這是好的工程解耦。
但三個月用下來，痛點也很真實
插件系統是把雙刃劍。社區裏有個帖子標題就很說明問題——「You don't need a lot of plugins (and they're bad for your system)」。作者砍掉大部分插件後，啓動速度快了 40%，內存降了 60%，四個月沒遇到一次 breaking update。插件的問題不是功能不行，而是每一個插件都是一個潛在的故障源。
記憶系統是另一個慢性痛點。OpenClaw 的記憶基於無上限的 Markdown 文件加可選向量嵌入。聽起來靈活，但「無上限」意味着你得自己管理。用了三個月，記憶文件膨脹到幾萬字，裏面充滿了過時的偏好和重複的上下文——你需要定期手動修剪，否則 Agent 的注意力會被垃圾信息稀釋。
安全警示：2026 年 3 月的 Shodan 掃描發現超過 13.5 萬個 OpenClaw 實例暴露在公網且無需認證，相關 CVE 漏洞的利用代碼在 GitHub 上出現得很快。這是生態擴張過快的代價，自託管用戶需要格外注意認證配置。
本質上，OpenClaw 給了你一個非常強大的基礎設施，但運維負擔落在了用戶身上。它更像一個需要你持續維護的服務器，而不是一個越用越省心的助手。
二、Hermes Agent 到底在賭什麼
Hermes Agent 由 Nous Research 開發，MIT 協議開源，Python 編寫。這個團隊同時在做 Hermes 模型系列（Hermes 4 在 2025 年引入了混合推理和大規模合成數據生成）和 Atropos RL 訓練框架。Hermes Agent 是他們把「訓練更強的模型」和「讓模型持續運行並自我進化」這兩條線合併的產物。
如果說 OpenClaw 賭的是「路由和控制」，Hermes 賭的是一個完全不同的命題：記憶和自我進化。
持久記憶：有限制才有紀律
Hermes 的記憶系統同樣用 SQLite + FTS5 全文檢索，但做了一個關鍵的設計決策：硬性字符上限——Agent 記憶 2200 字符，用戶畫像 1375 字符，就這麼多，不可無限擴展。
這看起來是限制，實際上是個極其聰明的工程選擇。因為空間有限，Agent 被迫做「信息優先級排序」——它必須判斷什麼值得記住、什麼可以遺忘，就像人類的工作記憶一樣。舊的對話不是簡單丟棄，而是被 LLM 壓縮提煉成關於你的關鍵洞察，再寫入長期存儲。
類比：OpenClaw 的記憶像一個無限容量的筆記本，什麼都往裏塞，最終你得自己整理。Hermes 的記憶像一個嚴格限制頁數的手賬——正因為只有這麼幾頁，每一條都經過深思熟慮。
自動 Skill 生成：Agent 自己寫 SOP
這是 Hermes 最有意思的特性。當你完成一個複雜任務（涉及多次工具調用）時，Agent 會自動評估操作流程，把成功的步驟抽象成一個 Markdown 格式的「Skill 文檔」存儲下來，記錄完整的操作步驟、踩過的坑和驗證方法。下次遇到類似任務，直接複用，而且每次執行後還會自動優化這個 Skill。
OpenClaw 也有 Skill，但需要用戶手動創建和維護。Hermes 的做法更接近一個「會寫工作手冊的實習生」——你帶着它做一遍，它自己把流程記下來，下次不用你教了。值得注意的是，兩者的 Skill 文件格式兼容（都遵循 agentskills.io 開放標準），這為遷移留了口子。
用戶建模：越用越懂你
Hermes 還有一個最容易被忽視的模塊——用戶建模（Honcho Dialectic）。它會逐漸建立一個關於你是誰、你怎麼工作的模型：你的格式偏好、你常做哪類任務、你在什麼情況下會否定它的輸出。普通 Agent 把每個用戶都當陌生人對待，Hermes 在用真實使用數據建立「你」的畫像。
極致的部署靈活性
模型切換是一條命令的事——OpenAI、Anthropic、OpenRouter（200 + 模型）、本地 Ollama/vLLM，隨時換，不改代碼。執行後端支持六種：本地、Docker、SSH、Daytona、Singularity、Modal。重計算任務可以甩到 Serverless 上跑，空閒時休眠，不燒錢。48 個內置工具開箱即用，原生支持 MCP 協議。消息平台支持 Telegram、Discord、Slack、WhatsApp、Signal、Matrix、飛書、企微等 14 個以上平台，並且強調跨平台會話連續性。
三、正面對比：兩種哲學的碰撞
不想做模糊的「各有千秋」式總結。以下是每個關鍵維度的直接對比：
核心差異一句話：OpenClaw 是一個你配置的工具，Hermes 是一個隨你成長的隊友。OpenClaw 今天是什麼樣，六個月後還是那個樣子。Hermes 今天是什麼樣，六個月後取決於你怎麼用它。
四、你真正需要想清楚的問題
對比表格好做，但真正的決策不在表格裏。你需要回答的不是「哪個更好」，而是：你想要一個「AI 交換機」，還是一個「AI 學徒」？
繼續用 適合繼續用 OpenClaw 的場景
核心訴求是多平台消息自動化，需要接入 10 個以上 IM 渠道
需要 iMessage 或語音喚醒等 Hermes 尚未支持的特定能力
喜歡 Canvas 可視化操作界面，或已建立成熟插件工作流
工作流是一次性、無規律任務，不需要 Agent 積累經驗成長
考慮遷移 適合遷移到 Hermes 的場景
核心訴求是 Agent 越用越聰明，有重複性的結構化工作流
重度使用 CLI，是開發者或研究者，想頻繁切換模型或跑本地模型
對安全性有更高要求，不想花時間運維記憶和插件
需要 Serverless 執行重計算任務，或正在做 AI 模型訓練研究
注意：把「更新」等同於「更好」是最常見的誤區。Hermes 比 OpenClaw 晚出來、star 漲得快——但這不意味着它對你更好。選工具要選匹配你場景的，而不是選最新的。
五、折騰了幾個月，你到底收穫了什麼
很多人的焦慮本質上是：「我花了這麼多時間在一個工具上，現在換了是不是全白費了？」不是。你獲得的東西比你以為的多。
- 你理解了 AI Agent 的核心架構。
網關、路由、會話管理、工具調用、權限控制——這些概念不屬於 OpenClaw，它們屬於整個 Agent 領域。你在 OpenClaw 上踩過的坑，在 Hermes 上、在未來任何一個框架上都是可複用的經驗。 - 你積累了可遷移的資產。
Skill 文件格式兼容，記憶可以導入，API Key 通用。這不是從零開始，這是在已有地基上蓋新樓。 - 你建立了調試 Agent 的直覺。
什麼時候是 prompt 的問題，什麼時候是工具調用的問題，什麼時候是上下文窗口溢出——這種直覺只有在實際使用中才能長出來，看一百篇教程都不如自己 debug 三天。 - 你知道了自己真正需要什麼。
三個月前你可能覺得「22 個平台全覆蓋」很重要，現在你可能發現自己 90% 的使用只在 Telegram 和終端。知道自己不需要什麼，本身就是巨大的收穫。
六、如果決定遷移，怎麼做
好消息是：Hermes 是目前極少數主動為競爭對手用戶鋪好遷移路的工具之一，這本身說明了態度和自信。
01備份 OpenClaw 數據
遷移工具不會修改 OpenClaw 的文件，但備份是好習慣。
cp -r ~/.openclaw ~/.openclaw_backup_$(date +%Y%m%d)02一行命令安裝 Hermes
自動處理 Python 3.11、依賴和配置，不需要 sudo，約 60 秒完成。
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash03先做 dry-run 預覽，不實際執行
重點檢查：Skill 文件、MEMORY.md、SOUL.md 人格設定、消息平台配置、API key。
hermes claw migrate --dry-run04確認後正式執行遷移
導入內容：記憶文件、用戶畫像、Skill 文檔（格式自動轉換）、API key、消息平台配置。
hermes claw migrate05CLI 驗證後再接消息平台
先在終端跑幾個任務，確認 Skill 加載正常、記憶可以召回，再重新接入 Telegram 等消息平台。問題排查用 hermes doctor。
06不一定要卸載 OpenClaw——並行跑一週
Hermes 用 Python，OpenClaw 用 Node.js，兩者在同一台服務器上不衝突。並行跑一週後問自己：我打開哪個更多？答案就是你的答案。
遷移提示：簡單 Skill（單步驟操作）幾乎無縫轉換；複雜 Skill（有條件分支）需手動檢查；引用了 OpenClaw 特有 API 的 Skill 需要重寫。遷移後不要急着手動優化 Skill——讓 Hermes 的 learning loop 自動做這件事。
七、借鑑hermes的設計理念如何優化openclaw
目標：先讓 agent 變成會記、會覆盤、會巡檢，不碰複雜自動化，按順序執行
第 1 步：給 agent 加「工作規矩」
打開 AGENTS.md，在最後追加以下內容：
## 記憶治理協議 每次任務結束前，按這個規則處理記憶：1. `MEMORY.md` 只保留長期有效的信息： - 用戶長期偏好 - 反覆出現的工作方式 - 最近 14 天內仍有效的重要決定 2. 下面這些內容不要長期留在 `MEMORY.md`： - 一次性任務過程 - 臨時背景 - 已經過期的信息 3. 一次性內容寫到當天文件： - `memory/YYYY-MM-DD.md` 4. 過時但又不想徹底刪掉的內容，移動到： - `memory/archive.md` 5. 當一個任務已經完成： - 在當天記憶裏寫一條結果摘要 - 不要把全部過程塞進 `MEMORY.md` ## 技能沉澱協議 當一個任務滿足下麪條件時，整理成 Skill： - 這個任務以後還會反覆做 - 步驟比較固定 - 做錯的地方比較類似 - 有明確的檢查方法 滿足條件後，創建文件： - `skills//SKILL.md` Skill 裏必須寫清楚 4 件事： 1. 什麼時候用 2. 具體步驟 3. 常見失敗點 4. 怎麼驗證有沒有成功 下面這些不要做成 Skill： - 一次性探索 - 每次步驟都不一樣的任務 - 強依賴臨時上下文的任務
第 2 步：準備記憶文件
1）長期記憶文件
文件：MEMORY.md
# MEMORY.md ## 用戶長期偏好 - 喜歡直接、簡潔、能落地的建議 - 不喜歡空話和大段鋪墊 - 優先看可執行步驟和模板 ## 長期工作原則 - 不清楚的需求先問清楚 - 交付前自己驗證 - 重要結論儘量多方確認 - 原則性要求要長期記住 ## 當前有效習慣 - 技術問題先查本地資料，再查外部資料 - 做完任務後記錄到 `memory/YYYY-MM-DD.md`2）當天記憶目錄
創建目錄：memory/
文件：memory/2026-04-09.md
# 2026-04-09 ## 今天做了什麼 - 給 agent 增加了記憶治理協議 - 給 agent 增加了技能沉澱協議 ## 今天得到的結論 - 長期記憶要瘦身 - 重複流程適合做成 Skill3）歸檔文件
文件：memory/archive.md
# archive ## 已歸檔 - 2026-04-01：一次性測試過程，已完成 - 2026-04-03：臨時討論內容，已失效記憶三層結構：
第 3 步：給 agent 一個最小可用的 heartbeat
作用：巡檢，只檢查異常，不做複雜操作
文件：HEARTBEAT.md
# heartbeat 工作清單 每次收到 heartbeat 時，按順序檢查： 1. 檢查 Gateway 是否正常 2. 檢查最近日誌裏有沒有新的嚴重報錯 3. 檢查 `MEMORY.md` 是否明顯變長、變亂 4. 檢查最近有沒有適合整理成 Skill 的重複任務 5. 如果沒有需要處理的事，回覆：HEARTBEAT_OK 6. 如果發現異常，直接說清楚： - 問題是什麼 - 影響是什麼 - 建議怎麼處理第 4 步：創建第一個 Skill 模板
創建目錄：skills/review_memory/skills/diagnose_gateway/
模板 1：整理記憶
文件：skills/review_memory/SKILL.md
name: review_memory description: 整理長期記憶、當天記憶和歸檔內容，避免上下文越來越亂 # 什麼時候用 當出現下面情況時使用： - `MEMORY.md` 變長了 - 有很多一次性內容混進長期記憶 - 任務做完後需要整理結論 # 步驟 1. 打開 `MEMORY.md` 2. 找出不適合長期保留的內容 3. 把一次性內容移動到 `memory/YYYY-MM-DD.md` 4. 把過期但還想保留的內容移動到 `memory/archive.md` 5. 保證 `MEMORY.md` 裏只剩長期有效的信息 # 常見失敗點 - 把任務過程全塞進 `MEMORY.md` - 把已經失效的信息繼續長期保留 - 歸檔了，但沒有在當天記憶裏寫摘要 # 怎麼驗證 檢查這 3 件事： 1. `MEMORY.md` 裏只剩長期有效信息 2. 當天發生的事寫進了 `memory/YYYY-MM-DD.md` 3. 舊信息被移動到了 `memory/archive.md`模板 2：排查 Gateway
文件：skills/diagnose_gateway/SKILL.md
name: diagnose_gateway description: 排查 OpenClaw Gateway 是否異常，檢查監聽、日誌和恢復情況 # 什麼時候用 當出現下面情況時使用： - 消息沒有正常發送 - heartbeat 異常 - cron 沒執行 - 用戶懷疑 Gateway 掛了 # 步驟 1. 檢查 Gateway 端口是否監聽 2. 查看最近日誌裏的 error、fail、exception 3. 判斷問題屬於哪一類： - 進程沒啓動 - 配置錯誤 - 權限或認證問題 4. 給出修復動作 5. 修復後再檢查一次 # 常見失敗點 - 只看報錯表面，不看日誌上下文 - 修完後不驗證 - 把配置問題誤判成服務掛了 # 怎麼驗證 至少確認下面兩件事： 1. 相關端口恢復監聽 2. 實際觸發一次相關功能，確認恢復第 5 步：把 heartbeat 配置打開
{ id: "sysmon", heartbeat: { every: "30m", target: "last", lightContext: true, isolatedSession: true, activeHours: { start: "08:00", end: "22:00", timezone: "Asia/Shanghai" } } }第 6 步：加兩個每週自動整理任務
任務 1：每週整理記憶
openclaw cron add \ --name "memory-review" \ --cron "30 10 * * 0" \ --session isolated \ --message "檢查 MEMORY.md、memory/YYYY-MM-DD.md、memory/archive.md，清理過時內容，只保留長期有效信息，並把結果寫入當天記憶。" \ --no-deliver任務 2：每週整理技能
openclaw cron add \ --name "skill-review" \ --cron "0 10 * * 0" \ --session isolated \ --message "檢查 skills 目錄，合併重複技能，刪除明顯過時的技能，補充常見失敗點和驗證方法，並把結論寫入當天記憶。" \ --no-delive八、關於「跟不上」這件事
2026 年的 AI 工具生態，有點像 2012 年的前端框架大戰。每個月都有新的「顛覆性」項目，每個社區都在說「這次不一樣」。Backbone、Ember、Angular、React、Vue……當年的前端開發者也經歷過完全一樣的焦慮。
回頭看，那場戰爭的贏家不是押對了某個框架的人，而是理解了底層模式的人。組件化、單向數據流、虛擬 DOM——這些概念超越了任何一個具體框架，在每一個新框架裏都能快速上手。
AI Agent 領域也一樣。不管框架怎麼換，有些能力是不會過時的：
- Prompt 工程
——如何給 Agent 下達精確的指令 - 工具設計
——如何定義好的工具接口（MCP 正在成為標準） - 記憶架構
——如何管理上下文、做信息壓縮和檢索 - Agent 調試
——如何定位「Agent 做了蠢事」的根因 - 安全邊界
——如何讓 Agent 有足夠權限做事，又不至於失控
這些能力，在 OpenClaw 裏鍛鍊的，在 Hermes 裏直接用得上，在未來任何一個 Agent 框架裏同樣適用。所以我的建議不是「趕緊換 Hermes」，也不是「守住 OpenClaw」，而是：
停止追逐工具，開始投資能力。選一個當前最適合你場景的框架，深度使用它，但把注意力放在那些可遷移的底層能力上。框架會過時，能力不會。
關於openclaw資料包和系列文章
配套資料包
私信 kekohu 獲取，內容不定期持續更新。
注意：付費社羣包含資料包全部內容，無需重複購買。
openclaw系列文章
持續更新，建議每篇認真閲讀
配置與理解
別被騙，OpenClaw 可以 24 小時幹活——但你得先做對這 6 件事
火了三個月的"龍蝦"，普通人裝了真的有用嗎？
用 OpenClaw 把 AI 失憶治好：開關、精簡、外掛三步走
多 Agent 與協作
技能與工具
實戰與案例
排錯與安全
關於嬌姐
40+ IT 從業者，前榮耀員工，現專注 AI 效率工具研究與實踐。持續輸出 OpenClaw 及 AI 工具的乾貨教程與落地案例，偶爾分享職場思考與生活感悟。
提示：覺得有用，點贊、關注、轉發，是我持續創作的動力。