Googles Open Knowledge Format: Ein erster Blick aus der Praxis

Googles Open Knowledge Format: Ein erster Blick aus der Praxis auf OKF

Ich hätte es fast ignoriert. Wieder eine Spezifikation, wieder ein Akronym, wieder eine "herstellerunabhängige Standard"-Pressemitteilung, die an einem Freitag in meinem Feed landete. Google Cloud veröffentlichte das Open Knowledge Format — OKF v0.1 — am 12. Juni 2026, und meine ehrliche erste Reaktion war ein Achselzucken. Wir haben schon ein Dutzend "das verändert alles"-Formate kommen und still wieder verschwinden sehen.

Dann öffnete ich die Spezifikation. Und mir wurde klar, dass das Ganze einfach nur Markdown-Dateien mit ein paar Zeilen YAML oben sind, gruppiert in einem Ordner. Kein SDK. Keine Runtime. Kein Kompressionsschema. Keine API zum Aufrufen. Ein "Wissensbündel" im Open Knowledge Format ist, fast beleidigend, einfach nur Dateien, die man in einem Texteditor schreiben könnte.

Das war der Teil, der mich vom Scrollen abhielt und mich einen Testordner anlegen ließ. Denn ich habe das letzte Jahr damit verbracht, Agent-Workflows zu bauen, und das Einzige, wogegen ich immer wieder anlaufe, ist dieselbe Wand: Meine Agents sind brillant im Denken und miserabel im Erinnern. Sie scrapen, fassen zusammen und leiten denselben Kontext jede Sitzung aufs Neue ab. Wenn ein Format, das so simpel ist, einem Agent einen sauberen, strukturierten Ort geben könnte, um Wissen daraus zu lesen — statt es jedes Mal aus rohem HTML neu abzuleiten — dann ist das einen Nachmittag wert.

Also verbrachte ich diesen Nachmittag damit. Ich baute ein kleines Bündel per Hand aus der veröffentlichten Spezifikation, ließ meine eigene Website durch einen Community-Generator laufen und öffnete das Ergebnis in Obsidian, um zu sehen, ob der Anspruch "menschenfreundlich" den Kontakt mit der Realität übersteht. Das ist, was ich fand — was OKF tatsächlich ist, die Teile, die die Ankündigungen richtig treffen, und der viel größere Stapel an Dingen, die zukunftsgerichtete Versprechen statt gelieferter Realität sind. Ich werde deutlich machen, was was ist, denn die Lücke dazwischen ist, wo der Großteil des Hypes lebt.

Was ist das Open Knowledge Format eigentlich?

Das Open Knowledge Format ist eine offene, herstellerunabhängige Spezifikation von Google Cloud zum Speichern von Wissen als Verzeichnis von Markdown-Dateien, jeweils mit YAML-Front-Matter, konzipiert für die Lesbarkeit durch sowohl Menschen als auch KI-Agents. Das ist die ganze Sache. Ein Satz deckt es ab.

Lässt man die Ankündigungssprache weg, trifft OKF genau drei strukturelle Entscheidungen:

• Wissen ist ein Ordner mit Markdown-Dateien. Google nennt einen Ordner ein Wissensbündel. Es ist ein Verzeichnis — möglicherweise mit Unterverzeichnissen — voller .md-Dateien.
• Jede Datei ist ein Konzept. Keine Webseite. Kein ganzes Dokument. Eine einzelne, diskrete Wissenseinheit: ein Playbook, eine Metrikdefinition, ein Runbook, eine API-Beschreibung, eine einzelne Entität. Karpathys Intuition, dass Wissen in Konzeptseiten atomisiert werden sollte statt als lange Dokumente abgelegt, ist direkt in das Format eingebaut.
• Jedes Konzept deklariert einen type. Die Spezifikation verlangt genau ein Front-Matter-Feld in jeder Datei: type. Alles andere — title, description, resource, tags, timestamp — ist empfohlen, aber optional.

Hier ist eine Konzeptdatei, die ich per Hand geschrieben habe, um das Format zu testen, modelliert nach einem meiner eigenen internen Playbooks:

---
type: playbook
title: Client Onboarding Sequence
description: The exact steps I run when a new AI automation client signs.
tags: [onboarding, process, clients]
resource: https://mejba.me/onboarding
timestamp: 2026-06-18
---

# Client Onboarding Sequence

When a new client signs, I run these steps in order. Each one has a
trigger and a definition of done — agents reading this should treat the
"done" condition as the success check.

## 1. Access provisioning
Grant repo + cloud read access within 24h of signature...

## 2. Context capture call
A 45-minute recorded call. The recording becomes its own concept file...

Das ist ein vollständiges, spezifikationskonformes OKF-Konzept. Kein Tool hat es erzeugt. Ich habe es getippt. Und hier ist der leise wichtige Teil: Es rendert sauber in jeder Markdown-App, in die ich es geworfen habe — GitHub zeigte eine Vorschau, Obsidian indexierte das Front Matter als Eigenschaften, und es würde ohne Widerstand in Notion passen. Das Format verlangt nicht, dass man etwas Neues übernimmt. Es beschreibt, was man wahrscheinlich bereits tut, nur mit einer vereinbarten Form.

Aber eine einzelne Datei ist nicht die interessante Einheit. Das Bündel ist es. Lassen Sie mich also zeigen, wie ein Bündel tatsächlich zusammengesetzt ist — denn hier hört OKF auf, "eine Markdown-Datei" zu sein, und beginnt, ein System zu werden.

Wie ein Wissensbündel strukturiert ist

Ein Wissensbündel ist ein Verzeichnis von Konzepten, und die Spezifikation gibt ihm zwei optionale, aber mächtige organisierende Dateien, die einen flachen Ordner in etwas verwandeln, durch das ein Agent intelligent navigieren kann.

Die Struktur sieht so aus:

my-knowledge-bundle/
├── index.md          # Übersicht + Verzeichnisliste (optional)
├── log.md            # chronologische Änderungshistorie (optional)
├── onboarding.md     # ein Konzept im Bündel-Stammverzeichnis
├── pricing.md        # ein weiteres Konzept
└── playbooks/        # ein Unterverzeichnis gruppiert verwandte Konzepte
    ├── index.md      # Unterverzeichnisse können eigene Indizes haben
    ├── refunds.md
    └── escalation.md

Die zwei speziellen Dateien sind, wo das Design clever wird.

index.md ist die Karte des Bündels. Sie listet auf, was im Verzeichnis ist, damit ein Agent das Bündel überblicken kann, bevor er irgendetwas liest. Das ist progressive Offenlegung — exakt dasselbe Muster, das gut gestaltete Agent-Skills effizient macht. Ein Agent liest den Index, entscheidet, welche drei von vierzig Konzeptdateien er tatsächlich braucht, und lädt nur diese. Er schüttet nicht den ganzen Ordner in den Kontext. Wenn Sie gegen das Token-Aufblähen gekämpft haben, das entsteht, wenn man alles ins Kontextfenster kippt, werden Sie erkennen, warum das wichtig ist — es ist dasselbe Prinzip, über das ich in meiner Analyse geschrieben habe, warum Kontextmanagement Konfiguration für KI-Agents schlägt. Der Index ist der Scheinwerfer; die Konzepte sind das, worauf er zeigt.

log.md ist das Gedächtnis des Bündels über seine eigenen Änderungen. Eine chronologische Geschichte der Aktualisierungen. Warum braucht ein Wissensformat ein Änderungsprotokoll? Weil OKF davon ausgeht, dass das Wissen lebt — dass es überarbeitet, widersprochen und korrigiert wird im Laufe der Zeit. Das Log ist, wie ein Agent (oder ein Mensch) nicht nur versteht, was das Wissen heute sagt, sondern wie es hierher gekommen ist.

Als ich mein Testbündel baute, war die Index-Datei das, was mich überzeugte. Ich schrieb fünf Konzeptdateien, schrieb dann eine index.md, die jede mit einer einzeiligen Beschreibung auflistete. Dann zeigte ich Claude auf den Ordner und stellte eine Frage, die nur ein Konzept beantworten konnte. Es las zuerst den Index, öffnete genau eine Datei und antwortete. Es berührte die anderen vier nie. Das ist der Unterschied zwischen einem Agent einen Bibliothekskartenkatalog zu geben versus jedes Buch auf seinen Schreibtisch zu kippen.

Nun — bevor das zu poliert klingt — lassen Sie mich ehrlich sein, wo die Einfachheit zur Einschränkung wird. Es gibt keine Durchsetzung. Nichts hindert Sie daran, vierzig Konzeptdateien ohne Index zu schreiben, mit inkonsistenten type-Werten und einem log.md, das eine Lüge ist. Das Format ist eine Konvention, keine Garantie. Was mich zum Vergleich bringt, den jeder immer wieder macht und leicht falsch versteht.

OKF vs. llms.txt vs. schema.org: Wo passt es hin?

Das ist die Frage, die ich innerhalb von zehn Minuten nach dem Lesen der Spezifikation hatte, und es ist die Frage, die die Ankündigungen am wenigsten klar beantworten. Wir haben bereits llms.txt. Wir haben bereits schema.org. Brauchen wir ein drittes Ding? Die kurze Antwort: Sie sitzen auf verschiedenen Ebenen, und OKF ist die tiefste.

So würde ich den Stack für KI-Sichtbarkeit im Jahr 2026 abbilden:

Denken Sie daran wie an ein Restaurant. llms.txt ist die Speisekarte, die dem Agent sagt, was verfügbar ist. Schema.org ist die Allergen- und Zutatenkennzeichnung, die Mehrdeutigkeit über jedes Gericht beseitigt. OKF ist das eigentliche Essen, angerichtet und verzehrfertig — das Wissen selbst, übergeben als sauberes Markdown-Konzept, statt den Agent zu zwingen, es aus gescraptem HTML zu reverse-engineeren.

Diese Einordnung ist wichtig wegen eines Vergleichs, den die Spezifikation implizit und den ich explizit mache: OKF ist das, wonach man greift, wenn schema.org keinen Platz mehr hat. Schema.org ist brillant für die Dinge, für die es Typen hat — Produkte, Rezepte, Events, Organisationen. Aber in dem Moment, in dem Ihr Wissen ein nuanciertes Playbook ist, ein proprietärer Prozess, eine hart erarbeitete Metrikdefinition oder eine Strategie, die auf keinen @type im Vokabular passt, hat schema.org nichts für Sie. OKF beschränkt Sie nicht auf ein vordefiniertes Vokabular. Ihr type kann playbook, runbook, case-study, pricing-logic sein — was auch immer Ihre Domäne braucht. Das ist der Kompromiss: schema.org gibt Ihnen maschinenvalidierte Strenge innerhalb eines festen Vokabulars; OKF gibt Ihnen offene Flexibilität mit fast keiner Validierung.

Und das wahrscheinliche Bindegewebe zwischen diesen Ebenen ist wieder llms.txt. Die zukunftsgerichtete Erwartung — und ich möchte dies klar als erwartet, nicht geliefert kennzeichnen — ist, dass Websites die Existenz eines OKF-Bündels über einen llms.txt-artigen Verweis signalisieren werden, auf dieselbe Weise, wie XML-Sitemaps und strukturierte Daten nach robots.txt kamen. Ab v0.1 gibt es kein formalisiertes Entdeckungsprotokoll, das in OKF selbst eingebaut ist. Das ist eine Lücke, und es ist die Art von Lücke, die ein v0.1 haben sollte.

Wenn Sie Content-Systeme bauen und diese Ebene lieber automatisiert als handgepflegt hätten, dann ist das genau die Art von Pipeline, die ich baue — das Umwandeln des Wissens einer Website in agent-lesbare Struktur wird zu einer eigenen Disziplin, und Sie können sehen, wie ich das angehe, in meiner Arbeit über die Automatisierung von SEO-Content-Workflows mit Claude Code. Aber Sie brauchen mich nicht, um anzufangen. Sie können heute Ihr erstes Bündel bauen, und das sollten Sie auch, denn das Lesen einer Spezifikation lehrt Sie fast nichts im Vergleich zum Schreiben eines schlechten Bündels.

Wie ich mein erstes OKF-Bündel gebaut habe (und was schiefging)

Ich wählte absichtlich zwei Wege: ein Bündel per Hand bauen, um das Format zu verstehen, und eine bestehende Website durch einen Generator laufen lassen, um zu sehen, was Automatisierung produziert. Der Kontrast lehrte mich mehr als jeder Weg für sich allein.

Weg eins: per Hand. Ich erstellte einen Ordner, schrieb fünf Konzeptdateien aus echten internen Dokumenten — meine Onboarding-Sequenz, meine Preislogik, zwei Playbooks und ein Glossar der Begriffe, die ich mit Kunden verwende. Das Front Matter war die einzige Reibung. Die Entscheidung über den type für jedes Konzept dauerte länger als das Schreiben des Inhalts, weil die Spezifikation Ihnen absichtlich nicht sagt, welche Typen Sie verwenden sollen. Ist mein Preisdokument ein pricing? Eine policy? Eine reference? Die Freiheit ist real, und die Entscheidungsmüdigkeit auch. Meine Erkenntnis: Wählen Sie Ihr Type-Vokabular zuerst, schreiben Sie es als eigenes Konzept auf und halten Sie sich daran. Inkonsistente Typen sind der schnellste Weg, ein Bündel zu erstellen, durch das ein Agent schlecht navigiert.

Dann schrieb ich die index.md per Hand und verstand sofort, warum sie in der Spezifikation optional, aber in der Praxis obligatorisch ist. Ohne sie ist ein Bündel ein Haufen. Mit ihr ist es ein Graph.

Weg zwei: ein Generator. Die Community bewegte sich schnell. Suganthan Mohanadasan — ein SEO, der bemerkenswerterweise seine eigene Website schon ein Markdown-Konzeptformat sprechen ließ, bevor Google OKF herausbrachte — baute einen kostenlosen OKF Bundle Generator, der eine URL oder Sitemap nimmt und ein herunterladbares Bündel plus eine Karte Ihres Contents produziert. Ich ließ einen Abschnitt meiner eigenen Website durchlaufen.

Das Ergebnis war aufrichtig nützlich und aufrichtig begrenzt zugleich, und die Begrenzung ist die ganze Lektion. Der Generator machte das Offensichtliche gut: Jede Seite wurde eine saubere Markdown-Datei mit vernünftigem Front Matter, querverlinkt, ohne HTML-Ballast. Aber er produzierte ein Konzept pro Seite — und das ist nicht wirklich, wofür OKF gedacht ist. Die Einheit von OKF ist das Konzept, nicht die Seite. Ein einzelner langer Blogpost von mir könnte vier verschiedene Konzepte enthalten, die in einem ordentlichen Bündel vier separate Dateien sein sollten, auf die ein Agent unabhängig verweisen kann. Der Generator übersetzte treu meine Seitenstruktur; er konnte den schwierigeren Akt der Konzeptextraktion nicht durchführen — eine Seite lesen und entscheiden, dass sie eigentlich drei Ideen enthält, die eigene Dateien verdienen.

Diese Lücke ist die eigentliche Chance, und ich sage es deutlich: Die wertvolle OKF-Tooling wurde noch nicht gebaut. Seite-zu-Markdown-Konverter sind ein gelöstes, kommodifiziertes Problem. Die Tools, die zählen werden, sind die, die Ihren unordentlichen, überlappenden Content lesen und ihn in saubere, deduplizierte Konzepte zerlegen, die Ihre tatsächliche Geschäftsstruktur widerspiegeln. Suganthans Begriff für das, was OKF ermöglicht — "semantisches Entbacken", zusammengebackenes Wissen zurück in strukturierte, interoperable Elemente aufbrechen — ist genau der Teil, den Automatisierung noch nicht geknackt hat. Ein Sprachmodell ist dafür gut geeignet, aber eines naiv auf "mache aus dieser Website Konzepte" zu richten, produziert immer noch Konzeptdateien, die sich überschneiden und widersprechen. Es gut zu machen ist ungelöst.

Wenn Sie lieber jemanden hätten, der diese Konzeptextraktions-Pipeline für Ihr Unternehmen baut, statt selbst damit zu ringen, ist das ein Projekt, das ich übernehme — Sie können die Art von Systemen, die ich baue, sehen auf fiverr.com/s/EgxYmWD. Aber bauen Sie aufrichtig zuerst ein Fünf-Dateien-Bündel per Hand. Es dauert zwanzig Minuten und lehrt Sie, was kein Tool kann.

Die Karpathy-Verbindung: Wissen, das sich selbst pflegt

OKF kommt nicht aus dem Nichts. Es ist die Formalisierung einer Idee, die Andrej Karpathy vorstellte — was er das LLM-Wiki-Muster nannte — und das Verständnis dieses Ursprungs sagt Ihnen, wohin sich das tatsächlich entwickelt.

Karpathys Argument ging gegen den Strom dessen, wie wir heute Retrieval betreiben. Das vorherrschende Muster, RAG, funktioniert, indem unstrukturierte Dokumente in Chunks aufgeteilt, eingebettet und die am besten passenden Chunks zur Abfragezeit abgerufen werden. Es ist mächtig, aber es ist grundsätzlich eine Suche über einen statischen Haufen. Der Haufen lernt nicht. Er versöhnt nicht. Wenn zwei Dokumente sich widersprechen, ruft RAG fröhlich beide ab und lässt das Modell es klären.

Karpathys LLM-Wiki dreht das Modell um: Statt eines statischen Haufens, den man durchsucht, pflegt man ein lebendiges Wiki, das das Modell selbst baut und überarbeitet. Neue Informationen werden nicht einfach angehängt — sie werden integriert. Das Modell aktualisiert die relevante Entitätsseite, überarbeitet eine Zusammenfassung, und wenn frische Daten einem alten Anspruch widersprechen, versöhnt es den Widerspruch, statt beides zu speichern. Die Wissensbasis ist ein dynamisches, sich entwickelndes Ding, und das Modell erledigt den Großteil der Pflege. Dieser letzte Teil ist der Durchbruch: Der Grund, warum Wikis normalerweise nicht skalieren, ist, dass Menschen sie pflegen müssen. Ein Agent, der sein eigenes Wiki pflegt, beseitigt den Engpass.

Man kann OKFs log.md und das Konzept-pro-Datei-Design als das On-Disk-Format für genau diese Vision sehen. Eine Konzeptdatei ist eine Entitätsseite. Das Log ist die Revisionshistorie. Die Struktur ist absichtlich einfach genug, dass ein Agent es nicht nur lesen, sondern auch schreiben kann — ein Konzept öffnen, einen Anspruch überarbeiten, an das Log anhängen, speichern. Das ist ein lebendiger Wissensgraph, den eine Maschine tatsächlich aktuell halten kann.

Ich jage einer selbstgebauten Version davon schon eine Weile nach, mit Obsidian als Speicher und Claude als Pfleger — ich habe das ganze Experiment aufgeschrieben in meinem Obsidian + Claude Code Persistent Memory Setup und einem verwandten Deep-Dive über den Aufbau einer Karpathy-Style RAG-Wissensbasis in Obsidian. OKFs Beitrag ist keine neue Idee darüber hinaus. Es ist eine gemeinsame Form. Der Grund, warum ein Standard hier wichtig ist, ist Interoperabilität: Wenn mein Agent und Ihr Agent beide OKF sprechen, könnte mein Onboarding-Bündel von Ihrem Agent ohne Übersetzung gelesen werden. Was zum Teil führt, der entweder am aufregendsten oder am meisten überversprochen ist, je nach Ihrer Skepsis.

Agentische Suchoptimierung und verkäufliches Wissen

Hier werden die Ankündigungen laut, also werde ich hier vorsichtig. Zwei große Behauptungen reisen mit OKF, und es sind beide plausible Richtungen statt aktuelle Realitäten. Ich werde den Mechanismus vom Marketing trennen.

Behauptung eins: OKF formuliert SEO in "agentische Suchoptimierung" um. Die Logik: Da KI-Agents zunehmend zwischen Menschen und Informationen vermitteln, verschiebt sich das Ziel von der Auffindbarkeit durch einen Such-Crawler zur Nutzbarkeit durch einen Agent. Statt eine Seite zu optimieren, damit ein Mensch darauf klickt, veröffentlichen Sie Wissen, damit ein Agent es direkt lesen, zitieren und danach handeln kann. Wenn Google selbst beginnt, Ihren Content als "Kontext, der an Agents ausgeliefert werden soll" zu beschreiben, ist es eine rationale Absicherung, ihn in der Form zu liefern, die Google beschreibt.

Ich denke, die Richtung ist real. Die Umsetzung ist unbewiesen. Es gibt, Stand Mitte 2026, keinen bestätigten Mechanismus, durch den das Veröffentlichen eines OKF-Bündels Ihre Sichtbarkeit in Googles agent-vermittelten Oberflächen verbessert. Google hat ein Format herausgebracht; es hat keinen Ranking-Vorteil für dessen Nutzung geliefert — oder versprochen. Behandeln Sie jeden, der "OKF für Rankings" verkauft, mit demselben Misstrauen, das Sie jemandem entgegenbringen würden, der Ihnen ein Meta-Keyword-Tag verkauft hat. Der ehrliche Zug ist: OKF macht Ihr Wissen sauberer und nützlicher für jeden Agent, der es liest, und das ist eine vertretbare Wette aus eigenem Verdienst, unabhängig davon, ob Google es jemals belohnt.

Behauptung zwei: Menschen werden OKF-Wissensbündel verpacken und verkaufen. Ein Anwalt verkauft ein Bündel kuratierter juristischer Playbooks. Ein Buchhalter verkauft Steuerstrategie-Konzepte. Ein SEO verkauft ein Bündel von Ranking-Heuristiken. Ein Unternehmen kauft diese und montiert sie in den Kontext seiner eigenen Agents. Weil ein Bündel nur ein Tarball aus Markdown ist, ist es trivial versendbar, auf jedem Git-Repo hostbar und wie jedes digitale Produkt lizenzierbar.

Diese finde ich überzeugender, weil der Mechanismus stimmt — ein Bündel ist aufrichtig eine portable, eigenständige Einheit von Expertise, und es gibt echte Nachfrage nach kuratiertem Kontext, den Agents konsumieren können. Aber es ist ein Markt, der noch nicht existiert, nicht etwas, das heute im großen Maßstab passiert. Dieselbe Reibung, die gute Bündel schwer zu generieren macht (Konzeptextraktion, Konsistenz, das Log ehrlich halten), macht gute verkäufliche Bündel noch schwieriger, weil Qualität jetzt ein Produktmerkmal ist. Ich würde wetten, dass dieser Markt entsteht. Ich würde nicht auf den Zeitplan wetten, und ich wäre skeptisch gegenüber der ersten Welle von "Expertise-Bündeln" auf dieselbe Weise, wie ich gegenüber jeder ersten Welle skeptisch bin.

Wo lässt das also einen Builder jetzt stehen? Mit einem klaren, risikoarmen Schritt und viel Geduld für den Rest.

Was ich heute tatsächlich mit OKF machen würde

Lassen Sie mich das konkret machen, denn "experimentiere damit" ist die Art von Rat, der gut klingt und nichts ändert. Hier ist die konkrete Abfolge, die ich durchlaufen würde, und was Sie von jedem Schritt erwarten können.

1. Lesen Sie die tatsächliche Spezifikation, nicht die Zusammenfassungen. Die OKF SPEC.md auf GitHub ist kurz und in fünfzehn Minuten lesbar. Jede Zusammenfassung aus zweiter Hand (einschließlich dieser) verliert Genauigkeit. Die Quelle ist die Quelle.

2. Bauen Sie ein Fünf-Dateien-Bündel per Hand. Wählen Sie ein echtes Stück Ihres eigenen Wissens — Ihre Prozesse, Ihre Produktdokumentation, Ihre hart erarbeiteten Heuristiken. Schreiben Sie fünf Konzeptdateien, eine index.md und eine log.md. Verwenden Sie kein Tool. Die Reibung ist die Bildung. Sie lernen mehr über Ihre eigene Wissensstruktur in zwanzig Minuten, als ein Generator Ihnen je sagen wird.

3. Öffnen Sie es in den Tools, die Sie bereits verwenden. Legen Sie den Ordner in Obsidian, pushen Sie ihn in ein GitHub-Repo, fügen Sie eine Datei in Notion ein. Bestätigen Sie selbst, dass "menschenfreundlich" standhält. Das ist die Eigenschaft, die OKF sicher zu übernehmen macht: Im schlimmsten Fall haben Sie etwas gut organisiertes Markdown geschrieben, das mit oder ohne jeden Agent Wert hat.

4. Zeigen Sie einem Agent auf das Bündel und stellen Sie eine Frage. Geben Sie Claude oder Gemini den Ordner und stellen Sie etwas, das nur ein Konzept beantworten kann. Beobachten Sie, ob er den Index zur Navigation verwendet. Das ist der Moment, in dem OKF aufhört, abstrakt zu sein — wenn Sie sehen, wie ein Agent die Karte überblickt und genau die richtige Datei öffnet, klickt das Design.

5. Schreiben Sie Ihr type-Vokabular als eigenes Konzept auf. Das ist die einzelne Gewohnheit mit dem größten Hebel. Die Freiheit der Spezifikation bei Typen ist ein zweischneidiges Schwert; die Bündel, die gut altern, sind die mit einem bewussten, dokumentierten Typsystem. Treffen Sie diese Entscheidung einmal, mit Absicht, und verweisen Sie darauf.

Was ich heute nicht tun würde: meine gesamte Content-Operation um OKF herum umstrukturieren, für "OKF-SEO"-Dienste bezahlen oder v0.1 als fertigen Standard behandeln. Google selbst nannte v0.1 einen Startpunkt, keine fertige Spezifikation. Darauf aufzubauen ist klug; Ihr Geschäft auf seine aktuelle Form zu verwetten ist es nicht.

Häufig gestellte Fragen

Was ist das Open Knowledge Format (OKF)?

Das Open Knowledge Format ist eine offene, herstellerunabhängige Spezifikation von Google Cloud, veröffentlicht als v0.1 am 12. Juni 2026, zum Speichern von Wissen als Verzeichnis von Markdown-Dateien mit YAML-Front-Matter — lesbar für sowohl Menschen als auch KI-Agents. Jede Datei repräsentiert ein Konzept und muss ein type-Feld deklarieren. Für die vollständige Strukturerklärung siehe den Bündelabschnitt oben.

Wie unterscheidet sich OKF von llms.txt?

OKF und llms.txt operieren auf verschiedenen Ebenen: llms.txt ist eine Entdeckungsdatei, die Agents auf Ihre wichtigen Ressourcen verweist, während OKF das kuratierte Wissen selbst als Konzept-Ebene Markdown-Dokumente übergibt. llms.txt ist die Speisekarte; OKF ist das Essen. Sie sind komplementär, und OKF-Bündel werden in Zukunft wahrscheinlich über einen llms.txt-artigen Verweis signalisiert.

Ist OKF ein SEO-Ranking-Faktor?

Nein — Stand Mitte 2026 hat Google keinen Ranking-Vorteil für das Veröffentlichen von OKF-Bündeln angekündigt. OKF macht Ihr Wissen sauberer und nützlicher für KI-Agents, die es lesen, was ein vertretbarer Grund zur Übernahme ist, aber behandeln Sie jede Behauptung, dass OKF direkt Rankings verbessert, mit Skepsis. Siehe den Abschnitt über agentische Suche oben für den vollständigen Vorbehalt.

Welche Tools kann ich verwenden, um OKF-Bündel zu erstellen?

Sie können OKF-Bündel per Hand in jedem Texteditor schreiben, da es sich um Markdown plus YAML handelt. Community-Generatoren wie Suganthans OKF Bundle Generator können eine Website in ein Basisbündel konvertieren, aber sie produzieren derzeit ein Konzept pro Seite statt echter Konzeptextraktion — die wertvollere Tooling zur Zerlegung von Content in saubere Konzepte wurde noch nicht gebaut.

Was ist Karpathys LLM-Wiki und wie hängt es mit OKF zusammen?

Das LLM-Wiki ist Andrej Karpathys Konzept einer lebendigen Wissensbasis, die ein KI-Modell selbst baut und pflegt — neue Informationen integrieren, Ansprüche überarbeiten und Widersprüche versöhnen, statt einen statischen Haufen wie bei traditionellem RAG zu durchsuchen. OKF ist im Wesentlichen das On-Disk-Dateiformat für diese Vision, mit Konzeptdateien als Entitätsseiten und einer Logdatei als Revisionshistorie.

Der wahre Grund, warum ich froh bin, dass ich es nicht ignoriert habe

Ich ging hinein mit der Erwartung, dass es eine weitere Spezifikation zum Ablegen unter "interessant, nie benutzt" wäre. Ich kam heraus mit einer veränderten Art, wie ich mein eigenes Wissen speichere — nicht weil OKF fertig ist, sondern weil es auf etwas Wahres zeigte.

Das, was es richtig macht, ist bescheiden: Wissen für Agents sollte kuratiert, atomisiert und übergeben werden, nicht gescrapt, in Chunks aufgeteilt und reverse-engineered. Das stimmt, unabhängig davon, ob Googles spezifisches Format gewinnt. Das Bündel, das ich per Hand gebaut habe, wird jede Schätzung über OKFs Adoption überleben, weil es einfach gut strukturiertes Markdown ist, das ich jetzt besser verstehe als heute Morgen.

Also hier ist das Einzige, was ich Sie tatsächlich bitten würde zu tun, bevor diese Woche endet: Öffnen Sie einen Ordner, schreiben Sie fünf Konzeptdateien über etwas, das Sie aus dem Effeff kennen, fügen Sie einen Index hinzu und zeigen Sie einem Agent darauf. Zwanzig Minuten. Dann bilden Sie sich Ihr eigenes Urteil darüber, ob die Zukunft ein Ordner ist. Meines ist, dass das Format mit ziemlicher Sicherheit über v0.1 hinaus evolvieren wird — aber die Form, die es beschreibt, Wissen als Konzepte, die ein Agent lesen und pflegen kann, ist die Richtung, in die sich alles bereits bewegt. Besser, die Form jetzt zu lernen, als sich später dorthin zu scrapen.

Lassen Sie uns zusammenarbeiten

Sie möchten KI-Systeme bauen, Workflows automatisieren oder Ihre Tech-Infrastruktur skalieren? Ich helfe gerne.

• Fiverr (Maßanfertigungen & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io