Concise Summary简洁概述
Hermes Agent runs four distinct memory layers — capped prompt files, searchable SQLite session history, a skills library, and an optional Honcho user-modeling layer — all organized around one constraint: keep the prompt prefix stable to preserve provider-side caching.
This directly corrects OpenClaw's markdown-log-centric design: rather than treating memory as an ever-growing diary, Hermes treats prompt-resident memory as a small, curated cache of only the highest-value, cache-friendly facts.
Hermes Agent 实际上运行着四套记忆系统——容量受限的提示词文件、可检索的 SQLite 会话历史、技能库，以及可选的 Honcho 用户建模层——全部围绕一个约束设计：保持提示词前缀稳定以利用供应商侧的缓存。
这直接修正了 OpenClaw 以 Markdown 日志为中心的设计思路：Hermes 不把记忆当成越写越长的日记，而是把驻留在提示词里的记忆当作一个极小、经过精选、对缓存友好的高价值事实集合。
Infographic信息图
Cache-first prompt assembly
提示词组装以缓存为先
Hermes orders the system prompt with the most stable content first (identity, tool rules) and volatile content (conversation, current message) last, so provider-side prompt caching stays hot across turns.
Hermes 把系统提示词按稳定性排序：身份与工具规则放最前，对话历史和当前消息放最后，这样模型供应商的提示词缓存能在多轮对话中保持命中。
Curated notes, not a diary
精选笔记而非流水账
MEMORY.md and USER.md are capped at ~2,200 and ~1,375 characters, storing only preferences, environment facts, and recurring fixes — never task progress or TODOs, unlike OpenClaw's markdown-log approach.
MEMORY.md 和 USER.md 分别限制在约 2,200 和 1,375 字符，只存用户偏好、环境事实和反复出现的修正，绝不存任务进度或待办——这与 OpenClaw 的日志式 Markdown 存储形成对照。
Search over stuffing
检索优先于塞入
Instead of injecting session history into every prompt, Hermes stores past conversations in SQLite and retrieves them on demand via session_search, summarizing matches with a cheaper helper model.
Hermes 不把历史会话塞进每次提示词，而是存入 SQLite，通过 session_search 按需检索，再用一个便宜的辅助模型对匹配结果做摘要。
Memory flush before compression
压缩前的记忆冲刷
Before lossy conversation compression runs, Hermes fires an extra model call with only the memory tool enabled, giving the model one last chance to persist anything worth keeping before it's summarized away.
在有损的对话压缩发生之前，Hermes 会额外调用一次模型，仅开放 memory 工具，让模型在信息被摘要抹去前，抓住最后机会把值得保留的内容写入记忆。
Detailed Summary详细解读
The article's starting move is methodological: because Hermes is open source, the author reads code paths instead of probing behavior through prompts. This matters because black-box reverse-engineering (used in the author's prior ChatGPT/Claude memory pieces) can only infer structure from outputs, while reading source reveals the actual prompt-assembly order, file formats, and character limits — ground truth rather than inference.
The core architectural insight is that Hermes assembles its system prompt in a fixed order — identity, tool rules, optional modules, then the curated MEMORY.md/USER.md snapshots, skill index, context files, and only at the very end conversation history and the current message. This ordering is not cosmetic: it's engineered so the stable prefix survives provider prompt caching across turns, which directly reduces latency and cost.
That caching constraint cascades into the memory design itself: MEMORY.md and USER.md are hard-capped at ~2,200 and ~1,375 characters respectively (roughly 1,300 tokens combined), use character limits rather than token limits to stay model-agnostic, and are frozen as a snapshot for the whole session — writes hit disk immediately but don't alter the already-generated prompt until a new session or a compression-triggered rebuild.
Beyond the small prompt-resident memory, Hermes layers in session_search over a SQLite archive for episodic recall (full-text search, grouped by session, summarized by a cheaper model before returning to the main model), a skills directory for procedural memory (an index only, full skill content loaded on demand), and an optional Honcho layer for cross-device user modeling that appends its context to user turns instead of rewriting the system prompt.
The comparison to OpenClaw is the article's sharpest contribution: OpenClaw treats markdown files as an ever-accumulating log of everything, while Hermes explicitly filters — preferences, environment facts, recurring corrections, and stable conventions go in; task progress, session outcomes, and TODOs are deliberately excluded. The memory tool itself enforces this via substring-match add/replace/remove and scans for prompt injection, credential leaks, and hidden Unicode.
The article's closing synthesis frames this as a general design principle worth generalizing beyond Hermes: memory systems should separate 'hot' identity-level facts (small, cached, always-present) from 'cold' episodic or procedural knowledge (large, searched, occasionally retrieved), rather than treating recall capacity as a single undifferentiated pool that grows with usage.
文章的起手式是方法论上的转变：因为 Hermes 开源，作者直接读代码路径，而不是像之前分析 ChatGPT、Claude 记忆系统那样靠提示词黑盒试探。这个区别很关键——黑盒逆向只能从输出反推结构，而读源码能看到真实的提示词组装顺序、文件格式和字符上限，是确凿事实而非推测。
核心架构洞察在于 Hermes 系统提示词的组装顺序是固定的：身份、工具规则、可选模块，然后是精选的 MEMORY.md/USER.md 快照、技能索引、上下文文件，最后才是对话历史和当前消息。这个顺序不是摆设，而是刻意设计让稳定前缀能在多轮对话中保住供应商侧的提示词缓存，从而直接降低延迟和成本。
这个缓存约束进一步下沉到记忆设计本身：MEMORY.md 和 USER.md 硬性限制在约 2,200 和 1,375 字符（合计约 1,300 个 token），用字符而非 token 计数以保持模型无关性，并且在整个会话期间冻结为一份快照——写入会立即落盘，但不会改变已生成的提示词，只有新会话或触发压缩重建时才会生效。
除了这层极小的驻留提示词记忆之外，Hermes 还叠加了针对 SQLite 归档的 session_search 做情景回溯（全文检索、按会话分组、用更便宜的模型先摘要再返回主模型），用技能目录做程序记忆（只加载索引，具体内容按需调取），以及可选的 Honcho 层做跨设备用户建模，其上下文附加在用户轮次而非改写系统提示词。
与 OpenClaw 的对比是文章最犀利的贡献：OpenClaw 把 Markdown 文件当成不断累积一切内容的日志，而 Hermes 明确做了筛选——偏好、环境事实、反复出现的修正、稳定规范才会被记录；任务进度、会话结果、待办事项则被刻意排除在外。memory 工具本身通过子字符串匹配的 add/replace/remove 强制执行这一点，并扫描提示词注入、凭证泄露和隐藏 Unicode 字符。
文章收尾把这一点升华成一条可推广到 Hermes 之外的通用设计原则：记忆系统应当把「热」的身份级事实（体量小、被缓存、始终在场）与「冷」的情景或程序性知识（体量大、需检索、偶尔调用）分开处理，而不是把记忆容量当成一个随使用量无差别膨胀的单一池子。
FAQ常见问答
Why does Hermes use character limits instead of token limits for memory files?Hermes 为什么用字符限制而不是 token 限制来控制记忆文件？
Character counting works identically regardless of which model or tokenizer is in use, so Hermes can enforce memory limits without calling a model-specific tokenizer, keeping the memory subsystem model-agnostic.
字符计数不依赖具体模型或分词器，Hermes 因此不需要调用特定模型的 token 计算工具就能判断记忆是否超限，让记忆子系统与模型解耦。
How is Hermes's memory fundamentally different from OpenClaw's?Hermes 的记忆和 OpenClaw 的记忆本质区别是什么？
OpenClaw treats markdown files as a growing log of everything that happens; Hermes treats its prompt-resident files as a small, curated cache — task progress and session outcomes are explicitly excluded, only stable facts and preferences persist.
OpenClaw 把 Markdown 文件当作不断累积一切事件的日志；Hermes 则把提示词驻留文件当成一个精选的小缓存——任务进度和会话结果被明确排除，只留下稳定的事实和偏好。
What happens to a memory write made mid-session?会话中途写入的记忆会立刻生效吗？
It's saved to disk immediately but doesn't change the already-built system prompt for that session; the update only appears in the prompt after a new session starts or a compression event triggers a rebuild.
它会立即落盘，但不会改变当前会话已经生成的系统提示词；这次更新只有在新会话开始，或触发压缩导致提示词重建时才会体现出来。
Why run an extra model call before compression instead of just letting the summary happen?为什么要在压缩前额外调用一次模型，而不是直接让摘要发生？
Compression summaries are lossy and can drop important facts; the pre-compression 'memory flush' call, with only the memory tool enabled, gives the model one last chance to persist what matters before that context is discarded.
压缩生成的摘要是有损的，可能丢失重要事实；压缩前的「记忆冲刷」调用只开放 memory 工具，让模型在这部分上下文被丢弃前，抓住最后机会保存关键内容。
Is the Honcho layer required for Hermes to function?Honcho 层是 Hermes 运行的必需组件吗？
No — it's an optional layer for deeper, cross-device user modeling. Its integration is designed so that after the first turn, its retrieved context is appended to user messages rather than rewritten into the system prompt, preserving caching.
不是——它是用于更深层、跨设备用户建模的可选层。其集成方式是在首轮之后，把检索到的上下文附加在用户消息后而非改写进系统提示词，以此保住缓存效果。
In-depth Analysis · Pros & Cons深入解读 · 优缺点
This piece reverse-engineers Hermes Agent's memory system from its open-source codebase, rather than guessing from behavior. It shows how caching economics, not just cognitive design, dictate what an agent chooses to remember and where.
这篇文章直接翻阅 Hermes Agent 的开源代码，而非靠提示词黑盒猜测，逆向拆解出它的记忆架构。它揭示了提示词缓存的经济学如何决定智能体记什么、记在哪。
- Ground-truth methodology基于源码的实证方法Reading actual code paths instead of inferring from black-box prompting yields concrete, verifiable claims about file formats, character limits, and prompt ordering rather than speculation.直接读代码路径而非从黑盒提示词行为反推，得出的是关于文件格式、字符上限和提示词顺序的具体、可验证结论，而非猜测。
- Names a coherent unifying principle提炼出统一的核心原则The piece distills a scattered set of implementation details into one clear organizing idea — optimize for prompt-cache stability — which explains nearly every design choice described.文章把一堆分散的实现细节提炼成一个清晰的组织原则——为提示词缓存的稳定性做优化——这一原则几乎能解释文中描述的每个设计选择。
- Concrete comparative framing具体的对照框架Contrasting Hermes against the author's earlier work on OpenClaw, ChatGPT, and Claude memory gives readers a comparative frame rather than an isolated system description.将 Hermes 与作者此前分析过的 OpenClaw、ChatGPT、Claude 记忆系统做对照，给读者提供了比较性框架而非孤立的系统描述。
- Layered taxonomy is reusable分层分类法可复用The hot/cold, semantic/episodic/procedural breakdown (prompt memory, session search, skills, Honcho) is a useful general vocabulary applicable to evaluating other agent memory designs.热/冷、语义/情景/程序的分层划分（提示词记忆、会话检索、技能、Honcho）是一套可用于评估其他智能体记忆设计的通用词汇。
- Single-source account单一信源The analysis relies entirely on reading Hermes's own codebase and documentation; there's no independent benchmark or user study confirming the caching-efficiency gains actually materialize in practice.分析完全基于阅读 Hermes 自身的代码库和文档，没有独立的基准测试或用户研究证实缓存效率的提升在实际使用中真的兑现。
- No cost/latency numbers缺少成本与延迟数据The piece asserts that cache-friendly prompt ordering reduces latency and cost but never quantifies the actual savings versus a naive full-history-stuffing approach.文章断言缓存友好的提示词顺序能降低延迟和成本，但从未量化相较于直接塞入全部历史的朴素方案，实际节省了多少。
- OpenClaw comparison is thin与 OpenClaw 的对比较单薄The OpenClaw contrast is asserted in a few bullet points without the same code-level evidence given for Hermes, so the 'fixes what OpenClaw got wrong' framing is more assertion than demonstrated proof.对 OpenClaw 的对比只用几条要点带过，没有像分析 Hermes 那样给出同等级别的代码证据，因此「修正了 OpenClaw 的误区」这一框架更像断言而非充分论证。
- Honcho layer underexploredHoncho 层着墨不足The optional Honcho integration is described only at a high level (context injected on turn one, appended afterward); how it actually builds or updates its user model is left unexamined.可选的 Honcho 集成只做了高层描述（首轮注入上下文，之后附加），但它究竟如何构建或更新用户模型没有被深入探讨。
Read this if you're designing or evaluating agent memory architecture and want a concrete, code-verified case study rather than another speculative memory-system pitch. The caveat: it's a single-source analysis of one open-source project, with no independent benchmarks confirming the caching gains — treat the design principles as a strong hypothesis worth testing, not a proven result.
如果你正在设计或评估智能体记忆架构，想要一个基于代码验证、而非又一篇臆测性方案的具体案例，这篇文章值得读。但要留意：这是对单个开源项目的单一信源分析，没有独立基准数据证实缓存收益，其设计原则应被当作值得验证的强假设，而非已被证明的结论。
Excerpt原文节选
This is a short excerpt, not the full piece — the complete essay belongs to its original author; please read it in full at the link above.
以下仅为节选，并非全文——完整文章版权归原作者所有，请点击上方链接阅读全文。
The English text on this side is an AI translation provided for convenience; the authoritative version is the source in the other language.
A Deep Dive into Hermes Agent's Memory System: How It Fixes What OpenClaw Got Wrong
By Manthan Gupta. Original: "I Read Hermes Agent's Memory System, and It Fixes What OpenClaw Got Wrong"
If you've read my earlier pieces on the memory systems of ChatGPT, Claude, and Clawdbot, you know I've been digging into the same question all along: how do these AI agents actually remember things?
Hermes Agent was especially interesting to me because this time I didn't have to "reverse-engineer" it purely by observing its behavior. Hermes is open source—its codebase and documentation are both public. So instead of blindly probing the black box with prompts, I went straight through its code paths: how it builds prompt state, persists sessions, cleans up memory, and queries past conversations.
In short: Hermes doesn't have one memory system—it has four.
A highly condensed prompt memory, stored in MEMORY.
[…the source continues — read the rest at the link above]
[……原文更长，完整内容请点击上方链接阅读]
The real trick isn't remembering more—it's remembering the right things, at the right level, at the right cost.
深度拆解 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）大致是按以下顺序组装的：
这非常关键，因为 Hermes 正在针对大模型供应商的 提示词缓存（Prompt Caching） 机制进行优化。代码显示，提示词构建器的目标非常明确： 让稳定的前缀部分尽可能长时间地保持不变。
这一个决定就解释了 Hermes 大部分的记忆架构。
如果某条信息每一轮对话都要用到，Hermes 会尽量把它缩得很小并注入进去；如果信息量很大、属于历史旧账或者偶尔才有用，Herme…
[…the source continues — read the rest at the link above]
[……原文更长，完整内容请点击上方链接阅读]
真正的诀窍不是记住更多，而是在正确的层级、以正确的成本，记住正确的事情。