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]]
|
||||
Reference in New Issue
Block a user