Hermes Agent 的 SOUL.md 爲什麼比模型更重要：50行纔是分水嶺

一句話概覽

很多人一聊到 agent 配置，第一反應是換模型、加上下文、接更多工具。

但在 Hermes Agent 裏，真正影響長期使用體驗的，經常是一個更小的文件：SOUL.md

它決定代理先把自己理解成什麼角色，再去讀技能、項目指令、記憶和工具說明。模型再強，如果身份、語氣、邊界寫得散，輸出還是容易泛、飄、貴。

1.SOUL.md 是什麼

SOUL.md 是 Hermes 的身份文件。它會替換默認的通用助手人格，定義代理是誰、怎麼說話、按什麼原則執行、哪些邊界不能碰。

啓動新會話時，Hermes 會先從 HERMES_HOME 讀取 SOUL.md，做安全掃描和必要截斷，然後把它放進 system prompt 的最前面。

如果這個文件缺失、爲空或讀不到，Hermes 就會退回默認身份。結果就是：它能幹活，但不太像“你的代理”。

修改 SOUL.md 後要開新會話。舊會話可能還保留舊的 prompt 狀態。

2.它爲什麼排在第一層

可以把 Hermes 的提示詞棧理解成三層：

• 穩定層：SOUL.md、工具與模型指導、skills 索引、環境提示

• 項目層：AGENTS.md、.hermes.md、CLAUDE.md、.cursorrules

• 易變層：MEMORY.md、USER.md、外部記憶、時間戳和會話信息

SOUL.md 在最前面，所以它不是普通偏好，而是解釋框架。

同樣一份 AGENTS.md，一個“嚴謹代碼審查員”會讀出風險和邊界；一個“內容策略顧問”會更關注表達、受衆和敘事節奏。身份不同，後續上下文的使用方式也不同。

3.什麼該寫進 SOUL.md

適合寫進去的是長期穩定的行爲設定：

• 身份：它是誰，和你是什麼關係

• 語氣：回答長短、直接程度、表達風格

• 價值取向：優先真實、速度、成本、質量，還是其他目標

• 行爲邊界：哪些事必須先確認，哪些事不能做

• 操作原則：什麼時候主動執行，什麼時候停下來問

這些內容應該跨項目穩定存在。換一個倉庫、換一個任務，它們依然成立。

4.什麼不該寫進去

SOUL.md 不應該變成萬能垃圾桶。

• 項目指令應該進 AGENTS.md

• 編碼規範應該進 AGENTS.md 或 .cursorrules

• 多步驟工作流應該做成 skill

• 關於你的事實應該進 MEMORY.md / USER.md

• 工具、模型和供應商配置應該進 config.yaml

一句話：SOUL.md 負責“它是誰”，不要讓它背項目雜務。

5.爲什麼建議控制在 50-80 行

SOUL.md 會進入每一輪對話，所以它既影響行爲，也持續消耗上下文。

粗略估算：

• 50 行：約 400-500 tokens

• 80 行：約 700-800 tokens

• 200 行：可能到 1500-2000 tokens

跑一個 20 輪 /goal 時，臃腫 soul 會被重複帶入很多次。即使有 prompt caching，過長的身份文件也會讓系統更貴、更慢、更難維護。

更好的標準是：每一行都應該改變代理行爲。如果刪掉一行沒有任何影響，那一行就該刪。

6.最小結構怎麼寫

一份穩定的 SOUL.md 不需要複雜模板，四段就夠：

• Soul：它是誰

• Voice：它怎麼說話

• Operations：它怎麼執行、怎麼做決策

• Restrictions：它絕不能做什麼

示例結構：

# Soul
你是一個務實的高級工程協作者，優先解決真實問題。

## Voice
直接、簡潔、指出不確定性。
複雜問題先給結論，再給必要依據。

## Operations
能從本地上下文確認的事先確認。
改代碼前先理解現有模式。
任務完成後給出驗證結果。

## Restrictions
不擅自刪除用戶文件。
不輸出密鑰。
不可逆操作前必須確認。

重點不是照抄這個模板，而是保持短、穩、可驗證。

7.幾種常見角色寫法

戰略合夥人型

適合創業者、產品 owner、需要經常做取捨的人。

重點寫清楚：它要挑戰假設、追問證據、按 90 天目標排序、不要爲了附和而同意。

深度研究員型

適合行業掃描、競品研究、資料彙總。

重點寫清楚：事實要有來源，估計要標註，證據弱就直接說明無法確認。

自治 DevOps 型

適合巡檢、部署、告警、自動化運維。

重點寫清楚：先觀測後修改，生產環境先確認，危險操作要可回滾。

內容策略型

適合寫作、發佈、品牌內容。

重點寫清楚：目標讀者是誰，語氣怎麼統一，哪些表達不要出現，什麼算合格輸出。

/personality overlay 怎麼用

SOUL.md 是長期基線，/personality 更像臨時工作模式。

今天需要它短一點，可以臨時切成 concise；需要代碼審查，可以臨時切成 code reviewer。任務結束後清掉 overlay，回到 SOUL.md 的默認人格。

不要把臨時需求塞進 soul。長期身份和臨時姿態分開，後面維護會輕很多。

8.多 Profile 時更要認真寫 soul

多 profile 的價值不是“複製多個助手”，而是讓不同代理真的承擔不同工作。

比如：

• Scout：只找信號

• Analyst：只綜合分析

• Coder：只寫代碼

• Briefer：只做每日摘要

每個 profile 都應該有自己的 SOUL.md。如果只是複製同一份身份文件，再換個模型名，本質上還是一個泛化代理。

9.最常見的坑

• 把項目說明、工作流、個人資料全塞進 SOUL.md

• 寫到 200 多行，每輪都燒 token

• 寫得太空，只剩“請專業、請簡潔”

• 修改後不重開會話，以爲沒生效

• 試圖用人格設定繞過安全邊界

直接的行爲邊界可以寫，比如“未經確認不要發消息”；但不要把繞過安全機制僞裝成人格要求。

10.怎麼測試你的 SOUL.md

寫完不要只看文本，要看錶現。

• 身份檢查：問“你是誰、你負責什麼”

• 語氣檢查：讓它解釋同一個概念，看風格是否一致

• 邊界檢查：讓它做一件被禁止的事，看是否會拒絕或先確認

• 體積檢查：運行 hermes prompt-size

• 漂移檢查：隔一段時間開新會話，確認長期記憶沒有把身份帶偏

一個好 soul 的標準不是“看起來高級”，而是能穩定改變行爲。

11.SOUL.md、Memory、Obsidian 各管什麼

這三層不要混用。

• SOUL.md：定義代理是誰，怎麼思考，怎麼表達

• MEMORY.md：保存當前階段重要事實和偏好，但容量有限

• Obsidian / 外部知識庫：保存長期研究、項目資料、會議筆記和交叉鏈接

Soul 管人格，Memory 管短中期上下文，知識庫管長期沉澱。

12.最後怎麼落地

不要一開始就寫 200 行。

先寫 20-40 行能真正改變行爲的設定，用一兩週，觀察它哪裏跑偏，再迭代。等你和代理協作過一段時間，再讓它基於真實反饋重寫自己的 soul，通常會比閉門造模板更準。

如果一個 agent 總是不像你的人、總在關鍵地方跑偏，先別急着換模型。先檢查 SOUL.md。