KIberblick
Inhaltsverzeichnis

Grundlagen

Open Knowledge Format: Wissen für KI-Agenten

Googles Open Knowledge Format speichert Firmenwissen als Markdown mit YAML, damit KI-Agenten es zuverlässig nutzen. Was OKF ist und wie ihr es einsetzt.

Entwickler:inProduct OwnerProjektleiter:in
18. Juni 20268 Min. Lesezeit

Du gibst einem KI-Agenten die Aufgabe, eine Auswertung über eure Bestellungen zu schreiben. Der Agent kennt die Datenbank nicht. Welche Tabelle? Welche Spalte ist der Umsatz, brutto oder netto? Was zählt als "aktiver Kunde"? Diese Antworten stehen verstreut: ein Teil im Wiki, ein Teil in Code-Kommentaren, ein Teil im Kopf der Kollegin, die das Schema vor zwei Jahren gebaut hat.

Genau dieses Problem will Googles Open Knowledge Format (OKF) lösen. Es ist ein offenes Format, um Wissen so aufzuschreiben, dass sowohl Menschen als auch KI-Agenten es zuverlässig lesen und pflegen können. Veröffentlicht wurde es Mitte Juni 2026 als Spezifikation auf GitHub, aktuell in Version 0.1 (Draft).

Was OKF ist (und was nicht)

OKF ist kein Produkt, kein Dienst und keine Plattform. Es ist ein Format, genauer: ein Verzeichnis aus Markdown-Dateien mit YAML-Frontmatter. Google bringt das selbst auf den Punkt: "What's missing is a format, not another service."

Der Kerngedanke ist bewusst minimal. Jede Datei beschreibt ein Konzept (eine Tabelle, eine Kennzahl, einen API-Endpunkt, ein Runbook). Oben im YAML-Block stehen ein paar strukturierte Felder, die ein Agent abfragen kann, ohne das ganze Dokument zu parsen. Darunter folgt normaler Markdown-Text. Oder wie es in der Spec heißt: Wenn du eine Datei mit cat lesen kannst, kannst du OKF lesen.

Wie ein OKF-Dokument aussieht

Ein einzelnes Dokument für unsere Bestelltabelle könnte so aussehen:

---
type: BigQuery Table
title: Bestellungen
description: Eine Zeile pro abgeschlossener Kundenbestellung.
resource: https://console.cloud.google.com/bigquery?p=acme&d=shop&t=bestellungen
tags: [shop, umsatz]
timestamp: 2026-06-15T14:30:00Z
---

# Schema

| Spalte | Typ | Beschreibung |
|--------|-----|--------------|
| `bestell_id` | STRING | Eindeutige ID der Bestellung. |
| `kunden_id` | STRING | Verweis auf /tabellen/kunden.md. |
| `umsatz_netto` | NUMERIC | Bestellwert ohne MwSt., in Euro. |

# Examples

Wöchentlicher Netto-Umsatz der letzten 8 Wochen:

```sql
SELECT DATE_TRUNC(bestell_datum, WEEK) AS woche, SUM(umsatz_netto)
FROM shop.bestellungen
GROUP BY woche ORDER BY woche DESC LIMIT 8;
```

Der Agent liest das Frontmatter, weiß sofort, dass es um eine Tabelle geht, kennt die Spalten und hat sogar ein Beispiel-Query, an dem er sich orientieren kann. Der Verweis auf /tabellen/kunden.md führt als normaler Markdown-Link zur nächsten Wissensdatei, so entsteht ein Graph aus verknüpften Konzepten.

Die Felder: ein Pflichtfeld, der Rest ist Empfehlung

OKF ist absichtlich knapp gehalten. Pflicht ist nur ein einziges Feld.

FeldStatusBedeutung
typePflichtKurzer String, der die Art des Konzepts benennt (z.B. BigQuery Table, Metric, Playbook). Nicht zentral registriert.
titleEmpfohlenLesbarer Anzeigename.
descriptionEmpfohlenEin Satz, der das Konzept zusammenfasst.
resourceEmpfohlenURI, die das zugrundeliegende Objekt eindeutig identifiziert.
tagsEmpfohlenListe zur thematischen Einordnung.
timestampEmpfohlenZeitpunkt der letzten Änderung (ISO 8601).

Eigene Felder sind erlaubt. Die einzige Regel für Konsumenten: unbekannte Felder und Typen nicht wegwerfen, sondern erhalten. Damit bleibt das Format erweiterbar, ohne dass jeder auf eine zentrale Instanz warten muss. Ein Bundle gilt als konform, wenn jede Nicht-Sonderdatei ein parsbares Frontmatter mit nicht-leerem type hat.

Die Bundle-Struktur

Mehrere Dokumente werden zu einem Bundle gebündelt, hierarchisch in Verzeichnissen:

shop/
├── index.md          # optionale Inhaltsübersicht
├── log.md            # optionale Änderungshistorie
├── tabellen/
│   ├── bestellungen.md
│   └── kunden.md
└── metriken/
    └── aktive-kunden.md

Zwei Dateinamen sind reserviert: index.md listet den Inhalt eines Verzeichnisses auf (gut für schrittweises Erkunden durch den Agenten), log.md hält die Änderungshistorie fest. Verlinkt wird am besten absolut ab der Bundle-Wurzel (/tabellen/kunden.md). Kaputte Links müssen Konsumenten tolerieren, das Format ist robust gegen Lücken ausgelegt.

OKF ist nicht MCP

Wer schon mit dem Model Context Protocol gearbeitet hat, fragt sich vielleicht, ob das nicht dasselbe ist. Ist es nicht, die beiden ergänzen sich.

MCPOKF
Was es istProtokoll (die Verbindung)Format (der Inhalt)
AnalogieDie Leitung, USB-C für KIDas Datenblatt, das durch die Leitung geht
BeantwortetWie greift die KI auf Tools und Daten zu?Wie schreibe ich Wissen so auf, dass die KI es versteht?
FormJSON-RPC, Server und ClientMarkdown-Dateien mit YAML

MCP transportiert, OKF beschreibt. In der Praxis kann ein MCP-Server ein OKF-Bundle ausliefern: MCP ist dann der Kanal, OKF der Inhalt, der durch ihn fließt.

Warum das zur git-basierten Arbeitsweise passt

Der eigentliche Charme liegt darin, dass Wissen so behandelt wird wie Code: versioniert, im Repo, mit Pull Requests und Diff. Die Idee geht auf Andrej Karpathys "LLM-Wiki" zurück. Sein Argument: Persönliche Wikis scheitern an der Pflege, weil Menschen vergessen, Querverweise zu aktualisieren. KI-Agenten haben genau dieses Problem nicht. Sie werden nicht müde, vergessen keine Referenz und können 15 Dateien in einem Durchgang anfassen.

OKF macht damit zwei Dinge möglich, die vorher umständlich waren. Erstens kann ein Agent das Wissen selbst pflegen, nicht nur lesen. Zweitens ist das Wissen portabel: Es hängt nicht mehr an einem bestimmten Katalog-Anbieter oder Wiki, sondern liegt als Klartext im Git, lesbar mit jedem Editor, renderbar auf GitHub.

Was Google schon mitliefert

OKF ist eine Spezifikation, aber nicht nur Papier. Google hat einige Referenz-Bausteine veröffentlicht:

  • Ein Enrichment-Agent, der BigQuery-Datensätze durchläuft und automatisch OKF-Dokumente mit Schemas, Join-Pfaden und Quellen generiert.
  • Einen statischen HTML-Visualizer, der ein Bundle ohne Backend als verknüpften Graphen darstellt.
  • Beispiel-Bundles für öffentliche Datensätze (GA4-E-Commerce, Stack Overflow, Bitcoin).
  • Eine Anbindung des Google Cloud Knowledge Catalog, der OKF einlesen und an Agenten ausliefern kann.

Lohnt sich der Einstieg jetzt?

Ehrlich eingeordnet: OKF ist Version 0.1 und ein Draft. Es kommt von Google, die Spec ist aber offen und lädt ausdrücklich zu eigenen Implementierungen ein. Ob daraus ein breit getragener Standard wird oder ein weiteres gut gemeintes Format, das neben anderen liegt, ist offen. Es gibt bisher keine Garantie, dass andere große Anbieter mitziehen.

Was unabhängig vom Etikett sinnvoll bleibt: die zugrundeliegende Praxis. Wenn ihr Agenten oder RAG-Pipelines baut und merkt, dass sie an fehlendem Kontext scheitern, ist "Wissen als versionierte Markdown-Dateien im Repo" eine gute Antwort, mit oder ohne OKF-Label. Der Einstieg kostet wenig, weil das Format nichts erzwingt: ein Ordner, Markdown, ein Pflichtfeld. Wer es testen will, kann mit einem kleinen Bundle für genau die Datenquelle anfangen, an der die eigenen Agenten heute am häufigsten scheitern.

Quellen