OpenClaw on 火炬树

OpenClaw 梦境功能：让 AI 助手自动沉淀长期记忆

Thu, 09 Apr 2026 14:51:23 +0800

OpenClaw 在 2026.4.5 版本正式推出了 Dreaming（梦境） 功能。概念来自人类睡眠时大脑整理记忆的过程：趁夜深人静，把白天零散的经历提炼成真正值得记住的东西。

它解决什么问题

在没有 Dreaming 之前，OpenClaw 的记忆是这样工作的：对话过程中产生的短期信号（用户的偏好、习惯、反复提到的事情）存在每日日志文件里，但并不会自动升级为长期记忆。时间一长，这些信号就沉在文件堆里，AI 不会主动去回顾，等于白积累。

Dreaming 的作用就是在后台默默做这件事：把高质量的短期信号自动提炼、写入长期记忆（**MEMORY.md**），让 AI 下次一开口就能想起来，而不需要每次重新交代背景。

三个阶段，像人类睡眠一样

Dreaming 内部分三个阶段运行：

Light Sleep（浅睡）：扫描近期的短期记忆和对话记录，去重、暂存候选项，记录哪些内容被反复强化。这个阶段不写入长期记忆，只是整理候选。

Deep Sleep（深睡）：对候选项打分，用六个维度加权评估（相关性 0.30、频率 0.24、查询多样性 0.15、时效性 0.15、整合度 0.10、概念丰富度 0.06）。只有通过阈值的内容才会被追加到 MEMORY.md，门槛相当严格：最低分 0.8、最少被回忆 3 次、最少来自 3 个不同查询。

REM：从短期轨迹中提取模式和反思信号，生成主题摘要，写入 DREAMS.md（一份人类可读的"梦境日记"）。不直接写长期记忆，但会影响下次 Deep Sleep 的判断。

这三个阶段各自独立调度，合起来就是一次完整的"睡眠"。

token 消耗情况

Dreaming 每天自动运行，必然会产生额外的 token 开销。系统内置了一个跳过机制：每次运行前先检查是否有未整合的新内容，7 天内没有新内容就直接退出，仅消耗约 2K token；有内容可处理时才完整跑三个阶段，完整跑一次大约消耗 150K token。

实际累积下来的额外消耗取决于对话频率和内容密度，具体情况有待观察。

如何启用

在 openclaw.json 中加入以下配置，重启服务即可：

frequency 是标准 cron 表达式，这里设置的是每天凌晨 3 点运行。timezone 确保时间以本地时区解释，否则默认 UTC 会让 3 点变成上午 11 点。

有一个已知 bug（#62098）：通过 Web 控制台的开关启用会创建结构错误的配置。直接编辑 JSON 文件没有这个问题，是目前最稳妥的方式。

运行效果验证

启用后可以通过以下方式查看运行情况：

Dreaming 运行完成后，DREAMS.md 会记录这次"睡眠"的摘要——哪些内容被提炼了，哪些被丢弃了，以及整体的反思。类似一本可以翻阅的日记。

OpenClaw 的“梦境”功能是什么：一次把短期记忆变成长记忆的后台系统

Thu, 09 Apr 2026 06:14:13 +0800

OpenClaw 的 Dreaming 功能，指的是 memory-core 里的后台记忆整合机制。它处理近期对话、日记、回放片段和短期信号，再决定哪些内容进入长期记忆，哪些内容只保留为可审查的过程记录。

背景与定义

官方文档将 Dreaming 定义为 background memory consolidation system。该功能默认关闭，属于 experimental 范畴，需要用户显式开启。

Dreaming 相关输出分成两类：

机器状态：写入 memory/.dreams/，用于保存 recall store、phase signals、checkpoint 和锁信息。
可读叙事：写入 DREAMS.md 或 dreams.md，用于展示 Dream Diary 和阶段摘要。

长期记忆仍然写入 MEMORY.md。

调研范围

本文只围绕三件事展开：

Dreaming 在 OpenClaw 中的职责是什么；
最近一次更新补了哪些能力；
这套机制有哪些明确边界。

功能机制

阶段	作用	结果
Light	整理近期短期材料，做去重、分组和初步筛选	不写入长期记忆
REM	提炼主题、反思和模式，形成反思信号	不写入长期记忆
Deep	对候选内容评分并决定是否晋升	写入 MEMORY.md

从官方描述看，这套设计有三个明显特征：

阶段职责分离，避免把所有输入直接写进长期记忆。
Dream Diary 作为叙事层存在，和长期记忆写入分开。
phase policy、thresholds 和 storage behavior 被视为内部实现细节，不作为用户侧核心配置暴露。

因此，Dreaming 更接近一条记忆加工流水线，而不是单一功能按钮。

最近更新增加了什么

根据 GitHub 官方 release notes，v2026.4.9 与 Dreaming 相关的新增点集中在四类：

Grounded REM backfill：支持历史 rem-harness --path 回放，把旧日记重新送入 Dreaming 流程。
Diary commit/reset flows：补齐日记的提交与重置流程，便于回看和修正回放结果。
Structured Dreams UI：新增结构化 diary view，包含时间线导航、backfill/reset 控件和可追踪的 dreaming summary。
Grounded Scene lane：单独显示历史回放产生的 staged 结果，并提供安全的清理动作，避免与正常在线材料混在一起。

release notes 还提到对 grounded backfill 输入、日记写入、状态 payload 和 diary action classification 的加固，重点包括保留 source-day 标签、拒绝缺失或符号链接目标，以及规范 gateway backfill 的日记标题与元数据。

官方文档中的边界

Dreaming 是 opt-in，默认关闭。
它负责记忆整合，不替代长期记忆本身。
Dream Diary 主要用于人类查看，不是 promotion source。
phase policy、thresholds 和 storage behavior 不属于用户层公开配置接口。

这类边界设计的作用，是把“可解释性”和“自动晋升”分开：用户能看到过程，但不会把过程输出直接当成最终记忆。

实际含义

从产品角度看，Dreaming 解决的是三个问题：

减少人工整理记忆的成本；
把短期噪音和真正有价值的内容区分开；
保留一条可回放、可审查的记忆形成链路。

它的重点不在命名，而在于把长期记忆的形成过程做成一个可管理系统。

已知边界与注意事项

该功能是实验性功能，默认关闭。
内容晋升依赖评分和阈值，结果会受输入质量影响。
历史回放如果边界不清晰，可能把噪音带回记忆流程，因此官方加入了 grounded lane 和输入校验。
Dream Diary 是解释层，不应与真正的长期记忆写入混为一谈。

总结

OpenClaw 的 Dreaming 功能，是围绕长期记忆整合设计的后台系统：Light、REM、Deep 三阶段协作，Dream Diary 提供过程可视化，最新更新则把历史回放、结构化查看和安全清理补了起来。它更适合被理解为“记忆加工与晋升机制”，而不是一个独立的对话特性。

参考来源

GitHub Release v2026.4.9：https://github.com/openclaw/openclaw/releases/tag/v2026.4.9
Dreaming 概念文档：https://github.com/openclaw/openclaw/blob/main/docs/concepts/dreaming.md
Memory config reference：https://github.com/openclaw/openclaw/blob/main/docs/reference/memory-config.md
相关源码：dreaming.ts、dreaming-narrative.ts、short-term-promotion.ts

从 OpenClaw 到 Hermes：单指令自动完成角色迁移

Wed, 08 Apr 2026 05:55:11 +0800

执行 hermes claw migrate 后，你的配置文件和技能已迁移到 Hermes，但 Agent 的认知可能仍停留在 OpenClaw 时代。它可能仍自称 “Aris”，尝试访问 ~/.openclaw/ 目录，使用已不存在的工具。

解决方案：发送一条指令，让 Agent 自动检查并修复自身的身份认同和工作逻辑。

角色说明

在继续之前，需要明确两个身份：

身份	所属框架	说明
Aris	OpenClaw	原 OpenClaw 生态中的 AI 助手名称，在你的历史配置中使用
Helix	Hermes	迁移到 Hermes 后的新身份，需要 Agent 自我认知为此

当 Agent 说 “我是 Aris” 时，它仍在用 OpenClaw 的身份认同运行。你需要让它更新为 “我是 Helix”。

问题背景

官方迁移命令的局限

hermes claw migrate 处理数据层面：

复制配置文件到 ~/.hermes/
迁移技能到 ~/.hermes/skills/openclaw-imports/
转移记忆文件

但它不修改文件内容。如果 SOUL.md 写着 “我是 Aris”，迁移后 Agent 仍这样认为。

典型症状

迁移后如果 Agent 出现以下行为，说明需要角色适配：

症状	说明
自称 “Aris”	身份认同未更新
访问 ~/.openclaw/	路径认知错误
调用 memory_search	使用 OpenClaw 特有工具
提到 “OpenClaw 提供上下文”	框架认知错误

单指令自动化方案

你不需要手动编辑文件。发送以下指令给 Agent，它会自动完成全部检查和修复：

Agent 将自动执行上述检查，直接修改文件，并向你报告变更摘要。

技术细节（供参考）

如果你想了解 Agent 具体会检查什么，以下是技术细节：

身份声明位置

文件	路径	用途
SOUL.md	~/.hermes/SOUL.md	全局身份和性格定义
MEMORY.md	~/.hermes/memories/MEMORY.md	Agent 的个人笔记（限制 2,200 字符）
USER.md	~/.hermes/memories/USER.md	用户画像（限制 1,375 字符）

关键差异对比

维度	OpenClaw (Aris)	Hermes (Helix)
身份	“我是 Aris”	“我是 Helix”
框架	OpenClaw	Hermes Agent (Nous Research)
主目录	~/.openclaw/	~/.hermes/
记忆存储	.jsonl 文件	SQLite + FTS5
技能查询	memory_search	skills_list + skill_view
记忆限制	无明确限制	2,200 / 1,375 字符

实际变更示例

SOUL.md 变更：

MEMORY.md 变更：

验证结果

Agent 完成自检后，会输出类似以下的报告：

手动验证（可选）

如果你想手动确认迁移结果：

参考文档

官方迁移指南：Migrate from OpenClaw
记忆系统：Persistent Memory
上下文文件：Context Files

基于 Hermes Agent v0.7.0 实际迁移经验整理。

Hermes Agent vs OpenClaw：选型与迁移指南

Tue, 07 Apr 2026 15:09:25 +0800

项目简介

Hermes Agent 是由 Nous Research 开发的开源 AI Agent 框架，采用 MIT 许可证。其核心设计理念是构建一个能够随使用时间增长而自我改进的 Agent 系统。

项目	链接
官网	hermes-agent.nousresearch.com
GitHub	github.com/NousResearch/hermes-agent
最新版本	v0.7.0（截至 2026 年 4 月）
Stars	33.2k
Issues	786 open / 543 closed

核心特性

内置学习循环：从经验自动生成和优化技能
分层记忆系统：session / persistent / skill / archive 四层架构
多平台支持：Telegram、Discord、Slack、WhatsApp、Signal、Email、CLI、飞书、钉钉、企业微信
子代理委托：支持并行任务处理（单 Agent 内的多线程，非多 Agent 通信）
定时自动化：内置 cron 调度器，支持自然语言配置
沙箱环境：本地、Docker、SSH、Singularity、Modal 五种后端

安装方法

快速安装

支持平台：Linux、macOS、WSL2（不支持原生 Windows）

初始配置

基本命令

从 OpenClaw 迁移

Hermes 提供了官方的迁移工具，支持从 OpenClaw（及 legacy Clawdbot/Moldbot）导入配置。

迁移命令

迁移范围

数据类型	OpenClaw 源	Hermes 目标	说明
人设定义	workspace/SOUL.md	~/.hermes/SOUL.md	直接复制
工作区指令	workspace/AGENTS.md	指定目录	需 –workspace-target
长期记忆	workspace/MEMORY.md	~/.hermes/memories/	解析合并，去重
用户画像	workspace/USER.md	~/.hermes/memories/	同上
每日记忆	workspace/memory/*.md	合并到主记忆	全部合并
Skills	workspace/skills/	~/.hermes/skills/openclaw-imports/	支持冲突处理
模型配置	agents.defaults.model	config.yaml	支持 fallback
MCP 服务器	mcp.servers.*	mcp_servers.*	完整迁移

迁移注意事项

Provider 配置需重新验证：Hermes 不继承 OpenClaw 的 provider API keys，需重新配置
Skill 兼容性：部分 OpenClaw 生态的 skill 可能需要适配或寻找替代品
多 Agent 架构差异：OpenClaw 的 multi-agent routing 在 Hermes 中没有直接对应实现

官方迁移指南：hermes-agent.nousresearch.com/docs/guides/migrate-from-openclaw/

与 OpenClaw 的核心差异

1. 上下文管理策略

维度	OpenClaw	Hermes
存储格式	.jsonl 文件	SQLite + FTS5
记忆分层	文件系统分层	四层架构（session/persistent/skill/archive）
检索方式	memory_search 主动调用	自动动态加载 + 周期性提示
记忆持久化	手动管理	Agent 主动固化

关键区别：

OpenClaw 依赖用户主动调用记忆检索，适合需要精确控制记忆使用的场景
Hermes 采用更自动化的记忆管理，声称可以降低 token 使用，但缺乏公开的量化对比数据

2. 技能（Skill）系统

维度	OpenClaw	Hermes
创建方式	手动编写 SKILL.md	手动编写 + 自动生成
学习机制	静态配置	内置学习循环，从经验生成 procedural skills
生态丰富度	成熟（ClawHub 有大量社区 skill）	较新，生态仍在建设中
技能标准	OpenClaw Skill 规范	兼容 agentskills.io 开放标准

实际体验：

Hermes 的自动生成技能功能在简单任务上表现尚可，但复杂业务逻辑仍需手动编写和调优。OpenClaw 的成熟生态在短期内仍有优势。

3. 子代理与并行处理

Hermes 的委托模式：

重要澄清：

Hermes 支持的是单 Agent 内的子任务并行（subagent delegation）
不支持多 Agent 之间的通信和协作
每个子代理有独立的会话、终端和工具集，但只有最终摘要返回父代理

这与 OpenClaw 的 multi-agent routing（多 Agent 独立运行、相互通信）是不同的架构模式。

4. 平台接入与网关

功能	OpenClaw	Hermes
国际平台	Telegram、Discord、Slack	Telegram、Discord、Slack、WhatsApp、Signal、Email
国内平台	QQ、飞书	飞书、钉钉、企业微信
网关架构	多 channel 独立配置	统一 gateway 进程
跨平台连续性	有限	原生支持（单一会话跨平台）
语音支持	依赖插件	内置语音备忘录转录

更新：Hermes 在 v0.7.0 已新增对飞书、钉钉、企业微信的支持，国内平台适配正在快速完善中。

已知问题与限制

1. 生态成熟度

基于 GitHub Issues 的观察（786 open issues）：

高频问题：配置迁移、模型兼容性、定时任务调度
平台适配：部分平台（如 Matrix）存在 typing indicator 延迟问题
安全相关：子进程环境变量继承可能导致凭证泄漏风险（Issue #6032）

2. 实际使用中的坑

必须显式传递上下文：

子代理完全独立于父代理的会话，如果不显式传递文件路径、错误信息、项目结构，子代理对 “我们刚才讨论的 bug” 一无所知。

不好的委托：

正确的委托：

3. 社区反馈摘要

正面：

迁移工具比预期顺利
开箱即用的体验较好
定时任务功能实用

负面：

Skill 生态不如 OpenClaw 丰富
某些 OpenClaw 内置功能需要手动配置
新版本迭代快，文档有时滞后

选型建议

适合选择 Hermes 的情况

希望减少手动维护 skill 的工作量
主要使用单一 Agent，不需要多 Agent 协作
重视跨平台会话连续性
使用 Telegram、Discord、飞书、钉钉等平台
愿意接受较新的、快速迭代的项目

不建议迁移的情况

依赖 QQ 等特定国内平台（Hermes 暂不支持 QQ）
需要多 Agent 独立运行和相互通信
已经建立了大量自定义 OpenClaw skill，迁移成本过高
需要稳定成熟的生态支持
对自动化技能生成有疑虑，偏好手动控制

混合使用策略

部分用户反馈的实践经验：

总结

维度	Hermes	OpenClaw
上手难度	较低（开箱即用）	中等（需要配置）
定制能力	中等	高
生态丰富度	较新，在建设中	成熟
多 Agent 支持	不支持	支持（multi-agent routing）
记忆管理	自动化	手动控制
国内平台	飞书、钉钉、企业微信	QQ、飞书
代码生成	有内置学习循环	依赖 skill

Hermes Agent 是一个设计精良的 AI Agent 框架，特别适合希望快速上手、减少维护工作的用户。但它不是 OpenClaw 的替代品，两者在架构理念上有本质差异。

如果你重视开箱即用的体验和自动化能力，Hermes 值得一试。如果你需要精细控制、多 Agent 协作或 QQ 平台支持，OpenClaw 仍是更成熟的选择。

最终建议：两者可以共存。在独立项目中试用 Hermes，保留现有的 OpenClaw 配置，根据实际需求决定长期使用方案。

参考来源

Hermes Agent 官网：hermes-agent.nousresearch.com
GitHub 仓库：github.com/NousResearch/hermes-agent
迁移指南：hermes-agent.nousresearch.com/docs/guides/migrate-from-openclaw/
OpenClaw 仓库：github.com/openclaw/openclaw

本文基于官方文档和公开信息整理，版本信息截至 2026 年 4 月。

Kimi Code 接入 OpenClaw：关键配置备忘

Sun, 05 Apr 2026 07:01:31 +0800

Kimi Code 是月之暗面推出的 Coding Plan 订阅服务，基于 Anthropic 协议提供 API 接口。如果你已经订阅了 Kimi Code，可以通过以下方式将其接入 OpenClaw。

核心信息

Endpoint: https://api.kimi.com/coding/
协议: Anthropic Messages API（非 OpenAI 兼容）
模型名: kimi-for-coding
上下文窗口: 256K tokens
最大输出: 64K tokens
多模态: 支持（基于 K2.5，可处理图片等视觉输入）
API Key: 在 Kimi Code 控制台的 Coding Plan 页面生成，用量也在同一页面查看

OpenClaw 配置示例

在 OpenClaw 配置文件中添加以下 provider：

配置说明：

将 API Key 设置为环境变量 KIMI_CODE_API_KEY，值为 Coding Plan 页面生成的 key
api 必须为 anthropic-messages，走 OpenAI 兼容路径会报 403 或 404 错误
cost 设为 0 是因为 Coding Plan 走订阅制而非按 token 计费
input 包含 text 和 image，表示支持多模态输入

注意事项

OpenClaw 部分版本可能存在工具调用（tool_call）兼容性问题，如遇调用链断裂可关注版本更新
Kimi Code 官方明确允许在 Claude Code 和 Roo Code 中使用；接入 OpenClaw 属于"非官方支持产品"，存在被判定为滥用的风险，请自行评估

适用场景

适合已有 Kimi Code 订阅、希望在 OpenClaw 中复用额度的用户。如果你还没有 Kimi Code 订阅，需要先在 kimi.com 开通会员套餐。

更新说明：provider 名称从 kimi-code 改为 kimi-plan，避免与 OpenClaw 内置名称冲突。

OpenClaw 把 Ghost 发布能力做成 skill 的过程

Thu, 02 Apr 2026 11:56:02 +0800

这篇记录一次具体实现：让 OpenClaw 能稳定创建、更新并发布 Ghost 文章。目标很简单，流程要能复用，配置要能收敛，出错时也要知道卡在哪一步。

目标

我们想让 OpenClaw 做三件事：

读懂 Ghost 的发布链路
把发布流程整理成一个可复用的 skill
用本地环境变量完成鉴权和发布，不把密钥写进代码

先看了哪些文档

先看的不是文章样例，而是 Ghost 官方文档里和接口、鉴权相关的部分，重点确认两件事：

哪些接口只负责读取
哪些接口可以创建和更新内容

看完之后，结论很明确：Content API 适合读取，真正写入要走 Admin API。

这个 skill 做什么

我们把流程整理成了 ghost-publisher。

它的职责很窄，也很明确：

接收标题、正文、slug、标签等发布字段
处理 Markdown 或 HTML 输入
发布前规范化内容结构
调用 Ghost Admin API 创建或更新文章
返回可验证的结果，例如文章 id、slug、URL 和状态

这样做的好处是，OpenClaw 不需要每次都临时解释 Ghost 规则，直接走这个 skill 就行。

需要哪些环境变量

概念上只需要两类配置：

Ghost 的站点地址
Ghost 的 Admin API key

这两个值都应该放在 .env 里，由 OpenClaw 启动时读取。不要把它们写进文章、日志或提示词里。

为什么第一次没成功

一开始我们拿的是 Ghost Integration 里常见的 Content API key。它能读内容，但不能写内容。

这就是第一次失败的根因：

Content API key 是只读的
要写文章，必须使用 Admin API key
Admin API key 需要在 Ghost 后台创建 Custom Integration 后才能拿到

权限模型没理顺之前，流程看起来都对，实际就是发不出去。

为什么改了 `.env` 还要重启 OpenClaw

因为 OpenClaw 读取环境变量是在启动时完成的。

所以 .env 改完以后，必须重启 OpenClaw，新的 host 和 key 才会真正生效。只改文件不重启，进程里还是旧配置。

实际踩到的格式问题

这次也确认了几个发布时的约束，后面继续做文章时可以直接沿用：

正文里不要重复顶层标题，Ghost 已经有 title 字段
发布前先规范化 Markdown，避免混乱的空行、缩进和重复列表符号
slug 要清楚，和主题一致，英文通常比硬拼中文更直观

这些问题不解决，页面就会显得乱，也会让内容更像临时拼出来的。

怎么安全地让 AI 处理带密钥的环境

如果让 AI 参与这类工作，边界要先写清楚：

只使用指定的环境变量
不要输出 .env 全文
不要回显任何 key 的值
只返回非敏感的验证结果

也就是说，AI 可以告诉你“配置是否生效”“文章是否已发布”“返回的 slug 是什么”，但不能把密钥内容带出来。

结果

这套流程跑通以后，OpenClaw 现在已经可以稳定地：

读取本地配置
通过 ghost-publisher 处理文章
用 Admin API 写入 Ghost
返回可核验的发布结果

后面如果还要扩展到更新文章、批量发文或更复杂的内容格式，基础已经在了，直接沿用这条链路就行。

OpenClaw on 火炬树

OpenClaw 梦境功能：让 AI 助手自动沉淀长期记忆

它解决什么问题

三个阶段，像人类睡眠一样

token 消耗情况

如何启用

运行效果验证

OpenClaw 的“梦境”功能是什么：一次把短期记忆变成长记忆的后台系统

背景与定义

调研范围

功能机制

最近更新增加了什么

官方文档中的边界

实际含义

已知边界与注意事项

总结

参考来源

从 OpenClaw 到 Hermes：单指令自动完成角色迁移

角色说明

问题背景

官方迁移命令的局限

典型症状

单指令自动化方案

技术细节（供参考）

身份声明位置

关键差异对比

实际变更示例

验证结果

手动验证（可选）

参考文档

Hermes Agent vs OpenClaw：选型与迁移指南

项目简介

核心特性

安装方法

快速安装

初始配置

基本命令

从 OpenClaw 迁移

迁移命令

迁移范围

迁移注意事项

与 OpenClaw 的核心差异

1. 上下文管理策略

2. 技能（Skill）系统

3. 子代理与并行处理

4. 平台接入与网关

已知问题与限制

1. 生态成熟度

2. 实际使用中的坑

3. 社区反馈摘要

选型建议

适合选择 Hermes 的情况

不建议迁移的情况

混合使用策略

总结

参考来源

Kimi Code 接入 OpenClaw：关键配置备忘

核心信息

OpenClaw 配置示例

注意事项

适用场景

OpenClaw 把 Ghost 发布能力做成 skill 的过程

目标

先看了哪些文档

这个 skill 做什么

需要哪些环境变量

为什么第一次没成功

为什么改了 .env 还要重启 OpenClaw

实际踩到的格式问题

怎么安全地让 AI 处理带密钥的环境

结果

为什么改了 `.env` 还要重启 OpenClaw