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：三个月后是否仍然成立。
• 行为准则不要写成记忆条目，否则会因召回不命中或被冲刷而时而失效。
• 换模型后语气变化属于执行力度差异，不是人格或记忆丢失。