Open Knowledge Format: Markdown-Dateien als tragbares Wissenslayer für Agenten
Googles OKF wandelt eine Ordner mit Markdown-Dateien in einen Wissensgraphen für Agenten um. Was es löst, wie man es ausprobiert, wo es Grenzen hat, und wie es zu RAG und MCP passt.
Agenten verbrauchen Tokens, indem sie immer wieder dieselben internen Dokumente lesen, und Google Cloud hat eine Lösung vorgeschlagen: das Open Knowledge Format, OKF. Version 0.1 wurde am 12. Juni 2026 auf dem Google Cloud Blog angekündigt. Die Idee ist einfach: Jedes Konzept, das für ein Team wichtig ist, wird zu einer Markdown-Datei, und eine Ordnerstruktur dieser Dateien dient als leichtgewichtiger Wissensgraph, den jeder Agent lesen kann. Dafür sind weder ein SDK noch eine Datenbank noch eine Bindung an eine Plattform erforderlich. Ein Skeptiker könnte erwarten, wieder eine Plattform vorzufinden, die als Format getarnt ist, doch es handelt sich tatsächlich nur um Dateien – und das ist der interessante Aspekt. Teams fügen Agenten ständig zusätzliche Komplexität hinzu, obwohl eine der schwierigsten Fragen eigentlich einfacher ist: Wo befindet sich das nützliche Wissen tatsächlich?
Das Problem: Agenten müssen ständig neu lernen
Das ist das übliche Muster: Ein Agent erhält eine Frage zu einer Metrik, lädt die gesamte interne Wiki-Datei herunter, fügt den Text ein und ermittelt die Bedeutung von Grund auf. Bei der nächsten Anfrage macht er genau dasselbe. Der Rohtext kann gecacht werden, doch niemand speichert das Verständnis davon.
Stellen Sie sich einen Agenten vor, der bei jeder einzelnen Anfrage ein Dokument neu lesen muss, das einen aktiven Benutzer definiert – schließlich hat diese Definition keinen festen Speicherort und befindet sich auf einer Notion-Seite, drei Ordner tief. Jeder Aufruf ist günstig, doch der Verbrauch summiert sich auf, genau wie kleine Verschwendungen, wenn niemand hinschaut. In einem Team, das täglich dieselben wenigen Anfragen stellt, ist der Tokenverbrauch erheblich. Es gibt keine offiziellen Zahlen dazu, da Außenstehende nicht an Googles interne Daten herankommen, doch das Problem ist den meisten, die Agenten betreiben, nur allzu vertraut.
Ein konkreteres Beispiel: Ein Analyse-Dokument definiert einen aktiven Benutzer als jeden, der innerhalb eines Kalendermonats mindestens eine bedeutende Produktaktion ausgeführt hat. Wenn man einen Mitarbeiter fragt, wie viele aktive Benutzer es im letzten Monat gab, benötigt man zwei verschiedene Dinge – die Zahlen sowie die Klärung, was hier unter „aktiv“ zu verstehen ist. Das sind getrennte Probleme. Die Datenbank berichtet, was geschehen ist, während eine Wissensschicht festhält, was das Unternehmen damit meint. OKF zielt darauf ab, diesen zweiten Aspekt leichter darzustellen.
Die Lösung ist ein Format – kein größeres Modell
OKF ist absichtlich nahezu langweilig einfach. Ein Bundle ist ein Ordner mit Markdown-Dateien, wobei jede Datei ein Konzept beschreibt – sei es eine Tabelle, eine Metrik, eine API oder ein Handbuch. Jede Datei beginnt mit einem kleinen YAML-Block, dem Frontmatter, zwischen zwei Markierungslinien. Nur ein Feld ist erforderlich:
---
type: Metric # required – tells the agent what kind of concept this is
---
Fünf optionale Felder vervollständigen das Ganze und sind hier mit ihren Zwecken aufgelistet:
| Field | Purpose |
| ------------- | ---------------------------- |
| `title` | Human-readable name |
| `description` | Short summary |
| `resource` | Link to the underlying asset |
| `tags` | Keywords for categorization |
Die Version 0.2 fügt optionale Felder hinzu, die die Herkunft, Überprüfung, Frische, Lebenszyklus sowie bestätigte Berechnungen umfassen. Sie können beliebige zusätzliche Schlüssel hinzufügen, wobei von den Nutzern erwartet wird, Schlüssel, die sie nicht erkennen, zu ignorieren, ohne dass dadurch Fehler entstehen – dadurch kann das Format erweitert werden, ohne die Agenten anderer zu beeinträchtigen. Zwei Dateinamen sind reserviert: index.md für eine Verzeichnisliste und log.md für eine Änderungshistorie, was Sie davor bewahrt, Konventionen erfinden zu müssen, die bereits in der Spezifikation festgelegt wurden. Die Spezifikation wurde als v0.1-Entwurf veröffentlicht, sodass mit weiteren Entwicklungen zu rechnen ist; prüfen Sie daher vor dem Erstellen von etwas Ernstem das Repository auf die aktuelle Version.
Links bilden das Netzwerk
Weil die Dateien reiner Markdown sind, verbinden sich Konzepte über gewöhnliche [Text](andere-Datei.md)-Links miteinander, und diese Links bilden die Kanten eines Graphen, der sich in der Ordnerstruktur befindet – ohne zusätzliche Datenbank. Eine gültige Konzeptdatei sieht so aus:
---
type: Metric
title: Monthly Revenue
description: Total money earned each month.
resource: https://console.cloud.google.com/bigquery?p=project&d=dataset&t=revenue
tags: [finance, monthly]
---
Revenue is counted after refunds are removed.
See also: [customer_acquisition_cost.md](customer_acquisition_cost.md)
Ein Agent, der revenue.md liest, erfährt, dass ein verwandtes Konzept in customer_acquisition_cost.md zu finden ist. Was die Verlinkung bedeutet, ergibt sich weiterhin von demjenigen, der die Dateien geschrieben hat, da das Format nicht vorgibt, dies für den Benutzer zu verstehen.
Testen in fünf Minuten
Die Spezifikation enthält echte Beispielmengen, die aus GA4-E-Commerce-Daten, Stack Overflow- und Bitcoin-Blockchain-Daten erstellt wurden. Ein Referenzagent, der BigQuery-Datensätze durchsucht und OKF-Dokumente erstellt, hat sie automatisch erzeugt, und alles befindet sich in einem einzigen Apache 2.0-Repository:
git clone https://github.com/GoogleCloudPlatform/knowledge-catalog.git
cd knowledge-catalog/okf
# Add your own concept
cat > new_metric.md <<'EOF'
---
type: Metric
title: Net Promoter Score
description: Measure of customer loyalty.
resource: https://console.cloud.google.com/bigquery?p=company&d=metrics&t=nps
tags: [customer, loyalty]
---
EOF
Jedes Beispielpaket enthält eine viz.html-Datei. Öffnen Sie sie in jedem Browser, um ein interaktives Diagramm des Pakets mit Knoten, Verbindungen, Suchfunktionen und Filtern zu erhalten – ohne dass ein Backend oder Server erforderlich ist. Eine Einschränkung besteht darin, dass die Erstellung einer viz.html-Datei für Ihr eigenes Paket bedeutet, das kleine Referenztool in dem Repository auszuführen. Dieses wandelt das Paket in eine einzige, selbstständige HTML-Seite um, die auf Cytoscape.js und marked.js basiert – ebenfalls ohne Backend, lediglich eine Datei, die Sie an einen Kollegen per E-Mail senden können.
Vorteile
- Niedrigere Kosten: Die Definition wird nur einmal festgehalten und direkt gelesen, sodass Sie nicht mehr fünfzig Mal am Tag dafür bezahlen müssen.
- Schnellere Ladezeit: Es handelt sich um reinen Text auf der Festplatte, ohne Netzwerkverkehr zu einem Wissensdienst und ohne Einbettungsschritt vor der Verwendung.
Die Überprüfbarkeit ist ein weiterer Vorteil. Angenommen, ein Agent schlägt diese Änderung vor:
- Revenue is recognized when an order is placed.
+ Revenue is recognized after delivery and the 30-day return window.
Das ist ein einfacher git Diff, und ein Prüfer sieht genau, was sich geändert hat. Das ist viel einfacher zu beurteilen als eine stille Aktualisierung, die in einem proprietären Wissenssystem verborgen ist.
Wo es nachlässt
- Es behebt keine fehlerhaften Definitionen. OKF standardisiert den Container und nicht den Inhalt, sodass, wenn sich ein Team nicht darauf einigen kann, was ein aktiver Benutzer bedeutet, eine Markdown-Datei keine Einigung erzwingen wird.
- Jemand muss es pflegen. Dateien werden veraltet, und das
timestamp-Feld sowielog.mdhelfen nur, wenn Menschen oder Agenten sie aktualisieren. Veraltete Informationen können mehr Schaden anrichten als gar keine, da die Agenten alles glauben, was sie finden. - Es handelt sich um einen jungen Entwurf, der ausdrücklich unvollendet ist, sodass Felder und Konventionen sich ändern können, und Frühnutzer sollten mit Veränderungen rechnen.
- Die Bedeutung wird nicht vorgeschrieben. Ein Link gibt an, dass zwei Konzepte miteinander verbunden sind, aber nicht wie, und die Beziehung wird in Prosa beschrieben, die flexibel, aber auch unklar ist. Strikt typisierte Beziehungen erfordern weiterhin eine echte Graph-Datenbank.
- Bislang gibt es nur wenige Nutzer. Fast alle Ersteller und Verarbeiter zum Zeitpunkt des Launches kamen von Google, und das Format kann nur dann erfolgreich sein, wenn weitere Tools und Teams es übernehmen.
OKF neben RAG und MCP
Im aktuellen Stack wird nichts weggeworfen, da OKF darunter eingefügt wird. RAG findet weiterhin relevante Abschnitte, wenn eine Anfrage eintrifft, und OKF stellt ihm saubereren, vorgestrukturierten Text zur Verfügung, wodurch die Erstellung von Embeddings genauer und kostengünstiger wird. MCP, Anthropics Model Context Protocol, überträgt den Kontext während eines Gesprächs, und OKF kann darunter als Quelle dienen, aus der diese Tools schöpfen. MCP kümmert sich um den Ablauf, während OKF die Definitionen speichert, sodass diese nicht jedes Mal neu berechnet werden müssen. Die drei Schichten sehen so aus:
OKF
↓
"What does this concept mean?"
RAG
↓
"Which pieces of knowledge should I retrieve?"
MCP
↓
"How does the agent interact with the tools and context?"
Jede Schicht löst ein anderes Problem, weshalb OKF eher als gemeinsame Wissensschicht unter beiden betrachtet werden sollte als als Konkurrent. Markdown-Dateien klingen kaum nach einer Produktvorstellung, doch manchmal ist die unscheinbare Option die, die funktioniert.
Sollten Sie es verwenden?
Für jeden Agenten, der Fragen zu Ihren Daten, Metriken oder Systemen beantwortet, lautet die Antwort ja – probieren Sie es aus. Der Versuch kostet fast nichts: Schreiben Sie drei Dateien, verknüpfen Sie sie, weisen Sie den Agenten auf den Ordner hin, und schon nach einem Nachmittag wissen Sie, ob es hilft. Wenn Ihr Wissen im Kopf einer Person oder in einer unübersichtlichen Wiki-Struktur liegt, bietet OKF einen unscheinbaren, versionierbaren Ort, an dem Sie es endlich aufschreiben können – was mit oder ohne Agent lohnenswert sein kann. Wenn Sie strenge Schemata, typisierte Beziehungen oder strenge Verwaltungsregeln benötigen, ist OKF derzeit noch zu locker, daher behalten Sie Ihren Katalog bei und exportieren Sie eventuell später ein Paket.
Fangen Sie nicht mit der gesamten Unternehmens-Wissensdatenbank an. Wählen Sie einen kleinen Bereich, zum Beispiel:
metrics/
active-user.md
revenue.md
conversion-rate.md
systems/
payments-api.md
orders-api.md
runbooks/
payment-failure.md
Verknüpfen Sie die Dateien, übergeben Sie sie einem einzigen Agenten und messen Sie, was sich ändert. Das ist ein weitaus besseres Experiment als drei Monate, die mit der Entwicklung einer Unternehmens-OKF-Plattform verbracht werden, bevor gezeigt werden kann, dass sie benötigt wird.
Ein einziges erforderliches Feld sowie ein Ordner mit Markdown-Dateien werden allein keine schlechte Dokumentation beheben. Was sie bieten, ist ein gemeinsamer, langweiliger, aber portabler Ort für die gute Dokumentation, die ein Team bereits besitzt – was auf dem Papier mehr wert ist, als es klingt.