Hermes Agent の記憶システムを深度解析：OpenClaw の誤解をどう修正したか
Hermes Agent の記憶システムは、提示詞の安定化とキャッシュ最適化を目的とした多層構造を採用し、OpenClaw のような従来のアプローチが抱える課題を解決する具体的な実装例を示している。
キーポイント
4 層構成による記憶アーキテクチャ
Hermes は単一の記憶ではなく、提示詞メモリ（MEMORY.md/USER.md）、SQLite 履歴検索、スキル管理、およびユーザーモデリング層の 4 つの独立したシステムを統合している。
プロンプトキャッシュ最適化戦略
安定した情報（環境設定やルール）は提示詞に固定し、変動する情報を外部ツールへ委譲することで、大規模モデルベンダーのキャッシュ機構を最大限に活用している。
厳格な文字数制限と圧縮
メモリファイルには 2,200 文字（MEMORY.md）や 1,375 文字（USER.md）という厳しい制限を設け、トークン効率を最大化し、提示詞の安定性を保つ設計となっている。
OpenClaw の誤りへの修正
従来の AI エージェントが抱えていた「記憶の肥大化によるコスト増」や「キャッシュ未活用」という課題に対し、Hermes は「固定部分は最小化し、検索は外部で行う」という逆転の発想で対応している。
影響分析・編集コメントを表示
影響分析
この記事は、単なる機能紹介にとどまらず、AI エージェント開発における「コスト効率」と「パフォーマンス最適化」の実践的な指針を示しています。特に、プロンプトキャッシュという技術的制約を逆手に取り、アーキテクチャ設計の根幹から最適化を図る Hermes のアプローチは、実運用レベルのエージェント開発において大きな示唆を与えます。
編集コメント
Hermes のような「キャッシュ最適化」を最優先した設計思想は、実運用におけるコスト削減に直結する重要な知見です。
Hermes エージェントの記憶システムを深度解析：OpenClaw の誤りをどのように修正したか
著者：Manthan Gupta**
原文：Hermes Agent の記憶システムを読み、OpenClaw が間違えた点を修正する
もし私が以前に ChatGPT、Claude、そして Clawdbot の記憶システムに関する記事を読んだことがあるなら、私が一貫して追求してきた同じ問題をご存知のことでしょう：これらの AI エージェント（AI Agent）は実際にはどのように記憶しているのか？
Hermes エージェントは私にとって特に興味深い存在です。なぜなら今回は、その行動を観察するだけで「逆エンジニアリング」を行う必要がないからです。Hermes はオープンソースであり、そのコードベースとドキュメントはすべて公開されています。したがって、プロンプト（Prompt）を用いてこのブラックボックスを盲目にテストするのではなく、そのコードパスを直接確認しました——プロンプト状態の構築方法からセッションの永続化、そして記憶のクリーンアップや履歴対話へのクエリに至るまで。
要約すると：Hermes が持っているのは単一の記憶システムではなく、4 つの異なるシステムです。**
- MEMORY.md と USER.md に保存された、高度に凝縮されたプロンプトベースの記憶。
- session_search 関数を通じて呼び出される SQLite の履歴セッションアーカイブ（検索可能）。
- プログラム的記憶（Procedural Memory）のように機能するエージェントスキル管理。
- より深いユーザーモデリング（User Modeling）のためのオプションである Honcho レイヤー。
これらの設計を結びつける中心的な論理は非常にシンプルです：プロンプトを安定させてキャッシュ（Caching）を活用し、それ以外の複雑な情報はすべてツールに任せる。
では、詳しく見ていきましょう。
Hermes のコンテキスト構造
記憶を理解する前に、まず Hermes がモデルに実際に送信している内容を見てみましょう。
システムプロンプト（System Prompt）は、おおよそ以下の順序で組み立てられます：
[0] デフォルトのエージェントアイデンティティ
[1] ツール使用行動ガイドライン
[2] Honcho 統合モジュール（オプション）
[3] オプションのシステムメッセージ
[4] 固定化された MEMORY.md スナップショット
[5] 固定化された USER.md スナップショット
[6] スキルインデックス
[7] コンテキストファイル（AGENTS.md、SOUL.md などのルールファイル）
[8] 日付/時刻 + プラットフォーム情報
[9] 対話履歴
[10] 現在のユーザーメッセージ
これは非常に重要です。なぜなら Hermes は大規模言語モデルベンダーのプロンプトキャッシュ（Prompt Caching）メカニズムに対して最適化されているからです。コードを見ると、プロンプトビルダの目標は非常に明確です：安定したプレフィックス部分を可能な限り長く一定に保つこと。
この一つの決断が、Hermes の記憶アーキテクチャの大部分を説明しています。
ある情報が対話の各ラウンドで必要とされる場合、Hermes はそれを極限まで圧縮して注入します。一方、情報量が多く、過去の履歴や時折しか不要な情報は、プロンプトから除外し、「オンデマンド検索」方式を採用します。
第一层：固化的提示词记忆
その内蔵メモリシステムは驚くほど小さい。
Hermes は永続的記憶を ~/.hermes/memories/ ディレクトリ内の 2 つのファイルに保存する。
ファイル | 用途 | 制限
---|---|---
MEMORY.md | エージェントノート：環境、仕様、ツールの癖、教訓 | 2,200 文字
USER.md | ユーザープロファイル：嗜好、コミュニケーションスタイル、身元情報 | 1,375 文字
この容量は決して大きくない。合計しても約 1,300 の トークン（モデルがテキストを理解する最小単位） に過ぎない。
しかし、これは意図的な設計だ。
セッション開始時、Hermes はこれら 2 つのファイルを読み込み、プロンプトブロックにレンダリングして、セッション全体を通じてこのスナップショットを固定化する。セッション中に書き込まれた記憶は即座にディスクに保存されるが、すでに生成されたシステムプロンプトには反映されない。これらの変更が有効になるのは、新しいセッションを開始するか、「圧縮（Compression）」によってプロンプトの再構築がトリガーされた場合のみである。
レンダリング後の形式は以下の通りだ：
══════════════════════════════════════════════
MEMORY (あなたの個人ノート) [67% — 1,474/2,200 文字]
══════════════════════════════════════════════
ユーザーのプロジェクトは ~/code/myapi にある Rust Web サービスで、Axum + SQLx を使用している
§
このマシンは Ubuntu 22.04 で動作し、Docker と Podman がインストールされている
§
ユーザーは簡潔な回答を好み、冗長な説明を嫌う
ここには私が特に評価するいくつかの設計上の細部がある：
- トークン制限ではなく文字制限を使用している点：これによりメモリロジックがモデルに依存しなくなる。Hermes は特定のモデル計算ツールを呼び出すことなく、メモリがいっぱいになったかどうかを判断できる。
- 単純な区切り文字ファイル形式：項目間は § で区切られる。複雑なベクトルデータベース（Vector DB）も独自バイナリストレージもなく、純粋なテキストのみだ。
- あえて極小のシステムプロンプト領域を維持している点：これが設計全体の最重要事項である。Hermes はすべての履歴をプロンプトに詰め込むつもりはない。最も価値のある事実だけを必要としているのだ。
- メモリは「日記」ではなく「精選された状態」である点：これが Hermes と OpenClaw の最大の違いだ。
OpenClaw のログはどちらかといえば「時系列の記録（日誌）」に近い。一方、Hermes はそれとは逆のアプローチを取る。そのツールアーキテクチャとテストロジックは以下を強調する：
- ユーザーの嗜好を保存する。
- 環境に関する事実を保存する。
- 繰り返し発生するエラー修正を保存する。
- 安定した仕様を保存する。
- タスクの進行状況を保存しない。
- セッションの結果を保存しない。
- 一時的なToDo（TODO）を保存しない。
真実はこうだ：Hermes は MEMORY.md と USER.md を簡潔で、頻繁に更新され、キャッシュに優しい状態に保ちたいと考えている。
memory ツール
Hermes は、add（追加）、replace（置換）、remove（削除）の 3 つの操作を持つ memory ツールを通じてこれらのファイルを管理する。
非常に使い勝手の良い細部として、replace と remove が部分文字列マッチングを使用している点が挙げられる。項目の内部 ID を覚える必要はなく、既存の項目から一意なテキストの一部を指定するだけでよい。
また、システムは完全に重複したコンテンツを拒否し、危険な情報を遮断します。ソースコードは記憶項目をスキャンして、プロンプトインジェクション（Prompt Injection、入力を通じて悪意のある指示を与え AI を誤導する行為）、認証情報の漏洩、または隠された Unicode 文字を防ぎます。
セッション検索による状況の再構築（第二層）
MEMORY.md が Hermes の「短期ホットメモリ」であるなら、session_search はその「長尾バックシステム」と言えます。
過去のすべてのセッションは SQLite データベースに保存されており、完全なインデックスと検索機能を備えています。モデルが以前の話した内容を思い出そうとする際、MEMORY.md をめくるのではなく、このセッションデータベースを検索します。
そのワークフローは以下の通りです：
- 過去メッセージの全文検索を行う。
- 結果をセッションごとにグループ化する。
- 最も関連性の高いセッションを読み込む。
- 安価な補助モデルを使用してこれらのセッションを要約する。
- 精製された振り返り内容をメインモデルに返す。
これは非常に実用的な設計です。無闇に膨大な歴史をすべてのプロンプトに詰め込むよりも、はるかに低コストで効率的です。
メモリ圧縮と記憶のフラッシュ（第三層）
Hermes のもう一つの賢い点は、長文会話における「圧縮」処理の方法です。
セッションが長くなりすぎると、Hermes は会話の中間部分を圧縮してスペースを節約します。しかし、要約には損失が生じるため、重要な事実が失われる可能性があります。
そこで Hermes はまず「メモリフラッシュ（記憶の洗い流し）」を実行します。
圧縮を行う前に、モデルに以下の指示を送信します：
**
"セッションが間もなく圧縮されます。覚えておくべきものはすべて保存してください。具体的なタスクの詳細よりも、ユーザーの好み、修正提案、反復パターンを優先して保存してください。"
**
その後、memory ツールのみを有効にして追加のモデル呼び出しを実行します。モデルに何か残すべきものがある場合、会話が"洗い流される"前に MEMORY.md に書き込まれます。
プログラムとしての記憶：スキル（第四層）
Hermes は事実だけでなく、スキルの記憶も可能です。
スキルは ~/.hermes/skills/ 配下に保存されます。Hermes が複雑なプロセスを発見したり、厄介な問題を解決したり、より良い方法を学んだりした際、それを「スキル」として保存できます。
多くの記憶システムが「意味的な再構築」（名前、好み、事実）に焦点を当てるのに対し、エージェントは物事のやり方も記憶する必要があります。
効率化のため、Hermes はすべてのスキルをプロンプトに詰め込むのではなく、スキルインデックスのみを含め、必要に応じて具体的なスキル内容を読み込みます。
深層モデリングのための Honcho（第五層）
最後にオプションの Honcho レイヤーがあります。ローカルメモリが Hermes のノートブックであるなら、Honcho は構築しようとする複雑なユーザーモデルです。これはデバイスやプラットフォームを跨ぐ記憶の連続性を実現します。
最も巧妙なのは、プロンプトキャッシュを破綻させることなく統合する方法です：
- セッションの初回ラウンドでは、Honcho のコンテキストがシステムプロンプトに織り込まれます。
- その後の会話では、プロンプトの安定性を保つため、Honcho からの再構築内容は現在のユーザーの質問の後に付加され、システムプロンプト自体は変更されません。
これによりキャッシュの有効性が維持される一方で、AI は最新の背景情報を依然として読み取ることができます。
Hermes と OpenClaw の違い
- OpenClaw：記憶は「Markdown 中心のストレージ」に近く、ログと永続ファイルが主要な事実源です。
- Hermes：プロンプト内の記憶は厳しく制限され、履歴は SQLite に保存され、必要に応じて検索されます。
Hermes はキャッシュ効率をより重視しています。 それは、すべての情報を「システムプロンプト」という黄金の立地に住まわせる必要はないと考えています。
総括：Hermes は何を正しく行ったのか？
- コールドとホットの分離：小規模なプロンプトメモリが常駐情報の役割を担い、検索が稀に利用される情報の役割を担います。
- キャッシュ優先：頻繁にプロンプトを変更すると遅延が増加しコストが上昇することを認識しています。
- メモリの多様性：メモリは階層化されていることを認めています——個人のプロファイル、状況の追跡、操作スキル、そして深いモデル化が含まれます。
Hermes の核心的な設計原則で最も感銘を受けたのはこれです：メモリは、プロンプトの安定性を破壊して博識を得る代わりに、エージェントをより使いやすくするべきものです。
真の秘訣は、単に多くを記憶することではなく、正しい階層で、適切なコストで、正しいことを記憶することにあります。
原文を表示
深度拆解 Hermes Agent 的记忆系统：它如何修正 OpenClaw 的误区
作者：Manthan Gupta**
原文：I Read Hermes Agent's Memory System, and It Fixes What OpenClaw Got Wrong
如果你读过我之前关于 ChatGPT、Claude 以及 Clawdbot 记忆系统的文章，你就会知道我一直在钻研同一个问题：这些 AI 智能体（AI Agent）到底是怎么记事的？
Hermes Agent 对我来说格外有趣，因为这次我不需要只靠观察它的行为来搞“逆向工程”。Hermes 是开源的，它的代码库和文档都是公开的。所以，我没有通过提示词（Prompt）去盲测这个黑盒，而是直接翻看了它的代码路径——从它如何构建提示词状态、持久化会话，到如何清理记忆和查询历史对话。
简而言之：Hermes 拥有的不是一套记忆系统，而是四套。**
- 存储在 MEMORY.md 和 USER.md 中、经过高度浓缩的提示词记忆。
- 通过 session_search 调用的 SQLite 历史会话存档（可搜索）。
- 像程序记忆（Procedural Memory）一样运作的智能体技能管理。
- 可选的 Honcho 层，用于更深层的用户建模（User Modeling）。
把这些设计联系在一起的核心逻辑非常简单：保持提示词稳定以便利用缓存（Caching），其他一切繁杂信息都交给工具。
让我们深入聊聊。
Hermes 的上下文结构
在理解记忆之前，我们先看看 Hermes 到底给模型发送了什么。
系统提示词（System Prompt）大致是按以下顺序组装的：
[0] 默认智能体身份
[1] 工具使用行为指南
[2] Honcho 集成模块（可选）
[3] 可选系统消息
[4] 固化的 MEMORY.md 快照
[5] 固化的 USER.md 快照
[6] 技能索引
[7] 上下文文件（AGENTS.md, SOUL.md 等规则文件）
[8] 日期/时间 + 平台信息
[9] 对话历史
[10] 当前用户消息
这非常关键，因为 Hermes 正在针对大模型供应商的提示词缓存（Prompt Caching）机制进行优化。代码显示，提示词构建器的目标非常明确：让稳定的前缀部分尽可能长时间地保持不变。
这一个决定就解释了 Hermes 大部分的记忆架构。
如果某条信息每一轮对话都要用到，Hermes 会尽量把它缩得很小并注入进去；如果信息量很大、属于历史旧账或者偶尔才有用，Hermes 就会把它踢出提示词，改用“按需检索”的方式。
第一层：固化的提示词记忆
其内置的记忆系统小得令人惊讶。
Hermes 将持久记忆存储在 ~/.hermes/memories/ 下的两个文件中：
文件
用途
限制
MEMORY.md
智能体笔记：环境、规范、工具怪癖、教训
2,200 字符
USER.md
用户画像：偏好、沟通风格、身份信息
1,375 字符
这容量真不大。加起来大约只有 1,300 个 Token（模型理解文本的最小单位）。
而这正是刻意为之。
在会话开始时，Hermes 加载这两个文件，把它们渲染进提示词区块，然后在整个会话期间固化这个快照。会话中途写入的记忆会立即存入硬盘，但不会改变已经生成的系统提示词。这些改动只有在开启新会话，或者触发了“压缩（Compression）”导致的提示词重建时才会生效。
渲染后的格式如下：
══════════════════════════════════════════════
MEMORY (你的个人笔记) [67% — 1,474/2,200 字符]
══════════════════════════════════════════════
用户的项目是一个位于 ~/code/myapi 的 Rust Web 服务，使用 Axum + SQLx
§
这台机器运行 Ubuntu 22.04，安装了 Docker 和 Podman
§
用户喜欢简洁的回复，讨厌冗长的解释
这里有几个我非常欣赏的细节设计：
- 使用字符限制而非 Token 限制：这让记忆逻辑与模型无关。Hermes 不需要调用特定模型的计算工具就能判断记忆是否存满。
- 简单的分隔符文件格式：条目之间用 § 分隔。没有复杂的向量数据库（Vector DB），没有自定义二进制存储，就是纯文本。
- 刻意保持极小的系统提示词空间：这是整个设计的重中之重。Hermes 不想把所有历史都塞进提示词，它只想要最有价值的事实。
- 记忆是“精选状态”，而不是“日记”：这是 Hermes 与 OpenClaw 最大的区别。
OpenClaw 的日志更像是“流水账”。而 Hermes 则反其道而行。它的工具架构和测试逻辑强调：
- 保存用户偏好。
- 保存环境事实。
- 保存反复出现的错误修正。
- 保存稳定的规范。
- 不保存任务进度。
- 不保存会话结果。
- 不保存临时的待办事项（TODO）。
真相是：Hermes 希望 MEMORY.md 和 USER.md 保持精简、高频且对缓存友好。
memory 工具
Hermes 通过一个拥有三种操作的 memory 工具来管理这些文件：add（添加）、replace（替换）、remove（移除）。
一个好用的细节是：replace 和 remove 使用子字符串匹配。你不需要记住条目的内部 ID，只需要传入现有条目中一段唯一的文字即可。
此外，系统会拒绝完全重复的内容，并拦截危险信息。源代码会扫描记忆条目，防止提示词注入（Prompt Injection，即通过输入恶意指令误导 AI）、凭证泄露或隐藏的 Unicode 字符。
第二层：用于情景回溯的 session_search
如果说 MEMORY.md 是 Hermes 的“短期热记忆”，那么 session_search 就是它的“长尾回溯系统”。
所有过去的会话都存储在 SQLite 数据库中，拥有完整的索引和搜索功能。当模型需要想起以前聊过的内容时，它不去翻 MEMORY.md，而是搜索这个会话数据库。
其工作流程是：
- 在过去的消息中进行全文搜索。
- 按会话分组结果。
- 加载匹配度最高的会话。
- 使用一个便宜的辅助模型对这些会话进行摘要总结。
- 将精炼后的回顾内容返回给主模型。
这是一种非常务实的设计。它比盲目地把长篇累牍的历史塞进每一个提示词要便宜且高效得多。
第三层：压缩与记忆冲刷（Memory Flush）
Hermes 另一个聪明之处在于它处理长对话“压缩”的方式。
当会话变得太长，Hermes 会压缩对话中间的部分以节省空间。但摘要是有损的，重要事实可能会丢失。
于是，Hermes 会先进行一次“记忆冲刷”。
在压缩之前，它会发送一条指令告诉模型：
“会话即将压缩，请保存任何值得记住的东西。优先保存用户偏好、修正建议和重复模式，而非具体的任务细节。”
然后它运行一次额外的模型调用，只开启 memory 工具。如果模型觉得有什么东西该留下来，就会在对话被“洗掉”之前把它写入 MEMORY.md。
第四层：作为程序记忆的技能（Skills）
Hermes 不仅能记住事实，还能记住技能。
技能（Skills）存储在 ~/.hermes/skills/ 下。当 Hermes 发现了一个复杂的流程、修复了一个棘手的问题或学会了更好的方法时，它可以将其保存为“技能”。
大多数记忆系统只关注“语义回溯”（名字、偏好、事实），但智能体还需要记住如何做事。
为了效率，Hermes 不会把所有技能都塞进提示词，而是只放一个技能索引，只有在需要时才加载具体的技能内容。
第五层：用于深层建模的 Honcho
最后是可选的 Honcho 层。如果说本地记忆是 Hermes 的笔记本，Honcho 就是它尝试构建的复杂用户模型。它能实现跨设备、跨平台的记忆连续性。
最精妙的是它如何在不破坏提示词缓存的前提下实现集成：
- 在会话的第一轮，Honcho 的上下文会被织入系统提示词。
- 在之后的对话中，为了保持提示词稳定，Honcho 的回溯内容会附加在当前用户的提问后面，而不是修改系统提示词。
这确保了缓存依然有效，同时 AI 依然能读到最新的背景信息。
Hermes 与 OpenClaw 的区别
- OpenClaw：记忆更接近“以 Markdown 为中心的存储”，日志和长效文件是主要事实来源。
- Hermes：提示词记忆被严格限制，历史记录存在 SQLite 里，只有需要时才搜索。
Hermes 更加关注缓存效率。 它认为：不是所有东西都配住在“系统提示词”这个黄金地段。
总结：Hermes 做对了什么？
- 冷热分离：小规模提示词记忆负责常驻信息，搜索负责偶尔用到的信息。
- 缓存优先：它意识到频繁改动提示词会导致延迟增加和成本上升。
- 记忆的多样性：它承认记忆是分层的——包括个人画像、情景回溯、操作技能和深层建模。
Hermes 的核心设计原则最令我折服：记忆应该让智能体变得更好用，而不是通过摧毁提示词的稳定性来换取博闻强识。
真正的诀窍不是记住更多，而是在正确的层级、以正确的成本，记住正确的事情。
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み