Dlaczego pamięć agenta programistycznego powinna przechowywać tylko różnicę, i jak ją przechowywać
Pamięć agenta kodującego powinna przechowywać tylko to, czego model nie mógł odgadnąć. Cztery testy na każdą pozycję, trzy wymagania dotyczące przechowywania oraz dlaczego markdown w git pasuje dobrze.
Wyobraź sobie prywatną bazę pamięci przechowywaną dla agenta programistycznego na pojedynczym komputerze. Zawiera ona 181 plików tematycznych za pomocą indeksu składającego się z 134 wierszy, a prawie nic z tego nie stanowi wiedzy w zwykłym rozumieniu tego słowa. Agent już rozumie narzędzia typu Express middleware, strukturę testów Playwright oraz funkcję pliku Dockerfile, przeczytawszy o nich znacznie więcej niż ktokolwiek inny. Każdy wiersz w tej bazie istnieje z przeciwnego powodu: oznacza on miejsce, w którym dany świat różni się od średniej w danej dziedzinie.
Dwa przykłady ilustrują tę koncepcję. Narzędzie weryfikujące proces wdrażania blokuje publikację, gdy nie można przeprowadzić sprawdzenia, i to jest celowe. Mechanizm samozatwierdzania w procesie wdrażania odczytuje wartość .status zamiast .conclusion – szczegół, który kosztował pół dnia, zanim stał się zwykłym wierszem w pliku.
To jest kształt dobrej pamięci agenta. To nie jest kopia tego, co agent wie. To jest delta, część pozostała. Wszyscy zgadzają się, że agent potrzebuje pamięci, a nikt nie określił jej dokładnego kształtu, więc reszta tego tekstu składa się z dwóch kroków: dlaczego agent w ogóle potrzebuje pamięci, a następnie jak ją zorganizować. Druga część dzieli się na cztery elementy: zachowanie prostoty, wymagania wobec poszczególnych jednostek pamięci oraz wobec całego systemu przechowywania, systemy przechowywania, które je spełniają, oraz rutyna pracy z tą pamięcią.
Pamięć agenta to nie pamięć ludzka
Prawdziwym instynktem jest rozumowanie przez analogię. Ludzie pamiętają rzeczy, więc agenty też powinny to robić. Ta analogia zawodzi już na pierwszym kroku. Człowiek zaczyna od zera, więc ludzka pamięć musi przechowywać zarówno normę, jak i wyjątek. Model natomiast przychodzi z już załadowaną normą, na skali przewyższającej możliwości jakiejkolwiek pojedynczej osoby. Podanie mu informacji o tym, czym jest middleware, nie dostarcza żadnych dodatkowych danych – dodaje jedynie tokeny.
Tokeny kosztują pieniądze, i to właśnie tutaj wielu ludzi popełnia błędy. Kontekst, którego nie było potrzeby, nie jest neutralny – to czysta strata. W jednym z badań badacze liczyli, jak często model prawidłowo wykonywał żądania API. Gdy model otrzymywał dokumentację do API, które już dobrze znał, a jej pobieranie było niepełne, jego wskaźnik prawidłowych żądań spadł o 39 punktów procentowych. Z kolei pobieranie takiej dokumentacji dla rzadkich API, których model nie widział, przyniosło korzyść – zwiększyło dokładność o dziewięć punktów. Ten sam treść i ta sama procedura, a efekt zmienił się całkowicie.
Patrząc w ten sposób, plik pamięci to jakby różnica w stosunku do istniejących założeń modelu. Każdy wiersz, który powtarza dobrze znane zasady, konkuruje o uwagę z tym jednym wierszem, który naprawdę ma znaczenie, a uwagi jest zawsze mało.
Zapisuj tylko to, czego model nie mógł zgadnąć.
Przeanalizuj te pliki w rzeczywistym kontekście przez ten filtr – większość ich treści znika. Zasady nazewnictwa, zasada „kompozycji zamiast dziedziczenia” oraz struktura folderów to informacje podstawowe, którymi zajmuje się narzędzie do sprawdzania kodu, a które model już posiada. To, co pozostaje, to zazwyczaj trudne do rozwiązania problemy: workarounds, porzucone ścieżki lub informacje prawdziwe tylko w tym repozytorium, a nie gdzie indziej.
W przykładowym sklepie, który ma około 3 700 wierszy (3 831, jeśli uwzględnić indeks), żaden wiersz nie mówi, jaki jest middleware ani jak strukturyzować testy. Wiersze, które opisywały popularne narzędzia, są usuwane, ponieważ model już je znał, a przy każdej prośbie marnowano tokeny bez potrzeby.
Najtańsza pamięć to ta, której nie potrzebujesz
Jeśli pamięć mnie nie myli, to jej rozmiar zależy od tego, jak daleko projekt odbiega od powszechnego wzorca. Przestrzegając standardowej architektury, agent prawie nic nie wymaga, ponieważ zna ten obszar. Jeśli stworzymy własny system modułów, każda z jego zasad staje się regułą, którą trzeba zapisać, przestrzegać i za którą trzeba zapłacić przy każdej prośbie.
Nie potrzeba żadnych testów porównawczych, by odczuć ten efekt. W standardowym środowisku agent po prostu wykonuje swoją pracę. W języku niszowym lub domowym frameworku zatrzymuje się, zgaduje lub zadaje pytania. Aby zniwelować tę różnicę, sam musimy przenosić kontekst: zapisać go, wersjonować i utrzymywać w aktualnym stanie na zawsze.
Nie istnieje czysty test A/B na potwierdzenie tego twierdzenia, a udawanie czegoś innego byłoby nieszczerze. Cytowane tu badania potwierdzają mechanizm, natomiast pliki jednej osoby potwierdzają jedynie praktykę, co nie jest dowodem na istnienie mechanizmu. Doświadczenie jest jednak spójne: nowe prace w zwykłych strukturach przyspieszają, natomiast prace w dużych, starych systemach, gdzie większość kontekstu nigdy nie została zapisana, przebiegają wolniej, czasami nawet wolniej niż przy pracy ręcznej.
Dlatego wybory architektoniczne stały się wyborami dotyczącymi pamięci. Wybierz nudny, powszechnie używany wzorzec, a nie będziesz musiał wiecznie utrzymywać nic dodatkowego. Każde odstępstwo od tego standardowego wzorca to informacja, którą ktoś musi zapisać i utrzymywać w dokładności, a niestandardowa ścieżka generuje większe koszty przy każdej kolejnej prośbie, nie tylko przy tej, która ją stworzyła.
Trudna część to pozostanie w małych rozmiarach
To jest powód. Sposób rozwiązania zaczyna się od nieprzyjemnego faktu: to, co niszczy systemy pamięci w praktyce, to nie zapominanie, lecz gromadzenie się danych.
Korzyściść ustępuje tempem wzrostu rozmiaru. Podwójna ilość pamięci nie oznacza podwójnej wartości, ponieważ zbędne dane gromadzą się szybciej niż istotne informacje, a po osiągnięciu pewnego poziomu większa ilość pamięci daje gorsze wyniki niż mniejsza, nawet przy zadaniach, do których została przeznaczona.
Konflikty rosną szybciej niż rozmiar. Każdy nowy fakt może być sprzeczny z każdym istniejącym, więc liczba możliwych konfliktów wzrasta znacznie szybciej niż liczba plików. Sprzeczność kosztuje również o wiele więcej niż brak informacji. Gdy brakuje jakiegoś faktu, agent jest niepewny, a ta niepewność jest do przyjęcia – pyta lub zawodzi w sposób widoczny dla ludzi. Gdy dwa fakty są sprzeczne, agent jest przekonany, ale myli się, a ponieważ nic w tym procesie nie wygląda na nieprawidłowe, nikt tego nie zauważa.
Gorzej jeszcze, większość produktów pamięciowych nie jest w stanie dostrzec tego problemu. Wskaźnik podobieństwa wektorowego rejestruje dwa zdania na ten sam temat, ale nie to, że jedno mówi „tak”, a drugie „nie”. W rezultacie wartości stają się jednolite, konflikty narastają, a po osiągnięciu pewnej wielkości system pamięciowy pogarsza działanie agenta.
Pamięć rzadko zawodzi w oczywisty sposób. Zawodzi, udając pewnie błędne odpowiedzi, podczas gdy każde zapytanie nadal jest rozpatrywane pomyślnie.
Zatem trudność nie polega na gromadzeniu coraz większej ilości danych, ponieważ każdy produkt chętnie to robi. Chodzi o utrzymanie małej objętości przy jednoczesnym zachowaniu wystarczającej efektywności. To wymaga usuwania danych, a usuwanie oznacza ocenę własnych dawnych tekstów.
Ludzie zwykle najpierw szukają struktury. Stając w obliczu chaotycznego zbioru informacji, wprowadzają taksonomię hierarchii, kategorii, grafów lub formalnych schematów wiedzy. To zawsze przynosi negatywne skutki. W jednej ocenie z 2026 roku sprawdzono dodanie głębi indeksowi kontekstowemu typu „na żądanie” przy użyciu tego samego modelu i narzędzi – dokładność spadła z 0,91 do 0,64. Struktura płaska okazała się skuteczniejsza od hierarchicznej we wszystkich testowanych przypadkach. Skomplikowana struktura nie rozwiązuje problemu złożoności – to kolejna warstwa złożoności nałożona na pierwszą, a teraz obie wymagają konserwacji.
Zorganizowanie pamięci polega zatem mniej na tworzeniu lepszych diagramów, a bardziej na ustaleniu standardu, który każda informacja musi spełniać, oraz na stworzeniu mechanizmu umożliwiającego łatwe jego osiągnięcie.
Cztery testy dla każdej jednostki pamięci
Ten standard odnosi się do samej jednostki, a nie do całego systemu. W zespole to właśnie te kryteria sprawdza osoba dokonująca oceny.
- Proste i zwięzłe. Tylko informacje o nasionach. Żadne zdanie nie istnieje tylko po to, by brzmieć kompletnie. Linijka, która nie zmienia tego, co agent miałby zrobić, jest dekoracją, a dekoracja ma swój koszt.
- Bez sprzeczności. Nie ma dwóch faktów, które nie mogłyby jednocześnie być prawdziwe. To wymaga aktywnego wysiłku, ponieważ sprzeczności gromadzą się powoli i nigdy celowo.
- Mierzalnie przydatne. Pamięć nie czyni agenta mądrzejszym. Sprawia, że agent działa szybciej i taniej przy tej samej jakości, dając te same odpowiedzi bez konieczności ponownego odkrywania informacji. Plik, który nie skraca widocznie czasu lub liczby tokenów w rzeczywistym zadaniu, nie zasługuje na utrzymanie.
reference_, ustalone zasady w plikach 50 feedback_, a stan ulotny w plikach 14 project_. Czytelnik wie, co dany plik przedstawia, zanim go otworzy.Jeden opublikowany wynik wydaje się podważać trzecią próbę, a w rzeczywistości ją wspiera. Badacze z ETH Zurich przeprowadzili porównanie plików kontekstowych z repozytorium z sytuacją, gdy nie ma żadnych plików. Nie stwierdzono żadnej ogólnej poprawy w skuteczności wykonywania zadań, a koszt wnioskowania wzrósł o ponad dwadzieścia procent; pliki stworzone przez maszyny osiągnęły wyniki nieco gorsze niż w przypadku braku jakichkolwiek plików. Przeczytaj zasady dotyczące różnic – to nie jest wynik przeciwny. Plik pełen przeciętnych informacji to dokładnie to, co zasada przewiduje jako coś, co wiąże się z kosztami, ale nie przynosi żadnych korzyści. Wyniki badań nie mówią, że pliki kontekstowe zawodzą, lecz jedynie, że pliki powtarzające przeciętne informacje zawodzą, co opisuje większość z nich.
Dlatego dyscyplina oznacza mniej pisania i większe redukowanie: każdy wiersz musi pozostać zwięzły, a żadna para wierszy nie może się sprzeczać.
Addy Osmani poruszył ten sam problem z punktu widzenia konserwacji w sierpniu, twierdząc, że pliki agentów stają się przestarzałe w miarę udoskonalania się modeli (jego post nosi tytuł „Audyt plików agentów”), dlatego zasługują na okresowe oczyszczanie i ponowną budowę, a nie na niekończące się rozszerzanie. Pamięć, która tylko się powiększa, jest w stanie odliczania.
Następnie podziel to, co pozostało, według zadań, tak jak to robisz przy samym przywoływaniu danych. To, co jest ładowane do pisania tekstu, różni się od tego, co jest ładowane do debugowania procesu budowy.
Nikt nie potrzebuje jednej pamięci. Potrzebna jest najmniejsza, poprawna część odpowiednia do danego zadania.
Trzy wymagania dla magazynu
Te cztery testy nic nie mówią o tym, gdzie znajdują się pliki, co stanowi drugą połowę procesu organizacji.
Wskazówkę daje to, co już dzielą istniejące narzędzia. AGENTS.md to zwykły plik markdown znajdujący się w przewidywalnej lokalizacji, a czyta go ponad dwadzieścia narzędzi, mimo że ich twórcy konkurują we wszystkim innym. Konkurencyjni dostawcy nigdy nie wdrożyli tego samego interfejsu do zarządzania pamięcią.
Badanie agentów do kodowania (opublikowane na Substack) wykazało, że siedem z nich osiągnęło podobny projekt bez żadnej koordynacji: mały plik markdown zawsze dostępny w kontekście oraz większy archiwum na dysku, które otwierane jest wtedy, gdy zadanie tego wymaga. Żaden z nich nie wykorzystywał wyszukiwania wektorowego. Chociaż nie mają wspólnego standardu oceny, wszystkie siedem spełnia te same trzy wymagania.
Możliwość wyszukiwania bez konieczności instalacji niczego. Termin „wyszukiwanie” często odnosi się do wyszukiwania semantycznego, które nawet nie jest standardem. Własne narzędzie pamięci firmy Anthropic umożliwia przeglądanie, tworzenie, zastępowanie, wstawianie, usuwanie i przemianowywanie danych, ale w ogóle nie posiada funkcji wyszukiwania. Agent wyświetla katalog i odczytuje zawarte w nim informacje. Pamięć, która funkcjonuje tylko wtedy, gdy został utworzony indeks, dane są aktualne, a usługa dostawcy jest dostępna, stanowi słaby element w kontekście pracy systemu. Musi nadal działać, gdy wszystko to przestaje funkcjonować.
Zmienne podczas obserwacji przez osobę. To pamięć, która sama się aktualizuje, ucierpiała najbardziej w tym obszarze. Audyt 10 134 automatycznie wyekstrahowanych wpisów w środowisku produkcyjnym wykazał, że 97,8% z nich stanowiło bezużyteczne dane. Inne badanie polegało na tym, że modele zapisywały swoje udane działania z powrotem do pamięci, a wyniki okazały się gorsze niż przy braku pamięci we wszystkich czterech testowanych agentach. Samodzielnie tworząca się pamięć zmienia się gwałtownie, a nie stopniowo, dlatego każda zmiana musi być widoczna w formie różnicy, podlegać odrzuceniu i może zostać cofnięta.
Możliwa konserwacja za pomocą już dostępnych narzędzi. Zepsucie rzadko kończy system pamięci. Zaniedbanie tak – plik jest zapisywany raz, nikt go więcej nie edytuje, i stopniowo staje się nieprawidłowy. Zgodnie z opisem jednego z badań z 2026 roku, połowa plików kontekstowych nie była edytowana od pierwszego komitowania, a te 6% plików, które były ciągle modyfikowane, należały do osób, które odnotowały rzeczywistą korzyść z tego narzędzia. Konserwacja musi odbywać się w edytorze, w systemie wyszukiwania i kontroli wersji, których ludzie i tak używają codziennie.
To jest pełna specyfikacja. Pozostaje tylko pytanie, który system przechowywania jej spełnia.
Dlaczego pliki markdown pasują do git
Kwestia plików nie jest nowością. Autorzy na Medium argumentowali przynajmniej sześć razy w ciągu ostatniego roku, że „markdown jest lepszy od baz danych wektorowych dla pamięci agentów”, a tematy na Hacker News wciąż przynoszą żarty sprowadzające się do używania zwykłego tekstu. Rzadko podawany jest jednak uzasadnienie tych argumentów.
Trzy firmy sprzedające bazy danych pamięciowe opublikowały swoje opinie na temat plików w ciągu trzech miesięcy, podczas gdy dwa dostawcy czołowych agentów już wcześniej wybrali pliki. Ten argument nie ma nic do zaoferowania poza folderem.
Co przechowuje ta dziedzina
To, co przechowuje system, decyduje o wszystkim w dalszej kolejności.
- Mem0 przechowuje zdanie wydobyte przez LLM wraz z jego embeddingiem, jedną wiersz w indeksie wektorowym. To, co wraca, to nie oryginalny dokument, lecz parafraza wydobywcy, i nie można go otworzyć.
- Zep przechowuje wpisaną krawędź grafu dla każdego faktu i śledzi dwa wycinki czasowe dla każdego z nich, dzięki czemu każdy z nich ma okno ważności. Naprawy odbywają się poprzez zastąpienie: stara krawędź jest oznaczana jako niesprawna zamiast była edytowana.
- Firma specjalizująca się w pamięci wektorowej od lat zarządzała archiwami wektorowymi. Na początku 2026 roku zmieniła domyślny magazyn swoich agentów programistycznych na drzewo plików markdown w repozytorium git, zapisując zmiany raz na edycję.
- Anthropic dostarcza narzędzie do zarządzania pamięcią, które polega wyłącznie na operacjach plikowych w katalogu
/memories, wykonywanych przez własnego klienta użytkownika. Jego usługa Memory Stores API, nadal w wersji beta, nazywa pliki według ścieżek w stylu systemu plików i rozwiązuje problemy z jednoczesnym zapisem za pomocą hasza treści, co stanowi model danych typu git z interfejsem HTTP. - Asystenci konsumentów przechowują streszczenie, które użytkownicy mogą oglądać jedynie w formie wyświetlanej. Do września 2026 roku nie istnieje dla żadnego z nich udokumentowana, czytelna przez maszyny wersja eksportu.
Prawdziwą granicą jest to, czy pamięć może być odczytywana, a podejście oparte na rozróżnieniu plików i baz danych to pomija. Wszystkie opcje inne niż pliki mają jedną wspólną cechę: pamięć nie może być porównywana w dwóch różnych momentach. Korekty dokonuje się za pomocą przełącznika, a nie komitowania.
Każda ze stron ma rację, ale w części
W marcu 2026 roku MatrixOrigin stwierdził, że statyczny Markdown ulega degradacji i niczego nie egzekwuje. Pięć tygodni później Mem0 opublikował post zatytułowany „Pamięć twojego agenta AI to po prostu plik? W tym problem”, w którym argumentował, że pliki tekstowe powtarzają błędy z czasów przed istnieniem baz danych z lat 70.: brak wyszukiwania semantycznego, brak rozumowania czasowego, brak bezpiecznych zapisów równoczesnych oraz brak możliwości zapominania. W czerwcu Zep dodał, że „Markdown to nie pamięć agenta”, podkreślając kluczowy punkt: plik Markdown pokazuje tylko to, co zostało napisane, a nie to, co zastąpił lub dlaczego.
Tymczasem własny agent programistyczny firmy Anthropic przechowuje swoją pamięć w postaci zwykłego Markdownu na dysku, a dokumentacja Windsurf doradza, by wszystko, co warto zachować, przenieść z jego magazynu pamięci do formatu Markdown pod kontrolą wersji. Warto zwrócić uwagę na to, kto co sprzedaje.
Dostawcy baz danych mają dwa uzasadnione argumenty. Wektory przeważają, gdy pytanie i notatka nie dzielą wspólnego słownictwa, jak w przypadku zapytania o „to, co oznacza wypalenie” wobec notatki, która w ogóle nie wspomina o wypaleniu. Tylko metoda embedding może to przezwyciężyć, przy stałej szybkości przetwarzania milionów wierszy. Narzędzie Grep nie może znaleźć tego, czego nie można nazwać.
Grafy przeważają pod względem czasu. Aby odpowiedzieć na pytanie, w co ktoś wierzył w zeszły wtorek i co to zastąpiło, potrzebne są fakty opatrzone datami początkowymi i końcowymi, a wynik podobieństwa nie może określić, który z dwóch sprzecznych faktów jest aktualny. Według doniesień, ponowne przetestowanie pytań czasowych w ramach jednego standardu testowego przez podmiot trzeci dało systemowi grafowemu wynik 63,8%, podczas gdy system oparty na wektorach osiągnął 49,0%. Pliki przegrywają w obu przypadkach.
Dowody, wraz z zastrzeżeniem
Wyniki wyszukiwania z 2026 roku zaskoczyły branżę. Agenty, które analizowały zwykłą stertę plików za pomocą grep, find oraz odczytu plików, przewyższyły wszystkie metody oparte na słowach kluczowych, embeddingach oraz systemach ponownego rankowania. Jeden z testów wydajności wyszukiwania agentowego pokazał, że usunięcie mechanizmu wykorzystującego embeddingi i pozwolenie agentowi na bezpośredni odczyt plików podniosło dokładność z 69% do 80%, przy jednoczesnym zmniejszeniu kosztów o prawie jedną trzecią. Inne badanie dotyczące zadań wymagających długoterminowej pamięci wykazało, że zwykłe wyszukiwanie według słów kluczowych przewyższało wyszukiwanie semantyczne we wszystkich konfiguracjach z wykorzystaniem narzędzi wewnętrznych. Gdy jednak wyniki pojawiały się w formie plików, kolejność zmieniała się w połowie przypadków, ponieważ zadania te premiowały znajdowanie dokładnych informacji, takich jak data, liczba, identyfikator lub ciąg znaków oznaczający błąd.
Artykuł o agentic-search zawiera również ważną uwagę, która powinna być oczywista: jeśli zwiększymy liczbę dokumentów z 100 000 do 400 000, ta sama metoda przekształca się z dokładności 80% na mniej niż 40%, przy jednoczesnym trzykrotnym wzroście liczby wywołań narzędzia. Grep funkcjonuje w określonych granicach wielkości i nie stanowi prawa przyrody; w tych granicach przewyższa inne rozwiązania pod względem jakości i kosztów, natomiast poza nimi traci efektywność.
Dlatego właściwe pytanie brzmi, po której stronie tych granic znajduje się dany system, a nie które podejście jest ogólnie lepsze. Zbiór 181 plików jest setki razy mniejszy od skali, na której, jak donoszono, pojawiają się problemy. System pamięci produkcyjnej w dużej firmie takiej jak LinkedIn nie mieści się w takich ograniczeniach, i nikt nie twierdzi, że powinien używać markdowna.
Tabela porównawcza: pliki kontra alternatywy
W odniesieniu do tych trzech wymagań pliki markdown spełniają każde z nich przy niemal zerowych kosztach. Grep służy jako rozwiązanie awaryjne – każda zmiana jest reprezentowana jako diff (odwracalna zmiana w repozytorium), a narzędzia do konserwacji są już dostępne na pulpicie.
Dwa dodatkowe korzyści przychodzą bez żadnych kosztów. Pojawiają się sprzeczności, ponieważ dwa sprzeczne fakty to po prostu dwie linie tekstu zamiast dwóch tablic typu float, a zapisany format służy jednocześnie jako format eksportu.
Ten kompromis wymaga nazwania, a nie ukrywania. Pliki tracą na efektywności w porównaniu z embeddingami, gdy potrzebna jest nieprecyzyjna wyszukiwanie w wielu dokumentach. Rozwiązaniem jest umieszczenie indeksu nad plikami, który można odbudować w każdej chwili, zamiast zastąpić nimi same pliki. Rozwiązania oparte na pamięci bazowej budują ten warstwę na SQLite, memsearch buduje ją na Milvus, a pomysł Karpathy’ego dotyczący kompozytowych wiki obejmuje jedynie stronę indeksu, bez żadnych embeddingów. Gdy indeks stanowi nośnik danych, trzeba zrezygnować z możliwości inspekcji, porównywania, określania właściciela oraz przenoszenia danych, aby uzyskać funkcjonalności wyszukiwania, które i tak były dostępne.
Jeśli nie możesz tego przeszukać, porównać i usunąć z niego linijki, to nie jest to twoja pamięć. To ktoś inny ma jej kopię w swojej pamięci podręcznej.
Jak wygląda działający system
Zasady są tanie, więc oto jeden sprawdzony układ.
- K warstwami wskaźników, bez żadnego manifestu. Pierwszy plik, który otwiera agent, ma 21 wierszy. Funkcjonuje jako mapa z trzema obszarami najwyższego poziomu, po jednym wierszu każdy, wskazującymi na głębsze pliki. Na poziom niżej znajduje się plik projektu, który przechowuje rzeczy naprawdę osobiste: repozytorium aktywne w porównaniu z tym, które przestało istnieć wskutek zmiany nazwy, wersje, do których wszystko jest przymocowane, oraz zasady komunikacji, których należy przestrzegać. W drzewie projektów znajduje się 28 takich plików, wszystkie napisane ręcznie, a każdy z nich ładowany jest tylko wtedy, gdy praca wymaga tego kierunku.
- Magazyn, do którego pisze agent, a potwierdza go człowiek. Obok niego znajduje się automatyczna pamięć, z 181 plikami tematycznymi za indeksem składającym się z 134 wierszy. Tylko indeks ładowany jest podczas rozpoczynania sesji, a plik tematyczny otwierany jest w momencie, gdy zadanie go wymaga.
Warstwy do ładowania, a nie do rozumowania
Liczba poziomów powyżej wynosi cztery, co odpowiada głębokości, przed którą ostrzega wcześniejszy wynik od 0,91 do 0,64. Jednak w tamtym badaniu zmiennej była głębokość, natomiast indeks pozostawał niezmienny we wszystkich konfiguracjach. Najlepszą opcją była płaska struktura indeksu na każde zadanie – agent przeczytałby wszystko za jednym razem, zanim zdecyduje, co otworzyć, co niemal podwoiło dokładność w porównaniu z prostą nawigacją, przy jednoczesnym zmniejszeniu kosztów o około połowę. Wyniki pogorszyły się tylko wtedy, gdy indeks nabrał gałęzi, po których model musiał schodzić, zgadując na podstawie samych etykiet, która z nich zawiera odpowiedź.
Indeks tej konfiguracji to prosty sort: jeden poziom, który jest czytany w całości na początku sesji. Składa się z 134 wierszy, mniej więcej po jednym na temat, z których każdy podaje nazwy plików, do których odnoszą się, wraz z krótkim streszczeniem. Nie ma żadnych rozgałęzień, więc nie trzeba niczego zgadywać. Jest to mała tabela routingu utrzymywana ręcznie, a nie taksonomia, za pomocą której model mógłby rozumować – może być niedoskonała: jedenastu z 181 plików w niej brakuje. Pliki tematyczne są małe, proste i czytane w całości, a warstwa zostaje otwarta, ponieważ praca trafiła do jej obszaru, a nie dlatego, że jakaś zapytanie wyszukała odpowiedź. To właśnie progresywne ujawnianie informacji.
Test jest prosty. Jeśli model musi zgadywać, który węzeł zawiera odpowiedź, opierając się wyłącznie na etykietach, oznacza to, że zbudowano drzewo, a wynik wynosi 0,64. Jeśli natomiast model czyta cały indeks i otwiera plik po nazwie, chodzi o kolejność ładowania.
Struktura istnieje po to, by decydować, co załadować. Nie służy ona temu, by model mógł przez nią rozumować.
Ochrona przed dewiacjami
Agent proponuje zmiany, które pojawiają się jako różnice, a osoba może je zaakceptować lub nie. Pliki przechowywane w repozytoriach mają własną historię, co oznacza, że pytanie, dlaczego agent w coś wierzy, można odpowiedzieć poprzez ich przeczytanie – czego nie może zaoferować żaden magazyn wektorów ani strona pamięci dostawcy. Pamięć, której nikt nie sprawdził, to plotka z nazwą pliku.
Czasami odbywa się rutynowa czyszczenie: usuwa się linie, które były prawdziwe w czerwcu, pliki, które model od tamtej pory wchłonął, oraz reguły zastąpione lepszymi. Magazyny kurczą się częściej, niż przewidują ludzie.
Wszystko znajduje się w zwykłym formacie Markdown na dysku lokalnym i funkcjonuje bez asystenta, który pomagał w jego tworzeniu. Gdy w przyszłym roku pojawi się silniejszy narzędzie, skieruj je na tę samą folder i kontynuuj pracę.
Test, który możesz przeprowadzić dziś
Struktura mieści się na jednej karcie: cztery testy dla każdej przechowywanej linii, trzy wymagania dotyczące miejsca przechowywania oraz osoba pośrednicząca pomiędzy agentem a plikiem.
Aby określić swoją pozycję, otwórz plik kontekstowy projektu – czy to CLAUDE.md, AGENTS.md czy cokolwiek innego, co odczytuje narzędzie – i usuń każdą linię, którą model mógłby odgadnąć samodzielnie. Redukcja o połowę to realistyczny wynik. Następnie przekaż następne rzeczywiste zadanie skróconemu plikowi i sprawdź, czy coś się pogorszy. Potem, za każdym razem, gdy agent popełni błąd w czymś, o czym nie miał pojęcia, dodaj jedną linię i sprawdź ją jak kod. To właśnie jest ta dyscyplina, i nie rozszerza się ona poprzez dodawanie kolejnych elementów.
Agent już zna wartość średnią. Jedynym zadaniem jest obliczenie delta.
Podobne artykuły
- Dlaczego testy pamięci agentów wprowadzają w błąd i jak oceniać na podstawie własnych danych — Listy rankingowe pamięci publicznej mają błędne arkusze odpowiedzi i osoby oceniające. Należy oddzielić proces wyszukiwania od udzielania odpowiedzi, dodać kontrolę spójności, świeżości, powstrzymywania się od odpowiedzi oraz zapominania, a także śledzić koszty.
- Injekcja promptów i śmiertelna trójka zagrożeń: zabezpieczanie agentów AI — Dlaczego agenci nie potrafią odróżnić twoich instrukcji od tych atakującego, jak działały ataki EchoLeak i GitHub MCP oraz które metody obrony są skuteczne.