# The Hermes Agent Memory Guidebook
**作者**: Kevin Simback
**日期**: 2026-05-23T19:02:34.000Z
**来源**: [https://x.com/KSimback/status/2058262328496554021](https://x.com/KSimback/status/2058262328496554021)
---
> TLDR: this is your definitive guide to all things related to memory systems for Hermes Agent. Why create this? Because every week I see new posts or articles describing some new memory tool for Hermes agents and these make me question if my memory setup is the best. So I dug into all of them and broke it down for you.
Over the past few months my Hermes agent has been mapping the Hermes ecosystem over at hermesatlas.com. One of the key areas it has covered is memory and it even has a dedicated section for it.
hermesatlas.com
And let's be honest, there are a LOT of memory related tools available and there are a LOT of write-ups about them. I see new articles on X every week about some new memory setup. It's hard to keep up, and even harder to know if you're doing it all wrong because they all make claims about how certain memory systems are better than others.
But many of these write-ups skip the architecture (how memory works in Hermes) or conflate different elements of the memory stack. This article is the culmination of everything I've learned about Hermes agent memory and a guide to help you navigate what makes most sense for your setup.
## Memory is arguably the most important element of an agent setup
Without memory, an agent is just a stateless function and no different than a blank ChatGPT window. Every prompt looks like the first prompt. That works for one-shot questions but breaks down the moment you have a use case that needs to know what happened yesterday, remember your preferences, accumulate skills from prior tasks, or coordinate with another agent.
A coding session that doesn't remember the conventions you established last Tuesday will reinvent them this Tuesday. A personal assistant agent that doesn't remember your preferences has to ask you the same repeated questions. Without memory, an agent really isn't an agent at all.
Memory is what turns an chatbot into something that compounds. Which is why every serious agent harness - OpenClaw, Claude Code, Codex, and our beloved Hermes - has memory primitives built in, and why a real product category has emerged around dedicated memory infrastructure or agents (Mem0 raised $24M, Letta $10M, plus Zep, Cipher, Supermemory, Hindsight, etc.).
The Hermes Agent take is interesting because Nous Research treats memory as first-class plug-in infrastructure, not a feature. There's a base layer that always runs, a pluggable provider system that lets you choose from 8 architectures (or write your own), and a healthy community plug-in layer on top.
That 3-layer stack is what I will explore in depth in this article.
## Hermes Agent memory architecture at a glance
Here's what each layer means for you as a Hermes user.
Layer 1 - what ships in the box. You get this whether you do anything or not. Two small markdown files the agent uses as its always-visible notebook, plus a local database that archives every session you've ever had. No setup, no config. For many use cases, this is often all you need.
Layer 2 - the optional plug-in slot. When you outgrow the native layer (you want semantic recall across sessions, or a system that models your preferences, or token-efficient retrieval at scale) you pick one of 8 official providers. They each take a different architectural bet about what memory should do, and you can run exactly one at a time. Switching providers is a clean start - the new provider doesn't inherit the old one's data, but the Layer 1 native files keep running underneath either way.
Layer 3 - what the community builds beyond the official 8. Two flavors. Some community projects are MemoryProvider plug-ins that compete head-to-head with the Layer 2 picks (Mnemosyne is the standout - fully local, sub-millisecond, with a real tiered cognitive architecture). Others sit alongside the official providers in a different slot entirely (GBrain is the standout here - it stores world facts like people, companies, and projects in a markdown vault, while your Layer 2 provider handles operational memory). Layer 3 usually means more setup and less polish than the official 8, but it's where you go when you need a capability the eight providers don't offer.
The layers stack rather than replace each other. Switching the Layer 2 provider does not wipe Layer 1. Each provider has its own store, but the native session database and the two markdown files keep running underneath. Layer 3 plug-ins are additive on top of both.
## Layer 1: Native - what you get out of the box
The native layer is three things that ship with every Hermes install: two small markdown files and one database. They play different roles, and it's worth understanding each before we get to the plug-in providers.
Note: if you already understand the out of box setup or want to skip to the optional stuff you can install on top, go to Layer 2.
The two markdown files
When you install Hermes, it creates two text files in your home directory at ~/.hermes/:
> MEMORY.md - the agent's general knowledge notebook. Project context, technical decisions, things worth remembering across sessions. Capped at about 2,200 characters, roughly a paragraph and a half.
> USER.md - what the agent knows about you specifically. Your preferences, your working style, your role. Capped at about 1,375 characters, roughly one paragraph.
You can open both files in any text editor. They're plain markdown. You can even edit them by hand if you want, and the agent will read your edits next session.
The reason they're so small is that they aren't the agent's filing cabinet - they're the agent's sticky notes. At the start of every session, Hermes pastes the entire contents of both files into the prompt sent to the model. So everything in these files is always "in front of" the agent. No retrieval needed, it just sees them.
The agent itself decides what goes into these files. When something important comes up in a session - you say "I prefer bullet points instead of paragraphs" or the agent figures out that you use Vercel for deployments - the agent calls a tool called memory with one of three actions: add, replace, or remove. There's no read action because the files are already pasted into the prompt; the agent reads them by virtue of looking at its own context.
What happens when the files fill up?
This is where most third-party write-ups get things wrong. They claim Hermes automatically consolidates the files when they hit 80% of the cap. I went into the code at agent/memory_manager.py to verify, and the actual behavior is more interesting:
There is no automatic consolidation - the 80% rule is a prompt instruction, not code. The system prompt header shows the agent a real-time fill gauge - something like "MEMORY: 1,847/2,200 chars (84 percent)" - along with the instruction "when memory is above 80% capacity, consolidate entries before adding new ones." The agent reads that, and the agent decides whether to act on it. If the file is already at the cap and the agent tries to add anything anyway, the memory tool returns an error listing the current entries and forces the agent to free space via replace or remove first.
This is a deliberate design choice. Nous trusts the model to manage its own notebook. The upside is full agent control, but the downside is also full agent control. A poorly-prompted agent can sit at the cap indefinitely, refusing every new add call and quietly losing information that should have replaced something older, but I'm confident this gets resolved soon as there's some PRs around this.
A related point of confusion worth clearing up before we go on: v0.12 introduced something called the "Autonomous Curator" and many write-ups describe it as automatic memory management. It is not. The Curator operates only on the agent's skill library at ~/.hermes/skills/ - moving skills from active to stale to archived based on usage. It never touches MEMORY.md or USER.md.
The database (and how it relates to the markdown files)
The two markdown files are the agent's always-visible notes. The database is the agent's full archive of everything that has ever happened.
Hermes stores every session in a SQLite database file at ~/.hermes/hermes_state.db. Every user message, every agent response, every tool call, every reasoning step, plus economic data like token counts and dollar cost per session - all of it lands here. Default retention is 90 days; older sessions get pruned automatically every 24 hours unless you change the setting.
This database is not auto-injected into prompts. It would be enormous - imagine pasting your entire chat history into every new conversation. Instead, the agent searches it on demand when it needs to find something specific.
The search uses SQLite's built-in full-text search (FTS5), and Hermes maintains two parallel indexes: one for normal word-level search ("did we discuss the content strategy?") and one for trigram search that handles substrings and code tokens ("find every session where I mentioned github").
So the mental model is:
> The two markdown files = what the agent always has in its head. Small, curated, always present in every prompt.
> The session database = what the agent can look up if it knows what to look for. Huge, raw, searchable on demand.
These are complementary, not redundant. When something matters across all future sessions, the agent should write it to MEMORY.md so it's always present. When something might matter again but doesn't need to be top-of-mind, it lives in the session database and gets pulled up only when the agent searches for it.
A nice side-effect of the database design: because Hermes captures every reasoning step and every tool call with full economic data, the database is also a complete training trajectory if you ever want to export it. This is beyond the scope of this article but something that aligns with my thesis on where the moats are in agents.
## Layer 2: The pluggable "MemoryProvider" system
This is the layer that lets you graduate from "small notebook plus searchable archive" to a real memory system - one that extracts facts from your conversations automatically, builds a profile of you, supports semantic recall across sessions, or handles a large knowledge graph.
Setting this up is quite simple - you run "hermes memory setup", pick a provider from the menu, and from then on the agent has a richer memory layer to draw from on top of the native files. Note: some providers require API keys and paid plans.
The important note is you can only run one provider at a time. Hermes treats this as a single deliberate choice, not a stack of bolt-ons.
That keeps your tool surface clean - each provider exposes its own set of agent tools, and the agent would get confused if there were three competing "search memory" tools sitting in front of it - and it makes the configuration easy to reason about. The Layer 1 native files keep running underneath whether you have a provider active or not.
Picking the right provider matters because they make very different architectural bets. Some are aggressive at extracting facts. Some build a model of how you think rather than what you said. Some are obsessed with token efficiency. Some are graph-first. The full decision tree is later in this article; the technical mechanics below are for readers who want to know what providers actually plug into.
Let's dive in.
## The 8 Official Providers
Honcho (Plastic Labs) - AI-native dialectic user modeling
The only provider in the lineup that tries to model how you think, not just what you said. Instead of storing flat facts like "Kevin uses 4-space indents," Honcho runs a multi-step reasoning pass after your conversations to build a profile of your reasoning patterns, preferences, and goals.
That profile evolves over time, so the agent gets better at anticipating what you'd want even on topics you've never discussed. It also lets multiple "AI identities" share the same view of you - useful if you run different specialist agents for coding, writing, and strategy and want all of them to know your style. Most-cited favorite in the Hermes Discord (@offendingcommit: "I've tried them all... I freakin' love Honcho.").
Mem0 - fastest 30-second setup, broadest ecosystem
The "just give me memory and stop asking questions" pick. You sign up for Mem0 cloud, paste an API key, and you're done - the provider extracts facts from conversations, deduplicates them, and serves up semantic search automatically in the background.
It's also the exclusive memory provider for AWS's Strands Agents SDK, which gives it the widest ecosystem reach in the lineup. In April 2026 Mem0 shipped a "v3" algorithm claiming to leapfrog Hindsight on benchmarks (94.8 on LongMemEval, 91.6 on LoCoMo).
Hindsight (Vectorize.io) - the benchmark king
The first memory system of any kind to publicly cross 90 on LongMemEval (91.4, December 2025). Hindsight thinks about memory as four separate networks - things about the world, things that happened, opinions, and raw observations - and pulls only a handful of high-value facts from each conversation (2 to 5, not one per sentence).
When you ask it something, it runs four different retrieval strategies in parallel - keyword search, vector similarity, graph traversal across related entities, and a recency pass - then fuses the results. That's how it gets the best recall accuracy in the published lineup.
It's also the only provider with a reflect tool that lets the agent run a reasoning pass over its own memory. That's uniquely valuable if you're running multiple agents on a shared memory bank and you need an orchestrator to synthesize what all of them know.
Holographic - zero-dependency, fully local, air-gapped
The only provider in the lineup that needs no internet, no API key, and no LLM to function. Everything lives in a local SQLite file. It uses a 1991-era technique called Holographic Reduced Representations to do compositional reasoning over facts - you can bind concepts together algebraically and probe for related ones later. Retrieval is sub-millisecond because it's pure local SQL.
OpenViking - tiered filesystem context DB
Your memory lives as files in a directory tree on your disk. You can cat them, grep them, edit them by hand. Each piece of stored knowledge has three loading tiers: a one-sentence summary, a paragraph-level overview, and the full content.
When the agent recalls something, it starts cheap (summaries only) and only loads the deeper tiers if the summary looks relevant. That structure is important if you're cost-sensitive at scale or you want memory you can read and edit like normal files.
RetainDB - cheapest paid tier, lowest friction
$20/month for 100,000 queries, with a free tier of 10,000 operations to test. The only provider in the lineup that's cloud-only at every price point (no self-host even on enterprise). The hook is convenience: you operate no infrastructure, RetainDB handles everything, and there's a "Memory Router" mode that intercepts your LLM calls and adds memory transparently with one config line.
Pick this option if you want shared memory across team members or agents and you don't want to operate a database.
ByteRover - memory as a git repo
Your memory is plain markdown files in a .brv/context-tree/ directory - grep-able, version-controllable, no database to run. ByteRover layers a 5-tier retrieval system on top, and four of those tiers don't need an LLM call, so most lookups finish in under 100ms with zero token spend.
The key selling point: you can branch, merge, and roll back memory like code with CLI commands. It also uses a special hook to extract high-value insights before Hermes compresses context, which is the cleanest fix in the lineup for the "agent loses memory after restart" failure mode (noted in issue #17251).
Supermemory - latency + scale leader
Sub-300ms recall sustained at over 100 billion tokens per month. Supermemory built a custom vector graph engine for this rather than stapling a vector DB and a graph DB together.
Its standout feature is context fencing: it automatically strips already-recalled memories out of conversations before storing them, which kills the "memory feedback loop" where auto-capture systems start re-ingesting their own outputs into the next round of memory.
Good choice if you want to operate at real scale (consumer app, multi-tenant SaaS, agent platform) and latency matters, but likely overkill for normal consumer use.
Here's a comparative look across all 8
## Layer 3: Community plug-ins worth knowing
If none of the official 8 fits your use case, or if you want even more on top, the community has built another layer of memory tooling for Hermes. About five of these are production-quality enough to consider seriously, plus a longer tail of experiments to keep eyes on.
Two things to know up front about Layer 3:
1. Not every Layer 3 project competes with Layer 2. Some are alternative MemoryProvider plug-ins you'd pick instead of one of the official 8 (Mnemosyne is the clearest example). Others occupy a different role entirely - they store a different type of memory and run alongside your Layer 2 provider, not in place of it (GBrain is the clearest example, storing world facts about people, companies, and projects in a separate brain layer while your Layer 2 provider handles operational memory).
2. You give up polish to get capability. The official 8 ship with Nous's review and tend to "just work." Community plug-ins are typically a bit rougher on the install, have fewer docs, and more chance of hitting a bug. But they unlock things the official set doesn't offer like fully-local sub-millisecond retrieval (Mnemosyne), a markdown-and-Postgres knowledge graph that builds itself with zero LLM calls (GBrain), explainable retrieval rankings (yantrikdb), and cross-agent memory portability (PLUR).
The safe path if you're committing to a memory stack for real work: start with one of the official 8 and only reach for Layer 3 when you've identified a specific capability gap a community project fills. The standouts below are GBrain and Mnemosyne.
GBrain (by garrytan) - this is what I personally use
Open-sourced in April, MIT licensed, ~18k+ stars. TypeScript. Built by Garry Tan to run his own production agents. GBrain is structurally different from the official 8. GBrain does not subclass MemoryProvider, it plugs in as skillpack + MCP server (~30 MCP tools), and occupys a different ontological slot. The explicit doctrine in docs/guides/brain-vs-memory.md:
What makes it special:
- Not just RAG: a full 8-layer knowledge engine for dramatically better memory and recall
- Epistemology layer: tracks “who said what, when, and with what confidence” so no more hallucinated facts or lost context
- Self-wiring knowledge graph: automatically extracts entities and creates real relationships (e.g., “attended,” “works_at,” “invested_in,” “founded”) with zero extra LLM calls
- Dream cycles for autonomous synthesis: runs overnight (or on-demand) so your brain literally gets smarter while you sleep
- Hybrid search done right: combines vector, keyword, RRF fusion, multi-query expansion, cosine reranking, compiled-truth boost, and backlink boost for far more accurate results than plain vector search
- Specialized + versioned chunking: recursive markdown chunker (v4) that intelligently handles code blocks, frontmatter, transcripts, etc. so edits don’t break memory
- Autonomous enrichment + persistent personal memory: tiered enrichment based on how often something is mentioned turning Hermes agent into a “clairvoyant” personal AI that actually knows you
Why pick GBrain over the official 8? If you want a graph cheap, git as system of record, overnight maintenance, you already have a markdown vault (migration covers Obsidian / Logseq / Notion / Roam), or you're building a "company of agents."
Mnemosyne (AxDSan/mnemosyne)
The strongest community alternative when you want a real MemoryProvider plug-in (rather than GBrain, which plays a different role). Runs entirely on your machine - no cloud, no API key, no internet - and recall is fast enough to feel instant (under 2 milliseconds in published tests).
What makes Mnemosyne interesting is its tiered memory architecture, modeled loosely on how humans handle short-term vs long-term memory. There's a "working" tier for what's actively relevant right now, an "episodic" tier for time-stamped events you might want to look up later, and a "scratchpad" for things still being considered for promotion. A consolidation pass runs periodically in the background to move useful items into long-term memory and prune the noise.
The standout feature for serious users: memory has a sense of time. You can ask "what did I believe about X last Tuesday?" and get back the agent's understanding as it was at that point, not as it is today. No other Hermes plug-in does this as cleanly. One soft adoption signal worth noticing: Mnemosyne is the only community memory plug-in that someone has bothered to write a dedicated Hermes skill wrapper for (a small file that teaches the agent how to use it intelligently). Nobody's done that for the others.
Others worth knowing about
- Ladybug Memory - the local-only option with built-in importance ranking. Every memory gets a score from 1 to 10 so the system surfaces the things that matter first instead of treating everything equally. Pick it if you want fully-local memory and the built-in MEMORY.md cap is too small for your knowledge.
- yantrikdb - he one to pick when you need to know why the agent recalled what it did. Every retrieval comes back with a "why retrieved" explanation, which is useful for debugging when the agent surfaces the wrong thing or for high-trust contexts where you need to audit what's shaping the agent's responses. Runs embedded out of the box, no separate database to manage.
- hermes-agentmemory - a community fix for a real Hermes problem: when you tell the agent to forget something, it doesn't actually forget - it keeps an internal summary that quietly influences future recall. This provider does real deletion (gone is gone) and logs every memory operation so you can audit what happened. Pick it if compliance, privacy, or user-controlled forgetting matters.
- PLUR - the cross-agent memory bridge. Hermes memory normally doesn't reach Cursor, and Cursor's doesn't reach Claude Code. PLUR stores everything in a shared .plur/ folder that all of them can read, so a fact you teach one agent automatically shows up in the others. Pick it if you work across multiple agents on the same project and don't want to teach each one separately.
- FlowState-QMD - The "guess what you'll need next" provider. It tries to predict the agent's next likely query and warms up that memory in advance, so by the time the agent actually searches, the result is already cached and responses come back faster. Pick it if your agent does repetitive long-horizon work where the next step is usually guessable from context.
One thing I expected to find that doesn't exist: memory-as-skill is effectively a non-pattern. The agentskills.io standard means a "skill" could in principle implement memory. In practice all credible persistent memory flows through the MemoryProvider ABC. Even skills that "do memory" (the Mnemosyne SKILL.md, for instance) are wrappers around plug-ins, telling the agent how to use them.
## How to actually pick?
Step 1: pick your layer strategy
Step 2: pick your layer 2 system
Warning signs you went too heavy:
- The agent feels noticeably slower. Responses that used to come back in about a second now take 3+ seconds. A heavy memory layer adds work on every turn, and once latency creeps past a few seconds the agent stops feeling responsive.
- Your API bill is creeping up for the same usage. Memory operations consume tokens, and some providers fire extra background LLM calls every time you save something. If your usage patterns haven't changed but your spend has, suspect the memory layer.
- The agent starts contradicting itself. It recalls one version of a fact in one session and the opposite in the next, and can't tell you which is right. This usually means memory is accumulating without ever being consolidated - the agent is now drawing from a polluted well.
- The agent runs out of context mid-conversation. A greedy memory layer eats into the same context budget your actual conversation needs. If you start seeing "context too long" errors, or the agent forgets what you told it five minutes ago, the memory layer is overspending its share.
- Your work isn't actually getting better. This is the one that matters most. You added memory expecting more accurate, more personalized output. After a couple of weeks, can you point at a specific way the agent is genuinely better than before? If you can't, the memory layer isn't earning its complexity. Pull it.
I hope you enjoyed this Hermes Agent deep dive on all things memory. If you want to explore more within the Hermes ecosystem, check out hermesatlas.com and sign up for the Hermes Atlas newsletter to stay up to date on everything.
## 相关链接
- [Kevin Simback](https://x.com/KSimback)
- [@KSimback](https://x.com/KSimback)
- [11K](https://x.com/KSimback/status/2058262328496554021/analytics)
- [hermesatlas.com](https://hermesatlas.com/)
- [hermesatlas.com](https://hermesatlas.com/)
- [Nous Research](https://x.com/NousResearch)
- [where the moats are in agents](https://x.com/compose/articles/edit/2044821377530597376)
- [Honcho (Plastic Labs)](https://hermesatlas.com/projects/plastic-labs/honcho)
- [@offendingcommit](https://x.com/@offendingcommit)
- [Mem0](https://hermesatlas.com/projects/mem0ai/mem0)
- [Hindsight](https://hermesatlas.com/projects/vectorize-io/hindsight)
- [Vectorize.io](https://vectorize.io/)
- [Holographic](https://github.com/NousResearch/hermes-agent/tree/main/plugins/memory/holographic)
- [OpenViking](https://openviking.ai/)
- [RetainDB](https://www.retaindb.com/)
- [ByteRover](https://docs.byterover.dev/autonomous-agents/hermes)
- [Supermemory](https://supermemory.ai/)
- [GBrain](https://hermesatlas.com/projects/garrytan/gbrain)
- [garrytan](https://x.com/garrytan)
- [Mnemosyne](https://hermesatlas.com/projects/AxDSan/mnemosyne)
- [Ladybug Memory](https://github.com/Ladybug-Memory/hermes-memory-plugin)
- [yantrikdb](https://github.com/yantrikos/yantrikdb-hermes-plugin)
- [hermes-agentmemory](https://github.com/MukundaKatta/hermes-agentmemory)
- [PLUR](https://hermesatlas.com/projects/plur-ai/plur)
- [FlowState-QMD](https://github.com/amanning3390/flowstate-qmd)
- [agentskills.io](https://agentskills.io/)
- [hermesatlas.com](https://hermesatlas.com/)
- [newsletter](https://hermesatlas.com/#newsletter)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [3:02 AM · May 24, 2026](https://x.com/KSimback/status/2058262328496554021)
- [11.7K Views](https://x.com/KSimback/status/2058262328496554021/analytics)
---
*导出时间: 2026/5/24 09:01:34*
---
## 中文翻译
# Hermes Agent 记忆指南手册
**作者**: Kevin Simback
**日期**: 2026-05-23T19:02:34.000Z
**来源**: [https://x.com/KSimback/status/2058262328496554021](https://x.com/KSimback/status/2058262328496554021)
---
> TLDR: 这是一份关于 Hermes Agent 记忆系统相关所有内容的终极指南。为什么要写这个？因为每周我都看到新的帖子或文章描述某种针对 Hermes 代理的新记忆工具，这让我怀疑我的记忆设置是否是最好的。所以我深入研究了所有这些工具，并在此为你进行了拆解。
在过去的几个月里，我的 Hermes 代理一直在 hermesatlas.com 上绘制 Hermes 生态系统的图谱。它涵盖的关键领域之一就是记忆，甚至为此专门设立了一个板块。
hermesatlas.com
老实说，现在有太多的相关工具可用，关于它们的文章也铺天盖地。我每周都能在 X 上看到关于某种新记忆设置的新文章。这让人很难跟上节奏，更难知道自己是否做错了，因为它们都声称某种记忆系统比其他的更好。
但许多此类文章跳过了架构部分（即记忆在 Hermes 中如何运作），或者混淆了记忆堆栈的不同元素。这篇文章是关于我所学到的 Hermes Agent 记忆知识的结晶，也是一份帮助你导航的指南，助你找到最适合你的设置方案。
## 记忆可以说是代理设置中最重要的元素
没有记忆，代理只是一个无状态函数，与空白的 ChatGPT 窗口没什么两样。每个提示看起来都像是第一个提示。这适用于一次性提问，但一旦你的用例需要知道昨天发生了什么、记住你的偏好、从先前的任务中积累技能或与另一个代理协调，这种模式就会崩溃。
一个不记得你上周二建立的约定的编码会话，会在本周二重新发明它们。一个不记得你偏好的个人助理代理不得不反复问你同样的问题。没有记忆，代理就根本算不上是代理。
记忆是将聊天机器人变成具有复利能力的东西的关键。这就是为什么每一个严肃的代理框架——OpenClaw、Claude Code、Codex 以及我们备受喜爱的 Hermes——都内置了记忆原语，也是为什么围绕专用记忆基础设施或代理出现了一个真正的产品类别的原因。
Hermes Agent 的观点很有趣，因为 Nous Research 将记忆视为一类插件基础设施，而不是一个功能。有一个始终运行的基础层，一个可插拔的提供商系统，允许你从 8 种架构中选择一种（或者编写你自己的），以及一个健壮的社区插件层。
我将在本文深入探讨这 3 层堆栈。
## Hermes Agent 记忆架构概览
作为 Hermes 用户，每一层对你意味着什么，请看如下说明。
第 1 层（Layer 1） - 开箱即用的内容。无论你做不做任何操作，你都能得到这个。两个小的 Markdown 文件，代理将它们用作始终可见的记事本，外加一个本地数据库，用于存档你曾经进行过的每一个会话。无需设置，无需配置。对于许多用例，这通常就是你所需要的全部。
第 2 层（Layer 2） - 可选的 插件槽。当你超越了原生层（你想要跨会话的语义召回，或者一个能对你的偏好建模的系统，或者大规模的高效检索），你可以从 8 个官方提供商中选择一个。它们对记忆应该做什么有不同的架构赌注，你一次只能运行一个。切换提供商是一个全新的开始——新的提供商不继承旧提供商的数据，但无论如何，第 1 层的原生文件都会在底层继续运行。
第 3 层（Layer 3） - 社区在官方 8 个提供商之外构建的内容。有两种风格。一些社区项目是 MemoryProvider 插件，与第 2 层的选择正面竞争（Mnemosyne 是其中的佼佼者——完全本地化，亚毫秒级，具有真正的分层认知架构）。其他的则处于一个完全不同的插槽中，与官方提供商并存（GBrain 是这里的佼佼者——它将人物、公司和项目等世界事实存储在 Markdown 保管库中，而你的第 2 层提供商处理操作性记忆）。第 3 层通常意味着比官方 8 个提供商更多的设置和更少的打磨，但当你需要这 8 个提供商未提供的能力时，你就要来这里。
这些层是堆叠的，而不是相互替代的。切换第 2 层提供商不会擦除第 1 层。每个提供商都有自己的存储，但原生的会话数据库和两个 Markdown 文件无论如何都会在底层运行。第 3 层插件是叠加在两者之上的附加项。
## 第 1 层：原生层 - 开箱即用的内容
原生层是每个 Hermes 安装附带的三个东西：两个小的 Markdown 文件和一个数据库。它们扮演不同的角色，在我们要了解插件提供商之前，值得逐一理解。
注意：如果你已经了解了开箱即用的设置，或者想跳过你可以安装的可选内容，请直接前往第 2 层。
两个 Markdown 文件
当你安装 Hermes 时，它会在你的主目录 ~/.hermes/ 下创建两个文本文件：
> MEMORY.md - 代理的通用知识笔记本。项目背景、技术决策、值得跨会话记住的事情。限制在约 2,200 个字符，大约一段半。
> USER.md - 代理具体了解你的信息。你的偏好、你的工作风格、你的角色。限制在约 1,375 个字符，大约一段。
你可以在任何文本编辑器中打开这两个文件。它们是纯 Markdown。如果你愿意，你甚至可以手动编辑它们，代理会在下一个会话中读取你的编辑。
它们之所以这么小，是因为它们不是代理的文件柜——它们是代理的便利贴。在每个会话开始时，Hermes 会将这两个文件的全部内容粘贴到发送给模型的提示中。因此，这些文件中的所有内容始终“在代理面前”。不需要检索，它直接就能看到。
代理自己决定将什么放入这些文件。当会话中出现重要事情时——你说“我更喜欢项目符号而不是段落”，或者代理发现你使用 Vercel 进行部署——代理会调用一个名为 memory 的工具，执行三种操作之一：add（添加）、replace（替换）或 remove（移除）。没有 read（读取）操作，因为文件已经粘贴到提示中；代理通过查看自己的上下文来读取它们。
当文件装满时会发生什么？
这是大多数第三方文章弄错的地方。它们声称 Hermes 在达到上限的 80% 时会自动整合文件。我进入 agent/memory_manager.py 的代码进行了验证，实际行为更有趣：
没有自动整合——80% 规则是一个提示指令，而不是代码。系统提示头向代理显示一个实时填充表——类似于“MEMORY: 1,847/2,200 chars (84 percent)”——以及指令“当内存超过 80% 容量时，在添加新条目之前整合现有条目”。代理读取该信息，并决定是否采取行动。如果文件已达到上限，而代理仍试图添加任何内容，memory 工具将返回一个列出当前条目的错误，并强制代理先通过 replace 或 remove 释放空间。
这是一个深思熟虑的设计选择。Nous 信任模型来管理自己的笔记本。好处是完全由代理控制，但坏处也是完全由代理控制。一个提示不当的代理可能会无限期地处于上限状态，拒绝每一次新的添加调用，并悄悄丢失本应替换较旧信息的信息，但我相信这很快就会得到解决，因为已经有一些相关的 PR 在处理这个问题。
在继续之前，值得澄清一个相关的混淆点：v0.12 引入了名为“Autonomous Curator”（自主策展人）的功能，许多文章将其描述为自动内存管理。其实不然。Curator 仅对位于 ~/.hermes/skills/ 的代理技能库进行操作——根据使用情况将技能从活跃变为陈旧，再变为归档。它从不触及 MEMORY.md 或 USER.md。
数据库（及其与 Markdown 文件的关系）
这两个 Markdown 文件是代理始终可见的笔记。数据库是代理对曾经发生的所有事情的完整存档。
Hermes 将每个会话存储在位于 ~/.hermes/hermes_state.db 的 SQLite 数据库文件中。每条用户消息、每条代理响应、每次工具调用、每个推理步骤，以及计费数据（如 token 计数和每次会话的美元成本）——所有东西都存放在这里。默认保留期为 90 天；除非你更改设置，否则较旧的会话每 24 小时自动修剪一次。
这个数据库不会自动注入提示中。它会很庞大——想象一下将你整个聊天历史粘贴到每个新对话中。相反，当代理需要查找特定内容时，它会按需搜索数据库。
搜索使用 SQLite 内置的全文搜索（FTS5），Hermes 维护两个并行索引：一个用于常规单词级搜索（“我们讨论过内容策略吗？”），一个用于处理子字符串和代码 token 的三元组搜索（“找到我提到 github 的每个会话”）。
所以心智模型是：
> 两个 Markdown 文件 = 代理始终记在脑子里的东西。小而精挑细选，始终出现在每个提示中。
> 会话数据库 = 如果代理知道要找什么，就可以查找的东西。庞大而原始，按需搜索。
它们是互补的，而不是多余的。当某些事情对未来所有会话都重要时，代理应该将其写入 MEMORY.md，以便它始终存在。当某些事情可能再次重要但不需要时刻记在心上时，它存在于会话数据库中，仅在代理搜索时才被调出。
数据库设计的一个很好的副作用：因为 Hermes 捕获了每个推理步骤和每次工具调用，并带有完整的计费数据，如果你想导出，该数据库也是一个完整的训练轨迹。这超出了本文的范围，但与我在代理护城河方面的论点是一致的。
## 第 2 层：可插拔的“MemoryProvider”系统
这一层让你从“小笔记本加可搜索存档”毕业到一个真正的记忆系统——一个自动从你的对话中提取事实、构建你的个人资料、支持跨会话的语义召回或处理大型知识图谱的系统。
设置这个非常简单——你运行“hermes memory setup”，从菜单中选择一个提供商，从那时起，除了原生文件之外，代理还有一个更丰富的记忆层可供使用。注意：一些提供商需要 API 密钥和付费计划。
重要的一点是，你一次只能运行一个提供商。Hermes 将此视为一个深思熟虑的选择，而不是一堆附加组件。
这保持了你工具界面的整洁——每个提供商公开自己的一组代理工具，如果有三个相互竞争的“搜索记忆”工具摆在面前，代理会感到困惑——而且这使配置易于推理。无论你是否激活了提供商，第 1 层的原生文件都会在底层继续运行。
选择正确的提供商很重要，因为它们在架构上的赌注非常不同。有些在提取事实方面很激进。有些构建的是你的思维方式模型，而不是你所说的内容。有些痴迷于 token 效率。有些是图优先的。完整的决策树在文章后面；下面的技术机制是针对那些想知道提供商实际连接到什么的读者。
让我们深入探讨。
## 8 个官方提供商
Honcho (Plastic Labs) - AI 原生的辩证用户建模
这是阵容中唯一试图模拟你如何思考的提供商，而不仅仅是记录你说了什么。Honcho 不存储像“Kevin 使用 4 空格缩进”这样平淡的事实，而是在你的对话后运行多步推理过程，以构建你的推理模式、偏好和目标的分析。
该分析随时间演变，因此即使在你从未讨论过的话题上，代理也能更好地预判你的需求。它还允许多个“AI 身份”共享对你的相同看法——如果你为编程、写作和战略运行不同的专家代理，并希望它们都了解你的风格，这非常有用。在 Hermes Discord 中被引用最多的最爱（@offendingcommit：“我都试过了……我简直太爱 Honcho 了。”）。
Mem0 - 最快的 30 秒设置，最广泛的生态系统
“给我记忆，别再问问题”的选择。你注册 Mem0 云，粘贴 API 密钥，就完成了——提供商自动从对话中提取事实，去重，并在后台自动提供语义搜索。
它也是 AWS Strands Agents SDK 的独家内存提供商，这使其在阵容中拥有最广泛的生态系统覆盖范围。2026 年 4 月，Mem0 发布了“v3”算法，声称在基准测试中超越 Hindsight（LongMemEval 上 94.8 分，LoCoMo 上 91.6 分）。
Hindsight (Vectorize.io) - 基准测试之王
第一个在公开场合 LongMemEval 上突破 90 分（91.4 分，2025 年 12 月）的任何类型的记忆系统。Hindsight 将记忆视为四个独立的网络——关于世界的事情、发生的事情、观点和原始观察——并且每次对话只提取少量高价值事实（2 到 5 个，而不是每句一个）。
当你问它问题时，它并行运行四种不同的检索策略——关键词搜索、向量相似度、跨相关实体的图遍历和最近通过——然后融合结果。这就是它在已发布的阵容中获得最佳召回准确率的方法。
它也是唯一提供商，拥有一个让代理对自己的记忆进行推理通过的 reflect（反思）工具。如果你在共享内存库上运行多个代理，并且需要一个协调器来综合所有代理的知识，那么这具有独特的价值。
Holographic - 零依赖，完全本地，气隙隔离
阵容中唯一不需要互联网、API 密钥和 LLM 就能运行的提供商。所有东西都存在于一个本地 SQLite 文件中。它使用一种名为全息简化表示（Holographic Reduced Representations）的 1991 年代技术来对事实进行组合推理——你可以代数地将概念绑定在一起，并在以后探测相关的概念。检索是亚毫秒级的，因为它是纯本地 SQL。
OpenViking - 分层文件系统上下文数据库
你的记忆作为文件存在于磁盘上的目录树中。你可以 cat 它们，grep 它们，手动编辑它们。每条存储的知识有三个加载层级：一句话总结、段落级概述和完整内容。
当代理回忆某事时，它从廉价的开始（仅总结），并且只有在总结看起来相关时才加载更深的层级。如果你在大规模运营中对成本敏感，或者想要可以像普通文件一样阅读和编辑的记忆，该结构很重要。
RetainDB - 最便宜的付费层级，最低阻力
每月 20 美元可进行 100,000 次查询，并提供 10,000 次操作的免费层级进行测试。阵容中唯一在每个价位都是仅限云端的提供商（即使是企业版也不支持自托管）。其卖点是便利性：你不需要运营基础设施，RetainDB 处理一切，并且有一个“内存路由器”模式，可以拦截你的 LLM 调用，并通过一行配置透明地添加内存。
如果你希望在团队成员或代理之间共享内存，并且不想运营数据库，请选择此选项。
ByteRover - 作为 Git 仓库的内存
你的内存是 .brv/context-tree/ 目录中的普通 Markdown 文件——可 grep、可版本控制、无需运行数据库。ByteRover 在其上分层了 5 层检索系统，其中四层不需要 LLM 调用，因此大多数查找在 100 毫秒内完成且零 token 消耗。
关键卖点：你可以将上下文树作为普通代码仓库进行提交、拉取和协作，非常适合团队记忆管理。