介绍 Hermes Dreaming：Hermes Agent 的可审查自我改进

为什么我要构建 Hermes Dreaming

今晚我发布了 Hermes Dreaming v0.1.0。Hermes 已经具备了真正的自我改进骨架：记忆、技能、用户笔记、事实。这些组件都已就位。Hermes Dreaming 在此基础上增加了一个专注的层次：一个分阶段插件工作流，用于提出变更、将变更作为工件进行审查、验证、有意识地应用或干净地丢弃。

这不是对 Hermes 自我改进的替代。这是它的收据层。因为代理自我改进的真正问题不是智能，而是信任。

任何人都可以说一个代理在改进。Hermes 的构建理念就是长期运行的代理需要记忆、技能、事实和不断演进的上下文。下一个问题是在这些演进落地之前使其更易于审查。难点在于让变更在落地之前变得清晰可读。什么变了？提案来自哪里？它会影响哪个文件？我能检查它吗？我能验证它吗？我能先备份现有状态吗？如果感觉不对，我能整个丢弃吗？

Hermes Dreaming 的存在就是为了在操作员友好的插件工作流中让这些答案变成“是”。

分阶段变更优于静默突变

“自我改进代理”这个说法在代理拥有真实状态后会变得更加严肃。Hermes 就是如此。它有记忆、技能、用户笔记和事实面，这些都能塑造未来的工作。这很强大。

Hermes Dreaming 增加了一条处理这种能力的路径——分阶段路径。对于操作员来说，下一级不仅仅是更多的自主权，而是可审查的自主权。我希望提出的改进能以工件形式到达，带有出处、验证、备份，以及在任何内容触及真实状态之前干净地说“不”的方式。

Hermes Dreaming 将自我改进变成了一个收据追踪链。它扫描显式来源。它暂存提议的变更。它编写工件包。它让你可以对结果进行 diff、验证、应用或丢弃。在“代理注意到了有用的东西”和“操作员批准了变更”之间没有神秘的步骤。这就是这个插件的工作。

本次发布有意保持简单

Hermes Dreaming 是一个独立的、开源的分阶段自我改进引擎，同时也作为 Hermes 插件分发。仓库现在位于：

https://github.com/asimons81/hermes-dreaming

包名为：hermes-dreaming

当前版本：v0.1.0

核心命令界面有意保持枯燥：

dreaming create --live-root ./live --artifact-root ./artifacts --source ./sources
dreaming diff ./artifacts/
dreaming validate ./artifacts/ --live-root ./live
dreaming apply ./artifacts/ --live-root ./live --backup-root ./backups --approve all
dreaming discard ./artifacts/ --archive-root ./archive
dreaming status --artifact-root ./artifacts

这种枯燥的形状正是关键点。

• create 扫描你显式提供的来源并暂存一个梦工件。
• diff 显示报告和暂存的提案。
• validate 在工件被允许触及真实状态之前进行检查。
• apply 写入已批准的提案并首先备份现有文件。
• discard 将工件归档而不改变实时工作区。
• status 显示工件根目录下暂存的工件。

重要的细节是 --source 是显式且可重复的。你将原材料指向 Dreaming。它不会直接吸入你的仓库并开始做生活选择。这很重要。带有审查路径的自主权是构建持久系统而不是意外混乱的方式。

工件就是产物

Hermes Dreaming 最重要的部分不是命令名称，而是工件。每次运行都会产生一个暂存目录，包含：

• manifest.json
• REPORT.md
• sources.jsonl
• proposals.jsonl

这个包就是收据。

• manifest.json 告诉你正在查看的是哪次运行。
• REPORT.md 提供人类可读的摘要。
• sources.jsonl 记录扫描了什么。
• proposals.jsonl 包含提议的变更。

这就是“代理学到了”与“这是提议的变更，这是它的来源，这是它想要影响的内容，这是你说不的机会”之间的区别。这是我在乎的部分。不是魔法，而是控制。

离线优先并非降级

默认的提供者路径有意保持清晰。离线标记工作流会查找源包中的显式 DREAM: 行。这意味着你可以在不需要云模型、API 密钥或不透明的推理层的情况下测试核心循环。

示例源标记如下：

DREAM: memory: Keep updates short and concrete.
DREAM: user: Prefer concise status updates.
DREAM: fact: {"type": "preference", "key": "tone", "value": "casual"}
DREAM: skill: path=skills/review.md | Preserve review gates and backups.

这并不会降低它的实用性。它反而使其可检查。一旦工作流清晰可读，你可以在以后替换为更强大的提供者。该版本已经包含了一个可选的 OpenAI 兼容提供者路径，但核心思想并不依赖于将模型神秘化。模型可以提出建议，但工作流仍然掌控一切。

它也作为 Hermes 插件分发

Hermes Dreaming 是独立的，但为 Hermes 操作员构建。仓库包含一个 Hermes 插件路径：

hermes plugins install asimons81/hermes-dreaming --enable

安装后：

hermes dreaming --help

还有一个捆绑的 Hermes 技能用于分阶段审查工作流：hermes-dreaming:dreaming

这一点很重要，因为 CLI 不仅仅是开发便利工具。CLI 是操作接口。如果一个代理将要触及记忆、技能、用户笔记或事实，操作员应该拥有一个使生命周期清晰可见的命令界面：扫描 -> 暂存 -> diff -> 验证 -> 应用 -> 丢弃

这就是整个论点的核心。

这并非什么

Hermes Dreaming 不是广泛的外部同步。

• 它不是网关管道。
• 它不是一个仪表板。
• 它不是你的代理明天会变成天才的承诺，因为它递归地盯着自己的文件足够久。
• 它不是要变得神秘。

第一个版本是一个以工件为先的 MVP，具有显式的应用和丢弃语义、验证、备份、离线标记解析、一个可选的 OpenAI 兼容提供者、围绕核心模型和 CLI 流程的测试，以及足够的仓库卫生，使其在公开发布审查时安全。

这是 v0.1.0 的正确形状：小表面积、硬边缘、处处收据。

为什么操作员应该关心

大多数代理演示过度关注能力。Hermes 已经比此类别中的大多数工具拥有更多的真实操作员基础。

• 它能写代码吗？
• 它能调用工具吗？
• 它能制定计划吗？
• 它能彻夜运行吗？

好，有用的问题。但长期运行的代理最终会遇到一个更深层的问题：当系统需要自我更新时会发生什么？不是回答问题，不是总结页面，而是改变自身。这才是信任变得真正重要的地方。

当自我改进的代理能够以操作员可检查、可验证、可应用或可丢弃的形式展示其工作成果时，它会变得更加有用。我希望自我改进看起来更像发布工程，而不是神话故事。

• 暂存变更。
• 显示 diff。
• 验证工件。
• 备份实时状态。
• 只应用已批准的内容。
• 干净地丢弃其余部分。

这就是标准。

要点

Hermes Dreaming 之所以有趣，是因为它使 Hermes 式的自我改进更加清晰可读。它不取代现有的自我改进能力。它为操作员提供了一个插件形状的审查工作流。它给你一个暂存的工件，让你在变更落地之前进行检查。这听起来很小，直到你被那些静默改变状态、夸大自身智能、或让回滚感觉像用镊子挖垃圾场的工具所坑过。

Dreaming 不承诺魔法。它承诺一个你可以信任的工作流，因为你实际上可以看到它。

这就是这次发布的全部意义所在。

带有收据的控制性变更，每次都胜过低劣的噱头。