A mesterséges intelligencia-ügynökök megbízhatóságában központi szerepet játszik a kontextus. A VB Pulse júniusi felmérése szerint a vállalatok 57%-a azonosított már olyan, magabiztosan téves ügynökválaszt, amelynek gyökere hiányzó vagy ellentmondó kontextus volt — ez is azt mutatja, mennyire kritikus a kontextus kezelése, ha az ügynökök önállóan döntenek.
A legtöbb eddigi javítás egy szűkebb problémát kezelt: egyetlen ügynök emlékezzen tovább egy munkameneten belül. A hiányzó lépés az volt, hogy hogyan használhatna egyszerre ugyanazt a kontextust egy ügynökcsapat. A hiba súlyosbodik, ha egy rossz ténnyel nem egy személynek kell újra és újra magyaráznia, hanem az egész csapat ügynökei öröklik azt.
Agent Memory és Team Memory
A Tencent erre a kihívásra az Agent Memory nevű, nyílt forráskódú projekttel reagált, amely állítólag egy hat hónapos fejlesztés eredménye volt, miután a csapat hosszú munkamenetek közben elvesző kontextusokat javított. A rendszer egyik eleme egy persona-réteg: egy stabil, tömörített kép a felhasználóról, amely sok beszélgetésből épül fel, és nem kell minden alkalommal újra felépíteni.
Tencent saját benchmarkján, amely azt vizsgálta, hogy egy ügynök mennyire tartja fenn a persona-képet hosszan tartó használat után, az accurate (%) 48%-ról 76%-ra nőtt, ami 59% relatív javulást jelent a persona-réteg hozzáadásával.
Ezen a héten a Tencent kibővítette a projektet a Team Memory bétájával: ez a megközelítés nem egyetlen ügynökre, hanem egy teljes csapatra nyitja meg ugyanazt a megosztott memóriát. A GitHubon a projekt repository-ja a TypeScript trending listájának No.1 helyére került a héten.
Mit csinál a Team Memory valójában?
A Team Memory alapötlete: megosztott hub a megosztott prompt helyett. Ahelyett, hogy egy nagy kontextustömböt másolnának minden ügynökbe, a rendszer négy újrafelhasználható eszközosztályt regisztrál, és minden ügynök csak azokat kapja meg, amelyekre szüksége van:
- Chat Memory: megőrzi a preferenciákat, tényeket, döntéseket és az interakciós előzményeket, négy rétegen keresztül tömörítve, a nyers beszélgetéstől a stabil, hosszú távú personáig.
- Skill: eljárásokat rögzít elkészült munkákból, verziózva és review-olva, mielőtt megosztanák.
- LLM-Wiki: dokumentumokat és specifikációkat strukturált, összekapcsolt oldalakká alakít.
- Code-Graph: indexeli a kódbázis szimbólumait, fájljait és híváskapcsolatait, hogy az ügynök ellenőrizhesse, mit érinthet egy változtatás.
A Tencent dokumentációja világosan különbséget tesz: „A RAG (retrieval-augmented generation) megválaszolja, hogy 'mi található meg?' A Team Memory azt is megválaszolja, hogy 'ki használhatja, mely verzió érvényes, és melyik ügynök kapja meg'."
Gyakorlatban az ügynökök "Agent Loadout"-okat kapnak: például egy Scout (kutató) ügynök piackutatási és versenytárselemzési eszközöket kaphat, míg egy Builder (fejlesztő) ügynök a Code-Graphot és a termékdokumentációt.
Láthatósági rétegek és alapértelmezett beállítások
Az eszközökhöz való hozzáférést négy láthatósági szint szabályozza:
- Private: csak az eszköz tulajdonosa olvashatja.
- Team: a csapat bármely tagja olvashatja.
- Restricted: felhasználó-, szerep- vagy ügynökszintű hozzáférés-vezérléssel gate-elve.
- Agent: egy konkrét ügynök számára felszerelve.
Új eszközök alapértelmezettként privátok, tehát a megosztás tudatos művelet kell legyen, nem automatikus.
Mi történik, ha egy memória téves?
A láthatósági modell azt szabályozza, ki olvashat egy memóriát, de nem válaszol arra a fontos kérdésre, mi történik, ha egy memóriaeszköz hibásnak bizonyul. A Tencent dokumentációja leírja az ownershipet, verziózást és státuszkövetést minden eszközre, de nem részletez javítási vagy lejárati folyamatot arra az esetre, ha egy tényt már elolvastak és újrahasznosítottak más ügynökök, illetve nincs leírás arról sem, hogyan lehet feloldani az eltérő emlékek közti ellentmondást.
Ezt a hiányt a szakmabeliek gyorsan jelezték a bejelentés után. "A megosztott memória esetén az írási útvonal jelenti az érdekes problémát. A lekérés kapja a legtöbb figyelmet, de egy rossz tény, amelyet egyszer írnak be, most az összes csapattárs ügynökéhez jut el ahelyett, hogy csak a tiédre hatna. Kíváncsi vagyok, hogyan kezeli a kormányzati réteg a javítást és a lejáratot," írta Blake Murphy X-en.
A probléma nem csak a tévedés későbbi javításáról szólt, hanem arról is, ki dönt arról, mi kerül be egyáltalán a feljegyzésbe. "A kormányzott rész a nehéz. Amint a csapattársak ügynökei olvashatják egymás kontextusát, valakinek döntenie kell arról, mi nem kerülhet feljegyzésre," írta Virgil Maro X-en.
Többen a közvetlen ellentmondásokra hívták fel a figyelmet: mi történik, ha két ügynök ellentétes tényeket ír ugyanarról a modulról? "A Code-Graph + LLM-Wiki felosztás jó döntés. Amit benchmarkolnék: megosztott módban kinek az emléke nyer, ha két csapattag ügynöke ellentmondó tényeket írt ugyanarról a modulról? Az egyedi ügynök memória lassan kúszik el, a megosztott memória gyorsan driftel, mert egy elavult írás elterjed olyanokhoz is, akik nem látták az eredeti munkamenetet," írta Austin Green X-en.
Az észrevételek között akadt támogatóbb hang is: "Érdekes váltás: a memória megosztott szolgáltatássá tétele valós csapattá formálja az ügynököket ahelyett, hogy elszigetelt botok lennének. A kormányzás lesz a legnehezebb rész, különösen amikor tények ütköznek," írta Moez Zhioua X-en.
Nem csak Tencent problémája
Ezek a felvetések nem csak a Tencent implementációjára korlátozódnak. Egy 2026. márciusi, függetlenül publikált tanulmány, "Governed Memory: A Production Architecture for Multi-Agent Workflows," a megosztott többügynökös memória rendszerekben strukturális kockázatként azonosítja a kormányzási fragmentációt és a csendes minőségromlást visszajelzési hurkok hiányában. A tanulmány mintázata megfelel annak a kritikának, hogy egyetlen ügynök memóriájában lévő téves tétel egy felhasználónak többszöri javítást jelent, míg a csapat-szintű memóriában ugyanaz a tétel széles körben terjedhet, mielőtt bárki észrevenné.
Hogyan viszonyul a Team Memory a többi megoldáshoz?
A 2026-os ügynök-memória fejlesztések többsége eddig egyetlen ügynök memória-képességeinek növelésére koncentrált: ilyenek a LangChain LangMem SDK-ja, a Google Always On Memory Agentje és Anthropic munkája a Claude Agent SDK-n belül. Egy másik irány az üzleti adatokra épülő megosztott kontextusmodellekhez ad hozzáférést; a VB júniusi felmérése szerint csak 25% volt azon vállalatok aránya, amelyeknél ilyen kormányzott kontextusréteg termelésben van. Az év során több beszállító — köztük AWS, Couchbase, Oracle, Redis és Pinecone — is kiadott hasonló megoldásokat.
A Team Memory talán legközelebbi összehasonlítása az Asana munkája: Asana korábban megvalósított közös memóriát a vállalati AI-csapatoknak, hogy egy ügynök ne legyen újra felbriefelve olyan kontextusért, amelyet már egy másik ügynök ismer. Asana hozzáállása hasonló kompromisszumokat tárgyalt: egy hozzáférésvezérlési rendszerre van szükség, amely megakadályozza, hogy egy ügynök memóriája kikerüljön olyan projektekbe, amelyekhez nincs jogosultsága. A Tencent verziója nyílt forráskódú és keretrendszer-független, míg Asana megoldása zárt volt és egy platformhoz kötött.
Összegzés
A Team Memory valós előnyt kínál: az ügynököknek nem kell újból megtanulniuk, amit a csapat már tud. Ugyanakkor a kompromisszum is egyértelmű: egy rossz bejegyzés mostantól nem egyetlen ügynöknél okoz problémát, hanem azoknál az összes ügynöknél, amelyek a megosztott adatbázisból olvasnak — és jelenleg nincs részletes javítási vagy lejárati mechanizmus leírva arra az esetre, ha ilyen hiba fordul elő.
A gyakorlati bevezetés sikerét így nem csak a technikai megvalósítás, hanem a kormányzási döntések (ki írhat, mit, mikor és hogyan lehet javítani vagy lejáratni) fogják meghatározni a következő hónapokban.
