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。