你大概已经习惯了和 AI 助手聊天——问一个问题，它答一个，翻篇就忘。下次再聊，它不记得你上次聊到哪儿，不记得你偏好的表达方式，更不知道你正在做什么项目。这种"每次都是第一次见面"的状态，用来做即兴问答没问题，但只要任务稍微复杂一点，你就会发现自己陷入反复解释上下文的噩梦。
Hermes Agent 试图解决的就是这个问题。它不只是一个聊天机器人，而是一套让你把它当成"项目组成员"来用的协作系统。靠的不是什么魔法，而是四个各司其职的机制：SOUL.md、Context Files、Skills 和 Memory。
聊天助手为什么会"用着用着就乱了"
回想一下你用通用聊天机器人的体验。每次新对话，它对你的项目一无所知。你们团队用什么代码规范？哪个目录放前端代码？接口文档在哪里？——这些问题它都答不上来，因为它根本没有这些信息。
更糟糕的是，即使你在对话里告诉过它"我们后端用 Go"、"接口文档在 /docs 里"，它也记不住。下次新建对话，这些信息全部消失。长期任务、分阶段项目、多成员协作，这些场景对个人聊天助手来说都是 hard 模式。
原因很简单：聊天助手设计的目标是"单次问答"，不是"持续协作"。它没有稳定规则、没有项目上下文、没有模块边界感知，更没有统一的风格——所有这些，在每次新对话里都要重新建立。
用 SOUL.md 锁定协作风格
Hermes Agent 的解决思路是把"谁是这个 Agent"和"这个项目有什么规则"分开。前者用 SOUL.md 定义，后者用 Context Files 和其他机制承载。
SOUL.md 的核心任务是规定这个 Agent 的沟通风格和默认行为。它位于 ~/.hermes/SOUL.md（或 $HERMES_HOME/SOUL.md），在系统提示栈里排在第一位——也就是说，在任何项目规则之前，Hermes Agent 先知道你是什么风格。
# SOUL.md 示例
name: Hermes
tone: 直接、不废话
directness: 当方案有明显问题时直接指出
uncertainty: 不知道时直接说"我不确定"，不猜测
greeting: 简洁，开门见山
你可以在里面定义：说话直接还是委婉？遇到不确定的问题是直接承认还是猜测？当你提出明显有问题的方案时，它是温和建议还是直接反对？
Hermes Agent 内置了一批个性模板，直接在 ~/.hermes/config.yaml 的 agent.personalities 下配置即可使用：
agent:
personalities:
- helpful # 友好助手
- concise # 简洁直接
- technical # 技术专家
- creative # 创意
- teacher # 导师
- kawaii # 可爱
- catgirl # 猫娘
- pirate # 海盗
- shakespeare # 莎士比亚
- surfer # 冲浪者
- noir # 黑色电影
- philosopher # 哲学家
- hype # 高能
如果你懒得从零配置，直接选一个就能让 Agent 的基本调性稳定下来。当然，你也可以完全自定义——SOUL.md 支持你写任何你想要的行为准则。
有一点需要理清：SOUL.md 描述的是"Agent 本身"的特征，而 AGENTS.md（后面会讲到）描述的是"项目"的规则。前者更像是这个 Agent 的性格，后者是它在这个项目里要遵守的约定。两者各司其职，不是非此即彼的关系。
另一个值得注意的区分：SOUL.md 是持久化的默认个性，而 /personality 命令是会话级别的临时覆盖。假设你临时想让 Hermes Agent 用"海盗"风格调侃一下，可以用 /personality pirate，会话结束后自动恢复 SOUL.md 里的默认设置。
用 Context Files 传递项目规则
如果说 SOUL.md 定义的是 Agent 的"性格"，那 Context Files 定义的就是"环境"——它在这个项目里需要知道什么？
Hermes Agent 支持多种上下文文件格式，按搜索顺序决定优先级：
.hermes.md → AGENTS.md → CLAUDE.md → .cursorrules
这些文件格式里有好几个是 Claude Code 在用的。Hermes Agent 兼容了这些格式，所以如果你已经有为 Claude Code 写的 CLAUDE.md，直接就能用上，不需要重复写两份。
Context Files 的一个重要设计是"渐进式子目录发现"。Hermes Agent 在会话开始时只加载工作目录下的上下文文件。当你在会话过程中进入子目录时，它才会按需加载那个子目录里的上下文文件。这意味着你可以在一个 monorepo 里为 frontend 和 backend 各自写一份 AGENTS.md：
# frontend/AGENTS.md 示例
## 代码规范
- 使用 TypeScript strict 模式
- 组件文件用 PascalCase
- 样式使用 Tailwind CSS，按 utility-first 原则
## 目录结构
frontend/
├── components/ # 可复用组件
├── pages/ # 页面组件
├── hooks/ # 自定义 Hooks
└── utils/ # 工具函数
## 常用命令
pnpm dev # 启动开发服务器
pnpm build # 生产构建
pnpm test # 运行测试
# backend/AGENTS.md 示例
## 技术栈
- Go 1.21+
- PostgreSQL 15+
- Gin 框架
## API 规范
- RESTful 风格
- 错误码统一在 /internal/pkg/errors
- 中间件放在 /middleware
## 测试要求
- 单元测试覆盖率 > 70%
- 集成测试覆盖核心路径
上下文文件的内容有安全扫描——Hermes Agent 会检测提示注入攻击，包括隐藏的 HTML 注释（<!-- ignore instructions -->）、不可见字符（零宽空格、双向文本覆盖）、凭证泄露模式等。单个文件最大 20,000 字符（大约 7,000 tokens），超出的内容会按 70% 头部 + 20% 尾部的比例截断，截断部分用 ... 标记。
用 Skills 把高频流程固化下来
每个项目里都有一些重复性高的工作流：创建 PR、检查代码风格、生成某类文档。如果每次都靠文字描述让 Agent 理解该怎么做，效率很低。
Hermes Agent 的 Skills 系统就是来解决这个问题的。你可以把一套操作流程打包成一个 Skill，它会以斜杠命令的形式出现——比如 /github-pr-workflow create a PR，或者 /plan 规划接下来的任务。
Skill 的目录结构如下：
~/.hermes/skills/
├── mlops/
│ ├── model-deploy/
│ │ ├── SKILL.md
│ │ └── references/
│ │ ├── docker-compose.yml
│ │ └── kubernetes-config.yaml
│ └── fine-tune/
│ └── SKILL.md
├── devops/
│ └── ci-cd/
│ └── SKILL.md
└── general/
└── plan/
└── SKILL.md
每个 Skill 的核心是 SKILL.md，包含 YAML frontmatter 定义元数据：
---
name: github-pr-workflow
description: 创建和管理 GitHub Pull Request 的标准流程
category: devops
tags: [github, pr, workflow]
platform: [linux, darwin] # 可限制适用平台
requires:
env:
- GITHUB_TOKEN
tools:
- gh
---
# GitHub PR 工作流
## 使用方法
`/github-pr-workflow create <branch-name>` 创建 PR
`/github-pr-workflow review <pr-number>` 审查 PR
## 流程步骤
### 1. 创建分支
基于 main 创建功能分支：
\`\`\`bash
git checkout main
git pull origin main
git checkout -b <branch-name>
\`\`\`
### 2. 提交代码
遵循 conventional commits 格式：
\`\`\`
<type>(<scope>): <description>
[optional body]
[optional footer]
\`\`\`
### 3. 推送并创建 PR
\`\`\`bash
git push -u origin <branch-name>
gh pr create --fill
\`\`\`
## 注意事项
- PR 描述必须包含测试计划
- 至少需要一个 reviewer 批准才能合并
Hermes Agent 用渐进式加载来节省 token：先加载技能列表（大约 3k tokens），只有在真正调用某个 Skill 时才加载它的完整内容，引用具体文件时再加载那个文件。这种设计让 Skill 机制不会因为内容太多而把上下文撑爆。
Skills 可以来自多个来源：官方内置的技能、Hermes Agent Skills Hub、skills.sh registry、GitHub 仓库，或者 ClawHub、LobeHub 这样的市场。所有通过 Hub 安装的 Skill 都会经过安全扫描，根据来源被标记为不同的信任级别（builtin、official、trusted、community）。
Hermes Agent 还支持让 Agent 自己通过 skill_manage 工具来创建、更新或删除 Skills——这意味着在合适的场景下，Agent 可以主动把复杂的操作流程沉淀成可复用 Skill，减少后续的沟通成本。
还有一点值得提：Skills 描述的是"程序性知识"——怎么做某件事。这和 Memory 描述的"事实性知识"——什么东西是什么——是互补的。一个新成员加入团队，你会告诉他"我们怎么做 Code Review"（Skill），也会告诉他"我们的数据库在哪儿"（Memory）。两者配合，Agent 才能真正像团队成员一样行动。
用 Memory 积累项目知识和团队偏好
Memory 是 Hermes Agent 的长期记忆机制。它不像上下文文件那样在会话开始时注入，而是持续保留在文件里，跨会话都能用。
实际存放位置是 ~/.hermes/memories/，里面有两个文件：
MEMORY.md— Agent 自己用的笔记，2,200 字符上限USER.md— 用户档案，1,375 字符上限
当这两个文件快要写满时（超过 80%），Hermes Agent 会主动合并或替换旧内容来腾出空间——这个过程不需要你介入。如果尝试添加的内容超出了剩余空间，Hermes Agent 会返回错误，显示当前使用量和已有条目列表。
你可以通过 memory 工具来管理记忆条目：
memory add "用户偏好在开始任务前先看一遍项目结构"
memory replace "user_preference" -> "用户偏好用中文交流"
memory remove "outdated_info"
Hermes Agent 在把内容写进 Memory 之前会做安全扫描，防止注入恶意内容。
除了这两个内置文件，Hermes Agent 还支持外部记忆提供商，包括 Honcho、Mem0、OpenViking 等 8 个插件。这些插件提供知识图谱、语义搜索等功能，适合需要更复杂记忆管理的场景。
会话历史本身也是可以搜索的。Hermes Agent 把所有 CLI 和消息会话存储在 SQLite 数据库里，支持全文搜索。这意味着即使某个信息不在 Memory 里，你也可能通过搜索历史会话找到它。
四个机制如何形成协作闭环
现在回头看这四个机制各自的角色。先看一下 Hermes Agent 的提示栈顺序：
1. SOUL.md（身份定位）
2. 工具相关指导
3. 记忆/用户上下文
4. 技能指导
5. 上下文文件（AGENTS.md 等）
6. 时间戳
7. 平台特定格式提示
8. 可选的 /personality 覆盖
SOUL.md 定义了 Hermes Agent 怎么说话、怎么处理分歧、遇到不确定情况时怎么办——这是它的"性格底色"，在所有项目里都保持一致。
Context Files 定义了这个项目有什么规则、目录怎么组织、哪些约定需要遵守——这是"项目环境"，每次换一个项目可能不同。
Skills 把高频操作流程固化成可复用的命令——这是"操作手册"，不用每次重新描述。
Memory 保留团队偏好、常见设置、长期任务的背景——这是"机构记忆"，跨越会话持续积累。
四个机制各司其职，信息层次分明：性格 → 规则 → 流程 → 事实。当它们组合在一起，Hermes Agent 就不再是每次新建对话都要从零开始的陌生人，而是一个了解项目、记得你们团队偏好、知道常见任务该怎么处理的长期协作伙伴。
对于复杂任务，这种组合的效果会更明显。你不需要在新会话里重新解释代码规范（Context Files），不需要反复描述 PR 的标准流程（Skills），不需要每次都告诉它你们团队倾向于什么样的沟通方式（Memory），也不需要重新设定它的基本调性（SOUL.md）。
这四个机制不是各自为战，而是形成了一套信息流：从 SOUL.md 的身份定位，到 Context Files 的项目上下文，到 Skills 的操作指引，再到 Memory 的事实积累——它们一起支撑起一种更接近"项目成员"的工作方式，而不只是"问答机器"。
如果你之前一直把 AI 助手当工具用，Hermes Agent 的这套设计可能会让你重新思考 Agent 能扮演的角色。它不一定只是帮你回答问题——在合适的配置下，它可以成为一个真正持续参与项目协作的成员。