SOUL.md 是你的 Hermes 实例的 核心身份。它是系统提示词(system prompt)中的第一项内容——它定义 market 了该智能体是谁、如何说话以及需要避免什么。
如果你希望每次与 Hermes 交谈时它都表现得像同一个助手——或者如果你想用你自己的角色完全取代 Hermes 的角色——这就是需要使用的文件。
SOUL.md 的用途
Section titled “SOUL.md 的用途”将 SOUL.md 用于:
- 语气
- bridge
- 沟通风格
- Hermes 应该有多直接或多温和
- Hermes 在风格上应该避免什么
- Hermes 应该如何应对不确定性、分歧和模糊性
简而言之:
SOUL.md关乎 Hermes 是谁以及 Hermes 如何说话
SOUL.md 不适用的地方
Section titled “SOUL.md 不适用的地方”请勿将其用于:
- 特定仓库的编码规范
- 文件路径
- 命令
- 服务端口
- 架构说明
- 项目工作流指令
这些内容属于 AGENTS.md。
一个很好的原则:
- 如果它适用于所有地方,请将其放入
SOUL.md - 如果它仅属于某一个项目,请将其放入
AGENTS.md
它的存放位置
Section titled “它的存放位置”Hermes 现在仅为当前实例使用全局 SOUL 文件:
~/.hermes/SOUL.md如果你使用自定义的主目录运行 Hermes,它将变为:
$HERMES_HOME/SOUL.md初次运行行为
Section titled “初次运行行为”如果尚不存在 SOUL.md,Hermes 会自动为你生成一个初始的 SOUL.md。
这意味着大多数用户现在都会从一个可以立即阅读和编辑的真实文件开始。
重要提示:
- 如果你已经有了
SOUL.md,Hermes 不会覆盖它 - 如果该文件存在但为空,Hermes 不会将其中的任何内容添加到提示词中
Hermes 如何使用它
Section titled “Hermes 如何使用它”当 Hermes 启动会话时,它会从 HERMES_HOME 读取 SOUL.md,扫描其中是否存在提示词注入模式,在需要时进行截断,并将其用作智能体身份——即系统提示词(system prompt)中的第 1 号插槽。这意味着 SOUL.md 会完全取代内置的默认身份文本。
如果 SOUL.md 缺失、为空或无法加载,Hermes 将回退到内置的默认身份。
文件周围不会添加任何包装语言。内容本身至关重要——请按照你希望智能体思考和说话的方式来编写。
一次不错的初次修改
Section titled “一次不错的初次修改”如果你不想做其他修改,只需打开该文件并更改几行,让它感觉更像你。
例如:
你是直接、冷静且技术精准的。相比于流于形式的礼貌,更看重实质内容。当一个想法不够好时,明确地提出异议。除非更有深度的细节有用,否则保持回答简练。单是这些调整就能显著改变 Hermes 给人的感觉。
1. 务实的工程师
Section titled “1. 务实的工程师”你是一位务实的高级工程师。你更关心正确性和运维现实,而不是让自己听起来很厉害。
## 风格
- 说话直接- 除非复杂度需要深度,否则保持简练- 当某件事是个坏主意时直言不讳- 相比于理想化的抽象,更倾向于实际的权衡
## 避免
- 奉承阿谀- 炒作语言- 过度解释显而易见的事情2. 研究伙伴
Section titled “2. 研究伙伴”你是一位深思熟虑的研究合作者。你充满好奇心,对不确定性保持诚实,并对不寻常的想法感到兴奋。
## 风格
- 探索各种可能性,而不假装确定- 区分推测与证据- 当想法空间不明确时,提出澄清性的问题- 相比于浅显的完整性,更倾向于概念的深度3. 老师 / 讲解者
Section titled “3. 老师 / 讲解者”你是一位耐心的技术老师。你关心的是理解,而不是表现。
## 风格
- 讲解清晰- 在有帮助时使用示例- 除非用户有所暗示,否则不预设其具备先验知识- 从直觉出发构建到细节4. 严厉的审查者
Section titled “4. 严厉的审查者”你一位严格的审查者。你很公正,但不会粉饰重要的批评。
## 风格
- 直接指出薄弱的假设- 将正确性置于和谐之上- 明确指出风险和权衡- 相比于模糊的外交辞令,更倾向于直率的清晰什么样的 SOUL.md 才算强?
Section titled “什么样的 SOUL.md 才算强?”一个强的 SOUL.md 应该是:
- 稳定的
- 广泛适用的
- 在语气上具体明确的
- 不塞满临时指令的
一个弱的 SOUL.md 通常是:
- 充满项目细节
- 相互矛盾
- 试图微管理每一种回复格式
- 大多是 “保持有帮助” 和 “保持清晰” 这类通用填充内容
Hermes 本来就会努力做到有帮助和清晰。SOUL.md 应该添加真正的个性和风格,而不是重复显而易见的默认行为。
你不一定需要标题,但标题会有帮助。
一个简单且有效的结构:
# IdentityHermes 是谁。
# StyleHermes 应该听起来是什么风格。
# AvoidHermes 不应该做什么。
# Defaults当出现歧义时,Hermes 应该如何处理。SOUL.md vs /personality
Section titled “SOUL.md vs /personality”它们是互补的。
使用 SOUL.md 作为你的持久基线。使用 /personality 进行临时模式切换。
示例:
- 你的默认 SOUL 是务实且直接的
- 然后在某个会话中使用
/personality teacher - 之后可以切换回来,而无需更改你的基础语气文件
SOUL.md vs AGENTS.md
Section titled “SOUL.md vs AGENTS.md”这是最常见的错误。
把这些放到 SOUL.md 中:
Section titled “把这些放到 SOUL.md 中:”- “保持直接。”
- “避免炒作式语言。”
- “除非深入解释有帮助,否则优先给短答案。”
- “当用户错误时,要提出反驳。”
把这些放到 AGENTS.md 中:
- “使用 pytest,而不是 unittest。”
- “前端位于
frontend/。” - “永远不要直接编辑 migrations。”
- “API 运行在 8000 端口。”
nano ~/.hermes/SOUL.md或者
vim ~/.hermes/SOUL.md然后重启 Hermes 或启动一个新会话。
一个实用工作流
Section titled “一个实用工作流”- 从初始化生成的默认文件开始
- 删掉任何不像你想要的语气的内容
- 添加 4–8 行,清楚定义语气和默认行为
- 与 Hermes 对话一段时间
- 根据仍然感觉不对的地方进行调整
这种迭代方式比试图一次性设计出完美个性更有效。
我编辑了 SOUL.md,但 Hermes 听起来还是一样
Section titled “我编辑了 SOUL.md,但 Hermes 听起来还是一样”检查:
- 你编辑的是
~/.hermes/SOUL.md或$HERMES_HOME/SOUL.md - 不是某个 repo-local 的
SOUL.md - 文件不是空的
- 编辑后已经重启会话
- 没有某个
/personality覆盖层主导结果
Hermes 忽略了我的 SOUL.md 的部分内容
Section titled “Hermes 忽略了我的 SOUL.md 的部分内容”可能原因:
- 更高优先级的指令覆盖了它
- 文件中包含冲突指导
- 文件太长,被截断了
- 某些文本类似 prompt-injection 内容,可能被扫描器阻止或改写
我的 SOUL.md 变得过于项目特定
Section titled “我的 SOUL.md 变得过于项目特定”将项目指令移动到 AGENTS.md,并让 SOUL.md 专注于身份和风格。