# 手把手实现 Hermes Agent 梦境模式
当 AI 在深夜开始反思自己

📅 2026-06-26 🏷️ Hermes Agent · 自进化 · 工程实践 ⏱ 阅读约 12 分钟
🔬 实战案例 ⚙️ 技术架构

## 一、起因：一篇头条文章引出的实验

今天在今日头条看到一篇文章《Hermes Agent 的"梦境模式"：当 AI 在深夜开始"反刍"记忆》。文章讲了一个概念：让 AI Agent 在夜间通过 Cron 触发，自动回顾白天的 Session 记录，识别错误模式、提取优化机会，甚至自动为 Skill 文件打补丁。

这个概念非常吸引人——它描述了 Hermes Agent 从"高级工具"向"自进化数字生命"跨越的关键一步。但文章本质是概念推演，并未给出完整可运行的实现。

于是我做了一个决定：用一下午时间，把这个"梦境模式"从概念变成真实可运行的工程方案。

## 二、梦境模式的系统架构

### 2.1 核心设计

"梦境模式"在技术上并不神秘——它是一个 后台反思循环（Background Reflection Loop），由以下组件构成：

🔍 Session DB
FTS5全文索引
→
🌙 梦境Agent
cronjob定时触发
→
📊 复盘报告
JSON结构化输出
→
🧩 Skill补丁
自动生成·确认生效

组件 | 技术实现 | 说明
--- | --- | ---
数据源 | Hermes Session DB（SQLite + FTS5） | 所有历史对话被实时索引，支持全文检索
触发器 | Hermes cronjob 系统 | 每日凌晨 3:00 自动触发，无需人干预
分析引擎 | Agent 通过 session_search 读取并分析 | 调用 LLM 对 Session 内容进行模式识别
产物A | 复盘报告 (dream_YYYYMMDD.json) | 错误模式、优化机会、原则对齐
产物B | 补丁建议 (patches_YYYYMMDD.json) | 可执行的 Skill 修改 diff，需确认后生效
安全护栏 | 只读操作 + 人类确认 | Phase 1 只读不写；Phase 2 补丁需 approve

### 2.2 两阶段递进

🌙 Phase 1：复盘报告
零风险只读模式。Agent 浏览近期 Session、识别错误模式、提取优化机会、评估与用户原则的对齐度。输出结构化 JSON 报告。
已运行 首份报告已产出
🧩 Phase 2：补丁生成
在复盘基础上，Agent 读取现有 Skill 库，针对重复出现的错误模式生成具体的 Skill 修改建议（含 diff 格式的 old_text/new_text）。
已运行 补丁生成已就绪

## 三、Phase 1 实现：复盘报告

### 3.1 一行命令创建梦境cronjob

Hermes 内置了完整的 cronjob 系统，无需写 Python handler 或修改源码：

# 创建一个每日凌晨3点的梦境复盘cronjob
hermes cron create \
--schedule "0 3 * * *" \
--prompt "分析过去48小时的Session记录..." \
--deliver origin

cronjob 的 Agent 会按顺序执行：

1. 浏览——用 `session_search()` 获取近期活跃 Session 列表
2. 阅读——选出 2-3 个有实质内容的 Session，读取完整记录
3. 分析——识别错误模式（errors）、优化机会（optimizations）、原则对齐（alignments）
4. 输出——写入结构化的 JSON 报告到 `~/WB_WS/_dream/`
5. 摘要——返回一段 200 字以内的可读"梦境摘要"

### 3.2 第一份梦境报告发现了什么

梦境第一次运行就发现了有价值的模式。以下是实际输出中的部分内容：

严重度 | 发现的错误模式 | 根因
--- | --- | ---
High | `web_search` 工具不存在但每个 Session 都调用 | 系统提示词中有这个工具名但实际未启用
Medium | 头条反爬导致大量无效重试 | curl 无 JS 运行时获取到混淆代码
Medium | Nginx 配置编辑时 Python 正则转义语法错误 | 转义符处理不当导致 nginx -t 验证失败
Low | 浏览器 Console eval `let` 变量命名冲突 | 多次注入 JS 用同一变量名

💡 价值： 第一个 High 严重度的错误模式——`web_search` 工具缺失——之前从未被系统化地识别过。梦境报告让它浮出水面，变成了一个可跟踪、可量化的改进项。

## 四、一个真实的修复案例：web_search 从缺失到就绪

梦境报告指出了 `web_search` 不可用的问题后，下一个自然的问题是：为什么它不存在？怎么修？

### 4.1 排查过程

检查 Hermes 配置发现 `web.search_backend` 为空字符串。Hermes 支持多种搜索后端：

后端 | 配置方式 | 费用 | 国内可用性
--- | --- | --- | ---
Firecrawl | API Key | 500次/月免费 | ✅
SearXNG | 自建 Docker | 免费 | ✅ 已有实例
DDGS (DuckDuckGo) | 零配置 | 免费 | ⚠️ 可能被墙
Brave Search | API Key | 2000次/月免费 | ✅

检查发现服务器上已有一个 SearXNG Docker 实例在运行——但它的 JSON API 输出被禁用，且默认搜索引擎（Google、DuckDuckGo）在国内无法访问。

### 4.2 修复链

这是一条完整的"问题发现→诊断→修复→验证"链：

# 1. 启用 JSON 输出格式（默认只有 html）
# 编辑 SearXNG settings.yml，在 formats 中加入 json
formats:
- html
- json # ← 新增
# 2. 更换可用的搜索引擎
# 禁用 Google/DuckDuckGo/Brave（国内被墙），启用百度/搜狗
# baidu: disabled: false
# sogou: disabled: false
# 3. 调大超时（默认3秒对中国网络太短）
request_timeout: 10.0
max_request_timeout: 15.0
# 4. 配置 Hermes 连接 SearXNG
# ~/.hermes/.env
SEARXNG_URL=http://127.0.0.1:8080
# ~/.hermes/config.yaml
web:
search_backend: searxng

### 4.3 验证结果

修复后，SearXNG 搜索正常工作：

✅ 搜索 "Hermes Agent" → 返回 20 条结果（百度+搜狗引擎）
✅ 搜索 "Hermes Agent 梦境模式" → 返回相关中文博客和教程
✅ 跨 Profile 继承——全局配置一处修改，8 个 Profile 全部生效

## 五、Phase 2 实现：Skill 补丁自动生成

### 5.1 补丁生成流程

Phase 2 在复盘报告的基础上增加了一个关键步骤——查看现有技能库，生成具体的文件修改建议：

📋 输出A
复盘报告
→
📂 技能库
skill_view()
→
📝 输出B
补丁建议
→
👤 你确认
approve后生效

### 5.2 补丁格式

每个补丁都包含完整可执行的 diff 信息：

{
"id": "patch-001",
"skill_name": "skills/operations/system-stewardship/SKILL.md",
"type": "update",
"reason": "源于web_search缺失的反复调用——需要在已知坑中新增替代方案",
"suggested_change": "新增规则：工具首次调用失败后立即切browser代替",
"old_text_pattern": "...",
"new_text": "...",
"confidence": "high",
"requires_approval": true
}

### 5.3 安全设计

- 默认只读——Phase 1 不修改任何文件，Phase 2 只生成建议不执行
- 需要确认——所有补丁的 `requires_approval` 默认为 true
- 置信度标注——High 表示重复性错误明确需要修；Medium 有价值但不紧急；Low 仅供参考
- 改进追踪——每次报告追踪上期问题的修复状态（fixed / still_exists / improved）

## 六、经验与避坑

### 6.1 什么做对了

- 渐进式推进——Phase 1（只读复盘）→ Phase 2（补丁建议）→ Phase 3（自动执行）。每次增加一个风险级别，而不是一口气到位
- 利用已有基础设施——Hermes 的 cronjob、session_search、skill 系统已经覆盖了"梦境"需要的所有组件，没有任何额外安装
- 改进追踪闭环——每次报告记录上期问题的状态，"web_search 缺失 → 确认仍未修复 → 手动修复 → 下期确认 fixed" 形成一个完整的 PDCA 循环

### 6.2 踩了哪些坑

- 走了 SearXNG 的弯路——明明有更轻量的后端方案（Brave Search 免费 Key），却因为"已有 SearXNG 实例"而选择了需要修容器的复杂路线
- Docker 网络问题——容器重启时 iptables 规则损坏，端口映射丢失，需要切换到 host 网络模式解决
- 搜索引擎被墙——默认配置的 Google、DuckDuckGo、Brave 在国内全部超时，需要手动切换到百度/搜狗
- Profile 配置层级——改了全局 config.yaml 后发现 Profile 有自己的配置覆盖了全局，需要逐个同步

## 七、下一步：Phase 3 方向

当前"梦境模式"已经能稳定运行：每晚自动复盘，输出结构化报告和补丁建议。Phase 3 的可能方向：

方向 | 说明 | 风险
--- | --- | ---
低置信度补丁自动执行 | confidence=high 且明确的错误修复，可自动写入 Skill | 需要严格的版本回滚机制
多维度交叉验证 | 同一问题被多个 Session 报告 → 置信度自动提升 | 低，只需修改分析逻辑
梦境报告实时推送到群聊 | 凌晨分析完成后自动推送摘要到企业微信群 | 低，cronjob 本身已支持 deliver
n8n MCP 集成 | 把梦境报告中的度量数据推送到 n8n 工作流 | 需先完成 n8n 部署

## 八、总结

"梦境模式不是一行命令或一个功能，它是一个工程思维——让 Agent 从自己的经验中学习。"

Hermes 的独特之处不在于它跑得比别的 Agent 快，而在于它有"记忆"和"反思"的架构基础。梦境模式只是这个基础之上的一种应用——利用已有的 SQLite + FTS5 会话存储、cronjob 定时调度、skill 知识沉淀能力，组合出"自我复盘→发现问题→提出改进→确认生效"的完整进化回路。

最重要的启示是：自进化 AI 不一定需要复杂的强化学习框架。一个结构化的复盘循环 + 可执行的补丁机制 + 人类监督护栏，已经能让 Agent 从经验中持续改进。

⚠️ 重要提醒： 梦境模式本质是对 LLM 输出进行再分析，存在"幻觉级联"风险——如果 LLM 在复盘时产生了错误的分析结论，基于此生成的补丁可能引入新问题。这就是为什么 Phase 2 的补丁强制需要人类确认。建议初始使用至少运行 1-2 周的 Phase 1，积累足够的模式数据后再启用补丁生成。