Warstwowy kontekst: Hierarchia wiedzy dla agentów AI

Agent z jednym, spłaszczonym plikiem pamięci nie zapomina rzeczy; raczej nie potrafi przestać pamiętać o rzeczach, o które nie został poproszony. Rozwiązaniem jest warstwowy kontekst, w którym każda warstwa wiedzy wchodzi do kontekstu za pomocą innego wyzwalacza.

Tryb błędu polega nie na zapominaniu, lecz na jego przeciwieństwie. W jednym spłaszczonym magazynie każdy fakt znajduje się w tym samym miejscu, wchodzi do kontekstu w ten sam sposób i jest więc dostępny w ten sam sposób — zawsze. Zapytaj agenta o e-maila od klienta, a przy tworzeniu odpowiedzi będzie opowiadał o konfiguracji routera; poproś go o diagnostykę usługi, a wspomni o stawce za sponsoring zacytowanej w ubiegłym miesiącu. Stos pamięci jest monolitem: każda zmiana jednej kwestii dotyka każdej innej, a zasięg rażenia każdego zapytania to cały korpus.

Standardowa rada ma charakter behawioralny: naucz agenta, co jest istotne dla bieżącego tematu. To jest oprogramieniowy odpowiednik wypisania „bądź ostrożny” na murze nośnym — agenta można poinstruować i w większości przypadków będzie się stosować, aż do dnia, w którym tak nie będzie. Alternatywą strukturalną jest wiedza, która nie może wejść do rozmowy, jeśli nie odbywa się już aktywność, której ta wiedza jest potrzebna. Ten artykuł definiuje taką strukturę jako pięciowarstwową hierarchię wiedzy — co to jest każda warstwa, co wyzwala jej wstrzykiwanie, co do niej należy i gdzie się zawodzi — i aplikuje ją do konkretnego, wielozakresowego ustawienia: jeden profil ogólny, jeden na domowy serwerownia (homelab), jeden na sprawy osobiste, jeden na pracę, jeden na edukację.

Nazewnictwo hierarchii

Nie ma jednego standardu branżowego, więc definicja tutaj jest jawna. Hierarchia wiedzy to warstwowe ułożenie tego, co agent wie, w którym każda warstwa różni się trzema właściwościami: sposobem, w jaki wchodzi do kontekstu modelu, dozwoloną wielkością i tym, jak długo ma być poprawna. Na poziomie architektury wiedzy sąsiednie paradygmaty — PKM, RAG, wiki i systemy pamięci — są porównane w PKM vs RAG vs Wiki vs Systemy Pamięci, a kontrakty runtime, które faktycznie implementują asystenci, są odwzorowane w Systemy Pamięci w Asystentach AI. Oba znajdują się wewnątrz Zarządzanie Wiedzą cluster, który obejmuje fundamenty, metody i narzędzia ludzkich systemów wiedzy. Ten artykuł dodaje klasyfikację opartą na wyzwalaczach oraz granicę profilu, które czynią umieszczanie wymuszalnym.

Dwie tradycje wyjaśniają kształt hierarchii.

Pierwszą jest hierarchia pamięci CPU. Procesor nie przechowuje każdego bajtu, którego może kiedykolwiek potrzebować, w tym samym rejestrze. Ma cache L1 — mały, zawsze zamieszkany, dostępny bez podejmowania decyzji — L2, pamięć główną i dysk, każda warstwa większa, wolniejsza w dostępie i dostępana tylko wtedy, gdy warstwy wyższe nie mają odpowiedzi. Regułą projektową nie jest „trzymaj wszystko szybko”. To większość danych rzadko ma znaczenie; płac koszty dostępu tylko wtedy, gdy ma. Agent z jednym spłaszczonym plikiem pamięci jest CPU, w którym wszystko jest wciśnięte do L1: plik rejestrów jest ogromny, więc wszystko jest widoczne, w tym bajty, o które bieżąca instrukcja nie prosiła. MemGPT dokonał tego samego ruchu dla agentów, modelując pamięć jako warstwy z jawnym przemieszczaniem między szybki a wolnymi magazynami.

Drugą jest taksonomia pamięci kognitywnej, która dzieli wiedzę na pamięć proceduralną (jak wykonywać rzeczy), semantyczną (fakty o świecie) i epizodyczną (co się wydarzyło, kiedy, komu). Taksonomia ma znaczenie, ponieważ tryby błędów różnią się w zależności od typu: przestarzała wiedza proceduralna to błąd w twoim workflow, przestarzała wiedza semantyczna to błędny fakt, a wyciek wiedzy epizodycznej to incydent prywatności. Hierarchia zorganizowana według typu treści, a nie lokalizacji, mówi, które błędy są niebezpieczne.

Oś organizującą tego artykułu nie jest żadna z powyższych. Klasyfikuj wiedzę według tego, co powoduje jej wejście do kontekstu. Wyzwalaczem wstrzykiwania jest mechanizm, a mechanizmem jest to, co faktycznie możesz wymusić. System agenta oferuje dokładnie cztery wyzwalacze:

• Zawsze. Wstrzykiwane do każdej tury, bezwarunkowo.
• Wyzwalacz zadania. Ładowane, gdy bieżąca aktywność odpowiada zadeklarowanemu warunkowi.
• Odzyskiwanie semantyczne. Wywoływane, gdy bieżąca wiadomość jest podobna do czegoś, co jest przechowywane.
• Jawne odniesienie. Pobierane, ponieważ zadanie nazywa plik lub zapytanie.

Każda warstwa hierarchii jest zdefiniowana przez to, który wyzwalacz ją zasilają. To jest cały projekt, a reszta tego artykułu jest rozwinięciem jednej tabeli.

Pięć warstw

Czytaj tabelę w dół kolumny wyzwalaczy, nie w poprzek. Warstwa 0 i Warstwa 1 to cache L1: płacą za swój przywilej stałej rezydencji, będąc miniaturowymi. Warstwa 2 to cache instrukcji: wyciągane przy warunkie gałęzi, gdy zadanie pasuje do wyzwalacza umiejętności. Warstwa 3 to dysk: może być ogromna, ponieważ nic nie wchodzi do kontekstu, aż do momentu, gdy krok zadania jawnie odczyta nazwany plik. Warstwa 4 jest niewygodna — to jest pamięć główna, dostępana przez podobieństwo, co jest jedynym wyzwalaczem na liście, który nie angażuje decyzji podjętej przez ciebie lub przez zadanie. Podobieństwo to brama probabilistyczna, i dlatego wymaga najsurowszych zewnętrznych kontroli, które zapewnia sekcja o profilach. Obraz szafki na górze tego artykułu koduje ten sam pomysł: im wyżej znajduje się poziom, tym swobodniej jego zawartość wchodzi do rozmowy, a szklana przegroda oznacza, gdzie kończy się półka jednej domeny.

Warstwa 0: tożsamość

SOUL.md, lub jak twój agent nazywa swój prompt systemowy. Jego zadaniem jest zdefiniowanie kogo, a nie czego: ton, wartości, granice odmowy i polityka pamięci. Polityka pamięci należy tutaj, ponieważ jest jedyną instrukcją, która musi obowiązywać, zanim cokolwiek zapyta się o pamięć. Plik tożsamości, który zaczyna wypisywać nazwy serwerów, nazwy klientów lub stawki, już zawodził — stał się treścią Warstwy 1 w opasce Warstwy 0 i teraz wjeżdża do każdej rozmowy, w tym takich, w których nie powinien się pojawiać.

Warstwa 1: pamięć rezydencja

Trwałe pliki pamięci: ogólne notatki i profil użytkownika. Dwie reguły rządzą tą warstwą, i to są reguły, które odróżniają działającą hierarchię od stosu.

Po pierwsze, wskaźniki, nie fakty. Jeśli fakt służy tylko jednej domenie, nie należy tutaj. Prawidłowym wpisem nie jest sam fakt, ale drogowskaz:

Fakty infra: wiki/infra/ + bank pamięci 'homelab'.
Klienci i kontrakty: wiki/business/clients/ + bank 'business'.

Drogowskaz jest neutralny domenowo, więc jest bezpieczny do niesienia wszędzie. Fakt, na który wskazuje, jest ładowany tylko przez aktywność, która nazwała przeznaczenie.

Po drugie, twardy budżet, egzekwowany. Jeśli magazyn nie ma limitu znaków, zapełni się, a wypełnienie zawsze odbywa się tematem ostatnio omawianym — więc tydzień infrastrukturalny cicho usuwa lub otacza kontekst ogólny infrastrukturą. Budżet, który jest prawie pełny, wymusza triage, a triage to jedyny mechanizm, który utrzymuje tę warstwę uczciwie. Implementacja Hermes jest działającym przykładem: MEMORY.md ograniczona do 2200 znaków i USER.md do 1375, wstrzykiwana jako zamarznięty blok na początku sesji, jest udokumentowana w System Pamięci Hermes Agent.

Warstwa 2: wiedza proceduralna

Umiejętności są sposobem, w jaki agent koduje jak: procedurę, pułapki i — kluczowo dla tego artykułu — wskaźniki do głębszych warstw. Umiejętność do administracji homelab nazywa który katalog wiki przechowuje inwentarz i który bank pamięci odzyskać. Umiejętność do pracy z klientem nazywa magazyn kontraktów i bank biznesowy. Opis umiejętności to jej wyzwalacz: to jest warunek gałęzi, który decyduje, czy procedura, a więc i jej wskaźniki, w ogóle wchodzą do kontekstu.

To jest warstwa, która czyni hierarchię operacyjnie działającą, ponieważ jest to szew między „co się dzieje” a „jakie dane ta aktywność może zobaczyć”. Zadanie dotyczące e-maila od klienta ładuje umiejętność klienta; umiejętność klienta nazywa bank biznesowy i katalog kontraktów; bank homelab i katalog infra są po prostu nigdy nie odwołują z ścieżki, którą przeszło zadanie.

Trybem błędu jest wzrost danych: wklejanie faktycznej listy klientów lub faktycznej tabeli IP do ciała umiejętności. Wtedy dane są zawsze ładowane, gdy ładowana jest procedura, a wyzwalacz procedury stał się granicą ekspozycji danych. Umiejętności niosą ścieżkę do danych, nic innego wrażliwego.

Warstwa 3: dane referencyjne

Wiki, drzewo notatek, system rekordów. To jest warstwa z najmniej restrykcji i najmniej zaskoczeń, ponieważ to jedyna warstwa z deterministyczną ścieżką dostępu: coś wchodzi do kontekstu tylko dlatego, że krok zadania jawnie odczytał ten plik. Tabele, inwentarze, kontrakty, runbooki, statystyki — to, co zachowałbyś w bazie danych lub systemie zarządzania konfiguracją. Gdy korpus jest utrzymywany przez LLM, wzorzec LLM Wiki ma zastosowanie: synteza dzieje się w czasie ingestu, a wynik jest przechowywany jako ustrukturyzowane, połączone strony.

Powodem, dla którego dane referencyjne należą tutaj, a nie do Warstwy 4, jest to, że jakość odzyskiwania to złe narzędzie do tabel. Odzyskiwanie semantyczne jest doskonałe dla „co klient X potwierdził o terminie” i okropne dla „jaki jest port usługi na hoście Y” — ten drugi ma dokładnie jedną prawidłową wiersz, a reranker zwracający trzy najbliższe akapity to zobowiązanie. Deterministyczne wyszukiwanie wygrywa dla danych referencyjnych; podobieństwo wygrywa dla epizodów. Trzymaj je osobno, i wzorzec dostępu każdej warstwy odpowiada kształtowi jej treści.

Trybem błędu jest przestarzałość, co jest problemem utrzymania, nie architektury: rekord odchodzi od rzeczywistości, a agent, robiąc wszystko dobrze, pracuje od błędnej tabeli. Mitygacja jest taka sama, jakiej potrzebuje każdy system rekordów — jeden pisarz na plik, dzienniki zmian i częstotliwość audytu — plus praktyki wykrywania dryfu i sprawdzania sprzeczności pokryte w Utrzymanie LLM Wiki: Dryf, Sprzeczności i Przegląd.

Warstwa 4: odzyskana pamięć

Magazyn pamięci z automatycznym odzyskiwaniem na turę: pamięć epizodyczna i relacyjna agenta. Decyzje i ich daty, „klient X potwierdził Y”, „spróbowaliśmy Z i nie zadziałało”. Tutaj żyje dynamiczna, samoorganizująca się część systemu — i tutaj historia bezpieczeństwa zaczyna się komplikować, ponieważ odzyskiwanie semantyczne to brama probabilistyczna, a bramy probabilistyczne przeciekają.

„Pytanie o rozliczenia dla klienta X” i „który host uruchamia serwer rozliczeń” są bliskie w przestrzeni embedding. Każdy pojedynczy bank, który trzyma zarówno rekordy klientów, jak i inwentarz infrastruktury, z nie-trivialną prawdopodobieństwem, wywoła drugi w pierwszym. Możesz zawęzić to za pomocą tagów i ograniczeń odzyskiwania, i powinieneś — ale filtr tagów na zmieszanej korpusie to dyscyplina, nie struktura. Odpowiedzią strukturalną jest przestanie mieszania: jeden bank na domenę, tak aby promień przecieku odzyskiwania, z konstrukcji, był jedną domeną. Wybór samego backendu — polityka przechwytywania, zależności, ograniczenia self-hosting — to osobne porównanie, pokryte w Porównanie Dostawców Pamięci Agentów.

Dwa detale mechaniczne mają znaczenie, gdy podpinasz tę warstwę. Ścieżki zapisu i ścieżki odczytu są osobnymi kontrolami: bank może być zawarty w odzyskiwaniu, będąc wyłączonym z retencji, co jest sposobem na zbudowanie profilu, który czyta wszystko i pisze nic. I każdy bank powinien nanieść własną misję retencji — krótką deklarację, do czego ten bank istnieje. Bank biznesowy z misją „korrespondencja z klientami, warunki kontraktowe, stan negocjacji; nigdy szczegóły infrastruktury” będzie ekstrahował odpowiednio, ponieważ ekstrakcja to wywołanie LLM, które czyta misję. Książka kucharska OpenAI do personalizacji traktuje konsolidację jako najbardziej wrażliwy i podatny na błędy etap cyklu życia pamięci — misja retencji to kontrakt, który utrzymuje ten etap uczciwie.

Profile: granica, która czyni separację strukturalną

Do tego momentu hierarchia separuje wiedzę według warstwy — konieczne, ale niewystarczające. Pięć warstw powyżej to anatomia jednego agenta. Pytanie, z którego ten artykuł zaczął, dotyczy domen: homelab, osobiste, praca, edukacja i kontekst ogólny, który je obejmuje.

Mechanizmem separacji domen jest profil — pełna, niezależna instancja agenta: własny plik tożsamości, własna pamięć rezydencja, własny katalog umiejętności, własne zadania zaplanowane i, zdecydowanie, własne połączenie banku pamięci. Profil to nie tag na rozmowie; to osobny system, który przypadkowo dzieli maszynę. Gdy uruchamiasz agent -p homelab, dostajesz proces, którego cała Warstwa 0 przez Warstwa 4 jest zakreślona do domeny homelab, a którego pula odzyskiwania nie może zawierać banku biznesowego, ponieważ bank biznesowy nie znajduje się w jego konfiguracji w ogóle.

To jest różnica między dwiema odpowiedziami na problem przecieku. „Nie ujawniaj infrastruktury w rozmowach biznesowych” to instrukcja promptu — prawdopodobieństwo. „Pula odzyskiwania profilu biznesowego nie zawiera banku infrastruktury” to konfiguracja — gwarancja. Hierarchia mówi, co gdzie idzie; granica profilu to to, co czyni umieszczenie nie do ominięcia od wewnątrz rozmowy.

Wzorcowy przykład, pięć domen:

Dwie komórki w tej tabeli robią ciężką robotę.

Wiersz banku profilu common to „brak, tylko odczyt”. Ogólna rozmowa to miejsce, w którym zadajesz pytania poprzeczne, więc powinna być w stanie zobaczyć odzyskane fakty każdej domeny — ale nie może pisać do żadnej z nich. Bzdury w ogólnej sesji to dokładnie materiał, którego nie chcesz, aby był ekstrahowany do trwałej pamięci domeny, a połączenie tylko do odczytu usuwa wybór z modelu całkowicie. Jeśli połączenie backendu wspiera listy banków tylko odzyskiwania (osobne od banków piszących), to jest jedna linia konfiguracji na bank domenowy; jeśli nie, profil common odzyskuje z dedykowanego banku ogólnego i akceptujesz słabszy widok poprzeczny.

Wiersze odzyskiwania profili domenowych są puste. Każdy profil domenowy widzi dokładnie jeden bank. Profil homelab nigdy nie odzyska warunku kontraktu klienta, nie dlatego, że został poinstruowany, że nie ma, ale ponieważ warunek nie znajduje się w puli, którą zapytuje. To jest dwukierunkowa separacja, dla której całe ćwiczenie istnieje: działa symetrycznie z konstrukcji, bez żadnej instrukcji zaangażowanej w żadnym kierunku.

Trzy konsekwencje operacyjne z tego wynikają, i to jest to, dlaczego podejście profilowe kosztuje więcej niż podejście jednoagentowe, ale warto tego dla każdego, czyje domeny są naprawdę rozdzielone.

• Wyzwalacz staje się powierzchnią. Jeśli praca nad homelabem dzieje się w terminalu, który uruchamiasz z -p homelab, a praca z klientem dzieje się na koncie komunikacyjnym kierowanym do profilu pracy, to który kapelusz nosisz jest własnością tego, jak wywołałeś agenta, nie flagi, którą pamiętasz, aby stanąć. Błąd kierunkowy — przypadkowe uruchamianie zadań klienta w kontekście homelab — staje się widoczny jak uruchomienie złej powłoki.
• Praca zaplanowana dziedziczy granicę. Zadania cron i delegowane podzadania działają wewnątrz profilu, który je posiada. Nocny check infra zaplanowany w profilu homelab nie może zdryfować treści biznesowej do banku homelab, ponieważ nigdy jej nie ma.
• System plików jest współdzielony, i to jest uczciwym limitem. Profile separują kontekst, nie dostęp. Terminal każdego profilu może odczytać pliki każdego profilu; granica chroni rozmowy, nie dyski. Tak więc warstwy, które trzymają rzeczywiście wrażliwy materiał, potrzebują własnej dyscypliny: poświadczenia w pliku środowiskowym lub magazynie sekretów, a nie w wiki plaintext, wiki poza jakimkolwiek publicznym repozytorium i uprawnienia per katalog, gdzie OS pomaga. Traktuj granicę profilu jako firewall dla kontekstu — doskonały w swojej pracy — i nie pozwól, aby był błądnie przyjęty za firewall dla danych.

Bootstrap z płaskiego stosu

Hierarchia jest zazwyczaj osiągana od dołu: agent, który zaczął z jednym plikiem pamięci i teraz trzyma w nim wszystko. Kolejność migracji ma znaczenie, ponieważ każdy krok jest tani tylko wtedy, gdy poprzedni jest zakończony.

Po pierwsze, podziel pulę odzyskiwania. Tworzenie jednego banku pamięci na domenę to zmiana konfiguracji, nie przepis treści — i to jest krok o najwyższej dźwigni, ponieważ wyciek odzyskiwania przestaje w dniu, gdy banki się dzielą. Treść może migrować później; granica nie powinna na nią czekać.

Po drugie, budżetuj Warstwę 1. Ustaw limit znaków na plikach rezydencja, a potem audytuj, co już się w nich znajduje, w stosunku do limitu. Fakty specyficzne dla domeny stają się wskaźnikami do miejsca, gdzie będą mieszkać; to, co zostaje, to to, co naprawdę dotyczy każdej sesji.

Po trzecie, daj zdegradowanym faktom miejsce docelowe. Jeden katalog wiki na domenę, z dyscypliną jednego pisarza i dziennika zmian, przyjmuje to, co Warstwa 1 uwalnia. Umiejętności podnoszą wskaźniki do niego na końcu, ponieważ umiejętność, która nazywa katalog, który jeszcze nie istnieje, jest gorsza niż brak umiejętności.

Gdzie hierarchia gniecie

Architektura jest tylko tak dobra, jak jej utrzymanie, i każda warstwa gnije w charakterystyczny sposób.

Warstwa 1 wypełnia się pierwsza. To jest warstwa z najwygodniejszą ścieżką zapisu („po prostu zapamiętaj to”), więc to pierwsza, która akumulujące fakty domenowe w przebraniu. Budżet czyni to widocznym: gdy magazyn jest w 90% pełny, audytuj go pod kątem wpisów, które powinny być wskaźnikami. Poprawka to zawsze ten sam ruch — zdegradować fakty do Warstwy 3, promować drogowskaz.

Warstwa 2 wpełza druga. Umiejętności to miejsce, gdzie procedury i dane chcą mieszkać razem, ponieważ „procedura ciągle odwołuje się do danych” wydaje się rozsądne w czasie pisania. Check jest mechaniczny: jeśli ciało umiejętności zawiera tabelę, która jest źródłem prawdy dla czegokolwiek, należy do wiki, a umiejętność powinna nieść ścieżkę.

Warstwa 4 dryfuje cicho. Odzyskana pamięć jest kierunkowa na dodawanie i samo-jawna, więc przestarzałe epizody nigdy nie są korygowane, tylko przetrwawane. Wstępem odzyskiwania („te pamięci to kontekst historyczny, nie zweryfikowane fakty”) jest standardową mitygacją. Czystszą mitygacją jest ta sama, co używa Warstwa 3: gdy epizod staje się trwałym faktem („klient podpisał w tym terminie na tych warunkach”), jest zapisywany do systemu rekordów, gdzie jest widoczny i edytowalny, a bank trzyma tylko narrację. Ostre warianty tego dryfu — własne wnioskowanie agenta zapisane z powrotem jako dowód — są przerobione w Pętle Wzmacniające Pamięć w Agentach AI.

Profile się mnożą. Pięć profili jest manageable; piętnaście to flota. Dyscypliną jest to, że nowy profil pojawia się tylko wtedy, gdy pojawia się nowa domena — nie dla nowego projektu, nowego narzędzia lub nowego nastroju. Separacja na poziomie projektu to to, po co struktura katalogów warstwy referencyjnej; separacja na poziomie domeny to to, po co profile. Mylenie tych dwóch to sposób, w jaki ludzie kończą się z zoo profili i bez jasnej historii odzyskiwania.

Główna myśl: jedna zasada umieszczania

Umieść każdy kawałek wiedzy w naj płytszej warstwie, której wyzwalacz pasuje do jej potrzeby: fakty zawsze potrzebne w pamięci rezydencji jako wskaźniki, procedury w umiejętnościach, dane referencyjne w plikach, epizody w banku — i umieść bank każdej domeny za profilem, którego profil innej domeny nie może odzyskać. Agent zachowuje się wtedy jak dobrze zaprojektowany system: prawidłowa wiedza jest obecna, ponieważ prawidłowa aktywność o nią poprosiła, błędna wiedza jest nieobecna, ponieważ nic w rozmowie nie miało do niej ścieżki, a jedyną rzeczą, która mogłaby wymusić ich połączenie, jest zmiana konfiguracji — coś, co robisz celowo, a więc możesz zobaczyć, gdy się dzieje.

Płaski stos nigdy nie był porażką dyscypliny. To była architektura, w której każdy fakt dzieli jeden wyzwalacz, a tym wyzwalaczem jest „zawsze”. Złam wyzwalacz na części, a wycieki przestają być kwestią sądu modelu. Przestają być możliwe.

Referencje

• PKM vs RAG vs Wiki vs Systemy Pamięci — fundamentalne porównanie osobistych magazynów wiedzy, pipeline’ów odzyskiwania i pamięci agentów
• Systemy Pamięci w Asystentach AI — stos pamięci runtime, w którym ta hierarchia się znajduje
• Odzyskiwanie vs Przedstawianie w Systemach Wiedzy — dlaczego kształt twojego magazynu determinuje, na co może odpowiedzieć
• Hub Pamięci Systemów AI