Memória és tudás

Mire való a memória

Memória nélkül minden ügynökbeszélgetés nulláról indul: ugyanazt a konvenciót kell újra elmagyarázni, ugyanazt a döntést újra megtárgyalni, ugyanazt a zsákutcát újra felfedezni. A memória a munkaterület szintű tároló, amely túléli a futásokat, és azért létezik, hogy az egyik ügynök által megtermelt tudás később egy másik számára megtalálható legyen.

Három rétege van, és ezek különböző kérdésekre válaszolnak:

1. Tények — mi igaz (egy konvenció, egy eredmény, egy döntés).
2. Szabályzatok — mit kell tenniük velük az ügynököknek (egy normatív szabály).
3. Munkamemória — mi van éppen folyamatban egy ügynöknél.

A megkülönböztetés azért számít, mert különböző útvonalakon jutnak el az ügynökhöz. A tényeket kereséssel találjuk meg, a szabályzatokat a rendszer tolja az ügynök elé, a munkamemória pedig privát.

Tények

A MemoryFact egy munkaterülethez és egy domainhez rendelt tudásegység.

Attribútum	Mit jelent
domain	A tudás domainje („conventions”, „decisions”, „codebase”)
topic	Rövid témacímke
content	A tudásszöveg
confidence	0.0–1.0, a származásból indul, és az ismételt említés növeli
memoryType	A tény fajtája — ez vezérli az időbeli lecsengési görbéjét
veracity	Hogyan vált ismertté — ez adja a kezdő bizalmi szintet, és ez szabja meg az egyes ismételt említések növelésének mértékét
sourceObservationIds	Mely megfigyelések vezettek hozzá
supersededBy	Az őt felváltó újabb tény, ha van ilyen
validUntil, recallCount, mentionCount	Lejárati és használati jelzések, amelyeket az előhívás használ

Az utolsó két sort szokták figyelmen kívül hagyni, pedig ezek döntik el, melyik tény kerül a felszínre. A memoryType típusonkénti Weibull-lecsengési paramétereket hordoz, így egy időhöz kötött vállalás gyorsan elhalványul, egy stabil profiltény viszont nem. A veracity a származást rögzíti — ember állította (1.0 súly), ügynök következtetett rá (0.7), eszköz állította elő (0.5), importálták (0.6) —, és ez a súly adja a tény kezdő bizalmi szintjét.

A tényeket soha nem szerkesztjük a helyükön, amikor ellentmondásba kerülnek. Egy tény írása konfliktusészlelést futtat az azonos domainű, azonos témájú tényekkel szemben, és felváltja a vesztest, közben rögzít egy konfliktussort. Az auditnapló a lényeg: mindig látod, mit tartottak igaznak korábban, és mi váltotta fel.

Szabályzatok

A MemoryPolicy a tényekből levezetett normatív szabály, amely egy munkaterülethez és egy domainhez kötődik, aktív jelzővel és opcionális requiredRole mezővel.

A munkaterület minden aktív szabályzata bekerül minden indításba, szűrés nélkül — nincs szűrés domain, szerep, feladat vagy tér szerint. Ezt érdemes tudni, mielőtt megírod a huszadik szabályzatodat, mert a szabályzatok ugyanazért a kontextusablakért versenyeznek, mint a feladat. Ez az oka annak is, hogy a szabályzaton a requiredRole csak tanácsadó jellegű: azt írja le, kinek szól a szabály, de nem akadályozza meg, hogy a szabály mindenki máshoz is eljusson.

Domainek

A MemoryDomain egy munkaterületen belül tényeket és szabályzatokat csoportosít. A domainek szervezeti szerkezetet adnak a tudásnak, és ezek az egységek, amelyekre a hozzáférési engedélyek íródnak — de mielőtt bizalmassági határként kezelnéd a domaint, olvasd el az alábbi figyelmeztetést.

Egy domain vagy munkaterület-szintű (architecture), vagy egyetlen tárolóra korlátozódik (repo:<slug>/architecture). Ugyanaz a név a két hatókörben két független tároló: egy tény, amely az egyik kódbázisra igaz, nem írja felül a munkaterület szintűt. A search_memory és az indítási preambulum a tárolóra korlátozott memóriát sorolja előre, amikor az ügynök abban a tárolóban dolgozik; a többit nem szűrik ki. Add meg a repo paramétert a propose_fact / propose_policy / search_memory hívásnál, hogy abba a hatókörbe írj, vagy növeld annak súlyát.

A hozzáférés-vezérlés olvasásnál fail-open

A MemoryAccessGrant egy ügynökszerepet és egy domaint képez le a három engedélyszint valamelyikére:

Engedély	Jelentés
none	Nincs hozzáférés
read	Kereshet és lekérdezhet tényeket
write	A propose_policy megköveteli. A tényírásokat (propose_fact, supersede_fact) nem kapuzza engedély

A hiányzó engedély olvasást jelent, nem elutasítást

Ha egy (role, domain) párhoz nincs engedélysor, a tényleges engedély a read. Az olvasás tervezésileg fail-open. Az egyetlen írás, amely kivételt dob, a propose_policy write engedély nélkül (InsufficientMemoryPermission). Ha érzékeny tartalmat teszel egy memóriadomainbe, az nem korlátozza, ki olvashatja, hacsak nem írtál kifejezetten none engedélyt minden olyan szerephez, amelynek nem szabad látnia.

A termékben ma egyébként sincs felület az engedélyekhez. A memóriaképernyőn a Tények, a Szabályzatok és a Tudásgráf fülek vannak, semmi más; az engedélyek csak a memory_access_grant.* RPC-műveleteken keresztül érhetők el.

Az aszimmetria — lágy az olvasásnál, kemény a szabályzatírásnál — szándékos kompromisszum. A memória akkor a leghasznosabb, ha kering, és egy olvasási elutasítás inkább egy csendben kevesebbet tudó ügynököt eredményez, mint egyet, amelyik problémát jelez. A szabályzatírás elutasítása ezzel szemben hangos és korrigálható, ezért az érvényesítés ott van. Az újonnan létrehozott domain minden szerephez write engedélyt vetít előre; ezt utólag szigorítani csak RPC-vel lehet, mert nincs engedélykezelő felület.

Munkamemória

Minden ügynöknek van egy AgentWorkingMemory-ja: egy munkaterület és az ügynök szerint kulcsolt szabad szöveges jegyzetfüzet. Futásokon át megmarad, az adott ügynök számára privát, és minden indításnál bekerül a promptjába. Itt él az „épp félúton voltam az auth refaktorálásában” típusú állapot — az, amit érdemes átvinni a következő futásba, de nem érdemes tartós ténnyé előléptetni.

Mi jut el valójában egy ügynök promptjába

Indításkor a memóriapreambulum pontosan három dologból áll össze:

• A munkaterület minden aktív szabályzata, - [domain] rule sorokként.
• Az ügynök saját munkamemóriája, szó szerint.
• A feladathoz kulcsszóra illeszkedő tények rövid listája — legfeljebb öt, körülbelül 1,200 karakteres kereten belül, és csak akkor, ha a feladat leírása legalább 20 karakter hosszú. A rövidebb feladatok egyáltalán nem kapnak tényeket.

A rövid lista csak FTS/kulcsszó alapú, és szándékosan van korlátozva. Egy lekérdezés beágyazása lassú, az indítási útvonal pedig az az egyetlen hely, ahol a késleltetés azonnal látható, ezért a lassú szemantikus útvonal szándékosan kimarad belőle. A preambulum azzal zárul, hogy az ügynök a search_memory segítségével ellenőrizze a lényeges elemeket, mert ott él a teljes előhívási modell.

Ezen az útvonalon a rendszer egyetlen hozzáférési engedélyt sem néz meg. Az ügynök azt látja, amit a rövid lista megtalál.

Előhívás: egy lekérdezés, négy hang

Az ügynökök felé nyitott search_memory eszköznek három módja van, és ezek valóban különböző keresések:

• keyword — csak FTS5.
• semantic — BM25- és vektortalálatok, amelyeket a reciprok rangfúzió módszerével vonunk össze.
• hybrid (az alapértelmezett) — polifonikus előhívás: négy rangsorolt hang összevonva, majd diverzifikálva.

A négy hang: lexikális (FTS), szemantikus (vektoros KNN), időbeli (nemrég aktív tények) és gráf — két lépéses bejárás az epizodikus éleken a legerősebb lexikális és szemantikus kiindulópontoktól. A gráf hang az oka annak, hogy egyáltalán léteznek epizodikus élek: felszínre hozza azt a tényt, amely kapcsolódik a válaszodhoz, anélkül hogy bármelyik szavadra illeszkedne. A hangokat egy osztályozott lekérdezési szándék súlyozza (alapértelmezésben a szemantikus viszi a legnagyobb súlyt, aztán a gráf és a lexikális, végül a frissesség), minden jelölt pontszámát a saját Weibull-lecsengése skálázza, az eredményhalmazt pedig MMR-rel diverzifikáljuk, hogy egy tény öt ismétlése ne szorítson ki négy különbözőt.

A szemantikus előhívás csendben marad, amíg a modell nincs telepítve

A vektoros hang csak akkor járul hozzá, ha az eszközön futó beágyazási modell már le van töltve. Addig a hibrid előhívás három hanggal fut, és nincs visszamenőleges feltöltés — a modell telepítése előtt írt tények soha nem kapnak vektorokat. A vektoros útvonal tovább romlik, egy Dartban futó beolvasásra a csomagolt beágyazások fölött, ha maga az SQLite vektorkiterjesztés sem töltődik be; az előhívás továbbra is válaszol, csak lassabban.

Az asztali és webes memóriakeresés külön, egyszerűbb útvonal: a memory_fact.search RPC-művelet csak FTS5-öt használ, mert egy vékony kliens nem tud lekérdezési beágyazást küldeni, a hibrid útvonal pedig a hoszton belül marad. Ezért a memóriaböngészőben látott rangsor nem azonos azzal, amelyet egy ügynök a search_memory-tól kap. Ez várható, nem hiba, de azt jelenti, hogy a felületen „kerestem és nem találtam meg” nem bizonyíték arra, hogy az ügynök sem fogja megtalálni.

Hol él a memória, és ki írja

A memóriaböngésző a Beállítások → Munkaterület → Memória helyen van (/workspaces/<id>/settings/memory), Tények, Szabályzatok és Tudásgráf fülekkel.

Van ott egy aszimmetria, amely meglepi az embereket: a memóriát szerkesztheted és törölheted, de nem hozhatod létre. Sem a Tények, sem a Szabályzatok fülön nincs hozzáadás lehetőség. A létrehozás ügynökoldali, a propose_fact és a propose_policy útján (supersede_fact / supersede_policy a lecserélésükhöz). A remember egy munkamenethez kötött, forró szintű elemet ír, amelyet a consolidate_memory később ténnyé léptethet elő; a record_observation és az update_my_notes az indításkor beinjektált privát jegyzetfüzetet írja. A böngésző átnézési és javítási felület, nem szerkesztői — tehát ha tényt szeretnél a memóriában, úgy tehetsz rá szert, hogy szólsz egy ügynöknek.

Két karbantartási művelet szintén ügynök hívja meg, nem ütemezett: a consolidate_memory összevonja és ritkítja a felhalmozódott tényeket, a harmonize_memory pedig összeegyezteti az ügynökök között széttartó meggyőződéseket. A list_memory_conflicts megmutatja, mit rögzített már a konfliktusészlelés. Ezeket semmi nem futtatja helyetted időzítővel. A megbeszélések döntései a decisions domainbe gyűlnek, amikor egy megbeszélés-mentési lépés rögzíti őket; ez nem egy időzítő a befejezett ügynökfutásokon.

Kapcsolódó fogalmak

• Az ügynökmodell: a szerepek azok, amelyekre az engedélyek íródnak
• Munkaterületek és elszigetelés: a memória munkaterület szintű, és az adott munkaterület saját adatbázisfájljában él
• Munkaterület-memória kezelése: a memóriával való munka a gyakorlatban