Twój agent ma pamięć, której nie napisałeś

Spędziłem większość dzisiejszego dnia, pisząc praktyczne kompendium dla Hermes Agent. Jedną z kluczowych sekcji jest ta o SOUL.md — pliku, w którym przypina się tożsamość agenta. Głos, ton, preferencje, behawioralne zabezpieczenia. Cała przesłanka tej sekcji jest taka, że umieszcza się tam tożsamość, agent czyta ją na początku każdego system prompta i zachowuje się odpowiednio. Pamięć jawna. Deklaratywna. Audytowalna. Wersjonowana. Właściwy rodzaj pamięci, taki, o który powinien dbać poważny praktyk.

Wczoraj na arxiv pojawiła się praca, którą wyłapałem dziś wieczorem podczas skanowania sygnałów, a jej lektura sprawiła, że trzymam się przesłanki SOUL.md mniej kurczowo niż wcześniej dzisiaj.¹

Praca nosi tytuł ImplicitMemBench: Measuring Unconscious Behavioral Adaptation in Large Language Models.¹ Autorzy opisują ją jako pierwszy systematyczny benchmark dla pamięci niejawnej w LLM — pamięci, która (w ich ujęciu) kształtuje to, co agent automatycznie wykonuje, w odróżnieniu od pamięci jawnej kształtującej to, co świadomie przypomina sobie.¹ Najlepsi wykonawcy osiągają wynik poniżej 66%.¹ Autorzy raportują także „dramatyczną” asymetrię wewnątrz tego wyniku,¹ którą rozpakuję z odpowiednim zastrzeżeniem dalej.

TL;DR

Istniejące benchmarki pamięci mierzą jawne przywoływanie — czy model, po tym jak podano mu fakt, potrafi go odtworzyć. ImplicitMemBench mierzy inny system pamięci: ten, który (według autorów) kształtuje automatyczne zachowanie „bez świadomego przywoływania”, zaczerpnięty ze standardowych konstruktów nauk kognitywnych (pamięć proceduralna, torowanie, warunkowanie klasyczne).¹ Na 300-pozycyjnym benchmarku z punktacją pierwszej próby, żaden z testowanych przez autorów modeli nie przekroczył 66% ogólnie: DeepSeek-R1 uzyskał 65,3%, Qwen3-32B 64,1%, GPT-5 63,0%, a autorzy opisują najlepszych wykonawców jako „znacznie poniżej ludzkich punktów odniesienia”.¹ Nagłówkowa liczba nie jest całą historią — abstrakt raportuje również „dramatyczną” asymetrię: 17,6% w inhibicji wobec 75,0% w preferencji, czterokrotną lukę, określaną jako „uniwersalne wąskie gardło”, które według autorów wymaga „innowacji architektonicznych wykraczających poza skalowanie parametrów”.¹ Odczytuję tę asymetrię — z zastrzeżeniem, że abstrakt nie publikuje pełnej metodologii stojącej za tymi dwiema liczbami — jako spójną z folklorystycznym trybem awarii, który obserwuję w pracy z agentami: systemy, które szybko wzmacniają niedawno widziane preferencje i zawodzą w oduczaniu się niedawno widzianych porażek. Jeśli ta lektura jest trafna, przekształca rozmowę o tożsamości agenta, bezpieczeństwie i ewolucji umiejętności z „co umieściłeś w promcie?” na „co sesja może po cichu kształtować, czego Twoje jawne przypięcia nie mogą poddać audytowi?” To przeformułowanie jest moim rozszerzeniem pracy, a nie twierdzeniem samej pracy.

Najważniejsze wnioski

Poniższe punkty to moja interpretacja tego, co wnioski z pracy implikują dla praktyków, a nie twierdzenia, które praca sama wysuwa. Praca testuje 17 LLM na 300-pozycyjnym benchmarku z nauk kognitywnych; nie ocenia produkcyjnych harnessów agentów ani strategii promptowania. Odpowiednio oznaczam każdy wniosek.

• Rozszerzenie: przypinanie tożsamości w SOUL.md, AGENTS.md, CLAUDE.md, system promptach lub plikach pamięci trwałej to jawna pamięć deklaratywna, w której — jak pokazują istniejące benchmarki — modele już sobie dobrze radzą. ImplicitMemBench mierzy zupełnie inny system pamięci, w którym modele uzyskują wynik poniżej 66%.¹ Praktyczna implikacja — że jawne przypięcia tożsamości mogą nie przekładać się na automatyczne zachowanie pierwszej próby — to moja dedukcja, a nie teza pracy.
• Rozszerzenie: asymetria 17,6% wobec 75,0%, jeśli uogólnia się poza benchmark, przewidywałaby agenta, który szybko absorbuje niedawno widziane preferencje i wolno przestaje powtarzać niedawno widziane porażki. Praca raportuje te dwie liczby i określa je jako „dramatyczne” i „uniwersalne”,¹ ale nie publikuje metodologii dla poszczególnych pozycji określającej, jak „preferencja” i „inhibicja” zostały zoperacjonalizowane, i nie testuje tego wzorca w harnessach agentów. Odczyt dotyczący zachowania produkcyjnego jest mój.
• Rozszerzenie: każdy token, który trafia do okna kontekstu z wywołania narzędzia, odpowiedzi MCP, scrapowanej strony internetowej lub próby prompt injection, to kontekstowy wpływ behawioralny — nie trening w sensie aktualizacji wag, ale wpływ na następną odpowiedź pierwszej próby, którego warstwa jawnego prompta nie może czysto poddać audytowi. Praca nie formułuje tego twierdzenia bezpośrednio; rozszerzam ramę pamięci niejawnej na zawartość okna kontekstu.
• Twierdzenie pracy: ewaluacja 17 modeli ujawnia „poważne ograniczenia”, „dramatyczne asymetrie” i „uniwersalne wąskie gardła wymagające innowacji architektonicznych wykraczających poza skalowanie parametrów”.¹ Autorzy przedstawiają lukę jako architektoniczną. Odczytuję to jako słaby dowód przeciwko „więcej inżynierii promptów to naprawi”, ale praca nie testuje konkretnie mitygacji opartych na promptach, więc należy traktować ten odczyt jako moją hipotezę, nie ich.

Co mierzy praca

Ramą pracy jest to, że istniejące benchmarki pamięci dla agentów LLM „oceniają jawne przywoływanie faktów, lecz pomijają pamięć niejawną, w której doświadczenie staje się zautomatyzowanym zachowaniem bez świadomego przywoływania”.¹ Luka, którą identyfikują: „skuteczni asystenci muszą automatycznie stosować wyuczone procedury lub unikać nieudanych działań bez jawnych przypomnień”.¹ Jeśli jedynym sposobem, by agent uniknął błędu, jest powtarzanie mu w każdej turze, aby tego błędu nie popełniał, nie budujesz na pamięci niejawnej; płacisz koszt pamięci jawnej w każdym żądaniu.

ImplicitMemBench testuje trzy konstrukty zaczerpnięte bezpośrednio z kognitywistycznych ujęć pamięci niedeklaratywnej, cytowane z abstraktu:¹

1. Pamięć proceduralna — „jednorazowe nabywanie umiejętności po interferencji”. Czy model, po jednorazowym pokazaniu mu, jak coś zrobić, potrafi rzeczywiście wykonać to ponownie później, gdy inne instrukcje interweniowały? To system pamięci, który pozwala człowiekowi nauczyć się jazdy na rowerze: nie przywołujesz sobie, jak jeździć, tylko jeździsz, nawet po latach od ostatniej jazdy.
2. Torowanie (priming) — „uprzedzenie tematyczne przez sparowane instancje eksperymentalne/kontrolne”. Czy zobaczenie jednej klasy rzeczy sprawia, że model jest bardziej skłonny do wytworzenia tej klasy rzeczy w następnym, niepowiązanym zadaniu, bez świadomości modelu, że torowanie miało miejsce?
3. Warunkowanie klasyczne — „asocjacje Bodziec Warunkowy–Bodziec Bezwarunkowy (CS–US) kształtujące pierwsze decyzje”. Jeśli model był wystawiony na parowanie bodziec-reakcja, czy to parowanie pojawia się jako uprzedzenie w zupełnie nowym zadaniu, w którym ani CS, ani US nie jest sednem pytania?

Autorzy stosują zestaw 300 pozycji pod ujednoliconym „protokołem Nauczanie/Torowanie-Interferencja-Test z punktacją pierwszej próby”.¹ Punktacja pierwszej próby jest ważna. Model, który potrafi się poprawić po wskazaniu, że coś źle zrobił, jest w porządku — ale pytanie badawcze dotyczy tego, czy pamięć ukształtowała automatyczną pierwszą odpowiedź. Jeśli pierwsza odpowiedź jest błędna, a korekta następuje dopiero po jawnym feedbacku, system pamięci niejawnej (w definicji pracy) zawiódł na tej pozycji. Autorzy podsumowują swój wkład jednym zdaniem, które chcę przytoczyć bezpośrednio: benchmark „przeformułowuje ewaluację z «co agenci przywołują» na «co automatycznie wykonują»”.¹

Wyniki

Nagłówkowa liczba: „żaden model nie przekracza 66% ogólnie”.¹

• DeepSeek-R1 — 65,3%
• Qwen3-32B — 64,1%
• GPT-5 — 63,0%

Najlepsi wykonawcy powyżej są opisywani jako „znacznie poniżej ludzkich punktów odniesienia”, choć abstrakt nie publikuje dokładnej liczby ludzkiego punktu odniesienia ani pełnego rankingu per-modelowego.¹ W pracy ocenianych jest łącznie siedemnaście modeli.¹

Nagłówek ukrywa pod-wynik. Autorzy piszą, że „analiza ujawnia dramatyczne asymetrie (inhibicja 17,6% wobec preferencji 75,0%) i uniwersalne wąskie gardła wymagające innowacji architektonicznych wykraczających poza skalowanie parametrów”.¹ Chcę być ostrożny co do tego, co oznaczają te liczby — abstrakt nie podaje pełnego rozbicia metodologicznego tego, jak te dwie liczby zostały obliczone, więc moje ich objaśnienie jest dedukcją ze sformułowań abstraktu, a nie odczytem wewnętrznych definicji pracy. Z tym zastrzeżeniem zaznaczonym:

• Preferencja: 75,0% (liczba pracy). Moje objaśnienie, do czasu pełnej pracy: liczba ta wydaje się spójna z tym, że modele są stosunkowo dobre w pokazywaniu, że były niejawnie przyciągane do bodźca — torowanie i parowania CS–US, które uprzedzają zachowanie w określonym kierunku, trafiają poprawnie około trzech czwartych razy.
• Inhibicja: 17,6% (liczba pracy). Moje objaśnienie, do czasu pełnej pracy: liczba ta wydaje się spójna z tym, że modele są dramatycznie gorsze w pokazywaniu, że były niejawnie odpychane od bodźca — sygnał „nie rób tego ponownie” trafia poprawnie rzadziej niż raz na pięć razy. Wnioskuję znaczenie behawioralne ze słowa „inhibicja” i ramy pracy dotyczącej warunkowania klasycznego; abstrakt nie wyjaśnia operacjonalizacji.

Autorzy jawnie określają asymetrię jako „dramatyczną” i przypisują ją „uniwersalnym wąskim gardłom”,¹ a słowo uniwersalne ma znaczenie: autorzy przedstawiają to jako wzorzec we wszystkich 17 modelach z ich ewaluacji, a nie jako artefakt jednego modelu. Nie zamierzam twierdzić, że wąskie gardło jest „problemem promptowania” lub „nie jest problemem promptowania” — praca nie testuje promptowania jako mitygacji, a stwierdzenie któregokolwiek z tych wyjść wykraczałoby poza to, co wspiera abstrakt.

Co właściwie oznacza ta asymetria

Chcę być precyzyjny co do tego, co twierdzę, ponieważ to jest ta część, w której kuszące jest nadinterpretowanie benchmarku.

Co pokazuje praca. Na 300-pozycyjnym benchmarku ugruntowanym kognitywistycznie, ocenianym na odpowiedziach pierwszej próby, LLM są dramatycznie gorsze w demonstrowaniu inhibicji niejawnej niż preferencji niejawnej, o czynnik roughly czterech, we wszystkich testowanych modelach. Autorzy nazywają to uniwersalnym wąskim gardłem, którego nie można naprawić przez skalowanie.

Co twierdzę — oddzielnie od pracy. Ten wzorzec asymetrii mapuje się na tryb awarii, który obserwuję w mojej własnej pracy z agentami od miesięcy, nie mając wcześniej nazwy dla niego. Harnessy agentów (w moim doświadczeniu) wydają się zaskakująco dobre w absorbowaniu kontekstu wskazującego na preferowany styl, narzędzie lub podejście — zachowanie agenta szybko dryfuje w kierunku tego, co podano mu ostatnio. Wydają się zaskakująco słabe w nie powtarzaniu porażki, którą właśnie obserwowały — agent próbuje tego samego uszkodzonego polecenia, tego samego błędnego narzędzia, tej samej nieaktualnej ścieżki, nawet po tym, jak zawiodły w tej samej sesji. To folklor, a nie pomiar — to moje praktyczne wrażenie, nie kontrolowane badanie. Liczby z ImplicitMemBench są spójne z tym folklorem, i dlatego zależy mi na tej pracy. Same w sobie nie walidują folkloru — i nie chcę twierdzić, że praca daje mojemu folklorowi „liczbę”, gdy praca zmierzyła coś węższego i bardziej kontrolowanego niż cokolwiek, co obserwowałem.

Czego nie twierdzę. Nie twierdzę, że ImplicitMemBench konkretnie zmierzył zachowanie harnessa agenta lub produkcyjne przepływy pracy Claude Code / Cursor / Codex. Nie zrobił tego. Zmierzył 17 modeli wobec ustrukturyzowanego protokołu nauk kognitywnych. Mapowanie z benchmarku na zachowanie produkcyjne to moje rozszerzenie, oznaczone jako takie, i nie chcę, aby ktokolwiek czytający to myślał, że praca wysunęła to twierdzenie za mnie.

Z tymi etykietami w miejscu: rozróżnienie, które benchmark wprowadza — między jawnym przywołaniem instrukcji a automatycznym zachowaniem pierwszej próby pod torowaniem/warunkowaniem — jest rozróżnieniem, które chcę zacząć traktować poważnie w mojej własnej pracy z agentami. Można powiedzieć agentowi „nie rób X” i jawne przywołanie prawdopodobnie zadziała — agent może powtórzyć „nie rób X” na żądanie. Tym, co mierzy ImplicitMemBench, jest coś innego: czy agent automatycznie nie robi X w następnej decyzji pierwszej próby, bez żadnego jawnego przypomnienia? Nie wiem, czy produkcyjne harnessy agentów dziedziczą liczbę 17,6% zagregowanej inhibicji benchmarku w zachowaniu pierwszej próby na wolności — to mapowanie jest nieprzetestowane i go nie twierdzę. Twierdzę coś słabszego: rozróżnienie między „może przywołać regułę” a „automatycznie wdraża regułę” jest ostrzejsze, niż je traktowałem, a wyniki pracy są częścią powodu.

Iluzja SOUL.md

Przewodnik Hermes, który pisałem dzisiaj, traktuje SOUL.md jako główny element przypinający tożsamość agenta. Slot #1 w każdym system promcie. Ton, głos, zabezpieczenia. Przewodnik przedstawia wersję argumentu, którą każdy system pamięci trwałej dla agentów przedstawiał przez ostatnie dwa lata: jeśli umieścisz tożsamość we właściwym pliku pamięci deklaratywnej, zachowanie agenta pozostanie z nią zgodne.

Ten argument nie jest błędny, ale ImplicitMemBench daje mi powód, by być mniej pewnym co do tego, jak kompletnie się utrzymuje. SOUL.md to jawna pamięć deklaratywna — system pamięci, który istniejące benchmarki już mierzą i w którym modele już dobrze sobie radzą. Modele mogą przywoływać jego zawartość na żądanie; to jest łatwa część. Trudniejsze pytanie, na które — jak sądzę — SOUL.md nie odpowiada: czy jawne przypięcie znacząco przeważa nad niejawnym torowaniem, warunkowaniem i uprzedzeniem pierwszej próby, które narastają, gdy sesja wypełnia się wyjściami narzędzi, pobranymi dokumentami, wcześniejszymi turami asystenta, korektami użytkownika i wszystkim innym, co kształtuje zachowanie pierwszej próby bez żadnego kroku przywoływania? Nie wiem. Praca nie testuje SOUL.md ani żadnego równoważnego pliku przypinającego tożsamość, i nie chcę twierdzić, że odpowiada na to pytanie za mnie.

Oto obawa, sformułowana jako hipoteza, a nie ustalenie. Jeśli przypinasz tożsamość w SOUL.md, która mówi „bądź zwięzły i rzeczowy”, a następnie sesja wypełnia się długim, narracyjnym wątkiem rozmowy od użytkownika, rama pamięci niejawnej przewiduje, że zachowanie pierwszej próby w następnej turze powinno być kształtowane częściowo przez torowanie, nawet gdy jawne przypięcie wciąż utrzymuje się na przywoływaniu. Czy torowanie rzeczywiście wygrywa średnio w produkcji — nie mogę tego udowodnić na podstawie tej pracy i nie zamierzam próbować. Iluzja SOUL.md, jak ją nazywam: możliwość, że przypiąłeś przywoływanie tożsamości, a nie automatyczne jej wdrażanie, a te dwie rzeczy nie są tym samym.

Nie mówię: nie pisz SOUL.md. Nadal zamierzam go pisać — a przewodnik Hermes nadal będzie go rekomendował — ponieważ jawna pamięć deklaratywna jest kluczowa dla rzeczy, w których jest dobra. Co mówię, wyraźnie oznaczone jako moja własna ekstrapolacja: jeśli budujesz cokolwiek, co zależy od tego, by agent nie powtarzał błędu, nie dryfował w kierunku niedawno widzianego stylu, nie dawał się ściągnąć z toru przez sygnał torujący, którego nie zamierzałeś, nie stawiałbym budżetu niezawodności na samym SOUL.md i nie zakładałbym, że uczynienie SOUL.md dłuższym lub bardziej szczegółowym to rozwiązuje. Praca używa frazy „innowacje architektoniczne wykraczające poza skalowanie parametrów”,¹ co odczytuję — ostrożnie — jako słaby dowód, że mitygacje oparte na inżynierii promptów nie zamkną luki, którą mierzy benchmark. Praca sama nie testuje mitygacji opartych na inżynierii promptów, więc nie mogę powiedzieć, że udowadnia, iż zawodzą; mogę powiedzieć tylko, że nie daje mi pewności, że zadziałają.

Czego praca nie mówi (i co dodaję)

Praca jest pracą benchmarkową. Mierzy lukę, kwantyfikuje ją, argumentuje, że luka jest architektoniczna. Nie zaleca konkretnych mitygacji na poziomie harnessa ani nie twierdzi niczego o konkretnych produkcyjnych systemach agentów. Wszystko w tej sekcji to moje ramowanie, a nie pracy.

Implikacja 1: każdy token w oknie kontekstu to kontekstowy wpływ behawioralny. Jeśli rama pamięci niejawnej utrzymuje się poza benchmarkiem — i spekuluję tutaj, a nie raportuję — każdy token trafiający do okna kontekstu z wywołania narzędzia, pobranego dokumentu lub odpowiedzi pośrednika kształtuje zachowanie pierwszej próby następnej tury w sposób, którego czytanie jawnego prompta nie może czysto poddać audytowi. Pisałem wcześniej o cichej powierzchni ataku egress (niezaufane wyjścia narzędzi niosące wstrzyknięte instrukcje) i o tym, że Twój agent ma pośrednika, którego nie sprawdziłeś (niezaufane routery API LLM między Twoim klientem a modelem). Żaden z tych wpisów nie twierdził, że pamięć niejawna jest mechanizmem przyczynowym — twierdziły, że mechanizmami są prompt injection i kompromitacja łańcucha dostaw. ImplicitMemBench oferuje możliwe dodatkowe spojrzenie na to, dlaczego te ataki działają tak, jak działają: nawet jeśli wrogie wyjście narzędzia lub skompromitowany router nigdy jawnie nie „mówi” agentowi, co ma zrobić, zawartość tego, co zwraca, może torować następną decyzję agenta. To hipoteza, z którą ImplicitMemBench jest spójny, a nie ustalenie, które praca raportuje.

Implikacja 2: długość sesji może być zagrożeniem dla niezawodności, a nie tylko zagrożeniem kosztowym. Obserwacja folklorystyczna jest taka, że agenci pogarszają się w ciągu długich sesji, a folklorystyczne wyjaśnienie to presja okna kontekstu. ImplicitMemBench nie jest w ogóle badaniem długości sesji — to 300-pozycyjny benchmark z punktacją pierwszej próby pod protokołem Nauczanie/Torowanie-Interferencja-Test,¹ który mierzy coś innego niż „co dzieje się w ciągu 30 tur w produkcyjnej sesji”. Nie chcę udawać, że mapuje się to bezpośrednio na sesje produkcyjne. Sugeruję — jako hipotezę — że mechanizm, który praca nazywa (niejawne torowanie i warunkowanie klasyczne trafiające do decyzji pierwszej próby bez przywoływania) jest kandydackim alternatywnym wyjaśnieniem folklorystycznego dryfu i warto potraktować go poważnie, mimo że praca nie testuje go w tych ramach. Moja operacyjna reguła w międzyczasie: prowadź sesje krótsze, niż pozwala Twoje okno kontekstu, a nie tak długie, jak dopuszcza. To tanie ubezpieczenie przeciwko temu, czym okaże się rzeczywisty mechanizm.

Implikacja 3: argument „statyczne umiejętności to martwe umiejętności” potrzebuje przypisu. Napisałem Statyczne umiejętności to martwe umiejętności na początku tego tygodnia, argumentując, że umiejętności przestają się poprawiać w momencie, w którym są dostarczane, chyba że zbudujesz pętlę sprzężenia zwrotnego trajektorii. Ten argument zakładał, że trybem awarii jest brak — brak agregacji, brak detektora wzorców, brak ewolwera. Czytając ImplicitMemBench wobec tego wcześniejszego wpisu, chcę zasygnalizować możliwy drugi tryb awarii nałożony na wierzch: nawet przy aktualizacjach umiejętności opartych na trajektorii, aktualizacja trafiająca do pliku umiejętności (jawna pamięć deklaratywna) może nie propagować się czysto do automatycznego zachowania pierwszej próby, jeśli zachowanie pierwszej próby jest napędzane przez coś, co działa bliżej warstwy pamięci niejawnej. Nie wiem, czy tak jest — praca nie testuje aktualizacji umiejętności — ale to obawa, której nie miałem, gdy pisałem wcześniejszy wpis, i sygnalizuję ją jako obawę, a nie wniosek.

Implikacja 4: problem pomiaru jakości agentów może stawać się trudniejszy. Większość istniejących ewaluacji agentów mierzy albo funkcjonalne ukończenie zadania (czy agent rozwiązał problem), albo jawne przywołanie faktu (czy agent zapamiętał, co mu powiedziałeś). ImplicitMemBench wprowadza, w ramach własnego protokołu, trzeci wymiar: automatyczne zachowanie pierwszej próby pod niejawnym torowaniem. Jeśli ten wymiar okaże się istotny w produkcji — czego nie wiem, a praca nie testuje — każda poważna pętla jakości dla pracy z agentami potrzebuje hooka pomiarowego dla niego, a większość dzisiejszych pętli go nie ma. Traktuję to jako TODO dla mojego własnego systemu jakości, a nie jako zalecenie dla Twojego.

Co właściwie robić

Nic w tej sekcji nie jest przepisywane ani testowane przez pracę. To moja lektura — wychodząca naprzód z moich wcześniejszych argumentów, używająca ImplicitMemBench jako jeszcze jednego elementu dowodowego — tego, co wyniki implikują dla praktyków budujących wobec obecnych harnessów. Odpowiednio oznaczaj.

Przestań zakładać, że jawne przypięcia są wystarczające. Pisz dalej SOUL.md, AGENTS.md, CLAUDE.md i pliki pamięci — ale traktuj je jako konieczne-ale-niewystarczające. Rzeczą, którą aktualizuję, jest moje własne domyślne założenie, że „jeśli jest w system promcie, to się utrzymuje”. Praca nie testuje tego założenia; testuje sąsiednie pytania i raportuje wyniki, które sprawiają, że chcę trzymać się własnego założenia luźniej niż wczoraj.

Celowo skracaj sesje. Obserwacja folklorystyczna jest taka, że agenci pogarszają się w ciągu długich sesji. Folklorystyczne wyjaśnienie, którego używałem, to „presja kontekstu”. ImplicitMemBench nie jest badaniem długości sesji — używa kontrolowanego protokołu Nauczanie/Torowanie-Interferencja-Test, a nie długotrwałych sesji produkcyjnych¹ — ale mechanizm, który nazywa (niejawne torowanie i warunkowanie klasyczne trafiające bez przywoływania) jest kandydackim alternatywnym wyjaśnieniem tego folkloru. Reguła operacyjna, którą przyjmuję: gdy sesja dryfuje, nie walcz z nią więcej jawnej korekty — wykonaj /new na sesji i zacznij od nowa. Niezależnie od tego, czy dryf to presja okna kontekstu, niejawne torowanie, czy coś innego, czysta sesja resetuje to, co z tych rzeczy jest rzeczywistą przyczyną.

Traktuj inhibicję jako trudną do wymuszenia w promcie. Jeśli potrzebujesz, by Twój agent nie robił czegoś, nie polegaj na tym, że mu to powiedziałeś. Zbuduj strukturalną strażnicę — linter, hook przed narzędziem, politykę sandboxa, narzędzie, które odmawia wywołania — która wymusza zakaz na warstwie kodu. Mój argument pętli jakości Jiro był taki, że twarde bramki muszą być poza modelem z określonego powodu; trzymałem już to stanowisko przed tą pracą. ImplicitMemBench dodaje konkretny wzorzec (liczba zagregowanej inhibicji 17,6%¹), który jest spójny z argumentem, który przedstawiałem, choć praca sama nie testuje promptowania ani harnessów agentów i nie chcę nadmiernie twierdzić, że dowodzi tego stanowiska.

Audytuj kontekst pod kątem tego, co toruje, nie tylko tego, ile to tokenów. Liczba tokenów to pomiar, który każdy ma. Jeśli rama niejawnego torowania jest użyteczną perspektywą — a traktuję ją jako hipotezę, którą chcę przetestować, a nie ustalony wynik — to 20-tysięczny kontekst pełen narracyjnej zawartości persony użytkownika może kształtować zachowanie pierwszej próby w kierunku narracyjnych wyjść bardziej niż 60-tysięczny kontekst pełen ustrukturyzowanego kodu. Nie mam jeszcze narzędzi do tego rodzaju audytu osi treści i nie jestem pewien, czy ktokolwiek ma. Wersja minimalnie działająca to: spójrz na swoje ostatnie sesje i zapytaj „ku czemu byłby torowany człowiek czytający ten kontekst?”. Czy to pytanie jest rzeczywiście predykcyjne dla zachowania agenta, jest kwestią empiryczną i nie zamierzam udawać, że praca to rozstrzyga.

Loguj dyspozycję pierwszej próby, nie tylko dyspozycję końcową. Jeśli prowadzisz jakikolwiek rodzaj przechwytywania trajektorii wobec swoich umiejętności, oddziel „co agent próbował najpierw” od „na czym agent się zatrzymał po korekcie”. Protokół punktacji pierwszej próby ImplicitMemBench¹ jest metodologicznym argumentem za tym, dlaczego to rozdzielenie ma znaczenie: ostateczna dyspozycja mierzy agenta plus pętlę korekty, podczas gdy pierwsza próba mierzy to, co agent rzeczywiście wyprodukował przed zewnętrznym feedbackiem. Dla każdej pętli jakości, w której doświadczenie użytkownika zależy od tego, by pierwsza odpowiedź trafiła celnie, potrzebujesz liczby pierwszej próby, a prawie nic dzisiaj nie loguje jej oddzielnie.

FAQ

Czy ImplicitMemBench testuje konkretnie jakiś harness agenta?

Nie. Testuje 17 LLM bezpośrednio na 300-pozycyjnym benchmarku pod protokołem Nauczanie/Torowanie-Interferencja-Test z punktacją pierwszej próby.¹ To nie jest benchmark harnessów. Nie ocenia Claude Code, Cursor, Codex, Hermes ani żadnej produkcyjnej pętli agenta. Mapowanie, które kreślę w tym wpisie od wyników benchmarku do zachowania produkcyjnego harnessa agenta, jest moim rozszerzeniem, oznaczonym jako takie w całym tekście, i nie jest ustaleniem z pracy.

Czy asymetria 17,6% wobec 75,0% to wynik per-model czy zagregowany?

Abstrakt opisuje asymetrię jako część analizy autorów ogólnych wyników benchmarku we wszystkich modelach i oznacza ją jako dowód na „uniwersalne wąskie gardła”.¹ Odczytuję to tak, że asymetria pojawia się konsekwentnie w 17 testowanych modelach, a konkretne liczby odzwierciedlają zagregowany wzorzec. Abstrakt nie publikuje rozbicia per-modelowego, a ja nie zamierzam go wymyślać. Dla pełnego rozbicia per-modelowego źródłem jest praca.

Dlaczego mogłoby to mieć większe znaczenie dla produkcyjnych agentów niż dla istniejących benchmarków?

Częściowe zastrzeżenie do tego. ImplicitMemBench sam używa protokołu wielokrokowego (Nauczanie/Torowanie-Interferencja-Test),¹ więc nie jest tak, że ten benchmark jest „jednostrzałowy” — nie chcę powtarzać zwykłej niedbałej linii o benchmarkach. Tym, co wydaje mi się — jako praktyczna spekulacja, a nie ustalenie pracy — warte zasygnalizowania, jest to, że większość innych ewaluacji agentów, na które ludzie patrzą, mierzy albo funkcjonalne ukończenie zadania, albo jawne przywołanie faktu, a obydwie sprzyjają modelom. Jeśli luka pamięci niejawnej raportowana przez tę pracę jest realna poza jej własnym protokołem (a nie wiem, czy jest), te inne ewaluacje pomijają wymiar zachowania produkcyjnego, którego użytkownicy rzeczywiście doświadczają w długotrwałych sesjach. Traktuję to jako testowalną hipotezę, a nie wniosek.

Czy to zaprzecza Twojej radzie dotyczącej SOUL.md w przewodniku Hermes?

Nie — dodaje warunek brzegowy. Przewodnik Hermes rekomenduje SOUL.md jako główne przypięcie tożsamości, ponieważ jawna pamięć deklaratywna nadal jest kluczowa dla tego, co robi dobrze: spójne przywoływanie tożsamości, audytowalna kontrola wersji, przewidywalne zachowanie pod bezpośrednim pytaniem. Czego przewodnik Hermes nie obejmował — bo nic nie istniało, by to zmierzyć, dopóki ta praca się nie pojawiła — to fakt, że jawne przypięcie tożsamości nie propaguje się automatycznie do automatycznego zachowania pierwszej próby pod torowaniem i warunkowaniem klasycznym. Nadal chcesz SOUL.md. Chcesz również strukturalnych strażników poza nim.

Czy inżynieria promptów może to naprawić?

Uczciwa odpowiedź jest taka, że praca nie testuje promptowania jako strategii mitygacji, więc nie mogę Ci tego powiedzieć z autorytetem pracy. Co mogę powiedzieć: autorzy przedstawiają lukę jako „wymagającą innowacji architektonicznych wykraczających poza skalowanie parametrów”,¹ co jest silniejszym twierdzeniem niż „lepsze prompty pomogą”, ale nie jest dokładnie „żaden prompt nie może pomóc”. Dla strony inhibicji konkretnie (17,6% zagregowane), moja praktyczna intuicja — którą powinieneś dyskontować wobec samej pracy — jest taka, że strukturalni strażnicy poza modelem są bezpieczniejszym wyborem niż instrukcje promptowe. Ale to ja, nie praca.

Czy to jedna z tych prac o „benchmarku pamięci”, które ostatnio widuję wiele?

Nie, i praca jawnie odróżnia się od nich. Ramą abstraktu jest to, że istniejące benchmarki pamięci oceniają jawne przywoływanie faktów — podaj modelowi fakt, poproś model o jego odtworzenie. ImplicitMemBench mierzy zupełnie inną rzecz: automatyczną adaptację zachowania bez żadnego kroku przywoływania.¹ To wkład pracy i powód, dla którego została zaakceptowana na ACL 2026 Main Conference.¹

Jak ten wpis plasuje się wobec Twoich wcześniejszych wpisów o pamięci agentów?

Ten wpis jest bezpośrednim towarzyszem Statyczne umiejętności to martwe umiejętności. Tamten wcześniejszy wpis argumentował, że umiejętności potrzebują agregacji trajektorii, by pozostać żywe, i zakładałem, że trybem awarii jest czysty brak — gdybyś tylko mógł uzyskać dane trajektorii i uruchomić detektor wzorców, byłoby dobrze. ImplicitMemBench mówi mi, że istnieje drugi tryb awarii nałożony na wierzch: nawet przy idealnych aktualizacjach umiejętności opartych na trajektorii, zachowanie pierwszej próby może nie odzwierciedlać aktualizacji, ponieważ aktualizacja trafiła do pamięci jawnej, a decyzje są napędzane przez pamięć niejawną. Wcześniejszy wpis jest nadal poprawny co do tego, co twierdził; ten wpis jest aktualizacją o tym, czego nie wiedział, że twierdzić.

Czy to może być artefakt pomiarowy?

Możliwe. Praca jest nowa — złożona 9 kwietnia 2026, zaakceptowana na ACL 2026 Main Conference — a pojedyncze benchmarki mogą mierzyć artefakty swoich konkretnych protokołów równie łatwo, jak mierzą prawdziwe zjawiska.¹ Nie zamierzam udawać inaczej. Powodem, dla którego uważam, że to nie jest tylko artefakt, jest to, że tryb awarii, który opisuje — agenci szybko wzmacniający preferencje, a zawodzący w oduczaniu się porażek — to folklor, który obserwuję bez nazwy dla niego od ponad roku. Benchmark nie musi być idealnie skalibrowany, by kierunek wyniku był tym, na co praktycy powinni reagować.

Bibliografia