Minne och kunskap

Vad minnet är till för

Utan minne börjar varje agentkonversation från noll: samma konvention måste förklaras igen, samma beslut omprövas, samma återvändsgränd utforskas på nytt. Minnet är det arbetsytespecifika lager som överlever körningar, och det finns för att kunskap som en agent producerar ska gå att hitta av en annan senare.

Det har tre nivåer och de svarar på olika frågor:

1. Fakta — vad som är sant (en konvention, ett utfall, ett beslut).
2. Policyer — vad agenterna måste göra åt det (en normativ regel).
3. Arbetsminne — vad en enskild agent var mitt uppe i.

Skillnaden spelar roll eftersom de når agenten på olika vägar. Fakta söks upp. Policyer skjuts in. Arbetsminnet är privat.

Fakta

En MemoryFact är en kunskapsenhet med en arbetsyta och en domän som omfång.

Attribut	Vad det är
domain	Kunskapsdomänen (“conventions”, “decisions”, “codebase”)
topic	En kort ämnesetikett
content	Själva kunskapstexten
confidence	0,0–1,0, sätts från proveniensen och höjs vid nytt omnämnande
memoryType	Faktans typ — styr dess tidsmässiga avklingningskurva
veracity	Hur den blev känd — sätter startvärdet för tillförlitligheten och bestämmer storleken på varje höjning vid nytt omnämnande
sourceObservationIds	Vilka observationer som ledde fram till den
supersededBy	Den nyare fakta som ersatte den, om någon
validUntil, recallCount, mentionCount	Utgångs- och användningssignaler som används vid återkallning

De två sista raderna är de som folk missar, och de avgör vilken fakta som dyker upp. memoryType bär Weibull-avklingningsparametrar per typ, så ett tidsbegränsat åtagande bleknar snabbt medan en stabil profilfakta inte gör det. veracity registrerar proveniensen — angiven av en människa (vikt 1,0), härledd av en agent (0,7), producerad av ett verktyg (0,5), importerad (0,6) — och den vikten sätter faktans startvärde för tillförlitlighet.

Fakta redigeras aldrig på plats när de motsägs. Att skriva en fakta kör konfliktdetektering mot fakta i samma domän och med samma ämne och ersätter förloraren, samtidigt som en konfliktrad registreras. Spårbarheten är själva poängen: du kan alltid se vad som ansågs vara sant tidigare och vad som ersatte det.

Policyer

En MemoryPolicy är en normativ regel som härleds från fakta, med en arbetsyta och en domän som omfång, och med en aktiv-flagga och en valfri requiredRole.

Varje aktiv policy i arbetsytan injiceras i varje dispatch, ofiltrerad — ingen filtrering efter domän, roll, uppgift eller yta. Det är värt att veta innan du skriver din tjugonde policy, eftersom policyer konkurrerar om samma kontextfönster som uppgiften. Det är också därför requiredRole på en policy är rådgivande: det beskriver vem regeln riktar sig till, men det hindrar inte att regeln når alla andra.

Domäner

En MemoryDomain grupperar fakta och policyer inom en arbetsyta. Domäner ger kunskapen organisatorisk struktur och de är den enhet som åtkomstbehörigheter skrivs mot — men läs varningen nedan innan du behandlar en domän som en sekretessgräns.

En domän är antingen arbetsyteövergripande (architecture) eller begränsad till ett enskilt repo (repo:<slug>/architecture). Samma namn i båda omfången är två oberoende lager: en fakta som gäller för en kodbas skriver inte över den arbetsyteövergripande. search_memory och dispatchpreambeln rangordnar repobegränsat minne först när agenten arbetar i det repot; de filtrerar inte bort resten. Skicka repo till propose_fact / propose_policy / search_memory för att skriva till eller lyfta det omfånget.

Åtkomstkontroll är fail-open för läsningar

MemoryAccessGrant mappar en agentroll och en domän till en av tre behörighetsnivåer:

Behörighet	Betydelse
none	Ingen åtkomst
read	Kan söka och hämta fakta
write	Krävs av propose_policy. Faktaskrivningar (propose_fact, supersede_fact) är inte behörighetsstyrda

En saknad behörighet betyder läsning, inte nekande

När det inte finns någon behörighetsrad för ett (roll, domän)-par är den effektiva behörigheten read. Läsningar är fail-open av design. Den enda skrivning som kastar ett fel är propose_policy utan write-behörighet (InsufficientMemoryPermission). Att lägga känsligt innehåll i en minnesdomän begränsar inte vem som kan läsa det, om du inte uttryckligen har skrivit en none-behörighet för varje roll som inte bör se det.

Det finns inte heller något gränssnitt för behörigheter någonstans i produkten i dag. Minneskärmen har flikarna Fakta, Policyer och Kunskapsgraf och inget annat; behörigheter går bara att nå via RPC-oparna memory_access_grant.*.

Asymmetrin — mjuk för läsningar, hård för policyskrivningar — är ett medvetet avvägande. Minnet är mest användbart när det cirkulerar, och ett nekande av en läsning ger en agent som tyst vet mindre i stället för en som rapporterar ett problem. Ett nekande av en policyskrivning är däremot högljutt och går att rätta, så det är där framtvingandet ligger. En nyskapad domän får write som startvärde för varje roll; att strama åt det i efterhand är en ändring som bara går via RPC, eftersom det inte finns något behörighetsgränssnitt.

Arbetsminne

Varje agent har ett AgentWorkingMemory: ett fritextkladdblock som är nycklat på arbetsyta och agent. Det består mellan körningar, är privat för den agenten och injiceras i dess prompt vid varje dispatch. Det är där “jag var halvvägs genom att refaktorera auth” bor — tillståndet som är värt att ta med till nästa körning men inte värt att befordra till en varaktig fakta.

Vad som faktiskt når en agents prompt

Vid dispatch sätts minnespreambeln ihop av exakt tre saker:

• Varje aktiv policy i arbetsytan, som - [domain] rule-rader.
• Agentens eget arbetsminne, ordagrant.
• En nyckelordsmatchad kortlista över fakta för den här uppgiften — högst fem, inom en budget på cirka 1 200 tecken och bara när uppgiftsbeskrivningen är minst 20 tecken lång. Kortare uppgifter får inga fakta alls.

Kortlistan är enbart FTS/nyckelord och den är begränsad med avsikt. Att beräkna en inbäddning av en fråga är långsamt, och dispatchvägen är den enda plats där latensen syns direkt, så den långsamma semantiska vägen hålls medvetet borta från den. Preambeln avslutas med att be agenten verifiera bärande punkter med search_memory, vilket är där den fullständiga återkallningsmodellen finns.

Inga åtkomstbehörigheter konsulteras på den här vägen. Vad kortlistan än hittar är det agenten ser.

Återkallning: en fråga, fyra röster

Verktyget search_memory som agenten använder har tre lägen, och de är genuint olika sökningar:

• keyword — endast FTS5.
• semantic — BM25- och vektorresultat sammanslagna med reciprocal rank fusion.
• hybrid (standard) — polyfonisk återkallning: fyra rangordnade röster slås samman och diversifieras sedan.

De fyra rösterna är lexikala (FTS), semantiska (vektor-KNN), tidsmässiga (nyligen aktiva fakta) och graf — en vandring på två hopp över episodiska kanter från de starkaste lexikala och semantiska utgångspunkterna. Grafrösten är anledningen till att episodiska kanter finns över huvud taget: den lyfter fram den fakta som är kopplad till ditt svar utan att matcha något av dina ord. Rösterna viktas efter en klassificerad frågeavsikt (semantisk väger tyngst som standard, sedan graf och lexikal, sedan färskhet), varje kandidats poäng skalas med dess Weibull-avklingning, och resultatmängden MMR-diversifieras så att fem omskrivningar av en och samma fakta inte tränger undan fyra olika.

Semantisk återkallning är tyst tills modellen är installerad

Vektorrösten bidrar först när inbäddningsmodellen på enheten har laddats ner. Fram tills dess kör hybridåterkallning med tre röster, och det finns ingen retroaktiv efterfyllning — fakta som skrevs innan modellen installerades får aldrig några vektorer. Vektorvägen försämras ytterligare, till en skanning i Dart över de packade inbäddningarna, om själva SQLite-vektorutökningen inte kan läsas in; återkallningen svarar fortfarande, bara långsammare.

Minnesökningen i skrivbords- och webbklienten är en separat, enklare väg: RPC-op:en memory_fact.search är enbart FTS5, eftersom en tunn klient inte kan skicka med en frågeinbäddning och hybridvägen förblir intern i värden. Rangordningen du ser i minnesbläddraren är alltså inte den rangordning en agent får från search_memory. Det är väntat, inte en bugg, men det betyder att “jag sökte och hittade det inte” i gränssnittet inte är bevis för att agenten inte kommer att hitta det.

Var minnet finns och vem som skriver det

Minnesbläddraren finns under Inställningar → Arbetsyta → Minne (/workspaces/<id>/settings/memory), med flikarna Fakta, Policyer och Kunskapsgraf.

Det finns en asymmetri där som förvånar folk: du kan redigera och ta bort minne, men du kan inte skapa det. Varken fliken Fakta eller fliken Policyer har något sätt att lägga till. Författandet sker på agentsidan, via propose_fact och propose_policy (supersede_fact / supersede_policy för att ersätta dem). remember skriver ett sessionsbundet objekt på hot-tier-nivån som consolidate_memory senare kan befordra till en fakta; record_observation och update_my_notes skriver det privata kladdblocket som injiceras vid dispatch. Bläddraren är en yta för granskning och rättning, inte för författande — så om du vill ha en fakta i minnet är sättet att få dit den att säga till en agent.

Två underhållsoperationer anropas på samma sätt av agenter i stället för att schemaläggas: consolidate_memory slår samman och rensar uppsamlade fakta, och harmonize_memory stämmer av övertygelser som har glidit isär mellan agenter. list_memory_conflicts visar vad konfliktdetekteringen redan har registrerat. Inget kör dem åt dig på en timer. Mötesbeslut skördas in i domänen decisions när ett persisteringssteg för ett möte registrerar dem; det är ingen timer för slutförda agentkörningar.

Relaterade koncept

• Agentmodellen: rollerna är det som behörigheter skrivs mot
• Arbetsytor och isolering: minnet är arbetsytespecifikt och ligger i arbetsytans egen databasfil
• Hantera arbetsytans minne: att arbeta med minnet i praktiken