10 Min. Lesezeit

Open Knowledge Format (OKF): Nutzen & Grenzen für KI-Agenten

Open Knowledge Format (OKF): Wie der offene Markdown-Standard KI-Agenten kuratiertes Wissen liefert – Aufbau, Abgrenzung zu RAG, Stärken und Grenzen.

Titelbild zu „Open Knowledge Format (OKF): Nutzen & Grenzen für KI-Agenten“

KI-Agenten scheitern oft an fehlendem Kontext: Sie wissen zu wenig über Anwendungen, Prozesse, Datenmodelle oder Fachbegriffe eines Unternehmens. Genau dort setzt das Open Knowledge Format, kurz OKF, an.

OKF beschreibt einen offenen, portablen Weg, Wissen für Sprachmodelle und Agenten bereitzustellen. Statt Wissen nur lose in Dokumenten, Wikis oder Code-Kommentaren zu verteilen, wird es in einer klaren Ordnerstruktur aus Markdown-Dateien mit Metadaten organisiert. Das Ziel ist simpel: Ein Agent soll schneller verstehen, wie eine bestimmte Domäne aufgebaut ist, welche Konzepte zusammenhängen und wo die eigentlichen Quellen liegen.

In diesem Artikel geht es darum, was OKF ist, wie es funktioniert, wo es sich von RAG unterscheidet und für welche Anwendungsfälle sich das Format wirklich lohnt.

Was ist das Open Knowledge Format?

Das Open Knowledge Format ist ein offener Standard für sogenannte Wissens-Bundles. Gemeint ist damit eine Sammlung von Wissensdokumenten in einer hierarchischen Ordnerstruktur. Jedes Dokument beschreibt ein Konzept, eine Komponente, eine Datenquelle oder einen fachlichen Zusammenhang. Veröffentlicht wurde die Spezifikation in Version 0.1 im Juni 2026 von Google Cloud — als bewusst anbieterneutraler Standard.

Technisch besteht OKF aus:

  • Markdown-Dateien für die Inhalte
  • YAML-Front-Matter für Metadaten am Dateianfang
  • Ordnern und Unterordnern für die Struktur
  • Index-Dateien, die Inhalte eines Bereichs kurz einordnen
  • Links zwischen Konzepten, damit Agenten Zusammenhänge erkennen
  • Zitaten oder Verweisen auf externe Quellen

Der Clou dabei: Das Format ist nicht an einen einzelnen Anbieter gebunden. Ein Wissens-Bundle kann prinzipiell zwischen Tools, Teams und Agenten ausgetauscht werden.

Welches Problem OKF löst

Viele KI-Systeme arbeiten mit allgemeinem Weltwissen plus etwas Laufzeitkontext. Das reicht für Standardaufgaben oft aus. Es reicht aber nicht, wenn ein Modell eine konkrete Anwendung, einen internen Prozess oder eine Fachdomäne korrekt verstehen soll.

Typische Probleme ohne kuratierten Kontext:

  • Ein Agent kennt interne Begriffe nicht.
  • Er verwechselt ähnliche Komponenten oder APIs.
  • Er muss Antworten bei jeder Anfrage neu aus unstrukturierten Quellen herleiten.
  • Wichtige Zusammenhänge zwischen Konzepten gehen verloren.
  • Wissen bleibt in Code, Tabellen, Tickets und Notizen verteilt.

OKF setzt hier auf einen anderen Ansatz: Wissen wird vorab kuratiert und in einer Form abgelegt, die für Menschen lesbar und für Agenten gut navigierbar ist.

Wie ein OKF-Bundle aufgebaut ist

Ein Bundle ist eine eigenständige Wissenssammlung. Darin liegen einzelne Wissensdokumente, meist als Markdown-Dateien. Jedes Dokument beschreibt genau ein Konzept oder eine Einheit.

Aufbau eines OKF-Bundlesbundle/index.mdkonzepte/kunde.mdapi.mdindex.mdEin Konzept = eine DateiFront Matter (YAML)type (Pflicht) · title · resource · tags · timestampBodyInhalt in Markdown, frei strukturiertCross-LinksVerweise auf andere Konzepte im BundleCitationsBelege und externe Quellen
Ein OKF-Bundle: Ordnerstruktur mit Index-Dateien links, Anatomie einer Konzept-Datei rechts

Die wichtigsten Bausteine

  • Konzept: Eine einzelne Wissenseinheit, zum Beispiel ein Kunde, eine API, eine Tabelle oder ein Feature.
  • Concept ID: Der Pfad innerhalb der Ordnerstruktur, also praktisch die Adresse des Konzepts.
  • Front Matter: YAML-Metadaten am Anfang der Datei.
  • Body: Der eigentliche Textinhalt in Markdown.
  • Cross-Links: Verlinkungen auf andere Konzepte im Bundle.
  • Citations: Verweise auf externe Quellen oder Belege.

Welche Metadaten vorgesehen sind

Im Standard ist nur ein Feld verpflichtend: type. Alle anderen Metadaten sind optional, aber sinnvoll.

Typische Felder sind:

  • type
  • title
  • description
  • resource
  • tags
  • timestamp

Daneben lassen sich weitere Schlüssel ergänzen, wenn sie für den eigenen Anwendungsfall nötig sind.

Warum die Index-Dateien wichtig sind

Ein zentrales Element von OKF sind Index-Dateien, sowohl global als auch in Unterordnern. Sie helfen Agenten beim Navigieren durch große Wissensbestände. Statt nur einen Verzeichnisbaum mit Dateinamen zu sehen, bekommt der Agent zu jedem Bereich eine kurze Einordnung.

Das ist bei großen Bundles hilfreich. Wenn Tausende Dateien vorliegen, ist ein bloßer Dateiname oft zu wenig. Eine gute Index-Datei spart Suchschritte und reduziert unnötigen Kontextverbrauch.

Was OKF von einem normalen Wiki unterscheidet

Auf den ersten Blick wirkt OKF vertraut. Markdown-Dateien in Ordnern, interne Links, Struktur per Verzeichnisbaum. Das gibt es seit Jahren in Wissenswerkzeugen und persönlichen Notizsystemen.

Der Unterschied liegt weniger im Dateiformat als in der Absicht:

  • Ein klassisches Wiki ist oft für Menschen optimiert.
  • OKF ist zusätzlich für Agenten und Sprachmodelle strukturiert.
  • Die Metadaten und Index-Dateien machen Navigation maschinenfreundlicher.
  • Das Bundle ist portabel und kann in verschiedene Systeme übernommen werden.

Dadurch wird aus einer losen Sammlung von Notizen eher eine kuratierte Wissensschicht für KI-Anwendungen.

OKF vs. RAG: Ersetzt das Format Retrieval?

Kurz gesagt: nein.

Rund um neue Wissensformate taucht schnell die Behauptung auf, RAG sei damit überflüssig. Das klingt griffig, hilft in der Praxis aber wenig. OKF und RAG lösen unterschiedliche Probleme.

OKF und RAG lösen unterschiedliche ProblemeOKF — kuratierte Wissensschichtvorab strukturiert und erklärtBegriffe, Beziehungen, Verweiseportabel zwischen Tools und Teamsversionierbar und auditierbarRAG — Laufzeit-Retrievaldurchsucht Quellen bei der Anfragebreite, dynamische Beständeunstrukturierte Dokumenteaktueller Stand zur LaufzeitIn der Praxis: kombinierenOKF beschreibt, was bekannt ist — RAG holt Details zur Laufzeit
OKF und RAG ergänzen sich: kuratierte Fakten plus dynamisches Retrieval

Wofür RAG gut ist

RAG, also Retrieval-Augmented Generation, durchsucht vorhandene Datenquellen und zieht bei Bedarf relevante Ausschnitte in den Prompt. Das ist nützlich, wenn Wissen breit verteilt, häufig aktualisiert oder zu groß für manuelle Kuratierung ist.

Wofür OKF gut ist

OKF beschreibt eine kompilierte Wissensschicht. Wissen wird vorab strukturiert formuliert, statt es erst im Moment der Anfrage aus beliebigen Textstücken zusammenzusuchen.

Das bringt Vorteile, wenn:

  • Begriffe sauber definiert werden müssen
  • Zusammenhänge zwischen Komponenten wichtig sind
  • Agenten sich in einer Anwendung oder Codebasis zurechtfinden sollen
  • Wissen zwischen Teams oder Tools austauschbar sein soll

Warum sich beides ergänzt

Ein praktisches Setup kombiniert oft beides:

  • OKF für kuratierte, deklarative Fakten
  • RAG für dynamische, breite oder unstrukturierte Quellen

Anders gesagt: Das eine beschreibt, was bekannt ist. Das andere hilft dabei, zusätzliche Details zur Laufzeit zu holen.

Robuste Datenpipelines und saubere Quellen sind dafür meist die Voraussetzung — eine stabile Grundlage im Data Engineering & Governance zahlt an dieser Stelle direkt ein.

OKF und Agent Skills: Wo der Unterschied liegt

OKF wird leicht mit Skill-Formaten für Agenten verwechselt, weil beides auf Ordnern, Markdown und progressiver Nachladung aufbauen kann.

Die Rollen sind aber verschieden:

  • Skills erklären einem Agenten, wie er eine Aufgabe ausführt.
  • OKF erklärt einem Agenten, was in einer bestimmten Welt oder Domäne gilt.

Ein Skill kann also prozedurales Know-how enthalten, etwa Ablaufwissen oder auszuführende Schritte. Ein OKF-Bundle enthält eher deklaratives Wissen, also Fakten, Begriffe, Beziehungen und Verweise.

In der Praxis lassen sich beide Ebenen gut kombinieren. Ein Agent-Skill kann auf ein OKF-Bundle verweisen, um domänenspezifischen Kontext nachzuladen.

Die Rolle des resource-Felds: besser verlinken als kopieren

Ein besonders nützliches Detail in OKF ist das Feld resource. Damit verweist ein Wissensdokument auf die eigentliche Quelle, statt deren Inhalt vollständig zu duplizieren.

Das kann zum Beispiel sein:

  • eine Python-Datei
  • eine Datenbanktabelle
  • ein API-Endpunkt
  • eine andere technische Quelle

Das hilft gegen ein altes Problem: veraltete Wissensbestände. Wenn eine Markdown-Seite zu viel Inhalt kopiert, driftet sie schnell von der Quelle weg. Eine schlanke Beschreibung plus Verweis auf die echte Quelle ist oft haltbarer.

Gerade für produktive KI-Systeme ist das eng mit Datenqualität verknüpft. Wenn Quellen unsauber oder uneinheitlich sind, hilft das beste Wissensformat nur begrenzt.

Warum OKF für große Wissensbestände interessant ist

Das Format ist simpel, aber genau darin liegt sein Reiz. Markdown-Dateien sind:

  • leicht lesbar
  • mit Versionskontrolle gut vergleichbar
  • auditierbar
  • nicht proprietär

Wer technische Dokumentation, Domänenwissen oder Architekturwissen verwalten will, bekommt damit eine transportable Form, die sich zippen, in Repositories speichern und zwischen Systemen austauschen lässt.

Das ist besonders nützlich, wenn Agenten über größere Anwendungslandschaften arbeiten sollen. Statt sich mühsam durch eine Codebasis oder Dokumentensammlung zu hangeln, können sie auf eine vorstrukturierte Wissensebene zugreifen.

Low-Poly-Diorama: Wissens-Bundles wandern auf einem Förderband zwischen zwei Teams

Wie Agenten ein solches Wissenssystem pflegen können

Ein interessanter Gedanke hinter dem LLM-Wiki-Ansatz ist: Sprachmodelle eignen sich gut für die lästige Bibliotheksarbeit.

Dazu gehören Aufgaben wie:

  • Querverweise nachziehen
  • neue Dateien einordnen
  • Änderungen in mehreren Wissensseiten gleichzeitig berücksichtigen
  • Index-Dateien aktualisieren

Gerade diese Pflegearbeit führt bei klassischen Wikis oft dazu, dass sie irgendwann veralten. Ein Agent kann hier helfen, solange es Guardrails und menschliche Kontrolle gibt.

Automatische Pflege mit GuardrailsQuelle ändert sichCode · Tabelle · APIAgent aktualisiertBundle-DateienPrüfungen laufenURLs · Belege · typeMensch gibt freiFreigabe und MergePrüfung fehlgeschlagen: Agent korrigiert erneut
Automatische Bundle-Pflege: deterministische Prüfungen und menschliche Freigabe als Guardrails

Warum Validierung wichtig ist

Bei automatischer Pflege reicht es nicht, den Agenten einfach schreiben zu lassen. Sinnvoll sind deterministische Prüfungen an der Schreibstelle.

Beispiele für solche Prüfungen:

  • Wurde eine referenzierte URL tatsächlich abgerufen?
  • Wurden Belege entfernt, obwohl sie vorher vorhanden waren?
  • Wurde eine verifizierte Struktur unzulässig verkleinert oder beschädigt?
  • Passt die erzeugte Seite zum angegebenen type?

Damit sinkt das Risiko, dass ein Agent erfundene Details einträgt oder belastbare Informationen versehentlich überschreibt.

Die größten Vorteile von OKF

1. Portabilität

Wissen bleibt nicht in einem einzelnen Tool eingeschlossen. Ein Bundle kann weitergegeben, versioniert und in anderen Umgebungen verarbeitet werden.

2. Gute Lesbarkeit

Markdown und YAML sind einfach. Das senkt die Hürde für Teams, die kein komplexes Spezialformat pflegen wollen.

3. Bessere Navigation für Agenten

Index-Dateien und Metadaten helfen Sprachmodellen, große Wissensräume gezielter zu erkunden.

4. Gute Kombination mit anderen Ansätzen

OKF muss nicht an die Stelle von RAG treten. Es kann als kuratierte Ebene darüber oder daneben arbeiten.

5. Versionierbarkeit und Nachvollziehbarkeit

Änderungen an Markdown-Dateien lassen sich in Git oder ähnlichen Systemen nachvollziehen. Das ist für technische und regulatorische Kontexte nützlich.

Die Grenzen und Schwächen von OKF

Das Format ist nützlich, löst aber einige Probleme bewusst nicht.

Freitext-Typen ohne zentrales Vokabular

Das Pflichtfeld type ist nicht zentral standardisiert. Das macht das Format flexibel, kann aber beim Zusammenführen mehrerer Bundles zu Reibung führen.

Wenn ein Team etwa customer nutzt und ein anderes client, dann sind damit womöglich dieselben Dinge gemeint, aber maschinell sieht es erst einmal nach zwei verschiedenen Typen aus.

Ungetypte Beziehungen

Links zwischen Konzepten stellen Beziehungen her, aber die Art der Beziehung wird nicht formal als Kante modelliert. Die Bedeutung steckt im Fließtext.

Das reicht oft aus, ist aber schwächer als ein streng typisiertes Wissensgraph-Modell.

Pflegeaufwand

Die Struktur ist leicht. Die Kuratierung nicht. Ein Bundle wird nur dann wertvoll bleiben, wenn Änderungen an den Quellen zuverlässig nachgezogen werden.

Drift von der Quelle

Ein kompiliertes Wissensartefakt kann kurz nach seiner Erstellung schon veraltet sein. Ohne automatische Aktualisierung oder regelmäßige Prüfung verliert der Kontext an Qualität.

Tool-Unterstützung ist noch nicht selbstverständlich

Offen bedeutet nicht automatisch breit unterstützt. Solange gängige Wissens- und Agentenwerkzeuge das Format nicht nativ verstehen, bleibt zusätzliche Integrationsarbeit nötig.

Für welche Anwendungsfälle sich OKF besonders eignet

  • Codebasen und Entwicklerplattformen, bei denen Features, Endpunkte und Komponenten als Konzepte dokumentiert werden sollen
  • Interne Fachdomänen, in denen Begriffe, Regeln und Zusammenhänge klar definiert werden müssen
  • Agenten für Wissensarbeit, die reproduzierbar auf kuratiertes Unternehmenswissen zugreifen sollen
  • Geteilte Wissenspakete, die zwischen Teams oder Partnern austauschbar sein sollen
  • Kompilierte Wissensschichten als Ergänzung zu Laufzeit-Retrieval

Wer genau solche Assistenten aufbauen will, findet bei KI-Agenten für Wissensarbeit den passenden Kontext für typische Architekturfragen.

Wann OKF eher nicht die erste Wahl ist

Das Format passt weniger gut, wenn:

  • Wissen extrem häufig wechselt und kaum kuratierbar ist
  • primär Volltextsuche über große, rohe Dokumentenmengen gefragt ist
  • formale Ontologien mit streng typisierten Beziehungen nötig sind
  • niemand die Pflegeverantwortung übernimmt

Dann sind klassische Retrieval-Ansätze, Datenkataloge oder stärker strukturierte Wissensgraphen oft geeigneter.

Best Practices für den Einsatz von OKF

Begriffe früh vereinheitlichen

Auch wenn type frei wählbar ist, lohnt sich ein internes Vokabular. Sonst entsteht schnell ein Wildwuchs an Bezeichnungen.

Dokumente schlank halten

Nicht alles in Markdown kopieren. Besser kurz erklären und auf die Quelle verweisen.

Index-Dateien ernst nehmen

Für Agenten sind sie Navigationshilfe und Einstiegspunkt zugleich — eine gute Index-Datei spart bei jeder Anfrage Suchschritte.

Automatische Aktualisierung einplanen

Neue Dateien, Änderungen und Löschungen sollten Trigger für die Pflege des Bundles sein.

Menschliche Prüfung beibehalten

Ein Agent kann aktualisieren. Freigeben sollte im Zweifel trotzdem ein Mensch.

Mit bestehenden KI-Workflows verbinden

OKF entfaltet den größten Nutzen als Teil einer breiteren Architektur aus Datenquellen, Retrieval und Modellintegration. Für solche Setups ist eine saubere LLM Implementierung und Integration meist der entscheidende Hebel.

Häufige Fragen zu OKF

Ist OKF ein Ersatz für eine Vektordatenbank?

Nein. Ein OKF-Bundle ist eine kuratierte Wissensschicht. Eine Vektordatenbank dient primär dem Retrieval über Einbettungen. Beides kann zusammen eingesetzt werden.

Ist OKF nur für Entwickler gedacht?

Nicht zwingend. Der Nutzen ist in technischen Domänen besonders offensichtlich, aber auch Fachwissen aus Vertrieb, Operations oder Compliance kann so strukturiert werden.

Muss jede Wissensseite stark standardisiert sein?

Nein. Im Body gibt es keine festen Pflichtabschnitte. Gerade das macht das Format flexibel. Die Kehrseite ist, dass gute Qualitätssicherung umso wichtiger wird.

Kann man OKF mit bestehenden Wiki-Systemen nutzen?

Ja, aber oft nicht ohne Reibung. Nicht jedes Tool interpretiert Index-Dateien oder Metadaten so, wie es der Standard vorsieht.

Warum ist das Pflichtfeld type so wichtig?

Weil es die minimale maschinenlesbare Einordnung eines Konzepts liefert. Darauf können Validierungslogik, Erzeugungsregeln und Agentenverhalten aufbauen.

Fazit

OKF löst nicht jedes Wissens- und Retrievalproblem. Als offenes, einfaches und portables Format für kuratierte Wissensschichten ist es aber ein sehr brauchbarer Baustein.

Seine Stärke liegt darin, einer KI geordnetes, erklärtes und verlinktes Domänenwissen zu geben, das sich zwischen Systemen transportieren lässt — ohne unstrukturierte Datenberge verdrängen zu müssen.

Für Agenten, die in einer konkreten Anwendungswelt zuverlässig arbeiten sollen, ist genau diese Art von Kontext oft der Unterschied zwischen beeindruckender Demo und nützlichem System im Alltag.