先關注後閲讀，嬌姐怕失去上進的你

文末嬌姐整理openclaw或者hermes所有文章連結

想了解嬌姐點擊文末連結

最近看了一些寫 Hermes 的文章，講安裝、講皮膚、講模型、講 MCP，寫得都挺好。但如果你真的把 Hermes 裝上，用了幾天，再拿它認真做點事，很快就會發現：真正影響體驗的，往往不是這些最顯眼的配置項。

我自己就是這樣。剛開始也會先看模型怎麼配、外接什麼記憶、MCP 要不要接滿。後來真用了一段時間，尤其是拿它去持續打磨一個從 OpenClaw 遷過來的 Agent 之後，我反而越來越在意一些更基礎的東西。

下面這 7 件事，是我現在最想先提醒新手的。不是那種"看起來很對"的原則，而是今天就可以開始改、改完就能感受到差別的東西。

0. openclaw遷移過來的agent，這一步很關鍵

1. 別急着折騰模型，先把 SOUL.md 寫出來

Hermes 剛裝好的時候，最容易讓人上頭的就是模型。但真用下來，SOUL.md 的優先級其實高得多。

模型決定的是上限，SOUL 決定的是它平時像不像你想要的那個助手。

如果這塊沒寫清楚，Hermes 很容易滑到一種很熟悉的狀態：認真、禮貌、什麼都懂一點，但總覺得不順手。要麼太愛鋪墊，要麼太愛解釋，碰到事先說一堆"我建議""我可以"，就是不動手。

我現在更願意把 SOUL.md 理解成"工作方式聲明"，而不是"人設文件"。哪怕先只寫幾條最樸素的也夠用：

• 不確定的事情先驗證，不猜
• 複雜任務先拆，不要直接開衝
• 輸出儘量讓我能直接照做
• 能沉澱成 skill 的經驗，不要只留在對話裏
• 少說空話，先把事做了

這幾條一旦寫進去，後面很多體驗會立刻不一樣。它不會一下子變天才，但會更像一個你能長期配合的工作型助手。

提示：如果你現在剛裝好 Hermes，不知道先改哪，建議先把 SOUL.md 寫了。寫得粗一點都沒關係，先把你最煩它犯的幾個毛病寫進去。

2. 只要是當前事實，就別讓它靠記憶回答

這個坑特別常見，而且越是剛開始用 Agent，越容易忽略。很多人會默認，Hermes 既然"記得"前面的內容，當前環境它也應該知道個大概。問題是，當前環境這種東西，偏偏最不能靠"大概"。

你問它現在在哪個目錄、某個文件裏寫了什麼、某個服務到底開沒開——這些問題一旦不查，後面很容易一步錯、步步錯。更麻煩的是，它說出來的話往往還挺像那麼回事，你一開始未必能發現問題在哪。

我現在給自己的規則很簡單：只要是當前事實，就別讓它靠記憶回答。先把這幾類問題卡死：

• 當前時間 / 當前目錄
• 文件內容 / 數據庫結構
• 服務狀態
• 最近一次到底做過什麼

這些都讓它先查，再說。看起來像基本功，但這條能減少的低級錯誤，比很多花哨配置都多。

3. 複雜任務開跑前，最好先做一遍 preflight

很多失敗根本不是"執行失敗"，而是"前提就不成立"。比如：

• 依賴服務沒起來
• 目標對象根本不存在
• 工作目錄不對 / 憑證沒配好
• 命令入口就壞了 / 數據庫不可寫

這些問題如果不在最前面攔住，後面你看起來像是在排查流程問題，其實只是最開始那個條件沒滿足。

我這邊那個公眾號整理 Agent，每次正式跑之前都必須先做 health check。原因很簡單，它依賴上游內容服務——只要那個服務不在線，後面的抓取、生成、投遞都會一起失真。

所以我現在遇到複雜任務，基本都會先來一句：先做 preflight，再執行。哪怕只查 3 件事：

• 關鍵依賴是不是在線
• 目標對象是不是存在
• 入口命令是不是正常

這個習慣的好處是把失敗前移——你不是跑到一半才發現不對，而是一開始就知道這事能不能做。一旦任務開始變長，preflight 的價值會越來越高。

4. 別把所有東西都往長記憶裏塞

很多人剛接觸 Agent 的長記憶時，都會經歷一個階段：覺得這玩意兒太好了，什麼都想記。表面上像是在"讓它越來越懂我"，實際上很多時候是在給以後埋雷。

長記憶一旦寫髒了，Hermes 後面就很容易帶着舊包袱說話——把已經過期、已經變化的信息，當成長期事實繼續用。

我現在判斷一個信息該不該進 memory，基本只問一句：這個東西，一個月後還值得相信嗎？

適合寫進長期記憶

用戶偏好 / 固定工作目錄

穩定環境事實 / 業務關鍵規則

已反覆驗證過的故障模式

不建議寫入

今天的任務進度 / 某次排查過程

某次執行結果 / 臨時 TODO

一次性上下文

很多 Agent 用久了變亂，未必是模型問題，很多時候就是 memory 裏堆了太多不該長期保存的東西。

5. 真正反覆會用的方法，早點寫成 skill

聊天記錄是上下文，不是能力。對話裏出現過一次的好方法，不代表下次它還會自然地這麼做。尤其是那種多步驟、踩過坑、你已經糾正過幾次的做法，如果還只留在聊天裏，遲早會再來一遍。

我現在的判斷標準挺粗暴的：如果一個方法以後大概率還會再用兩次以上，它就不應該只留在聊天記錄裏。

比如這些更適合做成 skill，而不是隻存在 memory 裏：

• 某類問題固定怎麼排查
• 某個複雜任務開始前要檢查什麼
• 某類文章怎麼起草更順
• 出現某種故障後怎麼定性

如果你是普通用戶，也不需要一上來就寫很大的 skill。先從最常重複的一類任務開始，先別追求全，先追求真能複用。只要以後還能再用一次，它就有變成 skill 的價值。

6. 一個坑別隻踩完就算，順手留點東西下來

很多人排障的方式都差不多：出問題，修好，繼續用。當下看沒毛病，可時間一長就會發現，同類問題還是會回來，只是換個樣子再讓你踩一次。

所以我現在會強迫自己多做一步：每次真實故障之後，順手留下一點長期資產。這個不一定是代碼層面的東西，可以很輕：

• 一條 memory 更新 / 一個新的 skill
• 一次 skill patch / 一個迴歸測試
• 一條新的檢查規則 / 一個更準確的結果口徑

比如一個很典型的坑：在恢復過程中用很窄的時間窗口看抓取結果，可能會誤以為"系統沒抓到"。後來驗證下來，未必是系統壞了，有時只是看的窗口太短。這個如果只是聊天裏知道了，下次大概率還會再犯；一旦補成測試、寫進 skill，後面就不太容易再掉進去。

所以我現在每次問題解決完，都會順手問一句：

重點：這次應該留下什麼？——這句話會逼着你從"這次修好了"切到"下次能不能更省心"。

7. 判斷 Hermes 好不好用，不要只看它聰不聰明

以前很容易被那種"第一次很驚豔"的體驗吸引。但真用久了以後，你會慢慢發現，日常體驗好不好，不是由那些最亮眼的時刻決定的，而是由它會不會重複犯錯決定的。

我現在判斷一個 Hermes 好不好用，已經不太看"這次說得漂不漂亮"，而更看這些：

• 同類問題第二次出現時，它是不是更快了
• 它是不是更少誤判了
• 你是不是不需要再把同樣的話重複講三遍
• 它有沒有把上次的經驗真正用起來
• 它會不會越來越穩，而不是越來越飄

那個從 OpenClaw 遷過來的 Agent，一開始也只是"能執行"。經過幾輪打磨後，我更在意的已經不是它這次到底能不能跑通，而是它有沒有開始形成穩定習慣：工作目錄固定了、preflight 固定了、skipped / failed 的口徑固定了、出了問題該怎麼沉澱也固定了。

這些東西不炫，但它們才是"越用越穩"的基礎。

重點：少問一句"它今天有多聰明"，多問一句"它下次會不會比這次更省心"。這才是真正有複利的地方。

寫在最後

如果只看功能，Hermes 當然可以被理解成一個會調工具、會接記憶、會擴展 skill 的 Agent 框架。但真用一段時間後，我越來越覺得，它最值得折騰的地方，不是"功能還能再加什麼"，而是"工作方式能不能穩定下來"。

上面這 8件事，說白了都不算高級技巧。它們不酷，也不花哨，甚至有點像基本功。但很多時候，Hermes 到底是"偶爾很驚豔"，還是"長期很好用"，差的還真就是這些東西。

關於openclaw資料包和系列文章

持續更新，建議每篇認真閲讀

【不推薦用官方命令】Windows 環境下安裝Hermes及遷移Openclaw的實操分享

我把 OpenClaw 的 Agent 無縫遷移到了 Hermes——就靠這一份 Skill

借鑑 Hermes 優化 OpenClaw：讓你的 AI 學會記、會覆盤、會巡檢