En agent uden persistens på tværs af sessioner starter hver session med den kontekst, den får. Persistens kan reducere behovet for gentagne forklaringer af konteksten, men skaber også forpligtelser inden for databeskyttelse, nøjagtighed, isolering og sletning.
Dette er hukommelsesproblemet. Kontekstvinduer håndterer den aktuelle samtale. Langtidshukommelse på tværs af sessioner, dage og måneder kræver sin egen arkitektur. Og det er sværere, end det ser ud.
Denne artikel præsenterer et referencedesign til afprøvning, ikke en certificeret implementering. Produktteams skal kontrollere adgangskontrol, rettelse, opbevaring, sletning, gendannelse og kvaliteten af datahentningen i deres eget system.
Hvad »hukommelse« betyder
En forenklet opfattelse: hukommelse = »modellen husker ting mellem samtaler«. Virkeligheden er mere nuanceret. Den kognitive videnskab skelner mellem typer af hukommelse, og AI-agenters hukommelse drager fordel af en tilsvarende inddeling:
Arbejdshukommelse. Den aktuelle samtale. Opbevares i kontekstvinduet. Forsvinder, når samtalen slutter (medmindre den gemmes).
Episodisk hukommelse. Specifikke begivenheder fra fortiden. »Sidste tirsdag diskuterede vi X.« »For tre måneder siden besluttede du Y.«
Semantisk hukommelse. Generelle fakta. »Dit navn er Alice.« »Du foretrækker korte svar.« »Din virksomhed ligger i Tallinn.«
Procedurel hukommelse. Hvordan man gør ting. »Når brugeren beder om et møde, skal du bruge denne skabelon.« »Når kunden er på niveau X, skal du følge proces Y.«
Forskellige typer hukommelse tjener forskellige funktioner. Brug kun de lag, som produktet kan retfærdiggøre og håndtere; at gemme mere er ikke automatisk bedre.
Hvad hukommelsen skal opnå
Før arkitekturen: målene.
Kontinuitet. Agenten fortsætter, hvor den slap. Du behøver ikke at introducere dig selv igen i hver session.
Personalisering. Agenten anvender dine præferencer uden at blive bedt om det. Den skriver i din stemme, bruger dine værktøjer og refererer til dit team.
Bevaring af kontekst. Beslutninger fra tidligere samtaler skal indgå i de aktuelle. »Vi besluttede X sidste måned« skal huskes.
Genbrug af bekræftede præferencer. Systemet kan genanvende en udtrykkelig eller verificeret præference i de områder, hvor den er gyldig. Gentagelse alene beviser ikke, at et værktøj, sprog eller en adfærd skal blive standard.
Databeskyttelse og glemning. Hvad der huskes, hvad der ikke gør, og hvad der slettes. Det handler både om brugerens tillid og juridisk efterlevelse.
Disse mål kan være i konflikt. Kontinuitet kan drage fordel af bevidst vedligeholdelse af data, mens databeskyttelse og nøjagtighed taler for minimering, formålsbegrænsning, korrektion og sletning. Arkitekturen skal gøre disse kompromiser eksplicitte.
Arkitekturen
En typisk lagdelt arkitektur:
┌─────────────────────────────────────┐
│ Arbejdshukommelse (i konteksten) │ Aktuel samtale
├─────────────────────────────────────┤
│ Sessionshukommelse (seneste) │ De sidste N samtaler
├─────────────────────────────────────┤
│ Episodisk hukommelse (langtidshuk.) │ Specifikke tidligere begivenheder
├─────────────────────────────────────┤
│ Semantisk hukommelse (fakta) │ Stabile brugeroplysninger
├─────────────────────────────────────┤
│ Procedurel hukommelse (præferencer) │ Sådan skal du opføre dig over for denne bruger
└─────────────────────────────────────┘
Hvert lag kræver udtrykkelige regler for lagring, søgning, adgang, oprindelse, rettelse, opbevaring og sletning; flere logiske lag kan godt dele et fysisk lager.
Vi gennemgår hvert lag.
Lag 1: Arbejdshukommelse
Emnet er allerede beskrevet i Kontekstdesign. Det gælder den aktuelle samtale i konteksten. Ved samtaler med flere trin bruges en lagdelt kontekst, hvor de seneste runder gengives ordret, mens ældre runder opsummeres.
En overførsel til langtidshukommelsen kan ske ved et udtrykkeligt kontrolpunkt, en varig hændelse eller sessionens afslutning. Da sessioner kan slutte brat, skal du kun gemme godkendte kandidater og gøre skrivestatus synlig i stedet for at antage, at en afslutningsfunktion altid bliver udført.
Lag 2: Sessionshukommelse
Resuméer af nylige sessioner kan gemmes med et begrænset detaljeniveau, når produktet har et berettiget formål. Ethvert antal, f.eks. de sidste ti samtaler, er et illustrativt input til reglerne, ikke en standard.
Implementering: ét resumé pr. session, gemt med tidsstempel og emne. Når brugeren vender tilbage, har agenten et hurtigt overblik over det seneste forløb.
{
"session_id": "abc-123",
"user_id": "alice",
"started": "2026-05-14T10:30:00Z",
"ended": "2026-05-14T10:45:00Z",
"topic": "Drafting proposal for Acme Corp",
"summary": "Drafted v1 of the Acme proposal. Decided to lead with the cost-savings angle. Alice will review and send Friday.",
"facts_learned": ["Acme is a current customer", "Alice's deadline is Friday"],
"open_items": ["Alice to review v1 by Thursday"]
}
Ved en ny session kan et autoriseret udsnit af nylige resuméer indlæses efter test af søgekvalitet, relevans, tokenbudget og databeskyttelse. Indlæs ikke som standard automatisk et fast antal i hver kontekst.
Dette er en forholdsvis enkel form for hukommelse på tværs af sessioner, men den kræver stadig isolering, dokumenteret oprindelse, rettelse, livscyklusstyring og test af søgningen.
Lag 3: Episodisk hukommelse
Specifikke begivenheder fra fortiden, der er værd at huske langsigtet. Beslutninger, milepæle, vigtige samtaler.
De udtrækkes fra sessioner, når de er bemærkelsesværdige, og gemmes med fyldige metadata.
{
"event_id": "ev-456",
"user_id": "alice",
"date": "2026-04-22",
"type": "decision",
"description": "Alice decided to migrate from Postgres to ClickHouse for the analytics workload, citing query performance.",
"context_summary": "After 3 weeks of evaluation including performance tests and cost analysis.",
"related_topics": ["infrastructure", "analytics", "database"],
"importance": "high"
}
Søgning: Når det er relevant for den aktuelle samtale, finder agenten relaterede begivenheder. Det sker via semantisk søgning, hvor den aktuelle forespørgsel omdannes til en indlejringsvektor for at finde matchende begivenheder, via emnematch eller via tidsbaserede forespørgsler som »hvad skete der sidste måned?«.
Udfordringen ligger i at afgøre, hvad der kvalificerer sig som en begivenhed, der er værd at huske. Et muligt mønster er, at modellen ved et godkendt kontrolpunkt foreslår beslutninger, forpligtelser eller milepæle sammen med kildeudsnit og regler for bekræftelse. En vigtighedsmærkat, som modellen har genereret, giver ikke i sig selv ret til at gemme personoplysninger.
Lag 4: Semantisk hukommelse
Stabile fakta om brugeren, der altid skal være tilgængelige. »Alice er CEO i Acme. Hendes foretrukne kommunikationsstil er kort og præcis. Hun arbejder i tidszonen Tallinn.«
Disse fylder mindre end episoder, men hentes oftere. De udgør agentens »model af brugeren«.
Implementering: en struktureret profil.
{
"user_id": "alice",
"profile": {
"name": "Alice Tamm",
"role": "CEO at Acme Corp",
"location": "Tallinn, Estonia",
"timezone": "Europe/Tallinn",
"preferred_language": "English",
"communication_style": "concise, direct, no preamble",
"expertise_areas": ["product strategy", "go-to-market"],
"tools_used": ["Notion", "Slack", "Linear"]
}
}
Opdateringer sker, når agenten lærer nye fakta. Efter en session identificerer en LLM nye stabile fakta og foreslår dem; de indarbejdes enten automatisk eller sættes i kø til gennemgang.
Vigtigt: semantiske fakta skal være velunderbyggede og stabile. En afslappet kommentar i én samtale (»Jeg må prøve Python«) bør ikke blive et semantisk faktum (»Alice foretrækker Python«). Kravene er højere.
En rent illustrativ arbejdsgang med konfidensniveauer, som stadig kræver dokumenteret oprindelse og kalibrering:
- Udledt én gang: kun en kandidat, med kildeudsnit og uden automatisk virkning på adfærden.
- Eksplicit udtalt: kandidat til det angivne omfang; bekræft før genbrug med konsekvenser.
- Udtrykkeligt bekræftet: gemt med dokumenteret oprindelse, omfang, gennemgangsdato og brugerstyring.
Dette forhindrer agenten i at »lære« forkerte fakta fra afslappede kommentarer.
Lag 5: Procedurel hukommelse
Hvordan agenten skal opføre sig over for denne bruger. Arbejdsgange, skabeloner, præferencer for specifikke handlinger.
Eksempler:
{
"user_id": "alice",
"procedural": {
"email_signature": "...",
"meeting_preferences": "always offer 3 time slots, never schedule before 9am",
"code_style": "Python, type hints required, dataclasses over dicts",
"tone_for_clients": "warm, direct, with explicit next steps",
"approval_process": "all customer-facing communications need Alice's review before sending"
}
}
Dette er mønstre, som agenten følger, når relevante opgaver opstår.
Opdateringer kan begynde med en udtrykkelig instruktion eller et gentaget mønster. Gentagen adfærd kan udløse en anmodning om bekræftelse, men bør ikke ubemærket oprette en permanent arbejdsgang.
Lagervalg
Hvor gemmes hukommelsen?
SQL-database. Pålidelig, velkendt og nem at forespørge. Hver hukommelsestype får sin egen tabel. Sammenføjninger bruges til søgning. Velegnet til strukturerede adgangsmønstre.
Vektordatabase. Til semantisk søgning i episoder som »find minder, der er relateret til dette emne«. Episoder omdannes til indlejringsvektorer og findes via lighedssøgning.
Kombination. SQL plus et vektorindeks er én mulig løsning, når både struktureret og semantisk adgang er nødvendig. Den dobbelte repræsentation øger forpligtelserne til synkronisering og sletning, så sammenlign den med et enklere lager.
Specialiserede hukommelsesværktøjer. Mem0, Letta (tidligere MemGPT) og Zep er formålsspecifikke hukommelseslag til agenter. De er værd at overveje, hvis du ønsker et højere abstraktionsniveau.
Start med det mindste lager, der opfylder kravene til struktureret adgang, semantisk søgning, adskillelse af kunder, dokumenteret oprindelse, rettelse, opbevaring, sletning samt sikkerhedskopiering og gendannelse. SQL, et vektorindeks, begge dele eller et specialiseret lag kan være den rette løsning; sammenlign drifts- og migrationsbyrden frem for blot at antage, at teamets sædvanlige valg også er rigtigt her.
Hentningsmønstre
Hvordan får agenten hukommelsen ind i konteksten?
Mønster 1: Automatisk indlæsning ved sessionsstart
Når en ny session starter, trækkes automatisk:
- Brugerens semantiske profil.
- De seneste N opsummeringer af sessioner.
- Eventuelle åbne forpligtelser eller opfølgninger.
Dette er agentens grundkontekst, når brugeren vender tilbage.
Mønster 2: Forespørgselsdrevet søgning
Når brugerens besked antyder tidligere emner, hentes relevante episoder.
Eksempel: Brugeren spørger »hvad var konklusionen på vores databasediskussion?« Agenten søger i episoder efter »database« og henter den relevante.
Implementering: Omdan brugerens besked til en indlejringsvektor, find lignende episoder, og medtag dem i konteksten.
Mønster 3: Eksplicitte hukommelsesværktøjer
Agenten har værktøjer til at forespørge hukommelsen:
search_episodes(query): Find specifikke tidligere begivenheder.get_user_profile(): Træk den semantiske profil.list_open_items(): Afventende forpligtelser.
Agenten afgør, hvornår disse skal kaldes baseret på samtalen.
Mønster 4: Berigelse af hukommelsen i baggrunden
En baggrundsproces gennemgår periodisk hukommelsen og:
- Konsoliderer relaterede episoder til temaer.
- Opdaterer konfidensen for fakta.
- Lader gamle minder henfalde, hvis de ikke er blevet tilgået.
Dette er »vedligeholdelse af hukommelsen«: at holde hukommelseslageret nyttigt over tid.
Skrive hukommelse
Hvornår skrives hukommelsen?
Udtrækning ved kontrolpunkt eller sessionsafslutning
Et batchmønster, der skal bestå test af holdbar levering og pludselig afbrydelse. Ved et godkendt kontrolpunkt eller ved sessionens afslutning:
- En LLM analyserer samtalen.
- Ekstraherer:
- Sessionsopsummering.
- Bemærkelsesværdige begivenheder (til episodisk hukommelse).
- Nye fakta (til semantisk hukommelse).
- Præferencesignaler (til procedurel hukommelse).
- Opdaterer og gemmer.
Batchbehandling kan reducere arbejdet undervejs i sessionen, men den kan også miste opdateringer, hvis en session afsluttes uventet, og forsinke rettelser. Mål begge dele, og brug en vedvarende jobkø, hvor persistens er påkrævet.
Prompt til ekstraktion:
Analyser denne samtale. Udsend JSON med:
1. summary: 2-3 sætninger, der opsummerer, hvad der skete.
2. notable_events: liste over betydningsfulde begivenheder, det er værd at huske (trufne beslutninger, milepæle, vigtig kontekst).
3. new_facts: liste over stabile fakta lært om brugeren (inkluder kun, hvis du har høj konfidens).
4. preference_signals: liste over observerede præferencer (kun hvis de er udtrykt tydeligt eller gentaget).
5. open_items: liste over uløste emner, som brugeren måske ønsker at vende tilbage til.
Vær konservativ. Inkluder kun elementer med høj konfidens. Det er bedre at overse noget end at hallucinere.
Realtidsopdateringer for fakta af høj værdi
For visse fakta er det forkert at vente, indtil sessionen slutter. Hvis en bruger siger »faktisk hedder jeg Alex, ikke Alice«, skal rettelsen anvendes med det samme.
Et mønster er at lade agenten opdage udtrykkelige rettelser eller vigtige nye fakta med det samme og opdatere hukommelsen i samme arbejdsgang.
Det kræver omhyggeligt design, fordi LLM’en kan »lære« forkerte fakta. Nogle teams kræver brugerbekræftelse, før øjeblikkelige opdateringer anvendes.
Brugerinitierede opdateringer
Brugeren kan eksplicit fortælle agenten ting, den skal huske:
- »Husk venligst, at jeg foretrækker X.«
- »Glem det, jeg sagde om Y.«
- »Gør altid Z.«
Disse bør være fuldt understøttede brugerfunktioner. Start den anmodede handling med det samme, vis dens omfang og status, og forklar eventuel lovlig opbevaring eller udløb af sikkerhedskopier, der forhindrer øjeblikkelig sletning overalt. En udtrykkelig udtalelse dokumenterer oprindelsen godt, men beviser ikke, at ethvert udledt omfang er korrekt.
Et specifikt værktøj, agenten kan tilbyde:
remember(content: string, type: "fact" | "preference" | "procedure")
forget(content: string)
list_what_you_remember()
At give brugere denne kontrol bygger tillid.
Glemning og henfald
Ubegrænset hukommelse skaber risici ved hentning, omkostninger, databeskyttelse og nøjagtighed. En dokumenteret livscyklus er afgørende; tidsbaseret henfald er én mulighed, ikke en erstatning for påkrævet opbevaring eller sletning.
Tidsbaseret henfald
Ældre minder hentes mindre sandsynligt. Implementering:
- Rangér søgningen efter
relevance * recency_decay. - Gamle minder forsvinder reelt, medmindre der henvises udtrykkeligt til dem.
Vigtighedsbaseret opbevaring
Vigtige episoder beholdes længere; trivielle henfalder hurtigere.
- Markér episoder med vigtighed ved skrivningstidspunktet.
- Begivenheder med høj værdi: en formålsspecifik opbevaringsperiode med en ejer og gennemgangsdato; undgå standardmæssigt ubegrænset opbevaring.
- Rutinebegivenheder: henfalder over måneder.
Brugerinitieret glemning
Brugeren kan anmode om, at specifikke minder slettes.
- Specifikke fakta.
- Specifikke tidsperioder.
- Specifikke emner.
Implementering: en arbejdsgang til sletning, der fjerner den primære post og alle afledte tekstblokke, indlejringsvektorer, resuméer, indeks, cacher, eksporter og job i kø. En slettemarkør kan forhindre genindlæsning, men det er ikke sletning blot at skjule en post. Definér, hvordan sikkerhedskopier udløber, og test, at slettede data ikke dukker op igen efter gendannelse.
Sletning på grund af lovkrav
Juridiske krav kan påbyde sletning eller opbevaring. GDPR, artikel 17 fastlægger en ret til sletning med undtagelser; en juridisk rådgiver skal kortlægge denne og andre gældende regler i forhold til produktet, jurisdiktionen og datarollen.
- Anmodning om sletning af brugerkonto → kør den gennemgåede arbejdsgang til sletning eller begrænsning på alle dækkede lagre, og oplys undtagelser eller udløb af sikkerhedskopier.
- Sletning af data efter anmodning → find de omfattede poster og afledte data, og verificér derefter resultatet.
- Opbevaringsgrænser → lad automatisk dækkede poster udløbe i henhold til den godkendte plan.
Disse skal indbygges fra starten. Eftermontering er smertefuldt.
Overvejelser om databeskyttelse
Hukommelse er følsom. Lageret indeholder meget information om brugeren. Overvejelser:
Kryptering af lagrede data
Hukommelsesdata krypteres under lagring. Det er almindelig praksis.
Adgangskontrol
Hvem kan se en brugers hukommelse? Kun brugeren, kun systemet eller supportmedarbejdere under visse betingelser? Definér dette tydeligt. Gennemgå adgangen.
Håndtering af personoplysninger
Personoplysninger som rigtige navne, adresser og økonomiske oplysninger skal mærkes og behandles omhyggeligt. Brug særlige adgangskontroller og sletteprocedurer.
Brugerens indsigt
Hvor produktet og gældende rettigheder kræver det, skal du give brugerne mulighed for at se, korrigere, afgrænse og slette hukommelsesposter. Et kontrolpanel for hukommelsen er én mulig implementering; test, om brugerne forstår det, og beskyt det som enhver anden brugerflade med følsomme data.
Hvad agenten husker om dig:
Profil:
- Navn: Alice Tamm
- Rolle: CEO hos Acme Corp
- Kommunikationsstil: kortfattet, direkte
Seneste sessioner:
- 2026-05-14: Udkastet forslag til Acme
- 2026-05-12: Gennemgik Q1-resultater
- ...
Præferencer:
- Foretrækker korte svar
- Bruger Notion, Slack, Linear
[Rediger] [Slet bestemte elementer] [Slet alt]
Denne gennemsigtighed bygger tillid. Uigennemskuelig hukommelse uden brugers indsigt gør det ikke.
Deling på tværs af kontekster
Hvis brugeren har flere »tilstande« (arbejdsagent og personlig agent), kan vedkommende ønske at holde minderne adskilt. Del dem ikke automatisk mellem tilstande, medmindre brugeren beder om det.
Almindelige fejltyper
Et par mønstre:
Fejl 1: Hallucinerede minder
Agenten hævder at huske ting, der ikke skete. »Sidste uge blev vi enige om X«, men X blev aldrig diskuteret.
Årsag: LLM’en finder på minder, der lyder plausible, under udtrækning eller søgning.
Løsning: Forankr hukommelseshandlingerne i virkelige samtaledata. LLM’en udtrækker kandidaterne; kontrollen sker mod den faktiske transskription. Hallucinerede fakta skal markeres.
Fejl 2: Forkerte fakta indlært
Agenten fremfører forkerte fakta med stor sikkerhed. »Du sagde, at du foretrækker Python«, når du faktisk sagde, at du blev tvunget til at bruge Python på arbejdet.
Årsag: misfortolkning under ekstraktion.
Løsning: Brug konfidensgrænser. Lær kun af udtrykkelige, gentagne eller bekræftede udsagn. Brugeren skal kunne rette dem.
Fejl 3: Lækage af personoplysninger
Hukommelse fra én bruger dukker op i en andens samtale. Katastrofalt.
Årsag: Fejl i logikken, der afgrænser data til den enkelte bruger.
Løsning: Håndhæv den brugerspecifikke afgrænsning i både lager- og søgelaget. Gennemfør revisioner. Stol aldrig på, at LLM’en filtrerer korrekt.
Fejl 4: Hukommelsesvækst
Efter et år fylder hukommelsen megabytes per bruger. Hentningen bliver langsommere. Omkostningerne stiger.
Årsag: Manglende henfald eller beskæring.
Løsning: Lad søgeprioriteten falde markant over tid. De fleste minder får lav søgeprioritet efter et par måneder. Komprimér regelmæssigt.
Fejl 5: Forældede fakta
Brugeren skiftede rolle for 6 måneder siden. Agenten refererer stadig til den gamle rolle.
Årsag: fakta er ikke opdateret, når de erstattes af nye.
Løsning: Opdag modsigelser, bevar dokumenteret oprindelse og gyldighedsdatoer, og bed om bekræftelse, når den autoritative værdi er uklar. Reglen »nyeste værdi vinder« er usikker ved forsinkede, citerede eller ondsindede input.
Fejl 6: Konsolidering, der forvrider hukommelsen
Baggrundskonsolidering af hukommelse omskriver lejlighedsvis minder på måder, der mister information.
Årsag: Aggressiv opsummering uden at bevare nøglefakta.
Løsning: Konsolideringen skal udtrykkeligt bevare fakta. Test den på virkelige samtaletransskriptioner.
En implementeringsskitse: personlig assistent med hukommelse
Et illustrativt referencedesign: en personlig AI-assistent til individuelle brugere.
Hukommelseslag:
- Arbejdshukommelse: den aktuelle samtale.
- Sessionshukommelse: de sidste 7 sessioner i opsummeret form.
- Episodisk hukommelse: de 100 seneste bemærkelsesværdige begivenheder med semantisk søgning.
- Semantisk hukommelse: brugerprofil (navn, rolle, præferencer, værktøjer).
- Procedurel hukommelse: udtrykkelige arbejdsgange, som brugeren har opsat.
Lagring:
- SQL (Postgres): struktureret profil, sessioner, episoder og procedurer.
- Vektordatabase (pgvector): episodisk semantisk søgning.
Drift:
- Start af session: automatisk indlæsning af semantisk profil + de sidste 3 sessioner + åbne punkter.
- Undervejs i sessionen: episodiesøgning udløst af emnerelevans.
- Slutning af session: LLM-baseret ekstraktion; brugeren kan gennemgå, hvad der er blevet lært.
- I baggrunden: ugentlig konsolidering, der kombinerer relaterede episoder og lader forældede data henfalde.
Brugerstyring:
- Kontrolpanel, der viser, hvad agenten husker.
- Redigering/sletning af individuelle elementer.
- Knap til »Glem den sidste time«.
- Arbejdsgang til sletning af hele kontoen med verificeret dækning, dokumenterede undtagelser og oplysninger om udløb af sikkerhedskopier.
Beviskrav for succes:
- Opgaveløsning med og uden hentet hukommelse på et fast evalueringssæt,
- Præcision af lagrede fakta og genfundne minder, herunder håndtering af modstridende oplysninger,
- Test af isolation mellem lejere og brugere,
- Udbredelse af rettelser og sletninger gennem poster, indlejringsvektorer, cacher, eksporter, job og udløb af sikkerhedskopier,
- Token-, lager-, latens- og driftsomkostninger baseret på faktiske spor,
- Test af brugerforståelse og kontrol frem for blot at antage, at brugerne har tillid til systemet.
Håndterede fejltyper:
- Tilfælde med hallucinerede minder indgår i test af udtræk og genfinding.
- Konfidensscorer kalibreres; de gør ikke et udsagn sandt alene ved deres værdi.
- Autorisation håndhæves før genfinding og igen før præsentation.
- Job til opbevaring og konsolidering har revisionslogfiler, fejlhåndtering og test af sletning.
Dette er en designtjekliste, ikke dokumentation for produktionsklarhed. Produktionsstatus kræver dokumentation fra implementeringen samt gennemgang af sikkerhed og databeskyttelse.
Specialiserede værktøjer
En bemærkning om løsninger, der leverer hukommelse som en tjeneste:
Mem0. Et hukommelseslag med åben kildekode. Vurdér den aktuelle dokumentation og koden i forhold til dine krav til persistens, isolering og sletning.
Letta (MemGPT). Et værktøjsorienteret hukommelsesdesign. Gennemgå den aktuelle dokumentation og de driftsmæssige begrænsninger.
Zep. En administreret tjeneste til hukommelse og kontekst. Validér den aktuelle dokumentation, datagrænsen og slettevilkårene.
Cognee. Et alternativ baseret på en vidensgraf. Vurdér modenhed og egnethed ud fra den aktuelle dokumentation og kodebase, før du tager det i brug.
Disse værktøjer kan reducere implementeringsarbejdet, men tilføjer afhængigheder inden for leverandør, sikkerhed, migration og datalivscyklus. Sammenlign dem med en intern løsning ved hjælp af de samme godkendelsestest.
Byg kun den hukommelse, der er berettiget
Langtidshukommelse giver agenter kontinuitet på tværs af sessioner, så de ikke begynder helt forfra. Det er også en af de vanskeligere funktioner at få til at virke korrekt.
Arkitekturen er lagdelt:
- Arbejdshukommelse (i kontekst).
- Sessionshukommelse (seneste sessioner).
- Episodisk hukommelse (specifikke begivenheder).
- Semantisk hukommelse (stabile fakta).
- Procedurel hukommelse (præferencer og arbejdsgange).
Hvert lag har sin egen logik for lagring, søgning og henfald. Hvert lag bidrager til at gøre agenten nyttig over tid.
Mønstrene, der betyder noget:
- Konservativ ekstraktion (hallucinér ikke fakta).
- Konfidensbaseret læring (lær ikke fra afslappede kommentarer).
- Aktiv glemning (henfald og beskæring).
- Brugerkontrol (gennemsigtighed og redigerbarhed).
- Databeskyttelseshåndhævelse (på hvert lag).
Når systemet består evalueringer og livscyklustest, kan hukommelse reducere behovet for gentagne introduktioner og gøre bekræftede præferencer tilgængelige på tværs af sessioner.
For agenter, der kræver kontinuitet på tværs af sessioner, er persistens et udtrykkeligt produktvalg. Byg kun det hukommelseslag, der er berettiget, med dokumenteret oprindelse, autorisation, brugerkontrol og en afprøvet proces for udfasning og sletning.
