Hermes Agent 的“大腦”可以替換嗎？模型層與 Agent 層如何分工
摘要
Hermes Agent 的"大腦"可以替換，但被替換的只是模型層，不是整個 Agent。模型層負責這一次怎麼想——理解問題、規劃步驟、決定調用哪個工具、組織語言；Agent 層負責讓思考能持續發生——身份（SOUL.md）、用户畫像（USER.md）、跨會話事實（MEMORY.md 與 memories/）、方法沉澱（skills/）、消息通道、自動任務、工作目錄，都存放在模型之外的獨立位置。所以換模型不會刪除這些資產：在 LightVela 上，一個 Agent 同一時間只使用一個生效模型，切換模型不會清除記憶、雲存儲文件、技能或自動化設置，改變的只是後續回覆所使用的推理引擎。換模型後如果感覺"它不認識我了"，絕大多數情況不是記憶丟失，而是新模型的指令遵循程度、上下文壓縮策略和表達習慣不同。
引子：換模型，到底換掉了什麼
"能不能給我的 Agent 換個更強的模型？"這是使用 Agent 產品時最高頻的問題之一。緊跟着來的往往是第二個問題："換了之後，它還記得我嗎？"
這兩個問題連在一起問，説明一個普遍存在的認知誤區：把"模型"和"Agent"當成同一個東西。在這種理解裏，Agent 就是模型套了個聊天界面，換模型等於換掉整個助理，於是"重新認識一遍"似乎理所當然。
但如果 Agent 真是這樣，它就不可能具備任何長期價值。你上週告訴它的項目背景、你調好的語氣偏好、你沉澱的工作流程，會在每次技術升級時清零。這顯然不是一個能長期使用的產品形態。
Hermes Agent 的設計前提恰恰相反：模型是可替換的部件，Agent 是持續存在的主體。 把這句話拆開講清楚，就是這篇文章要做的事。
一、先把三件事分開：模型、運行時、長期資產
討論"換模型"之前，需要先承認一個 Agent 至少包含三個不同層次，它們的生命週期完全不同。
| 層次 | 它是什麼 | 生命週期 | 換模型時 |
|---|---|---|---|
| 模型層 | 提供推理與生成能力的大模型 | 隨配置變化，可隨時替換 | 被替換 |
| Agent 運行時 | 承載工具執行、通道收發、任務調度的進程 | 長期運行 | 保持不變 |
| 長期資產 | SOUL.md、USER.md、MEMORY.md、memories/、skills/、工作目錄文件 | 長期累積 | 保持不變 |
多數人的直覺只看到第一層和聊天界面，忽略了中間的運行時和底下的資產層。而恰恰是後兩層決定了"這個 Agent 是不是同一個它"。
一個便於記憶的類比：模型像一個人此刻的思考能力，運行時像這個人的身體和手腳，長期資產則像這個人的身份、記憶和職業習慣。換掉思考方式的人還是同一個人，因為身份和記憶沒有跟着換掉。
二、模型層：負責"這一次怎麼想"
模型層在一次對話裏承擔的工作比"生成文字"更寬。它至少決定四件事：
- 理解：把你這句話解析成一個明確的任務目標，包括你沒説出口但暗示了的約束。
- 規劃：判斷這件事需要幾步、先做哪一步、是否需要先查資料再動手。
- 工具調用決策：決定要不要讀文件、要不要檢索網頁、要不要執行命令，以及參數怎麼填。
- 表達：把結果組織成你能讀懂的語言，包括詳略取捨和格式選擇。
這四件事都屬於"本次推理"。它們的質量直接決定你這一次的使用體驗，所以換模型帶來的觀感變化往往很明顯。
但同樣重要的是明確模型層不負責什麼：
- 模型不是你的資料庫。它不保存你的偏好、項目狀態或歷史結論。
- 模型不是任務調度器。它不知道"每天早上七點要執行一次"這件事。
- 模型不是通道管理器。它不負責把回覆投遞迴 Telegram 的哪一條會話。
這些能力都在模型之外。這正是"換模型不等於換 Agent"的技術基礎。
三、Agent 層：負責"讓思考能持續發生"
Agent 層的職責，可以按"它解決什麼問題"分成五類。
3.1 身份與行為準則：SOUL.md
SOUL.md 定義這個 Agent 是誰、以什麼語氣工作、優先級如何排序、哪些事不做。它是一份穩定的行為準則，而不是每次對話臨時生成的語氣。
換模型後，SOUL.md 依然在原處。新模型會重新閲讀並執行這份準則——執行力度可能不同，但準則本身沒有變化。這個區別是後面理解"為什麼感覺不一樣"的關鍵。
3.2 用户畫像：USER.md
USER.md 保存關於你的穩定信息：語言習慣、溝通節奏偏好、常用工具、明確的禁忌。它讓 Agent 不必每次都重新問一遍"你想要詳細一點還是簡短一點"。
3.3 跨會話事實：MEMORY.md 與 memories/
這一層保存已經發生過、並被判斷值得長期保留的事實與結論：項目叫什麼、上週做了什麼決定、某個參數為什麼定成現在這樣。Hermes 用 SQLite + FTS5 建立全文索引，在你提到相關話題時把匹配條目召回進上下文，而不是把全部歷史塞進去。
記憶的寫入不是無限追加，而是通過 add / replace / remove 這類原子操作維護，並可以通過 /memory pending 審批。這套機制的完整設計，可參考《記憶不是越多越好：Hermes Agent 如何篩選、整理和更新長期記憶》。
3.4 方法沉澱：skills/
skills/ 存放"遇到某類場景該怎麼做"的標準流程，每份 SKILL.md 通常帶 YAML frontmatter 聲明觸發條件。它屬於程序性記憶，與陳述性的 Memory 是兩條獨立通路，詳見《Memory 不是 Skill：Hermes Agent 的事實記憶與程序性記憶有何不同？》。
3.5 連接與調度：通道、自動任務、工作目錄
- 通道決定這個 Agent 從哪些入口接收消息、把結果投遞迴哪裏。
- 自動任務決定它在你沒提問時也要完成哪些工作。
- 工作目錄決定任務的輸入輸出文件放在哪裏、邊界在哪裏。
這三樣都是 Agent 層的配置，與當前使用哪個模型無關。
四、為什麼必須解耦：四個現實理由
把模型和 Agent 分開不是架構潔癖，而是有明確收益。
理由一：模型迭代速度遠快於個人資產積累速度。 大模型可能幾個月就有明顯更強的版本，而你和 Agent 之間的記憶、偏好、工作流程需要長期累積。如果兩者綁定，每次升級都要以清空積累為代價，用户就會拒絕升級。
理由二：不同任務需要不同模型。 寫初稿要快，做複雜推理要強，兩者未必是同一個模型。解耦之後你可以按任務切換，而不必為每種任務各建一個 Agent、各自維護一份記憶。
理由三：提供商可用性無法保證。 某個提供商限流、報錯或調整策略時，你需要能立刻切到另一個已配置模型繼續工作。如果記憶綁在模型上，這種切換的代價會高到不可接受。
理由四：資產歸屬清晰。 記憶和技能存放在獨立文件與目錄裏，意味着它們是你的資產，而不是某個模型的附屬品。這也是"訓練自己的 Agent"這句話能成立的前提。
五、在 LightVela 上換模型時實際發生了什麼
前面講的是機制，這裏講產品上的實際行為。
一個 Agent 同一時間只使用一個生效模型。 切換模型的操作是"選擇當前生效的已配置模型"，而不是新建一個 Agent。這意味着你不需要為了用不同模型而維護多個 Agent。
切換模型不會清除記憶、雲存儲文件、技能或自動化設置。 模型切換隻改變後續回覆使用的引擎。它不會移動聊天記錄、不會改寫雲存儲中的文件、不會變更技能與自動任務配置。
切換前的準備與切換後的確認，產品文檔給出的做法是：
- 確認目標模型已經配置完成，且賬户可以使用它。尚未配置時先完成模型配置。
- 準備一條簡短的測試消息，用於確認新模型能夠正常回復。
- 切換後在聊天中發一條測試消息，確認 Agent 能正常回復，且控制台顯示的是你選擇的模型。
- 剛切換後的首次回覆如果稍慢，可以稍等後重試一次，再決定是否繼續調整。
需要澄清一個常見誤傳：自動任務的配置項包括名稱、執行時間（固定星期、固定間隔、單次執行三選一）、任務説明、生效時間段、通知方式，其中並不包含"鎖定某個模型"這一項。因此"換模型後必須逐個同步自動任務的模型"並不成立。換模型後值得檢查的是任務的執行結果質量，而不是去找一個不存在的模型字段。
六、為什麼換完之後"感覺不一樣"
這是最容易被誤判成"失憶"的環節。表現變化與數據丟失是兩件不同的事，混淆兩者會導致錯誤的排查方向。
不同模型在以下維度存在真實差異：
| 差異維度 | 表現出來的樣子 | 容易被誤讀為 |
|---|---|---|
| 指令遵循程度 | 對 SOUL.md 裏的約束執行得更松或更嚴 | "人格變了" |
| 上下文壓縮策略 | 更少主動引用背景信息 | "它忘了我們聊過的事" |
| 詳略偏好 | 回答明顯更短或更長 | "它變笨了 / 變囉嗦了" |
| 工具調用傾向 | 更少或更多地主動讀文件、查資料 | "它不會用工具了" |
| 語言風格 | 措辭、稱呼、語氣變化 | "換了個人" |
判斷方法很直接：用一條你確定它應該知道的事實去驗證。 比如你之前明確告訴過它某個項目的名稱或某個偏好，切換後直接問這件事。如果它答得出來，説明記憶層完好，你遇到的是表達風格差異；如果確實答不出來，再去檢查記憶文件是否存在、條目是否還在。
一個實用原則：每次只改一個因素，改完就測。 同時換模型、改人格、加技能，出問題時你無法判斷原因出在哪一層。
七、什麼時候值得換模型
按需求場景選擇，比追逐"最強模型"更實際。
| 你的需求 | 建議做法 |
|---|---|
| 需要更快完成初稿 | 選擇適合短任務、常規工作的已配置模型 |
| 任務需要更強的推理或代碼協助 | 選擇你已為這類工作配置好的模型 |
| 某個提供商不可用或受到限流 | 切換到另一款已配置模型，並在聊天中測試 |
| 希望比較輸出質量 | 每次切換後使用同一條測試消息，再比較結果 |
切換後如果無法正常使用，排查順序是：確認目標模型的憑證與提供商設置完整 → 確認該模型對你的賬户可用、配額充足 → 換一個已知可用的模型測試 → 仍不行則查看診斷中心的近期日誌。
八、LightVela 的做法：把模型做成可選項，把資產留給用户
Hermes 在機制上完成了模型與 Agent 的解耦，但它面向的仍然是願意直接管理 Markdown 文件與本地環境的使用者。LightVela 的方向是把這套解耦變成產品層面的默認體驗：
- 模型是可切換的配置項，不是安裝時一次性決定、之後再也不能改的前提。
- 記憶、技能、雲存儲、自動任務是用户資產，在模型切換時保持穩定，用户不必擔心"升級即清零"。
- 切換過程可驗證：控制台會顯示當前生效模型，聊天中的一條測試消息就能確認切換是否成功。
- 出問題可追溯：診斷中心保留近期日誌，用於區分問題出在模型、配置還是任務本身。
這樣做的結果是：模型的進步能被你直接享受到，而你已經積累的東西不會成為升級的代價。
小結
- Agent 至少包含三層：可替換的模型層、長期運行的運行時、持續累積的長期資產。
- 模型層負責本次的理解、規劃、工具調用與表達；它不保存偏好，不負責調度，不管理通道。
SOUL.md、USER.md、MEMORY.md、memories/、skills/與工作目錄都在模型之外，因此換模型不會帶走它們。- 在 LightVela 上，一個 Agent 同時只有一個生效模型；切換不清除記憶、雲存儲、技能與自動化設置。
- 自動任務沒有"鎖定模型"這個配置項，"換模型要同步自動任務模型"是誤傳。
- 換完感覺不一樣，通常源自指令遵循、上下文壓縮與表達習慣的差異，而不是記憶丟失；用一條已知事實即可驗證。