如果你用过 Hermes Agent，可能会遇到这种情况：聊了几轮之后它突然"失忆"了，或者换了项目之后它完全不了解你的代码结构。这不是 bug，是 Hermes 的记忆和人格系统需要你主动配置。
Hermes 解决这个问题的思路很清晰：把"记忆"、"人格"、"项目规则"拆成三个独立层次，各管各的事，组合起来才能配合默契。
先把三件事分开说
很多新手容易把三者混为一谈，觉得塞进去越多信息越好。实际上这三层机制各有各的职责：
Memory 负责保存长期信息——用户的偏好、环境的实际情况、以后还能用上的事实。它不会每次对话都清空，而是会累积。
SOUL.md 定义的是 Hermes 这个人怎么说话、用什么姿态沟通。你可以把它理解成"人设文件"，它决定了 Hermes 的默认语气、思维方式这些更底层的东西。
上下文文件 则是项目级别的规则。.hermes.md、AGENTS.md、CLAUDE.md、.cursorrules 都属于这一类，它们告诉 Hermes 当前这个项目有什么特殊要求、哪些文件不能碰、提交规范是什么。
三层各司其职，缺一不可。
怎么用好 Memory
Hermes 的记忆分成两份：MEMORY.md 和 USER.md。
MEMORY.md 偏向 Hermes 自己的视角，记录它认为值得长期保留的信息。USER.md 则是从用户角度出发的信息，比如你告诉过它的偏好、你的工作习惯这类内容。
两个文件都有严格的字数上限：MEMORY.md 上限 2,200 字符，USER.md 更紧凑，只有 1,375 字符。容量满的时候工具会直接报错，告诉你当前用了多少、你还有多少空间。超过 80% 容量时建议先合并条目，别等到塞爆了再处理。
存什么是讲究的。应该存的包括：用户偏好、环境事实、修正、项目约定、完成的工作记录。不应该存的也很明确：原始数据转储、大段代码块、会话特定的临时内容、已经写在 Context Files 里的信息。
来看一个具体的 MEMORY.md 长什么样：
# 用户的生产环境
生产数据库: AWS RDS PostgreSQL 16.2, us-west-2
staging 与生产结构一致，staging 地址是 10.0.1.50
# 项目约定
- 所有 API 请求走 /api 前缀，不接受硬编码 URL
- 数据库迁移文件不能直接修改，用 alembic revision
- 测试覆盖率低于 80% 不能合并
# 已完成的工作
- 2026-01-15 迁移数据库到 PostgreSQL 16
- 2026-03-02 添加 Redis 缓存层
USER.md 的画风就不一样了，更偏人本身：
# 基本信息
姓名: 张工
角色: 后端工程师
时区: Asia/Shanghai (UTC+8)
# 沟通偏好
- 喜欢用中文交流
- 回复尽量简洁，不要废话
- 有不确定的地方直接说"我不确定"，别硬编
# 工作习惯
- 习惯睡前把代码提交，第二天早上再 review
- 不喜欢在周末被 push
- 习惯先问清楚再做，不喜欢被跳步骤
塞错东西的后果很直接：有效信息被稀释，真正重要的内容反而可能被挤出去。
SOUL.md 怎么稳住风格
SOUL.md 放在 HERMES_HOME 目录下。它在系统提示里的优先级是最高的，比任何项目上下文文件都靠前。这意味着一旦你配置了 SOUL.md，Hermes 的身份定义就先于其他一切被加载。
这有什么实际影响？如果你的 SOUL.md 里写了"Hermes 是一个喜欢简洁回复的助手"，那即使某个项目的上下文文件让 Hermes 多说两句，它也不会轻易跑偏。 SOUL.md 才是真正的"人设锚点"。
一个典型的 SOUL.md 大概是这样：
# 我是谁
我是一个直接、简洁的技术助手。不说废话，不绕弯子。
## 沟通风格
- 回复尽量短，重点说清楚就行
- 代码示例要给就跑得通的，别给半成品
- 有错误就直接指出来，不用客气
## 立场
帮用户解决问题是第一位，不是证明自己有多聪明。
## 禁忌
- 不要出现"当然可以！""太好了！""非常棒！"这类语气
- 不要在没有把握的时候说"应该是"
- 不要列出三四个选项让用户自己选，如果我有判断就说判断
它和上下文文件的关系一句话就能说清：SOUL.md 定义的是 Hermes 是谁，上下文文件告诉它这个项目有什么特殊要求。前者稳定全局，后者局部覆盖。
有一点容易混淆：SOUL.md 和 /personality 命令不是一回事。前者是持久化的全局基线，配好之后每次会话都生效；后者是临时覆盖，单次会话结束后就恢复原状。想长期改人格，改 SOUL.md；想临时切换体验一把，用 /personality。
上下文文件的加载逻辑
这里有个关键点需要记住：上下文文件有优先级机制，Hermes 只会加载一种项目上下文类型。
优先级顺序是这样的（首个匹配获胜）：
换句话说，如果你同时放了 .hermes.md 和 AGENTS.md，Hermes 不是两个都读，而是按这个顺序选第一个匹配到的。所以不用想着把规则分散在好几个文件里，Hermes 只会看到它认为优先级最高的那一个。
SOUL.md 不在这个优先级体系里——它始终独立加载，固定在系统提示的第一槽位，不受这个规则限制。
AGENTS.md 有一个很实用的特性——支持递归发现。启动时 Hermes 会加载当前工作目录的 AGENTS.md，但更厉害的是，会话期间它还会根据你操作的文件路径，自动发现子目录里的 AGENTS.md 并注入上下文。比如你打开 frontend/ 下的文件，Hermes 会自动把 frontend/AGENTS.md 也纳入参考。每个目录只检查一次，最多向上遍历 5 层父目录。这个设计很适合微仓库或者 monorepo 场景：每个子模块都有自己的局部说明，互不干扰，而且不会让系统提示词膨胀。
上下文文件有大文件保护机制：超过 20,000 字符的文件会被截断，只取头部 70% 加尾部 20%，中间 10% 用截断标记提示。这个机制确保即使有人往里塞大段内容，也不会把系统提示词撑爆。
来看一个 AGENTS.md 的实际例子：
# Backend 服务约定
## 技术栈
- Python 3.11 + FastAPI
- PostgreSQL 16 + SQLAlchemy 2.0
- Redis 7 用于缓存和任务队列
## API 开发规范
- 所有端点必须有 OpenAPI 文档注释
- 错误响应统一用 `{ "error": "message", "code": "ERR_CODE" }` 格式
- 分页用 cursor 方式，不用 offset
## 禁止事项
- 不能直接操作 migration 文件
- 不能在代码里硬编码 secrets，用环境变量
- 不能删除生产数据，即使用户要求
## 关键路径
- 入口: src/main.py
- 数据库模型: src/models/
- API 路由: src/api/
- 迁移: alembic/
三层叠加的效果
把这三层组合起来看：一个配置完善的 Hermes 会是这样的——
SOUL.md 稳住基本人设，让它用你期望的语气和方式沟通。Memory 记住了跨会话的重要信息，不用每次重新解释背景。项目上下文文件让每个项目都有自己独立的规则，不会把 A 项目的规范套到 B 项目上。
三层各守本位，Hermes 才不会在长会话里失忆，换项目的时候发疯。
听起来有点复杂，实际上手很简单：先配 SOUL.md 定人设，再根据需要在 Memory 里沉淀关键事实，项目里放好上下文文件就够了。三件事分开管，比塞到一个 prompt 里省心得多。