Jun 11, 2026, 10:46 AM
This commit is contained in:
Paweł Domański
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "Agent Formatting Dialects (Dialekty Formatowania Agentów)"
|
||||
type: "concept"
|
||||
tags: [agent-ai, syntax, markdown, obsidian]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/what-happens-giving-keys-to-llm-obsidian]]", "[[summaries/obsidian-vault-as-knowledge-graph]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Agent Formatting Dialects (Dialekty Formatowania Agentów)
|
||||
|
||||
## Definition
|
||||
Specyficzne, niestandardowe rozszerzenia i dialekty formatów tekstowych (takie jak Obsidian-flavored Markdown), których agenty AI muszą się jawnie nauczyć, aby poprawnie pisać i modyfikować pliki wewnątrz wyspecjalizowanych środowisk programistycznych lub PKM.
|
||||
|
||||
## The Problem
|
||||
Standardowe modele LLM są trenowane na czystym języku Markdown (CommonMark / GFM). Jednak zaawansowane aplikacje, takie jak Obsidian, używają własnych, unikalnych dialektów:
|
||||
- Linki wewnętrzne w postaci podwójnych nawiasów kwadratowych: WikiLinks.
|
||||
- Bloki wyróżnień (Callouts): `> [!info]`.
|
||||
- Systemy wizualnych map myśli: pliki Canvas (`.canvas` na bazie struktur JSON).
|
||||
Bez jawnego przeszkolenia, agent AI piszący notatki cicho uszkadza składnię (np. generuje puste linki, psuje schematy YAML czy zrywa hierarchie), co wymaga manualnych poprawek ze strony człowieka.
|
||||
|
||||
## The Solution
|
||||
Tworzenie i wgrywanie dedykowanych zestawów reguł i wzorców (np. oficjalnej biblioteki [[entities/obsidian-skills]] od Steph Ango). Uczą one agenta precyzyjnej obsługi specyficznego dialektu, gwarantując pełną poprawność składniową przy autonomicznych operacjach na plikach.
|
||||
|
||||
## Sources
|
||||
- [[summaries/what-happens-giving-keys-to-llm-obsidian]]
|
||||
- [[summaries/obsidian-vault-as-knowledge-graph]]
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Claude Skills (Umiejętności Claude'a)"
|
||||
type: "concept"
|
||||
tags: [claude, agent-ai, modularity, system-design]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/best-12-claude-skills-setup]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Claude Skills (Umiejętności Claude'a)
|
||||
|
||||
## Definition
|
||||
Architektoniczny mechanizm rozszerzania możliwości agentów z rodziny Claude, polegający na grupowaniu instrukcji, przykładów i skryptów wykonawczych w odrębne, modularne foldery, które model ładuje dynamicznie tylko wtedy, gdy są one bezpośrednio dopasowane do zapytania użytkownika.
|
||||
|
||||
## How It Works
|
||||
Pojedyncza umiejętność (Skill) składa się z trzech opcjonalnych elementów:
|
||||
1. Pliku `SKILL.md` — zawierającego nazwę, opis (wyzwalacz) oraz precyzyjne instrukcje zachowania.
|
||||
2. Plików wspierających — szablonów dokumentów, logotypów czy przewodników marki.
|
||||
3. Skryptów wykonawczych (Python/Node.js) — które model może autonomicznie odpalać w tle do ciężkich zadań obliczeniowych lub edycyjnych.
|
||||
|
||||
## Incremental Context Loading
|
||||
Największą zaletą umiejętności jest tzw. **stopniowe ujawnianie (Incremental Context Loading)**. Agent nie ma wszystkich instrukcji wgranych na stałe do okna kontekstowego (co szybko przepełniłoby pamięć). Zamiast tego czyta jedynie krótkie opisy i nagłówki YAML z plików `SKILL.md`. Dopiero gdy zapytanie użytkownika pasuje do opisu (np. prośba o wygenerowanie pliku `.docx`), agent ładuje pełen zestaw instrukcji i plików powiązanych z tą konkretną umiejętnością.
|
||||
|
||||
## Sources
|
||||
- [[summaries/best-12-claude-skills-setup]]
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Compounding Feedback Loops (Kumulujące Pętle Sprzężenia)"
|
||||
type: "concept"
|
||||
tags: [knowledge-representation, machine-learning, system-design]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/15-obsidian-workflows-and-plugins]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Compounding Feedback Loops (Kumulujące Pętle Sprzężenia)
|
||||
|
||||
## Definition
|
||||
Praktyka i wzorzec architektoniczny polegający na ponownym wprowadzaniu wartościowych syntez wygenerowanych przez agenta AI podczas czatu z powrotem do bazy wiedzy jako trwałych notatek, co pozwala systemowi na trenowanie i wnioskowanie na bazie swojej własnej, doprecyzowanej wiedzy.
|
||||
|
||||
## How It Works
|
||||
Gdy użytkownik prowadzi eksplorację i prosi agenta AI o wygenerowanie głębokiego porównania, analizy rynkowej lub mapy relacji, ten wynik nie powinien ginąć w historii czatu. Proces przebiega następująco:
|
||||
1. Agent generuje wysokiej jakości syntezę lub odpowiedź.
|
||||
2. Odpowiedź ta jest zapisywana jako nowa strona (np. synteza lub notatka koncepcyjna) w `knowledge/`.
|
||||
3. Plik jest oznaczany specjalnym tagiem (np. `#machine-generated`), co pozwala na łatwe filtrowanie.
|
||||
4. Przyszłe zapytania i operacje ingestu korzystają już z tej zakumulowanej analizy, co buduje efekt procentu składanego (compounding knowledge).
|
||||
|
||||
## Why It Matters
|
||||
Zapobiega to marnowaniu zasobów obliczeniowych i intelektualnych. Baza wiedzy staje się dynamicznie rosnącym organizmem, który rozwija się wraz z każdą dyskusją i pytaniem użytkownika, podnosząc poziom inteligencji systemu wykładniczo.
|
||||
|
||||
## Sources
|
||||
- [[summaries/15-obsidian-workflows-and-plugins]]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "Context Stack Management (Zarządzanie Stosem Kontekstu)"
|
||||
type: "concept"
|
||||
tags: [agent-ai, system-design, prompt-engineering]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/5-mental-models-for-ai-agents]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Context Stack Management (Zarządzanie Stosem Kontekstu)
|
||||
|
||||
## Definition
|
||||
Inżynieryjny proces precyzyjnego komponowania, hierarchizowania i optymalizowania wszystkich warstw danych składających się na okno kontekstowe (RAM) agenta AI podczas jego aktywnej sesji operacyjnej.
|
||||
|
||||
## The Context Stack Layers
|
||||
Stos kontekstu nie jest jednolitą masą tekstu. Składa się z warstw o różnym rygorze i priorytecie:
|
||||
1. **Instrukcje systemowe (System Prompts)**: Stałe, głębokie definicje tożsamości, bezpieczeństwa i ról agenta (najwyższa waga).
|
||||
2. **Kontrakt aktywny (Active Instructions / Config)**: Lokalne reguły i ograniczenia projektu (np. pliki `CLAUDE.md`, `GEMINI.md` czy wczytane [[concepts/claude-skills]]).
|
||||
3. **Aktywny kontekst operacyjny (Active Context)**: Informacje o tym, nad czym dokładnie użytkownik obecnie pracuje w tej konkretnej minucie.
|
||||
4. **Historia konwersacji (Session History)**: Logi poprzednich wiadomości i kroków (zarządzane za pomocą strategii przycinania, aby uniknąć marnowania tokenów).
|
||||
5. **Dopasowane wycinki merytoryczne (Retrieved Chunks)**: Wyselekcjonowane fragmenty z bazy wiedzy wczytane za pomocą wyszukiwania semantycznego (RAG) lub serwerów [[concepts/mcp-servers]].
|
||||
|
||||
## The Core Tension
|
||||
Inżynierowie balansują na cienkiej linii między dostarczeniem modelowi zbyt małego kontekstu (co skutkuje halucynacjami i brakiem uziemienia w faktach) a przeładowaniem stosu (co prowadzi do eksplozji kosztów tokenów, powolnego czasu reakcji i ignorowania twardych wytycznych z instrukcji systemowych).
|
||||
|
||||
## Sources
|
||||
- [[summaries/5-mental-models-for-ai-agents]]
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "Doer-Judge Split (Separacja Wykonawcy od Sędziego)"
|
||||
type: "concept"
|
||||
tags: [agent-ai, system-design, validation, verification]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/5-mental-models-for-ai-agents]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Doer-Judge Split (Separacja Wykonawcy od Sędziego)
|
||||
|
||||
## Definition
|
||||
Zasada projektowania systemów agentowych, nakazująca fizyczny podział ról na agenta wykonującego zadanie (**Doer** / Wykonawca) oraz niezależnego agenta weryfikującego jakość, poprawność i zgodność wyniku z regułami (**Judge** / Sędzia).
|
||||
|
||||
## How It Works
|
||||
Uruchomienie jednego agenta, który jednocześnie wykonuje pracę i sam ocenia swój wynik, jest częstym trybem awaryjnym (model ma skłonność do ignorowania własnych błędów). Wzdrzec Doer-Judge Split eliminuje to zjawisko:
|
||||
- **Doer (Wykonawca)**: Skupia się na kreatywnym lub technicznym rozwiązaniu problemu (np. pisanie kodu, generowanie raportu, parsowanie maili).
|
||||
- **Judge (Sędzia)**: Posiada rygorystyczny zestaw kryteriów walidacji (np. testy jednostkowe, schemat YAML, reguły bezpieczeństwa) i bezwzględnie odrzuca wyniki, które nie spełniają norm, wymuszając na wykonawcy poprawki.
|
||||
|
||||
## The Verification Spectrum (Spektrum Weryfikacji)
|
||||
Sędziowanie i walidacja mogą odbywać się na różnych poziomach rygoru:
|
||||
1. *Walidacja deterministyczna*: Kompilatory, parsery JSON, lintery (np. nasz `lint_knowledge.ps1`). Szybkie i bezkosztowe.
|
||||
2. *Weryfikacja LLM (Model-as-a-Judge)*: Użycie mniejszego, wyspecjalizowanego modelu do oceny semantycznej poprawności i spójności.
|
||||
3. *Human-in-the-Loop (Nadzór człowieka)*: Ostateczna brama weryfikacji przed krytycznym zatwierdzeniem zmian w systemie.
|
||||
|
||||
## Why It Matters
|
||||
Separacja ta drastycznie podnosi niezawodność systemów agentowych w środowiskach produkcyjnych (np. w systemach finansowych, analizie oszustw, administracji bazami danych), eliminując przypadkowe halucynacje i błędy formatowania.
|
||||
|
||||
## Sources
|
||||
- [[summaries/5-mental-models-for-ai-agents]]
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Graduated Autonomy (Stopniowana Autonomia)"
|
||||
type: "concept"
|
||||
tags: [agent-ai, human-in-the-loop, automation, trust-building]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/5-mental-models-for-ai-agents]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Graduated Autonomy (Stopniowana Autonomia)
|
||||
|
||||
## Definition
|
||||
Podejście do wdrażania systemów autonomicznych (agentów AI) polegające na stopniowym zwiększaniu ich niezależności operacyjnej w miarę budowania i weryfikowania zaufania do ich decyzji przez człowieka.
|
||||
|
||||
## The Autonomy Gradient
|
||||
Zamiast zero-jedynkowego wyboru między całkowicie manualną pracą a pełną, niekontrolowaną automatyzacją, Graduated Autonomy wprowadza płynne spektrum:
|
||||
1. **Human-in-the-Loop (HITL)**: Agent przygotowuje propozycje i plany działań, ale *każda* operacja fizycznie modyfikująca system (zapis na dysk, wysłanie przelewu) wymaga wyraźnej autoryzacji i zatwierdzenia przez człowieka.
|
||||
2. **Human-on-the-Loop**: Agent działa autonomicznie i bezpośrednio wykonuje zadania, ale człowiek monitoruje jego pracę w czasie rzeczywistym i ma możliwość natychmiastowego cofnięcia operacji (np. za pomocą bramki czasowej - delay przed zatwierdzeniem).
|
||||
3. **Pełna autonomia (Human-out-of-the-loop)**: Agent działa całkowicie samodzielnie i podejmuje suwerenne decyzje. Człowiek wkracza wyłącznie w przypadku wystąpienia błędów krytycznych lub anomalii zgłoszonych przez agenta kontrolnego (Sędziego).
|
||||
|
||||
## Why It Matters
|
||||
Stopniowana autonomia pozwala na bezpieczne wdrażanie sztucznej inteligencji do krytycznych obszarów biznesowych (takich jak analiza oszustw, monitoring sieci czy administracja bazami danych). Pozwala wyłapać anomalie projektowe w fazie HITL przed oddaniem agentowi pełnej kontroli nad systemem.
|
||||
|
||||
## Sources
|
||||
- [[summaries/5-mental-models-for-ai-agents]]
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Incremental Context Loading (Dynamiczne Ładowanie Kontekstu)"
|
||||
type: "concept"
|
||||
tags: [prompt-engineering, system-design, agent-ai, optimization]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/best-12-claude-skills-setup]]", "[[summaries/5-mental-models-for-ai-agents]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Incremental Context Loading (Dynamiczne Ładowanie Kontekstu)
|
||||
|
||||
## Definition
|
||||
Strategia optymalizacji systemów agentowych, polegająca na dynamicznym, wybiórczym wprowadzaniu szczegółowych instrukcji, plików referencyjnych lub baz danych do okna kontekstowego (RAM) modelu LLM wyłącznie w momencie, gdy są one niezbędne do realizacji bieżącego zadania.
|
||||
|
||||
## Why It Matters
|
||||
Wielkie okna kontekstowe (sięgające milionów tokenów) kuszą inżynierów do "wrzucania wszystkiego naraz" (wszystkich instrukcji, dokumentacji technicznych i historii sesji). Prowadzi to do poważnych problemów:
|
||||
- **Wzrost kosztów**: Wykładniczy wzrost zużycia tokenów przy każdej kolejnej wiadomości.
|
||||
- **Spowolnienie działania (Latency)**: Dłuższy czas przetwarzania i generowania odpowiedzi.
|
||||
- **Zaszybianie uwagi (Attention Loss)**: Model "gubi się" w gigantycznym natłoku instrukcji i ignoruje kluczowe reguły (błędy wykonawcze).
|
||||
|
||||
## How It Is Solved
|
||||
Poprzez wdrożenie ustrukturyzowanych klastrów wiedzy i umiejętności (takich jak [[concepts/claude-skills]]). System ocenia nagłówek zapytania, wybiera wąską specjalizację i podczytuje tylko te instrukcje, które są skojarzone z aktywnym pod-zadaniem. Gwarantuje to maksymalną szybkość działania i najwyższą precyzję wykonywanej pracy.
|
||||
|
||||
## Sources
|
||||
- [[summaries/best-12-claude-skills-setup]]
|
||||
- [[summaries/5-mental-models-for-ai-agents]]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "Model as CPU, Harness as OS (Model jako CPU, Rusztowanie jako OS)"
|
||||
type: "concept"
|
||||
tags: [agent-ai, system-design, scaffolding, software-architecture]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/5-mental-models-for-ai-agents]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Model as CPU, Harness as OS (Model jako CPU, Rusztowanie jako OS)
|
||||
|
||||
## Definition
|
||||
Mentalny wzorzec architektoniczny w inżynierii systemów agentowych, w którym sam model językowy (LLM) jest traktowany jak surowa jednostka obliczeniowa (CPU), natomiast rusztowanie systemowe (harness / scaffolding) pełni rolę systemu operacyjnego (OS).
|
||||
|
||||
## How It Works
|
||||
Model językowy (np. Gemini lub Claude) sam z siebie jest bezstanowy i po prostu zgaduje kolejne wyrazy na podstawie dostarczonego kontekstu. Aby stworzyć stabilnego, bezpiecznego i deterministycznego agenta produkcyjnego, potrzebne jest rusztowanie (harness), które działa jak OS:
|
||||
- **Zarządzanie wejściem/wyjściem**: Parsowanie zapytań, walidacja poprawności formatu (np. schematów JSON).
|
||||
- **Zarządzanie narzędziami**: Udostępnianie modelowi tylko niezbędnych, precyzyjnie opisanych API i funkcji (ograniczenie entropii decyzyjnej).
|
||||
- **Obsługa stanu (State & Checkpointing)**: Możliwość zapisywania stanu działania agenta, wstrzymywania i wznawiania (checkpoint/resume).
|
||||
- **Śledzenie wykonania (Tracing)**: Trwałe rejestrowanie każdego kroku wnioskowania i użycia narzędzi do celów debugowania i audytu (run-level tracing).
|
||||
- **Zasady bezpieczeństwa (Guardrails)**: Nienaruszalne reguły i filtry blokujące niebezpieczne komendy i wyciek poufnych danych.
|
||||
|
||||
## Why It Matters
|
||||
Różne rusztowania zbudowane wokół tego samego modelu językowego dają gigantyczne różnice w jakości i poprawności wykonywanych zadań. Zamiast ciągłej wymiany modelu na większy, inżynierowie powinni inwestować w optymalizację i utwardzanie "systemu operacyjnego" agenta (kontrakty agentów, obsługa błędów, walidacja).
|
||||
|
||||
## Sources
|
||||
- [[summaries/5-mental-models-for-ai-agents]]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "PKM Automation (Automatyzacja Zarządzania Wiedzą)"
|
||||
type: "concept"
|
||||
tags: [pkm, produktywność, automatyzacja, agent-ai]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/15-obsidian-workflows-and-plugins]]", "[[summaries/karpathy-llm-knowledge-superpower-researchers]]", "[[summaries/what-happens-giving-keys-to-llm-obsidian]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# PKM Automation (Automatyzacja Zarządzania Wiedzą)
|
||||
|
||||
## Definition
|
||||
Praktyka wykorzystywania agentów AI do automatyzacji żmudnej i powtarzalnej pracy administracyjnej związanej z prowadzeniem Osobistej Bazy Wiedzy (PKM - Personal Knowledge Management), takiej jak linkowanie, kategoryzacja, utrzymywanie indeksów i czyszczenie bazy.
|
||||
|
||||
## The Core Problem of PKM
|
||||
Ludzie masowo porzucają systemy "drugiego mózgu" (np. Obsidian, Notion, Roam Research) po kilku tygodniach lub miesiącach. Wynika to z faktu, że **tarcie utrzymaniowe (maintenance overhead)** rośnie szybciej niż realna wartość z posiadania bazy. Ręczne pisanie podsumowań, tworzenie indeksów i aktualizowanie połączeń zwrotnych (backlinks) staje się nudnym obowiązkiem.
|
||||
|
||||
## How AI Resolves It
|
||||
W modelu PKM Automation człowiek skupia się wyłącznie na curatingu (wyborze wartościowych źródeł), czytaniu skomponowanych syntez i formułowaniu pytań badawczych. Agent AI przejmuje całą brudną robotę:
|
||||
- **Automatyczny Ingest**: Przetwarzanie surowych plików, wstrzykiwanie nagłówków YAML, generowanie podsumowań i automatyczne linkowanie pojęć.
|
||||
- **Konserwacja (Linting)**: Regularne wyszukiwanie osieroconych notatek, martwych linków i przestarzałych informacji.
|
||||
- **Aktywny Dialog**: Przekształcenie bazy z pasywnego archiwum plików w aktywnego rozmówcę, który przeczytał wszystko co użytkownik i potrafi wskazać luki metodologiczne i ukryte sprzeczności w wiedzy.
|
||||
|
||||
## Sources
|
||||
- [[summaries/15-obsidian-workflows-and-plugins]]
|
||||
- [[summaries/karpathy-llm-knowledge-superpower-researchers]]
|
||||
- [[summaries/what-happens-giving-keys-to-llm-obsidian]]
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Search-Assisted Writing (Pisanie ze Wsparciem Wyszukiwania)"
|
||||
type: "concept"
|
||||
tags: [pkm, collaboration, writing-workflows, AI]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/what-happens-giving-keys-to-llm-obsidian]]", "[[summaries/karpathy-llm-knowledge-superpower-researchers]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Search-Assisted Writing (Pisanie ze Wsparciem Wyszukiwania)
|
||||
|
||||
## Definition
|
||||
Nowy paradygmat współpracy człowieka z AI w systemach zarządzania wiedzą osobistą, w którym model językowy nie jest tylko pasywną wyszukiwarką odpowiadającą na pytania, ale aktywnym redaktorem współtworzącym i organizującym treść w tle.
|
||||
|
||||
## Shifting Patterns
|
||||
Koncepcja ta redefiniuje dotychczasowy podział ról przy robieniu notatek:
|
||||
- **Tradycyjne podejście (Chat with your vault)**: Notatki są bazą tylko do odczytu. LLM pełni rolę "bibliotekarza" wyciągającego fragmenty (RAG). Wynik sesji jest ulotny.
|
||||
- **Nowy paradygmat (Search-assisted writing)**: Notatki są żywą, edytowalną strukturą. LLM pełni rolę "redaktora naczelnego" pracującego na systemie plików. Samodzielnie pisze artykuły o koncepcjach, wiąże autorów z tematami, sugeruje kierunki badań i wskazuje luki.
|
||||
|
||||
## Why It Matters
|
||||
Pozwala człowiekowi przestać marnować czas na manualną kategoryzację, linkowanie i przepisywanie podsumowań. Przekształca bazę notatek z biernego archiwum myśli w aktywnego partnera intelektualnego, który stymuluje myślenie i przyspiesza syntezę skomplikowanych problemów.
|
||||
|
||||
## Sources
|
||||
- [[summaries/what-happens-giving-keys-to-llm-obsidian]]
|
||||
- [[summaries/karpathy-llm-knowledge-superpower-researchers]]
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "Three-Tier Memory (Trójwarstwowy Model Pamięci)"
|
||||
type: "concept"
|
||||
tags: [agent-ai, memory-systems, system-design]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/5-mental-models-for-ai-agents]]", "[[summaries/building-personal-ai-assistant-sqlite-gtd]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Three-Tier Memory (Trójwarstwowy Model Pamięci)
|
||||
|
||||
## Definition
|
||||
Wzorzec architektoniczny dzielący pamięć agenta AI na trzy odrębne, fizycznie odseparowane warstwy poznawcze, co zapobiega przepełnieniu okna kontekstowego i gwarantuje stabilność operacyjną w długich horyzontach czasowych.
|
||||
|
||||
## The Three Cognitive Tiers
|
||||
Wytrawni inżynierowie unikają wrzucania wszystkich informacji do jednego "worka" (np. prostej bazy wektorowej). Zamiast tego wdrażają trzy poziomy pamięci:
|
||||
1. **Tier 1: Pamięć Krótkoterminowa / Robocza (Short-term / Working memory)**:
|
||||
- *Rola*: Odpowiednik pamięci RAM. Obsługuje aktualną sesję czatu, przechowuje lokalne zmienne, aktywne pod-zadania i przejściowy stan operacyjny.
|
||||
- *Realizacja*: Okno kontekstowe bieżącej rozmowy, pliki wejściowe i zmienne środowiskowe.
|
||||
2. **Tier 2: Pamięć Epizodyczna / Operacyjna (Episodic / Operational memory)**:
|
||||
- *Rola*: Chronologiczna księga zdarzeń. Zapisuje historię wykonanych operacji, sukcesy i błędy z przeszłości. Pozwala agentowi na analizę wsteczną (retrospekcja) i odtwarzanie ścieżek decyzji (tracing).
|
||||
- *Realizacja*: Append-only dziennik zmian (np. plik `log.md` w bazie wiedzy).
|
||||
3. **Tier 3: Pamięć Długoterminowa / Semantyczna (Long-term / Semantic memory)**:
|
||||
- *Rola*: Odpowiednik dysku twardego / SSD. Przechowuje niezmienne reguły zachowania, preferencje użytkownika, przewodniki stylu, schematy danych oraz zakumulowaną, skompilowaną wiedzę.
|
||||
- *Realizacja*: Kontrakty agentów (np. `CLAUDE.md`, `GEMINI.md`), trwałe ustrukturyzowane notatki o preferencjach (`memory.md`) oraz cała baza pojęć i podmiotów (`knowledge/`).
|
||||
|
||||
## Why It Matters
|
||||
Taki podział pozwala agentowi AI działać w sposób wysoce zorganizowany i precyzyjny. Chroni model przed gubieniem wątków podczas długich sesji i pozwala na precyzyjną, długofalową akumulację wiedzy (compounding knowledge).
|
||||
|
||||
## Sources
|
||||
- [[summaries/5-mental-models-for-ai-agents]]
|
||||
- [[summaries/building-personal-ai-assistant-sqlite-gtd]]
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Vault as a Database (Skarbiec jako Baza Danych)"
|
||||
type: "concept"
|
||||
tags: [obsidian, system-design, dataview, graph-theory]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/15-obsidian-workflows-and-plugins]]", "[[summaries/obsidian-vault-as-knowledge-graph]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Vault as a Database (Skarbiec jako Baza Danych)
|
||||
|
||||
## Definition
|
||||
Podejście do organizacji osobistego skarbca notatek Markdown, w którym płaskie pliki tekstowe są traktowane i strukturyzowane jak rekordy w relacyjnej bazie danych, co umożliwia precyzyjne odpytywanie i manipulowanie informacjami przez algorytmy i agenty AI.
|
||||
|
||||
## How It Works
|
||||
Tradycyjny skarbiec to zbiór nieustrukturyzowanych, opisowych notatek. Przekształcenie go w bazę danych opiera się na trzech elementach:
|
||||
1. **Ścisły Schemat (YAML Frontmatter)**: Każda notatka posiada ujednolicony nagłówek metadanych określający jej typ (summary, concept, entity), tagi, datę utworzenia oraz powiązane źródła. Działa to jak definicja kolumn w tabeli SQL.
|
||||
2. **Kompilator Skarbca ([[entities/dataview]])**: Narzędzie indeksujące metadane i udostępniające ustrukturyzowane tabele i zmienne, ułatwiające odpytywanie bazy.
|
||||
3. **Graf Połączeń (Edges & Nodes)**: Linki wewnętrzne (WikiLinks) tworzą krawędzie grafu relacyjnego, umożliwiając wykonywanie algorytmów grafowych (np. ranking centralności, detekcja klastrów i mostów).
|
||||
|
||||
## Why It Matters
|
||||
Agenty AI (np. [[entities/claude-code]]) działają drastycznie skuteczniej i zużywają mniej tokenów, gdy poruszają się po ustrukturyzowanej bazie danych z wyraźnymi schematami i powiązaniami, niż gdy próbują odczytywać i interpretować całkowicie chaotyczny, nieustrukturyzowany szum tekstowy.
|
||||
|
||||
## Sources
|
||||
- [[summaries/15-obsidian-workflows-and-plugins]]
|
||||
- [[summaries/obsidian-vault-as-knowledge-graph]]
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Dataview"
|
||||
type: "entity"
|
||||
tags: [wtyczka, obsidian, baza-danych, technologia]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/15-obsidian-workflows-and-plugins]]", "[[summaries/obsidian-vault-as-knowledge-graph]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Dataview
|
||||
|
||||
## Overview
|
||||
Niezwykle popularna wtyczka społecznościowa dla programu [[entities/obsidian]], która indeksuje metadane (YAML frontmatter oraz inline fields) ze wszystkich notatek w skarbcu, umożliwiając wykonywanie dynamicznych zapytań (DQL - Dataview Query Language) i renderowanie wyników w postaci tabel, list i widoków zadań.
|
||||
|
||||
## Role in AI PKM
|
||||
Wtyczka Dataview odgrywa kluczową rolę w ustrukturyzowanych bazach wiedzy zarzadzanych przez AI:
|
||||
- **Twarda struktura**: Zamienia płaskie foldery z plikami Markdown w bazę danych o wyraźnym schemacie (odpowiednik tabel SQL).
|
||||
- **Redukcja tokenów**: Gdy agent AI (np. [[entities/claude-code]]) wchodzi do skarbca, odczytuje zestawienia Dataview (tablice danych), co pozwala mu natychmiast zrozumieć powiązania i właściwości setek plików, bez konieczności kosztownego czytania każdego dokumentu z osobna.
|
||||
|
||||
## Related Entities
|
||||
- [[entities/obsidian]] — Środowisko uruchomieniowe.
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "FastMCP"
|
||||
type: "entity"
|
||||
tags: [framework, technologia, open-source, mcp]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/best-12-claude-skills-setup]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# FastMCP
|
||||
|
||||
## Overview
|
||||
Wysoce zoptymalizowany, nowoczesny framework open-source przeznaczony do błyskawicznego projektowania, testowania i wdrażania serwerów MCP ([[concepts/mcp-servers]]) w językach Python oraz TypeScript.
|
||||
|
||||
## Capabilities
|
||||
- **Dekoratory**: Pozwala na przekształcenie standardowych funkcji językowych w natywne narzędzia (tools) i zasoby dla modeli LLM za pomocą prostych adnotacji (np. `@mcp.tool()`).
|
||||
- **Szybkość wdrożenia**: Drastycznie skraca czas i upraszcza architekturę budowy serwerów w porównaniu do ręcznej implementacji protokołu MCP.
|
||||
|
||||
## Related Concepts
|
||||
- [[concepts/mcp-servers]] — Standardy komunikacji i dostarczania ustrukturyzowanych narzędzi dla agentów.
|
||||
- [[concepts/claude-skills]] — Możliwość rozbudowy agentów.
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Mistral NeMo 12B"
|
||||
type: "entity"
|
||||
tags: [model-llm, technologia, open-source, local-first]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/what-happens-giving-keys-to-llm-obsidian]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Mistral NeMo 12B
|
||||
|
||||
## Overview
|
||||
Lekki, wysoce zoptymalizowany, otwartoźródłowy model językowy (LLM) o rozmiarze 12 miliardów parametrów, stworzony we współpracy Mistral AI i NVIDIA. Działa z powodzeniem lokalnie na urządzeniach konsumenckich posiadających standardową ilość pamięci VRAM (np. MacBooki z Apple Silicon lub karty graficzne Nvidia RTX).
|
||||
|
||||
## Role in Local-First PKM
|
||||
Mistral NeMo 12B jest uznawany za jeden z optymalnych wyborów dla w pełni prywatnych, lokalnych systemów zarządzania wiedzą (Karpathy Pattern):
|
||||
- **Wydajność**: Oferuje doskonałą jakość syntezy merytorycznej, rzetelne podążanie za instrukcjami systemowymi oraz bardzo dobrą obsługę kodu Markdown.
|
||||
- **Bezpieczeństwo**: Całe rozumowanie i parsowanie notatek odbywa się w 100% lokalnie na maszynie użytkownika. Wrażliwe dane (dzienniki, notatki biznesowe) nie są przesyłane na serwery chmurowe.
|
||||
|
||||
## Related Concepts
|
||||
- [[concepts/local-first-ai]] — Model wdrażania bazy opartej na zasobach lokalnych.
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Obsidian Git"
|
||||
type: "entity"
|
||||
tags: [wtyczka, git, obsidian, wersjonowanie]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/15-obsidian-workflows-and-plugins]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Obsidian Git
|
||||
|
||||
## Overview
|
||||
Wtyczka społecznościowa dla programu [[entities/obsidian]], pozwalająca na automatyczne wersjonowanie i synchronizowanie lokalnego skarbca notatek z dowolnym zdalnym repozytorium Git (np. GitHub, GitLab).
|
||||
|
||||
## Critical Role in Agent PKM
|
||||
Gdy zezwalamy autonomicznym agentom AI (np. [[entities/claude-code]]) na bezpośrednie zapisywanie i modyfikowanie plików w naszej bazie wiedzy, pojawia się ryzyko uszkodzenia danych (błędy składniowe, nadpisanie istotnych sekcji). Obsidian Git służy jako polisa ubezpieczeniowa:
|
||||
- **Niezmienny stan**: Wykonuje automatyczne zatwierdzenia (commits) i wypchnięcia (push) w tle z określoną częstotliwością (np. co 30 minut).
|
||||
- **Bezpieczne cofanie zmian**: W razie awarii lub błędnej edycji agenta, użytkownik może natychmiast przywrócić poprawny stan bazy z historii rewizji.
|
||||
- **Transparentność**: Umożliwia precyzyjny przegląd różnic w tekście (diffs) w celu weryfikacji zmian dokonanych przez model AI.
|
||||
|
||||
## Related Entities
|
||||
- [[entities/obsidian]] — Przetwarzany skarbiec.
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "Obsidian Skills"
|
||||
type: "entity"
|
||||
tags: [narzędzie, open-source, prompt-engineering, obsidian]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["[[summaries/what-happens-giving-keys-to-llm-obsidian]]", "[[summaries/15-obsidian-workflows-and-plugins]]"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Obsidian Skills
|
||||
|
||||
## Overview
|
||||
Oficjalny zestaw otwartoźródłowych (licencja MIT) umiejętności agentowych stworzony na początku 2026 roku przez Stepha Ango (CEO Obsidiana) w celu ustandaryzowania i zabezpieczenia interakcji zewnętrznych modeli LLM z lokalnymi skarbcami notatek Obsidian.
|
||||
|
||||
## Capabilities & Modules
|
||||
Paczka `kepano/obsidian-skills` instalowana jest w katalogu umiejętności agenta i zawiera pięć wyspecjalizowanych modułów:
|
||||
1. `obsidian-markdown` — uczy model specyficznego dialektu Markdown (WikiLinki, bloki calloutów, osadzenia), zapobiegając uszkadzaniu składni.
|
||||
2. `obsidian-bases` — zarządza strukturami ustrukturyzowanych danych i typami właściwości frontmatter.
|
||||
3. `json-canvas` — pozwala agentom na bezpieczne generowanie, modyfikowanie i odczytywanie wizualnych map myśli (plików Obsidian Canvas bazujących na formacie JSON).
|
||||
4. `obsidian-cli` — udostępnia pełne API do manipulowania skarbcem z poziomu wiersza poleceń (CLI).
|
||||
5. `defuddle` — autonomiczny scraper i czyściciel stron internetowych, usuwający reklamy, skrypty i elementy nawigacyjne z kodu HTML, co oszczędza od 40% do 80% tokenów przy importowaniu artykułów z sieci.
|
||||
|
||||
## Why It Is a Game-Changer
|
||||
To pierwszy przypadek, w którym twórca platformy osobiście napisał i wydał oficjalne specyfikacje integracji agentowej, zapobiegając "zatruwaniu" i psuciu prywatnych baz wiedzy przez improwizujących i działających bez ścisłych reguł agentów AI.
|
||||
|
||||
## Related Entities
|
||||
- [[entities/obsidian]] — Wspierany system notatek.
|
||||
- [[entities/claude-code]] — Terminalowy agent wykorzystujący te umiejętności.
|
||||
@@ -1,6 +1,6 @@
|
||||
# 12 Ulubionych Problemów Feynmana
|
||||
|
||||
Poniższa lista zawiera kluczowe pytania i obszary zainteresowań, które są "testowane" przy każdym nowym źródle wiedzy. Cel: Znalezienie nowych perspektyw, połączeń lub cząstkowych rozwiązań dla tych długoterminowych wyzwań.
|
||||
Poniższa lista zawiera kluczowe pytania i obszary zainteresowań, które są "testowane" przy każdym nou źródle wiedzy. Cel: Znalezienie nowych perspektyw, połączeń lub cząstkowych rozwiązań dla tych długoterminowych wyzwań.
|
||||
|
||||
## 1. Zarządzanie sobą w czasie
|
||||
- **Notatki i połączenia**:
|
||||
@@ -12,6 +12,8 @@ Poniższa lista zawiera kluczowe pytania i obszary zainteresowań, które są "t
|
||||
- [[summaries/karpathy-llm-knowledge-superpower-researchers]]: LLM jako "księgowy" automatyzujący nudne zadania i konserwację bazy wiedzy, zapobiegając jej porzuceniu przez ludzi.
|
||||
- [[summaries/building-personal-ai-assistant-sqlite-gtd]]: System MarcOS integruje GTD z SQLite i Claude Code, automatyzując cotygodniowy przegląd zadań.
|
||||
- [[summaries/building-llm-research-knowledge-philosophy]]: Etapowe podejście do wdrażania bazy i odrzucenie "fantazji migracyjnej" chroni przed wypaleniem narzędziowym.
|
||||
- [[summaries/15-obsidian-workflows-and-plugins]]: Autonomiczne potoki wykonawcze (autopsje, audyty stanu, inicjalizacja) usuwają konieczność ręcznej administracji bazą.
|
||||
- [[summaries/best-12-claude-skills-setup]]: Ustrukturyzowane, modularne umiejętności (np. `schedule`, `consolidate-memory`) zwiększają precyzję pracy agentów przy minimalnym zużyciu tokenów.
|
||||
|
||||
## 2. Zarządzanie bazami danych
|
||||
- **Notatki i połączenia**:
|
||||
@@ -29,6 +31,8 @@ Poniższa lista zawiera kluczowe pytania i obszary zainteresowań, które są "t
|
||||
- [[summaries/loom-thinking-tool]]: Wykorzystanie AI do [[concepts/metacognition-as-a-service]] i [[concepts/idea-collision]].
|
||||
- [[summaries/building-llm-research-knowledge-philosophy]]: Wprowadzenie [[concepts/epistemic-markers]] (`[W]`, `[P]`, `[?]`) pozwala rozróżnić obiektywne syntezy modeli od własnych przemyśleń badacza.
|
||||
- [[summaries/obsidian-vault-as-knowledge-graph]]: Zastosowanie serwerów [[concepts/mcp-servers]] (np. [[entities/mcpvault]]) pozwala LLM na strukturalną i grafową analizę pojęć w bazie.
|
||||
- [[summaries/what-happens-giving-keys-to-llm-obsidian]]: Zestawy cech `obsidian-skills` od Steph Ango uczą modele poprawnej składni dialektu Obsidian, eliminując błędy formatowania.
|
||||
- [[summaries/5-mental-models-for-ai-agents]]: Optymalizacja stosu kontekstowego (Context Stack) oraz separacja wykonawcy od sędziego (Doer-Judge Split) zapewniają stabilność i poprawność generatywnych operacji biznesowych.
|
||||
|
||||
## 4. Automatyzacja i Agenci AI
|
||||
- **Notatki i połączenia**:
|
||||
@@ -39,6 +43,8 @@ Poniższa lista zawiera kluczowe pytania i obszary zainteresowań, które są "t
|
||||
- [[summaries/how-to-deploy-autoresearch]]: [[concepts/autoresearch]] – najwyższy stopień autonomii agenta AI w procesie badawczym.
|
||||
- [[summaries/building-personal-ai-assistant-sqlite-gtd]]: Claude Code jako aktywny administrator systemów użytkownika (GTD/faktury), działający pod nienaruszalnym kontraktem `CLAUDE.md`.
|
||||
- [[summaries/obsidian-vault-as-knowledge-graph]]: Wykorzystanie Claude Code bezpośrednio na bazie Markdown jako "bazy kodu", z użyciem specjalnych "umiejętności" Obsidiana.
|
||||
- [[summaries/what-happens-giving-keys-to-llm-obsidian]]: Zwrot ról: LLM nie jest już tylko pasywną wyszukiwarką (RAG), lecz autonomicznym redaktorem naczelnym bazy wiedzy (Search-assisted writing).
|
||||
- [[summaries/5-mental-models-for-ai-agents]]: Pięć konsensusowych modeli dla agentów AI (rusztowanie jako OS, trójwarstwowa struktura pamięci, stopniowana autonomia) definiuje profesjonalne ramy systemów autonomicznych.
|
||||
|
||||
---
|
||||
*Miejsce na kolejne problemy (5-12)...*
|
||||
|
||||
@@ -26,3 +26,14 @@ Słownik terminów i modeli mentalnych zgromadzonych w knowledge.
|
||||
- [[concepts/knowledge-scaling]]
|
||||
- [[concepts/gtd-ai]]
|
||||
- [[concepts/mcp-servers]]
|
||||
- [[concepts/pkm-automation]]
|
||||
- [[concepts/vault-as-database]]
|
||||
- [[concepts/compounding-feedback-loops]]
|
||||
- [[concepts/search-assisted-writing]]
|
||||
- [[concepts/agent-formatting-dialects]]
|
||||
- [[concepts/claude-skills]]
|
||||
- [[concepts/incremental-context-loading]]
|
||||
- [[concepts/context-stack-management]]
|
||||
- [[concepts/doer-judge-split]]
|
||||
- [[concepts/three-tier-memory]]
|
||||
- [[concepts/graduated-autonomy]]
|
||||
|
||||
@@ -11,3 +11,8 @@ Katalog narzędzi, technologii i organizacji.
|
||||
- [[entities/sql-js]]
|
||||
- [[entities/mcpvault]]
|
||||
- [[entities/constella]]
|
||||
- [[entities/dataview]]
|
||||
- [[entities/obsidian-git]]
|
||||
- [[entities/obsidian-skills]]
|
||||
- [[entities/mistral-nemo]]
|
||||
- [[entities/fastmcp]]
|
||||
|
||||
@@ -16,3 +16,7 @@ Pełna lista streszczeń materiałów źródłowych.
|
||||
- [[summaries/building-llm-research-knowledge-philosophy]]
|
||||
- [[summaries/building-personal-ai-assistant-sqlite-gtd]]
|
||||
- [[summaries/obsidian-vault-as-knowledge-graph]]
|
||||
- [[summaries/15-obsidian-workflows-and-plugins]]
|
||||
- [[summaries/what-happens-giving-keys-to-llm-obsidian]]
|
||||
- [[summaries/best-12-claude-skills-setup]]
|
||||
- [[summaries/5-mental-models-for-ai-agents]]
|
||||
|
||||
@@ -2,6 +2,14 @@
|
||||
|
||||
Chronologiczny zapis operacji na knowledge.
|
||||
|
||||
## [2026-06-09] Ingest | PKM Automation & AI Agent Harness Architectures
|
||||
- Przetworzono `15 workflowów i wtyczek Obsidian, których większość ludzi nie zna.md`: dodano podsumowanie `[[summaries/15-obsidian-workflows-and-plugins]]`, koncepcje `[[concepts/pkm-automation]]`, `[[concepts/vault-as-database]]`, `[[concepts/compounding-feedback-loops]]` oraz podmioty `[[entities/dataview]]` i `[[entities/obsidian-git]]`.
|
||||
- Przetworzono `Co się dzieje, gdy dasz LLM-owi klucze do swojego skarbca Obsidian.md`: dodano podsumowanie `[[summaries/what-happens-giving-keys-to-llm-obsidian]]`, koncepcje `[[concepts/search-assisted-writing]]`, `[[concepts/agent-formatting-dialects]]` oraz podmioty `[[entities/obsidian-skills]]` i `[[entities/mistral-nemo]]`.
|
||||
- Przetworzono `The Best 12 Claude Skills Setup — A Complete 2026 Guide to Configuring Claude Like a Pro.md`: dodano podsumowanie `[[summaries/best-12-claude-skills-setup]]`, koncepcje `[[concepts/claude-skills]]`, `[[concepts/incremental-context-loading]]` oraz podmioty `[[entities/fastmcp]]`.
|
||||
- Przetworzono `The 5 Core Mental Models for AI Agents: Harness & Memory (Deep Dive + Action Plan) - BPMS Team.md`: dodano podsumowanie `[[summaries/5-mental-models-for-ai-agents]]`, koncepcje `[[concepts/model-as-cpu-harness-as-os]]`, `[[concepts/context-stack-management]]`, `[[concepts/doer-judge-split]]`, `[[concepts/three-tier-memory]]` oraz `[[concepts/graduated-autonomy]]`.
|
||||
- Zaktualizowano powiązania z Feynman Problems w `[[feynman_problems]]` (Problemy #1, #3, #4).
|
||||
- Zaktualizowano indeksy podsumowań, koncepcji i podmiotów.
|
||||
|
||||
## [2026-06-09] Ingest | LLM-Knowledge & Personal AI Productivity
|
||||
- Przetworzono `Karpathy LLM knowledge to supermoc dla badaczy. Oto jak go używam..md`: dodano podsumowanie `[[summaries/karpathy-llm-knowledge-superpower-researchers]]`.
|
||||
- Przetworzono `Budowanie knowledge badawczej LLM_ Jak przekształciłem 3000 stron filozofii w żywy system wiedzy.md`: dodano podsumowanie `[[summaries/building-llm-research-knowledge-philosophy]]`, koncepcje `[[concepts/epistemic-markers]]`, `[[concepts/multi-agent-orchestration]]` oraz `[[concepts/knowledge-scaling]]`, i podmioty `[[entities/constella]]`.
|
||||
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "15 workflowów i wtyczek Obsidian, których większość ludzi nie zna"
|
||||
type: "summary"
|
||||
tags: [obsidian, pkm, automatyzacja, workflow, mcpvault, git]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["raw/inbox/15 workflowów i wtyczek Obsidian, których większość ludzi nie zna.md"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# 15 workflowów i wtyczek Obsidian, których większość ludzi nie zna
|
||||
|
||||
Artykuł autorstwa Shashwata przedstawia zaawansowany zestaw 15 wtyczek i automatycznych przepływów pracy (workflows), które przekształcają statyczny skarbiec Obsidian w aktywny, samodzielnie zapytujący i kumulujący wiedzę ekosystem cyfrowy (tzw. "Second Brain" oparty o pętle LLM).
|
||||
|
||||
## Key Points
|
||||
|
||||
### Podstawowa Infrastruktura (Wtyczki):
|
||||
- **Smart Connections (RAG)**: Wtyczka wprowadzająca lokalny silnik wyszukiwania semantycznego (RAG) do przeszukiwania skarbca na bazie wektorowej, zamiast prostego dopasowania słów kluczowych.
|
||||
- **Templater (Egzekutor szablonów)**: Służy do automatycznego wymuszania ustrukturyzowanych metadanych YAML frontmatter (daty, tagi, klucze), co zapobiega halucynacjom modeli na surowym szumie informacyjnym.
|
||||
- **Dataview (Kompilator skarbca)**: Przekształca foldery i notatki w tabele bazodanowe (podobne do SQL). Dzięki temu model AI może odpytywać konkretne właściwości i zmienne zamiast interpretować surowy tekst.
|
||||
- **Obsidian Git**: Zapewnia wersjonowanie bazy z automatycznym commitem co 30 minut. Jest to nienaruszalna polisa ubezpieczeniowa przed uszkodzeniem plików podczas automatycznych edycji wsadowych przez agenta.
|
||||
- **Obsidian CLI (Interfejs terminalowy)**: Umożliwia terminalowym agentom (np. [[entities/claude-code]]) bezproblemowe przeszukiwanie i edycję bazy bezpośrednio z wiersza poleceń.
|
||||
|
||||
### Autonomiczne Potoki Wykonawcze (Workflows):
|
||||
- **Protokół Inicjalizacji**: Skrypt uruchamiany rano, który nakazuje modelowi AI pobranie logów z ostatnich 72 godzin i przygotowanie sterylnej listy priorytetów i zadań na dany dzień.
|
||||
- **Automatyczny Ingest (Lejek)**: Umieszczenie dokumentu w folderze stagingu wyzwala proces, w którym model analizuje treść, wstrzykuje tagi metadanych i automatycznie tworzy linki do istniejących pojęć w bazie.
|
||||
- **Algorytmiczna Autopsja**: Piątkowy cron-job zbierający zmodyfikowane w ciągu tygodnia pliki, obliczający deltę postępu i generujący bezwzględną, 300-słowną krytyczną ocenę wydajności użytkownika.
|
||||
- **Audyt Stanu (Structural Health Audit)**: Raz w miesiącu model AI przeszukuje skarbiec pod kątem osieroconych notatek, martwych linków i przestarzałych tagów, zapobiegając "zużyciu" repozytorium (odpowiednik naszego lintera).
|
||||
- **Dziennik Decyzji (Binary Decision Log)**: Zapisywanie założeń decyzji oraz ich ostatecznych rezultatów, co pozwala modelowi na analizę naszych historycznych błędów poznawczych i wzorców porażek.
|
||||
|
||||
### Orkiestracja i Architektura:
|
||||
- **Trwały Napęd Kontekstowy**: Wykorzystanie plików `CLAUDE.md` / `GEMINI.md` jako trwałej pamięci RAM, wymuszającej na agencie przestrzeganie naszych historycznych reguł i preferencji przed rozpoczęciem nowej sesji.
|
||||
- **Protokół mcpvault**: Integracja lokalnego serwera MCP ([[entities/mcpvault]]) z wyszukiwaniem BM25, pozwalająca agentom na błyskawiczne przeszukiwanie i odczyt notatek bez otwierania interfejsu Obsidian.
|
||||
- **Kanoniczne Specyfikacje (`obsidian-skills`)**: Używanie oficjalnych bibliotek Steph Ango ([[entities/obsidian-skills]]) do bezpiecznej i precyzyjnej modyfikacji plików Markdown i Canvas.
|
||||
- **obsidian-second-brain**: Monolityczny moduł posiadający 31 komend, pozwalający na pobieranie transkrypcji YouTube, zaciąganie danych na żywo przez API Grok i automatyczne argumentowanie przeciwko tezom użytkownika.
|
||||
- **Kumulująca Pętla Feedbacku**: Oznaczanie syntez wygenerowanych przez AI tagiem `#machine-generated`, co pozwala na celowy i kontrolowany trening bazy na jej własnych, doprecyzowanych syntezach.
|
||||
|
||||
## Relevant Concepts
|
||||
- [[concepts/pkm-automation]] — Wykorzystanie agentów do automatyzacji nudnej księgowości wiedzy.
|
||||
- [[concepts/vault-as-database]] — Traktowanie struktury plików tekstowych jako odpytywalnej relacyjnej bazy danych.
|
||||
- [[concepts/compounding-feedback-loops]] — Systemy uczące się i zagęszczające wiedzę na bazie własnych, zweryfikowanych wyjść.
|
||||
- [[concepts/knowledge-graph-analysis]] — Strukturalne audyty zdrowia grafu notatek.
|
||||
|
||||
## Relevant Entities
|
||||
- [[entities/obsidian]] — Centralne środowisko PKM.
|
||||
- [[entities/mcpvault]] — Serwer MCP do bezserwerowego przeszukiwania bazy.
|
||||
- [[entities/obsidian-skills]] — Kanoniczne instrukcje Steph Ango dla agentów AI.
|
||||
- [[entities/claude-code]] — Agent wykonujący skrypty i operacje na bazie.
|
||||
|
||||
## Source Metadata
|
||||
- **Type**: Artykuł / Przewodnik techniczny
|
||||
- **Author**: Shashwat
|
||||
- **Date**: 2026-06-02
|
||||
- **URL**: https://medium.com/tech-and-ai-guild/15-obsidian-workflows-and-plugins-that-most-people-dont-know-3fa3e6f05ee4
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "The 5 Core Mental Models for AI Agents: Harness & Memory (Deep Dive + Action Plan)"
|
||||
type: "summary"
|
||||
tags: [agent-ai, system-design, mental-models, memory-tiers, autonomy]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["raw/inbox/The 5 Core Mental Models for AI Agents_ Harness & Memory (Deep Dive + Action Plan) - BPMS Team.md"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# The 5 Core Mental Models for AI Agents: Harness & Memory (Deep Dive + Action Plan)
|
||||
|
||||
Artykuł zespołu BPMS definiuje pięć fundamentalnych modeli mentalnych, które pozwalają inżynierom oprogramowania na przeniesienie agentów AI z fazy prostych prezentacji (demos) do stabilnych, produkcyjnych systemów biznesowych. Ramy te zostały zilustrowane na przykładzie budowy agenta do analizy oszustw (fraud analysis) z wykorzystaniem Gemini CLI i BigQuery.
|
||||
|
||||
## Key Points
|
||||
|
||||
### Model Mentalny 1 — Model to procesor (CPU). Rusztowanie (Harness) to system operacyjny (OS).
|
||||
- Sam model językowy (LLM) to tylko surowy silnik wnioskowania (jak procesor Intel/AMD). Poziom jakości i bezpieczeństwa aplikacji zależy całkowicie od **rusztowania (harness/scaffolding)**, które pełni rolę systemu operacyjnego.
|
||||
- "OS" definiuje wejścia/wyjścia, ograniczenia, bezpieczeństwo, cykle weryfikacji, checkpointy, wznawianie pracy (checkpoint/resume) oraz śledzenie kroków (run-level tracing). Zmiana rusztowania ma większy wpływ na wynik niż wymiana samego modelu na większy.
|
||||
- Wąski, rygorystyczny i dobrze oznaczony zestaw narzędzi (tools) jest zawsze lepszy niż przeładowany przybornik ze względu na minimalizację entropii decyzji modelu.
|
||||
|
||||
### Model Mentalny 2 — Kontekst jest Produktem (Context is the Product)
|
||||
- Zarządzanie **Stosem Kontekstu (Context Stack)** to kluczowy element inżynierii systemów agentowych. Na stos składają się: instrukcje systemowe, aktywne instrukcje projektu, historia konwersacji oraz pobrane wycinki z baz danych (RAG).
|
||||
- Istnieje stałe napięcie między chęcią dostarczenia modelowi maksymalnej liczby informacji (co marnuje tokeny i spowalnia czas reakcji) a zbyt wąskim zakresem, który prowadzi do halucynacji i błędów logicznych.
|
||||
|
||||
### Model Mentalny 3 — Oddziel Wykonawcę od Sędziego (Separate the Doer from the Judge)
|
||||
- Dla zachowania rzetelności procesów biznesowych należy bezwzględnie odseparować agenta wykonującego zadanie (**Doer**) od agenta weryfikującego jakość i zgodność z regułami (**Judge**).
|
||||
- Weryfikacja przebiega na spektrum: od automatycznych bram logicznych (kod deterministyczny, walidacja schematu JSON), przez sędziowanie za pomocą innego, mniejszego modelu LLM, aż po ostateczny nadzór człowieka (Human-in-the-Loop).
|
||||
|
||||
### Model Mentalny 4 — Pamięć to Trzy Poziomy Poznawcze, a nie jeden worek
|
||||
Systemy agentowe powinny rozróżniać i fizycznie separować pamięć na trzy warstwy:
|
||||
1. **Tier 1: Pamięć Krótkoterminowa / Robocza (Short-term / Working memory)**: Aktywny kontekst sesji czatu, lokalne zmienne i przejściowy stan operacyjny.
|
||||
2. **Tier 2: Pamięć Epizodyczna / Operacyjna (Episodic / Operational memory)**: Chronologiczny dziennik wykonanych akcji i zdarzeń (historyczny log sesji). Pozwala na odtworzenie ścieżki wnioskowania (run-level tracing).
|
||||
3. **Tier 3: Pamięć Długoterminowa / Semantyczna (Long-term / Semantic memory)**: Trwałe, utwardzone preferencje, reguły zachowania, przewodniki marki i wzorce bazodanowe (odpowiednik ustrukturyzowanych pamięci i plików kontraktów agenta).
|
||||
|
||||
### Model Mentalny 5 — Stopniowana Autonomia (Graduated Autonomy)
|
||||
- Zaufanie do agenta AI buduje się stopniowo poprzez weryfikację. Autonomia powinna być wdrażana etapowo na gradientowej skali:
|
||||
- *HITL (Human-in-the-Loop)*: Każda akcja modyfikująca system wymaga fizycznej zgody i kliknięcia człowieka.
|
||||
- *Human-on-the-Loop*: Agent wykonuje akcje autonomicznie, ale człowiek ma możliwość ich natychmiastowego cofnięcia (bramka czasowa / delay).
|
||||
- *Pełna autonomia*: Agent działa samodzielnie, raportując jedynie anomalie i błędy krytyczne do sędziego lub administratora.
|
||||
|
||||
## Relevant Concepts
|
||||
- [[concepts/model-as-cpu-harness-as-os]] — Architektura oddzielająca silnik wnioskowania od rusztowania operacyjnego.
|
||||
- [[concepts/context-stack-management]] — Strategie dynamicznego i oszczędnego zarządzania oknem kontekstowym.
|
||||
- [[concepts/doer-judge-split]] — Wzorzec projektowy zwiększający niezawodność poprzez separację ról wykonawczych i kontrolnych.
|
||||
- [[concepts/three-tier-memory]] — Trójwarstwowy model podziału pamięci agentów AI.
|
||||
- [[concepts/graduated-autonomy]] — Metody stopniowego zwiększania niezależności systemów autonomicznych.
|
||||
|
||||
## Sources
|
||||
- [[summaries/5-mental-models-for-ai-agents]]
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: "The Best 12 Claude Skills Setup — A Complete 2026 Guide to Configuring Claude Like a Pro"
|
||||
type: "summary"
|
||||
tags: [claude, claude-skills, agent-ai, automatyzacja, mcp, prompt-engineering]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["raw/inbox/The Best 12 Claude Skills Setup — A Complete 2026 Guide to Configuring Claude Like a Pro.md"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# The Best 12 Claude Skills Setup — A Complete 2026 Guide to Configuring Claude Like a Pro
|
||||
|
||||
Artykuł autorstwa Noora Mohamada analizuje zaawansowany mechanizm "Umiejętności" (Skills) w ekosystemie agentów Claude (szczególnie w Claude Code i Cowork). Autor wyjaśnia, jak te moduły radykalnie zwiększają precyzję pracy modeli, podaje instrukcję instalacji oraz rekomenduje zestaw 12 konkretnych umiejętności optymalizujących codzienną pracę.
|
||||
|
||||
## Key Points
|
||||
|
||||
### Czym są Umiejętności (Skills)?
|
||||
- **Definicja**: Umiejętność to wydzielony folder zawierający instrukcje (`SKILL.md`), przykłady szablonów oraz ewentualne skrypty wykonawcze (Python/Node), które model językowy łaguje **wyłącznie wtedy, gdy są one bezpośrednio potrzebne**.
|
||||
- **Zasada Stopniowego Ujawniania (Incremental Context Loading)**: Model nie czyta wszystkich umiejętności naraz, co oszczędza okno kontekstowe (RAM). Odczytuje tylko krótkie nagłówki i opisy, dynamicznie ładując pełne pliki instrukcji w momencie dopasowania zapytania.
|
||||
- **Uniwersalność**: Napisana raz umiejętność działa spójnie na wszystkich powierzchniach Claude: w aplikacji webowej, terminalu Claude Code, API oraz trybie Cowork.
|
||||
|
||||
### Metody Instalacji:
|
||||
1. **Wbudowane (Built-in)**: Włączane jednym kliknięciem w ustawieniach (obsługa formatów `.docx`, `.pptx`, `.xlsx`, `.pdf`).
|
||||
2. **Społecznościowe (Marketplace)**: Pobierane bezpośrednio z oficjalnego repozytorium GitHub Anthropica poprzez komendę `/plugin install`.
|
||||
3. **Własne (Custom)**: Lokalny katalog zawierający plik `SKILL.md` z tagami metadanych w nagłówku, umieszczony w folderze `~/.claude/skills/`.
|
||||
|
||||
### Rekomendowany Stos 12 Umiejętności:
|
||||
- **Kategoria "Generatory Dokumentów"**:
|
||||
- `docx` — generowanie profesjonalnych, ustrukturyzowanych dokumentów Word (spisy treści, śledzenie zmian).
|
||||
- `pptx` — budowanie edytowalnych prezentacji PowerPoint z wykorzystaniem biblioteki `python-pptx`.
|
||||
- `xlsx` — tworzenie arkuszy Excel z formułami i formatowaniem warunkowym.
|
||||
- `pdf` — wyodrębnianie tabel i tekstu, wypełnianie formularzy, łączenie plików i automatyczny OCR.
|
||||
- **Kategoria "Kompilatory Agentów"**:
|
||||
- `skill-creator` — asystent AI przeprowadzający wywiad z użytkownikiem i automatycznie budujący nowe, niestandardowe pliki `SKILL.md`.
|
||||
- `mcp-builder` — automatyczne tworzenie i wdrażanie lokalnych serwerów FastMCP (Python/TypeScript).
|
||||
- **Kategoria "Generatory Treści i Pamięć"**:
|
||||
- `brand-voice` (Custom) — rygorystyczne egzekwowanie unikalnego tonu pisania, listy zakazanych korporacyjnych słów i szablonów zakończeń.
|
||||
- `consolidate-memory` — okresowy przegląd, konsolidacja i czyszczenie bazy wspomnień agenta (merytoryczny linter pamięci).
|
||||
- **Kategoria "Programowanie (Shipping Code)"**:
|
||||
- `mern-ecommerce-expert` — obsługa gotowych wzorców e-commerce dla stosu MERN.
|
||||
- `review` — rzetelny, głęboki przegląd kodu bazujący na plikach diff, szukający realnych logicznych błędów.
|
||||
- `security-review` — audyt bezpieczeństwa gałęzi kodu pod kątem wstrzyknięć kodu i podatności.
|
||||
- **Kategoria "Automatyzacja i Rutyna"**:
|
||||
- `schedule` — harmonogramowanie i automatyczne uruchamianie cyklicznych zadań w tle (np. poniedziałkowy raport).
|
||||
|
||||
### Dobre Praktyki Tworzenia Umiejętności:
|
||||
- **Triage Nurse Description**: Opis w nagłówku YAML musi być napisany z precyzją pielęgniarki na izbie przyjęć. Zamiast "pomaga pisać" należy napisać "używaj, gdy użytkownik chce stworzyć lub edytować plik .docx". To decyduje o trafnym wywołaniu.
|
||||
- **Ograniczenia na początku**: Twarde zakazy, listy słów zakazanych i kluczowe formaty powinny znaleźć się w pierwszych 200 słowach pliku `SKILL.md`, ponieważ model silniej waży instrukcje z początku kontekstu.
|
||||
|
||||
## Relevant Concepts
|
||||
- [[concepts/claude-skills]] — Ramy rozszerzania możliwości modeli Anthropic za pomocą ustrukturyzowanych umiejętności.
|
||||
- [[concepts/incremental-context-loading]] — Strategie oszczędzania okna kontekstowego poprzez dynamiczne ładowanie instrukcji.
|
||||
- [[concepts/agent-contracts]] — `SKILL.md` jako kontrakt wykonawczy dla konkretnego zadania.
|
||||
|
||||
## Relevant Entities
|
||||
- [[entities/claude-code]] — Środowisko CLI obsługujące wtyczki i umiejętności.
|
||||
- [[entities/fastmcp]] — Framework do błyskawicznego budowania serwerów MCP.
|
||||
|
||||
## Source Metadata
|
||||
- **Type**: Poradnik techniczny / Best practices
|
||||
- **Author**: Noor Mohamad
|
||||
- **Date**: 2026-05-13
|
||||
- **URL**: https://blog.stackademic.com/the-best-12-claude-skills-setup-a-complete-2026-guide-to-configuring-claude-like-a-pro-486d2fd906f3
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "Co się dzieje, gdy dasz LLM-owi klucze do swojego skarbca Obsidian"
|
||||
type: "summary"
|
||||
tags: [obsidian, karpathy, llm-knowledge, obsidian-skills, privacy, pkm]
|
||||
created: 2026-06-09
|
||||
updated: 2026-06-09
|
||||
sources: ["raw/inbox/Co się dzieje, gdy dasz LLM-owi klucze do swojego skarbca Obsidian.md"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Co się dzieje, gdy dasz LLM-owi klucze do swojego skarbca Obsidian
|
||||
|
||||
Artykuł Valerie analizuje rewolucyjny zwrot w osobistym zarządzaniu wiedzą (PKM) zapoczątkowany przez manifest Andreja Karpathy'ego "LLM Knowledge Base". Autorka szczegółowo opisuje wdrożenie oficjalnych "umiejętności agentów" (`obsidian-skills`) autorstwa Steph Ango (CEO Obsidiana) i krytycznie ocenia szanse oraz realne zagrożenia związane z oddaniem kontroli nad naszym skarbiecem sztucznej inteligencji.
|
||||
|
||||
## Key Points
|
||||
|
||||
### Przesunięcie Paradygmatu:
|
||||
- **Stary schemat (Chat with your vault)**: Płaskie wyszukiwanie wektorowe (RAG), w którym model pobiera wycinki i generuje odpowiedź na jedno pytanie. Sesja czatu jest ulotna, a skarbiec pozostaje nieuporządkowanym cmentarzem notatek.
|
||||
- **Nowy schemat (Search-assisted writing)**: Model AI staje się aktywnym redaktorem naczelnym, który nigdy nie śpi. Działa w tle, porządkuje notatki, dodaje strony podmiotów (entities), aktualizuje pojęcia, łączy fakty i samodzielnie utrzymuje porządek w bazie.
|
||||
|
||||
### Rozwiązanie problemu formatowania (`obsidian-skills`):
|
||||
- Modele językowe znają czysty Markdown, ale popełniają błędy w dialekcie Obsidiana (błędne WikiLinki, uszkadzanie metadanych YAML frontmatter czy plików Canvas).
|
||||
- Steph Ango (CEO Obsidiana) wydał oficjalną paczkę `kepano/obsidian-skills` (licencja MIT), która uczy agentów (Claude Code, Codex) natywnych zasad Obsidiana:
|
||||
- `obsidian-markdown` — rzetelna obsługa linków dwukierunkowych i calloutów.
|
||||
- `obsidian-bases` — obsługa danych strukturalnych.
|
||||
- `json-canvas` — bezpieczne generowanie i edycja płócien wizualnych.
|
||||
- `obsidian-cli` — zarządzanie skarbcem bezpośrednio z terminala.
|
||||
- `defuddle` — czyszczenie zrzucanych stron internetowych ze śmieci reklamowych, co oszczędza tokeny.
|
||||
|
||||
### Realne Ryzyka i Tryby Awaryjne:
|
||||
- **To nie czyni Cię mądrym, czyni mądrym Twój skarbiec**: Model generuje doskonałą syntezę, ale po dwóch tygodniach uświadamiasz sobie, że od pół roku obracasz w głowie tę samą, niedokończoną myśl. AI ułatwia księgowość, ale nie zastępuje myślenia.
|
||||
- **Zjawisko Halucynacji Relacji**: Lokalne, mniejsze modele potrafią z dużą pewnością połączyć dwa zupełnie niezwiązane ze sobą pojęcia i napisać przekonujący akapit o ich relacji, która nie ma żadnego poparcia w Twoich notatkach. Wymaga to permanentnej, krytycznej weryfikacji człowieka.
|
||||
- **Problem Zimnego Startu**: Model nie uporządkuje chaosu za Ciebie. Jeśli Twoje notatki to niechlujne bazgroły, pierwszy miesiąc spędzisz na sprzątaniu bazy, którego AI nie potrafi wykonać bez Twoich wytycznych.
|
||||
- **Prywatność danych**: Przekazanie kluczy do skarbca agentom chmurowym oznacza wysłanie swoich najbardziej intymnych notatek, pamiętników czy listów rezygnacyjnych na serwery firm trzecich. Prywatność jest zachowana wyłącznie przy użyciu modeli 100% lokalnych.
|
||||
- **Koszty sprzętowe**: Dobre, lokalne systemy wymagają mocnego i drogiego sprzętu (np. Mac z dużą ilością pamięci unified RAM lub dedykowane karty RTX) do uruchomienia modeli typu Mistral NeMo 12B czy Qwen3. Mniejsze lub starsze komputery generują syntezy o drastycznie niższej jakości.
|
||||
|
||||
## Relevant Concepts
|
||||
- [[concepts/search-assisted-writing]] — Model pracy, w którym AI jest redaktorem, a nie tylko wyszukiwarką.
|
||||
- [[concepts/agent-formatting-dialects]] — Specjalizacja instrukcji dla agentów w celu poprawnej obsługi niestandardowych formatów plików.
|
||||
- [[concepts/rag-vs-knowledge]] — Zderzenie transakcyjnego RAG z trwałą kompilacją wiedzy.
|
||||
- [[concepts/knowledge-compilation]] — Rola LLM jako kompilatora surowej wiedzy.
|
||||
|
||||
## Relevant Entities
|
||||
- [[entities/obsidian-skills]] — Zestaw umiejętności agentowych od Steph Ango.
|
||||
- [[entities/obsidian]] — Program do prowadzenia bazy notatek.
|
||||
- [[entities/claude-code]] — Terminalowy agent operujący na plikach.
|
||||
- [[entities/mistral-nemo]] — Rekomendowany, lokalny model 12B optymalny do zadań PKM.
|
||||
|
||||
## Source Metadata
|
||||
- **Type**: Artykuł / Krytyczna analiza PKM
|
||||
- **Author**: Valerie
|
||||
- **Date**: 2026-05-08
|
||||
- **URL**: https://medium.com/dare-to-be-better/what-happens-when-you-give-an-llm-the-keys-to-your-obsidian-vault-370562d821e0
|
||||
+437
@@ -0,0 +1,437 @@
|
||||
---
|
||||
title: "Budowanie osobistego systemu operacyjnego CTO z wykorzystaniem kodu Claude'a"
|
||||
source: "https://obie.medium.com/building-a-personal-cto-operating-system-with-claude-code-b3fb9c4933c7"
|
||||
author:
|
||||
- "[[Obie Fernandez]]"
|
||||
published: 2026-01-25
|
||||
created: 2026-06-11
|
||||
description: "Jak wykorzystuję AI jako asystent wykonawczy, zarządzając 10 inżynierami, kodującą statki i jednocześnie pracując na poziomie C-level."
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
|
||||
|
||||
## Jak wykorzystuję AI jako asystent wykonawczy, zarządzając 10 inżynierami, kodującą statki i jednocześnie pracując na poziomie C-level.
|
||||
|
||||
T Kilka tygodni temu zacząłem nową rolę jako CTO na pełen etat w ZAR. Pierwszą rzeczą, jaką zrobiłem, było utworzenie nowego folderu na laptopie, uruchomienie Claude Code i zadanie dość prostego komunikatu:
|
||||
|
||||
```c
|
||||
Create me a markdown-based system where I can regularly run you,
|
||||
Claude Code, that lets me be the best world-class CTO possible.
|
||||
I'm planning to use you as my personal executive assistant and
|
||||
CTO expert coad. Document everything in a series of folders as
|
||||
you see fit. We're in plan mode, feel free to interview me if you
|
||||
have any questions about this job.
|
||||
```
|
||||
|
||||
Nie projektowałem struktury folderów z wyprzedzeniem. Nie szukałem podpowiedzi ani szablonów do takich rzeczy. Po prostu zaufałem bardzo zdolnemu modelu Opus 4.5, żeby to rozgryźć. Ten wpis dokumentuje to, czego się do tej pory nauczyłem, dla każdego, kto chce zbudować coś podobnego.
|
||||
|
||||
## Praktyczne efekty po trzech tygodniach
|
||||
|
||||
Najpierw pozwól, że wyjaśnię*, dlaczego* możesz chcieć spróbować tego rozwiązania:
|
||||
|
||||
- Przygotowanie do spotkania: Jestem przygotowany na każde spotkanie. Codziennie. Pełny kontekst o uczestnikach, odpowiednia historia, proponowane punkty do rozmowy.
|
||||
- Jasność priorytetów: W każdej chwili, bez względu na to, jak bardzo jestem rozproszona czy zestresowana, mogę zaufać Claude'owi, że pomoże mi się uspokoić i zdecydować, na czym powinnam się skupić dalej.
|
||||
- Historia decyzji: Gdy ktoś w końcu zapyta o wcześniejszą decyzję, będę miał pełny kontekst. Nie jest to mgliste wspomnienie. Rozważałem rzeczywiste alternatywy, dlaczego wybrałem to, co zrobiłem, i kto był zaangażowany.
|
||||
- Wykonanie bez przełączania kontekstu: publikowanie na Slacku, aktualizacja kalendarzy, tworzenie pomysłów na wpisy na bloga, śledzenie zadań... Wszystko to rozmowne w naturalnej formie.
|
||||
|
||||
Miałem wcześniej asystentów wykonawczych. Dobre. Ten system jest lepszy. Nigdy niczego nie zapomina, nigdy nie trzeba go wprowadzać w bieżąco i działa w tempie rozmowy. Czy wspomniałem, że jest zawsze dostępny?
|
||||
|
||||
## Jak wykorzystuję go do zarządzania codziennością
|
||||
|
||||
Zawsze mam otwartą przynajmniej jedną sesję Claude Code w tym katalogu. Podczas równoległych etapów pracy (przygotowanie do wielu spotkań, badanie kandydatów, pisanie dokumentów) otwieram dodatkowe zakładki z równoległymi sesjami. Właśnie sprawdziłem i obecnie mam 9 równocześnie otwartych sesji Claude Code w osobnych zakładkach w jednym oknie terminala poświęconym tylko mojemu asystentowi.
|
||||
|
||||
Mimo że jestem bardzo szybkim typerzem, staram się jak najbardziej zmusić się do używania głosu (Wispr Flow) przy czymkolwiek dłuższym niż jedno zdanie. Strumień świadomości działa świetnie.
|
||||
|
||||
Krótkie prompty nie muszą być nawet pełnymi myślami. "Poranna synchronizacja", "Next 1:1", "Post summary of this to Slack". Claude całkiem dobrze rozumie, co mam na myśli z kontekstu.
|
||||
|
||||
## Poranna rutyna
|
||||
|
||||
Jedną z pierwszych korzyści było rozpoczęcie dnia pracy od słowa "dzień dobry", na co Claude odpowiada następującymi krokami:
|
||||
|
||||
1. Czyta mój cotygodniowy dokument tematyczny
|
||||
2. Sprawdza oczekujące na zadania
|
||||
3. Pobiera moje rzeczywiste dane dane w kalendarzu
|
||||
4. Ustala, co wymaga mojej natychmiastowej uwagi.
|
||||
|
||||
Zajmuje mi około 30 sekund, żeby dokładnie zorientować się, jak wygląda mój dzień.
|
||||
|
||||
W końcu zacząłem się zastanawiać, co Claude wymyśli, jeśli ustandaryzuję swoją poranną rutynę jako umiejętność.
|
||||
|
||||
To jest prompt, który napisał, wyzwalany poleceniem ukośnika w następujący sposób:`/morning`
|
||||
|
||||
```c
|
||||
# Morning Briefing
|
||||
|
||||
Run the morning sync workflow:
|
||||
|
||||
1. Read the weekly focus from \`priorities/weekly-focus.md\`
|
||||
2. Check \`meetings/actions/\` for any pending action items
|
||||
3. Check today's calendar using Google Calendar MCP tools (GOOGLECALENDAR_EVENTS_LIST with today's timeMin/timeMax in UTC)
|
||||
4. Summarize:
|
||||
- What's the focus today based on weekly priorities
|
||||
- What meetings are scheduled for today
|
||||
- Any pending action items that need attention
|
||||
- Any blockers or items requiring immediate attention
|
||||
|
||||
Keep the briefing concise and actionable.
|
||||
```
|
||||
|
||||
## Przetwarzanie transkrypcji spotkań
|
||||
|
||||
W pracy używamy Gemini do transkrypcji prawie wszystkich spotkań. Na początku kopiowałem transkrypcje do konsoli. W końcu udało mi się uruchomić integrację MCP z moim Google Suite (patrz poniżej jak) i udało mi się zautomatyzować ten proces.
|
||||
|
||||
Kilka razy dziennie wywołuję niestandardową umiejętność o nazwie i Claude automatycznie:`/meetsync`
|
||||
|
||||
- Tworzy notatki ze spotkań w odpowiednim folderze
|
||||
- Ekstrakcja przedmiotów akcji z właścicielami
|
||||
- Aktualizuje skład drużyny o wszystko, czego nowe się dowiemy o ludziach
|
||||
- Aktualizuje inne istotne pliki kontekstowe
|
||||
|
||||
Nie zastanawiam się, gdzie trafiają transkrypty. Zajmuje się samym archiwizacją i organizacją. Oczywiście, nie napisałem też niestandardowej umiejętności, napisał ją sam Claude:
|
||||
|
||||
```c
|
||||
# Meeting Sync Command
|
||||
|
||||
Sync unprocessed meeting transcripts from Google Calendar/Gemini
|
||||
into the zarcto knowledge system.
|
||||
|
||||
## Instructions
|
||||
|
||||
Execute the following workflow:
|
||||
|
||||
### Step 1: Get Recent Meetings from Google Calendar
|
||||
|
||||
Use the Rube MCP to query Google Calendar for meetings from the
|
||||
last 48 hours that have Gemini notes attachments:
|
||||
|
||||
1. Call \`RUBE_SEARCH_TOOLS\` with use_case "list calendar events with
|
||||
attachments"
|
||||
2. Call \`GOOGLECALENDAR_EVENTS_LIST\` for the primary calendar with:
|
||||
- timeMin: 48 hours ago (RFC3339 format)
|
||||
- timeMax: now (RFC3339 format)
|
||||
- singleEvents: true
|
||||
- orderBy: startTime
|
||||
- timeZone: Europe/Amsterdam
|
||||
|
||||
3. Filter results to only meetings that have:
|
||||
- \`attachments\` array containing items with \`title\` containing "Gemini"
|
||||
or "Notes by Gemini"
|
||||
- \`eventType\` of "default" (exclude working locations, etc.)
|
||||
|
||||
### Step 2: Find Unprocessed Meetings
|
||||
|
||||
1. Read the list of existing files in \`meetings/notes/\` directory
|
||||
2. For each calendar meeting with Gemini notes:
|
||||
- Extract the date (YYYY-MM-DD) and generate expected filename pattern
|
||||
- Check if a corresponding note already exists
|
||||
- If no note exists, add to "unprocessed" list
|
||||
|
||||
### Step 3: Fetch Transcript Content
|
||||
|
||||
For each unprocessed meeting:
|
||||
|
||||
1. Extract the Google Doc ID from the attachment fileUrl or fileId
|
||||
2. Use \`GOOGLEDOCS_GET_DOCUMENT_BY_ID\` to fetch the document
|
||||
3. Extract plain text from the document body using the standard
|
||||
extraction pattern:
|
||||
\`\`\`
|
||||
body.content → paragraph.elements → textRun.content
|
||||
\`\`\`
|
||||
|
||||
### Step 4: Process Each Transcript
|
||||
|
||||
For each fetched transcript, follow the standard "Process Meeting
|
||||
Transcript" workflow from CLAUDE.md:
|
||||
|
||||
1. **Create meeting note** in \`meetings/notes/YYYY-MM-DD-topic.md\`:
|
||||
- Use the meeting summary/title to derive the topic slug
|
||||
- Include key discussion points, decisions, and context
|
||||
- Format similar to existing notes (see examples in the directory)
|
||||
|
||||
2. **Create action items** in \`meetings/actions/YYYY-MM-DD-topic.md\`:
|
||||
- Extract actionable items from the transcript
|
||||
- Group by person responsible
|
||||
- Use checkbox format: \`- [ ] Action item\`
|
||||
|
||||
3. **Update team roster** (\`team/roster.md\`):
|
||||
- Add any new information learned about team members
|
||||
- Update skills, interests, or context if relevant
|
||||
|
||||
4. **Update recruiting pipeline** (\`recruiting/pipeline.md\`):
|
||||
- Only if meeting involved candidate discussions
|
||||
|
||||
5. **Update other context files** as appropriate:
|
||||
- \`context/architecture.md\` for technical decisions
|
||||
- \`priorities/weekly-focus.md\` if priorities discussed
|
||||
- \`decisions/\` if significant decisions made
|
||||
|
||||
### Step 5: Present Summary
|
||||
|
||||
After processing all meetings, present a summary:
|
||||
|
||||
\`\`\`
|
||||
## Meeting Sync Complete
|
||||
|
||||
**Processed**: X meetings
|
||||
**Skipped** (already processed): Y meetings
|
||||
**Failed** (permission denied, etc.): Z meetings
|
||||
|
||||
### Newly Processed:
|
||||
1. YYYY-MM-DD Topic Name
|
||||
- Created: meetings/notes/YYYY-MM-DD-topic.md
|
||||
- Actions: X items for Y people
|
||||
- Updates: [list any other files updated]
|
||||
|
||||
2. ...
|
||||
|
||||
### Action Items Created:
|
||||
- Person A: X items
|
||||
- Person B: Y items
|
||||
|
||||
### Notable Updates:
|
||||
- [Any significant context file changes]
|
||||
\`\`\`
|
||||
|
||||
## Error Handling
|
||||
|
||||
- If Google Calendar or Docs connection fails, prompt user to reconnect via Rube
|
||||
- If a specific document has permission issues, note it and continue with others
|
||||
- If no unprocessed meetings found, report "All meetings already synced"
|
||||
|
||||
## Notes
|
||||
|
||||
- Default lookback is 48 hours; user can specify different range with argument
|
||||
- Only processes meetings where Obie is an attendee
|
||||
- Skips external meetings without Gemini notes
|
||||
```
|
||||
|
||||
## Przygotowanie 1:1
|
||||
|
||||
Oto moje polecenie tworzenia notatek z indywidualnych spotkań. Jeszcze raz, to napisał Claude, nie ja. Odtwarzam te umiejętności tylko w celach ilustracyjnych, nie po to, żebyś mógł je skopiować.`/prep`
|
||||
|
||||
```c
|
||||
# 1:1 Preparation
|
||||
|
||||
Prepare for a 1:1 meeting with $ARGUMENTS.
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Read team member info** from \`team/roster.md\`
|
||||
- Extract their current context, recent work, concerns, goals
|
||||
|
||||
2. **Read recent 1:1 notes** from \`team/one-on-ones/[name].md\`
|
||||
- Review last 2-3 conversations
|
||||
- Note any follow-up items from previous meetings
|
||||
|
||||
3. **Check pending action items** in \`meetings/actions/\`
|
||||
- Find any action items assigned to them or involving them
|
||||
- Note status of items from previous 1:1s
|
||||
|
||||
4. **Suggest topics to cover**:
|
||||
- Follow-up on previous action items
|
||||
- Current blockers or challenges
|
||||
- Career development and growth
|
||||
- Feedback (both directions)
|
||||
- Team dynamics or concerns
|
||||
- Any patterns noticed from recent work
|
||||
|
||||
5. **Format the output**:
|
||||
\`\`\`
|
||||
# 1:1 Prep: [Name]
|
||||
|
||||
## Context
|
||||
[Brief summary of their role, current focus, recent wins/challenges]
|
||||
|
||||
## Last 1:1 Highlights
|
||||
[Key points from most recent conversation]
|
||||
|
||||
## Pending Items
|
||||
- [ ] Item 1 from previous 1:1
|
||||
- [ ] Item 2 related to them
|
||||
|
||||
## Suggested Topics
|
||||
1. Topic 1 (with context)
|
||||
2. Topic 2 (with context)
|
||||
3. Topic 3 (with context)
|
||||
|
||||
## Notes to Remember
|
||||
[Anything specific to bring up or be mindful of]
|
||||
\`\`\`
|
||||
|
||||
Keep it concise and actionable. Focus on what matters most right now.
|
||||
```
|
||||
|
||||
Korzystając z tego polecenia, zaczynam każde spotkanie jeden na jeden z pełnym kontekstem naszych wcześniejszych rozmów i ewentualnych spraw.
|
||||
|
||||
## Decyzje dotyczące logowania
|
||||
|
||||
Kiedy podejmuję decyzję, mówię "loguj decyzję o X" lub wywołuję. Claude omawia ze mną kontekst i opcje, tworzy uporządkowany zapis decyzji i linkuje do odpowiedniego kontekstu.`/decide`
|
||||
|
||||
Trzy miesiące później, gdy ktoś zapyta "dlaczego przeszliśmy z X na Y?", będę miał pełne uzasadnienie udokumentowane. Nie tylko decyzja, ale także rozważane alternatywy i powody, dla których je odrzuciliśmy.
|
||||
|
||||
```c
|
||||
# Log Decision
|
||||
|
||||
Capture the following important decision with context, alternatives,
|
||||
and rationale:
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Understand the decision context**
|
||||
- Ask clarifying questions if the decision topic is vague
|
||||
- Understand what problem this decision solves
|
||||
- Identify who was involved in making this decision
|
||||
|
||||
2. **Explore alternatives**
|
||||
- What other options were considered?
|
||||
- Why were they rejected?
|
||||
- What tradeoffs were evaluated?
|
||||
|
||||
3. **Read the decision template** from \`decisions/_template.md\`
|
||||
|
||||
4. **Check for related decisions** in \`decisions/\`
|
||||
- Search for similar past decisions
|
||||
- Note if this reverses or builds on previous decisions
|
||||
- Link to relevant prior decisions
|
||||
|
||||
5. **Create the decision record**:
|
||||
- Use filename format: \`decisions/YYYY-MM-DD-slug.md\`
|
||||
- Follow the template structure
|
||||
- Include:
|
||||
- Date and context
|
||||
- Problem/need
|
||||
- Decision made
|
||||
- Alternatives considered
|
||||
- Rationale and tradeoffs
|
||||
- Consequences (expected)
|
||||
- People involved
|
||||
- Related decisions or context files
|
||||
|
||||
6. **Link to relevant context**:
|
||||
- Reference architecture docs if technical
|
||||
- Reference project briefs if project-specific
|
||||
- Reference team discussions if relevant
|
||||
|
||||
7. **Confirm with Obie** before writing the file
|
||||
- Show him the draft
|
||||
- Get approval on completeness
|
||||
- Then write the file
|
||||
|
||||
Keep it concise but complete. Future you (or future team members)
|
||||
should be able to understand why this decision was made without
|
||||
additional context.
|
||||
```
|
||||
|
||||
## Publikowanie na Slacku i innych narzędziach
|
||||
|
||||
Muszę zaktualizować kanał inżynierski o istotnym PR lub decyzji. Mówię "wrzuć to do #engineering na Slacku" i przekazuję wiadomość. To publikuje. Gotowe.
|
||||
|
||||
Komunikowałem się ze wszystkimi moimi podwładnymi przez Slacka, prosząc ich o ustalenie cyklicznych spotkań 1:1 z moim linkiem do umawiania spotkań. Podobnie jest z Twitterem. To samo dotyczy zaproszeń do kalendarza. To samo dotyczy każdej usługi, którą podłączyłem przez integrację Rube MCP.
|
||||
|
||||
Jak wspomniano wyżej, integracja Rube MCP jest świetna do tego typu rzeczy, bez nadmiernego obciążania kontekstu.
|
||||
|
||||
## Techniczne przygotowania
|
||||
|
||||
### Struktura katalogu
|
||||
|
||||
Oto, co stworzył Claude, żeby pokazać, że jest to kompleksowe. Nigdy tu nie wchodzę i celowo nie próbowałem tego zaprojektować sam.
|
||||
|
||||
```c
|
||||
context/ # Company, team, architecture docs
|
||||
decisions/ # Decision records with rationale
|
||||
drafts/ # Work in progress documents
|
||||
journal/ # Weekly reflections
|
||||
meetings/
|
||||
actions/ # Action items with owners
|
||||
notes/ # Meeting transcripts and summaries
|
||||
playbooks/ # Recurring process documentation
|
||||
priorities/ # Weekly focus, 90-day plans
|
||||
projects/ # Project briefs and status
|
||||
recruiting/ # Pipeline, candidates
|
||||
reference/ # Mental models, frameworks
|
||||
team/
|
||||
one-on-ones/ # Individual 1:1 histories
|
||||
roster.md # Team member details
|
||||
```
|
||||
|
||||
Naprawdę nigdy nie myślę o tej strukturze. Claude wie, dokąd to zmierza. Po prostu z nim rozmawiam. W dniu, gdy zawartość zacznie być zbyt duża lub będzie się zagłębiać, poproszę Claude'a, żeby ją zoptymalizował. Do tego czasu wszystko w porządku.
|
||||
|
||||
### Integracja z MCP
|
||||
|
||||
Integracja [z Rube MCP](https://rube.app/) jest niezbędna. Daje Claude'owi dostęp do:
|
||||
|
||||
- Kalendarz Google (czytanie i tworzenie wydarzeń)
|
||||
- Slack (publikowanie wiadomości, czytanie kanałów)
|
||||
- Twitter/X (aktualizacje publikowania)
|
||||
- Liniowe (zarządzanie projektami i problemami)
|
||||
- Gmail i inne usługi
|
||||
|
||||
To oznacza, że mogę powiedzieć "co mam jutro w kalendarzu?" albo "wrzuć to na Slacka" bez przełączania kontekstu. To właśnie integracja zamienia ten system z systemu notatek w prawdziwego asystenta wykonawczego.
|
||||
|
||||
### Kontrola wersji
|
||||
|
||||
Wszystko jest w prywatnym repozytorium Git. Haki automatycznie synchronizują się. Daje mi to:
|
||||
|
||||
- Pełna historia wszystkich zmian
|
||||
- Robisz kopię zapasową bez zastanowienia
|
||||
- Możliwość odniesienia się do czegokolwiek z dowolnego momentu
|
||||
|
||||
Wszyscy w ZAR są w trakcie wdrażania i korzystania z tego systemu. Radziłem osobom nietechnicznym, żeby uruchamiali to na prywatnym Google Drive zamiast uczyć się Githuba i repozytoriów.
|
||||
|
||||
## Rzeczywiste przykłady
|
||||
|
||||
Rekrutacja: Wklejam CV kandydata lub jego profil na LinkedIn. Claude aktualizuje pipeline rekrutacyjne, proponuje pytania na rozmowie kwalifikacyjnej oparte na lukach w zespole i przygotowuje mnie do rozmowy kwalifikacyjnej.
|
||||
|
||||
Śledzenie wydajności: Jeśli muszę przejrzeć historię inżyniera, mogę powiedzieć "przeprowadź mnie przez historię z \[imię\]". Claude wyciąga notatki indywidualne, pokazuje wzorce w rozmowach, odnosi się do udokumentowanych obaw lub sukcesów.
|
||||
|
||||
Planowanie: "Jakie trzy najważniejsze czynniki blokują produktywność w tej chwili?" Claude czyta notatki z ostatnich spotkań, sprawdza oczekujące punkty działania, przegląda status liniowy i dostrzega rzeczywiste wąskie gardła.
|
||||
|
||||
Komunikacja: "Opublikuj aktualizację dotyczącą przyjęcia przez Stephena naszej oferty #leadership na Slacku." Gotowe. Brak zmiany kontekstu.
|
||||
|
||||
## Liczby po trzech tygodniach
|
||||
|
||||
Nie znałem tych liczb, dopóki nie poprosiłem Claude'a o ich obliczenia do tego wpisu na blogu. Całkiem imponujące statystyki, jeśli mogę tak powiedzieć.
|
||||
|
||||
- 82 notatki ze spotkań przetworzone i złożone
|
||||
- 47 spotkań w styczniu (2+ dziennie)
|
||||
- 18 udokumentowanych spotkań 1:1 z pełnym kontekstem i dalszymi działaniami
|
||||
- 35 plików śledzących zadania akcji z właścicielami i statusem
|
||||
- 23 członków zespołu śledzonych z 264 linijkami szczegółowego kontekstu
|
||||
- 9 dokumentów kontekstowych zachowanych
|
||||
- Łącznie przechwycono 11 579 linii wiedzy instytucjonalnej
|
||||
|
||||
A jednocześnie kod wysyłkowy. Jednocześnie działając na poziomie C-P razem z CEO i CPO.
|
||||
|
||||
## Dlaczego to działa lepiej niż inne systemy
|
||||
|
||||
Większość systemów zarządzania wiedzą zawodzi, ponieważ ich utrzymanie to druga praca. Trzeba pamiętać, żeby aktualizować rzeczy. Musisz wszystko zorganizować. Musisz myśleć o systemie, a nie o swojej rzeczywistej pracy.
|
||||
|
||||
Ten system działa, bo nigdy o nim nie myślę. Myślę o swojej pracy, a system uchwyca ją jako efekt uboczny naturalnej rozmowy.
|
||||
|
||||
Porównaj to z Notion, gdzie ciągle zastanawiasz się "czy to powinna być strona, baza danych?" albo "do której przestrzeni roboczej to należy?" albo reorganizujesz, bo taksonomia wybrana sześć miesięcy temu już nie pasuje.
|
||||
|
||||
W takim podejściu implementacja jest niewidoczna. Po prostu rozmawiam z Claude'em i on wszystko załatwia.
|
||||
|
||||
## Jak zacząć
|
||||
|
||||
1. Zacznij prosto: otwórz kod Claude w świeżym katalogu. Powiedz mu, czego potrzebujesz. Niech sam odkryje strukturę. Użyj mojego powyższego promptu, coś w stylu: "Zbuduj system operacyjny oparty na markdown, który sprawi, że będę działał jak światowej klasy \[twoja rola\]."
|
||||
2. Używaj go przez tydzień: zobacz, co działa, a co nie. Claude się dostosuje.
|
||||
3. Umieść to w kontroli wersji: prywatne repozytorium Git, jeśli jesteś techniczny. W przeciwnym razie umieść go w folderze, który się synchronizuje (Google Drive, iCloud, Dropbox).
|
||||
4. Połącz swoje narzędzia: Ustaw integracje MCP dla kalendarza, narzędzi komunikacyjnych i zarządzania projektami. To właśnie zmienia ją z notatek w prawdziwego asystenta.
|
||||
5. Zrób kilka sesji: Jedna sesja jest dobra. Trzy równoległe sesje pracy równoległej to moment, kiedy czujesz przewagę.
|
||||
6. Gdy zauważysz, że robisz to samo kilka razy, poproś Claude'a, żeby napisał jakąś umiejętność. W ten sposób uzyskujesz skumulowaną produktywność.
|
||||
|
||||
System z czasem staje się mądrzejszy. Każda rozmowa dodaje kontekstu. Każda decyzja tworzy punkt odniesienia. Każda aktualizacja drużyny buduje bogatszy obraz.
|
||||
|
||||
## Co dalej
|
||||
|
||||
Obecnie jestem ograniczony do okna terminala. Głos przez Wispr Flow już sprawia, że wszystko wydaje się bardziej naturalne. Trajektoria zmierza ku ciągłej rozmowie przez cały dzień, a nie "używaniu narzędzia".
|
||||
|
||||
Chciałbym dać Claude'owi możliwość wyświetlania wyników na moim pulpicie w formie tekstu bogatego. Zasadniczo dlatego, że jeśli generuje coś na przykład notatki ze spotkań 1:1, potrzebuję, żeby się pojawiały i były dostępne, zamiast przewijać się poza bieżący kontekst terminala. To zmniejszyłoby moją potrzebę ciągłego otwierania nowych sesji.
|
||||
|
||||
Bardzo chciałbym też móc komunikować się z moim asystentem przez wiadomości tekstowe i czat głosowy, gdy nie jestem przy komputerze. Eksperymentuję z Clawdbot, aby dowiedzieć się więcej o tym, jak poradzić sobie z tym konkretnym wyzwaniem. Jest bardzo możliwe, że w końcu przeniosę cały ten system na instancję Clawdbota!
|
||||
|
||||
Podsumowując, jestem pewien, że modele będą się nadal rozwijać dzięki lepszemu rozumowaniu, lepszej pamięci i lepszemu wykorzystaniu narzędzi. Więc system, który mam teraz, będzie tylko bardziej zaawansowany. Będę tu publikować aktualizacje, gdy opracuję nowe techniki i przełomy.
|
||||
@@ -0,0 +1,222 @@
|
||||
---
|
||||
title: "Build An AI Second Brain Knowledge Base (Step-By-Step)"
|
||||
source: "https://www.youtube.com/watch?v=yke4fLQUsh4&list=PLf-bJpKeji6T054DPLgMEgAj8rySAwFWJ"
|
||||
author:
|
||||
- "[[Matt Wolfe]]"
|
||||
published: 2026-05-06
|
||||
created: 2026-06-09
|
||||
description: "Here's how to build an AI second brain. Launch your own AI agents with OpenClaw at http://hostinger.com/mattopenclaw and get 10% off with code MATTWOLFEDisco..."
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
|
||||
|
||||
## Transcript
|
||||
|
||||
### Wprowadzenie
|
||||
|
||||
**0:00** · So, I just built a second brain knowledge management system that has an entire wiki built in that I can chat with. It will pull any information from that second brain when I chat. It's got a built-in CRM. I can journal, and it will actually look at my wiki knowledge base and try to help me with whatever issues I'm going through from my journal by looking inside of the wiki.
|
||||
|
||||
**0:18** · And of course, it's got all of the content that I've saved from around the web, including YouTube videos and articles and tweets and podcasts and just tons of stuff that I've injected into this that is all accessible directly from a chat or from journaling. It is really, really sweet, and I'm going to break down how the whole thing works and how you can build one for yourself right now. Most second brain systems are just like storage, right?
|
||||
|
||||
**0:42** · You dump your YouTube transcripts and your articles and your blog posts and your podcasts and just everything that you're interested in, you just dump it all into one place.
|
||||
|
||||
**0:53** · Problem is, that's kind of where the information just goes to die. Unless you're like actively going back through and reviewing the notes all the time and searching through your second brain, it's just a dumping ground for information that I never go back and look at later. So, for the knowledge management system that I'm going to build, there's three core pillars that I want to build for mine. Number one is the wiki/knowledge base. This is where I'm going to store like everything from around the web that I find.
|
||||
|
||||
### Przegląd systemu
|
||||
|
||||
**1:17** · YouTube transcripts, articles, podcast transcripts, tweets, you name it, it all goes into this wiki knowledge base section. Number two is my CRM. So, whenever I go to a events and I meet people or I jump on Zoom calls with people, I want to remember those conversations and I want to be able to recall them in the future. I also want to store details about those people, how I met them, where I met them, some of the discussions we had, any sort of contact details I got from them, email, phone number, address, whatever.
|
||||
|
||||
**1:46** · They can all live in this sort of CRM element of this bigger second brain that I'm building. And the third element is where this all gets pulled together, and And the journal. Now, I'm a big journaler. I journal pretty much every single day.
|
||||
|
||||
**1:59** · When I have good days, I journal about what went right, the things I'm excited about, gratitude, that sort of stuff.
|
||||
|
||||
**2:04** · When I have rough days, I journal about the things that are bothering me. My videos not performing as well as I want them to, having a creative block and not knowing what to make videos about. I do a lot of travel and I debate a lot about whether the travel's going to be worth it or not. I journal about pretty much everything in my business. So, these are my three ideal inputs. For you, it might be clients or workouts, research papers, recipes, sales calls, classroom notes.
|
||||
|
||||
**2:30** · The point is, the knowledge base sits at the center and then everything else sort of connects to it. The two elements that I think are probably the most useful to the most amount of people are going to be the wiki and the journal. Maybe the CRM isn't what you need. Again, maybe it's your classroom notes, your workouts, your recipes, et cetera. So, here's a rough drawing of what I have in mind. So, you've got your knowledge base that lives at the center of all of this.
|
||||
|
||||
**2:53** · All of this knowledge is going to live in Obsidian. I'll get into the whole building process in a second. You're going to save articles from around the web, YouTube videos, you know, podcast notes, whatever you find around the web that's relevant to you, you're going to save it with a simple Chrome web clipper and it's going to save into your knowledge base. The CRM that I just mentioned, notes about people you met and where you met them and all that kind of stuff gets saved to the knowledge base. Meeting notes, I personally use Granola to record my meetings and take notes for me. Those meeting notes can automatically be injected into the knowledge base.
|
||||
|
||||
**3:24** · And then you have journal entries. This is the layer where you actually interact with your knowledge base. You journal on what you're dealing with right now and ideally it's going to pull from the knowledge base that has all of this other information in it to ground the responses to your journal entries. This will make more sense as I go. Please excuse the PowerPoint style slide here, but I really want to explain what I'm trying to build. So, here's the system I imagine. You save your articles, your transcripts, et cetera, into this system. We'll do that using a web clipper.
|
||||
|
||||
**3:53** · The AI layer in the background that we're going to build then summarizes this stuff for us. So, it's not just a giant transcript, it's actually sort of the bullets and just the information we need to know. The AI is also going to extract people, companies, tools, ideas, and themes, and sort of break those off. That's where it becomes kind of like a wiki. You could click into the tools page and it will list off all the tools that have been mentioned across everything that we've saved. You can click into one of the tools and it will mention where and what video that came from. And that goes for all of these little categories here. I also wanted to auto-link related notes.
|
||||
|
||||
**4:27** · So, if I have multiple videos about how to build something with OpenClaw, they all get cross-referenced to each other and I can click around and sort of jump into others. If you're familiar with other second brain systems or like the Zettelkasten system, it's essentially that same concept of interlinking. I'm then going to let the journal directly into the system. So, when I do write journals, it responds like ChatGPT, but it's actually grounded in my own saved knowledge. So, it's not going to just respond with what ChatGPT would have responded with.
|
||||
|
||||
**4:56** · It's going to respond with something like, "I see you're struggling with ideas for videos. Well, you saved this video 3 days ago that says you should do this, this, and this.
|
||||
|
||||
**5:05** · You also saved this video 2 weeks ago that gave this advice when you're struggling with video ideas." And it will actually pull from the knowledge that I've saved, making it more tailored to exactly what interested me and what I found valuable over time as I save stuff into the system. It's also going to use AI to find patterns from past journal entries. So, if I'm constantly journaling on the same thing over and over again, the same struggle, it's going to see that as a pattern and take that into account when it's responding to my next journal entries.
|
||||
|
||||
**5:31** · It should resurface relevant ideas when I need them, and it should also let me save notes about people and connect those people to ideas, companies, events, and conversations. So, the CRM and the meeting notes that I'm constantly saving, that should also be connected to ideas and journal entries and all of it sort of pulled together in this big mashup of like here's the conversations I've had, here's what I'm journaling on, here's what I've saved that I found interesting, and it's all in this big old soup of content that I'm saving, but
|
||||
|
||||
**5:59** · that big old soup of content that I'm saving is the grounded information that is getting pulled when I write my journal entries and then get a chat response based on those journal entries.
|
||||
|
||||
**6:08** · All right, now that I've completely over explained this, let's just jump into the process I'm going through to build this.
|
||||
|
||||
### OpenClaw na Hostingerze
|
||||
|
||||
**6:14** · There's a cool new feature from Hostinger that's made for deploying AI agents at home. So, if you've ever wanted to run something like OpenClaw, but don't know where to start or find it really complicated, this is going to make the process a lot easier. I actually use OpenClaw myself, so I can attest that the setup can get pretty technical. Right now, it's deployed on my DGX Spark and my favorite thing it built is simple CRM that when I meet people at events, I can save quick notes in Slack and then later ask it to remind me what we talked about.
|
||||
|
||||
**6:42** · So, it's great for automating everyday things like that to full-on businesses and these huge agentic systems, which I've also seen people do. And this new feature from Hostinger makes it a lot easier to set up. You can either pick a managed OpenClaw plan or a VPS option. The managed version is honestly the easiest.
|
||||
|
||||
**7:02** · It's a one-click deployment that includes built-in AI credits, web scraping already connected, and they handle the updates, backups, and security for you. You just go to the OpenClaw landing page on Hostinger, click get OpenClaw, choose your plan, and by the way, if you do the 12- or 24-month option, it's even cheaper per month. Then, during setup, you choose your AI provider, pick your communication channel like Telegram or WhatsApp, and launch. And then, once it's live, your agent runs 24/7. AI agents like this used to feel very gatekept.
|
||||
|
||||
**7:34** · Like, only the really technical people or big enterprises were able to use them, but now it's pretty cool how easy it's become to set it up and use it for yourself at home. So, if you've wanted your own AI assistant without the headache of managing servers manually, this is probably the easiest way I've seen to do it. Check it out at the link in the description box, and to save even more money, use my code Matt Wolfe for an additional 10% off. And thank you so much to Hostinger for supporting my channel and sponsoring this portion of today's video. Now, before I go any further on this, I do want to give credit where credit is due.
|
||||
|
||||
### Koncepcja Wiki Karpathy LLM
|
||||
|
||||
**8:06** · This whole LLM knowledge base idea came straight from Andrej Karpathy. I specifically took the idea of using Obsidian as the front end. Obsidian sort of helps organize and easily read markdown files. I'm just sort of extrapolating off of this idea and adding my journaling element and my CRM element to the wiki concept that Andre laid out here. Now, in order to build this, you're going to need a couple tools. I'm going to build this in Codex here. This has been sort of my IDE of choice lately to do coding and projects like this.
|
||||
|
||||
### Potrzebne narzędzia
|
||||
|
||||
**8:35** · This is free to download, and you get a certain amount of usage on the free ChatGPT plan, but you're going to get the most out of it if you do end up upgrading. I'm also using Obsidian here. Again, this is just a giant markdown organizer and reader. This is totally free to get. You can find it over at obsidian.md.
|
||||
|
||||
**8:52** · You're also going to want the Obsidian web clipper. So, if you're on the obsidian.md website, I can scroll all the way to the bottom here, and you can see there's a link for web clipper.
|
||||
|
||||
**9:01** · Click in there, click add to Chrome, and you'll get this little Obsidian web clipper that you can see here in my Chrome. And if I click this, this is what automatically creates a new markdown file, a new note for whatever page you're on. And the cool thing that I really like about this Obsidian web clipper is that it automatically pulls the transcripts from any YouTube video.
|
||||
|
||||
**9:20** · So, if I come over here to YouTube and click on one of my recent YouTube videos, and then I come up to the Obsidian web clipper, it'll take a second to load, but it will eventually load the entire transcript for this whole video straight into Obsidian, and that makes it really easy to inject any YouTube video or any article you find around the web directly into your Obsidian vault. So, once you have Obsidian installed on your computer, create a brand new vault, and I'm going to call it second brain, and I'm going to save it in a folder on my computer called second brain.
|
||||
|
||||
### Budowanie
|
||||
|
||||
**9:49** · Now, I'll open that, and we'll create this new vault, and you can see I have a fresh blank vault with nothing in it yet except for a little welcome message. Now, it's important to remember where on your computer you just saved this vault, cuz that's going to be necessary in the next step here. I'm going to delete this welcome message. It's not going to be necessary, and now we have a purely empty clean vault. So, for the next step, I'm going to jump into Codex, and we're going to actually build the dang thing.
|
||||
|
||||
**10:16** · So, over on the left here inside of Codex, I'm going to click on add new project, and then I'm going to select use an existing folder. It's going to open up my browser here to pick the folder, and I'm going to go to the exact folder that we just set our Obsidian vault up with. So, for me, it's this second brain folder that I created here, and we'll go ahead and open that, and then you can see I now have a project over here called second brain. So, to start this off, we're going to build the basic bones of our wiki. And luckily, Andre Karpathy generously gave us this GitHub page that explains exactly how the wiki architecture works.
|
||||
|
||||
**10:49** · So, the initial sort of hard part of building the wiki is already figured out for us.
|
||||
|
||||
**10:56** · We can just take this URL to this GitHub post here, open up Codex, make sure we're in our second brain project folder here, and giving it the prompt build out architecture based on Karpathy's LLM wiki here. I'm linking to that page on GitHub that we were just looking at, and then I said the current second brain folder is the folder that Obsidian is connected to. It is currently empty, so we're building from scratch. And let's go ahead and let it build out the sort of architecture bones for us based on what Karpathy's already figured out. All right, so it worked for about 5 minutes.
|
||||
|
||||
**11:26** · It actually built out a whole bunch of extra files that it didn't need to build. I don't know why it created 51 files. The architecture is actually supposed to be pretty small for this.
|
||||
|
||||
**11:37** · So, I literally prompted it, "Please remove all the extra crap and just build what's explicitly called for in Carpathy's game plan." And it says, "Done. I pruned it back to the minimal Carpathy game plan." And now we just have these files built in. If we pop open Obsidian here, you could see we've got just the folders we need. We have the raw folder, we have the wiki folder, we have our agents.md file, our index.md file, and our log.md file. We can see here exactly what each of these is for.
|
||||
|
||||
**12:05** · The raw folder is for the immutable source material. This is where the original stuff goes. Raw/assets, this is for optional local Obsidian attachments.
|
||||
|
||||
**12:13** · You got the wiki. This is the AI-generated markdown files that it's pulling from the raw content that we're inputting. You have the agents.md file, which basically explains how this whole thing works. So, we can see it's got the operations. When the user adds a source and asks LLM to process it, it does all these things. When the user asks a question, it queries it this way. So, it basically tells it how this agent should operate. You have the index.md file.
|
||||
|
||||
**12:39** · This is basically the catalog of everything that's in the wiki. And then you have the log file, where whenever you make updates or changes or add things, it updates the log file. Super, super simple. We're starting bare-bones here. If I look directly in the folder, we just have what you see inside of Obsidian. So, now I'm going to make sure that my Obsidian web clipper is dialed in. So, I'll go ahead and click on this.
|
||||
|
||||
**13:00** · We'll click on settings. Make sure you add the name of your vault right here under the vault list. If you're in Obsidian down in the very bottom left corner down here, you can see this is the name of the vault. So, make sure it's the same name exactly. And then over under default, you've got the templates over here. Click on the default template and make sure that you select that Second Brain vault or whatever you titled it. And then I'm having mine pull in these properties.
|
||||
|
||||
**13:23** · The source title, the source URL, the date that it was created. That's the date that I'm saving it in the web clipper, not the date that the article was actually written, and it's adding an automatic web clip tag to it. And then for the note content, it's just pulling in the content. A lot of this might actually be set for you by default, but if it's not, this is what it should look like. Under note location, we're going to change this to just say raw, because that is the folder inside of our Obsidian vault that we want it to dump it inside of.
|
||||
|
||||
**13:49** · All right, so I can close out of this, and for the very first thing I'm going to ingest, might as well ingest the instructions for how to build one of these wikis. I know it's very meta, but I want it inside of my wiki.
|
||||
|
||||
**14:01** · I'll click on my little Obsidian clipper button, and you can see the source title, LLM Wiki, we've got our source URL, the date I'm pulling this in, and the tags for web clip. And then here is all of the content of this page here.
|
||||
|
||||
**14:12** · We'll go ahead and click add to Obsidian, and we can see it added it directly inside of the raw folder here inside of Obsidian. Now, nothing's going to happen automatically. We actually need it to tell it to process the files inside of raw for anything to actually happen. But let's add a few more things.
|
||||
|
||||
**14:28** · I'm going to look through my YouTube history and ingest some of the recent videos that I've watched, like this video called how to trick your brain into becoming so disciplined your friends will be shocked by your success.
|
||||
|
||||
**14:38** · I love a lot of psychology and mindset type videos, so if I want to ingest this, I come up to my web clipper, and you can see it's going to pull in the entire transcript here. So I'm going to go ahead and click add to Obsidian, and once again, we've got another file here under raw. Now, there's one issue that's going to pop up when I pull in YouTube videos, is it's not going to properly know the channel name, because it's not automatically pulling it in into any of these properties. But I can go to codex here and give it some additional instructions.
|
||||
|
||||
**15:04** · When I save a video from YouTube using the Obsidian web clipper, and then you go and process the files, make sure it also pulls the channel name from YouTube and adds it as one of the front matter fields. All right, so let's go ahead and do that. So now let's go ahead and do a quick test. We've got two source files in here. So I'm going to jump into Codex and go ahead and tell it to process the files inside the raw folder. Let's see how well it does right now.
|
||||
|
||||
**15:32** · All right, so it took about 3 minutes to process and it created a few new sections. So let's just go ahead and pull open Obsidian here and we can see it left the original source material here, but then it started to build out the wiki of everything else. So we've got our compounding knowledge base which was clearly pulled from the explanation from Andre, discipline without willpower. This was pulled from this channel, Aaron Miller study. Let me just double check that it got the channel name correct. Yep, Aaron Merrill study, environment design.
|
||||
|
||||
**16:03** · We can see this was from the source discipline without willpower, which was one of the concepts that it saved, which came from this original video that we saved. Identity led goals, LLM wiki, temporal discounting, and temptation bundling. So we can see our wiki is starting to get built out we have our index here, our various sources, the LLM wiki and the discipline without willpower. It actually renamed it cuz it was originally called how to trick your brain into becoming so disciplined your friends will be shocked by your success, but it decided discipline without willpower was a better name for it.
|
||||
|
||||
**16:33** · We can see the concepts here and it's starting to build out. And if we look in our log, we can see what it registered in our log so far since we started building this. One thing that I actually like to do as this gets bigger and bigger is you've got this graph view here that starts really small when you first build it and over time you'll see this build out and build out and things get more interconnected with each other and it just gets really cool over time.
|
||||
|
||||
**16:58** · Now, I'm going to go seed this with some more content. I'm going to go through my watch history and pull in some of the other videos that I watched recently, using your money to be happier, the art of tripod filmmaking, how to become addicted to doing hard things, if you think you're too busy watch this, how to become a lucky person, and then build your own self-improving AI wiki in 11 minutes. I know that's very meta, but let's go ahead and import that. So, I'm just going to go through and inject every single one of these like we just saw.
|
||||
|
||||
**17:23** · I'm going to let it process them all, and then they'll all be in the Wiki, and then we'll move on to the next steps, which are building out the journal and the CRM elements that I mentioned earlier. Okay, so it's done injecting all of those videos that I just saved. It took about 6 minutes here, and this is what my Obsidian looks like now. You can see all of the assets of stuff that I ingested into it, and the Wiki is getting built out quite a bit more. We've got our index here, and as you can see, the index is also getting built out more as well.
|
||||
|
||||
**17:50** · If I click into like Hermes agent here, we can see we've got key ideas from this original video plus related content inside of our Wiki. So, Codex capabilities, I click on this one, and it jumps to the video from Riley Brown and the details around that one. Again, this is the very, very simple, basic setup of Carpathys' LLM Wiki. Now, if I come into Codex again, we can essentially chat with the Wiki. So, I come to my second brain folder, click on new chat, and I can ask questions.
|
||||
|
||||
### Zapytania do Wiki
|
||||
|
||||
**18:19** · Like, what are some tips for motivation when I don't feel like doing the hard task today? I know I saved a couple videos about this exact topic, and we can see it's already saying, "I'll treat this as a Wiki query. First, I'm checking the vault index, then I'll answer from anything already captured and add the reusable bit back into the Wiki if it isn't there yet." Here's our final response. When you don't feel like doing the hard task, don't wait for motivation to arrive first. Treat it as a task design problem. Make the first few minutes smaller, easier, and more rewarding. Try this.
|
||||
|
||||
**18:47** · Gives me a handful of tips, and this was all pulled and grounded from the Wiki, but it also updated the Wiki based on the question that I asked. You can see that it changed the index.md file, the log.md file, and the Wiki motivation for hard tasks. So, opening up my Obsidian vault here again, looking in my log, we can see that it actually logged this query, motivation when avoiding a hard task, answer to query about motivation, and it even updated the index with it.
|
||||
|
||||
**19:13** · And it created motivation for hard tasks and linked back to the original sources that it found this information from. So, as you ask questions, the wiki further and further and further builds out based on the questions you were asking. Now, there's a few things that I want to do to clean this up a little bit and make it slightly more useful for me cuz right now, once it processes something, it just leaves it in this raw folder, and this is just going to build up and build up. And so, what I want to do is under this raw folder here, I'm going to go ahead and create a new folder, and I'm going to call it processed.
|
||||
|
||||
### Ręczna aktualizacja agenta
|
||||
|
||||
**19:44** · Whenever it processes one of these files and adds it to the wiki, I want it to move it to the processed folder, so I know that that has already been ingested. So, now that I've got this processed folder, I can simply come down to my agents file here and then tweak what happens when the file is processed. So, if I come down here, we've got operations ingest when the user adds a source and asks the LLM to process it, read the source from raw, create or update wiki pages, update relevant entity concept topic overview synthesis or comparison pages, update index.md, append an entry to log.md.
|
||||
|
||||
**20:18** · Well, now I can just add a number six and say move the source file from the root raw directory to raw/processed.
|
||||
|
||||
**20:27** · By adding that extra bit to the little prompt here, now it's going to go through all these steps, but then move it into the processed folder. It also misunderstood me when I said to add the channel name. It thought I wanted it to add the channel name to the actual wiki generated page, but I wanted it to add the channel name to the original source. That's what makes the most sense to me.
|
||||
|
||||
**20:46** · So, I'm going to come to my agents section here and just tweak that as well. So, right now it says for YouTube videos clipped with Obsidian Web Clipper, also open or inspect the YouTube source URL and add the channel name to the generated wiki page front matter. But instead of that, I'm going to say add the channel name to the original source page front matter. I I want it to link back to the original source. So, I'm going to add a step right after step three here and say cross-link any wiki pages generated or updated to the original source page.
|
||||
|
||||
**21:15** · Basically, I don't want these pages orphaned. If there's a new wiki page here, I want it to link to the original page here. So, that's the manual way to update the agents.md file, but you can also do it by prompting it inside of Codex. So, if I come to my second brain project, create a new chat here, I can give it instructions on additional things that I want to happen. So, I mentioned my journal and I mentioned my CRM. So, let me go ahead and build the bones for that here. I will close these folders to clean everything up. I will create a new folder called journal and a new folder called CRM.
|
||||
|
||||
### Umożliwienie sztucznej inteligencji aktualizacji agenta i budowanie dziennika/CRM
|
||||
|
||||
**21:46** · Now, I can come to Codex and say update the agents.md file to handle these items. Number one, if I start a chat with journal, add the text of that chat and subsequent conversation as a new md file within the journal folder. The entire conversation should be added to the markdown file.
|
||||
|
||||
**22:05** · Create an index file in the journal folder that's similar to the wiki index file. Each new journal entry gets added to the index file. Decide on a short title for the journal entry based on the contents of the journal and use the date and the title as the journal entry file name. Add the date and title to the index and link to the entry. Also, log the journal entry title and short summary in the log.md file. Your response to my journal entry should be grounded in content from the wiki in the same way you view the index and respond to my chat questions based on what's in the wiki.
|
||||
|
||||
**22:34** · Provide advice and insights to my journal entries based on what's available in the wiki, as well as your own LLM knowledge. Provide helpful advice, insights, guidance, tactics, and ideas using what you know, along with what's available from the wiki, past journal entries, and the CRM. So, when I journal, I want it to look in the wiki, find information that's helpful to what I just journaled on. I want it to look in past journal entries to see if there's anything relevant I've journaled on in the past, and I want it to look at my CRM and see if there's conversations I've had with people about what I'm journaling about, too, for the CRM.
|
||||
|
||||
**23:03** · If I tell you I'm giving you information for the CRM, either update the person in the CRM or add the person to the CRM. CRM file should always be a person's name. I will share details about a person, their name, contact details I have for them, details about where or how we met, things that I know about them, etc.
|
||||
|
||||
**23:21** · Creator, update the contact record in the CRM with whatever details I give you. In the CRM folder, create an index file similar to our other index files with the name of the people in the CRM listed in alphabetical order and a short bio of what information I have about that person. This will allow me to ask questions about contacts that are inside the CRM.
|
||||
|
||||
**23:38** · I want it to update these two things in our agents.md file, which will make it so that whenever I chat with my second brain project here in Codex, it's either one going to answer the question that I asked it using the sort of query task that's already built into the agent, it's going to handle it as a journal if I preempt it with journal here, or if I tell the chatbot that it's for the CRM, it will update the CRM section.
|
||||
|
||||
**24:02** · So, I'm going to let it go ahead and update our agents.md file, create the various index files, and that should build out the system for these elements. Okay, so we can see that it updated the agents.md file with our journal rules, our CRM rules, and if we open up Obsidian once again, I can open my journal folder and you can see we've got an index with date entry and summary, and if I open up my CRM, we've got our index with the person and the summary, and where most of the updates happened was this agents.md file. So, now below the wiki section, we have a journal section.
|
||||
|
||||
**24:34** · It built all the rules that I just asked it to build for me, and then we also have our CRM section.
|
||||
|
||||
**24:40** · So, it created all the rules for the CRM section now. Let's jump into Codex one more time and let's test this out. I'm just going to say add to CRM, and then I'll put Matthew Berman, and then I'll just put met at Qualcomm event in 2024, hung out at CES in 2025, got lunch during TechCrunch disrupt in 2025, and then I would obviously add whatever sort of contact details I have about him, but no point in doing that on camera.
|
||||
|
||||
### Testowanie CRM
|
||||
|
||||
**25:12** · I'll just tell it to add that to the CRM, and we can see updating the CRM record for Matthew Berman, creating a new record, and it says, "Great, I created that." If I look in my Obsidian here, we can see under CRM, we now have a Matthew Berman in CRM here with our summary, no contact details provided, how we met, relationship context, and you know, other stuff that's still empty right now. And then if I look at my index, we can see it added the person, Matthew Berman, and a quick summary there. It also added it to the log down here that the CRM was updated.
|
||||
|
||||
**25:40** · But the idea being is, let's say I'm going to a conference, and I bump into somebody, and I'm like, "Oh, shoot, where did we meet?" I can jump into my second brain and say, "Where did I meet Matthew Berman again?" I'll check the vault and CRM records. You met Matthew Berman at Qualcomm event in 2024 according to your CRM notes. So, a really good way to reference information later. I'm going to go ahead and make a pretend journal.
|
||||
|
||||
### Testowanie dziennika
|
||||
|
||||
**26:03** · So, what I'll do is I'll click on a new chat inside of my second brain project here, and I'll start it with journal, and then I'll go to another line, and I'll just brain dump some thoughts. So, this is just a simple demo journal entry, but you know, it's got some reality to it. I have a ton of ideas for videos, but I decide not to make them because I'm worried they won't get a good view count.
|
||||
|
||||
**26:22** · I also talk about how I know how to write titles that will get a lot of clicks, but I also hate the whole clickbait thing, so I end up making titles that I know will get less clicks because they're more literal to what the video is about, and I constantly grapple with making videos that will get a lot of clicks, but knowing I'll get hate in the comments because they're too click-baity versus making videos that the title is very literal, so I won't get the hate comments, but I'll also get a lot of less views.
|
||||
|
||||
**26:50** · And that's something that I grapple with, and I know pretty much every YouTuber grapples with. And so, that's my short journal entry. So, let's go ahead and submit that and see what happens. I'll treat this as a journal entry and grab the response in the vault first. Going to read the indexes, look for relevant prior notes around creating video attention, then I'll write the journal file before answering. The vault has several creator strategy pages. I'm pulling those in rather than answering from a blank slate. There aren't prior journal entries yet, and the CRM doesn't appear relevant to this one. So, it's just pulling from the wiki. Okay, and check out this journal response here.
|
||||
|
||||
**27:20** · I think there are two fears braided together here, creative integrity and channel safety. One part of you does not want to betray the video with a title that feels gross. Another part is afraid that a few underperformers will teach YouTube not to trust you. The creator notes in the vault push back on the second fear. YouTube value of death and creator persistence both frame visible metrics as lagging indicators. A few lower view videos are not a downward spiral, blah blah blah. So, it is actually grounding the response to my journal in what is existing in the wiki.
|
||||
|
||||
**27:49** · And then it actually goes on to just give a response that ChatGPT would normally give, but it's pulling from both the knowledge built into the LLM as well as the knowledge in the wiki. So, that's all working exactly as intended. And then if I want to pop open Obsidian here, I can open my journal folder, and we can see here is my journal entry. Here is what the assistant replied with.
|
||||
|
||||
**28:10** · Here's some synthesis, and here's some related content about what I'm journaling about. If I look at my index here, it automatically logged the date, the entry title, and a quick like one paragraph summary of what my journal entry is about. Now, I want some of this to happen on autopilot. I don't want to have to jump into Codex constantly and tell it to process everything that I saved in here. And there's an easy solution for that. Before I show you, I'm going to do one thing.
|
||||
|
||||
**28:34** · I'm going to go ahead and clean up my existing Obsidian wiki because, remember, I want these to all get moved into processed, and I also want it to save the YouTube channel name up here in the front matter. So, I'm going to tell it, "Please reprocess all of the files in the raw directory following the recent updated instructions on how to process them." So, I'm going to let that process. It's going to clean up my wiki real quick.
|
||||
|
||||
**29:01** · All right, now that that's finished and my Obsidian vault is cleaned up and we can see all of my videos have been moved to process and it added the channel name to the original videos here. Let's automate some of this. So, in Codex here, you've got a feature called automations. This is where you can set it up to do recurring tasks. So, if I click into automations here, select new automation. For automation title, we'll call it process second brain raw files. For work tree, I'm going to set it on local so it runs directly in the selected project. For our project, we're going to select second brain. Here, we'll select when we want it to run.
|
||||
|
||||
### Automatyzacja linkowania Wiki
|
||||
|
||||
**29:33** · I'm going to go ahead and set mine to hourly, but you can do it at whatever cadence you want. And I'm just going to say if there are any unprocessed files inside the raw directory, please process them now. For the model, I'm going to set it as a GPT-5.5.
|
||||
|
||||
**29:49** · I recommend just using the strongest model you have available. I'm going to set it on high reasoning and I will create this automation. Now, it's going to run every hour, see if there's anything in my raw folder that's unprocessed, and then it will process it. And that's it. That's the whole process now. Whenever I come across stuff I want to save, I just use the Obsidian web clipper and clip it into my raw folder automatically. And every hour, it's going to ingest that and turn it into one of the wiki pages. If I want to add somebody to my CRM, I just open up Codex, create a new chat inside of this project, and add the CRM details.
|
||||
|
||||
**30:21** · If I feel like journaling right now, I can journal straight into my second brain, and it will ground the response in what's available in my wiki, past journals, and within my CRM. If you want an extra layer of backup, you can also go to GitHub, create a new repository on GitHub. I'm going to go ahead and call this one second brain. I'm going to set this to private, so it's only available to me, and I'll create the repository.
|
||||
|
||||
### Tworzenie kopii zapasowej na GitHubie
|
||||
|
||||
**30:43** · Now, if I copy this URL, jump back over to Codex here, I can say commit this current version to my private GitHub repo here. Pasting the URL of the private GitHub repo I just created, and then go ahead and submit it. Now, I've previously attached the GitHub plugin, so it should just work out of the box.
|
||||
|
||||
**31:02** · You can see I'm already synced with GitHub, but if you haven't done that already, just add the GitHub plugin and go through the motions to get that set up, and you should be good to go. And it went ahead and pushed it to GitHub, so if I open my browser here and refresh, we can see everything I've created is all saved on GitHub now. If I jump back into Codex, I can go to my automation and edit this automation and say if there are any unprocessed files in the raw directory, please process them now.
|
||||
|
||||
**31:28** · Once everything is processed, please commit and push the current version of the directory to the main branch on GitHub. So, now it's going to process everything in the raw directory, and then once it's done processing, it's going to update GitHub so that backup is constantly happening every hour. And there you have it. There's the whole second brain process. Not only do you have a wiki of all of the information you're finding and saving from around the internet, but now you have a journal and a CRM that's built on top of it as well.
|
||||
|
||||
### Podsumowanie i końcowe przemyślenia
|
||||
|
||||
**31:51** · And if you ever want to tweak how it operates, you just open up Obsidian, which is your visibility layer to see how everything is built, and you go into agents.md, and you just tweak the instructions. This is all just prompts at the end of the day. You just change how it gets prompted. And in the short amount of time that we've been working on it, this is what our graph view looks like now, and we can start to see all of these things interconnect with each other a little bit more. Do this for a few days and a few weeks, and the next thing you know, you have a vault that looks like this.
|
||||
|
||||
**32:19** · Uh yeah, pretty insane, crazy vault that just has a ton of information saved inside of it. So, I know that video was long. There was a lot of details. I wanted to make sure it was very clear and you got the whole process, and I didn't skip any steps, but I want to show you how I've been building this sort of second brain concept that I can journal on top of that I have a CRM on top of where all of the wiki elements are interconnected.
|
||||
|
||||
**32:42** · You can even dial it in more by building in separate folders and telling it to break out people from different pieces of content and break out companies from different pieces of content and really, really dial in that wiki more and more and more. But really, really cool concept. All you really need is Obsidian and Codex. Anthropic's co-work or Claude code also works. Whatever your sort of front-end chat platform of choice is.
|
||||
|
||||
**33:07** · I've been really liking Codex lately, so that's what I've been using. But yeah, go build it. It's really, really cool and a lot simpler than you think and over time it just gets smarter and smarter and smarter and more and more powerful. So, that's what I got for you.
|
||||
|
||||
**33:20** · This isn't like my normal videos. I normally make end of week news breakdowns where every single Friday I break down all of the news that happened in the AI world for the week. I drink from the fire hose all week, keep up with all of the news, keep myself completely looped in so that other people don't have to feel overwhelmed.
|
||||
|
||||
**33:37** · I'll take on the overwhelm and just report what I think is the most interesting. I put those videos out every single Friday. If stuff like that, as well as tutorials like this, are something that interest you, maybe consider liking this video and subscribing to this channel. It really, really helps me out a lot. But again, that's what I got. Thanks for hanging out with me, nerding out with me. Hopefully, I'll see you in the next one.
|
||||
|
||||
**33:55** · Bye-bye.
|
||||
+215
@@ -0,0 +1,215 @@
|
||||
---
|
||||
title: "I rebuilt Karpathy's LLM Wiki. Here's what's missing from the original."
|
||||
source: "https://theaioperator.io/p/i-rebuilt-karpathys-llm-wiki-heres"
|
||||
author:
|
||||
- "[[Eugeniu Ghelbur]]"
|
||||
published: 2026-04-29
|
||||
created: 2026-06-10
|
||||
description: "Looking for Karpathy's original LLM Wiki gist? It's in here. Plus the five things a working second brain does that the original doesn't, shipped as 34 open-source slash commands."
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
### Szukasz oryginalnego gistu LLM na Wiki Karpathy'ego? Jest tutaj. Do tego pięć rzeczy, które robi działający drugi mózg, a oryginał nie, wydane jako 34 otwartoźródłowe komendy ukośnicze (ukoś).
|
||||
|
||||
Codziennie korzystasz z Claude'a. Każda sesja zaczyna się od zera. Wyjaśniasz wszystko na nowo, co już wczoraj wyjaśniłeś. Rozmowa się kończy. Wszystko znika.
|
||||
|
||||
|
||||
|
||||
Szybka orientacja. Jeśli przyszedłeś tutaj szukając oryginalnego gistu LLM Wiki Karpathy'ego, oto on: [oryginalny gist LLM Wiki Karpathy'ego.](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) Dodaj to do zakładek, to nadal najczystszy punkt startowy. Poniżej znajduje się wersja, którą na nim zbudowałem – drugi mózg, który sam się przepisuje, otwartoźródłowy, żebyś mógł go sklonować: [https://github.com/eugeniughelbur/obsidian-second-brain](https://github.com/eugeniughelbur/obsidian-second-brain)
|
||||
|
||||
---
|
||||
|
||||
## TL; DR
|
||||
|
||||
- Wiki LLM Karpathy'ego opisuje właściwy wzorzec, ale na poziomie intencji: integruj nowe źródła, okresowo usuwaj kłaczki, traktuj wiki jako źródło główne. To jest plan koncepcyjny, a nie konfigurowalny szczegół.
|
||||
- Różnica między treścią a działającym systemem tkwi w mechanice: jak integracja radzi sobie ze sprzecznościami, jak lint działa bez twojego pytania i dla kogo wiki jest faktycznie napisane.
|
||||
- Ta odbudowa uzupełnia specyfikację na pięciu osiach: określone mechaniki integracji, automatyczne uzgadnianie sprzeczności, nieproszona synteza, zaplanowane agenty konserwacyjne oraz notatki napisane z myślą o odzyskiwaniu przez AI, a nie przez człowieka.
|
||||
- Najbardziej sprzeczną z tych pięciu jest zasada AI – najpierw Vault: notatki zaprojektowane tak, by przyszły Claude mógł je przeczytać w 10 sekund, a nie tak w przyszłości – można je przeczytać ponownie w 30 minut. Ogólny tekst Karpathy'ego traktuje wiki jako służącą zarówno ludziom, jak i LLM; Ta przebudowa odwraca to.
|
||||
- Implementacja open-source jest dostępna jako umiejętność Claude Code z 31 komendami ukośnika i 4 zaplanowanymi agentami.
|
||||
|
||||
---
|
||||
|
||||
## Jaki jest wzór LLM na Wiki Karpathy'ego?
|
||||
|
||||
**LLM Wiki Karpathy'ego to wzorzec bazy wiedzy opublikowany jako publiczna informacja na początku 2026 roku.** Wkładasz źródła do folderu. LLM je czyta, wyodrębnia byty i koncepcje na strony wiki oraz łączy wszystko. Na przyszłe pytania odpowiada się z wiki, a nie z nowego wyszukiwania w internecie.
|
||||
|
||||
Pełny schemat tkwi w [sercu Karpathy'ego](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f). Główna intuicja jest trafna i ważna: **wiki to produkt, czat to tylko interfejs**. Istnieją już odwołania krzyżowe. Synteza już odzwierciedla wszystko, co zostało przeczytane. Wiedza narasta jak zainteresowanie, zamiast być regenerowana od zera za każdym razem, gdy otwierasz czat.
|
||||
|
||||
To był właściwy punkt wyjścia. To także miejsce, gdzie większość implementacji się kończy. Na rok 2026-04 każda publiczna implementacja Karpathy-Wiki, którą przeglądałem (sześć na GitHubie, dwie na Substacku, jedna na dev.to), traktuje oryginalną koncepcję jako kompletną specyfikację. Żadne z nich nie rozwiązuje problemów, które pojawiają się, gdy twoja wiki przechodzi przez kilkaset źródeł.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Dlaczego konceptualny plan nie jest działającym drugim mózgiem
|
||||
|
||||
**Wzór Karpathy'ego jest z założenia wyłącznie do dołączenia.** Każde wejście tworzy nowe strony i dodaje odwołania; istniejące strony pozostają zamrożone. To działa dla pierwszych 50 do 100 źródeł. Poza tym trzy tryby awarii się kumulują: roszczenia stają się przestarzałe, sprzeczności narastają szybciej, niż je rozwiązujesz, a wykres krzyżowy staje się zbyt gęsty, by można było go ręcznie poruszać.
|
||||
|
||||
Wiki zbudowane w ten sposób to w zasadzie dziennik z linkami wewnętrznymi. Rejestruje to, co czytasz, ale nie aktualizuje tego, co wcześniej wierzyłeś. Jeśli wejdziesz film na YouTube o osobie, która zmieniła pracę, otrzymujesz nową stronę źródłową z nowym faktem oraz link zwrotny na jej istniejącej stronie. Strona tej osoby nadal opisuje ją w poprzedniej pracy. Przyszły Claude czytający stronę widzi oba, nie ma sposobu, by wiedzieć, który jest aktualny, i daje ci zawieszoną odpowiedź.
|
||||
|
||||
Naprawa jest konstrukcyjna. Prawdziwy drugi mózg musi przepisywać, godzić, syntetyzować, planować i przepisywać dla AI. Pięć przedłużeń. Poniżej.
|
||||
|
||||
## Pięć rzeczy, które musi robić działający drugi mózg, a oryginał nie
|
||||
|
||||
|
||||
|
||||
### 1\. Ingest musi przepisywać, a nie tylko dodawać
|
||||
|
||||
**Prawdziwe przepisania wywiadu.** Kiedy wgrywam film na YouTube o kimś, kto już jest w moim skarbcu, strona tej osoby jest aktualizowana. Status startupu zmienia się z "rozważam dołączenie" na "dołączył w marcu 2026". Teza, która była "spekulacją", staje się "potwierdzona". Stara wersja jest zachowana jako datowany wpis poniżej, nie usunięta, ale aktualny stan strony odzwierciedla najnowsze dowody.
|
||||
|
||||
To jest różnica między rozwijającą się wiki a wiki, która się uczy. Bazy wiedzy tylko do dołączania stają się niewidoczne i niewidoczne, bo nic w ich czytaniu nie mówi, że fakt pochodzi z 2024 roku. Przepisywanie zmusza każdą stronę, by na górze była najlepsza odpowiedź.
|
||||
|
||||
|
||||
|
||||
### 2\. Sprzeczności muszą być rozwiązywane, a nie tylko oznaczane
|
||||
|
||||
**Wzorzec Karpathy'ego wytyka sprzeczności podczas spożycia. Rozwiązujesz je ręcznie.** W małej wiki to działa. W skarbcu dłuższym niż kilkaset stron sprzeczności gromadzą się szybciej, niż zdążysz je rozwiązać. Wiki staje się wewnętrznie niespójna, a przyszły Claude czerpiący z niej otrzymuje sprzeczne dane wejściowe i generuje zabezpieczone wyniki.
|
||||
|
||||
Rozwiązaniem jest automatyczne uzgadnianie. Dedykowany proces skanuje skarbiec, znajduje twierdzenia sprzeczne ze sobą na stronach i rozstrzyga je według aktualności źródła, autorytetu źródła oraz wyraźnych poziomów zaufania. Najbardziej aktualne, najlepiej zweryfikowane i najwyższe zaufanie wygrywa twierdzenie. Przegrany roszczenie jest archiwizowane wraz z wyjaśnieniem, dlaczego zostało zastąpione. Skarbiec pozostaje wewnętrznie spójny bez twojej pilnowania.
|
||||
|
||||
### 3\. Wzory muszą być ujawnione bez pytania
|
||||
|
||||
**Wiki Karpathy'ego odpowiada na pytania, które mu zadasz. Nie może powiedzieć ci o wzorcach, które zauważył, a ty tego nie zrobiłeś.** To ogromna zmarnowana szansa. Połowa wartości bazy wiedzy to to, że LLM mówi ci: "wspomniałeś o tym pomyśle siedem razy w pięciu różnych notatkach i nigdy go nie nazwałeś. Oto o co chodzi."
|
||||
|
||||
Działający drugi mózg samodzielnie wykonuje syntezę. Przeszukuje skarbiec w poszukiwaniu nienazwanych, powtarzających się motywów, ukrytych sprzeczności między deklarowanymi wartościami ludzi a ich rzeczywistymi decyzjami oraz powiązań między projektami, które wydają się niepowiązane. Pisze strony syntezy bez wywołania wywołania. Skarbiec mówi ci, co zauważył w tobie.
|
||||
|
||||
### 4\. Konserwacja musi być planowana, a nie na żądanie
|
||||
|
||||
**Wzór Karpathy'ego działa tylko wtedy, gdy go zaproponujesz.** Każda operacja odbywa się na żądanie. To oznacza, że konserwacja odbywa się tylko wtedy, gdy o niej pamiętasz, a więc nigdy się nie zdarza. Skarbce gniją w ciszy.
|
||||
|
||||
Rozwiązaniem są agenci na zaplanowanym poziomie. Nocny proces zamyka dzień, porządkuje luźne pomysły, aktualizuje dzienną notatkę. Cotygodniowy proces wykonuje pełne przejście uzgadniające i przejście syntezy. Kontrola stanu zdrowia znajduje osierocone notatki, martwe linki i strony, które stały się nieaktualne. Budzisz się w skarbcu, który już odrobił pracę domową, i nigdy sam nie uruchamiasz komendy konserwacyjnej.
|
||||
|
||||
### 5\. Notatki muszą być pisane dla AI, a nie dla ludzi
|
||||
|
||||
**To najbardziej kontrariański punkt i główny punkt tego artykułu.** Każda tradycja zarządzania wiedzą osobistą (Zettelkasten, Budowanie drugiego mózgu, [wieczne notatki](https://notes.andymatuschak.org/Evergreen_notes)) optymalizuje notatki do czytania przez człowieka. Wzorzec Karpathy'ego podąża za tą konwencją. Strony wiki wyglądają jak artykuły z Wikipedii, napisane płynną prozą, zaprojektowane tak, by człowiek mógł je pobieżnie czytać.
|
||||
|
||||
Założenie jest błędne. **Nie czytasz własnych notatek.** LLM tak. Powinny być więc zoptymalizowane do wyszukiwania LLM, a nie do czytania przez człowieka. To jest zasada AI z Vault First i jest to największe odblokowanie w tej odbudowie.
|
||||
|
||||
## Zasada AI – Pierwsza Skarbca
|
||||
|
||||
**Notatki zaprojektowane do wyszukiwania AI pokonują notatki przeznaczone do czytania przez człowieka, w każdym sejfie, gdzie LLM wykonuje większość czytania.** Każda notatka spełnia siedem zasad: preambuła, maszynowo czytelna część okładkowa, obowiązkowe wikilinki, markery aktualności dla zewnętrznych twierdzeń, zachowane adresy URL dosłownie, poziomy zaufania tam, gdzie to możliwe, oraz samodzielny kontekst, dzięki któremu notatka może być dostępna samodzielnie.`## For future Claude`
|
||||
|
||||
```markup
|
||||
---
|
||||
type: person
|
||||
name: "Andrej Karpathy"
|
||||
date: 2026-04-29
|
||||
tags: [ai-researcher, llm-wiki-pattern]
|
||||
ai-first: true
|
||||
confidence: high
|
||||
---
|
||||
|
||||
## For future Claude
|
||||
Andrej Karpathy is the originator of the LLM Wiki pattern, published as a public
|
||||
gist in early 2026. He proposes that LLMs should maintain a living markdown wiki
|
||||
as the primary knowledge artifact, not a vector store. Use this page as the
|
||||
canonical reference when reasoning about the LLM Wiki pattern.
|
||||
|
||||
## Key claims
|
||||
- The wiki is the product. Chat is the interface (as of 2026-02, karpathy gist).
|
||||
- Knowledge should compound across sessions. Source: same.
|
||||
- Cross-references should already exist when a question is asked. Source: same.
|
||||
|
||||
## Related
|
||||
[[LLM Wiki Pattern]] · [[Obsidian Second Brain]] · [[Append vs Rewrite]]
|
||||
```
|
||||
|
||||
Ta strona jest trudniejsza do przejrzenia dla człowieka niż zwykła notatka w stylu Wikipedii. LLM jest znacznie szybszy w pobieraniu, analizowaniu i rozumowaniu. Przednia część informuje LLM, jaki to rodzaj notatki w trzech linijkach. Preambuła "Na przyszłość Claude" mówi mu, czy warto czytać resztę, w kolejnych trzech zdaniach. Wskaźniki świeżości mówią mu, co ma zweryfikować. Wikilinki mówią, dokąd iść dalej.
|
||||
|
||||
Odwrócenie jest niewygodne dla każdego, kto zainwestował w piękny skarbiec z Obsydianu. To także jedyna rzecz, która sprawia, że sejf powyżej kilkuset nut faktycznie się kumuluje w workflow opartym na LLM. Gdy przestaniesz udawać, że przeczytasz swoje notatki ponownie, możesz je napisać w sposób, który będzie się kumulował dla systemu, który to zrobi.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Jak to się ma do oryginalnej wersji Karpathy'ego i v2 Rohitg00
|
||||
|
||||
**Ta przebudowa jest trzecią wersją publicznego wzoru LLM Wiki.** Sedno Karpathy'ego (2026-02) to v1: pobieranie tylko do dodawania, ręczne kłaczki, notatki czytelne dla człowieka. [rohitg00 w LLM Wiki v2](https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2) (2026-03) dodała punktowanie pewności siebie, zastąpienie przestarzałych twierdzeń i wykrywanie sprzeczności. Ta przebudowa dodaje trzy rzeczy, których v2 nadal nie posiada: zaplanowanych agentów, automatyczną syntezę oraz strukturę nut opartą na AI.
|
||||
|
||||
Żadna z istniejących publicznych implementacji nie oferuje działającej integracji z kodem Claude jako umiejętność poleceń ukośnikowych. Żaden z nich nie dostarcza prawdziwej specyfikacji notatek stawiających na AI w pierwszym miejscu. Nie wysyłają agentów zaplanowanych. Repozytorium stojące za tym artykułem tak ma. Jest open-source, posiada licencję MIT i jest dostępny na GitHub: [eugeniughelbur/obsidian-second-brain](https://github.com/eugeniughelbur/obsidian-second-brain).
|
||||
|
||||
```markup
|
||||
## What I got wrong
|
||||
|
||||
When I first shipped \`/research-deep\` and ran it against my own vault, the command wrote
|
||||
three different kinds of garbage into the synthesis note. I had assigned the wrong
|
||||
Perplexity model to the synthesis call, so the API returned a hardcoded 10,000-word
|
||||
academic report instead of following the markdown structure I asked for.
|
||||
The reasoning model I switched to wrapped its internal deliberation
|
||||
in \`<think>...</think>\` blocks, and those tags ended up saved to the vault verbatim.
|
||||
And the frontmatter meant to log which queries had run was instead saving stringified
|
||||
Python dictionaries.
|
||||
|
||||
Three small bugs, but together they meant the command designed to make my vault smarter
|
||||
was making it dumber on its first run. I only caught it because I happened to test on a
|
||||
real topic in my own vault and actually read the output. If I had trusted the test less
|
||||
and the implementation more, the broken version would have shipped, and every other vault
|
||||
running the skill would have inherited the same junk.
|
||||
|
||||
The fix took an afternoon. The lesson took longer. **The right level of automation
|
||||
is not "everything always," it is "everything reversibly."** A second brain that
|
||||
rewrites itself is only valuable if you can see exactly what it changed and roll
|
||||
back when it gets it wrong. Every scheduled agent in this rebuild now logs its changes
|
||||
to a daily diff note and waits 24 hours before any change becomes permanent.
|
||||
The first version did not. That is the difference between a tool I trust on my own vault
|
||||
and one I would never let near it.
|
||||
```
|
||||
|
||||
**The general lesson is that the right level of automation is not “everything always,” it is “everything reversibly.”** A second brain that rewrites itself is only valuable if you can see what it changed and roll back when it gets it wrong. Every scheduled agent in this rebuild logs its changes to a daily diff note and waits 24 hours before any change becomes permanent.
|
||||
|
||||
---
|
||||
|
||||
## Frequently asked questions
|
||||
|
||||
### What is the LLM Wiki pattern?
|
||||
|
||||
The LLM Wiki pattern is a knowledge-base architecture proposed by Andrej Karpathy in early 2026. You drop sources into a folder, an LLM reads them and writes wiki pages, cross-references entities, and answers future questions from the wiki rather than from fresh web searches. The wiki is a persistent artifact that compounds across sessions, instead of being regenerated each chat.
|
||||
|
||||
### How is this different from RAG?
|
||||
|
||||
**RAG retrieves chunks of source documents at query time and feeds them to an LLM as context.** The LLM Wiki pattern flips this: an LLM reads sources once, distills them into structured wiki pages, and the wiki itself becomes the retrieval target. The result is faster, cheaper queries, plus cross-references that already exist instead of being inferred at query time. This rebuild adds write-back so the wiki stays current with new sources.
|
||||
|
||||
### Do I need to know how to code to use this?
|
||||
|
||||
No. The implementation is a Claude Code skill that ships as 31 slash commands. You install it once with a shell script, then operate it with commands like and from any Claude Code session. The vault is plain markdown, so Obsidian works on top of it natively.`/obsidian-save` `/obsidian-ingest`
|
||||
|
||||
### Will this break my existing Obsidian vault?
|
||||
|
||||
No. The skill never deletes or modifies notes destructively without explicit confirmation. Existing notes are left untouched. New notes follow the AI-First Vault Principle. A health-check command flags pre-AI-first notes so you can update them on your own schedule. Every scheduled agent writes to a daily diff log so you can see what changed overnight and revert if needed.
|
||||
|
||||
### Does it work without Claude?
|
||||
|
||||
The current implementation is built for Claude Code, but the AI-First Vault Principle and the slash-command interface are portable. The vault format is plain markdown with YAML frontmatter, so the underlying knowledge base is model-agnostic. As of 2026-04 the production-tested integration is Claude Code only.
|
||||
|
||||
### What does it cost to run?
|
||||
|
||||
The 26 vault commands work without any API keys: only your Claude Code subscription is required. The 5 research commands require API keys for xAI Grok and Perplexity. Approximate per-call costs as of 2026-04: around $0.05, around $0.13, around $0.04, around $0.40 to $0.80, around $0.04.`/x-read` `/x-pulse` `/research` `/research-deep` `/youtube`
|
||||
|
||||
---
|
||||
|
||||
## Key takeaways
|
||||
|
||||
- Karpathy’s LLM Wiki pattern is a brilliant foundation. The wiki is the product, chat is the interface, knowledge compounds across sessions.
|
||||
- Append-only ingest fails past a few hundred sources. Stale claims, unresolved contradictions, and missed patterns accumulate invisibly.
|
||||
- The five extensions that turn a Karpathy-style wiki into a working second brain are write-back, reconciliation, unsolicited synthesis, scheduled agents, and AI-first notes.
|
||||
- The AI-First Vault Principle is the most important of the five. Notes designed for AI retrieval beat notes designed for human reading in any vault where the LLM does most of the reading.
|
||||
- Automation has to be reversible. Every scheduled agent in this rebuild writes a diff log and waits 24 hours before any change becomes permanent.
|
||||
- The open-source implementation is live on GitHub and runs as a Claude Code skill with 31 slash commands. Install in two minutes.
|
||||
|
||||
> **If Karpathy’s LLM Wiki is a knowledge base you maintain with an LLM, this rebuild is a knowledge base that maintains itself.**
|
||||
|
||||
---
|
||||
|
||||
## Further reading
|
||||
|
||||
- [Karpathy’s original LLM Wiki gist](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) (2026-02): the canonical pattern.
|
||||
- [rohitg00’s LLM Wiki v2 gist](https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2) (2026-03): adds confidence and supersession.
|
||||
- [Penfield Labs on what’s missing from Karpathy’s wiki](https://dev.to/penfieldlabs/what-karpathys-llm-wiki-is-missing-and-how-to-fix-it-1988): typed-link extension.
|
||||
- [Andy Matuschak on evergreen notes](https://notes.andymatuschak.org/Evergreen_notes): the human-first PKM tradition this rebuild departs from.
|
||||
- [obsidian-second-brain on GitHub](https://github.com/eugeniughelbur/obsidian-second-brain): the open-source implementation.
|
||||
|
||||
---
|
||||
|
||||
**About the author**
|
||||
|
||||
Eugeniu Ghelbur is an AI Automation Engineer at Single Grain, where he builds production AI systems for marketing and sales workflows. He ships open-source Claude Code skills and writes about AI knowledge management at [ghelburlabs.substack.com](https://ghelburlabs.substack.com/). The obsidian-second-brain skill described in this article is live on GitHub at [github.com/eugeniughelbur/obsidian-second-brain](https://github.com/eugeniughelbur/obsidian-second-brain) and has been used in production since 2026-03.
|
||||
+173
@@ -0,0 +1,173 @@
|
||||
---
|
||||
title: "Jak zbudować drugi mózg, któremu naprawdę możesz zaufać, korzystając z myKG i Obsidianu"
|
||||
source: "https://medium.com/@senol.isci/how-to-build-a-second-brain-you-can-actually-trust-52ac621188b7"
|
||||
author:
|
||||
- "[[Senol Isci]]"
|
||||
- "[[Ph.D.]]"
|
||||
published: 2026-06-08
|
||||
created: 2026-06-11
|
||||
description: "More"
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
*LLM może przekształcić folder notatek w graf wiedzy jednym poleceniem. Trudniejsze nie jest jej zbudowanie. Trudne jest zaufanie do tego.*
|
||||
|
||||
## Problem
|
||||
|
||||
Pewnie już widziałeś to demo. Wskazujesz model językowy na folder z notatkami w Markdown, a on oddaje ci wykres wiedzy: byty, relacje, sieć, którą możesz przeszukiwać. Wygląda imponująco.
|
||||
|
||||
Potem próbujesz go faktycznie użyć, a jedno pytanie cię zatrzymuje: **które z tych połączeń są w ogóle prawdziwe?**
|
||||
|
||||
To pytanie jest trudne, ponieważ prosty pipeline "LLM czyta moje notatki, potem buduje bazę wiedzy" zwykle zawodzi na dwa sposoby, a oba błędy są ciche. Po pierwsze, **wymyśla rzeczy**: model określa relację, której notatki nigdy nie powiedziały, a teraz to fałszywe twierdzenie wygląda dokładnie tak samo jak prawdziwe. Po drugie, traci **pewne rzeczy**: model natrafia na fakt, którego nie potrafi sklasyfikować, i zamiast ci o tym powiedzieć, po prostu go porzuca. Żadne promptowe rozwiązania nie rozwiązują żadnego z tych sposobów, bo problem nie leży w tym, o co pytasz model, tylko w tym, że nic nie sprawdza, co daje z powrotem. Zaufanie nie wynika z jednej sprytnej instrukcji. Wynika to ze *struktury*: jasnych zasad dotyczących dozwolonych działań, testów, które mogą się nie zdać, oraz zapisu, który można samodzielnie sprawdzić.
|
||||
|
||||
## Rozwiązanie: myKG
|
||||
|
||||
Dlatego zbudowałem [**myKG.**](https://github.com/SenolIsci/mykg) Nie byłem zadowolony z istniejących narzędzi do ekstrakcji grafów wiedzy, które często dawały imponująco, ale trudne do zaufania wyniki.
|
||||
|
||||
[**myKG**](https://github.com/SenolIsci/mykg) to narzędzie open-source, które buduje wykresy wiedzy z folderu dokumentów o mieszanym formacie. Został zaprojektowany dokładnie wokół tego pytania: *które z tych węzłów i połączeń są prawdziwe?*
|
||||
|
||||
Wciąż używa LLM do czytania notatek. Różnica polega na tym, że wszystko jest zbudowane wokół tego LLM. Wynik to nie tylko wykres, to wykres, który możesz sprawdzić:
|
||||
|
||||
- **Każdy węzeł, link i atrybut otrzymuje wskaźnik zaufania** (od 0 do 1) oraz listę plików źródłowych, z których pochodzi. Każde roszczenie można prześledzić aż do oryginalnego tekstu.
|
||||
- **Schemat jest najpierw zapisywany i sprawdzany**, więc wykres może zawierać tylko te rzeczy i linki, które określiłeś, że są dozwolone.
|
||||
- **Nic niepewnego nie zostaje cicho zamienione w fakt, a nic, czego model nie potrafi umiejscowić, zostaje cicho wyrzucone.** Model może powiedzieć "Nie jestem pewien" lub "Nie wiem."
|
||||
|
||||
Działa też bezpośrednio w narzędziach, których już używasz. myKG można uruchomić z Claude Code przez tę umiejętność.`**/mykg**`
|
||||
|
||||
|
||||
|
||||
*(zobacz* [*Od dokumentów do żywego wykresu wiedzy: Wprowadzenie myKG*](https://medium.com/@senol.isci/from-documents-to-a-living-knowledge-graph-introducing-mykg-fab7cea22de5)*, aby uzyskać więcej szczegółów)*
|
||||
|
||||
## Przygotowanie:
|
||||
|
||||
Najpierw zainstaluj pakiet i włącz tryb agenta z Claude Code: instaluje on umiejętność i tworzy lub aktualizuje plik, żeby agent wiedział, jak prowadzić pipeline.`--profile agent-claude-code` `/mykg` `CLAUDE.md`
|
||||
|
||||
```c
|
||||
pip install mykg
|
||||
mykg init --profile agent-claude-code
|
||||
```
|
||||
|
||||
|
||||
Następnie otwórz terminal (na przykład w VS Code), uruchom kod Claude z folderu projektu i uruchom pipeline z.`/mykg`
|
||||
|
||||
Umiejętność sprawdza, czy tryb agenta jest włączony, rozpoczyna sesję i rozpoczyna pętlę przetwarzania, wysyłając podagenta dla każdego kroku:
|
||||
|
||||
```c
|
||||
# Inside Claude Code (drives the LLM steps via the agent skill):
|
||||
/mykg extract notes/
|
||||
```
|
||||
|
||||
|
||||
## Przykład: poznaj korpus
|
||||
|
||||
Aby każde zgłoszenie było konkretne, reszta tego artykułu śledzi jeden prawdziwy bieg od początku do końca, przez cztery krótkie notatki w Markdown o wymyślonej firmie o nazwie **"Acme Corp."** Zanim spojrzysz na jakiekolwiek wyniki, warto wiedzieć, co faktycznie znajduje się w tych notatkach, ponieważ zaufanie sprowadza się do tego, czy wykres odpowiada tekstowi.
|
||||
|
||||
(*Pliki demo są* [*tutaj*](https://github.com/SenolIsci/mykg/tree/main/docs/examples/blog_demo_run/blog_demo_input))
|
||||
|
||||
- `**team.md**`: który pracuje w Acme. Alice Chen (starsza inżynierka z dyplomem z MIT), CTO James Whitfield (doktorat ze Stanford), CEO Sandra Kim, dyrektor Bob Martinez oraz zespoły, którymi zarządzają.
|
||||
- `**projects.md**`: co budują. Migracja bazy danych do AWS Aurora, pipeline RAG prowadzony przez dr Yunę Park oraz usługa sekretów platformy, a także informacja, kto jest właścicielem i współtworzy każdą z nich.
|
||||
- `**technologies.md**`: stos technologiczny. PostgreSQL, Pinecone (wybrany zamiast Weaviate i Qdrant, które zostały *rozpatrzone i odrzucone*), GitHub Actions, Kubernetes, PyTorch, Python, Go oraz który zespół używa którego narzędzia.
|
||||
- `**partners.md**`: świat poza Acme. Formalne partnerstwo z DataSystems Inc, luźniejsza relacja "nieformalna doradcza" z NovaTech (notatki mówią, że "nie ma aktywnego kontraktu komercyjnego") oraz dostawcami takimi jak HashiCorp i AWS.
|
||||
|
||||
Te nuty celowo mieszają wszystko. Niektóre fakty są jasno przedstawione i powtarzane w różnych aktach. Niektóre są zabezpieczone. Niektórzy pojawiają się tylko raz, przelotnie. Ta mieszanka ma znaczenie: wiarygodny pipeline powinien traktować te sprawy inaczej, zamiast spłaszczać je wszystkie do tego samego rodzaju "faktów".
|
||||
|
||||
Ten przebieg generuje graf z **44 węzłami i 49 linkami**, który przechodzi walidację bez problemu (zobacz wynik z przebiegu [tutaj](https://github.com/SenolIsci/mykg/tree/main/docs/examples/blog_demo_run/2026-06-07T21-24-38)). Kolejne cztery sekcje krok po kroku przechodzą przez proces i pokazują, gdzie faktycznie buduje się zaufanie na każdym etapie.
|
||||
|
||||
## Pass 1 buduje schemat i go sprawdza
|
||||
|
||||
**Większość narzędzi do "notatek do wykresów" zaczyna od wyciągania *rzeczy*: ludzi, projektów, narzędzi. myKG zaczyna o krok wcześniej, decydując, jakie *rzeczy* w ogóle mogą istnieć na wykresie.**
|
||||
|
||||
Zanim wyodrębni pojedynczy przykład, Pass 1 buduje schemat: małą, typowaną strukturę wymieniającą kategorie rzeczy (zwane pojęciami) oraz typowe relacje dozwolone do ich połączenia. Z tych czterech notatek powstaje sześć pojęć (,,,,, ) oraz dwanaście relacji, z których każda ma jasno określony typ źródła i typ celu:`Person` `Organization` `Team` `Project` `Technology` `Location`
|
||||
|
||||
```c
|
||||
{ "name": "uses_technology", "domain": "Project", "range": "Technology" }
|
||||
```
|
||||
|
||||
To nie jest tylko miły przedmiot. Schemat jest *sprawdzany* w bibliotece rdflib przed jakąkolwiek ekstrakcją. Źródło i typ docelowy każdego związku musi wskazywać na pojęcie, które zostało faktycznie zadeklarowane. Jeśli schemat nie przejdzie tego testu, nic nie zostanie wyodrębnione.
|
||||
|
||||
myKG zawiera osobny mechanizm człowieka w pętli, który pozwala człowiekowi wejść i edytować schemat, *jeśli chce,* zanim zostanie zablokowany do ekstrakcji.
|
||||
|
||||
Schemat jest *też dopracowany*, nie tylko generowany raz i pozostawiany bez przerwy. myKG utrzymuje ruch, a w tym przebiegu zanotował trzy kroki, z których każdy dopracowywał zadanie:`schema_history`
|
||||
|
||||
|
||||
|
||||
Tak wygląda Pass 1 w terminalu: cztery notatki są odczytywane, jedna partia trafia do budowy schematu, a powstały schemat jest dopracowywany przez kroki harmonizacji i oceny jakości do czystych sześciu koncepcji i dwunastu relacji:
|
||||
|
||||
|
||||
|
||||
## Przejdź 2 ekstrakcje z pewnością na każdym ziarnie
|
||||
|
||||
Gdy schemat jest już zablokowany, Pass 2 czyta każdą nutę i wyciąga konkretne elementy oraz relacje, które do niej pasują. I tutaj "model tak powiedział" nie jest traktowane jako proste tak lub nie. myKG przypisuje punkt pewności *do każdego elementu* grafu: każdego węzła, każdego atrybutu, każdego linku. Oto węzeł w skarbcu Obsidian z tego biegu:
|
||||
|
||||
|
||||
|
||||
Ten sam poziom szczegółowości niesie *niepewność* do przodu, zamiast ją ukrywać. Wyraźnie określone wyniki partnerstwa Acme-to-DataSystems.`0.95`
|
||||
|
||||
|
||||
|
||||
Relacja Acme-NovaTech, którą same notatki opisują jako "nieformalną współpracę doradczą" bez "aktywnej umowy handlowej", osiąga niższy wynik –. A gdy model naprawdę czegoś nie wie, ta luka nie znika: notatka Boba Martineza wspomina o jego stanowisku, ale nie o e-mailu czy wykształceniu, więc te dwie cechy są zapisane jako szczere "nie wiemy", a nie cicha pustka, którą sam musiałbyś zauważyć.`0.85` `{"value": null, "confidence": 0.0}`
|
||||
|
||||
Oto przepustka 2 działająca w terminalu. Pobiera z wszystkich czterech plików w jednej partii i raportuje, gdy duplikaty z różnych plików zostały połączone:`44 node(s), 49 edge(s)`
|
||||
|
||||
|
||||
|
||||
## Walidacja, która nie pyta o opinię modelu
|
||||
|
||||
Wyniki pewności są przydatne, ale nadal są miękkim sygnałem, miarą pewności modelu. Niektóre testy muszą być trudniejsze. Gdy graf jest w pełni złożony, myKG uruchamia osobny przebieg walidacyjny swojej struktury: czyste sprawdzanie reguł, bez udziału LLM. Relacja typu, na przykład, musi przebiegać od a do. Bez wyjątków. Jeśli relacja łamie deklarowane źródło lub typ celu, to błąd, a nie kwestia opinii.`uses_technology` `Project` `Technology`
|
||||
|
||||
```c
|
||||
{ "valid": true, "tbox_checks": { "errors": [] }, "abox_checks": { "errors": [] } }
|
||||
```
|
||||
|
||||
Ten test nie może powiedzieć, czy dany fakt jest *prawdziwy*. Gwarantuje to, że wszystko na wykresie przynajmniej ma *kształt*, jaki schemat sugeruje, że powinien mieć. Model nie ma tu nic do powiedzenia.
|
||||
|
||||
## Pozwalając modelowi powiedzieć "nie"
|
||||
|
||||
Niektóre decyzje naprawdę wymagają rozsądku. A najważniejszym wyborem projektowym myKG jest pozwolenie, by ta ocena była " **nie".**
|
||||
|
||||
Po złożeniu grafu niektóre węzły nie mają żadnych połączeń, "sieroty", które pojawiają się w tekście, ale nie łączą się wyraźnie z niczym innym. Prosta zasada oparta na tym, które słowa pojawiają się blisko siebie (bez udziału LLM), sugeruje możliwe powiązania tych sierot. Następnie model jest proszony o potwierdzenie lub odrzucenie każdej sugestii i wyraźnie może odmówić. W tym przebiegu odmówił każdej sugestii (log odrzuceń pokazuje 52 odrzucenia), pozostawiając trzynaście węzłów szczerze mówiąc niepołączonych, zamiast wymuszać połączenia, które tak naprawdę nie istniały. Te trzynaście dzieli się na dwie grupy, a notatki zostały napisane tak, by pokazać obie:
|
||||
|
||||
- **Rzeczy, które brzmią wiarygodnie, ale nie są faktycznie zgłaszane.** oraz są to bazy wektorowe, które według nich zostały *rozpatrzone i odrzucone* na rzecz Pinecone. To prawdziwe słowa, które pojawiają się w notatkach, ale tekst nigdy nie wskazuje ich relacji.`qdrant` `weaviate` `technologies.md`
|
||||
- **Rzeczy, które są prawdziwe, ale schemat nie ma miejsca.** Alice Chen naprawdę ma dyplom z MIT, a zespół badawczy AI naprawdę korzysta z PyTorch. Oba są faktami przedstawionymi. Ale ten schemat nie ma związku z edukacją, a jego jedyny związek z wykorzystaniem technologii przebiega od do, a nie od do. Nie ma szczerego związku z rysowaniem, więc żadne nie jest rysowane.`Person → Organization` `Project` `Technology` `Team` `Technology`
|
||||
|
||||
Narzędzie zoptymalizowane, by wyglądać imponująco i gęsto połączone, i tak wymyśliłoby wszystkie trzynaście połączeń. Narzędzie zoptymalizowane pod kątem zaufania odłącza ich od rzeczywistości i dokładnie zapisuje dlaczego oraz sugeruje dalsze aktualizacje schematu. Oto dziennik run dla drugiej grupy, prawdziwe rzeczy, na które schemat nie ma miejsca:
|
||||
|
||||
```c
|
||||
22:32:49 [INFO] mykg.steps.orphan_connect — Step orphan_connect — technology-qdrant: no edges confirmed; promoted to schema-gap orphan
|
||||
22:32:49 [INFO] mykg.steps.orphan_connect — Step orphan_connect — technology-github-actions: no edges confirmed; promoted to schema-gap orphan
|
||||
22:32:49 [INFO] mykg.steps.orphan_connect — Step orphan_connect — technology-weaviate: no edges confirmed; promoted to schema-gap orphan
|
||||
```
|
||||
|
||||
Zwróć uwagę na etykietę: nie "odrzucony", nie "zignorowany", lecz flaga. Model nie tylko odmawia połączenia Alice Chen z MIT czy zespołu AI Research z PyTorch, ale także wskazuje, *dlaczego* nie może: schemat, który zatwierdziłeś w kroku 1, nie ma miejsca na taki rodzaj relacji. To coś innego niż twierdzenie, którego notatki nie potwierdzają. To twierdzenie, które notatki *potwierdzają*, że wykres obecnie nie ma uczciwego sposobu, by się utrzymać. I właśnie tę sytuację myKG oddaje ci do naprawy, nie wymuszając połączenie, ale uruchamiając aktualizację schematu, żeby następny przebieg miał uczciwe miejsce, gdzie go umieścić.`**schema-gap orphan**`
|
||||
|
||||
## Efekt: zaufanie jako tarcza
|
||||
|
||||
Dodaj te cztery kroki i daje coś konkretnego: zaufanie to już nie jest wyrok tak lub nie, który wydajesz modelowi. To tarcza, a to ty ją trzymasz
|
||||
|
||||
Każdy uruchomienie generuje interaktywny plik z wbudowanymi suwakami pewności. Przeciągnij je, a wykres sam się przerysuje przed tobą. Na najniższym poziomie widzisz wszystko: wszystkie 44 węzły i 49 łączy (ten konkretny wykres jest na tyle czysty, że nic w nim nie ocenia poniżej ):`knowledge_graph.html` `0.80`
|
||||
|
||||
|
||||
|
||||
Podnieś poziom do, a najsłabsze ogniwa zaczynają znikać, a graf kurczy się do swojego rdzenia:`0.90`
|
||||
|
||||
|
||||
|
||||
Przy **wartości 0,9 i wyżej wykres spada do 33 widocznych łączy w 29 z oryginalnych 44 węzłów**, a to, co znika, to dokładnie taki niepewny powód, którego chciałbyś zniknąć:
|
||||
|
||||
- `Carol Okafor -[reports_to]→ Dr. Priya Nair` przy **0,80** – relacja raportowa z *poprzedniej* pracy, nie obecna
|
||||
- `Alice Chen -[contributes_to]→ Platform Secrets Service` przy **0,82**, wkład, o którym notatki wspominają tylko luźno
|
||||
- `RAG Pipeline -[uses_technology]→ Python` **0,82** – prawda, ale wspomniana tylko mimochodem
|
||||
|
||||
Na wyższym poziomie pozostaje solidne jądro: fakty jasno przedstawione i zarchiwizowane w wielu plikach, jak relacje z pracą i partnerami na i powyżej. Ale zwróć uwagę, czego trzymał się ten niższy poziom nauczania: stary tekst Carol Okafor, luźny wkład Alice Chen, przelotne użycie Pythona przez RAG Pipeline. Żadne z tych rozwiązań nie jest złe, po prostu są cieńsze niż kręgosłup. To dokładnie ten rodzaj rzeczy, które warto zobaczyć, gdy eksplorujesz korpus, którego jeszcze dobrze nie znasz, półzapomniane wspomnienie, które warto sprawdzić w notatkach źródłowych, nawet jeśli nie chciałbyś, by agent traktował to jako ustalony fakt. Nie ufasz wykresowi tylko dlatego, że ktoś ci to powiedział.`0.95`
|
||||
|
||||
Możesz wybrać własny próg zaufania w zależności od tego, co z nim robisz. Budujesz agenta, który odpowiada z solidnych podstaw? Ustaw podłogę i podaj tylko grzbiet, który właśnie widziałeś. Rozplanowanie, co faktycznie zawierają twoje notatki, włącznie z niedokończonymi sprawami? Pociągnij suwak z powrotem w dół i zobacz wszystko, co model znalazł, w tym słabe sygnały. **Numer należy do Ciebie, a po prostu powiedz agentowi Claude'a przez komendę /myKG, jaki poziom pewności ma operować podczas odpowiadania na zapytania.**`0.9` `0.0`
|
||||
|
||||
## Podsumowanie
|
||||
|
||||
Drugi mózg, któremu możesz zaufać, nie powstaje z jednego sprytnego testu czy dobrze wystrojonego promptu. Jest zbudowany z warstw, które wyłapują wzajemne błędy, i właśnie to daje myKG: owija LLM tymi warstwami, więc nie musisz ich tworzyć sam. W tym przebiegu każda warstwa spełniła swoje zadanie. Schemat został sprawdzony przed wyodrębnieniem czegokolwiek. Każdy element wykresu ma własny wskaźnik pewności. Kontrole strukturalne przeprowadzono bez pytania o opinię modelu. Model mógł swobodnie odrzucać niektóre twierdzenia zamiast wymyślać fałszywe powiązania.
|
||||
|
||||
To, co **wnosi myKG**, to to, co sprawia, że drugi mózg staje się czymś, na czym naprawdę można polegać.
|
||||
|
||||
*Zbudowany z* [*myKG.*](https://github.com/SenolIsci/mykg) *Przykład: pliki demo są* [*tutaj*](https://github.com/SenolIsci/mykg/tree/main/docs/examples/blog_demo_run/2026-06-07T21-24-38)*.*
|
||||
|
||||
*Pełny projekt i zestaw funkcji narzędzia znajdziesz w* [*artykule From Documents to a Living Knowledge Graph: Introducing myKG*](https://medium.com/@senol.isci/from-documents-to-a-living-knowledge-graph-introducing-mykg-fab7cea22de5) *and* [*the Github repozytorium*](https://github.com/SenolIsci/mykg)*.*
|
||||
@@ -0,0 +1,155 @@
|
||||
---
|
||||
title: "Karpathy's LLM Wiki v2: What to Keep, What to Skip"
|
||||
source: "https://theaioperator.io/p/karpathys-llm-wiki-v2-what-to-keep"
|
||||
author:
|
||||
- "[[Eugeniu Ghelbur]]"
|
||||
published: 2026-06-09
|
||||
created: 2026-06-10
|
||||
description: "I rebuilt it, ran it daily for months, and most of the v2 hype is overkill."
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
### Odbudowałem ją, uruchamiałem codziennie przez miesiące, a większość hype'u wokół v2 to przesada.
|
||||
|
||||
|
||||
|
||||
**Internet spędził dwa miesiące projektując "v2" LLM Wiki Andreja Karpathy'ego: oceny pewności, łańcuchy supersesji, zapominanie krzywych, wyszukiwanie wektorowe, haki cyklu życia.**
|
||||
**Odbudowałem oryginał i od miesięcy uruchamiam go codziennie przez [repozytorium, które już 2 317 osób obsadziło.](https://github.com/eugeniughelbur/obsidian-second-brain)**
|
||||
**Oto szczery raport o tym, które pomysły v2 zasługują na swoje miejsce, a które są przesadzone i wyrwiecie je w tydzień.**
|
||||
|
||||
Andrej Karpathy opublikował w zeszłym roku ogólny opis, jak prowadzi wiki utrzymywane przez LLM: surowe źródła pozostają nietknięte, AI posiada folder z notatkami markdown, a plik reguł mówi jej, jak pobierać, aktualizować i zapytywać. Odbudowałem **[ten wzór jako działający system](https://theaioperator.io/p/i-rebuilt-karpathys-llm-wiki-heres)** i napisałem o tym, co oryginał pominął.
|
||||
|
||||
Od tego czasu pojawił się niewielki gatunek. Ludzie publikują "LLM Wiki v2" gist. Najbardziej współdzielony (przez programistę o pseudonimie rohitg00) dodaje ocenę pewności, łańcuchy supersesji, zapominanie krzywych, hybrydowe wyszukiwanie wektorowe oraz haki zdarzeń. Inne wersje mają ścieżki audytowe, pamięć wielopoziomową i oceny jakości.
|
||||
|
||||
Wygląda to jak prawdziwa aktualizacja. Większość z nich nie jest.
|
||||
|
||||
Nie teoretyzuję. Codziennie od miesięcy prowadzę odbudowaną wiki i udostępniłem ją jako **[obsydian-second-brain](https://github.com/eugeniughelbur/obsidian-second-brain)**. Oto różnica między pomysłami v2, które przetrwały codzienne użycie, a tymi, które w ogóle wyglądają na mądre, a w praktyce umierają.
|
||||
|
||||
## Najpierw to, co wszyscy dobrze rozumieją
|
||||
|
||||
Jeśli trafiłeś tu na zimno, wzór to trzy warstwy i naprawdę działa.
|
||||
|
||||
Po pierwsze: surowe źródła, niezmienne. Cokolwiek mu włożysz (artykuł, transkrypcję, spotkanie), trafia do folderu i nigdy nie jest edytowane. To jest twoja prawda.
|
||||
|
||||
Po drugie: wiki. Folder z notatkami markdown, które AI posiada i przepisuje. Nowe informacje nie są dodawane na dole. Jest on wklejany do istniejącej nuty, a sprzeczności są godzone.
|
||||
|
||||
Po trzecie: plik zasad. Jeden plik Markdown, który informuje AI, jak pobrać źródło, jak zaktualizować stronę, jak zapisać to, co zrobiła. An do nawigacji i tylko do dołączania do historii.`index.md` `log.md`
|
||||
|
||||
Powód, dla którego to lepsze niż wrzucenie wszystkiego do ogromnego okna kontekstu: wyselekcjonowana wiki z 50 000 do 100 000 tokenów odpowiada na większość pytań bez ładowania całego korpusu. Wydajesz żetony na odpowiedź, nie na stóg siana. Ta część jest prawdziwa i v2 tego nie zmienia.
|
||||
|
||||
|
||||
|
||||
## Co "v2" właściwie oznacza teraz
|
||||
|
||||
Nie ma oficjalnej wersji 2. Smysł Karpathy'ego pozostaje jedyną kanoniczną specyfikacją. "v2" to wspólnotowa etykieta dla stosu proponowanych dodatków, które skupiają się w dwóch kategoriach.
|
||||
|
||||
Cechy ładu: wskaźniki zaufania do roszczeń, łańcuchy supersesji, więc stary fakt wskazuje na nowy, który go zastąpił, oraz "zapominanie krzywych", więc starze notatki się rozpadają zamiast gnić na miejscu.
|
||||
|
||||
Wyszukiwanie i infrastruktura: wyszukiwanie hybrydowe (słowa kluczowe plus osadzenia wektorowe), haki cyklu życia i zdarzeń, ocena jakości, pamięć wielopoziomowa.
|
||||
|
||||
Pierwszy kubeł dotyczy tego, czy wiki mówi prawdę. Druga dotyczy maszyn. Po miesiącach prowadzenia tego projektu, podział między nimi to dokładnie ten podział między tym, co działa, a tym, co jest przesadą.
|
||||
|
||||
|
||||
|
||||
## Pomysły na v2 wysłałem i zachowałem
|
||||
|
||||
Kubełek zarządzania zasługuje na swoje miejsce. Każdy z tych elementów jest w systemie, który prowadzę.
|
||||
|
||||
**Wskaźniki pewności.** Każde twierdzenie, które pisze moja wiki, nosi tag:,, lub. Kosztuje prawie nic (jedno słowo na fakt) i zmienia sposób czytania. Gdy AI syntetyzuje między notatkami, twierdzenie traktowane jest jako cytat, a nie prawda. To jest najdroższy pomysł v2 o najwyższej wartości i nie wymaga żadnej infrastruktury.`stated` `high` `low` `stated`
|
||||
|
||||
**Supersession, zrobione jako pojednanie.** Gdy nowe źródło przeczy istniejącej notatce, wiki nie zachowuje obu i wzrusza ramionami. Polecenie je uzgadnia: notatka jest przepisywana na aktualną prawdę, a zmiana jest rejestrowana. Nie potrzebujesz formalnej struktury danych "łańcucha supersesji". Potrzebujesz, żeby AI faktycznie rozwiązało konflikt, zamiast go gromadzić.
|
||||
|
||||
**Zapominająca krzywa, ale nudna.** Wersja wymyślna obejmuje ścieżki spadku i znaczniki czasu. Moja jest prostsza: lekcje są powtarzane, a te, które przestały być prawdziwe, są przycinane. **[Notatki, które się gromadzą, stają się cmentarzem](https://theaioperator.io/p/your-notes-are-a-graveyard)**. Celem krzywej zapominania nie jest matematyka. Chodzi o to, że coś się usuwa.
|
||||
|
||||
**Haczyki cyklu życia, jako agenci zaplanowani.** Ten jest prawdziwy i prowadzę go. Agenci tła budzą się według harmonogramu i utrzymują wiki, gdy ja nie patrzę: pojednają sprzeczności, syntetyzują wzorce, oznaczają przestarzałe twierdzenia. Nie potrzebujesz abstrakcji z magistrali zdarzeń. Potrzebujesz crona i pliku reguł.
|
||||
|
||||
|
||||
|
||||
## Pomysł z v2 pominąłem i dlaczego
|
||||
|
||||
Hybrydowe wyszukiwanie wektorowe to główna cecha niemal każdego gist-a v2. Próbowałem. Wyjąłem ją.
|
||||
|
||||
Oto coś, czego nikt piszący te analizy nie zmierzył: na poziomie wiki nie ma problemu z odzyskiwaniem informacji. Selekcjonowana wiki to od 50 000 do 100 000 tokenów. To mała sprawa. Grep plus read znajduje właściwą notatkę szybciej i bardziej przewidywalnie niż wyszukiwanie embedding, bez bazy wektorowej do hostowania, bez indeksu do utrzymania świeżości i bez debugowania "dlaczego zwrócił ten fragment".
|
||||
|
||||
Wyszukiwanie wektorowe zarabia na setkach tysięcy dokumentów. Osobista czy zespołowa wiki to nie jest to. Przykręcanie osadzeń na sejf o 200 banknotach to rozwiązanie problemu, którego nie masz, i płacenie za bazę danych, żeby to zrobić.
|
||||
|
||||
To samo dotyczy wielopoziomowej pamięci i rozbudowanych silników punktacji jakości. Są odpowiedziami na problemy ze skalą. Na poziomie, w którym wiki LLM jest faktycznie użyteczne, są one ważne.
|
||||
|
||||
|
||||
|
||||
## Czego naprawdę wciąż brakuje
|
||||
|
||||
Szczerość działa w obie strony, więc oto luka, którą w2 gists też pomija.
|
||||
|
||||
Żaden z nich nie ma prawdziwej ochrony przed tym, by AI kłamało na temat tego, co jest w wiki. Przekonałem się tego na własnej skórze: gdy czytałem widełki mojego repozytorium, obca osoba dodała dokładnie to, czego mi brakowało. Najczęstszą porażką nie jest to, że AI wymyśla fakt. To AI mówi "nie ma notatki o tym", gdy jest, bo odpowiedziała z pamięci, zamiast faktycznie szukać.
|
||||
|
||||
To jest prawdziwa granica v2. Nie bardziej wyszukane wyszukiwanie. Reguła, która zmusza model do weryfikacji obecności i nieobecności poprzez wymienianie i greppowanie, nigdy z pamięci, zanim powie ci, że coś nie istnieje. Teraz łączę tę opaskę. Żaden wopis v2, który nie widziałem, by to uwzględniał.
|
||||
|
||||
|
||||
|
||||
## Właściwa lekcja
|
||||
|
||||
Dyskurs v2 ma kierunek odwrotny. Traktuje tę aktualizację jak maszynę, którą dodajesz: magazyn wektorowy, silnik punktacji, hierarchię pamięci.
|
||||
|
||||
Wersja, która działa, jest odwrotna. To najmniejszy zestaw zasad, które sprawiają, że AI zachowuje własną prawdę. Pewność w każdym roszczeniu. Sprzeczności rozwiązane, nie gromadzone. Usunięto starze notatki. Agent, który wykonuje konserwację według harmonogramu. Wszystko to znajduje się w pliku reguł i żadne z tego nie wymaga bazy danych.
|
||||
|
||||
Pierwotna intuicja Karpathy'ego była taka, że wiki powinno być zwykłym markdownem, który należy do AI. Prawdziwa wersja 2 to szanuje. Nie zalewa go w infrastrukturze.
|
||||
|
||||
Cały system jest open source w **[obsidian-second-brain](https://github.com/eugeniughelbur/obsidian-second-brain)**. **[Najpierw zbudowałem go dla siebie](https://theaioperator.io/p/i-built-this-for-myself-then-1374)** i warto przeczytać plik zasad. To tam faktycznie mieszka wersja 2.
|
||||
|
||||
---
|
||||
|
||||
## Najczęściej zadawane pytania
|
||||
|
||||
**Czym jest Wiki LLM Karpathy'ego?**
|
||||
Wzorzec, który Andrej Karpathy podzielił, pozwalając AI utrzymywać niewielką bazę wiedzy o cenzurach. Trzy warstwy: surowe źródła pozostają niezmienne, wiki z notatkami, które AI posiada i przepisuje, oraz plik reguł, który informuje ją, jak pobierać, aktualizować i zapytywać.
|
||||
|
||||
**Czym jest "LLM Wiki v2"?**
|
||||
Wytwórnia społecznościowa, a nie oficjalne wydanie. Główny wątek Karpathy'ego jest nadal jedyną kanoniczną specyfikacją. "v2" odnosi się do dodawań, które ludzie proponują we własnych gistach: wskaźniki pewności, łańcuchy supersesji, zapominanie krzywych, hybrydowe wyszukiwanie wektorowe oraz haki cyklu życia.
|
||||
|
||||
**Czy potrzebujesz wyszukiwania wektorowego do wiki LLM?**
|
||||
Nie, nie na poziomie wiki. Kuratorowana wiki to 50 000 do 100 000 tokenów, a grep plus read znajduje właściwą notę szybciej i bardziej przewidywalnie niż osadzenia, bez bazy danych do hostowania. Wyszukiwanie wektorowe zdobywa swoje miejsce wśród setek tysięcy dokumentów.
|
||||
|
||||
**Które pomysły na v2 faktycznie warto dodać?**
|
||||
Te dotyczące zarządzania: tagi zaufania przy roszczeniach, uzgadnianie sprzeczności zamiast ich gromadzenia, usuwanie starych notatek oraz zaplanowany agent utrzymujący wiki. Każda z nich to kilka linii w pliku reguł, a nie nowa infrastruktura.
|
||||
|
||||
**Jak duży może być wiki LLM, zanim się zepsuje?**
|
||||
Jest budowany dla małych, starannie wyselekcjonowanych korpusów, około 50 000 do 100 000 tokenów. Poza tym zaczynają mieć znaczenie cechy skale, które proponują gists v2. W rozmiarze, w którym wiki LLM jest najbardziej przydatna, są one ważne.
|
||||
|
||||
**Gdzie mogę uzyskać działającą implementację?**
|
||||
Cały system jest open source jako obsidian-second-brain, umiejętność Claude Code na GitHubie.
|
||||
|
||||
---
|
||||
|
||||
## Kluczowe wnioski
|
||||
|
||||
- Trójwarstwowy wzór Karpathy'ego (niezmienne źródła, wiki należące do AI, plik reguł) jest solidny i v2 go nie zmienia.
|
||||
- "LLM Wiki v2" to wytwórnia społecznościowa, a nie oficjalne wydanie. Istota Karpathy'ego to wciąż jedyna kanoniczna specjalizacja.
|
||||
- Pomysły v2, które warto zachować, to wszystkie zarządzanie: tagi zaufania, pojednanie, przycinanie i zaplanowani agenti. Każda z nich kosztuje kilka linii w pliku zasad.
|
||||
- Hybrydowe wyszukiwanie wektorowe jest przesadą na skalę wiki. Grep plus read wygrywa wśród setek tysięcy dokumentów.
|
||||
- Prawdziwą luką, którą nie pokrywa gist v2, jest ochrona przed fałszywą nieobecnością: AI twierdzi, że notatka nie istnieje, gdy jednak istnieje.
|
||||
- Ulepszenie to zasady, które AI narzucuje sobie sama, a nie przymontowane maszyny.
|
||||
|
||||
---
|
||||
|
||||
## Dalsza lektura
|
||||
|
||||
- Oryginalny smysł LLM na Wiki Andreja Karpathy'ego (2026-02)
|
||||
- Smysł rohitg00 do Wiki v2 (2026-03)
|
||||
- [Odbudowałem Wiki LLM Karpathy'ego. Oto, czego brakuje w oryginale.](https://theaioperator.io/p/i-rebuilt-karpathys-llm-wiki-heres)
|
||||
- [Twoje notatki to cmentarz. Oto jak je przywrócić do życia.](https://theaioperator.io/p/your-notes-are-a-graveyard)
|
||||
- [obsydian-second-brain na GitHub](https://github.com/eugeniughelbur/obsidian-second-brain)
|
||||
|
||||
---
|
||||
|
||||
## O autorze
|
||||
|
||||
Eugeniu Ghelbur jest inżynierem automatyzacji AI w Single Grain, gdzie tworzy systemy AI produkcyjne dla procesów marketingowych i sprzedaży. Dostarcza otwartoźródłowe umiejętności Claude Code i pisze o zarządzaniu wiedzą AI w theaioperator.io. Opisana tutaj umiejętność obsydianowego drugiego mózgu jest dostępna na żywo na GitHubie w [github.com/eugeniughelbur/obsidian-second-brain](https://github.com/eugeniughelbur/obsidian-second-brain), gdzie została wyróżniona przez ponad 2300 deweloperów.
|
||||
|
||||
---
|
||||
|
||||
#### Subskrybuj The AI Operator
|
||||
|
||||
Autor: Eugeniu Ghelbur · Uruchomiony 2 lata temu · Uruchomiony 2 lata temu
|
||||
|
||||
Systemy agentów AI, napisane przez kogoś, kto wysyła je w produkcji.
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "OpenCode jest naprawdę świetny!"
|
||||
source: "https://lofidewanto.medium.com/opencode-is-really-great-c679b5774448"
|
||||
author:
|
||||
- "[[Dr Lofi Dewanto]]"
|
||||
published: 2026-06-04
|
||||
created: 2026-06-11
|
||||
description: "Pojedynczy CLI dla wszystkich LLM"
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
## Pojedynczy CLI dla wszystkich LLM
|
||||
|
||||
Po tym, jak GitHub Copilot podniósł ceny i cały internet zaczął o tym krzyczeć, wielu niezależnych deweloperów zaczęło się frustrować. Nowe ceny wydają się znacznie droższe niż wcześniej, więc zacząłem też szukać alternatyw dla moich prywatnych projektów.
|
||||
|
||||
> ==Bardzo podoba mi się połączenie OpenCode i GitHub Copilot==, bo mogę używać wielu LLM-ów jako moich "mózgów" i pozwalać im przeglądać swoje prace nawzajem, co uważam za jeden z najlepszych sposobów na SDD.
|
||||
|
||||
|
||||
|
||||
OpenCode jest naprawdę świetny!
|
||||
|
||||
Po kilku godzinach próbowania Claude Code zdałem sobie sprawę, jak bardzo tęsknię za tym setupem. Oto dlaczego:
|
||||
|
||||
👉 (1) Dzięki OpenCode mogę używać Claude'a, GPT, Gemini, DeepSeek, Big Pickle i innych modeli razem. *Mogą przeglądać swoje dorobki.* Błąd, którego Opus nie potrafi rozwiązać, może zostać naprawiony przez GPT, i odwrotnie. Poleganie tylko na jednej rodzinie modeli nie zawsze jest optymalne.
|
||||
|
||||
👉 (2) OpenCode ma świetny interfejs użytkownika. Jest łatwy do zrozumienia i *wyraźnie zaprojektowany pod kątem SDD*. Tryb planowania, tryb budowy i przegląd zadań są bardzo dostępne i ułatwiają zobaczenie, co robi agent. CLI Claude Code wydaje mi się mniej intuicyjne, choć może to wynikać z tego, że spędziłem więcej czasu z OpenCode.
|
||||
|
||||
🚀 Ogólnie mam nadzieję, że branża ostatecznie zjednoczy się na jednym standardzie agenta AI, abyśmy mogli swobodnie mieszać "mózgi" (LLM) stojące za nim. Obecnie każdy dostawca tworzy własne CLI, co nie jest idealne dla doświadczenia deweloperów.
|
||||
|
||||
|
||||
|
||||
Agenci AI i wielu innych...
|
||||
|
||||
Jakie masz doświadczenia z pracą z CLI agentów AI?
|
||||
+294
@@ -0,0 +1,294 @@
|
||||
---
|
||||
title: "RAG, LLM Wiki, or Gbrain? How Your Agent Remembers Changes Everything"
|
||||
source: "https://ai.gopubby.com/rag-llm-wiki-or-gbrain-how-your-agent-remembers-changes-everything-56829e66725c"
|
||||
author:
|
||||
- "[[Yanli Liu]]"
|
||||
published: 2026-04-27
|
||||
created: 2026-06-11
|
||||
description: "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 …"
|
||||
tags:
|
||||
- "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](https://medium.com/ai-advances/rag-llm-wiki-or-gbrain-how-your-agent-remembers-changes-everything-56829e66725c?sk=451323ab65a9d49cd1ae653ef4a1e8cb)
|
||||
|
||||
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](https://arxiv.org/abs/2401.05856). 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](https://arxiv.org/abs/2401.05856) 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](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) 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](https://github.com/garrytan/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](https://github.com/garrytan/gbrain/blob/master/skills/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`
|
||||
|
||||
```hs
|
||||
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](https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2) — łą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](https://neo4j.com/blog/agentic-ai/knowledge-layer/) łą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](https://python.langchain.com/docs/tutorials/rag/) to wciąż najszybsza droga do działającego prototypu
|
||||
- **LLM Wiki:** [Sedno Karpathy'ego](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) to 200 linii schematu, które możesz dziś wykorzystać przeciwko Claude'owi lub GPT
|
||||
- **Fat Skills:** [repozytorium GBraina](https://github.com/garrytan/gbrain) 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](https://ai.gopubby.com/openai-quietly-told-you-to-throw-away-your-prompt-stack-ef1178f2e5ec?source=post_page-----56829e66725c---------------------------------------)
|
||||
|
||||
### 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](https://ai.gopubby.com/openai-symphony-vs-claude-managed-agents-vs-crewai-which-agent-orchestration-pattern-wins-43141fd7b944?source=post_page-----56829e66725c---------------------------------------)
|
||||
|
||||
### 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](https://levelup.gitconnected.com/the-4-lines-every-claude-md-needs-2717a46866f6?source=post_page-----56829e66725c---------------------------------------)
|
||||
|
||||
### 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](https://ai.gopubby.com/harness-engineering-what-every-ai-engineer-needs-to-know-in-2026-0ab649e5686a?source=post_page-----56829e66725c---------------------------------------)
|
||||
|
||||
### 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](https://medium.com/@yanli.liu/about) na Medium i subskrybuj, aby otrzymywać mój najnowszy artykuł🫶
|
||||
|
||||
## [O nim - Yanli Liu - Medium](https://medium.com/@yanli.liu/about?source=post_page-----56829e66725c---------------------------------------)
|
||||
|
||||
### Przeczytaj teksty Yanli Liu na Medium. Dzienny specjalista finansowy z Luksemburga, doświadczony programista i pasjonat...
|
||||
|
||||
medium.com
|
||||
Reference in New Issue
Block a user