本指南默认你已完成 Hermes 的基础安装与配置。我们将直接进入进阶核心内容:记忆系统、技能自进化、多 Agent 协作、生产化部署与高级调试。
目录
一、记忆系统进阶 二、技能自进化 三、多 Agent 协作 四、生产化部署 五、高级扩展与调试 六、疑难解答(Q&A) 七、配置速查表
一、记忆系统进阶
很多人用了 Hermes 一段时间后,最大的抱怨是:"它根本记不住东西。"这通常不是 Bug,而是没有理解它的记忆机制。搞懂这套机制,才能让 Agent 越用越智能。
1 记忆系统整体架构
Hermes 的记忆系统由内置记忆 + 外部记忆提供商 + 运行时上下文三部分组成。内置记忆始终激活;外部 Memory Provider 是叠加能力,而非替代关系。
第一层:内置记忆(始终激活)
默认 profile 下,记忆文件存放于 ~/.hermes/memories/;启用命名 Profile 后,路径会跟随 HERMES_HOME 切换到对应 profile 的 memories/ 目录。
MEMORY.md:Agent 的工作笔记,保存环境事实、项目约定和已学到的技巧。系统硬限制为 2,200 字符,建议日常维持在 1,800 字符左右,预留约 20% 空间供 Agent 自动追加。USER.md:用户画像,保存偏好、沟通风格和工作习惯。系统硬限制为 1,375 字符,建议维持在 1,100 字符左右。
这两个文件在每次会话开始时作为冻结快照(Frozen Snapshot)注入上下文。"冻结"意味着:会话中途 Agent 新写入的记忆,通常要到下一次会话或重载后才会生效。这一设计的核心目的是保持前缀稳定,从而提升 KV Cache 命中率、降低推理成本。
第二层:外部记忆提供商(可选,叠加激活)
外部提供商是对内置记忆的补充,不是替代。启用后,Hermes 会在合适时机从外部提供商提取相关信息,并在会话结束或阶段性反思时同步长期记忆。不同 provider 的具体行为略有差异,以对应 provider 的官方文档为准。
2 Agent-curated memory 机制:为什么它"不记得"?
Hermes 的内置记忆采用 Agent 策展(Agent-curated)机制,而非全量记录。
为什么这样设计?
- 节省 Token、提升推理速度:实时更新记忆会导致 System Prompt 头部频繁变化,破坏 KV Cache 前缀缓存,推理成本和响应速度都会变差。冻结快照能让 Prompt 头部保持稳定,大幅降低 Token 消耗。
- 防止记忆污染、保证质量:Agent 推理过程中的临时试错和中间结果并不值得长期保留。只有经 Agent 判断为"重要"的内容,才会被写入长期记忆,确保记忆保持高密度、干净。
哪些内容更容易被记住?
- 你明确表达了偏好,例如"我喜欢/不喜欢 xxx"
- 发现了环境事实,例如"这台机器装了 xxx"
- 纠正了 Agent 的错误,例如"不要用 sudo,我在 docker 组里"
- 完成了重要任务里程碑
- 你明确要求它记住某件事
触发时机:记忆写入不是每句话实时发生,而是结合 nudge_interval 节奏控制,在若干轮对话后触发一次"记忆反思"。会话太短或任务过于单一时,Agent 可能没有足够机会整理和固化记忆。
最直接的解决方案:在对话中明确下达记忆指令,例如:
记住我的偏好:所有代码统一使用 Python 3.11,不要用 3.12 或 3.13。
3 核心记忆文件使用方法(附模板)
| 文件 | 路径 | 用途 | 谁来维护 |
|---|---|---|---|
MEMORY.md |
~/.hermes/memories/ |
工作笔记、环境事实、学到的技巧 | 主要由 Agent 维护 |
USER.md |
~/.hermes/memories/ |
用户画像、偏好、沟通风格 | 主要由 Agent 维护 |
SOUL.md |
~/.hermes/ |
Agent 的人格、行为准则、固定规则 | 建议你自己编写 |
AGENTS.md |
项目根目录 | 项目级行为规范和执行约束 | 建议你自己编写 |
铁律:不要把应该写在 SOUL.md 里的内容放进 MEMORY.md。
MEMORY.md 会被整理、压缩,甚至替换过时内容;你的固定规则应放在 SOUL.md,那里适合承载稳定的、不希望被自动重写的约束。
AGENTS.md 模板(复制到项目根目录)
# 项目规范:MyAPI Service
## 技术栈
- 语言:Rust 1.75+
- 框架:Axum
- 数据库:PostgreSQL 16(使用 SQLx)
## 编码约定
1. 所有数据库查询必须使用 SQLx 的宏进行编译期检查。
2. 错误处理统一使用 anyhow::Result 和自定义的 AppError 枚举。
3. 环境变量配置在 .env 文件中,不要在代码中硬编码任何凭证。
## 常用命令
- 运行测试:cargo test --all-features
- 启动服务:cargo run --bin server
4 nudge 频率配置
在 ~/.hermes/config.yaml 中找到或添加:
memory:
nudge_interval: 5
数值越小,记忆反思越频繁,写入内容通常更多,但 Token 消耗也会增加。推荐值可参考以下经验:
- 小模型 / 较小上下文窗口:从 3~5 起步,需要更早固化重要信息。
- 标准模型 / 常见上下文窗口:从 5~10 起步,在成本与记忆质量间取得平衡。
- 大上下文模型:可考虑 10~15,因为它们可以在更长对话后做出质量更高的总结。
nudge_interval的"轮"指一次完整的用户输入与 Agent 回复,不是 Agent 内部的 tool call 次数。
5 跨会话与长任务记忆保持
方法一:手动插入 Checkpoint
在长任务进行到一半时,主动告知 Agent:
当前进度总结:我们已完成数据清洗和特征工程,下一步是训练模型。请把这个进度写入你的记忆,确保后续不会忘记。
方法二:用外部文件作为任务状态文件
对于超长任务,让 Agent 维护一个专门的状态文件:
请在项目目录下创建 TASK_STATUS.md,记录当前任务的完整状态。每次恢复工作时,先读取这个文件。
6 外部 Memory Providers 实战配置
自 v0.7.0 起,Hermes 已支持多种外部 Memory Providers,包括:Honcho、Mem0、Holographic、Supermemory 等。内置的 MEMORY.md / USER.md 仍继续工作,并不会被外部 provider 替代。实际支持列表请以当前版本官方文档为准。
推荐一:Mem0(自动化程度高,适合不想手动设计记忆流程的用户)
pip install mem0ai
echo "MEM0_API_KEY=your-key-here" >> $HERMES_HOME/.env
hermes config set memory.provider mem0
hermes memory status
推荐二:Holographic(本地运行,隐私友好)
hermes config set memory.provider holographic
hermes memory status
7 记忆文件管理与清理技巧
记忆的核心逻辑是:越稳定、越高密度越好,而不是越多越好。
MEMORY.md(2,200 字符上限)通常适合保存 8~15 条高价值事实。USER.md(1,375 字符上限)通常适合保存 5~10 条稳定偏好。
建议将内容控制在容量上限的 70%~80%,保持内容紧凑、可复用、不过度重复。
当 MEMORY.md 接近上限时,可以引导 Agent 主动整理:
请整理你的记忆,删除过时条目,合并相关条目,腾出空间。
也可以直接手动编辑:
nano ~/.hermes/memories/MEMORY.md
8 记忆与技能的联动
当 MEMORY.md 中多次出现类似工作流记录时,这往往意味着该流程更适合沉淀为一个 Skill,而不是继续零散地保存在记忆里。你可以主动引导:
我注意到你已经记住了我们的部署流程。请把它创建为一个可复用的 Skill,命名为 deploy-workflow。
动手实践:构建你的专属记忆系统
- 将
SOUL.md模板复制到~/.hermes/SOUL.md,根据实际情况修改。 - 在常用项目目录下创建
AGENTS.md。 - 将
config.yaml中的nudge_interval设置为 5 进行测试。 - 开启新对话,告知 Agent 一条偏好,例如:"以后所有 Python 脚本都保存在
/tmp/scripts目录下。" - 进行 5 轮以上对话,观察是否触发记忆整理。
预期效果:运行 cat ~/.hermes/memories/MEMORY.md,能看到你刚才告知的偏好已被记录。开启新会话后,Agent 在编写 Python 脚本时应能自动遵循该偏好。
二、技能自进化
Hermes 的核心差异不只是"能干活",而是"越干越会干"。理解技能自生成机制,才能让 Agent 真正进化,而不是每次都从零开始。
1 自我进化机制详解(Agent-Managed Skills)
技能自进化与 skill_manage 工具密切相关。这更接近 Agent 的"程序性记忆":当它摸索出一套非平凡的工作流后,会把这套方法保存为 Skill,供未来复用。
记忆 vs 技能的本质区别:
- 记忆:事实和经验的碎片化记录,解决"记得住"的问题。
- 技能(Skill):将经验提炼为清晰的触发条件 + 操作步骤 + 注意事项 + 验证方法,相当于标准化 SOP,解决"用得高效且可复用"的问题。
Skill 通常存放在当前 HERMES_HOME 对应的 skills/ 目录下(默认为 ~/.hermes/skills/)。它不是可执行代码,而是告诉 Agent"遇到这类任务时应该怎么做"的操作知识。
2 自动创建 Skill 的触发条件
常见触发场景:
- 完成了一个相对复杂的任务
- 遇到错误后找到了正确路径
- 用户纠正了它的做法
- 发现了值得复用的非平凡工作流
主动引导 Agent 创建 Skill:
我们刚完成的数据处理流程很有价值,请把它保存为一个 Skill,命名为 data-pipeline,放在 devops 分类下,包含触发条件、操作步骤、注意事项和验证方法。
3 技能质量评估标准
一个好的 Skill 应具备:
- 触发条件清晰:Agent 能准确判断何时该用它
- 步骤可执行:每一步都有明确操作,而非空泛描述
- 有验证方法:执行完后能判断是否成功
- 有注意事项:记录了已踩过的坑
手动优化时,建议让 Agent 做定点修改而非整篇重写:
请更新 stock-daily-report 这个 Skill,在注意事项里补充一条:"周五收盘后数据可能延迟到周六早上才完整。"
4 技能退化与重复问题
常见表现:描述越来越模糊,触发条件越来越宽泛;多个 Skill 做同一件事但写法不同。
解决方案:让 Agent 做技能审计。
请审查所有 Skills,找出:功能重复的(合并它们)、描述模糊的(重写它们)、步骤过时的(更新它们)。给我一份审计报告,等我确认后再执行修改。
5 Skill 与记忆系统的联动
在 SKILL.md 中,可以引导 Agent 在执行技能前先查看记忆:
## 操作流程
1. 先检查 MEMORY.md 中是否有关于该 API 的特殊注意事项。
2. 如果有,优先遵循记忆中的约定。
3. 执行完成后,将新发现的注意事项写入 MEMORY.md。
6 Self-optimization 功能说明
从 v0.8.0 到 v0.9.0,Hermes 在 tool-use 优化和失败模式修复上持续增强,使 Agent 在遇到问题时能更智能地调整行为策略。但具体实现细节和配置入口会随版本迭代,建议以官方最新文档为准。
动手实践:训练你的第一个自动化技能
- 找一个你经常做的重复性任务,例如:清理 Docker 悬空镜像并输出简报。
- 在对话中一步步引导 Agent 完成任务,纠正错误,直到执行稳定。
- 发送指令:"请把刚才的清理流程保存为 Skill,命名为
docker-cleanup,包含触发条件、执行命令和验证步骤。" - 运行
hermes skills list验证是否创建成功。
预期效果:新会话中直接发送 /docker-cleanup,Agent 能按之前固化的步骤稳定完成任务。
三、多 Agent 协作
1 Sub-Agent 的 spawn 机制
Hermes 对子 Agent 并发做了保护性限制。对于大多数在线模型场景,建议从 2~3 个并发子任务起步,再根据额度、限流情况和结果质量逐步调整。并发越高,API 消耗增长越快,且更容易触发 Rate Limit。
主 Agent 可通过 delegate_task 等方式派生子 Agent:
这个任务可以并行处理:
子任务 A:抓取 A 股今日涨停板数据
子任务 B:分析北向资金流向
子任务 C:生成市场情绪指数
请派生 3 个子 Agent 并行完成,然后汇总结果。
子 Agent 的关键限制(必读):子 Agent 往往从全新的会话上下文开始,不会自动继承主 Agent 的历史。你必须在 context 中把所需背景信息传递完整:
delegate_task(
goal="修复 api/handlers.py 中的 TypeError",
context="""
文件路径:/home/user/myproject/api/handlers.py
错误信息:第 47 行 TypeError: 'NoneType' object has no attribute 'get'
原因:parse_body() 在 Content-Type 缺失时返回 None
项目使用 Python 3.11 + Flask
"""
)
不要假设子 Agent 知道"这个错误""刚才那个文件""上一步那个思路"是什么。
2 Profiles 功能实战
Profile 是一个完全隔离的 Hermes 环境,每个 Profile 拥有独立的配置、记忆、会话和技能,底层通过独立的 HERMES_HOME 路径实现目录隔离。
注意:默认 profile 仍然是
~/.hermes;只有显式创建并切换到命名 Profile 时,相关文件才会切换到~/.hermes/profiles/<name>/。
创建 Profile 的三种方式:
# 方式一:全新 Profile(空白)
hermes profile create mybot
# 方式二:克隆配置(复用 API Key 和模型,记忆和会话独立)
hermes profile create work --clone
# 方式三:完整克隆(包含记忆、会话、技能等)
hermes profile create backup --clone-all
运行多个独立 Agent:
# 终端 1:编码助手
hermes -p coder chat
# 终端 2:投研助手(独立的记忆和技能)
hermes -p research chat
3 子 Agent 的记忆与技能隔离
每个 Profile 的 memories/、skills/、sessions/ 和 logs/ 目录相互独立,不会互相读写。
若希望多个 Profile 共享同一套技能,可配置外部技能目录(具体字段名以当前版本配置参考为准):
skills:
external_dirs:
- ~/.hermes/shared-skills
4 主 Agent 协调多个子 Agent 的技巧
在 SOUL.md 或 AGENTS.md 中明确定义角色分工:
## 多 Agent 协作规范
- Planner Agent:负责任务分解和进度追踪,不直接执行
- Executor Agent:负责具体的数据获取和处理,不做决策
- Reviewer Agent:负责质量检查和结果验证,不做修改
5 多 Agent 资源分配与冲突避免
Bot Token 冲突:两个 Profile 如果使用同一个 Bot Token,运行中的 Gateway 会产生冲突。应在各自的 .env 中配置不同的 Token。
端口冲突:本地运行多个 Hermes 实例时,应使用不同端口:
# Profile A
GATEWAY_PORT=8080
# Profile B
GATEWAY_PORT=8081
动手实践:配置双 Agent 协作工作流
- 运行
hermes profile create coder --clone,创建专门写代码的 Agent。 - 运行
hermes profile create reviewer --clone,创建专门做代码审查的 Agent。 - 分别编辑各自的
SOUL.md,赋予不同角色定位。 - 让
coder写一段含 Bug 的代码并保存到文件。 - 切换到
reviewer,让它读取该文件并提出修改建议。
预期效果:两个 Agent 独立运行,reviewer 的记忆中不会混入 coder 的工作流。
四、生产化部署
1 Gateway 长期后台运行
方式一:Systemd(Linux 生产环境首选)
hermes gateway install
systemctl status hermes-gateway
journalctl -u hermes-gateway -f
方式二:Docker Compose(适合多 Profile 部署)
version: "3.8"
services:
hermes-default:
image: nousresearch/hermes-agent:latest
restart: unless-stopped
command: gateway run
volumes:
- ~/.hermes:/opt/data
hermes-coder:
image: nousresearch/hermes-agent:latest
restart: unless-stopped
command: gateway run
volumes:
- ~/.hermes/profiles/coder:/opt/data
重要:不要让两个容器挂载同一个数据目录,否则共享状态文件会产生冲突。
2 定时任务、Heartbeat 与通知机制
⚠️ 警告:严禁盲目复制模板时区!
Hermes 的 Cron 任务严格依赖服务器系统时区。配置前必须确认:
timedatectl
# 国内服务器应显示 Asia/Shanghai,否则执行:
sudo timedatectl set-timezone Asia/Shanghai
时区设置错误会导致定时任务在错误时间触发。
Heartbeat 配置(防止静默失败):
echo "GATEWAY_HEARTBEAT=true" >> ~/.hermes/.env
添加定时任务:
# 工作日早上 8:30 生成日报
hermes cron add "30 8 * * 1-5" "生成今日 A 股市场日报并发送到 Telegram"
创建任务后,建议先手动触发一次验证逻辑是否正常:
hermes cron list
hermes cron run 任务名称
3 日志监控与调试
日志目录跟随当前 profile 的 HERMES_HOME,默认 profile 下通常位于 ~/.hermes/logs/。
hermes logs # 查看日志
hermes debug share # 生成脱敏调试报告(向社区或官方反馈问题时使用)
4 Tirith 安全模块
Tirith 是 Hermes 的预执行安全扫描模块,配置如下:
approvals:
mode: manual # manual | smart | off
manual:所有高风险命令需人工确认。smart:做一层风险分级,低风险场景更顺滑。off:关闭安全检查,仅适合完全可信的环境。
如果某些高频命令被误拦截,可在当前版本支持的情况下将其加入白名单(具体字段名请以当前版本配置参考为准)。
5 Telegram 接入
echo "TELEGRAM_BOT_TOKEN=your-bot-token" >> ~/.hermes/.env
echo "TELEGRAM_ALLOWED_USERS=your-telegram-user-id" >> ~/.hermes/.env
提醒:上线前必须配置用户白名单,否则任何人都能与你的 Bot 交互。
6 生产化部署 Checklist
- [ ]
hermes doctor无明显报错 - [ ] API Key 已配置在
.env文件中,而非config.yaml - [ ] 已按需设置
GATEWAY_HEARTBEAT=true - [ ] 已配置用户白名单(如
TELEGRAM_ALLOWED_USERS) - [ ] 已设置
approvals.mode - [ ] 已安装为 Systemd 服务,或容器设置了自动重启
动手实践:完成生产环境的稳定部署
- 在
.env中配置好 Telegram 的 Token 和你的 User ID。 - 使用
hermes gateway install注册为 Systemd 服务,或采用 Docker Compose。 - 启动服务:
systemctl start hermes-gateway。 - 在手机上向 Bot 发送消息测试。
- 配置一个简单的 Cron 任务,测试定时触发是否正常。
预期效果:关闭 SSH 终端后,Bot 仍能正常回复;Cron 任务能在指定时间附近准确触发。
五、高级扩展与调试
1 MCP 外部工具链集成
MCP(Model Context Protocol)允许为 Hermes 接入外部工具,例如本地文件系统、数据库、自定义 API 等。
接入本地文件系统:
npm install -g @modelcontextprotocol/server-filesystem
在 $HERMES_HOME/mcp.json 中配置:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/home/ubuntu/projects",
"/home/ubuntu/data"
]
}
}
}
配置后,Agent 可通过 MCP 工具直接读写指定目录,而不必每次依赖终端命令。
2 调试工具箱
hermes doctor # 全面健康检查,优先运行
hermes memory status # 检查记忆系统
hermes mcp status # 检查 MCP 连接
hermes debug share # 生成脱敏调试报告
动手实践:接入本地文件系统
- 安装
@modelcontextprotocol/server-filesystem。 - 配置
mcp.json,将一个安全的测试目录暴露给 Agent。 - 运行
hermes mcp status确认连接成功。 - 在对话中让 Agent 列出该目录下的文件内容。
预期效果:Agent 无需执行普通 shell 命令,即可通过 MCP 工具读写指定目录中的文件。
六、疑难解答(Q&A)
Q1:为什么告诉了 Agent 一件事,它下次还是不记得?
常见原因:会话太短,没有触发记忆整理;或 Agent 认为该内容不值得长期保存。最直接的做法是明确说:"请把这件事写入你的长期记忆。"
Q2:Cron 定时任务没有按时触发怎么办?
按顺序排查:① 运行 hermes cron list,确认任务状态正常;② 检查 Gateway 是否在后台运行;③ 运行 timedatectl 检查系统时区;④ 手动运行 hermes cron run 任务名 确认任务逻辑本身无问题。
Q3:Tirith 总是拦截正常的 bash 命令怎么办?
三个方向:① 临时切到更宽松的工作模式;② 将 approvals.mode 从 manual 调整为更灵活的策略;③ 如果版本支持命令白名单,将高频安全命令加入 allowlist。
Q4:多个 Profile 可以共享同一个 Telegram Bot 吗?
不建议。多个运行中的 Gateway 应使用独立 Token,避免冲突。
Q5:日志文件太大怎么清理?
先确认当前版本是否已提供轮转或管理机制;若没有,可手动清理旧日志,清理前确认重要问题已留档。
Q6:多个子 Agent 并发时 API 消耗急剧增长,如何控制成本?
四个有效方法:① 从 2~3 个并发子任务起步,不要一开始就开太多;② 让子任务尽量短且上下文清晰,避免反复试错;③ 让子任务优先使用更便宜的模型,并控制最大轮次;④ 如果版本支持 Credential Pools,利用多 API Key 自动轮转缓解 429 限流。
Q7:子 Agent 为什么总是说不知道任务背景?
子 Agent 从新的上下文开始,不会继承主会话历史。你必须在 context 字段中明确写出文件路径、报错信息、项目结构、依赖版本等所有必要背景。
七、配置速查表
以下示例按默认 profile 编写。如果你使用命名 Profile,请将所有
~/.hermes替换为当前 profile 的HERMES_HOME。
生产环境参考 config.yaml
agent:
max_turns: 90
memory:
nudge_interval: 10
provider: mem0 # 或 holographic / honcho / supermemory 等
approvals:
mode: smart
terminal:
backend: docker
timeout: 60
生产环境参考 .env
# 核心 API Key
OPENAI_API_KEY=sk-xxx
ANTHROPIC_API_KEY=sk-ant-xxx
# Gateway 配置
GATEWAY_PORT=8080
GATEWAY_HEARTBEAT=true
# 平台接入与白名单
TELEGRAM_BOT_TOKEN=123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11
TELEGRAM_ALLOWED_USERS=123456789,987654321
# 外部记忆提供商(按需启用)
MEM0_API_KEY=m0-xxx
approvals.mode: smart是面向生产的推荐策略示例,不代表官方默认值。如果你的环境更强调稳妥与审计,可以继续使用manual。
本文已按官方截至 v0.9.0 的文档与发布说明完成修订。若本机实际命令输出、配置键名或插件列表与本文存在差异,请以当前版本官方文档、release notes 和 hermes doctor 实际结果为准。