DBAdmin/brain/raw/articles/RAG, LLM Wiki, or Gbrain_ How Your Agent Remembers Changes Everything.md

title, source, author, published, created, description, tags

title	source	author	published	created	description	tags
RAG, LLM Wiki, or Gbrain? How Your Agent Remembers Changes Everything	https://ai.gopubby.com/rag-llm-wiki-or-gbrain-how-your-agent-remembers-changes-everything-56829e66725c	Yanli Liu	2026-04-27	2026-06-11	RAG, LLM Wiki, or Gbrain? How Your Agent Remembers Changes Everything Karpathy’s compounding wiki, Garry Tan’s autonomous brain, and the decision framework most teams skip Read this for …	clippings

Wiki kompoundingu Karpathy'ego, autonomiczny mózg Garry'ego Tana i ramy decyzyjne, które większość zespołów pomija

Zdjęcie: Elisa na Unsplash

Przeczytaj to za darmo

Trzy tygodnie temu Andrej Karpathy opublikował na GitHubie informację, która w ciągu kilku dni osiągnęła 5 000 gwiazdek. Jego argument: przestań używać LLM-ów jako wyszukiwarek do swoich dokumentów. Wykorzystaj ich jako inżynierów wiedzy, którzy kompilują, odwołują i utrzymują żywą wiki. System się uczy. Wiedza się kumuluje.

Później Garry Tan wysłał GBrain – 24 autonomiczne umiejętności, 21 cronowych zadań oraz mózg obejmujący 17 888 stron. Jego system nie tylko zapamiętuje rzeczy. Działa na nich. Autonomicznie.

Obaj zgadzają się co do diagnozy: samo RAG to za mało. Twój agent czyta te same dokumenty do każdego pytania, nigdy się nie uczy, nigdy nie składa wniosków, nigdy nie łączy punktów między wczorajszymi wglądami a dzisiejszym zapytaniem. To retriever, nie myśliciel.

Ale ich rozwiązania idą w przeciwnych kierunkach.

Karpathy chce, aby twój agent zbudował trwałą, powiązaną wiki — wiedzę, która wzbogaca się z każdym kolejnym źródłem, które jej podajesz.

Garry Tan chce, aby twój agent wykorzystał tę wiedzę — umiejętności, które nie tylko wiedzą, ale też działają, działając w tle, gdy śpisz.

Tymczasem większość zespołów produkcyjnych nadal używa podstawowego RAG-a. Nie dlatego, że jest idealny, ale dlatego, że działa na dużą skalę, a alternatywy są jeszcze młode.

Która architektura faktycznie pasuje do Twojego agenta? Odpowiedź zależy od pytania, którego większość artykułów o "RAG nie żyje" nigdy nie zadaje:

• Jaka jest praca twojego agenta?
• Czy to jest wyszukiwanie odpowiedzi z dużego korpusu?
• Gromadzenie wiedzy, która powinna się rozwijać z czasem?
• Albo działa autonomicznie na podstawie tego, co wie?

Trzy wzory. Trzy kompromisy. Jeden system decyzyjny.

Dlaczego agenci zapominają

Oto co większość tutoriali o agentach pomija: okno kontekstowe to nie pamięć. To tablica, która jest usuwana po każdej sesji.

Twój agent może przechowywać milion tokenów w kontekście. Brzmi to jak dużo, dopóki nie uświadomisz sobie, że degradacja zaczyna się około 300 000–400 000 tokenów — czyli około 30–40% sufitu. A gdy sesja się kończy, wszystko znika. Twój agent zaczyna kolejną rozmowę od zera.

Diagram autora: Luka w wiedzy — okno kontekstowe kontra trwała wiedza

RAG był pierwszą poważną odpowiedzią na ten problem. Zamiast upychać wszystko do okna kontekstowego, osadzasz dokumenty w wektorach, przechowujesz je w bazie danych i pobierasz odpowiednie fragmenty w czasie zapytania. Działa. Działają na nim miliony systemów produkcyjnych.

Jednak RAG ma fundamentalne ograniczenie, które artykuł naukowy z 2024 roku obejmował na siedem odrębnych punktów awarii. Trzy z nich mają największe znaczenie dla agentów:

Problem z chunkingiem. Twoja 30-stronicowa specyfikacja techniczna dzieli się na fragmenty po 500 tokenów. Fragment wspominający o wymogu zgodności trafia do jednego wektora. Fragment, który wyjaśnia, dlaczego ten wymóg istnieje, ląduje w innej dziedzinie. Retriever znajduje jednego, a drugiego nie trafia. Twój agent udziela technicznie poprawnej, ale niebezpiecznie niekompletnej odpowiedzi.

Problem rederywacji. Każde zapytanie zaczyna się od zera. Twój agent wczoraj przeanalizował ten sam dokument architektury i wyciągnął te same wnioski. Jutro znowu to zrobi. RAG odzyskuje — nigdy się nie uczy. Karpathy ujął to ostro: "RAG czyta te same książki na każdy egzamin, nigdy tak naprawdę nie ucząc się materiału."

Problem bierności. RAG czeka, aż zapytasz. Nigdy nie zauważa, że dokument, który indeksował w zeszły wtorek, stoi w sprzeczności z tym, który indeksował dziś. Nigdy nie wskazuje, że trzy źródła nie zgadzają się co do kluczowego szczegółu. Nigdy nie działa na podstawie tego, co wie.

Te trzy luki — fragmentaryczny kontekst, brak kumulacji, brak działań — to właśnie to, do czego celują dwie nowe architektury. Wiki LLM Karpathy'ego atakuje pierwsze dwa. GBrain Garry'ego Tana atakuje wszystkie trzy.

Diagram autora: Trzy krytyczne punkty awarii RAG

Architektura 1: RAG — Retriever

RAG wygrywa na dużą skalę, a przegrywa na głębokości. Jeśli masz 100 000 dokumentów zmieniających się codziennie i potrzebujesz odpowiedzi teraz, nic innego nie może się z tym równać. Ale Twój agent nigdy nie stanie się mądrzejszy dzięki temu.

Jak to działa. Osadzasz dokumenty w wektorach, przechowujesz je w bazie danych takich jak Pinecone czy Chroma, a gdy pojawi się zapytanie, znajdujesz najbliższe fragmenty, wprowadzasz je do promptu i pozwalasz modelowi wygenerować odpowiedź. Potok jest osadzany → przechowywany → pobierany → generowany.

Architektura jest dojrzała. LangChain, LlamaIndex i kilkanaście innych frameworków ustandaryzowały ją. Twój zespół prawdopodobnie już wie, jak go zbudować. To ma większe znaczenie, niż przyznaje większość porównań architektonicznych.

Tam, gdzie się trzyma. RAG radzi sobie z rozmiarami korpusów, które mogłyby zablokować alternatywy. Firma posiadająca 200 000 wewnętrznych dokumentów — polityk, notatek, specyfikacji, eksportów ze Slacka — może indeksować wszystko i zacząć odpowiadać na pytania tego samego dnia. Brak wstępnego przetwarzania na strony wiki. Nie mam umiejętności inżynierskich w marce-down. Po prostu wstaw i idź.

Radzi sobie też ze świeżością. Gdy dokument się zmienia, ponownie go osadzasz. Następne zapytanie otrzymuje zaktualizowaną wersję. Nie jest potrzebny audyt wiki, nie trzeba przepisywać umiejętności.

Gdzie się łamie. Problem z chunkingiem z Sekcji 2 jest konstrukcyjny, nie da się go naprawić lepszymi rozmiarami chwałek. Badanie z 2024 roku zidentyfikowało siedem punktów awarii w produkcyjnych systemach RAG — a trzy z siedmiu występują zanim model językowy w ogóle zobaczy kontekst.

Jest też koszt, o którym nikt nie mówi: opóźnienia. Potok RAG składa się z wielu etapów — osadzenia, wyszukiwania wektorowego, rerankingu, pakowania kontekstowego — z których każdy dodaje milisekundy. Na jedno zapytanie jest w porządku. Dla agenta wykonującego 40 wywołań narzędzi w pętli, te milisekundy łączą się w sekundy.

Rzeczywistość biznesowa. RAG to to, na czym obecnie korzysta większość zespołów produkcyjnych, ponieważ to architektura z największą liczbą blizn bitewnych. Posiada znane tryby awarii, udokumentowane poprawki oraz ekosystem dostawców konkurujących o rozwiązanie jej problemów. Jeśli musisz wysłać wewnętrznego asystenta wiedzy do następnego kwartału, RAG to sprawdzona droga.

To także kwestia zgodności architektonicznej, którą zespoły rozumieją. Twoje dane pozostają w magazynie wektorowym. Pobieranie jest możliwe do audytu. Generowanie jest możliwe do śledzenia. W branżach regulowanych ta możliwość audytu często przeważa nad kumulowanymi korzyściami wynikającymi z nowszych podejść.

Werdykt: Używaj RAG, gdy twój korpus jest duży (10 000+ dokumentów), często się zmienia, a priorytetem jest dostarczenie systemu produkcyjnego z znanymi kompromisami. Nie używaj go, gdy twój agent musi uczyć się na własnej pracy lub działać autonomicznie.

Diagram autora: Potok architektury RAG z punktami awarii

Architektura 2: LLM Wiki — Kompilator

Wiki LLM wygrywa na poziomie głębokości, a przegrywa na skali. Jeśli masz mniej niż 1000 źródeł i chcesz, aby twoja wiedza wzbogacała się z każdym dokumentem, który jej przekazujesz, to właśnie ta architektura się kumuluje. Ale spróbuj na 100 000 dokumentów, a koszty utrzymania cię pogrążą.

Smysł Wiki LLM Karpathy'ego proponuje prostą, ale potężną zmianę: zamiast pobierać surowe fragmenty w czasie zapytania, użyj LLM do wstępnego skompilowania źródeł do trwałej, powiązanej wiki. Model wykonuje syntezę raz. Każde przyszłe zapytanie korzysta z tej pracy.

Architektura trójwarstwowa. Surowe źródła są na dole — PDF-y, artykuły, transkrypcje, zakładki. Są niezmienne. LLM je czyta, ale nigdy ich nie modyfikuje.

Powyżej znajduje się samo wiki — strony markdown generowane przez LLM, zawierające streszczenia, strony encji, definicje pojęć i odnośniki krzyżowe. LLM całkowicie kontroluje tę warstwę.

Na górze znajduje się schemat — plik konfiguracyjny (pomyśl CLAUDE.md), który informuje LLM, jak utrzymywać wiki: konwencje nazewnictwa, reguły krzyżowe, co jest sprzecznością.

Diagram autora: LLM Wiki architektura trójwarstwowa

Jak działa naliczanie składane. Gdy wprowadzasz do systemu nowy dokument, LLM nie tworzy po prostu strony podsumowującej. Odczytuje nowe źródło względem istniejącej wiki i aktualizuje każdą stronę, która została dotknięta. Pojedynczy ingest zazwyczaj obejmuje 10–15 stron wiki — dodając odwołania, oznaczając sprzeczności, aktualizując profile podmiotów.

Pętla zapytań dodatkowo to potęguje. Gdy zadajesz pytanie i otrzymujesz zsyntezowaną odpowiedź reprezentującą nową wiedzę, ta odpowiedź jest archiwizowana jako nowa strona wiki. Pocisk pochodzi z samego pytania. Jutrzejsze zapytania korzystają z dzisiejszej syntezy.

I jest pętla konserwacji, którą większość ludzi pomija: proces usuwania kłaczków. Okresowo LLM audytuje całą wiki — znajduje osierocone strony bez linków, oznacza przestarzałe twierdzenia, identyfikuje koncepcje wspomniane, ale nigdy nie otrzymujące własnej strony. Wiki pozostaje zdrowa, bo maszyna wykonuje konserwację, którą ludzie zawsze porzucają.

Diagram autora: Jak jeden dokument zajmuje 15 stron

==Gdzie się łamie.== ==Skala to twardy sufit. Wiki korzysta z plików markdown, które nawigują przez BM25 lub grep. To działa świetnie przy 100 źródłach, generując kilkaset stron wiki. Przy 10 000 źródeł nawigacja się psuje. Przy 100 000 jest nieużyteczny bez dodania warstwy wyszukiwania na wierzchu — co znów zaczyna przypominać RAG.==

Jest też koszt obliczeniowy z góry. Każde wejście wymaga od LLM przeczytania nowego źródła, przeczytania odpowiednich istniejących stron wiki oraz przepisania całej dotkniętej treści. To jest znacznie droższe za dokument niż osadzenie RAG. Dla osobistej wiki badawczej koszt jest do ogarnięcia. Dla bazy wiedzy korporacyjnej to rozmowa o budżecie.

A wiki jest bierna. Pięknie gromadzi wiedzę, ale nie działa na jej podstawie. Nie zauważy, że termin wspomniany w trzech źródłach już minął. Nie wywoła powiadomienia, gdy nowy dokument jest sprzeczny z obowiązującą polityką. Wie — ale nie robi.

Rzeczywistość biznesowa. Ta architektura najlepiej sprawdza się dla badaczy, analityków i małych zespołów budujących głęboką wiedzę w konkretnej dziedzinie. Zespół śledzący zmiany regulacyjne w 200 dokumentach źródłowych? Świetne dopasowanie. Firma próbująca uczynić 500 000 stron Confluence podatnymi na zapytania? Złe narzędzie.

Historia zarządzania danymi jest mieszana. Wiki tworzy kopie pochodne twojego materiału źródłowego — streszczenia, odnośniki, strony syntetyczne. W niektórych środowiskach regulacyjnych te artefakty pochodne podlegają wymogom przechowywania i audytu. To nie jest powód do rozstania, ale to rozmowa, którą powinien przeprowadzić twój zespół prawny.

Werdykt: Korzystaj z LLM Wiki, gdy twoich źródeł jest setki (nie tysiące), twoja wiedza powinna się kumulować z czasem, a chcesz syntezy — nie tylko wyszukiwania. Nie używaj go, gdy potrzebujesz świeżości w czasie rzeczywistym, ogromnej skali czy autonomicznej akcji.

Architektura 3: Umiejętności grube — Operator

Umiejętności grube wygrywają na autonomii, a tracą na dostępności. Jeśli chcesz wiedzy, która nie tylko leży, ale uruchamia akcje, działa według harmonogramów i z czasem powiększa swoje możliwości, to właśnie ta architektura działa. Ale wymaga to prawdziwych inwestycji inżynieryjnych — a obecnie to jednoosobowy spektakl.

GBrain Garry'ego Tana wprowadza ideę, której ani RAG, ani LLM Wiki nie próbują: wiedzę, która działa. Nie tylko "co wiemy?", ale "co powinniśmy z tym zrobić i kiedy?"

Ważny kontekst: GBrain nie został zaprojektowany jako produkt korporacyjny. Został stworzony do działania na osobistych agentach AI — konkretnie na OpenClaw, Hermes i Claude Code. README jest bezpośredni: " Nasz agent AI jest bystry, ale zapominalski. GBrain nadaje mu mózg." To infrastruktura zbudowana przez CEO Y Combinator, aby prowadzić własnych agentów, a następnie udostępniona jako open source. To pochodzenie kształtuje wszystko w architekturze — optymalizuje pod kątem przepływów pracy jednego użytkownika, a nie wdrożenia organizacyjnego.

Cienka uprząż, architektura umiejętności grubości. GBrain odwraca typowy projekt agenta. Większość frameworków buduje gęsty runtime z dziesiątkami definicji narzędzi zajmujących połowę okna kontekstowego. GBrain ogranicza się do około 200 linii kodu — wystarczająco, by zarządzać wykonywaniem modeli, odczytywać/zapisywać pliki oraz egzekwować bezpieczeństwo.

Diagram autora: Architektura Fat Skills – trójwarstwowa architektura

Cała inteligencja tkwi w umiejętnościach. Każda umiejętność to obszerny dokument markdown — nie szablon promptu, lecz cały workflow: kiedy zwolnić, co sprawdzić, jak łączyć z innymi umiejętnościami, jaki pasek jakości egzekwować. Agent odczytuje plik umiejętności i wykonuje go.

Resolver jako tabela routingu. RESOLVER.md GBraina to dyspozytor, który kieruje intencje użytkownika do umiejętności w sześciu kategoriach: umiejętności stale dostępne, operacje mózgu, pobieranie treści, umiejętności myślenia, zadania operacyjne oraz konfiguracja. Ale oto spostrzegawcze: same opisy umiejętności pełnią rolę rozwiązywacza. Model automatycznie odczytuje opisy i dopasowuje intencję. Nie potrzebny jest żaden wyraźny kod routingowy.

Najnowsza wersja Garry'ego Tana idzie o krok dalej: "Mniej grubszych umiejętności sprawia, że resolver jest krótszy, co samo w sobie jest mniejsze nadmuchanie kontekstu. Krótkie resolvery są lepsze niż długie." Trend zmierza ku mniejszej liczbie umiejętności, bardziej kompleksowych z parametrami rozgałęzienia, zamiast biblioteki wąskich.

Diagram autora: Przepływ routingu resolvera

Jak naprawdę wygląda umiejętność otyłości. Oto materiał wstępny od GBrain's Skills — tego, który tworzy i utrzymuje dossier osób i firm:enrich

name: enrich
version: 1.0.0
description: |
  Enrich brain pages with tiered enrichment protocol.
  Creates and updates person/company pages with compiled
  truth, timeline, and cross-links.
triggers:
  - "enrich"
  - "create person page"
  - "update company page"
  - "who is this person"
tools:
  - get_page
  - put_page
  - search
  - add_link
  - add_timeline_entry
mutating: true
writes_to:
  - people/
  - companies/

To nie jest szablon promptu. To kontrakt. Umiejętność określa swoje wyzwalacze, narzędzia, do czego pisze i czy mutuje stan mózgu. Pod tym tematem znajduje się siedmiostopniowy protokół wzbogacający obejmujący trzy poziomy — pełne badania dla kontaktów wewnętrznych (wszystkie API, wyszukiwanie w sieci deep-web), umiarkowany wysiłek dla przedstawicieli branżowych (web + social + cross-reference brain cross-reference) oraz lekki dotyk dla podmiotów wartych śledzenia, ale nie krytycznych. Każde twierdzenie wymaga cytowań w tekstie zgodnie z rygorystyczną hierarchią precedensów: najwyższe miejsca są stwierdzenia użytkownika, potem skompilowana prawda, następnie wpisy w osi czasu, a następnie zewnętrzne API.[Source: ...]

Filozofia tej umiejętności oddaje całe podejście: "Dossier wywiadowcze, nie scrapy z LinkedIn." System stawia na fakturę — przekonania, bieżące projekty, motywacje, trajektorię — ponad podstawowe fakty, które można znaleźć w wyszukiwarce Google.

Warstwa zawsze włączona. Niektóre umiejętności w ogóle nie czekają na wyzwalacze. GBrain's uruchamia każdą wiadomość przychodzącą, działając jako tani subagent równolegle z główną odpowiedzią. Zawiera dwie rzeczy: oryginalne idee (zachowane w dokładnym sformułowaniu użytkownika, nigdy nie sparafrazowane) oraz wzmianki o bytach (ludzie, firmy, koncepcje). Każda wykryta istota jest łączona z istniejącymi stronami mózgu lub tworzy nową. Zasada działania: "Niepowiązana wzmianka to zepsuty mózg." signal-detector

To właśnie odróżnia umiejętności związane z otyłością od wywoływania funkcji. Wywołanie funkcji jest bezstanowe — wykonuje się, zwraca i zapomina. Umiejętność grubości utrzymuje swój status, egzekwuje standardy jakości, łączy się z innymi umiejętnościami i sprawia, że mózg jest bogatszy po każdej egzekucji.

Cron: umiejętności, które same się uruchamiają. Harmonogram crona zamienia umiejętności w autonomicznych agentów. Każde zadanie jest celowo skromne — zadanie to dosłownie "Przeczytaj i uruchom to." Cała inteligencja zostaje w pliku umiejętności, nie w planowniku. Zadania działają na 5-minutowych, przesuwanych przedziałach, aby zapobiec kolizjom, szanować godziny ciszy (domyślnie 23:00–8:00) oraz wymuszać idempotencję — uruchomienie tego samego zadania dwukrotnie daje identyczne rezultaty bez duplikatów wyjść. Wyniki są składane do rejestru ścieżek audytu.skills/{name}/SKILL.md reports/{job-name}/{YYYY-MM-DD-HHMM}.md

Typowy zestaw crona może obejmować: scrapowanie Hacker News co sześć godzin i wprowadzanie nowych sygnałów, codzienne wzbogacanie nowo wymienionych podmiotów, cotygodniowe sprawdzanie metryk spółek portfelowych oraz szkicowanie podsumowania w każdy poniedziałek rano. Agent działa, gdy śpisz.

Deterministyczny podział. Umiejętność potrafi wywoływać kod deterministyczny — zapytania SQL, wywołania API, operacje plikowe — do zadań, które nie powinny być pozostawiane ocenie LLM. GBrain oddziela pracę utajoną (odczyt, synteza, rozpoznawanie wzorców) od pracy deterministycznej (zapisy w bazie danych, obliczenia, powtarzalne wyniki). Mieszanie ich to sposób na halucynacje agentów.

Gdzie się łamie. Inwestycja inżynieryjna jest znaczna. 24 umiejętności GBraina są w pełni testowane poprzez kompleksowe testy, oceny i testy jednostkowe. To nie jest projekt na weekend. To baza kodu.

To też bardzo osobiste. GBrain opiera się na specyficznych przepływach pracy Garry'ego Tana — jego ludziach, firmach, harmonogramie wydawniczym. Architektura jest przenośna, ale implementacja nie polega na przeciąganiu i upuść. Nie możesz npm zainstalować czyjegoś mózgu.

A pytanie o skalę różni się od RAG czy Wiki. Repozytorium mózgowe GBraina obejmuje 17 888 stron — imponujące jak na system osobisty, niewielkie jak na przedsiębiorstwo. Zaplecze Postgres + pgvector teoretycznie mogłoby skalować się dalej, ale architektura umiejętności zakłada jednego operatora, który rozumie cały system.

Rzeczywistość biznesowa. Ta architektura dobrze pasuje do konkretnego wzorca przedsiębiorstwa: użytkownika zaawansowanego, który pełni rolę mnożnika siły dla swojego zespołu. Starszy analityk prowadzący autonomiczne procesy badawcze. Lider produktu, który potrzebuje codziennej aktualizacji analizy konkurencyjnej bez prośby. Kierownik inżynierii, którego agent monitoruje stan wdrożenia i eskaluje autonomicznie.

Ale nie pasuje to do typowego wdrożenia w przedsiębiorstwie, gdzie "daj wszystkim dostęp do asystenta wiedzy". Koszty inżynierskie na użytkownika są zbyt wysokie, a umiejętności tworzenia wymagają poziomu zrozumienia systemu, którego większość pracowników wiedzy nie posiada. Przynajmniej jeszcze nie.

Werdykt: Używaj umiejętności grubych, gdy twoja wiedza musi wywołać autonomiczne działania, gdy jesteś gotów zainwestować w inżynierię warstwy umiejętności i gdy jeden zaawansowany użytkownik może zdefiniować workflow dla zespołu. Nie używaj go, gdy potrzebujesz szerokiego dostępu organizacyjnego lub gdy twój zespół nie jest w stanie utrzymać kodu umiejętności.

Porównanie: ten sam problem, trzy kompromisy

Oto co przeoczą dyskurs "RAG umarł": te architektury nie konkurują. Rozwiązują różne wersje tego samego problemu. Wybór między nimi to decyzja projektowa, a nie test lojalności.

Diagram autora: Macierz porównania trójstronnego

Decyzja zaczyna się od jednego pytania: czym zajmuje się Twój agent?

Diagram autora: Drzewo decyzyjne — Jakie jest zadanie Twojego agenta?

Twój agent zdobywa odpowiedzi z dużego korpusu. Masz tysiące dokumentów. Zmieniają się regularnie. Użytkownicy zadają pytania i potrzebują szybkich odpowiedzi. Twoim priorytetem jest wysyłka czegoś gotowego do produkcji z znanym modelem kosztowym.

Używaj RAG. To nie jest efektowne, ale to architektura, która skaluje się do rozmiarów korpusów, jakie większość organizacji faktycznie posiada. Połącz go z rerankerem i pokryjesz 80% przypadków użycia asystenta wiedzy.

Twój agent buduje wiedzę, która powinna się kumulować z czasem. Masz setki źródeł — artykuły naukowe, dokumenty regulacyjne, analizy konkurencji, specyfikacje techniczne. Wartość nie tkwi w żadnym pojedynczym dokumencie, lecz w powiązaniach między nimi. Chcesz, żeby twój agent stawał się coraz mądrzejszy, im dłużej go używasz.

Użyj LLM Wiki. Podaj mu swoje źródła, pozwól mu budować odwołania krzyżowe i zapytuj skompilowaną wiki zamiast surowych fragmentów. Twoje setne zapytanie będzie znacznie lepsze niż pierwsze — czego RAG nigdy nie będzie w stanie obiecać.

Twój agent musi działać na podstawie tego, co wie, bez proszenia. Nie chcesz tylko odpowiedzi. Chcesz, aby twój agent monitorował, oznaczał, wzbogacał i realizował. Chcesz, żeby działał podczas snu, rejestrował informacje z powrotem do systemu, uruchamiał przepływy pracy przy zmianie warunków.

Używaj umiejętności otyłości. Ale budżet na inżynierię. To nie jest weekendowy hack — to baza kodu z testami, ocenami i nakładem na konserwację. Efektem jest agent, który działa, a nie tylko odpowiada.

Hybrydowa rzeczywistość. Systemy produkcyjne nie będą trzymać się jednego pasa. Najbardziej zaawansowane architektury łączą wszystkie trzy: RAG dla warstwy wyszukiwania (znajdowanie istotnej zawartości na dużą skalę), Wiki dla warstwy syntezy (kompilacja pobranych treści do trwałej wiedzy) oraz umiejętności dla warstwy akcji (operacjonalizacja tej wiedzy w autonomicznych przepływach pracy).

Claude Code już sugeruje tę zbieżność. CLAUDE.md pliki działają jak mini-wiki (trwały kontekst, który kumuluje się między sesjami). Pamięć automatyczna uczy się na podstawie interakcji (kumulacja). Umiejętności wywołują przepływy pracy (akcję). To nie jest celowe wdrożenie wszystkich trzech wzorców — ale te same naciski przyniosły te same rozwiązania.

Dokąd to zmierza

Podział na trzy strony nie potrwa długo. Podobnie jak bazy danych ewoluowały od "wybierz SQL lub NoSQL" do systemów hybrydowych obsługujących oba te systemy, tak architektury wiedzy się zbliżają.

Wczesne oznaki są już widoczne. Rozszerzenia społecznościowe LLM Wiki v2 firmy Karpathy dodają warstwy wyszukiwania na skompilowanych wiki — łącząc skalę łączącą się ze skalą. Umiejętności GBraina już teraz zapytują backend Postgres + pgvector — akcja spotyka się z wyszukiwaniem. A platformy korporacyjne, takie jak Neo4j, budują warstwy wiedzy łączące bazy danych grafów, wyszukiwanie wektorowe i rozumowanie semantyczne w jednym punkcie dostępowym.

Pytanie na 2026 rok nie brzmi "która architektura wygra". Chodzi o to, jak szybko granice między pobieraniem, kompilowaniem i działaniem rozmywają się w jednym systemie operacyjnym z wiedzą, który obsługuje wszystkie trzy elementy.

Diagram autora: Konwergencja — pobieranie, kompilacja, nakładanie się działania

Jeśli chcesz zacząć eksplorować już dziś:

• RAG: Samouczek RAG od LangChain to wciąż najszybsza droga do działającego prototypu
• LLM Wiki: Sedno Karpathy'ego to 200 linii schematu, które możesz dziś wykorzystać przeciwko Claude'owi lub GPT
• Fat Skills: repozytorium GBraina jest otwartoźródłowe — przeczytaj RESOLVER.md i THIN_HARNESS_FAT_SKILLS.md zanim przeczytasz jakikolwiek kod

Warstwa wiedzy to ta część stosu agentów, o której nikt nie mówi, dopóki nie zepsuje się. Teraz już wiesz, jakie masz opcje.

OpenAI cicho powiedziało, żebyś wyrzucił stos promptów

A Anthropic powiedział to samo. Trzy ery promptowania — i tego, czego najmądrzejsi modelki naprawdę od ciebie oczekują.

ai.gopubby.com

OpenAI Symphony kontra Claude Managed Agents kontra CrewAI: Który wzorzec orkiestracji agentów wygrywa

Trzy architektury sprawdzone. 617 tys. dolarów różnicy kosztów rocznie. Jeden zwycięzca z optymalizacją Pareto.

ai.gopubby.com

Cztery linie, których każdy CLAUDE.md potrzebuje

Co zdiagnozował Karpathy, co 60 000 programistów dodało do zakładek i dlaczego ograniczenia behawioralne przewyższają listy kontrolne funkcji

levelup.gitconnected.com

Inżynieria uprzęży: Co każdy inżynier AI powinien wiedzieć w 2026 roku

Trzy obozy, trzy architektury — i to, co Opus 4.7 właśnie udowodnił o wszystkich

ai.gopubby.com

Zanim pójdziesz! 🦸🏻♀️

Jeśli podobała ci się moja historia i chcesz mnie wesprzeć:

1. Rzuć trochę Medium miłości 💕 (brawa, komentarze i podkreślenia), wasze wsparcie znaczy dla mnie wszystko. 👏
2. Śledź mnie na Medium i subskrybuj, aby otrzymywać mój najnowszy artykuł🫶

O nim - Yanli Liu - Medium

Przeczytaj teksty Yanli Liu na Medium. Dzienny specjalista finansowy z Luksemburga, doświadczony programista i pasjonat...

medium.com