Hermes Agent 的性格從哪裏來？Persona、用户偏好與長期記憶如何共同作用

摘要

Hermes Agent 的性格不是一段固定的人設文案，而是三份內容共同作用的結果：SOUL.md 規定"我是誰、我怎麼做事"，屬於穩定的行為準則；USER.md 記錄"你希望我怎樣對待你"，屬於關係的默認設置；MEMORY.md 與 memories/ 保存"我們已經一起確認過什麼"，屬於共同經歷的證據。三者分工明確才能同時做到穩定與個性化：只有 Persona 會導致對所有人一個樣，只靠記憶會導致行為隨機漂移。它們不該互相替代——Persona 不寫具體事實，USER.md 不寫一次性情緒，MEMORY.md 不承擔行為準則。換模型時這三份文件都保留在原處，所以人格的穩定性不依賴某個具體模型。

---

引子：同樣的人設，為什麼對不同的人應該不一樣

假設有兩個用户，都給自己的 Agent 設定了"耐心的研究助手"這個角色。

第一個用户是產品經理，習慣先看結論再看依據，討論的多是版本節奏與優先級。第二個用户是學生，需要完整推導過程，討論的多是概念理解與作業。

如果這兩個 Agent 説出完全一樣的話，那"耐心的研究助手"這個設定就沒有真正落地——它只是一個標籤，沒有變成具體的相處方式。

反過來，如果為了個性化就讓 Agent 的行為完全隨每次對話漂移，那它又會失去可預期性：今天嚴謹、明天隨意，你無法依賴它。

性格需要同時滿足兩個矛盾的要求：穩定，且因人而異。 Hermes 的解法是把這兩個要求拆到不同的層裏，各自用不同的文件承載。

---

一、三份內容，三種職責

先建立整體圖景。

這三者的變化頻率差異是分開存放的核心理由之一。把一份幾個月不動的行為準則，和一份每天追加條目的事實清單放在同一個文件裏，穩定的部分會被高頻變化沖刷掉。這與 USER.md 和 MEMORY.md 之所以不能合併是同一類道理，詳見《為什麼 Hermes Agent 要把記憶分成兩類？USER.md 與 MEMORY.md 的職責》。

---

二、Persona：穩定的行為準則

SOUL.md 是 Agent 的行為準則，通常包含這些內容：

• 角色定位：它扮演什麼，比如研究助手、寫作搭檔、社群值班助手。
• 語氣與表達風格：正式還是輕鬆，是否使用比喻，是否允許玩笑。
• 優先級排序：當準確性與速度衝突時先要哪個，當簡潔與完整衝突時先要哪個。
• 行為邊界：哪些事不做，哪些內容不展開，哪些操作必須先確認。

寫 Persona 時有三條實踐要點。

第一，寫原則，不寫具體事實。 "我服務於一位做 agent-demo 項目的產品經理"不該寫進 SOUL.md——那是事實，屬於 USER.md 或記憶。Persona 應該寫"面對產品類問題時，先給結論再給依據"這類可長期適用的原則。

第二，邊界要具體到可判斷。 "保持專業"無法判斷是否遵守；"不主動給出醫療、法律、投資的決策建議，只提供公開信息並提示諮詢專業人士"可以判斷。抽象的準則在不同模型下執行差異會很大。

第三，衝突時的優先級要顯式寫出來。 準則之間必然會衝突——"簡潔"和"完整"就是一對。如果不寫清楚誰優先，Agent 只能每次自己猜，表現就會不穩定。

---

三、用户偏好：關係的默認設置

USER.md 承載的是關於你的穩定信息，讓 Agent 不必每次重新詢問。適合寫進去的內容：

• 語言與表達偏好：用什麼語言，術語保留原文還是翻譯，是否需要舉例。
• 溝通節奏：習慣先結論後展開，還是希望看到完整推理過程。
• 常用工具與環境：你日常使用的技術棧、平台、工作方式。
• 明確的禁忌：不希望被追問的方向，不希望使用的表達方式。

判斷某條信息該不該進 USER.md，有一個簡單標準：它在三個月後是否仍然成立？ "我偏好簡潔的回答"大概率成立，適合放進來；"我今天很急"不成立，屬於一次性語境，不該寫入。

這個標準很重要。把一次性情緒寫進 USER.md，會導致 Agent 長期按一個臨時狀態對待你——比如你某天趕時間説了"簡單點説"，如果被當成長期偏好固化，之後你需要詳細解釋時它反而不給了。

---

四、長期記憶：共同經歷的證據

MEMORY.md 與 memories/ 保存的是已經發生並值得長期保留的事實：項目狀態、已做出的決定、可複用的結論、某個參數為什麼定成現在這樣。

它與前兩者的關係可以這樣理解：

• Persona 決定行為原則。
• USER.md 決定默認交互方式。
• 記憶決定雙方共享的背景知識。

記憶的召回是按需的：Hermes 通過 SQLite + FTS5 建立全文索引，在你提到相關話題時把匹配條目拉進上下文，而不是把全部歷史塞進去。寫入也不是無限追加，而是通過 add / replace / remove 這類原子操作維護，並可通過 /memory pending 審批。完整的治理邏輯見《記憶不是越多越好：Hermes Agent 如何篩選、整理和更新長期記憶》。

記憶不應該替代 Persona。 一個常見錯誤是把行為準則寫成記憶條目，比如"記住：以後回答都要先給結論"。這類內容放在記憶裏有兩個問題：它可能因為 query 不命中而沒被召回；它會被後續條目沖刷。行為準則應該寫進 SOUL.md，那裏是常駐的。

---

五、三者如何共同產出一次回答

用一個具體場景把三層串起來。

設定：

• SOUL.md：研究助手；先給結論再給依據；不確定的地方明確標註不確定；不展開醫療與投資建議。
• USER.md：偏好中文；術語保留英文原文；希望回答控制在可快速掃讀的長度。
• MEMORY.md：當前在做 agent-demo 項目的國際站；上週決定把首頁改為動態漸變；該項目使用 Next.js。

你的問題："國際站首頁現在的方案，如果要加一個視頻背景，有什麼風險？"

三層各自的作用：

1. 記憶提供背景：Agent 知道"國際站首頁"指的是 agent-demo 項目的哪個頁面，也知道上週剛改成動態漸變，所以能判斷"加視頻背景"是在這個基礎上的改動，而不是從零開始。
2. Persona 決定結構：先給結論（"主要風險是首屏性能與移動端流量"），再展開依據；對不確定的部分明確標註。
3. USER.md 決定表達：用中文回答，LCP、autoplay 這類術語保留英文，長度控制在可快速掃讀。

三層缺任何一層，結果都會明顯變差：缺記憶會答得很泛；缺 Persona 會結構混亂、該標註不確定的地方不標註；缺用户偏好會在語言和長度上不合手。

---

六、常見問題與歸屬判斷

實際使用中最常見的問題是"這條信息該寫到哪裏"。下表給出判斷方法。

最後一行值得強調：換模型後語氣變化不是人格丟失。 SOUL.md 仍在原處，變的是執行力度。區分方法見《切換模型會讓 Agent"失憶"嗎？模型、人格與記憶的解耦設計》。

---

七、LightVela 的做法：把人格與偏好也做成可管理資產

Hermes 已經把這三層拆得很清楚，但它面向的仍是直接編輯 Markdown 的使用者。LightVela 採用雲端託管模式，不提供面向用户的文件系統操作，因此這三層的維護方式與自託管不同：

• 人格通過「人設」能力配置：管理台 Agent 設置頁的「人設」區域提供「隨機抽取人設」與「答題測試人設」兩種入口，查看人設卡的角色、語氣與行為説明後點擊「注入人設」即可生效。它生成並注入 Soul，不需要你直接操作雲端文件系統，但也不等於提供一個可編輯任意雲端文件的通用編輯器。
• 記憶在管理台可查看：管理台的記憶頁用於查看 Agent 記住了什麼，並區分「記憶」與「用户畫像」兩個標籤頁，對應事實與穩定偏好的分工。
• 增刪主要通過對話完成：你不必刻意「填寫」記憶。正常對話中 Hermes 會自行判斷哪些信息值得長期保留；需要它記住或忘掉某些內容時，直接在對話裏説明即可。
• 容量可控：管理台可調整記憶容量上限，避免長期上下文無節制增長。
• 跨模型穩定：切換模型不會清除記憶、技能與自動化設置，人格的穩定性不依賴某個具體模型。
• 跨通道一致：同一個 Agent 在多個通道共享同一份記憶與人格，換手機或換通道後記憶仍在，不需要為每個平台複製一遍。

---

小結

• 性格由三份內容共同產生：SOUL.md（行為準則）、USER.md（默認交互方式）、MEMORY.md / memories/（共同背景）。
• 分開存放的核心理由是變化頻率不同：準則幾個月不動，記憶幾乎每天追加。
• Persona 寫原則不寫事實，邊界要具體到可判斷，衝突時的優先級必須顯式寫出。
• 判斷信息是否該進 USER.md：三個月後是否仍然成立。
• 行為準則不要寫成記憶條目，否則會因召回不命中或被沖刷而時而失效。
• 換模型後語氣變化屬於執行力度差異，不是人格或記憶丟失。