# Hermes Agent 从中级到高级进阶指南：让你的AI助手真正"记住你"
**作者**: 弘毅新征程
**日期**: 2026-04-23T08:25:58.000Z
**来源**: [https://x.com/hongyi88/status/2047230488163864664](https://x.com/hongyi88/status/2047230488163864664)
---
你是不是也有过这种经历？跟Hermes聊了一大堆需求和偏好，结果下次开新会话，它就像什么都没发生过一样——"你是谁来着？"
别急着骂它记性差。真相是：Hermes的记忆系统有非常明确的设计逻辑，你可能一直没搞对用法。
本文适合已完成基础配置的同学，直接上进阶内容。
## 一、记忆系统的三层架构
很多人踩坑的根源在于：把Hermes当成了"全量记录仪"。实际上，它的记忆系统是内置记忆 + 外部提供商 + 运行时上下文的三层组合，理解这个架构，你才能真正用活它。
第一层：内置记忆（始终激活）
内置记忆由两个文件组成，默认存放在~/.hermes/memories/目录。启用命名Profile后，路径会跟随当前HERMES_HOME变化。
MEMORY.md——更像Agent的工作笔记，保存环境事实、项目约定和学到的技巧。硬限制2200字符，建议日常维持在1800字符左右，给Agent自动追加预留20%空间。
USER.md——更像用户画像，保存你的偏好、沟通风格和工作习惯。硬限制1375字符，建议维持在1100字符左右。
关键点："冻结快照"。这两个文件在每次会话开始时，会作为冻结快照注入上下文。这意味着：会话中途写入的记忆，通常要到后续会话才能更明显体现。这种设计的核心目的是保持前缀稳定，从而提升KV Cache命中并降低推理成本。
第二层：外部记忆提供商（可选叠加）
外部提供商是对内置记忆的补充，不是替代。启用后，Hermes会在合适时机从外部提取相关信息，会话结束时同步新的长期信息。自v0.7.0起支持Honcho、Mem0、Holographic、Supermemory等多种Provider。
推荐一：Mem0（省心自动化）
Hermes Agent 的 Mem0 功能是将 Mem0 作为外部可插拔记忆提供商，与内置的本地 MEMORY.md / USER.md 记忆系统协同工作，实现自动从对话中提取事实、去重并进行语义搜索的长期记忆能力。 启用后，Mem0 在后台自动运行（对话前零延迟预取记忆、对话后同步存储），无需手动维护，只需运行 hermes memory setup 选择 Mem0 并输入 API Key 即可。
配置方法：
pip install mem0ai
# 获取API Key: https://app.mem0.ai/
echo "MEM0_API_KEY=your-key-here" >> $HERMES_HOME/.env
hermes config set memory.provider mem0
hermes memory status
推荐二：Holographic（本地隐私友好）
Hermes 的 Holographic 功能是一个完全本地的记忆提供商，使用 SQLite 数据库 + HRR（Holographic Reduced Representations）技术，实现快速事实存储、关键词搜索和高级代数式组合推理，无需任何 API Key 或网络。
配置方法：
hermes config set memory.provider holographic
hermes memory status
这两条命令就是 手动把 Hermes 的长期记忆切换成完全本地的 Holographic，并立刻检查是否切换成功。执行完后，你的 Hermes Agent 就完全使用本地记忆了，数据不会上传到云端，隐私更高。
第三层：运行时上下文（会话级）
当前会话内的对话历史，不写入任何文件，只存在于本次会话的内存中。
## 二、为什么你的Hermes"不记得"？
这是最多人踩的坑。 Hermes的内置记忆是Agent策展（Agent-curated）的，不是全量记录。
机制原理：
Hermes把记忆写入设计成"冻结快照 + Agent策展机制"，有两个重要原因：
节省Token和提升推理速度。 如果每轮对话都实时更新记忆，System Prompt的头部就会频繁变化，导致模型无法有效利用KV Cache（前缀缓存），推理成本和响应速度都会明显变差。冻结快照的设计能让Prompt头部保持相对稳定，大幅降低Token消耗。
防止记忆污染，保证质量。 Agent在思考过程中的很多"碎碎念"、临时试错、中间结果，其实并不值得长期保留。只有经过Agent自己判断"重要"的内容，才会被策展后写入长期记忆。这样能让记忆保持干净、高密度，避免低价值信息干扰后续决策。
简单总结：实时写入会贵且乱，策展+周期性nudge是性能与质量的平衡点。
触发时机：
Agent不会把你说的每一句话都写进记忆。通常只有在以下场景，记忆才更容易被保留：
你明确表达了偏好，例如"我喜欢/不喜欢xxx"
发现了环境事实，例如"这台机器装了xxx"
纠正了Agent的错误做法，例如"不要用sudo，我在docker组里"
完成了一个重要任务里程碑
你明确要求它记住某件事
写入通常不是每句话实时发生，而是结合nudge_interval这类节奏控制，在若干轮对话后触发一次"记忆反思"。如果会话太短或任务太单一，Agent可能根本没有足够机会整理并固化记忆。
解决方案：尽量明确地下达记忆指令。
最直接的方法：
"记住我的偏好：所有代码统一使用Python 3.11，不要用3.12或3.13。"这样更容易让Agent把这类信息视为值得长期保留的内容。
## 三、核心记忆文件的正确用法
很多人搞混了这几个文件的用途。按用途来记会更直观：
MEMORY.md（~/.hermes/memories/）——Agent的工作笔记，主要由Agent维护，会被整理压缩甚至替换过时内容。
USER.md（~/.hermes/memories/）——用户画像，主要由Agent维护。
SOUL.md（~/.hermes/）——Agent的人格、行为准则和固定规则，这部分更适合你自己来写。铁律：不要把应该写在SOUL.md里的东西放进MEMORY.md，因为MEMORY.md的内容会被自动重写。
AGENTS.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`
## 四、Super Memory与nudge配置
调整nudge频率，打开~/.hermes/config.yaml：
memory:
nudge_interval: 5
数值越小，Agent越频繁地进行记忆反思，Token消耗也会增加。
推荐值按模型能力来估算：
- 小模型/小上下文窗口 → 从3-5起步，上下文紧，需要更早固化重要信息
- 标准模型/常见上下文 → 从5-10起步，成本与记忆质量更平衡
- 大上下文模型 → 考虑10-15，可以在更长对话后再做高质量总结
注意：这里的"轮"是指一次完整的用户输入与Agent回复，而不是Agent内部的tool call次数。在很多环境里默认值是10，但不同版本、旧配置迁移结果可能不同，以本机config.yaml为准。
## 五、跨会话与长任务记忆保持
方法一：手动插入Checkpoint（最简单有效）
在长任务进行到一半时，主动告诉Agent：
"当前进度总结：我们已经完成了数据清洗和特征工程，下一步是训练模型。请把这个进度写入你的记忆，确保后续不会忘记。"方法二：用外部文件作为"任务状态文件"
对于超长任务，让Agent维护一个专门的状态文件：
"请在项目目录下创建TASK_STATUS.md，记录当前任务的完整状态。每次我们恢复工作时，先读取这个文件。"
## 六、记忆文件管理规则与清理技巧
记忆容量管理的核心逻辑：记忆不是越多越好，而是越稳定、越高密度越好。
- MEMORY.md的2200字符硬限制，通常适合保存8-15条高价值事实
- USER.md的1375字符硬限制，通常适合保存5-10条稳定偏好
最佳实践不是"把容量塞满"，而是尽量让内容保持紧凑、可复用、不过度重复。实战中控制在70%-80%左右通常更舒服，但这属于经验建议，不是硬性规则。
当MEMORY.md接近上限时，手动引导Agent：
"请整理你的记忆，删除过时条目，合并相关条目，腾出空间。"手动清理也可以直接编辑：nano ~/.hermes/memories/MEMORY.md
## 七、记忆与技能的联动机制
这是很多人忽视但非常重要的机制。
当Agent在MEMORY.md中多次记录了类似工作流，例如"每次部署前都要执行A、B、C三步"，这通常意味着：这个流程更适合沉淀为一个Skill，而不是继续零散地塞在记忆里。
主动引导：
"我注意到你已经记住了我们的部署流程。请把这个流程创建为一个可复用的Skill，名字叫deploy-workflow，这样以后可以直接复用。"我的理解一：记忆解决"记得住"，技能解决"用得高效且可复用"
记忆更多是"事实和经验的记录"，相对散乱。而Skill是把这些经验提炼成清晰的触发条件 + 操作步骤 + 注意事项 + 验证方法，相当于把"知道怎么做"变成"标准化SOP"。这样做的好处是大幅降低Agent每次重新推理的负担，同时Skill更容易被标准化、复用，甚至跨Profile或跨Agent分发。
从长期看，记忆是私有的、碎片化的，而Skill是可共享、可积累的"程序性知识"——这是Hermes实现"规模化协作"和"持续自我进化"的重要基础。
## 八、技能自进化机制
Hermes最大的差异点不只是"能干活"，而是"越干越会干"。
Agent自动创建Skill的触发条件通常包括：
- 完成了一个相对复杂的任务
- 遇到了错误或死路，后来找到了正确路径
- 你纠正了它的做法
- 发现了一个值得复用的非平凡工作流
主动引导创建Skill：
"请把刚才的清理流程保存为一个Skill，命名为docker-cleanup，包含触发条件、具体执行命令和验证步骤。"技能质量判断标准：
- 触发条件清晰：Agent能准确判断什么时候该用它
- 步骤可执行：每一步都有明确操作，而不是空泛描述
- 有验证方法：执行完后能判断是否成功
- 有注意事项：记录了踩过的坑
技能退化怎么办？ 让Agent做技能审计：
"请审查你所有的Skills，找出功能重复的、描述模糊的、步骤已过时的，给我一份审计报告，然后等我确认后再执行修改。"
## 九、Sub-Agent协作与Profiles
Sub-Agent并发保护机制：
实战中不建议一上来把并发拉太高。对大多数在线模型场景，更稳妥的起点是2-3个子Agent，再根据额度、限流情况和结果质量逐步调整。
专家建议：并发数不建议超过3个，特别是使用官方API时，建议从2个起步，防止触发Rate Limit或被封禁IP。追求理论最大并发往往不如控制成本与上下文质量重要。子Agent的关键限制：
子Agent往往从一个新的会话上下文开始，不会天然继承主Agent的完整历史。必须在context里把子Agent所需的背景信息传完整：
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协作的本质是分工，不是堆量
Sub-Agent不是越多越好，关键在于"谁来决策、谁去执行、谁做验证"。提前定义角色分工，比疯狂堆并发更有效。同时记住：子Agent不会继承主Agent的完整历史，你必须在context里把背景信息传完整，否则它真的什么都不知道——不要假设它知道"刚才那个文件""上一步那个思路"是什么。
Profiles功能：同一台机器运行多个独立Hermes
Profile是完全隔离的Hermes环境，每个Profile都有自己独立的配置、记忆、会话和技能。
# 方式一：全新空白Profile
hermes profile create mybot
# 方式二：克隆配置（复用API Key和模型，记忆会话独立）
hermes profile create work --clone
# 方式三：完整克隆（包含记忆会话技能等更多状态）
hermes profile create backup --clone-all
多Profile运行示例：
# 终端1：编码助手
coder chat
# 终端2：投研助手（独立记忆和技能）
research chat
冲突避免：
- Bot Token冲突：如果两个Profile使用同一个Bot Token，Gateway会产生冲突。各自.env中配置不同Token。
- 端口冲突：本地运行多个实例时使用不同端口，如8080和8081。
## 十、生产化部署的实战要点
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
container_name: hermes-default
restart: unless-stopped
command: gateway run
volumes:
- ~/.hermes:/opt/data
注意：不要同时运行两个容器挂载同一个数据目录。
定时任务与时区问题
⚠️ 专家级警告：严禁盲目复制模板时区！Hermes的Cron任务严格依赖服务器系统时区。配置前必须运行timedatectl确认。
- 国内服务器：应显示Asia/Shanghai
- 海外服务器：若显示UTC，请手动执行sudo timedatectl set-timezone Asia/Shanghai修正
否则你的定时任务会在半夜"惊喜上线"。
# 工作日早上8:30生成日报
hermes cron add "30 8 * * 1-5" "生成今日A股市场日报并发送到Telegram"
# 创建任务后手动验证
hermes cron list
hermes cron run 任务名称
Heartbeat机制（防止静默失败）：
echo "GATEWAY_HEARTBEAT=true" >> ~/.hermes/.env
Tirith安全模块
Tirith是Hermes的预执行安全扫描模块，配置三种模式：
approvals:
mode: manual # manual | smart | off
- manual：所有高风险命令都需要人工确认
- smart：由辅助判断做一层风险分级，低风险场景更顺滑
- off：关闭安全检查，仅适合可信环境
生产化部署Checklist
- [ ] hermes doctor无明显报错
- [ ] API Key已配置在.env文件中
- [ ] 已按需设置GATEWAY_HEARTBEAT=true
- [ ] 已配置用户白名单
- [ ] 审批模式已根据需求设置
- [ ] 已安装为Systemd服务或设置容器自动重启
## 十一、高级扩展与调试
MCP外部工具链集成
MCP允许为Hermes接入外部工具，如本地文件系统、数据库、自定义API等。
实战：接入本地文件系统
npm install -g @modelcontextprotocol/server-filesystem
在$HERMES_HOME/mcp.json中配置：
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/ubuntu/projects"]
}
常用调试工具箱
hermes doctor # 全面健康检查，优先运行
hermes memory status # 检查记忆系统
hermes mcp status # 检查MCP连接
hermes debug share # 生成脱敏调试报告
## 十二、疑难Q&A
Q1：为什么告诉了Agent一件事，它下次还是不记得？
A：常见原因——会话太短，没有触发记忆整理；或者Agent认为不值得长期保存。最直接做法：明确说"请把这件事写入你的长期记忆"。
Q2：Cron定时任务没有按时触发怎么办？
排查顺序：①hermes cron list确认任务状态 ②检查Gateway是否在后台运行 ③timedatectl检查服务器时区 ④hermes cron run 任务名手动验证逻辑。
Q3：Tirith总是拦截正常命令怎么办？
从三个方向处理：①临时切到更宽松工作模式 ②调整approvals.mode ③如果版本支持命令白名单，把高频安全命令加入allowlist。
Q4：多个Profile可以共享同一个Telegram Bot吗？
通常不建议。多个运行中的Gateway最好使用独立Token，避免冲突。
Q5：日志文件太大怎么清理？
先看当前版本是否提供轮转或管理机制；如果没有，再手动清理旧日志文件，清理前确认重要问题已留档。
Q6：多个子Agent并发运行时API消耗急剧增长，怎么控制成本？
四个最有效的办法：第一，不要一上来开太多并发，先从2-3个试起。第二，让子任务尽量短、上下文尽量清晰，避免反复试错。第三，子任务使用更便宜的模型并控制最大轮次。第四，如果配置了Credential Pools，利用多API Key自动轮转来缓解429限流。
Q7：子Agent为什么总是说不知道任务背景？
因为子Agent不是从主会话"复制脑子"过去的，而是从新上下文开始。你必须在context字段中把文件路径、报错信息、项目结构、依赖版本等都明确写出来
十三、我的hermes配置
看过我之前文章的朋友，应该知道我目前一直在使用hermes，多分身使用，不是子agent，每个是独立进程、独立记忆、独立Telegram Bot。
Sub-Agent = 你让主Agent"去派生几个小弟并行干活"，干完汇总，结果返回后小弟消失
分身 = 多个独立的人（各有姓名、性格、技能），长期驻守在各自Telegram Bot，随时待命
每个五个分身的特点和分工
小乔 — 投研+AI分析师
- 擅长加密货币基本面、DeFi、Layer1/Layer2研究
- AI/ML技术趋势分析
- 数据驱动，喜欢表格
阿娇 — 汇报材料专家
- 日报/周报/月报撰写
- 会议纪要整理
- 商业文案写作
文君 — 市场人性研究员
- 新产品开发趋势研究
- 竞品分析
- 用户需求挖掘
阿强 — 人生规划师
- 职业发展规划
- 目标拆解和OKR
- 决策利弊分析
testhongyi — AI量化交易分身
- BTC-RSI Regime组合策略
- OKX Demo现货交易
- 交易信号监控和执行
## 总结：Hermes进阶的核心逻辑
用了一段时间后我才真正理解——Hermes的记忆系统不是"记不住"，而是"不值得记的不记"。这套"策展机制"的本质是性能与质量的平衡：省Token、防污染、保持高密度。
所以，下次遇到它"失忆"时，先问自己：这件事，我有没有明确告诉它"这条值得长期保留"？
如果本文对你有帮助，欢迎转发给正在用Hermes的朋友。
## 相关链接
- [弘毅新征程](https://x.com/hongyi88)
- [@hongyi88](https://x.com/hongyi88)
- [2.8K](https://x.com/hongyi88/status/2047230488163864664/analytics)
- [https://app.mem0.ai/](https://app.mem0.ai/)
- [$HERMES](https://x.com/search?q=%24HERMES&src=cashtag_click)
- [@modelcontextprotocol/server-filesystem](https://x.com/@modelcontextprotocol/server-filesystem)
- [@modelcontextprotocol/server-filesystem](https://x.com/@modelcontextprotocol/server-filesystem)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [4:25 PM · Apr 23, 2026](https://x.com/hongyi88/status/2047230488163864664)
- [2,807 Views](https://x.com/hongyi88/status/2047230488163864664/analytics)
- [View quotes](https://x.com/hongyi88/status/2047230488163864664/quotes)
---
*导出时间: 2026/4/23 23:44:35*