Hermes Agent Memory System: Så här fungerar bestående AI-minne

Du vet hur det går till. Du öppnar en chatt med en AI-agent, förklarar ditt projekt, delar dina preferenser, får lite arbete gjort och stänger fliken. När du kommer tillbaka veckan efter är det som att prata med en främling – all kontext är borta, varje preferens är glömd och projektet måste förklaras från scratch.

Detta är inte en bugg. Så här fungerar stora språkmodeller (LLM) per design. De är tillståndslösa: varje förfrågan är oberoende, varje svar genereras utifrån den prompt du skickar just nu, utan minne, utan historik och utan kontinuitet bortom token i den aktuella kontextfönstret.

För interaktioner med en enda tur går det bra. Ställ en fråga, få ett svar, gå vidare. Men för agenter – system som ska göra saker över sessioner, lära sig av misstag och utvecklas tillsammans med dig – är tillståndslöshet ett hårt arkitektoniskt tak. Det är ett av de centrala olösta problemen i självhostade AI-system.

Industrin har försökt lösa detta. LangChain lade till minnesmoduler. OpenAI introducerade assistenter med trådar. Ramverk som Letta, Zep och Cognee byggde hela arkitekturer kring ihållande minne. Databricks publicerade forskning om “memory scaling” – idén att agentens prestanda förbättras med ackumulerad erfarenhet. Dedikerade benchmark-papper, översikter av episodiskt minne och ett snabbt växande ekosystem av verktyg har uppstått sedan 2024 för att adressera det som alltmer erkänns som ett av de centrala olösta problemen inom agentic AI.

De flesta av dessa metoder delar ett gemensamt problem: de behandlar minnet som en eftertanke – en databas du frågar, ett kontextfönster du stoppar fullt, ett hämtningsystem som lägger till latens och brus snarare än tydlighet.

Hermes Agent tar ett fundamentalt annorlunda tillvägagångssätt. Minnet är inte något som agenten hämtar vid behov. Det är något som agenten är hela tiden – inbyggt i systemprompten, kuraterat, begränsat och alltid aktivt. Det är tillräckligt litet för att vara snabbt, tillräckligt strukturerat för att vara användbart och tillräckligt disciplinerat för att veta vad som ska glömmas.

Den här artikeln förklarar exakt hur det fungerar.

Del 1: Problemet med AI-agentens minne

Varför “lägg bara till kontext” inte skalbar för agenter

Den uppenbara lösningen på tillståndslös AI är att lägga till kontext. Bilaga den tidigare konversationen. Inkludera projektets dokumentation. Skicka hela historiken.

Det fungerar en stund. Du har ett kontextfönster på 128K. Du kan få in mycket text där.

Men kontext är inte minne – det finns en verklig och viktig skillnad mellan dem. Kontext är allt du visas just nu; minne är vad du aktivt behåller och bär vidare.

Kontext har ingen kuratering. Det är en dump: när den växer måste modellen processera tusentals token av irrelevant historik för att hitta den ena fakta den behöver. Det kostar token och pengar, ökar latensen och träffar till slut taket.

Minnet är kuraterat. Det är destillationen av erfarenhet till något kompakt och handlingskraftigt. Det växer inte oändligt – det konsoliderar, uppdaterar och glömmer.

Människans minne fungerar på samma sätt. Du minns inte varje konversation du någonsin haft. Du minns delarna som betyder något: vem du pratar med, vad de bryr sig om, vad ni kommit överens om, vad du lärt dig. Resten är antingen glömd eller sökbar när du behöver den.

Forskningslandskapet

Utrymmet för AI-agentminne har exploderat sedan 2024, med dedikerade benchmark-suite, växande forskningslitteratur och en mätbar prestandagap mellan olika arkitektoniska metoder. Här är var läget är.

Letta (tidigare MemGPT) var en av de tidigaste ramverken att behandla ihållande minne som en förstaklassfråga, med 21,7K GitHub-stars. Det använder ett OS-inspirerat tre-nivåmodell: kärnminne (liten, alltid i kontext), återkallningsminne (sökbar konversationshistorik) och arkivminne (långtidskallagring). Insikten att inte allt minne är lika var korrekt. Implementationen kräver dock att agenter körs helt inuti Letta-runtime – att anta det betyder att anta hela plattformen, inte bara ett minneslager.

Zep / Graphiti fokuserar på konversationellt minne med temporell entitetsspårning – fakta bär giltighetsfönster så att grafen vet när något var sant. Det är starkt för chattbotar som behöver relationsgrafer, mindre lämpat för autonoma agenter som spårar miljöfakta och projektkonventioner.

Cognee är byggd för kunskapsutvinning från dokument och strukturerad data, med 30+ inmatningskopplingar och en kunskapsgrafbakände. Det excellerar i institutionell kunskap och RAG-pipelines men är mindre fokuserad på personligt agentminne. Se självhosta Cognee med lokala LLM för en praktisk installationsguide.

Hindsight gör återkallning baserad på kunskapsgraf med entitetsrelationer och ett unikt verktyg reflect som utför korsminnesdestillation – som kombinerar flera minnen till nya insikter. Det är bland de bästa prestandorna på agentminnesbenchmarks och finns tillgängligt som minnesleverantör för Hermes Agent.

Mem0 hanterar minnesutvinning på serversidan via LLM-analys, vilket kräver minimal konfiguration. Mem0-forskningspapperet, publicerat på ECAI 2025 (arXiv:2504.19413), benchmarkade tio distinkta metoder för AI-minne och validerade den selektiva utvinningsmetoden – att lagra diskreta fakta, deduplicera och hämta bara det som är relevant. Mem0 har växt till cirka 48K GitHub-stars och stödjer 21 ramverksintegrationer. Kompromissen är molnberoende och kostnad.

Databricks’ forskning om minnesskalning introducerade konceptet att agentprestanda förbättras med ackumulerad erfarenhet. Deras arkitektur innehåller systemprompter, företagsresurser och episodiskt/semantiskt minne scoped på organisations- och användarnivå, vilket validerar idén att minneskvalitet betyder lika mycket som modellkapacitet.

Den gemensamma tråden i de flesta ramverk är att de behandlar minnet som ett hämtproblem: lagra det någonstans, fråga det vid behov, injicera det i kontexten. Hermes gör det motsatta – minnet hämtas inte på begäran, det injiceras vid sessionsstart och är alltid närvarande. Alltid aktivt, alltid tillgängligt, kuraterat nog för att förbli användbart.

Del 2: Arkitektur — Två filer, en hjärna

Hermes Agents inbyggda minnessystem finns i två filer.

• ~/.hermes/memories/MEMORY.md — Agentens personliga anteckningar (2 200 tecken, ~800 token)
• ~/.hermes/memories/USER.md — Användarprofil (1 375 tecken, ~500 token)

Det är hela den ihållande minnesytan: två filer, under 3 600 tecken totalt, färre än 1 300 token. Det ser avsiktligt litet ut eftersom det är det – och det är exakt designavsikten.

MEMORY.md: Agentens anteckningar

Här sparar agenten allt den lär sig om sin miljö, projektet, verktyg, konventioner och lärdomar. Så här ser det ut:

Användarens projekt är en Go-mikrotjänst vid ~/code/gateway som använder gRPC + PostgreSQL
Denna maskin kör Ubuntu 22.04, har Docker och kubectl installerat
Användaren föredrar snake_case för variabelnamn undviker camelCase

Detta är inte loggar. De är fakta. Täta, deklarativa, informationsmättade. Inga tidsstämplar, inget fluff, inget “den 5 januari frågade användaren mig att…”

USER.md: Användarprofilen

Här sparar agenten allt den vet om dig.

Användaren är en fullstack-utvecklare som är bekväm med TypeScript, Go och Python.
Användaren föredrar snake_case för variabelnamn undviker camelCase.
Användaren använder främst Linux Ubuntu 22.04.
Användaren distribuerar till AWS med Terraform.

Identitet, roll, preferenser, tekniska färdigheter, kommunikationsstil, pet peeves. Det som får agenten att svara annorlunda på dig än på någon annan.

Den frusna snapshot-mönstret

Vid sessionsstart laddas båda filerna från disken och injiceras som en frusen block i systemprompten. Så här ser det ut:

══════════════════════════════════════════════
MINNE (dina personliga anteckningar) [7% — 166/2 200 tecken]

Användarens projekt är en Go-mikrotjänst vid ~/code/gateway som använder gRPC + PostgreSQL § Denna maskin kör Ubuntu 22.04, har Docker och kubectl installerat § Användaren föredrar snake_case för variabelnamn undviker camelCase §

══════════════════════════════════════════════ ANVÄNDARPROFIL (vem användaren är) [8% — 110/1 375 tecken] ══════════════════════════════════════════════ Användaren är en fullstack-utvecklare som är bekväm med TypeScript, Go och Python. § Användaren föredrar snake_case för variabelnamn undviker camelCase. §

Formatet använder rubriker, användningsprocent, teckantal och `§` (sections-tecken) som avgränsare. Poster kan vara flerradiga. Det är designat för att vara parsbart av modellen samtidigt som det förblir läsbart för människor.

Varför fruset? [Prefix caching](https://www.glukhov.org/sv/llm-performance/). Systemprompten är densamma över varje tur i en session. Genom att hålla minnet statiskt efter sessionsstart kan modellen cacha prefixberäkningen och bara processa de variabla delarna – konversationen. Detta är en betydande prestandaoptimering. Du beräknar inte om uppmärksamheten över samma minnes-token vid varje tur.

Ändringar som görs under en session persisteras till disken omedelbart, men de dyker bara upp i systemprompten vid nästa sessionsstart. Verktygs-svar visar alltid den live-status, men modellens "sinne" ändras inte under sessionen. Detta förhindrar att modellen springer efter sin egen svans – uppdatera minnet och sedan reagera på sin egen uppdatering i samma konversation.

### Teckenbegränsningar som en funktion

2 200 tecken. 1 375 tecken. Dessa är inte godtyckliga begränsningar. De är designbegränsningar som tvingar fram kuratering.

Obegränsat minne är en svaghet. Det uppmuntrar till att dumpa allt, aldrig konsolidera och till slut bli brus. Begränsat minne tvingar agenten att vara selektiv. Vad är verkligen viktigt? Vad kommer jag att behöva igen? Vad kan komprimeras utan att förlora betydelse?

När minnet är fullt misslyckas agenten inte bara tyst. Den får ett fel med aktuella poster och användning, och följer sedan ett arbetsflöde:

1. Läs aktuella poster från felresponsen
2. Identifiera poster som kan tas bort eller konsolideras
3. Använd `replace` för att sammanfoga relaterade poster till kortare versioner
4. Lägg till den nya posten

Så här håller minnet sig användbart. Det är inte en databas. Det är en kuraterad samling av fakta som betyder något.

### Säkerhet: Skanning av promptinjektion

Varje minnespost skannas innan den accepteras. Systemet blockerar försök till promptinjektion, utmatning av inloggningsuppgifter, SSH-backdoors och osynliga Unicode-tecken.

Minnet är också deduplicerat. Exakta dubletter avvisas automatiskt. Detta förhindrar att motståndare försöker injicera skadlig kod genom upprepade inlämningar.

---

## Del 3: När minnet avlossas — Triggers och beslut

Den vanligaste frågan om Hermes Agents minne är när det faktiskt sparar något.

Svaret är: ständigt, men selektivt. Agenten hanterar sitt eget minne via verktyget `memory`, och beslutet att spara drivs av en kombination av explicita signaler och implicita mönster.

### Skrivartriggers: När bestämmer agenten sig för att spara?

Agenten sparar minnet proaktivt. Den väntar inte på att du ska be om det. Här är vad som utlöst det.

**Användarkorrigeringar.** När du korrigerar agenten, det är en signal att minnas. "Gör inte så igen." "Använd detta istället." "Kom ihåg detta." Dessa är explicita instruktioner att uppdatera minnet.

Exempel: du ber agenten konfigurera en Python-miljö. Den föreslår `pip`. Du säger "Jag använder `poetry` för allt." Agenten sparar: `Användaren föredrar att använda pakethanteraren 'poetry' för alla Python-projekt.`

**Upptäckta preferenser.** Agenten observerar mönster och infererar preferenser. Om du konsekvent använder ett visst verktyg, ramverk eller arbetsflöde sparas det.

Exempel: efter att ha sett dig använda `poetry` flera gånger över olika projekt, sparar agenten det som en preferens.

**Miljöfakta.** Saker om maskinen, projektet, de verktyg som är installerade. Dessa upptäcks genom utforskning och sparas som fakta.

Exempel: agenten kontrollerar vad som är installerat och sparar: `Denna maskin kör Ubuntu 22.04, har Docker och kubectl installerat.`

**Projekt konventioner.** Hur projektet är strukturerat, vilka verktyg det använder, vilka mönster det följer. Dessa upptäcks genom kodinspektion och sparas.

Exempel: `Användarens projekt är en Go-mikrotjänst vid ~/code/gateway som använder gRPC + PostgreSQL.`

**Slutförda komplexa arbetsflöden.** Efter att ha slutfört en uppgift som tog 5+ verktygsanrop, överväger agenten att spara metodiken som en färdighet eller åtminstone notera vad som fungerade.

**Verktygsnyheter och omgången.** När agenten upptäcker något som inte är självklart om ett verktyg, API eller system – en begränsning, en omgående, en konvention – sparar den det.

**Vad som hoppas över:**

- Trivial eller uppenbar information
- Saker som lätt kan upptäckas igen
- Rå data dumpar
- Sessionspecifika ephemera
- Information som redan finns i kontextfiler (SOUL.md, AGENTS.md)

### Läsutlösare: När minns agenten?

Minnet hämtas inte – det är alltid där. Men det finns olika tillgångsnivåer.

**Sessionsstart (automatiskt).** MEMORY.md och USER.md injiceras i systemprompten. Agenten har dem från första token. Ingen fråga behövs, ingen latens, inget verktygsanrop. Detta är kärnminnet – alltid aktivt.

**`session_search` (på begäran).** När agenten behöver hitta något från tidigare konversationer som inte finns i kärnminnet, använder den verktyget `session_search`. Detta frågar SQLite (`~/.hermes/state.db`) med FTS5 fulltextsökning och Gemini Flash-summering.

Exempel: du frågar "Diskuterade vi Docker-nätverk i förra veckan?" Agenten söker i sessionshistoriken och returnerar en sammanfattning av den relevanta konversationen.

**Externa leverantörsverktyg (när konfigurerat).** När en extern minnesleverantör är aktiv har agenten ytterligare verktyg tillgängliga: `honcho_search`, `hindsight_recall`, `mem0_search` etc. Dessa används när agenten bestämmer att extern kontext behövs.

### Beskedsträdet

Här är hur agenten väger "är detta värt att minnas?":

Är detta en korrigering eller explicit instruktion? JA → Spara till minnet NEJ → Är detta en preferens eller mönster? JA → Spara till användarprofilen NEJ → Är detta en miljöfakta eller konvention? JA → Spara till minnet NEJ → Är detta lätt att upptäcka igen? JA → Hoppa över NEJ → Är detta sessionspecifikt? JA → Hoppa över NEJ → Spara till minnet

Agenten tänker inte för mycket på detta. Den sparar proaktivt, konsoliderar när den är full och litar på teckenbegränsningarna för att hålla saken tight.

---

## Del 4: Internt minne vs. Externa kunskapsbas

Här uppstår ofta förvirring. Hermes Agent har *internt minne* (MEMORY.md, USER.md, externa leverantörer) och *externa kunskapsbas* (LLM Wiki, Obsidian, Notion, ArXiv, filsystem), och de tjänar helt olika roller. Detta liknar skillnaden mellan [retrieval-augmented generation](https://www.glukhov.org/sv/rag/) pipelines och agentens arbetsminne – extern hämtning är bra för djupa kunskapslookup, inte för att bära identitet och preferenser. Internt minne är agentens hjärna – alltid aktivt, kuraterat, bär in i varje session. Externa kunskapsbas är dess bibliotek – omfattande referensresurser som konsulteras på begäran.

### Skillnaden

**Internt minne (hjärnan):**

- Liten, ihållande, injicerad i systemprompten
- Innehåller: användarpreferenser, agentkonventioner, omedelbara lärdomar
- Alltid "i sinnet" under konversationen
- Kuraterat, begränsat, aktivt hanterat
- Exempel: MEMORY.md, USER.md, Honcho, Hindsight, Mem0

**Externa kunskapsbas (biblioteket):**

- Omfattande, endast referens, åtkomst på begäran
- Innehåller: dokument, papper, kod, anteckningar, databaser
- Åtkomst via verktyg när det behövs
- Inte "minns" – hämtas
- Exempel: LLM Wiki, Obsidian, Notion, ArXiv, filsystem, GitHub

### Hur de relaterar

Agenten *åtkommer* externa baser via verktyg när det behövs. Den "minns" dem inte – den hämtar dem.

**LLM Wiki (llm-wiki):** Karpathys sammanlänkade Markdown-kunskapsbas för att bygga och fråga domänkunskap. Agenten använder `llm-wiki`-färdigheten för att läsa, söka och fråga den. Det är en referensresurs, inte minne.

**[Obsidian](https://www.glukhov.org/sv/knowledge-management/tools/obsidian-for-personal-knowledge-management/):** Personliga anteckningsvalv med tvärsidiga länkar. Agenten använder `obsidian`-färdigheten för att läsa, söka och skapa anteckningar. Obsidian är en del av det bredare [personliga kunskapsförvaltning](https://www.glukhov.org/sv/knowledge-management/) ekosystem som Hermes kan ta del av som en biblioteksresurs.

**Notion/Airtable:** Strukturerade databaser och wikis åtkomst via API. Agenten frågar dem när det behövs.

**ArXiv:** Akademiska pappersarkiv. Agenten söker och utvinner papper när den forskar i ett ämne.

**Filsystem:** Projekt kod, dokumentation, konfigurationer. Agenten läser filer när den arbetar med ett projekt.

### Destillationsmönstret

Här är den viktiga insikten: kritiska insikter från externa baser kan *destilleras* in i internt minne.

Exempel: agenten läser ett papper från ArXiv om minnesskalning för AI-agenter. Den sparar inte hela papperet i minnet. Den sparar nyckeltagelsen: `Minnesskalning: agentprestanda förbättras med ackumulerad erfarenhet genom användarinteraktion och affärskontext som sparas i minnet.`

Den externa resursen är enorm. Det interna minnet är destillationen.

### När man ska använda vilket

**Internt minne för:**

- "Vem hjälper jag?"
- "Vad föredrar de?"
- "Vad lärde vi oss just?"
- "Vad är projektuppsättningen?"
- "Vilka verktyg är tillgängliga?"

**Externa kunskapsbas för:**

- "Vad är den senaste forskningen om X?"
- "Vad finns i projektets dokumentation?"
- "Vad diskuterade vi förra månaden?"
- "Vad är API:t för denna tjänst?"
- "Vad är kodstrukturen?"

Agenten förstår skillnaden och använder varje lämpligt – den förväxlar inte att slå upp ett dokument med att minnas något den har lärt sig om dig och din miljö.

---

## Del 5: Hur det egentligen fungerar

Låt oss titta på mekaniken.

### Verktyget `memory`

Agenten hanterar minnet genom ett enda verktyg med tre åtgärder: `add`, `replace`, `remove`.

Det finns ingen `read`-åtgärd – minnesinnehåll injiceras automatiskt i systemprompten. Agenten behöver inte läsa det eftersom det alltid finns där.

**`add`** — Lägger till en ny post.

```python
memory(action="add", target="memory",
       content="Användaren kör macOS 14 Sonoma, använder Homebrew, har Docker Desktop installerat.")

replace — Ersätter en befintlig post med hjälp av delsträngsmatchning.

memory(action="replace", target="memory",
       old_text="dark mode",
       content="Användaren föredrar light mode i VS Code, dark mode i terminalen")

remove — Tar bort en post med hjälp av delsträngsmatchning.

memory(action="remove", target="memory",
       old_text="temporary project fact")

Delsträngsmatchning

replace och remove använder korta unika delsträngar via old_text. Du behöver inte hela posttexten. Detta möjliggör kirurgiska redigeringar utan att känna till exakt innehåll.

Om en delsträng matchar flera poster returneras ett fel som begär en mer specifik matchning. Agenten förfinar sedan sin fråga.

Målbehållare: memory vs user

Parametern target bestämmer vilken fil som uppdateras.

• memory — Agentens personliga anteckningar. Miljöfakta, projekt konventioner, verktygsnyheter, lärdomar.
• user — Användarprofil. Identitet, roll, tidszon, kommunikationspreferenser, pet peeves, arbetsflödeshabiter.

Kapacitetsstyrning

När minnet är >80% fullt konsoliderar agenten. Den sammanfogar relaterade poster, tar bort utdaterade fakta och komprimerar information.

Bra minnesposter är kompakta och informationsmättade:

Användaren kör macOS 14 Sonoma, använder Homebrew, har Docker Desktop installerat. Skalk: zsh med oh-my-zsh. Redigerare: Neovim med Telescope-plugin.

Dåliga minnesposter är vaga eller verbosa:

Användaren har ett projekt.
Den 5 januari 2026 bad användaren mig att titta på deras projekt som finns på ~/code/gateway och det använder Go med gRPC och PostgreSQL för databaslager.

Den första är tät och användbar. Den andra är antingen för vag eller för verbose.

Sessionsökning vs. Ihållande minne

session_search och ihållande minne tjänar olika syften.

Tumregel: använd minne för kritiska fakta som alltid ska vara i kontexten. Använd sessionsökning för historiska lookup.

Del 6: Externa minnesleverantörer — Alla 8 alternativ jämförda

Utöver de inbyggda filerna MEMORY.md och USER.md stöder Hermes Agent 8 externa minnesleverantörsplugin för ihållande, över-session kunskap.

Endast en extern leverantör kan vara aktiv på en gång. De inbyggda filerna är alltid aktiva tillsammans med den externa leverantören – additiv, inte ersättning.

Aktivering

hermes memory setup   # Interaktiv plockare + konfiguration
hermes memory status  # Kontrollera vad som är aktivt
hermes memory off     # Inaktivera extern leverantör

Eller manuellt i ~/.hermes/config.yaml:

memory:
  provider: openviking  # eller honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory

Leverantörsjämförelse

Detaljerad uppdelning

Honcho

Bäst för: multi-agent-system, kontext över sessioner, användar-agent-justering.

Honcho körs parallellt med befintligt minne – USER.md förblir som det är, och Honcho lägger till ett ytterligare kontextlager. Det modellerar konversationer som jämlikar som utbyter meddelanden – en användarpeer plus en AI-peer per Hermes-profil, alla delar ett arbetsområde.

Verktyg: honcho_profile (läs/uppdatera peerkort), honcho_search (semantisk sökning), honcho_context (sessionskontext – sammanfattning, representation, kort, meddelanden), honcho_reasoning (LLM-syntetiserad), honcho_conclude (skapa/radera slutsatser).

Viktiga konfigurationsreglage:

• contextCadence (standard 1): Minsta antal turer mellan baslageruppdatering
• dialecticCadence (standard 2): Minsta antal turer mellan peer.chat() LLM-anrop (1-5 rekommenderas)
• dialecticDepth (standard 1): .chat() pass per anrop (klemat 1-3)
• recallMode (standard ‘hybrid’): hybrid (auto+verktyg), context (endast injicera), tools (endast verktyg)
• writeFrequency (standard ‘async’): Flush-timing: async, turn, session, eller heltal N
• observationMode (standard ‘directional’): directional (alla på) eller unified (delad pool)

Arkitektur: Två-lagers kontextinjektion – baslager (sessionsammanfattning + representation + peerkort) + dialektiskt supplement (LLM-resonemang). Väljer automatiskt kallstart vs varma prompter.

Multi-peer-kartläggning: Arbetsområdet är en delad miljö över profiler. Användarpeer (peerName) är en global mänsklig identitet. AI-peer (aiPeer) är en per Hermes-profil (hermes standard, hermes.<profil> för andra).

Installering:

hermes memory setup  # välj "honcho"
# eller legacy: hermes honcho setup

Konfiguration: $HERMES_HOME/honcho.json (profil-lokal) eller ~/.honcho/config.json (global).

Profilhantering:

hermes profile create coder --clone  # Skapar hermes.coder med delat arbetsområde
hermes honcho sync                   # Backfills AI-peers för befintliga profiler

OpenViking

Bäst för: självhostad kunskapsförvaltning med strukturerad bläddring.

OpenViking ger en filhierarki med nivålastning. Det är gratis, självhostad, och ger dig full kontroll över din minneslagring.

Verktyg: viking_search, viking_read (nivå), viking_browse, viking_remember, viking_add_resource.

Installering:

pip install openviking
openviking-server
hermes memory setup  # välj "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Bäst för: hands-free minnesförvaltning med automatisk utvinning.

Mem0 hanterar minnesutvinning på serversidan. Du konfigurerar ingenting – det fungerar bara. Kompromissen: molnberoende och kostnad.

Verktyg: mem0_profile, mem0_search, mem0_conclude.

Installering:

pip install mem0ai
hermes memory setup  # välj "mem0"
echo "MEM0_API_KEY=din-nyckel" >> ~/.hermes/.env

Konfiguration: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).

Hindsight

Bäst för: kunskapsgrafbaserad återkallning med entitetsrelationer.

Hindsight bygger en kunskapsgraf av ditt minne, och utvinner entiteter och relationer. Dess unika verktyg reflect utför korsminnesdestillation – som kombinerar flera minnen till nya insikter.

Verktyg: hindsight_retain, hindsight_recall, hindsight_reflect (unik korsminnesdestillation).

Installering:

hermes memory setup  # välj "hindsight"
echo "HINDSIGHT_API_KEY=din-nyckel" >> ~/.hermes/.env

Auto-installerar hindsight-client (moln) eller hindsight-all (lokal). Kräver >= 0.4.22.

Konfiguration: $HERMES_HOME/hindsight/config.json

• mode: cloud eller local
• recall_budget: low / mid / high
• memory_mode: hybrid / context / tools
• auto_retain / auto_recall: true (standard)

Lokal UI: hindsight-embed -p hermes ui start

Holographic

Bäst för: integritetsfokuserade uppställningar med endast lokal lagring.

Holographic använder HRR (Holographic Reduced Representation) algebra för minneskodning, med tillitsscore för minnespålitlighet. Inget molnberoende – allt körs lokalt på din egen hårdvara.

Verktyg: 2 verktyg för minnesoperationer via HRR-algebra.

Installering:

hermes memory setup  # välj "holographic"

Inga beroenden. Allt körs lokalt.

RetainDB

Bäst för: högfrekventa uppdateringar med deltakomprimering.

RetainDB använder deltakomprimering för att effektivt lagra minnesuppdateringar. Det är molnbaserat med en kostnad på $20/månad, men komprimeringen betyder mindre datatransfer och snabbare uppdateringar.

Verktyg: retaindb_profile (användarprofil), retaindb_search (semantisk sökning), retaindb_context (uppgiftsrelevant kontext), retaindb_remember (lagring med typ + viktighet), retaindb_forget (radera minnen).

Installering:

hermes memory setup  # välj "retaindb"

ByteRover

Bäst för: bandbredds begränsade miljöer med förkomprimeringsutvinning.

ByteRover komprimerar minnet före utvinning, vilket minskar bandbreddsanvändningen. Tillgängligt i lokala eller molnlägen.

Verktyg: 3 verktyg för minnesoperationer.

Installering:

hermes memory setup  # välj "byterover"

Supermemory

Bäst för: företagsarbetsflöden med kontextfänsning och sessionsgrafingång.

Supermemory tillhandahåller kontextfänsning (isolering av minne efter kontext) och sessionsgrafingång (importera hela konversationshistoriker). Det är molnbaserat och betalt, men designat för företagskala minnesförvaltning.

Verktyg: 4 verktyg för minnesoperationer.

Installering:

hermes memory setup  # välj "supermemory"

Hur man väljer

• Behöver multi-agent-stöd? Honcho
• Vill ha självhostat och gratis? OpenViking eller Holographic
• Vill ha noll-konfiguration? Mem0
• Vill ha kunskapsgrafer? Hindsight
• Vill ha deltakomprimering? RetainDB
• Vill ha bandbreddseffektivitet? ByteRover
• Vill ha företagsfunktioner? Supermemory
• Vill ha integritet (endast lokal)? Holographic

För fullständig profil-för-profil leverantörs konfigurationer och verkliga arbetsflödesmönster, se Hermes Agent produktionsuppställning.

Del 7: Filosofin

Varför begränsat minne slår obegränsat minne

Instinkten är att göra minnet så stort som möjligt. Lagra allt. Hämta vad du behöver.

Begränsat minne fungerar bättre. Här är varför.

Kuratering tvingar fram kvalitet. När du har begränsat utrymme sparar du bara det som betyder något. Du komprimerar, konsoliderar och prioriterar. Obegränsat minne uppmuntrar till att dumpa allt och aldrig städa upp.

Hastighet betyder något. 1 300 token i systemprompten är snabbt. 100 000 token hämtade från en databas är långsamt. Minne ska vara omedelbart, inte en fråga.

Brus försämrar prestanda. Mer minne är inte bättre minne. Det är brusigare minne. Modellen måste skilja signal från brus, och det tar uppmärksamhet – uppmärksamhet som bör spenderas på den faktiska uppgiften.

Att glömma är en funktion. Mänskligt minne glömmer. Det är inte en bugg – det är hur vi prioriterar. Agenter bör också glömma. Inte allt förtjänar att minnas.

Problemet med “att glömma”

Agenter behöver lära sig bort. Inte bara glömma, utan aktivt ta bort utdaterad information.

Här är hur Hermes Agent hanterar det:

• remove-åtgärd: Radera poster som inte längre är relevanta.
• replace-åtgärd: Uppdatera poster med ny information.
• Kapacitetspress: När minnet är fullt konsoliderar agenten och tar bort gamla poster.
• Säkerhetsskanning: Blockerar skadliga eller korrupta poster.

Att glömma är inte misslyckande – det är underhåll. En agent som inte kan lära sig bort kommer till slut att bära lika mycket brus som signal.

Minnesskalning

Databricks introducerade konceptet “minnesskalning”: fungerar en agent med tusentals användare bättre än en med en enda användare?

Deras forskning tyder på ja, men med förbehåll. Minnesskalning kräver:

1. Kvalitativ utvinning: Inte alla interaktioner är värda att minnas. Agenten måste utvinna insikter, inte loggar.
2. Effektiv hämtning: Hämtade minnen måste vara relevanta. Brus försämrar prestanda.
3. Generalisering: Minnen ska vara mönster, inte specifikationer. “Användaren föredrar Python” skalbar. “Användaren körde kommando X vid tidsstämpel Y” gör det inte.

Hermes Agents begränsade minne stöder naturligt minnesskalning. Genom att tvinga fram kuratering säkerställer den att minnen är generaliserbara, kompakta och användbara.

Vad detta betyder för framtiden

Minne blir den konkurrensfördel i agentic AI – inte modellen själv, utan vad modellen bär mellan sessioner. Två agenter med identiska underliggande modeller kan prestera mycket olika: den ena minns dina preferenser, din miljö och dina tidigare misstag; den andra startar kall varje gång.

Frågan är inte längre om agenter ska ha ihållande minne. Det är avgjort: de måste. Den öppna frågan är hur man designar det minnet bra – vad man ska behålla, vad man ska kasta, hur man gör det omedelbart och hur man förhindrar att det blir brus.

Hermes Agents svar är att hålla minnet litet, kuraterat och alltid aktivt – inte en databas man frågar, utan en arbetsmodell av användaren som agenten bär med sig in i varje konversation.

Slutsats

Hermes Agents minnessystem är avsiktligt enkelt: två filer, hårda teckenbegränsningar, ingen hämtpipeline, ingen vektordatabas och ingen per-fråga latens. Det som låter som en begränsning är hela poängen.

Det fungerar eftersom det behandlar minnet som en hjärna fungerar snarare än som en databas gör – liten, kuraterad och alltid aktiv. Agenten hämtar inte minnet när den behöver det; minnet är helt enkelt alltid där, vävt in i systemprompten från första token i varje session.

Externa minnesleverantörer utvidgar detta system för användare som behöver mer: kunskapsgrafer, multi-agent-stöd, självhostad lagring, företagsfunktioner. Men kärnan förblir densamma: begränsad, kuraterad, alltid tillgänglig.

Och externa kunskapsbas – LLM Wiki, Obsidian, Notion, ArXiv – tjänar en annan roll. De är biblioteket, inte hjärnan. Agenten slå upp dem, minns dem inte. Kritiska insikter destilleras in i internt minne; resten stannar i biblioteket.

Så här kommer en AI-agent att minnas dig. Inte genom att lagra allt, utan genom att minnas det som betyder något.

Hermes Agent släpptes av Nous Research i februari 2026 och nådde över 64 000 GitHub-stars i april 2026 (v0.9.0), med 242+ bidragare. Det är open-source och tillgängligt på github.com/NousResearch/hermes-agent. För installation, konfiguration och arbetsflödesguider, se Hermes Agent översikt.