Hermes Agentminnessystem: Så fungerar bestående AI-minne i praktiken

Du känner igen mönstret. Du öppnar en chatt med en AI-assistent, 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 ingen bugg. Det är så stora språkmodeller (LLM) fungerar enligt 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 det aktuella kontextfönstret.

För engångsinteraktioner fungerar 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 en hård arkitektonisk gräns. Det är ett av de centrala, olösta problemen inom självhärbärgade AI-system.

Branschen har försökt lösa detta. LangChain lade till minnesmoduler. OpenAI införde assistenter med trådar. Ramverk som Letta, Zep och Cognee byggde hela arkitekturer kring ihållande minne. Databricks publicerade om “memory scaling” — idén att agentens prestanda förbättras med ackumulerad erfarenhet. Sedan 2024 har dedikerade benchmarkrapporter, översikter över episodiskt minne och ett snabbt växande ekosystem av verktyg dykt upp för att adressera det som alltmer erkänns som ett av de centrala olösta problemen inom agens-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 klarhet.

Hermes Agent tar ett fundamentalt annorlunda tillvägagångssätt. Minne är inte något som agenten hämtar vid behov. Det är något som agenten är vid alla tillfällen — 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 — det Hermes-specifika lagret i den tvärramverksmodellen i Minnesystem för AI-assistenter och den bredare stacken i AI-assistentarkitektur. För aktiverings- och inspektionskommandon (hermes memory, hermes dump, loggtailning), kombinera det med Hermes Agent CLI-snabbguide. För den komplementära sidan av Hermess “långsiktiga kunskap” — återanvändbara procedurer i SKILL.md snarare än kuraterade minnesfiler — se Hermes Agent-färdighetsutveckling — Struktur och bästa praxis för SKILL.md.

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. Bifoga den tidigare konversationen. Inkludera projekt dokumentationen. Skicka hela historiken.

En stund fungerar det. 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 det du aktivt behåller och tar med dig framåt.

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

Minne är kuraterat. Det är destillationen av erfarenhet till något kompakt och handlingskraftigt. Det växer inte oändligt — det konsolideras, uppdateras 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 bortglömd eller sökbar när du behöver det.

Forskingslandskapet

AI-agentens minnesområde har exploderat sedan 2024, med dedikerade benchmarksviter, en växande forskningslitteratur och en mätbar prestandaklyfta mellan olika arkitektoniska tilvägagångssätt. Här är läget.

Letta (tidigare MemGPT) var ett av de första ramverken som behandlade ihållande minne som en förstaklassfråga, med 21,7K GitHub-stjärnor. Det använder en OS-inspirerad tre-nivåmodell: kärnminne (litet, alltid i kontext), påminnelseminne (sökbar konversationshistorik) och arkivminne (långsiktig kall lagring). Insikten att inte allt minne är lika var korrekt. Implementeringen kräver dock att agenter körs helt inne i Letta-runtime — att adoptera det innebär att adoptera hela plattformen, inte bara ett minneslager.

Zep / Graphiti fokuserar på konversationsminne 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 projektstandarder.

Cognee är byggt för kunskapsutvinning från dokument och strukturerad data, med 30+ inmatningskopplingar och en kunskapsgraf som backend. Det excellerar i institutionell kunskap och RAG-pipelines men är mindre fokuserat på personligt agentminne. Se självhärbärgad Cognee med lokala LLM för en praktisk installationsguide.

Hindsight gör kunskapsgrafbaserad återkallelse med entitetsrelationer och ett unikt reflect-syntesverktyg som utför tvärsminnessyntes — kombinerar flera minnen till nya insikter. Det ligger bland de bästa prestandorna på agentminnesbenchmarks och finns tillgängligt som minnesleverantör för Hermes Agent.

Mem0 hanterar minnesutvinning serverbaserat via LLM-analys, vilket kräver minimal konfiguration. Mem0:s forskningsrapport, publicerad vid ECAI 2025 (arXiv:2504.19413), benchmarkade tio distinkta tillvägagångssätt till AI-minne och validerade den selektiva utvinningmetoden — lagring av diskreta fakta, deduplicering och hämtning av endast det som är relevant. Mem0 har växt till cirka 48K GitHub-stjärnor och stöder 21 ramverksintegrationer. Kompromissen är molnberoende och kostnad.

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

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

Del 2: Arkitektur

Läs denna del toppbotten — lager och per-omgång återkallelse/lagring först, sedan vad som finns i MEMORY.md och USER.md, sedan hur man ansluter en extern leverantör.

Två lager

Hermes staplar minnet i två lager:

1. Inbyggt — MEMORY.md och USER.md, filbaserat, alltid aktivt. Hårda tak på 2 200 tecken (agentens anteckningar) och 1 375 tecken (användarprofil).
2. En extern leverantör (valfritt) — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory och liknande som du aktiverar via konfiguration. Endast en extern backend körs åt gången. Den lägger till hämtning och behåll bredvid filerna; den ersätter dem inte.

Den mentala modellen är additiv — frusna kärnfiler plus högst ett plugin. Prefetch- och synkhakar orkestrerar det externa lagret; de två filerna stannar injicerade separat som en del av den frusna systemprompten.

Runtime-flöde (prefetch och sync)

Återkallelse sker innan modellen svarar; persistens sker efter assistentmeddelandet. I Hermes Agents minneshanterare motsvarar detta prefetch på vägen in och sync på vägen ut. Namnen nedan matchar implementationsytan (MemoryManager, per-leverantör prefetch / sync_turn / queue_prefetch).

Användarmeddelande
    |
    v
MemoryManager.prefetch_all(query)        <-- återkallelsefas
    |
    +-- provider.prefetch(query)        <-- varje extern leverantör söker i sin lagring
    |
    v
Kontext injicerad i LLM-omgången
    |
    v
LLM svarar (assistentmeddelande)
    |
    v
MemoryManager.sync_all(user, assistant)  <-- lagringsfas
    |
    +-- provider.sync_turn(user, assistant)
    +-- provider.queue_prefetch(user)    <-- bakgrundssökning mot nästa omgång

Inbyggda MEMORY.md och USER.md är inte hämtade genom prefetch_all — de är redan en del av den frusna systemprompten. Externa backends kopplas in i prefetch_all / sync_all; queue_prefetch låter en leverantör värma upp hämtningen för nästa omgång utan att blockera det aktuella svaret.

Tre vägar in i långsiktigt minne

1. Inbyggt memory-verktyg. Modellen anropar memory med add, replace eller remove när instruktioner säger att något ska persista — hållbara fakta, preferenser, korrigeringar, miljöanteckningar. target='user' underhåller USER.md; target='memory' underhåller MEMORY.md. Exempel på form: memory(action='add', target='user', content='…').

2. Passiv behållning hos externa leverantörer. Varje omgång anropar ramverket leverantörens synkväg så att konversationen kan chunkas, sammanfattas eller utvinnas utan att modellen behöver namnge varje fakta. Beteendet skiljer sig beroende på backend — till exempel batchar Hindsight omgångar och kör strukturerad behållning med entiteter och relationer; Honcho skickar dialogen genom sin dialektiska pipeline; Mem0- och Supermemory-stil stackar utvinner fakta passivt från omgångar.

3. Leverantörsspecifika verktyg. När pluginet exponerar dem, explicita skrivingar som honcho_conclude, hindsight_retain eller honcho_profile lagrar hållbara skär på begäran.

Automatisk återkallelse versus leverantörsverktyg

Kärnminnet behöver inget läsverktyg — det är redan i prompten. Externa backends lägger antingen automatisk injicering från prefetch (ingen separat återkallelseverktygsanrop för den delen av kontexten) eller explicita hämtverktyg (honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect och liknande) när modellen behöver en skarpare frågeställning än prefetch ensam.

Återkallelsemodes (externa leverantörer)

Plugin stödjer en konfigurerbar återkallelsemode (vanligtvis recall_mode bredvid memory.provider i konfigurationen) som byter token mot kontroll.

När ingen extern leverantör är inställd (memory.provider tom eller oinställd), gäller endast de inbyggda filerna och sessionssökning — ingen prefetch/sync från ett plugin.

Sökvägar på disk och budgetar

Hermes Agents inbyggda minne finns i två filer.

• ~/.hermes/memories/MEMY.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 designsyftet.

MEMORY.md: Agentens anteckningar

Här lagrar 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 variablnamn och undviker camelCase

Detta är inte loggar. Det är fakta. Täta, deklarativa, informationspackade. Inga tidsstämpel, ingen fluff, inget “den 5 januari frågade användaren mig att…”

USER.md: Användarprofilen

Här lagrar agenten allt den vet om dig.

Användaren är en fullstack-utvecklare bekväm med TypeScript, Go och Python.
Användaren föredrar snake_case för variablnamn och 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 till dig än till någon annan.

Den frusna snapshot-mönstret

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

══════════════════════════════════════════════
MEMORY (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 variablnamn och undviker camelCase
§

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

Formatet använder rubriker, användningsprocent, teckenantal och § (sektionstecken) som avgränsare. Poster kan vara flerradiga. Det är designat för att vara parsbart av modellen samtidigt som det förblir läsbar för människor.

Varför fruset? Prefixcaching. Systemprompten är densamma över varje omgång i en session. Genom att hålla minnet statiskt efter sessionsstart kan modellen cacha prefixberäkningen och bara bearbeta de variabla delarna — konversationen. Detta är en betydande prestandaoptimering. Du beräknar inte uppmärksamheten över samma minnestoken vid varje omgång.

Ändringar som görs under en session persistar till disk omedelbart, men de dyker bara upp i systemprompten vid nästa sessionsstart. Verktygssvar visar alltid live-läget, men modellens “sinne” ändras inte mitt i 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 kuratering.

Obegränsat minne är en skuld. Det uppmuntrar dumpning av allt, aldrig konsolidera och slutligen 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 mening?

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

1. Läs aktuella poster från felsvar
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 fakta som betyder något.

Säkerhet: Promptinjektionsskanning

Varje minnespost skannas innan acceptans. Systemet blockerar promptinjektionsförsök, exfiltrering 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.

Externa minnesleverantörer (aktivering och länkar)

Utöver inbyggda MEMORY.md och USER.md kan Hermes Agent fästa en extern minnesplugin åt gången — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover eller Supermemory — för ihållande, tvärsessions kunskap. Endast en extern leverantör är aktiv i taget; de två kärnfilerna förblir laddade bredvid den (additivt, inte ersättande).

Aktivera och inspektera leverantörer med hermes memory setup, hermes memory status och hermes memory off, eller ställ in memory.provider och recall_mode i ~/.hermes/config.yaml. Autentiseringsmönster varierar (till exempel HINDSIGHT_API_KEY, Honcho-nycklar under $HERMES_HOME/honcho.json); använd hermes memory setup för interaktiv koppling.

Minimal YAML-form endast med inbyggt:

memory:
  provider: ""
  memory_enabled: true
  user_profile_enabled: true

Exempel på aktivering för en backend (byt hindsight mot honcho, mem0, supermemory eller andra som din installation stödjer):

memory:
  provider: "hindsight"

För fullständig jämförelsetabell, anteckningar om LLM- och inbäddningsberoenden, nedbrytning per leverantör och hur dessa backends förhåller sig till OpenClaw och andra stackar, se Agentminnesleverantörer jämförda.

För profilsspecifik koppling och produktionsarbetsflöden, se Hermes Agent produktionsinstallation. AI-systems minnehub listar denna guide plus relaterade Cognee- och kunskapslagerartiklar.

Del 3: När minnet avfyras — Triggare & 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 memory-verktyget, och beslutet att spara drivs av en kombination av explicita signaler och implicita mönster.

Skrivtriggare: När bestämmer sig agenten att spara?

Agenten sparar minne proaktivt. Den väntar inte på att du ska be om det. Här är vad som triggar 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 installerade verktygen. Dessa upptäcks genom utforskning och sparas som fakta.

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

Projektstandarder. 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 tillvägagångssättet som en färdighet eller åtminstone notera vad som fungerade.

Verktygsgrejjer och lösningar. När agenten upptäcker något icke-uppenbart om ett verktyg, API eller system — en begränsning, en lösning, en konvention — sparar den det.

Vad som hoppas över:

• Trivial eller uppenbar information
• Saker som lätt kan återupptäckas
• Rådatadumps
• Sessionspecifika ephemera
• Information som redan finns i kontextfiler (SOUL.md, AGENTS.md)

Lästiggare: När minns agenten?

Minnet hämtas inte — det är alltid där. Men det finns olika åtkomstnivåer.

Sessionsstart (automatiskt). MEMORY.md och USER.md injiceras i systemprompten. Agenten har dem från den 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 session_search-verktyget. Detta frågar SQLite (~/.hermes/state.db) med FTS5 fulltextsökning och Gemini Flash-sammanfattning. Använd detta när frågan låter som “prata vi om detta tidigare” snarare än “kom ihåg denna fakta för alltid.”

Exempel: du frågar “Diskuterade vi Docker-nätverkning i 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, kör ramverket också ett automatiskt prefetch-steg innan varje svar (se Del 2). Ytterligare verktyg som honcho_search, hindsight_recall eller mem0_search är för riktade sökningar när agenten väljer explicit hämtning — beroende på recall_mode, kan automatisk injicering, verktyg eller båda vara aktiva.

Beslutsträdet

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

Är detta en korrigering eller explicit instruktion?
  JA → Spara till minne
  NEJ → Är detta en preferens eller mönster?
    JA → Spara till användarprofil
    NEJ → Är detta en miljöfakta eller konvention?
      JA → Spara till minne
      NEJ → Är detta lätt att återupptäcka?
        JA → Hoppa över
        NEJ → Är detta sessionspecifikt?
          JA → Hoppa över
          NEJ → Spara till minne

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

Del 4: Internt minne versus Externa kunskapsbas

Detta är där förvirring ofta uppstår. 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 pipelines och agentens arbetsminne — extern hämtning är bra för djup kunskapsupplysning, inte för att bära identitet och preferenser. Internt minne är agentens hjärna — alltid aktiv, kuraterad, med 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 huvudet” under konversationen
• Kuraterad, begränsad, aktivt hanterad
• 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 vid behov
• Inte “minns” — slå upp
• Exempel: LLM Wiki, Obsidian, Notion, ArXiv, filsystem, GitHub

Hur de förhåller sig

Agenten åtkommer externa baser via verktyg vid behov. Den “minns” dem inte — den slår upp dem.

LLM Wiki (llm-wiki): Karpathys lä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: Personliga anteckningsvalv med bidirektionella 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 ekosystemet som Hermes kan ta del av som en biblioteksresurs.

Notion/Airtable: Strukturerade databaser och wikis åtkomna via API. Agenten frågar dem vid behov.

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

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

Destillationsmönstret

Här är nyckelinsikten: kritiska insikter från externa baser kan destilleras till 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 nyckelinsikten: Minnesskalning: agentens prestanda förbättras med ackumulerad erfarenhet genom användarinteraktion och affärskontext lagrad i minnet.

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

När använda vilket

Internt minne för:

• “Vem hjälper jag?”
• “Vad föredrar de?”
• “Vad lärde vi oss just?”
• “Vad är projektinstallationen?”
• “Vilka verktyg är tillgängliga?”

Externa kunskapsbas för:

• “Vad är den senaste forskningen om X?”
• “Vad finns i mitt projekts 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 minns något den har lärt sig om dig och din miljö.

Del 5: Hur det faktiskt fungerar

Låt oss titta på mekaniken.

memory-verktyget

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

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

add — Lägger till en ny post.

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 terminal")

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 gör kirurgiska redigeringar möjliga utan att känna till det exakta innehållet.

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 versus user

Parametern target avgör vilken fil som uppdateras.

• memory — Agentens personliga anteckningar. Miljöfakta, projektstandarder, verktygsgrejjer, 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 föråldrade fakta och komprimerar information.

Bra minnesposter är kompakta och informationsintensiva:

Användaren kör macOS 14 Sonoma, använder Homebrew, har Docker Desktop installerat. Skål: 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 är placerat vid ~/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 verbos.

Sessionsökning versus ihållande minne

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

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

Del 6: 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 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 dumpning av allt och städar aldrig 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 ögonblickligt, 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 borde spenderas på den faktiska uppgiften.

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

Problemet med “att glömma”

Agenter behöver lära om. Inte bara glömma, men aktivt ta bort föråldrad information.

Så här hanterar Hermes Agent det:

• remove-åtgärd: Ta bort 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 om kommer till slut att bära lika mycket brus som signal.

Minnesskalning

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

Deras forskning tyder på ja, men med reservationer. Minnesskalning kräver:

1. Kvalitetsutvinning: 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ödjer naturligt minnesskalning. Genom att tvinga 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 agens-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. Den är besvarad: de måste. Den öppna frågan är hur man designar det minnet väl — vad man ska behålla, vad man ska kasta, hur man gör det ögonblickligt 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 du frågar, utan en arbetsmodell av användaren som agenten bär med sig in i varje konversation.

Slutsats

Hermes Agents minnesystem är medvetet 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 på samma sätt som en hjärna snarare än som en databas — liten, kuraterad och alltid aktiv. Agenten hämtar inte minnet när den behöver det; minnet är enkelt alltid där, vävt in i systemprompten från den första token i varje session.

Externa minnesleverantörer utökar detta system för användare som behöver mer: kunskapsgrafer, multi-agent-stöd, självhärbärgad 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år upp dem, minns dem inte. Kritiska insikter destilleras till 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-stjärnor i april 2026 (v0.9.0), med 242+ medverkande. Det är open-source och tillgängligt på github.com/NousResearch/hermes-agent. För installation, konfiguration och arbetsflödesguider, se Hermes Agent översikt.