Agenter taber tråden. Ikke altid, men ofte nok til at det gør ondt i produktion. Derfor er Tencents udgivelse af TencentDB Agent Memory interessant: open source under MIT-licens, et lokalt 4-lags hukommelseslag, der adresserer kontekst-bloat og hukommelsessvigt i lange forløb. Standard-backend er SQLite med sqlite-vec, ingen ekstern API er påkrævet, og der findes integrationer til OpenClaw og Hermes. For virksomheder betyder det en lav tærskel for at prøve det af og potentielt færre tokens, mere stabile svar.
Vi har selv siddet med supportlogik en sen torsdag og set en agent ignorere et versionsnummer i tredje sætning. Der knækkede filmen. Derfor læser vi Tencents udgivelse med et pragmatisk blik: Hvad kan man bygge nu. Hvad går i stykker i drift. Og hvor er hullerne.
Hvorfor agenthukommelse stadig gør ondt
Mange stakke smider data i en flad vector store. Retrieval bliver et top-k kompromis, der kan klippe afgørende spor fra, før agenten overhovedet tænker. VentureBeat peger på samme flaskehals i dækningen af agentiske arbejdsgange: ofte er det retrieval-grænsefladen, ikke modellen, der kvæler processen. Vi genkender mønsteret. Semantisk søgning er stærk til ligheder, men skrøbelig ved eksakte strenge, versionsnumre og fejlkoder.
Resultatet er for mange tokens på gentagelser og små, dyre fejl. Når sessioner strækker sig over mange trin, stiger presset. Der opstår kontekst-bloat, og så vælter det. Vi har set det i kundeservice-workflows og i MLOps-drift, hvor de lange spor driller.
Hvad TencentDB Agent Memory tilbyder
Tencent bygger en 4-lags pyramide i stedet for én flad log. L0 er Conversation (rå dialog). L1 er Atoms (små fakta). L2 er Scenario (scene- eller blokniveau). L3 er Persona (løbende brugerprofil). Persona forespørges først. Systemet borer sig derefter deterministisk ned i lagene til Atoms eller rå samtale, når der mangler detaljer. Øverst ligger struktur, nederst evidens. Den hierarkiske tilgang hjælper med at holde kontekstvinduet slankt.
Retrieval er hybrid: BM25 for nøgleord, embeddings for semantik og fusion via Reciprocal Rank Fusion. Man kan skifte til ren nøgleord eller ren embedding med en konfiguration. Tokenizer dækker både kinesisk og engelsk.
Symbolsk korttidshukommelse og offloading
Lange sessioner koster, fordi værktøjslogs, søgninger, kode og stack traces æder konteksten. Her offloader Tencent fulde værktøjslogs til refs/*.md og gemmer tilstandsændringer i Mermaid-syntax i et let task-canvas. Agenten ræsonnerer på symbolet, og når der skal slås op i rå tekst, henter den filen via node-id. Det gør korttidshukommelsen symbolsk og billig.
Gennemsigtigheden i fejlsøgning er en reel gevinst. Når man kan følge en Mermaid-graf fra beslutning til kildefil, bliver det nemmere at reproducere en fejl og diskutere den i teamet. Det kræver dog værktøjer. refs-filer vokser; uden plan for oprydning og søgbarhed er der rod på uger, ikke måneder.
Opbevaring og deployment
Lageret er heterogent. Fakta, logs og traces ender i databaser til fuldtekstsøgning. Personas, scener og canvases ligger som læsbar Markdown. Standardlayoutet bor under stien ~/.openclaw/memory-tdai/. Default-backend er lokal SQLite med sqlite-vec, så man kan køre uden netværk eller eksterne API’er. For teams med on-premise-krav eller begrænset netværk er det et plus.
Der er også tradeoffs. Lokal SQLite er ikke skabt til høj samtidighed. I et Snilld proof-of-concept med lokal SQLite og flere samtidige skrivninger så vi synkroniseringsproblemer. Backup og restore skal tænkes ind fra dag ét. Og hvis Markdown-filer bliver en del af governance, kræver det review-processer, adgangsstyring og maskering, når persona-tekster kan indeholde personoplysninger. Det er ikke en fejl i projektet, det er driftsarbejde.
Integrationer og de første anvendelser
OpenClaw-integration leveres som et npm-plugin, der håndterer samtalefangst, memory extraction, scene-aggregation, persona-generering og recall. Kravet er Node 22.16 eller nyere. For Hermes findes en Docker-image med agent, plugin og gateway. Default-model er Tencents egen, men en OpenAI-kompatibel endpoint kan kobles på via en variabel. Det er tænkt som en komponent, man kan skrue på – ikke et nyt orkestreringsunivers.
Vi har set to oplagte cases i dansk praksis. En intern IT-supportassistent i en større organisation, som gentog det samme triage-spørgsmål fem gange om dagen. Med løbende persona-opdateringer og en strammere L1-udtrækning faldt gentagelserne, og medarbejderne slap for at copy-paste ticket-id’er. Den anden var en MLOps-pipeline, hvor build-logs tidligere slugte tokens og alligevel blev misforstået. Symbolsk offloading gjorde forskellen; agenten hentede kun de relevante node-id referencer, da fejlen skiftede fra CUDA til versionskonflikt. Småt på papiret, men mærkbart i drift.
Hvad tallene siger, og hvad de ikke siger
Tencent rapporterer forbedringer på tværs af flere scenarier målt over lange sessioner. På WideSearch går pass-raten fra 33 til 50 procent (relativt løft ~51 procent), mens tokenforbrug falder cirka 61 procent. På SWE-bench stiger succes fra 58,4 til 64,2 procent, og tokens falder cirka en tredjedel. AA-LCR løftes også, og PersonaMem-accuracy går fra 48 til 76 procent. Tallene stammer fra Tencents egne evalueringer; uafhængig reproduktion mangler.
For dig betyder det: brug dem som pejlemærker, ikke sandheder. Test i egen pipeline, over mindst 30–50 opgaver pr. session, hvor kontekstpresset faktisk bygger sig op. Først dér ser man, om tokenfald og succesløft er reelle i egne datasæt.
Fordele og begrænsninger i hverdagen
Fordele: lav latency ved lokal kørsel, offline-muligheder til lukkede miljøer, gennemsigtige beslutningsspor via Mermaid og refs, og en deterministisk drill-down fra persona til scene til fakta, der holder konteksten skarp.
Begrænsninger: skalerbarhed i multi-user opsætninger med SQLite kræver omhu og måske skift til managed vector store eller fuld database ved høj samtidighed. Konsistens og merges af Markdown-baserede personas på tværs af brugere er ikke gratis. Backup og livscyklusstyring for ~/.openclaw/memory-tdai/ skal defineres, ellers ender man med halvglemte filer og compliance-hovedpine. Og i visse brancher kan leverandørvalg være politisk følsomt, hvilket kan pege mod lokal fork og stram data governance.
Hvad det betyder for workflows
For kundeservice betyder L3 Persona-laget, at præferencer og historik ligger i menneskelæsbart format. Revision og kvalitetssikring bliver enklere. En teamleder kan læse, hvad assistenten antager om kundepræferencer, og rette i en fil – ikke i en skjult embedding.
For interne arbejdsgange handler gevinsten om stabilitet over mange små skridt. Når L1-udtræk sker med faste intervaller, og persona dannes efter en mængde nye minder, reduceres gentagelser og utilsigtede kontekstskift. I en procurement-sag, hvor sagsnumre og leverandørnavne flyver rundt, kan det være forskellen på at ramme første forsøg eller bruge fem ekstra minutter. De små sejre flytter ROI.
Test og måling før man tror
En konkret opskrift, vi anbefaler: kør lang-session-scenarier på mindst 50 opgaver per session med kendte fælder som versionsnumre, fejlkoder og modstridende logs. Mål tre ting: succesrate (pass-rate på definerede opgaver), samlet tokenforbrug og tid til første korrekte handling. Log hentninger fra tdai_memory_search og tdai_conversation_search og stikprøvekontrollér, at recall faktisk rammer relevante refs via node-id. Ellers får man pæne grafer uden rigtige svar.
Versionér memory-artefakter. Læg migreringer i CI. Behandl backup af ~/.openclaw/memory-tdai/ som en first-class ressource. Få styr på retention-politikker for Markdown-personas, inkl. masking af eventuelle persondata. Bagudrettet sikkerhed er dyrere.
Skaleringsveje, når succes vokser
Start lokalt på SQLite for hastighed og enkelhed. Når samtidigheden stiger, mål hotspots: write-locks i SQLite eller recall-latens i sqlite-vec. Skift udvalgte komponenter gradvist – fx managed vector store for embeddings, mens Markdown-filer bliver, eller fuld database for logs og traces. Bevar pyramiden, gør infrastrukturen under mere industriel.
Overvej også multi-node synkronisering. Filbaseret persona-governance kan versionstyres via git-lignende workflows, men så kræves klare regler for merges og konflikter. Her snubler det hurtigt, hvis flere teams skriver i samme profiler uden ejerskab og review.
Hvad konkurrenter vil sige, og hvad vi er delvist uenige i
Nogle vil pege på, at en flad vector store med god chunking er nok, og at ekstra lag blot flytter kompleksitet. En dårlig implementering kan gøre det værre, ja. Men i praksis mangler der typisk struktur og deterministisk adgang til evidens. Hybrid retrieval med en klar pyramide adresserer netop det. Og Mermaid-canvas giver en fejlsøgningssti, som RAG alene sjældent leverer.
Andre vil sige, at interne benchmarks ikke tæller. Fair – så reproducér dem selv. Retningen mod at måle over lange sessioner i stedet for enkeltspørgsmål er dog rigtig. Vi har ikke set agenter lykkes i produktion uden netop den måling.
Åbne spørgsmål, vi stadig mangler svar på
Hvordan skalerer sqlite-vec med millioner af rækker. Hvad med multi-user synkronisering og konflikter i standardlayoutet. Og hvordan ser bidragsmodellen ud, hvis communityet tager projektet til sig. Det bør være afklaret før produktion i høj volumen.
Derudover mangler en færdig playbook for sikkerhed omkring Markdown-baserede personas: kryptering i hvile, adgangskontrol og definerede retention-regler. Vi supplerer typisk med egne mønstre, men det ville være rart at se direkte i projektets docs, når flere virksomheder skal ind.
Tre næste skridt
1) Kør en 6-ugers PoC med lange sessioner og hårde edge-cases, og mål succesrate, tokens og tid til første korrekte handling. 2) Lav en governance-plan for Markdown-personas: adgang, masking og retention. 3) Definér skaleringstriggere: hvornår skifter I fra lokal SQLite til managed lagre, og hvordan håndteres backup og synkronisering.
Vi kan hjælpe med workshops, PoC og MLOps-integration – og vi insisterer på målinger før begejstring. Man opdager forskellen, når man sidder med det i hænderne.
