The Hermes Agent Memory Guidebook

✍ Kevin Simback🕐 2026-05-28📦 27.2 KB 🟢 已读 𝕏 文章列表

这是一份关于 Hermes Agent 记忆系统的终极指南。文章深入解析了 Hermes 的三层记忆架构：开箱即用的原生层、可选的插件层以及社区扩展层。作者详细说明了本地数据库与 Markdown 文件的协同工作机制，澄清了关于记忆合并的常见误区，并强调了记忆在 Agent 从无状态聊天机器人转变为具备技能累积和个性化能力的智能体过程中的关键作用。

# 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) --- ![Image](/doc/2305/image/img_87de4e7470ed.jpg) > 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. ![Image](/doc/2305/image/img_ebc7c9b87271.jpg) 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 ![Image](/doc/2305/image/img_6c0135b11788.jpg) 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 ![Image](/doc/2305/image/img_c796da1b02a4.jpg) ## 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 ![Image](/doc/2305/image/img_252075a76b6c.jpg) Step 2: pick your layer 2 system ![Image](/doc/2305/image/img_1d17007bb9a4.jpg) 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) - [77K](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) - [77.7K Views](https://x.com/KSimback/status/2058262328496554021/analytics) - [View quotes](https://x.com/KSimback/status/2058262328496554021/quotes) --- *导出时间: 2026/5/28 19:34:29* --- ## 中文翻译 # Hermes Agent 指南手册 **作者**: Kevin Simback **日期**: 2026-05-23T19:02:34.000Z **来源**: [https://x.com/KSimback/status/2058262328496554021](https://x.com/KSimback/status/2058262328496554021) --- ![Image](/doc/2305/image/img_87de4e7470ed.jpg) > 长话短说：这是关于 Hermes Agent 内存系统所有内容的权威指南。为什么要写这个？因为每周我都会看到新的帖子或文章描述某种新的 Hermes Agent 内存工具，这让我怀疑我目前的内存设置是否是最佳的。所以我深入研究了所有这些工具，并为你把它们拆解分析了一遍。在过去几个月里，我的 Hermes Agent 一直在 hermesatlas.com 上绘制 Hermes 生态系统图谱。它涵盖的关键领域之一就是内存，甚至为此设立了专门的版块。 ![Image](/doc/2305/image/img_ebc7c9b87271.jpg) hermesatlas.com 老实说，目前有大量的相关工具可供选择，也有大量的相关文章介绍。我每周都会在 X 上看到关于某种新内存设置的新文章。很难跟上步伐，更难知道你是否做错了，因为它们都声称某种内存系统比其他的更好。但许多这类文章要么跳过了架构（即内存在 Hermes 中如何工作），要么混淆了内存堆栈的不同元素。这篇文章总结了我在 Hermes Agent 内存方面学到的所有知识，并作为一个指南，帮助你找到最适合你的设置方案。 ## 内存可以说是 Agent 设置中最重要的元素没有内存，Agent 只是一个无状态的函数，与空白的 ChatGPT 窗口没什么两样。每一个提示词看起来都像是第一个提示词。这适用于一次性问答，但一旦你的用例需要知道昨天发生了什么、记住你的偏好、从之前的任务中积累技能，或者与另一个 Agent 协调，这种方式就会失效。一个不记得你上周二建立的编码约定的编码会话，会在本周二重新发明一遍它们。一个不记得你偏好的个人助理 Agent 会不得不反复问你同样的问题。没有内存，Agent 就根本不成其为 Agent。正是内存将聊天机器人变成了能够自我叠加成长的工具。这就是为什么每一个严肃的 Agent 框架——OpenClaw、Claude Code、Codex 以及我们喜爱的 Hermes——都内置了内存原语，也是为什么围绕专用内存基础设施或 Agent 形成了一个真正的产品类别（Mem0 融资了 2400 万美元，Letta 融资了 1000 万美元，还有 Zep、Cipher、Supermemory、Hindsight 等等）。 Hermes Agent 的视角很有趣，因为 Nous Research 将内存视为一等插件基础设施，而不是一个功能。它有一个始终运行的基础层，一个可插拔的提供者系统（让你从 8 种架构中选择一种或编写你自己的），以及顶层一个健康的社区插件层。这三层堆栈就是我将在本文中深入探讨的内容。 ## Hermes Agent 内存架构概览 ![Image](/doc/2305/image/img_6c0135b11788.jpg) 以下是每一层对你作为 Hermes 用户的意义。 **第 1 层 - 开箱即用**。无论你是否进行任何设置，你都会获得这一层。两个小的 Markdown 文件，Agent 将其用作始终可见的笔记本，以及一个本地数据库，用于存档你曾经进行过的每一个会话。无需设置，无需配置。对于许多用例，这通常就是你所需的全部。 **第 2 层 - 可选的插件槽位**。当你超越了原生层（你需要跨会话的语义回忆，或一个能对你的偏好进行建模的系统，或是大规模的、Token 高效的检索）时，你可以从 8 种官方提供者中选择一种。它们对内存应该做什么有不同的架构赌注，你一次只能运行一个。切换提供者意味着一个全新的开始——新的提供者不会继承旧提供者的数据，但无论如何，第 1 层的原生文件都会在底层继续运行。 **第 3 层 - 社区在官方 8 种之外构建的内容**。有两种类型。一些社区项目是与第 2 层选择正面竞争的 MemoryProvider 插件（Mnemosyne 是其中的佼佼者——完全本地化，亚毫秒级，拥有真正的分层认知架构）。其他的则完全位于不同的槽位，与官方提供者并存（GBrain 是这里的典型代表——它在 Markdown 库中存储世界事实，如人物、公司和项目，而你的第 2 层提供者处理操作性内存）。第 3 层通常意味着比官方 8 种更多的设置和更少的打磨，但当你需要这 8 种提供者不具备的能力时，这就是你要去的地方。这些层是堆叠而不是相互替换的。切换第 2 层提供者不会擦除第 1 层。每个提供者都有自己的存储，但原生会话数据库和两个 Markdown 文件无论如何都会在底层继续运行。第 3 层插件是叠加在两者之上的附加组件。 ## 第 1 层：原生层——开箱即用的部分原生层是每个 Hermes 安装包中自带的三个东西：两个小的 Markdown 文件和一个数据库。它们扮演不同的角色，在我们进入插件提供者之前，值得理解每一个。注意：如果你已经了解了开箱即用的设置，或者想跳过这部分，直接去看你可以安装的可选内容，请跳转到第 2 层。 **两个 Markdown 文件** 当你安装 Hermes 时，它会在你的主目录 `~/.hermes/` 下创建两个文本文件： > MEMORY.md - Agent 的通用知识笔记本。项目背景、技术决策、值得跨会话记住的事情。上限约为 2,200 个字符，大约一段半。 > USER.md - Agent 对你的具体了解。你的偏好、你的工作风格、你的角色。上限约为 1,375 个字符，大约一段。你可以在任何文本编辑器中打开这两个文件。它们是纯 Markdown 格式。如果你愿意，你甚至可以手动编辑它们，Agent 会在下一次会话中读取你的编辑。它们之所以这么小，是因为它们不是 Agent 的档案柜——它们是 Agent 的便利贴。在每次会话开始时，Hermes 会将这两个文件的全部内容粘贴到发送给模型的提示词中。因此，这些文件中的所有内容始终“在 Agent 面前”。无需检索，它直接就能看到。 Agent 自己决定往这些文件里放什么。当会话中出现重要事情时——比如你说“我更喜欢要点而不是段落”，或者 Agent 发现你使用 Vercel 进行部署——Agent 会调用一个名为 `memory` 的工具，执行三个操作之一：`add`（添加）、`replace`（替换）或 `remove`（删除）。没有 `read`（读取）操作，因为文件已经粘贴到提示词中了；Agent 通过查看自己的上下文来读取它们。 **当文件装满时会发生什么？** 这是大多数第三方文章弄错的地方。它们声称 Hermes 会在文件达到上限的 80% 时自动合并文件。我深入查看了 `agent/memory_manager.py` 中的代码来验证，实际行为更有趣：没有自动合并——80% 规则是一个提示指令，而不是代码。系统提示标题向 Agent 显示一个实时填充量表——类似于“MEMORY: 1,847/2,200 chars (84 percent)”——以及指令“when memory is above 80% capacity, consolidate entries before adding new ones.”（当内存超过 80% 容量时，在添加新条目之前合并条目）。Agent 读取该指令，然后由 Agent 决定是否采取行动。如果文件已经达到上限，而 Agent 仍然尝试添加任何内容，内存工具将返回一个错误，列出当前条目，并强制 Agent 先通过 `replace` 或 `remove` 释放空间。这是一个深思熟虑的设计选择。Nous 信任模型来管理自己的笔记本。好处是 Agent 拥有完全的控制权，但坏处也是 Agent 拥有完全的控制权。一个提示不当的 Agent 可能会无限期地停留在上限状态，拒绝每一个新的添加调用，并悄悄丢失本应替换旧内容的信息，但我相信这个问题很快会得到解决，因为已经有一些相关的 PR 正在处理这个问题。在我们继续之前，值得澄清另一个相关的困惑点：v0.12 引入了名为“Autonomous Curator”（自主策展人）的功能，许多文章将其描述为自动内存管理。其实不是。Curator 仅对 Agent 位于 `~/.hermes/skills/` 的技能库进行操作——根据使用情况将技能从活动变为陈旧再到存档。它永远不会触及 MEMORY.md 或 USER.md。 **数据库（及其与 Markdown 文件的关系）** 这两个 Markdown 文件是 Agent 始终可见的笔记。数据库是 Agent 对所有曾经发生过的事情的完整存档。 Hermes 将每个会话存储在 `~/.hermes/hermes_state.db` 的 SQLite 数据库文件中。每一条用户消息、每一条 Agent 回复、每一次工具调用、每一个推理步骤，以及像 Token 计数和每次会话的美元成本这样的经济数据——所有这些都保存在这里。默认保留期为 90 天；除非你更改设置，否则较旧的会话每 24 小时会自动修剪一次。这个数据库不会自动注入到提示词中。它太庞大了——想象一下把你整个聊天历史粘贴到每个新对话中。相反，当 Agent 需要找到特定内容时，它会按需搜索该数据库。搜索使用 SQLite 内置的全文搜索（FTS5），Hermes 维护两个并行索引：一个用于常规词级搜索（“我们讨论过内容策略吗？”），一个用于处理子字符串和代码 Token 的 Trigram 搜索（“找到我提到 github 的每个会话”）。所以心智模型应该是： > 两个 Markdown 文件 = Agent 脑海里始终有的东西。小巧、精心策划、存在于每个提示词中。 > 会话数据库 = 如果 Agent 知道要查找什么，可以查阅的内容。庞大、原始、按需搜索。它们是互补的，而不是冗余的。当某事对所有未来的会话都很重要时，Agent 应该将其写入 MEMORY.md，以便始终存在。当某事可能再次重要但不需要牢记时，它位于会话数据库中，并仅在 Agent 搜索时才会被提取。数据库设计的一个不错的副作用：因为 Hermes 捕获了每个推理步骤和每次工具调用，并包含完整的经济数据，如果你想导出的话，这个数据库也是一个完整的训练轨迹。这超出了本文的范围，但与我关于 Agent 护城河在哪里的论点是一致的。 ## 第 2 层：可插拔的 “MemoryProvider” 系统这是让你从“小笔记本加可搜索存档”升级到真正的内存系统的层——一个能自动从你的对话中提取事实、为你建立档案、支持跨会话语义回忆或处理大型知识图的系统。设置这个非常简单——你运行 `hermes memory setup`，从菜单中选择一个提供者，从那时起，Agent 除了原生文件之外，还有一个更丰富的内存层可供使用。注意：一些提供者需要 API 密钥和付费计划。重要的一点是，你一次只能运行一个提供者。Hermes 将此视为一个单一的有意识的选择，而不是一堆额外的附加组件。这保持了你工具界面的整洁——每个提供者都公开自己的一组 Agent 工具，如果有三个竞争的“搜索内存”工具摆在它面前，Agent 会感到困惑——这也让配置变得容易理解。无论你是否激活了提供者，第 1 层的原生文件都会在底层继续运行。选择正确的提供者很重要，因为它们在架构上有着非常不同的赌注。有些在提取事实方面很激进。有些建立的是你思维方式而非你所说的内容的模型。有些痴迷于 Token 效率。有些是图优先的。完整的决策树在文章后面；下面的技术机制是给那些想知道提供者到底接入了什么的读者看的。让我们深入了解一下。 ## 8 种官方提供者 **Honcho (Plastic Labs) - AI 原生辩证用户建模** 阵容中唯一一个试图模拟你如何思考，而不仅仅是你说什么的提供者。Honcho 不存储像“Kevin 使用 4 空格缩进”这样的扁平事实，而是在你的对话结束后运行一个多步推理过程，以构建你的推理模式、偏好和目标的档案。该档案会随时间演变，因此即使在你从未讨论过的话题上，Agent 也能更好地预判你的需求。它还允许多个“AI 身份”共享对你的同一看法——如果你为编码、写作和战略运行不同的专业 Agent，并希望所有这些 Agent 都知道你的风格，这就很有用。在 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”工具的提供者，允许 Agent 对自己的内存运行推理过程。如果你在共享内存库上运行多个 Agent，并且需要一个协调器来综合所有 Agent 知道的内容，那么这具有独特的价值。 **Holographic - 零依赖，完全本地，物理隔离** 阵容中唯一不需要互联网、API 密钥或 LLM 就能运行的提供者。所有内容都存在于一个本地 SQLite 文件中。它使用一种 1991 年代的技术，称为全息简化表示（Holographic Reduced Representations），对事实进行组合推理——你可以代数地将概念绑定在一起，并在以后探测相关概念。检索是亚毫秒级的，因为是纯本地 SQL。 **OpenViking - 分层文件系统上下文数据库** 你的内存作为磁盘上目录树中的文件存在。你可以 cat 它们，grep 它们，手动编辑它们。每条存储的知识有三个加载层级：一句话摘要、段落级概览和完整内容。当 Agent 回忆某事时，它从廉价的层级开始（仅摘要），并且只有在摘要看起来相关时才加载更深的层级。如果你在大规模场景下对成本敏感，或者想要可以像普通文件一样阅读和编辑的内存，这种结构很重要。 **RetainDB - 最便宜的付费层级，最低阻力** 每月 20 美元可进行 100,000 次查询，并有 10,000 次操作的免费层级用于测试。阵容中唯一在每个价格点都仅限云端的提供者（即使在企业版也不能自托管）。其卖点是便利：你无需运营基础设施，RetainDB 处理一切，并且有一个“Memory Router”模式可以拦截你的 LLM 调用，只需一行配置即可透明地添加内存。如果你想要跨团队成员或 Agent 的共享内存，并且不想运营数据库，请选择此选项。 **ByteRover - 内存即 Git 仓库** 你的内存是 `.brv/context-tree/` 目录中的纯 Markdown 文件——可用 grep 搜索、可进行版本控制、无需运行数据库。ByteRover 在此之上分层了 5 层检索系统，其中四层不需要 LLM 调用，因此大多数查找在 100 毫秒内完成且零 Token 消耗。关键卖点：你可以 c

🔗 相关文档