Open Knowledge Format: Markdown Google dla Agentów AI

12 czerwca 2026 roku Google Cloud opublikował specyfikację tego, jak agenty AI powinny czytać i wymieniać wyselekcjonowaną wiedzę. Można by się spodziewać bazy grafowej, rejestru schematów, SDK i usługi do jej uruchamiania.

Zamiast tego Open Knowledge Format to: katalog plików Markdown z frontmatterem YAML.

To cały format. I właśnie ta powściągliwość jest tu ciekawa.

Specyfikacja Jest Mniejsza, Niż Myślisz

Większość osób piszących o OKF streszczała ogłoszenie. Warto przeczytać samą specyfikację, bo jej zakres jest zaskakująco mały.

OKF v0.1 wymaga dokładnie jednego pola w każdym dokumencie koncepcyjnym:

---
type: BigQuery Table
---

To wszystko. type to krótki string identyfikujący, jaki rodzaj koncepcji opisuje dokument — używany do routingu i filtrowania. Wartości nie są rejestrowane centralnie — nie ma komitetu zatwierdzającego listę dopuszczalnych typów. Producenci wybierają samowyjaśniające się określenia i idą dalej.

Pięć kolejnych pól jest zalecanych, żadne nie jest wymagane:

Pole	Cel
title	Nazwa wyświetlana. Jeśli jej brak, konsumenci mogą wywnioskować ją z nazwy pliku.
description	Jednozdaniowe podsumowanie.
resource	URI jednoznacznie identyfikujący bazowy zasób.
tags	Lista YAML do kategoryzacji przekrojowej.
timestamp	Data i godzina ISO 8601 ostatniej modyfikacji.

Producenci mogą dodawać dowolne własne klucze. Konsumenci muszą zachować nieznane pola, zamiast je odrzucać.

Kompletny, zgodny dokument koncepcyjny wygląda tak:

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, orders]
timestamp: 2026-05-28T00:00:00Z
---

# Schema

| Column | Type | Description |
|--------|------|-------------|
| order_id | STRING | Unique identifier |

Jeśli kiedykolwiek napisałeś notatkę w Obsidianie z frontmatterem, napisałeś coś bardzo bliskiego prawidłowej koncepcji OKF.

Graf Wiedzy Bez Bazy Danych Grafowej

Oto decyzja projektowa warta podkradnięcia, niezależnie od tego, czy wdrożysz OKF.

Relacje między koncepcjami są wyrażane jako standardowe linki Markdown. Nie jako krawędzie w bazie danych. Nie jako blok relationships: we frontmatterze. Po prostu linki:

Each order references a [customer](/tables/customers.md).

Ścieżki bezwzględne względem bundla (zaczynające się od /) są zalecane ze względu na stabilność; zwykłe ścieżki względne, jak ./other.md, też działają.

A potem część, która sprawia, że to działa: rodzaj relacji niesie otaczająca proza, nie sam link. „Each order references a customer” jest etykietą krawędzi. Nie ma tu ontologii do utrzymywania, nie ma słownika predykatów do uzgadniania, bo naturalny język już go ma, a konsumentem jest model językowy.

Dekada narzędzi do grafów wiedzy poszła w formalizowanie typów relacji, żeby maszyny mogły je interpretować. Zakład OKF polega na tym, że to już niepotrzebne — maszyna czyta dziś angielski.

Dwie Zarezerwowane Nazwy Plików

Tylko dwie nazwy plików mają specjalne znaczenie wewnątrz bundla:

• index.md — spis katalogu, który umożliwia stopniowe odkrywanie treści. Nie zawiera frontmattera. Agent czyta najpierw indeks i podąża tylko za potrzebnymi linkami, zamiast ładować każdą koncepcję do kontekstu.
• log.md — chronologiczna historia aktualizacji, z nagłówkami dat w formacie ISO 8601, od najnowszych.

Każdy inny plik .md jest dokumentem koncepcyjnym. Bundle wygląda w efekcie jak zwykły, przeglądalny folder:

sales/
├── index.md
├── datasets/orders_db.md
├── tables/orders.md
└── metrics/weekly_active_users.md

index.md to ten po cichu najważniejszy plik. To ten sam instynkt, który stoi za dobrze napisanym CLAUDE.md: nie wrzucaj całej biblioteki do okna kontekstu, daj agentowi spis treści i pozwól mu pobrać to, czego potrzebuje.

Czym OKF Nie Jest

To nie jest RAG. RAG odtwarza wiedzę w momencie zapytania, pobierając surowe fragmenty i licząc, że te właściwe wypłyną na wierzch. Bundle OKF przechowuje wyselekcjonowane, wzajemnie połączone koncepcje, które agent czyta i aktualizuje bezpośrednio. Selekcja odbywa się raz, świadomie, zamiast być przybliżana przy każdym zapytaniu.

To nie jest AGENTS.md ani CLAUDE.md. To pliki instrukcji — mówią agentowi, jak zachowywać się w repozytorium. OKF opisuje wiedzę merytoryczną: co oznacza ta tabela, jak zdefiniowana jest ta metryka, dlaczego w tym zbiorze danych jest luka w marcu. Inna rola, komplementarna.

To nie jest MCP. MCP to protokół czasu wykonania do łączenia agenta z działającymi systemami. OKF to format plików spoczywający na dysku. Sensowne jest używanie obu naraz: MCP, żeby dotrzeć do hurtowni danych, i OKF, żeby wyjaśnić, co w niej jest.

Zasady Zgodności Są Celowo Wyrozumiałe

Bundle jest zgodny z OKF v0.1, jeśli każdy niezarezerwowany plik .md ma dający się sparsować frontmatter YAML, każdy blok frontmattera ma niepuste pole type, a zarezerwowane pliki — jeśli występują — trzymają się swoich struktur.

Bardziej wymowne jest to, czego specyfikacja zabrania konsumentom. Konsument nie może odrzucić bundla z powodu brakujących pól opcjonalnych, nieznanych wartości type, nieznanych kluczy, zerwanych linków między dokumentami czy brakującego index.md.

To format zaprojektowany przez ludzi, którzy zakładają, że bundle będą w połowie skończone, częściowo generowane maszynowo i w ciągłym ruchu — bo tak właśnie wyglądają prawdziwe bazy wiedzy. Sztywne formaty umierają od własnej sztywności. Ten jest zbudowany, żeby przetrwać kontakt z bałaganiarskim folderem.

Google wydał razem z nim narzędzia referencyjne: agenta wzbogacającego dane BigQuery, statyczny wizualizator HTML i trzy przykładowe bundle.

Jedno zastrzeżenie warto powiedzieć wprost: OKF to v0.1 i jawnie szkic. Specyfikacja jest wersjonowana i zaprojektowana pod wsteczną kompatybilność rozwoju, ale nazwy pól i konwencje wciąż mogą się zmienić. Nie przebudowuj dziś swojej bazy wiedzy wokół niej. Ale warto zauważyć, w którą stronę zmierza ten standard.

Dlaczego To Ma Znaczenie Poza Google Cloud

Odejmij przykłady BigQuery, a OKF okaże się zakładem o dużo szerszym zasięgu: że trwałym formatem wiedzy czytelnej maszynowo są zwykłe pliki Markdown w folderze, który należy do ciebie.

Nie zastrzeżony katalog z API. Nie embeddingi w bazie wektorowej, której nie da się odczytać. Nie wiki z przyciskiem eksportu, który psuje twoje tabele. Pliki. Na dysku. Diffowalne, przeszukiwalne grepem, przenośne między dostawcami, czytelne dla człowieka i dla każdego modelu na rynku.

To ten sam wniosek, do którego niezależnie doszły Claude Code, Cursor, Copilot i Windsurf, wybierając Markdown jako format swoich instrukcji. To, że Google Cloud spisał go jako specyfikację, jest potwierdzeniem, nie wynalazkiem.

Gdzie Pasuje Minibase

Jeśli prowadzisz Minibase Vault, już utrzymujesz coś strukturalnie bliskiego bundlowi OKF: folder plików Markdown z frontmatterem, na twoim własnym dysku, czytany przez Claude’a i ChatGPT.

Uczynienie go formalnie zgodnym to drobna zmiana — dodaj type do swojego frontmattera i pozwól, żeby resztę zrobiły twoje linki:

---
type: Article
title: How the Open Knowledge Format can improve data sharing
resource: https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/
tags: [okf, agents, markdown]
timestamp: 2026-07-19T00:00:00Z
---

To praktyczny kształt tego ogłoszenia. Trudną częścią budowy bazy wiedzy dla agentów nigdy nie był format pliku — było nią wprowadzenie do niej dobrego materiału źródłowego. Specyfikacja mówi ci, jak ukształtować folder. Nie wypełnia go za ciebie.

Minibase to część, która go wypełnia: jedno kliknięcie zamienia dowolną stronę internetową — dokumentację, README z GitHuba, specyfikację, wątek, artykuł naukowy — w czysty Markdown leżący w twoim folderze, gotowy na następnego agenta, którego uruchomisz.

Format jest już standardem. To, co w nim umieścisz, wciąż jest twoją przewagą.

---

Minibase zamienia dowolną stronę internetową w czysty Markdown, który mogą czytać twoje agenty — zainstaluj rozszerzenie i zacznij budować bundle, który czyni twoje agenty mądrzejszymi.