很多人刚开始用 Hermes,只知道一句:
hermes chat能聊天,能跑命令,能装 Skill,能让它帮你看项目,这就够用了。
但用一阵子之后,你会发现 Hermes 文件夹里、项目文件夹里,开始出现一堆 .md 文件:
SOUL.mdAGENTS.mdSKILL.mdHERMES.md.hermes.mdCLAUDE.md.cursorrulesMEMORY.mdUSER.mdREADME.md新手看到这些文件,第一反应通常是:
这都是什么?
能不能改?
改错了会不会出事?
我想让 Hermes 更懂我,到底该写在哪个文件里?
我想告诉它项目怎么跑,又该写在哪个文件里?
这篇就用大白话讲清楚。
你不用每个都改,也不用一上来折腾。普通用户最重要的是先知道:这些 .md 文件不是一类东西,它们各自管的范围不一样。
先记住一句口诀:
SOUL.md:管“这个助手像谁”AGENTS.md:管“这个项目怎么干”SKILL.md:管“这类任务怎么做”把这三个分清楚,Hermes 就不会越用越乱。
一、先给你一张总地图
Hermes 官方文档里专门讲了 Context Files,也就是上下文文件。Hermes 会自动发现并加载一些文件,用来影响它在当前项目里的行为。文档里列到的项目上下文文件包括 .hermes.md / HERMES.md、AGENTS.md、CLAUDE.md、.cursorrules、.cursor/rules/*.mdc,而 SOUL.md 是全局身份文件,只从 HERMES_HOME 里加载。
普通用户可以先这样理解:
文件
大白话解释
普通用户建议
SOUL.md
助手的性格、人设、说话方式
可以改,但别写太长
AGENTS.md
当前项目的规矩、命令、边界
很值得写
SKILL.md
某类任务的操作手册
会折腾后再动
.hermes.md / HERMES.md
Hermes 专用项目规则
高级用户知道即可
CLAUDE.md
Claude Code 常见项目规则
用 Claude Code 会见到
.cursorrules
Cursor 的项目规则
用 Cursor 会见到
MEMORY.md / USER.md
长期记忆和用户画像
普通用户别乱手改
README.md
给人看的项目说明书
可以读,不等于 Agent 规则
你看到这些文件,不要一股脑都改。
先问自己一个问题:
我现在想告诉 Hermes 的,到底是“我的偏好”,还是“这个项目的规矩”,还是“以后做同类任务的方法”?答案不同,放的位置就不同。
二、SOUL.md:这个助手到底像谁?
先讲 SOUL.md。
这个文件名字听起来最玄,但其实最好理解。
它管的是 Hermes 的长期性格和说话方式。
Hermes 官方 SOUL 指南说,SOUL.md 是 Hermes 实例的主要身份文件,是系统提示词里的第一部分,用来定义 Agent 是谁、怎么说话、应该避免什么。它适合放语气、人格、沟通风格、直接程度,以及 Hermes 如何面对不确定、分歧和模糊问题。
大白话说:
SOUL.md 不是项目说明书。SOUL.md 是这个 Hermes 的“性格底色”。比如你希望 Hermes 长期这样回答:
默认使用中文。先给结论,再给步骤。少说客套话,不要空泛鼓励。不确定的信息要直接说明不确定。当我的想法有风险时,要明确提醒。不要为了讨好我而假装同意。这些就适合放进 SOUL.md。
它回答的是这些问题:
这个助手要不要直接?
要不要温柔?
要不要多解释?
要不要敢反驳?
遇到不确定信息要不要提醒?
回答要偏技术文档,还是偏大白话?
如果你每次都要重复说:
请用中文大白话,不要 AI 腔,别太空泛。那就说明这类规则适合写进 SOUL.md。
三、SOUL.md 不适合写什么?
很多人最容易犯的错,就是把项目规则塞进 SOUL.md。
比如这些就不适合:
这个项目用 pnpm。前端目录是 frontend/。后端端口是 8000。测试命令是 npm test。不要修改 migrations。这些是项目规则,不是助手人格。
Hermes 官方 SOUL 指南也明确说,SOUL.md 不应该放仓库专属代码规范、文件路径、命令、服务端口、架构说明和项目工作流,这些应该放进 AGENTS.md。官方给的判断规则也很清楚:如果它应该到处都适用,放 SOUL.md;如果它只属于某一个项目,放 AGENTS.md。
普通用户可以记住:
跟“我喜欢它怎么说话”有关,放 SOUL.md。跟“这个项目怎么运行”有关,别放 SOUL.md。如果你把项目命令都塞进 SOUL.md,后面会很乱。
今天这个项目用 npm,明天那个项目用 pnpm,后天又换 Python。
全写进 SOUL.md,Hermes 会被你喂成一个“大杂烩助手”。
四、AGENTS.md:这个项目的交通规则
接下来讲 AGENTS.md。
这个文件可以理解成:
给 Agent 看的项目 README。AGENTS.md 官方网站也这么解释:它是一个专门给 AI 编程 Agent 提供上下文和指令的固定位置,可以帮助 Agent 理解项目并按规则工作。这个格式已经被大量开源项目采用。
Hermes 官方 Context Files 文档也说,AGENTS.md 是主要项目上下文文件,会告诉 Agent 项目结构、约定和特殊指令;Hermes 会在 session 启动时加载工作目录里的 AGENTS.md,并在 Agent 进入子目录时逐步发现相关上下文文件。
大白话说:
SOUL.md 告诉 Hermes:你这个助手应该怎么说话。AGENTS.md 告诉 Hermes:你在这个项目里应该怎么干活。适合写进 AGENTS.md 的内容包括:
项目是干什么的;
怎么安装依赖;
怎么启动;
怎么测试;
目录结构怎么分;
哪些文件不能动;
新增依赖要不要先问;
改完以后怎么验收;
遇到危险操作时怎么处理。
比如:
# AGENTS.md## 项目概况这是一个前端小项目,用来验证页面原型。## 常用命令- 安装依赖:`npm install`- 启动项目:`npm run dev`- 构建项目:`npm run build`- 代码检查:`npm run lint`## 目录说明- `src/`:主要源码- `docs/`:文档- `tests/`:测试- `.env`:环境变量文件,不要直接修改## 工作规则- 修改文件前,先说明计划- 修改后,列出改了哪些文件- 不要删除文件,除非我明确同意- 不要修改 `.env`- 新增依赖前必须先问我- 不要把密钥、Token、Cookie 写进代码## 验收标准完成任务后必须说明:1. 做了什么2. 改了哪些文件3. 跑了哪些检查4. 还有什么风险这份不复杂,但已经能帮 Agent 少犯很多低级错。
五、AGENTS.md 不适合写什么?
AGENTS.md 也不是万能垃圾桶。
不适合写这些:
你以后说话温柔一点。请用中文大白话。不要 AI 腔。你是我的长期内容助手。这些是长期风格,应该放 SOUL.md。
也不要写太多空话:
你要非常聪明。你要努力做好。你要像世界顶级工程师一样。这种对 Agent 帮助很小。
AGENTS.md 最有价值的是具体规则:
怎么启动怎么测试哪些文件不能碰什么时候必须问我完成后怎么汇报它越像交通规则,越有用。
它越像口号,越没用。
六、SKILL.md:这类任务的操作手册
再讲 SKILL.md。
这个文件普通用户不一定会手写,但一定会遇到。
尤其你装 Hermes Skill、OpenCLI Skill、Obsidian Skill、PPT Skill、浏览器 Skill 时,经常会看到某个 Skill 目录里有一个:
SKILL.md它到底是什么?
Hermes 官方 Skills 文档说,Skills 是按需加载的知识文档,用来教 Hermes 如何处理特定任务,比如生成 ASCII art、管理 GitHub PR 等。
换成大白话:
SKILL.md 是某类任务的操作手册。它不是某个项目的规矩。
它也不是助手性格。
它更像:
以后遇到这种任务,就按这个流程做。比如你有一个“分析 GitHub 项目”的流程:
# SKILL.md## 什么时候使用当用户给出 GitHub 项目链接,并要求判断是否值得写文章、是否适合普通用户上手时使用。## 工作流程1. 先打开 README2. 核查 Star / Fork / Release3. 查安装命令4. 查系统要求5. 查 Node / Python / Docker / API Key 门槛6. 找第一次最小测试方法7. 判断适合谁、不适合谁8. 输出常见坑和成功标志这就适合沉淀成 Skill。
因为它不是只属于某一个项目,而是你以后反复会用的流程。
七、什么时候该做成 SKILL.md?
普通用户不要一上来就手写 Skill。
更稳的方式是:
先让 Hermes 跑通一次任务。
如果你发现:
这个流程以后会反复用;
你每次都要贴同样的步骤;
Hermes 这次终于跑对了;
你想让它下次遇到同类任务自动想起这套方法;
这时候再考虑沉淀成 Skill。
比如这些适合做 Skill:
每次研究 GitHub 项目的流程;
每次排查 Node 项目启动失败的流程;
每次整理网页资料到 Obsidian 的流程;
每次写头条 AI 工具文章的流程;
每次生成封面图和干货总结图的流程。
Hermes Skills System 文档里也提到,可以直接从一个 HTTP(S) URL 安装单文件 SKILL.md,Hermes 会抓取、解析 frontmatter、安全扫描并安装;这说明 SKILL.md 本质上就是 Skill 的核心说明文件。
普通用户记住:
AGENTS.md 是项目规则。SKILL.md 是可复用流程。这两个别混。
八、.hermes.md / HERMES.md:Hermes 专用项目规则
有些项目里你还可能看到:
.hermes.mdHERMES.md这两个是 Hermes 专用项目上下文文件。
Hermes 官方 Context Files 文档把 .hermes.md / HERMES.md 列为项目指令文件,而且优先级最高。文档还写到,项目上下文类型只会加载一个,优先级是 .hermes.md → AGENTS.md → CLAUDE.md → .cursorrules,而 SOUL.md 会作为 Agent 身份单独加载。
这句话对普通用户有点重要。
意思是:
如果同一个项目里同时有 .hermes.md 和 AGENTS.md,Hermes 会优先用 .hermes.md 这一类专用规则。
所以普通用户一般不用主动建 .hermes.md。
除非你很确定:这个规则只给 Hermes 用,不想被其他 Agent 工具读。
大多数情况下,写 AGENTS.md 更通用。
九、CLAUDE.md:Claude Code 用户常见
如果你用 Claude Code,常见的是:
CLAUDE.md这个文件通常用来给 Claude Code 提供项目规则、代码风格、测试方式等。
Hermes 也会检测 CLAUDE.md 作为项目上下文文件之一,但它的优先级低于 .hermes.md 和 AGENTS.md。
所以你可以这样理解:
CLAUDE.md:更偏 Claude Code 的项目规则文件。AGENTS.md:更通用的 Agent 项目规则文件。如果你同时用 Hermes、Codex、Claude Code,我建议:
核心通用规则写 AGENTS.md;
Claude Code 特有规则再写 CLAUDE.md;
不要在两个文件里写互相矛盾的内容。
十、.cursorrules 和 .cursor/rules/*.mdc:Cursor 用户会遇到
如果你用 Cursor,可能会见到:
.cursorrules.cursor/rules/*.mdc这些是 Cursor 相关的项目规则文件。
Hermes 官方 Context Files 文档也列出了 .cursorrules 和 .cursor/rules/*.mdc,说明 Hermes 可以识别这类 Cursor 规则文件。
普通用户不用深入研究。
你只要知道:
看到 .cursorrules,不要惊讶。它通常是 Cursor 项目规则。如果你主要用 Cursor,那它有价值。
如果你主要用 Hermes,优先看 AGENTS.md 和 SOUL.md 就够了。
十一、MEMORY.md / USER.md:记忆文件,别乱手改
再讲两个容易让人好奇的文件:
MEMORY.mdUSER.mdHermes 的功能总览里提到,它有 Persistent Memory,也就是持久记忆,会通过 MEMORY.md 和 USER.md 记住偏好、项目、环境和学到的信息。
这两个和前面几个不太一样。
它们更像 Hermes 的“长期记忆仓库”。
大白话说:
MEMORY.md:偏向 Agent 自己记下的重要信息。USER.md:偏向关于用户的长期画像和偏好。普通用户不建议一上来手动乱改。
为什么?
因为记忆会进入上下文,写错了可能长期影响 Hermes 的判断。
比如你一时兴起写进去:
用户永远只喜欢极简回答。后面你想要详细分析时,它可能还受影响。
更稳的方式是:
让 Hermes 在聊天中根据真实互动自己维护记忆。
你真想改,也先备份,再少量修改。
十二、README.md:给人看的,不是专门给 Agent 的
最后讲最常见的:
README.mdREADME 是给人看的项目说明书。
它通常写:
项目是什么;
怎么安装;
怎么使用;
功能介绍;
贡献方式;
许可证。
Agent 当然也会读 README,但 README 不一定适合放所有 Agent 规则。
比如:
不要修改 .env新增依赖前必须问我改完必须列出风险这些更适合放 AGENTS.md。
因为 README 面向所有人,太多 Agent 规则会让它变得很臃肿。
AGENTS.md 官方也强调,它就是一个专门给 Agent 提供上下文和指令的可预测位置,可以避免把 README 塞得太满。
所以:
README.md:给人看。AGENTS.md:给 Agent 看。这两个可以互补,不需要互相替代。
十三、到底该写哪里?看这个判断表
如果你还是懵,就看这张表。
你想写的内容
放哪里
默认用中文、大白话、少废话
SOUL.md
不确定就说明,不要装懂
SOUL.md
遇到风险要提醒我
SOUL.md
这个项目用
pnpm install
AGENTS.md
启动命令是
npm run dev
AGENTS.md
修改后必须跑
npm test
AGENTS.md
不要修改
.env
AGENTS.md
不要删除用户文件
AGENTS.md
分析 GitHub 项目的固定流程
SKILL.md
排查 Node 启动失败的步骤
SKILL.md
Hermes 专用项目规则
.hermes.md/
HERMES.md
Claude Code 项目规则
CLAUDE.md
Cursor 项目规则
.cursorrules
用户长期偏好和历史记忆
MEMORY.md/
USER.md,普通用户别乱手改
给人看的项目介绍
README.md
再压缩成一句话:
跟“我这个助手”有关,放 SOUL.md。跟“这个项目”有关,放 AGENTS.md。跟“这类任务”有关,做成 SKILL.md。这个判断基本够用了。
十四、普通用户怎么按需配置?
如果你只是好奇,建议这样做:
第一步,只打开看看,不急着改。
cat ~/.hermes/SOUL.md看看 Hermes 默认人格是什么。
第二步,给常用项目加一个最小 AGENTS.md。
先写启动命令、测试命令、不要改 .env、新增依赖先问我。
第三步,跑通几次任务后,再考虑 Skill。
不要一上来就手写复杂 SKILL.md。
第四步,别乱动 MEMORY.md / USER.md。
如果你真要动,先备份。
第五步,不同工具文件别互相打架。
如果项目里同时有 AGENTS.md、CLAUDE.md、.cursorrules,尽量让核心规则一致。
不要这个文件说“用 npm”,那个文件说“用 pnpm”。
Agent 最怕规则冲突。
十五、最小模板给你一份
如果你想马上动手,先从 AGENTS.md 开始。
因为它最安全,也最实用。
# AGENTS.md## 项目概况这是一个【项目类型】,主要用于【一句话说明用途】。## 常用命令- 安装依赖:`npm install`- 启动项目:`npm run dev`- 运行测试:`npm test`- 代码检查:`npm run lint`## 目录说明- `src/`:主要源码- `docs/`:文档- `tests/`:测试文件- `.env`:环境变量文件,不要直接修改## 工作规则- 修改文件前,先说明计划- 修改后,列出改了哪些文件- 涉及删除文件、安装新依赖、修改环境变量时,必须先问我- 不要改生产配置- 不要把密钥、Token、Cookie 写进代码## 验收标准完成任务后必须说明:1. 做了什么2. 改了哪些文件3. 跑了哪些检查4. 还有什么风险如果你想改 SOUL.md,先别写太多。
最小版本可以这样:
# Identity你是我的长期 AI 助手,擅长把复杂问题讲清楚,并给出可执行步骤。# Style- 默认使用中文- 先给结论,再给步骤- 不确定的信息要直接说明- 遇到风险要提醒我- 不要把简单问题复杂化SKILL.md 先别急着写。
等你某个流程跑通了,再让 Hermes 帮你总结成 Skill。
最后说一句
Hermes 里的 .md 文件确实多。
但它们不是让你背文件名的。
它们真正的作用,是把不同层级的规则分开:
助手性格,放 SOUL.md。
项目规矩,放 AGENTS.md。
可复用流程,放 SKILL.md。
其他工具规则,按工具放 CLAUDE.md、.cursorrules。
长期记忆,交给 MEMORY.md / USER.md,普通用户别乱手改。
人类说明,继续放 README.md。
你不需要一次全配置。
先看懂,再按需改。
对普通用户来说,最值得先动的是两个:
SOUL.md:让 Hermes 更像你的长期助手。AGENTS.md:让 Hermes 更懂当前项目的规矩。等你用久了,发现某个流程反复出现,再考虑:
SKILL.md:把成功流程沉淀成可复用能力。这样用,Hermes 就不会越用越乱。
它会慢慢从一个“什么都能聊的工具”,变成一个知道你习惯、懂项目边界、会复用经验的长期助手。
热门跟贴