O czym jest ten film
- Andrej Karpathy spopularyzował ideę „LLM wiki” — wzorca budowania osobistej bazy wiedzy, w której to model językowy pomaga tworzyć i utrzymywać połączony zbiór plików Markdown.
- Pomysł zdobył ogromną popularność (gist z 40 tys. gwiazdek), bo jest prosty: można go wkleić do agenta kodującego i „jednym strzałem” zbudować własne wiki.
- Zamiast bezmyślnie indeksować dokumenty (jak w klasycznym RAG), LLM czyta każde źródło, wyciąga kluczowe informacje i wplata je w istniejącą strukturę — budując graf wiedzy.
- Główny problem klasycznego podejścia: brak standardu. Każdy buduje wiki inaczej, więc nie da się ich sensownie wymieniać między ludźmi ani zespołami.
- Google wypuściło Open Knowledge Format (OKF) — minimalny, otwarty standard nakładany na ideę Karpathy’ego, który ujednolica strukturę i metadane.
- OKF standaryzuje dwie rzeczy: sposób organizacji informacji (dokumenty encji, koncepcje, indeksy) oraz konkretne pola w metadanych (YAML front matter).
- Jedynym wymaganym polem metadanych jest
type— to ono daje kategoryzację; reszta (tytuł, tagi, powiązania) jest opcjonalna, ale zalecana. - Wdrożenie jest banalne: wystarczy skopiować plik
spec.mdz repozytorium OKF do agenta i kazać mu zbudować nowe wiki albo zrefaktoryzować istniejące (można użyć subagentów przy dużej skali). - Autor udostępnia gotowy „bundle” OKF z transkryptami swoich najlepszych filmów o AI coding, który można natychmiast wciągnąć do własnego drugiego mózgu i odpytywać.
- Zarzut wobec OKF („zbyt prosty, mało wnosi ponad wiki Karpathy’ego”) jest częściowo słuszny, ale zdaniem autora minimalizm to zaleta — to najcieńsza możliwa warstwa interoperacyjności.
Redakcyjne tłumaczenie
Punkt wyjścia: LLM wiki Karpathy’ego
Kilka miesięcy temu Andrej Karpathy przedstawił ideę „LLM wiki” — wzorca budowania osobistych baz wiedzy z pomocą modeli językowych. Pomysł błyskawicznie się przyjął i nie bez powodu, bo tkwi w nim ogromna siła płynąca z prostoty. Pojedynczy dokument Markdown opublikowany na GitHubie jako gist zebrał 40 tysięcy gwiazdek. I naprawdę — możesz wziąć ten plik, skopiować go, wkleić do swojego agenta kodującego i poprosić, żeby zbudował ci LLM wiki. Zrobi to w zasadzie za jednym podejściem. Wejście w temat jest więc bardzo łatwe.
Idea jest taka: budując osobistą bazę wiedzy — swój „drugi mózg” — zamiast po prostu wrzucać stertę dokumentów albo indeksować wszystko pod RAG, pozwalamy modelowi pomóc nam stworzyć coś mądrzejszego. Przyrostowo budujemy i utrzymujemy trwałe wiki złożone z ustrukturyzowanych, wzajemnie połączonych plików Markdown. Kiedy z czasem dorzucamy kolejne źródła — transkrypty spotkań, dokumenty planistyczne, artykuły z sieci — model nie tylko je indeksuje. Czyta każdy plik, wyciąga kluczowe informacje i integruje je z istniejącym wiki. Aktualizuje na przykład strony encji, które sam tworzy, dzięki czemu powstaje graf wiedzy, po którym agent może się poruszać i pamiętać wszystkie ważne informacje, jakie do niego wprowadzamy.
(Informacja dodatkowa: „drugi mózg” to popularne określenie osobistego, zewnętrznego systemu gromadzenia wiedzy — spopularyzowane m.in. przez metodę Building a Second Brain Tiago Fortego. „Encja” w tym kontekście to osobna strona poświęcona konkretnemu bytowi — osobie, narzędziu, koncepcji — do której odwołują się inne dokumenty.)
Problem: brak wspólnego standardu
Na tym etapie praktycznie każdy buduje własne LLM wiki w swoim drugim mózgu. Ale to nie wystarcza. Główny problem polega na tym, że kiedy bierzesz ten gist i tworzysz własną wersję wiki, będzie ona zbudowana inaczej niż wersja kolejnej osoby robiącej dokładnie to samo. Nie ma standardu. A skoro go nie ma, to praktycznie nie da się podzielić swoim wiki z kimś innym. I to jest problem.
Łatwo wyobrazić sobie mnóstwo sytuacji, w których chciałbyś przez jakiś czas budować bazę wiedzy, a potem udostępnić ją innym — na przykład członkom swojego zespołu. Może chcesz jedno wspólne wiki dla całego zespołu, z którego niezależnie korzystają „drugie mózgi” poszczególnych osób. Może chcę stworzyć wiki dla swoich treści z YouTube i udostępnić je tobie. Powodów są tysiące. Ale jeśli twój agent nie wie dokładnie, jak zbudowałem swoje wiki — jakich użyłem metadanych i jak wyglądają moje pliki encji — nie będzie w stanie optymalnie po nim wyszukiwać.
Potrzebujemy standardu, żeby wszyscy budowali wiki w ten sam sposób i żeby dało się je swobodnie wymieniać.
Rozwiązanie: Open Knowledge Format od Google
I właśnie to udostępnił Google w postaci swojego Open Knowledge Format. To rzecz pięknie prosta — tak jak sama idea LLM wiki Karpathy’ego. To po prostu prosty standard zbudowany na wierzchu, dzięki któremu masz gwarancję, że budujesz swoje wiki w sposób zrozumiały dla drugich mózgów innych osób i odwrotnie.
W tym filmie chcę pokazać, dlaczego OKF jest tak potężny — to naprawdę przyszłość osobistych agentów — a także jak łatwo zacząć z tym standardem, zarówno przy nowych LLM wiki, jak i przy przenoszeniu istniejących do tego formatu. To bardzo proste. I niezależnie od tego, jak bardzo zamierzasz swoje wiki udostępniać (albo nie), warto to zrobić choćby jako optymalizację nakładaną na ideę Karpathy’ego.
Wiem, że Google w wyścigu AI obecnie odstaje — Gemini nie jest tak dobre jak GPT czy Claude — ale firma wypuszcza naprawdę wartościowe rzeczy dotyczące tego, jak skutecznie wykorzystywać modele językowe. To zupełnie inny obszar niż samo budowanie modeli. Dlatego uważam, że warto się w to zaangażować, nawet jeśli OKF ostatecznie nie stanie się standardem dla osobistych agentów. Bo coś takiego na pewno powstanie — więc dobrze zrozumieć to już teraz.
Co dokładnie standaryzuje OKF
OKF standaryzuje dwie rzeczy. Pierwsza to sposób organizacji informacji — na przykład dokumentów encji i koncepcji. Druga to konkretne pola, które mają się znaleźć w metadanych. Metadane to informacje, którymi oznaczamy górę każdego dokumentu, żeby dać agentowi bogatszy zestaw danych — możemy wtedy odpytywać go choćby po tytule czy tagach. Mamy więc kategoryzację, a to jedna z najważniejszych rzeczy pozwalających agentowi poruszać się po naszym wiki jak po grafie wiedzy.
Najlepiej zobrazować to na przykładzie tradycyjnego wiki Karpathy’ego — jednego z pierwszych, jakie zbudowałem, gdy pojawiła się ta idea. Na jego przykładzie pokażę też problemy, z jakimi się mierzymy.
Jak działa klasyczne wiki Karpathy’ego
Na samej górze każdego wiki znajduje się plik indeksu. Agent utrzymuje go za każdym razem, gdy wprowadza nowe informacje. To ten plik agent czyta jako pierwszy, przeszukując bazę wiedzy — praktycznie zawsze. Daje on wysokopoziomowy przegląd wszystkich dokumentów dostępnych w wiki: nazwę artykułu i krótkie streszczenie, dzięki czemu agent wie, czy dany dokument warto zgłębić w kontekście prośby użytkownika. Za każdym razem, gdy dodajemy nowe dokumenty, indeks ewoluuje. Agent go czyta, a jeśli na podstawie pytania uzna, że powinien zajrzeć na przykład do dokumentu encji o Supabase, wchodzi w szczegóły.
Mamy też metadane — tytuł i tagi — dzięki którym agent może wyszukiwać po konkretnych atrybutach. Jeśli chce spojrzeć na kategorię „bezpieczeństwo”, może odfiltrować tylko te dokumenty. Dalej mamy pełną treść, działającą jak skill.md — na zasadzie progresywnego ujawniania (progressive disclosure): indeks mówi, jaką wiedzę zawiera dany dokument, a agent czyta go w całości dopiero wtedy, gdy to zasadne. Na dole linkujemy też do powiązanych koncepcji — i to właśnie te linki dają nam widok grafu, w którym widać, jak wszystkie encje i dokumenty są ze sobą połączone. Agent może przez to przesiewać, żeby zebrać naprawdę kompletny zestaw informacji, jeśli pytanie tego wymaga.
(Informacja dodatkowa: „progresywne ujawnianie” to zasada projektowa, w której szczegóły pokazywane są dopiero wtedy, gdy są potrzebne — tu chodzi o to, że agent najpierw czyta streszczenie, a pełny dokument dopiero w razie potrzeby, oszczędzając kontekst.)
Patrząc na jeden z takich dokumentów, można poczuć, że budowanie całej tej wiedzy z czasem jest przytłaczające. Ale w LLM wiki oddajesz stery całkowicie modelowi. Nie musisz być techniczny. Nie musisz poświęcać dużo czasu na utrzymanie. Cała korzyść z wiki polega na tym, że zanim mieliśmy do tego modele językowe, tworzenie takiej bazy wiedzy było zbyt żmudne — to my byliśmy odpowiedzialni za rozumienie powiązanych koncepcji i budowanie tego z czasem, w miarę dokładania informacji. To mnóstwo żmudnej pracy, w której modele są naprawdę bardzo dobre.
Dlaczego samo wiki Karpathy’ego to za mało
Ale choć modele są w tym dobre, nie zbudują tego systemu w taki sam sposób jak model kogoś innego. Sposób linkowania powiązanych koncepcji może się różnić. Sposób strukturyzowania informacji też. Nawet metadane — co, jeśli ja nie mam pola „tags”, tylko pole „categories”? Nawet tak drobna różnica może sprawić, że gdybym oddał swoją bazę wiedzy agentowi innej osoby, ten nie wiedziałby, jak wyszukiwać kategorycznie. Musiałby najpierw zanurzyć się w metadane, żeby to zrozumieć — a mógłby w ogóle nie podjąć takiej decyzji. Wszystkie te drobne problemy zaczynają się kumulować, kiedy nie masz tych samych metadanych ani tych samych folderów. I to właśnie chcemy rozwiązać przez OKF.
Jak zacząć: plik spec.md
Jeśli chcesz budować z OKF — stworzyć nową bazę wiedzy w tym formacie albo przerobić istniejącą — nie szukaj dalej niż plik spec.md. Jest w ich repozytorium (link w opisie). Działa tak jak gist Karpathy’ego: kopiujesz dokument jednym kliknięciem, wkładasz do agenta kodującego i mówisz mu, żeby zbudował wiki zgodne z Open Knowledge Format albo zrefaktoryzował istniejące. Agent poradzi sobie z każdym z tych zadań doskonale, bo spec.md działa jak swego rodzaju „skill” — uczy agenta wszystkiego, co musi wiedzieć o standardzie: oto terminologia, oto jak strukturyzujemy bundle, oto jak budujemy front matter YAML i jakie atrybuty ma każdy dokument (jak tagi do kategoryzacji). To jedno źródło prawdy to wszystko, czego agent potrzebuje.
Ponieważ format jest tak prosty, agent raczej się nie pogubi. Plik jest dość długi, ale jak na to, co dzisiejsze modele potrafią obsłużyć — zwłaszcza GPT-5.5 czy Opus 4.8 — to niewiele instrukcji. Nie ma też znaczenia skala twojej obecnej bazy wiedzy przy refaktoryzacji, bo możesz wprost poprosić agenta, żeby użył subagentów do przerobienia różnych sekcji bazy naraz. Łatwo się skaluje i łatwo puścić agenta przez ten spec.
(Informacja dodatkowa: „bundle” to w terminologii OKF spakowany zestaw plików tworzący jedno wiki — autor używa tego słowa wymiennie z „wiki OKF”. „Front matter YAML” to blok metadanych na początku pliku Markdown, ujęty między liniami ---.)
Sponsor: PostHog
Sponsorem dzisiejszego odcinka jest PostHog — jedno miejsce do zrozumienia, jak użytkownicy faktycznie korzystają z twojej aplikacji, do debugowania i naprawy błędów oraz testowania i wdrażania zmian. Sam używam PostHog w Archonie, moim otwartoźródłowym narzędziu do budowania harnessów AI do kodowania, i codziennie opieram się na płynących stąd danych, żeby wiedzieć, jak ulepszać Archon zgodnie z realnymi potrzebami użytkowników. Instalacja jest banalnie prosta — klikasz „install with AI” na stronie, uruchamiasz jednym poleceniem kreatora, który jak starszy inżynier w kilka minut pomoże ci wdrożyć analitykę w całej aplikacji. Można tworzyć własne widoki danych i schodzić do bardzo szczegółowego poziomu — aż po pojedyncze uruchomienia i parametry. W produkcji nie można latać po omacku; potrzebujesz obserwowalności, a PostHog jest w tym najlepszy. Link w opisie.
OKF jako fundament: dzielenie się wiedzą
Wspomniałem o tym na początku, ale to naprawdę przyszłość osobistych agentów. To, co MCP zrobiło dla komunikacji agent–narzędzie, OKF robi dla komunikacji agent–baza wiedzy.
(Informacja dodatkowa: MCP — Model Context Protocol — to otwarty standard łączenia agentów AI z zewnętrznymi narzędziami i źródłami danych.)
Jedną z najważniejszych rzeczy w specyfikacji jest to, że OKF jest standardem zarówno dla konsumowania baz wiedzy (przeszukiwania ich), jak i dla ich produkowania — czyli tego, jak z czasem rozwijamy wiki i budujemy strony encji, o czym Karpathy pisał w pierwotnym giście. Naprawdę budujemy tu na jego fundamencie.
Ciekawe jest to, że OKF jest świetny nie tylko do dzielenia się bazami wiedzy albo do wspólnego wiki dla zespołu. Jest też bardzo przydatny, nawet jeśli nigdy nie zamierzasz niczego udostępniać. Pomyśl: jeśli wszyscy mają ten sam standard budowania własnych osobistych baz wiedzy, wszyscy mogą łatwiej wymieniać się pomysłami — „oto strony encji, które świetnie się u mnie sprawdzają, i tak chcę organizować rzeczy w ramach standardu”. A skoro standard jest fundamentem, innym łatwiej jest przejąć te pomysły. Myślę, że zobaczymy, jak taki standard ewoluuje z czasem, coraz bardziej ułatwiając ludziom tworzenie bogatych baz wiedzy bez konieczności długiego projektowania ich z modelem na starcie. Nie sądzę, żeby akurat OKF ostatecznie stał się tym standardem — ale coś podobnego na pewno się pojawi.
Przykład: gotowy bundle z filmami o AI coding
Największą korzyścią z OKF jest oczywiście dzielenie się wiki z innymi — i to prowadzi mnie do przykładu, który jest zarazem prezentem. Zbudowałem bundle (tak nazywa się wiki OKF), który pakuje wszystkie moje ulubione filmy o AI coding z mojego kanału.
Wiem, że wielu z was nie ogląda każdego mojego filmu w całości. Przesiewacie treści, bierzecie transkrypt, wrzucacie go do drugiego mózgu i zadajecie pytania. Już to robicie — a ja chcę wam to ułatwić, pakując zestawy filmów wcześniej, żebyście mogli bez trudu wciągnąć je do drugiego mózgu i pytać o to, co naprawdę was interesuje albo nad czym akurat pracujecie.
Wygląda to tak: najpierw bierzesz spec i dajesz go swojemu agentowi kodującemu, żeby sam nauczył się OKF. Potem idziesz do repozytorium z moim bundlem wiedzy o AI coding (link w opisie), wklejasz do agenta jeden prompt, podajesz mu link do repo i mówisz, żeby przeczytał README i wszystko skonfigurował. Agent już rozumie OKF, więc łączy te dwie rzeczy ze sobą, wciąga bundle do twojego lokalnego Obsidiana, Notion czy czegokolwiek, w czym zarządzasz wiedzą — i możesz od razu zadawać pytania. Nie musisz sam wprowadzać transkryptów. To najłatwiejszy sposób, żeby twórcy treści w ogóle dzielili się swoją wiedzą ze światem — tworząc bundle. Ja tworzę je teraz dla wszystkich swoich filmów.
Jak wygląda konfiguracja OKF w praktyce
Wejdźmy do środka. Pokażę, jak konfiguruję OKF, i przejdziemy przez przykładowy bundle. W swoim drugim mózgu dla każdego systemu, który buduję, zawsze mam dokument na najwyższym poziomie opisujący, jak on działa — na przykład: „tak pracuję z bundlami OKF, a oto różne bundle, które mam”. Mam więc indeks, dzięki któremu agent wie, w jakie bundle może wejść, i może przeczytać indeks znajdujący się w środku każdego z nich. Mamy więc niejako dwie warstwy indeksowania.
Zbudowałem też prosty skrypt CLI (jest w przykładowym bundle, który można sklonować), który ułatwia agentowi z poziomu wiersza poleceń wylistowanie bundli, obejrzenie konkretnego indeksu, a gdy znajdzie plik, który chce przeczytać — odczytanie go po konkretnym ID bundla i koncepcji. Dodałem więc trochę własnej organizacji na wierzchu OKF, dotyczącej tego, jak zarządzam wieloma bundlami, ale poza tym trzymam się formatu dokładnie.
Wnętrze bundla: sekcje, indeksy i pole type
Wejdźmy w bundle, którego GitHub właśnie udostępniłem. W indeksie widać dwie sekcje — to raczej mały bundle, nie chciałem robić czegoś super skomplikowanego. Pierwsza sekcja to filmy: jest ich tylko cztery, ale to najlepsze i najbardziej aktualne materiały o AI coding na moim kanale. Druga to koncepcje — rzeczy, o których mówię w wielu filmach i które chciałem wyodrębnić do osobnych stron encji.
Indeks wskazuje sekcje, ale nie zawiera listy każdego pojedynczego pliku — po prostu pozwalam agentowi odczytać pliki znajdujące się w folderach „concepts” czy „videos”. Agent może wylistować wszystkie pliki, może odczytać indeks wewnątrz samych „concepts” — jak wolisz. Przejdzie przez kolejne warstwy dokumentów albo po prostu zrobi wyszukiwanie po słowach kluczowych.
Wejdźmy na przykład w „PIV loop” — to podstawowy model myślowy, którego zawsze uczę przy AI coding. Bardzo ważne jest, żeby mieć własny proces: planować, implementować i walidować to, co tworzysz z agentem kodującym.
(Informacja dodatkowa: PIV loop — Plan, Implement, Validate — to autorska pętla pracy Cole’a Medina: planuj, implementuj, waliduj.)
Na górze mamy front matter YAML. Pole type to jedyne wymagane przez OKF pole metadanych, bo to ono daje kategoryzację dokumentom. Tutaj type to „concept”; przy filmie type to „video”. Dzięki temu możemy wyszukiwać osobno po samych filmach albo po samych koncepcjach — co jest szczególnie potężne przy bundlach znacznie większych niż ten.
Mamy też wszystkie opcjonalne pola OKF: title, tags, related videos. Tak łączymy rzeczy ze sobą. W tamtym wcześniejszym wiki elementy były po prostu linkowane na dole; teraz nawigacja jest łatwiejsza, bo powstaje standard tego, jak łączymy encje. Każde z tych pól jest opcjonalne — wymagany jest tylko type. Ale to, że nie zawsze masz te pola, nie znaczy, że agent ich nie zrozumie: jeśli twój agent jest konsumentem OKF — jeśli dałeś mu spec i nauczyłeś go konsumować ten format — będzie wiedział, jak wykorzystać te pola do lepszego wyszukiwania i poruszania się po grafie wiedzy.
Poza tym mamy całą treść o pętli PIV — trzymałem ją prostą — z linkami także do filmów, co może trochę dubluje pole „related videos”. Pewnie mógłbym ten bundle dopracować, ale chciałem mieć wstępny przykład, który od razu wnosisz do drugiego mózgu i zaczynasz zadawać pytania.
Demonstracja: agent w działaniu
Pokażę przykład w terminalu. Na najwyższym poziomie drugiego mózgu zapytałem po prostu: „jakie mam bundle?”. Agent uruchomił polecenie — użył tego małego narzędzia CLI, żeby wylistować wszystkie moje bundle — i mi je podał. Potem zadałem pytanie, nawet nie wskazując, który konkretnie bundle ma przejrzeć: „Jaki jest największy pojedynczy pomysł Cole’a na uzyskiwanie niezawodnego kodu z asystenta AI do kodowania?”. Agent uruchomił w sumie cztery polecenia. Najpierw postanowił przeczytać indeks „Cole AI coding” (to ten GitHub, który dla was mam). Na podstawie indeksu uznał: „spójrzmy na koncepcje”. Z koncepcji wywnioskował: „najważniejsza rzecz to context engineering — przeczytajmy koncepcję context engineeringu”. Widać więc progresywne ujawnianie w akcji: agent sam ustala, gdzie musi zajrzeć, żeby znaleźć dla mnie odpowiedź — i na końcu dostajemy finalną odpowiedź.
Aż przyjemnie patrzeć, jak to działa. Przy tak ustrukturyzowanej wiedzy agentowi jest bardzo łatwo zacząć praktycznie bez kontekstu i schodzić coraz głębiej dokładnie do tego, czego potrzebujemy. To właśnie daje nam OKF jako standard.
Krytyka: czy OKF jest „zbyt prosty”?
Jeśli na tym etapie ktoś nie jest przekonany do idei standardu dla LLM wiki, to nie wiem, co więcej powiedzieć. Jedyny zarzut, który uważam za faktycznie zasadny, brzmi: OKF jest zbyt prosty — niewiele wnosi ponad wiki Karpathy’ego. Widziałem to kilka razy podczas researchu, a przygotowanie tych filmów kosztuje mnie sporo czasu.
I ten zarzut jest po części słuszny. Bo co OKF realnie dodaje ponad wiki Karpathy’ego? Mówi dokładnie o tym, jak organizujesz pliki — mają indeksy wewnątrz folderów oraz indeks najwyższego poziomu, jak w moim bundle. Tego akurat wcześniej w swoich wiki nie miałem. Do tego dochodzą konkretne pola metadanych, gdzie type jest wymagane, a reszta opcjonalna, choć zalecana. I to w zasadzie tyle. Jak organizujemy i jakie są metadane — praktycznie cały standard.
Argument, że „to niewiele daje”, jest więc częściowo słuszny. Ale myślę, że właśnie o to chodzi. Standard jest minimalnie opiniotwórczy — to najcieńsza warstwa, jakiej potrzebujemy, żeby produkować i konsumować te wiki dokładnie w ten sam sposób u wszystkich agentów, które w OKF wchodzą. Uważam, że to zaleta, a nie wada. To, że nie ma tu wiele „treści”, może wydawać się nieintuicyjne, ale w moim przekonaniu to dobrze.
Zachęta na koniec
Zachęcam, żebyś po prostu wypróbował ten bundle, który dla ciebie przygotowałem. Daj agentowi spec, potem ten prompt i zacznij zadawać pytania o AI coding — jak używam subagentów, czym jest pętla PIV — i zobacz, jak łatwo agent to dla ciebie wyciąga. To wszystko, co mam dziś na temat OKF. To naprawdę przyszłość osobistych agentów. Jeśli film ci się przydał i czekasz na więcej materiałów o AI coding i drugich mózgach, będę wdzięczny za łapkę w górę i subskrypcję. Do zobaczenia w następnym filmie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.LLM wiki bije zwykły RAG dzięki aktywnej integracji wiedzy
Na czym polega: Zamiast wrzucać dokumenty do indeksu wektorowego, pozwalasz modelowi przeczytać każde źródło, wyciągnąć esencję i wpleść ją w istniejącą strukturę powiązanych plików Markdown — budując graf wiedzy z aktualizowanymi stronami encji.
Jak stosować: Skopiuj gist Karpathy’ego do swojego agenta kodującego i każ mu zbudować wiki; potem dokładaj źródła (transkrypty, notatki, artykuły) i każ agentowi integrować, a nie tylko archiwizować.
Na co uważać: Jakość zależy od tego, jak dobrze model rozpozna powiązania — przy dużej ilości źródeł kontroluj, czy strony encji nie puchną i czy nie powstają duplikaty. To nie zwalnia z okazjonalnego przeglądu przez człowieka.
2.Brak standardu to główna bariera dzielenia się wiedzą
Na czym polega: Każde wiki zbudowane „po swojemu” ma inną strukturę folderów i inne metadane, więc agent innej osoby nie potrafi go optymalnie przeszukać.
Jak stosować: Jeśli planujesz kiedykolwiek dzielić się bazą wiedzy (zespół, klienci, odbiorcy), od początku buduj ją na wspólnym standardzie zamiast konwertować później.
Na co uważać: Problemy się kumulują — jedno inne pole metadanych (np. categories zamiast tags) potrafi zepsuć wyszukiwanie kategoryczne u odbiorcy, choć u ciebie działało.
3.OKF standaryzuje tylko dwie rzeczy — i to jest jego siłą
Na czym polega: Open Knowledge Format ujednolica wyłącznie organizację plików (indeksy w folderach + indeks nadrzędny) oraz pola metadanych w YAML front matter. Nic więcej.
Jak stosować: Traktuj OKF jako cienką warstwę interoperacyjności nakładaną na dowolne wiki — nie przebudowuj całej filozofii swojej bazy, tylko dopasuj strukturę folderów i metadane.
Na co uważać: Minimalizm oznacza, że OKF nie rozwiąże za ciebie problemów jakości treści ani sensownego podziału na encje — to nadal twoja robota. Standard gwarantuje tylko czytelność między agentami.
4.Pole type jest jedynym wymaganym — i najważniejszym
Na czym polega: type (np. video, concept) daje kategoryzację, dzięki której agent może wyszukiwać osobno po typach dokumentów. Pozostałe pola (title, tags, related) są opcjonalne, ale zalecane.
Jak stosować: Zawsze nadawaj type każdemu dokumentowi i projektuj typy pod realne zapytania („pokaż mi tylko koncepcje”, „tylko filmy”) — to opłaca się przy większych bundlach.
Na co uważać: Zbyt drobnoziarniste typy utrudnią nawigację; przemyśl niewielki, spójny zbiór typów, zanim rozrośnie się baza.
5.Wdrożenie sprowadza się do skopiowania spec.md
Na czym polega: Plik spec.md z repo OKF działa jak „skill” — uczy agenta terminologii, struktury bundli i budowy front matter. Wklejasz go i każesz zbudować lub zrefaktoryzować wiki.
Jak stosować: Przy migracji istniejącej bazy każ agentowi użyć subagentów do równoległego przerobienia różnych sekcji — dzięki temu skala bazy nie jest przeszkodą.
Na co uważać: Choć spec jest długi, mieści się w oknie kontekstu nowoczesnych modeli — ale przy dużych migracjach weryfikuj wynik sekcja po sekcji, bo subagenty mogą niespójnie interpretować reguły.
6.OKF to dla baz wiedzy to, czym MCP jest dla narzędzi
Na czym polega: Standard obejmuje zarówno konsumowanie (przeszukiwanie), jak i produkowanie (rozwijanie wiki i stron encji) — dwustronny protokół komunikacji agent–wiedza.
Jak stosować: Ucz agenta obu ról: jako konsument ma umieć wykorzystać pola metadanych do nawigacji po grafie; jako producent ma spójnie rozbudowywać encje przy każdym nowym źródle.
Na co uważać: OKF prawdopodobnie nie będzie tym ostatecznym standardem — autor wprost to mówi. Nie buduj sztywnych zależności; traktuj to jako format przejściowy, który może ewoluować.
7.Standard opłaca się nawet, gdy nigdy nie udostępniasz wiki
Na czym polega: Wspólny format ułatwia wymianę pomysłów na organizację — możesz przejąć czyjś sprawdzony układ stron encji, bo fundament jest ten sam.
Jak stosować: Nawet dla prywatnej bazy trzymaj się OKF, żeby móc bez tarcia importować cudze wzorce organizacyjne i eksportować własne.
Na co uważać: Korzyść jest realna tylko, gdy faktycznie trzymasz się standardu; „prawie OKF” z własnymi odstępstwami psuje interoperacyjność, o którą chodzi.
8.Bundle twórcy jako gotowa wiedza do wciągnięcia
Na czym polega: Cole udostępnia bundle OKF z transkryptami swoich najlepszych filmów; wystarczy dać agentowi spec, wskazać repo i wkleić prompt, by wciągnąć całość do Obsidiana/Notion i od razu odpytywać.
Jak stosować: Zamiast oglądać każdy film w całości, importuj takie bundle i zadawaj konkretne pytania związane z tym, nad czym pracujesz. Twórcy: rozważ pakowanie własnych treści w bundle jako formę dystrybucji wiedzy.
Na co uważać: Jakość odpowiedzi zależy od jakości bundla — mały przykład (4 filmy) jest raczej demonstracją niż kompletną bazą; nie myl dostępności z kompletnością źródła.
9.Dwuwarstwowe indeksowanie + CLI ułatwiają skalowanie wielu bundli
Na czym polega: Cole dokłada ponad OKF własny dokument nadrzędny listujący bundle oraz prosty skrypt CLI do listowania bundli, przeglądania indeksów i odczytu po ID — zachowując przy tym zgodność z formatem.
Jak stosować: Gdy masz wiele bundli, dodaj warstwę indeksu „bundli” i narzędzie CLI, żeby agent tanio nawigował z poziomu wiersza poleceń, zanim wczyta pełne dokumenty.
Na co uważać: Własne nakładki trzymaj ponad OKF, nie modyfikując samego formatu — inaczej stracisz przenośność bundli między agentami.
10.Progresywne ujawnianie oszczędza kontekst i zwiększa trafność
Na czym polega: Agent startuje niemal bez kontekstu: czyta indeks nadrzędny → wybiera sekcję → czyta indeks sekcji → dopiero wtedy pełny dokument. Dzięki temu schodzi dokładnie do potrzebnej informacji.
Jak stosować: Projektuj indeksy tak, by streszczenia jednoznacznie kierowały agenta do właściwego dokumentu; nie ładuj wszystkiego naraz — pozwól modelowi „drążyć” warstwami.
Na co uważać: Jeśli streszczenia w indeksie są mylące lub zbyt ogólne, agent zejdzie w złą gałąź i pominie odpowiedź. Dobre streszczenia encji to warunek działania całego mechanizmu.