--- title: "Open Ontologies: Herleitungszertifikate prüfen" canonical: https://wavect.io/de/blog/open-ontologies-proof-verification/ language: de description: "Prüfe Herleitungszertifikate mit Open Ontologies: reproduzierbarer Graph-Test, erkannte Fälschung, RAG-Ausschnitte und klare Kriterien für die Freigabe." image: "https://wavect.io/img/blog/headers/header_open-ontologies-proof-verification.png" author: ["Kevin Riedl"] published: "2026-11-03" updated: "2026-11-03" reviewed: "2026-11-03" --- # Open Ontologies: Herleitungszertifikate prüfen [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 min Lesezeit · 3. November 2026 Zuletzt geprüft 3. November 2026 [**Weiter**](/de/blog/graph-engineering-ai-agents/) TL;DR Open Ontologies plant Graphänderungen und erzeugt Herleitungszertifikate für einen unabhängigen Prüfer. Unser kleiner Test fand neue Konsequenzen trotz niedrigen strukturellen Risikos, erkannte eine veränderte Schlussfolgerung und unterschied vollständige von gekürzten RAG-Ausschnitten. Beim unveränderten Zertifikat scheiterte der Prüfer mit einem Laufzeitfehler. Eine erfolgreiche unabhängige Verifikation bleibt deshalb unbestätigt. Prüfe Graphumfang, Regelprofil und die genaue Prüferausgabe, bevor ein Agent eine Schlussfolgerung verwendet. Ein zusätzliches Tripel ließ das strukturelle Risiko in unserem Open-Ontologies-Test bei `low`. Trotzdem entstanden drei neue Konsequenzen. Ein späterer Retrieval-Test endete erfolgreich und meldete zugleich ausdrücklich, dass seine Schlussfolgerung ungeprüft war. **Um ein Herleitungszertifikat von Open Ontologies zu prüfen, bewahrst du den Ausgangsgraphen samt Regelumfang auf. Führe den unabhängigen Prüfer mit den Dateien für Ausgangsaussagen und Herleitungen aus und bewerte das strukturierte Ergebnis zusammen mit dem Prozessstatus.** Gib genau den Graphen und die Aussagen frei, deren Prüfung erfolgreich war. Ungeprüfte Ergebnisse und Prüferfehler bleiben offen. [Open Ontologies](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/README.md) ist eine quelloffene Engine, die Ontologieänderungen plant und Zertifikate für unterstützte Herleitungen erzeugt. Der Vergleich mit Terraform beschreibt den Ablauf aus Planung, Prüfung und Anwendung einer Änderung. Falls du noch entscheidest, ob dein Agent überhaupt einen Wissensgraphen braucht, beginne mit unserem [Entscheidungsleitfaden zu Graph Engineering für KI-Agenten](/de/blog/graph-engineering-ai-agents/). **Stand von Test und Recherche: 3. November 2026.** Wir verwendeten per Prüfsumme verifizierte Linux-Dateien aus [v2.1.0](https://github.com/fabio-rovai/open-ontologies/releases/tag/v2.1.0), veröffentlicht am 23. Oktober 2026. Die Quellverweise zeigen auf den späteren Commit `c7fd75f` vom 2. November. Eine erfolgreiche unabhängige Prüfung bleibt **unbestätigt**: Beim unveränderten Zertifikat scheiterte der Prüfer in unserer Umgebung mit einem Laufzeitfehler. Der Testfall untersucht das Verhalten; er liefert keinen Performance-Benchmark. ## Was belegt ein Beweis von Open Ontologies? **Ein akzeptiertes Herleitungszertifikat von Open Ontologies belegt, dass seine Schlussfolgerungen unter der unterstützten formalen Semantik aus den gelieferten Ausgangsaussagen folgen.** Ob ein Dokument freigegeben, korrekt oder aktuell ist, braucht weiterhin eigene Belege. Ein Prüfer kann die Folgen einer falschen Prämisse bestätigen, ohne ihren Fehler zu erkennen. Die [Dokumentation der Prüfarchitektur](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/docs/assurance-architecture.md) trennt zwei Aufgaben: eine Schlussfolgerung prüfen und feststellen, welchen Graphen die Engine verwendet hat. | Frage | Zu prüfender Beleg | Grenze | | --- | --- | --- | | Ist die Herleitung gültig? | Ergebnis des unabhängigen Prüfers für die Dateien mit Ausgangsaussagen und Herleitungen | Gilt unter diesen Ausgangsaussagen und den unterstützten Regeln | | Ist dies der beabsichtigte Graph? | Graphrevision, Hash der Ausgangsaussagen und ausgewählter Graphumfang | Ein gültiger Beweis kann den falschen Datenstand beschreiben | | Sind die Ausgangsaussagen verlässlich? | Quellbelege, Prüfung der Extraktion und zuständige Person | Formale Folgerung überprüft keine Tatsachen außerhalb des Systems | | Darf der Agent das Ergebnis verwenden? | Anwendungsregeln und Zugriffskontrollen | Ein Klassenname erteilt keine Berechtigung | Unsere [Analyse von LLM-as-a-Verifier](/de/blog/llm-as-a-verifier/) behandelt erlernte Bewertungen, mit denen du Modellausgaben sortierst. Open Ontologies prüft eine explizite Herleitung anhand von Regeln. ## Wie prüfst du ein Herleitungszertifikat von Open Ontologies? **Erzeuge das Zertifikat und führe dann `oo-cert` mit `asserted.tsv` und `derivations.tsv` aus.** Bewahre stdout, stderr und den Exit-Code auf. Akzeptieren kannst du das Zertifikat erst, wenn der Prüfer seinen Lauf abschließt und das dokumentierte Erfolgsergebnis zurückgibt. Der [Zertifikatsleitfaden](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/docs/lean-certificates.md) beschreibt einen separaten Lean-Prüfer, der die aufgezeichneten Inferenzschritte erneut prüft. Laut Dokumentation besteht das Erfolgsergebnis aus Exit-Code `0`, `ok: true` und dem Theorem `OOCert.certificate_sound`. Bei einem abgelehnten Schritt sollen Regel, Schlussfolgerung und Prämissen erkennbar sein. Lade unseren [Open-Ontologies-Testfall mit Zertifikaten und aufgezeichneten Ergebnissen](/downloads/open-ontologies-proof-verification-fixture.zip) herunter und wechsle in das entpackte Verzeichnis. Das Beispiel setzt voraus, dass die verifizierten Programme für Engine und Prüfer in deinem PATH liegen. Das Paket enthält die Testeingaben und ein Skript zum Erfassen der Ergebnisse; die Programme stellst du separat bereit. ``` open-ontologies --no-connect --data-dir ./review-store batch - <<'OO' load proposed.ttl reason --profile rdfs --certificate ./certificate OO oo-cert ./certificate/asserted.tsv ./certificate/derivations.tsv ``` Der Batch lädt den Graphen und führt die Schlussfolgerung im selben Prozess aus. Unser vorgeschlagener Graph enthielt vier Ausgangstripel; die Schlussfolgerung mit `rdfs` erzeugte drei Herleitungen. Anschließend änderten wir eine Schlussfolgerung: `note42` sollte nun zu `ApprovedForProduction` gehören. Die Prämissen blieben unverändert. | Eingabe | Beobachtetes Ergebnis | Entscheidung für die Freigabe | | --- | --- | --- | | Unverändertes, erzeugtes Zertifikat | Exit-Code 1, leeres stdout, stderr: `failed to locate application` | Zurückhalten. Der Prüfer gab keine erfolgreiche Verifikation aus | | Veränderte Schlussfolgerung, unveränderte Prämissen | Exit-Code 1, JSON `ok: false`, `first_rejected: 2`, Regel `rdfs9` | Veränderte Herleitung ablehnen. Eine konkrete Regelprüfung schlug fehl | Beide Prozesse endeten mit `1`. Nur der zweite lieferte eine strukturierte Regelablehnung. `first_rejected: 2` bezeichnet den dritten Herleitungsdatensatz, weil der Index bei null beginnt. Der erste Lauf scheiterte bereits beim Auffinden der Anwendung. Diese Fehler haben unterschiedliche Ursachen; die Negativkontrolle ersetzt keine erfolgreiche Prüfung des ursprünglichen Zertifikats. ## Warum braucht auch ein Plan mit niedrigem Risiko eine semantische Prüfung? **Open Ontologies weist strukturelles Risiko und semantische Konsequenzen getrennt aus.** Auch ohne neue benannte Klassen können bestehende Regeln neue Klassifizierungen ableiten. Prüfe den Block `conservativity` und die betroffenen Schlussfolgerungen, bevor du die Änderung als beabsichtigt freigibst. Unser Ausgangsgraph enthielt diese drei Aussagen. Die Deklaration von `Retrievable` nimmt diesen Namen bewusst in das ursprüngliche Vokabular auf: ``` @prefix ex: . @prefix rdfs: . ex:note42 a ex:ProjectNote . ex:ProjectNote rdfs:subClassOf ex:Document . ex:Retrievable a rdfs:Class . ``` Der Änderungsvorschlag ergänzt ein Tripel: ``` ex:Document rdfs:subClassOf ex:Retrievable . ``` Die [Dokumentation zur Konservativität](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/docs/modules-and-conservativity.md) grenzt den endlichen Vergleich anhand einer Regeltabelle von einer allgemeinen Garantie logischer Konservativität ab. Unser Plan mit `owl-rl` meldete eine Einfügung, null betroffene Tripel im Feld für den strukturellen Änderungsradius, `risk_score: low` und `not_conservative_under_rule_table`. | Tripel, verkürzt | Warum es hinzukommt | | --- | --- | | Document ist Unterklasse von Retrievable | Die neue Ausgangsaussage selbst | | ProjectNote ist Unterklasse von Retrievable | Neue Herleitung über die Unterklassenkette | | note42 hat den Typ Retrievable | Neue Herleitung anhand dieser Klassifizierung | Das sind **drei neue Konsequenzen, darunter eine Ausgangsaussage und zwei neue Herleitungen**. Das Zertifikat enthält drei Herleitungen, weil es zusätzlich `note42 type Document` aufführt. Diese Klassifizierung folgte bereits aus dem Ausgangsgraphen. Die [veröffentlichte Projektdemonstration](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/README.md) nennt 901 neue Konsequenzen in 0,04 Sekunden. Ein separater Versuch umfasst 259 zertifizierte Herleitungen und eine abgelehnte Fälschung. Wir haben diese Anzahlen und Laufzeiten nicht reproduziert. Wie unser Beispiel zeigt, kann die Zahl der Konsequenzen auch die ergänzte Ausgangsaussage einschließen. Unser Batch-Prozess endete außerdem mit `0`, obwohl sein verschachtelter Konservativitätsbericht `exit_code: 1` enthielt. Dieser semantische Befund kann eine gewollte Änderung beschreiben. Ein Freigabeprozess muss den Bericht auswerten und die Entscheidung festhalten. Wer nur den Shell-Status prüft, übersieht ihn. ## Erhält ein kleinerer RAG-Kontext dieselbe Schlussfolgerung? **Open Ontologies kann prüfen, ob ein ausgewählter Graphenausschnitt bestimmte positive Tripel ohne Variablen unter einem gewählten Regelprofil weiterhin stützt.** Du gibst die zu prüfenden Aussagen vor. Das Werkzeug extrahiert und validiert nicht jede Aussage einer generierten Antwort. Auch ein hoher Anteil erhaltener Nachbartripel belegt nicht, dass die benötigten Prämissen erhalten geblieben sind. In unserem Testfall lautet das Ziel `note42 type Retrievable`. Der vollständige Ausschnitt enthält die drei Tripel dieser Herleitung und lässt die eigenständige Klassendeklaration weg. Im gekürzten Ausschnitt fehlt `ProjectNote subClassOf Document`. Beide bleiben Teilmengen des vorgeschlagenen Graphen. Der [Leitfaden zur Folgerung aus Graphenausschnitten](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/docs/projection-entailment.md) vergibt unterschiedliche Namen für geprüfte, direkt vorliegende und ungeprüfte Ergebnisse: | Lauf | Ergebnis für das Ziel | Prozessstatus | Bedeutung für die Freigabe | | --- | --- | --- | --- | | Vollständiger Ausschnitt, kein Prüfer konfiguriert | `preserved_unchecked` | 0 | Die Engine leitet das Ziel ab; die unabhängige Prüfung fehlt | | Gekürzter Ausschnitt, kein Prüfer konfiguriert | `lost_under_profile_unchecked` | 1 | Das gewählte Profil leitet das Ziel aus diesem Ausschnitt nicht mehr ab | | Vollständiger Ausschnitt, Prüfer vorgeschrieben | `certificate_rejected`, `STOP_THE_LINE` | 2 | Zurückhalten und die ursprüngliche Fehlermeldung des Prüfers untersuchen | In der dritten Zeile enthält der Bericht denselben Laufzeitfehler `failed to locate application`. Die Ablehnungsbezeichnung des Wrappers belegt deshalb nicht, dass die Herleitung an einer Regelprüfung gescheitert ist. In dieser Umgebung haben wir kein `preserved_checked` erhalten. Auch der Befund über den Verlust einer Folgerung hat Grenzen: Er beschreibt das negative Engine-Ergebnis innerhalb der unterstützten Regeln. Er beweist keine Nichtfolgerung in jeder Ontologielogik. Verlangt ein Workflow einen Beweis, würden wir ein ungeprüftes positives Ergebnis zurückhalten, eine fehlende Prämisse wiederherstellen und einen Prüferfehler untersuchen, bevor der Agent die Aussage verwenden darf. Das Erhalten einer Folgerung klärt keine Zugriffsrechte. Unser [Leitfaden zu RAG-Berechtigungen](/de/blog/rag-permissions-sharepoint-confluence-drive/) behandelt die vorgelagerte Frage, ob der Nutzer diese Fakten überhaupt abrufen darf. ## Was gehört in das Freigabeprotokoll? **Ein Freigabeprotokoll für Open Ontologies sollte Graphrevision, ausgewählte Ausgangsaussagen, Regelprofil, semantische Änderung und das genaue Prüfergebnis festhalten.** Bei einem abgerufenen Ausschnitt kommen die Einzelurteile zu den Zielen hinzu. Das ist unser Vorschlag für die Anwendungsregeln. Er bedeutet nicht, dass die Engine betriebliche Änderungen automatisch freigibt. | Aufzeichnung | Frage für die Freigabe | | --- | --- | | Identität von Engine und Prüfer | Welche heruntergeladenen Programme oder Builds liefen, und stimmen ihre Hashes mit den geprüften Versionen überein? | | Graphrevision und Bytes der Ausgangsaussagen | Beschreibt das Zertifikat genau die Eingabe, die für diesen Lauf freigegeben wurde? | | Ausgewählter Umfang und Profil | Welche Graphen und Regeln wurden verwendet, und wurden relevante Konstrukte oder Ziele zurückgewiesen? | | Bericht zur semantischen Änderung | Hat eine zuständige Person die gemeldeten Konsequenzen akzeptiert und offene Befunde geklärt, unabhängig vom strukturellen Risikolabel? | | stdout, stderr und Exit-Code des Prüfers | Hat der vorgesehene Prüfer eine erfolgreiche Verifikation ausgegeben? | | Ausschnitt, explizite Ziele und Einzelurteile | Liegen für jede erforderliche abgeleitete Aussage die Belege vor, die deine Anwendung verlangt? | Die [Dokumentation zur vertrauenswürdigen Rechenbasis](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/docs/trusted-computing-base.md) erklärt, dass der Prüfer Zertifikatsdateien liest. Deinen beabsichtigten Anwendungszustand kennt er nicht. Er untersucht auch `scope.tsv` nicht; der Aufrufer muss diese Auswahl prüfen. Ein Hash bindet die Bytes der Ausgangsaussagen. Er belegt weder ihre Wahrheit und Aktualität noch ihren Berechtigungsstatus. Für diesen Versuch bleibt die Entscheidung **bis zur unabhängigen Verifikation zurückhalten**. Die Ablehnung der Fälschung ist ein nützlicher Befund. Sie ersetzt jedoch keine erfolgreiche Prüfung des Zertifikats, das du verwenden willst. Wiederhole die Kontrollen für erfolgreiche Prüfung und Ablehnung auf deinem Deployment-Host, bevor du sie mit einem Agenten verbindest. ## Wie verbindest du Open Ontologies mit Claude Code? **Registriere Open Ontologies als lokalen stdio-MCP-Server mit einem expliziten Programm- und Speicherpfad.** Entscheide bewusst über die Persistenz: Standardmäßig liegt der Speicher im Arbeitsspeicher. Ein Prozessneustart erhält den geladenen Graphen daher nicht. Eine funktionierende MCP-Verbindung belegt auch nicht, dass der separate Beweisprüfer installiert ist. Die auf den Commit festgelegte [Speicher- und Embedding-Konfiguration](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/src/config.rs) definiert den Standard im Arbeitsspeicher sowie den persistenten Modus. Nach der aktuellen [MCP-Anleitung für Claude Code](https://code.claude.com/docs/en/mcp) nutzt diese Registrierung den lokalen Transport: ``` claude mcp add \ --env OPEN_ONTOLOGIES_STORAGE_MODE=persistent \ --transport stdio open-ontologies -- \ /absolute/path/open-ontologies \ --data-dir /absolute/path/oo-store serve ``` Ersetze beide absoluten Pfade. Konfiguriere und verifiziere den Prüfer separat und kontrolliere die Verbindung anschließend mit `/mcp`. Wir haben die Befehlsstruktur mit der Dokumentation abgeglichen. Eine laufende Claude-Code-Sitzung oder jeden MCP-Client haben wir nicht getestet. `--data-dir` ist hier ein CLI-Flag, keine Umgebungsvariable. Plane Zeit für beide Programme und eine erfolgreiche Beweisprüfung auf deinem Deployment-Host ein. Unser Test belegt keine verifizierte Einrichtung in einer Minute. ## Wann würden wir Open Ontologies einsetzen? **Wir würden Open Ontologies prüfen, wenn ein Agent von expliziten, nachvollziehbaren Aussagen und Regeln abhängt, deren Konsequenzen relevant sind.** Beginne mit einer wichtigen Aussage, einer vorgeschlagenen Ontologieänderung und einer absichtlich beschädigten Herleitung. Erweitere den Umfang erst, wenn die Deployment-Umgebung sowohl die erfolgreiche unabhängige Prüfung als auch die erwartete Ablehnung nachweist. Wenn du diese Schlussfolgerungsschicht mit einer Anwendung verbinden willst, ist unsere [Entwicklung von KI-Produkten und Agenten](/de/services/artificial-intelligence/) der passende nächste Schritt. Definiere die Aussagen und Freigabekriterien, bevor du den Graphen erweiterst. ## Fragen zur Beweisprüfung mit Open Ontologies ### Ist Open Ontologies ein Terraform-Provider? Der Terraform-Vergleich des Projekts beschreibt das Planen, Prüfen, Anwenden und Zurückrollen von Ontologieänderungen. Er belegt keine Kompatibilität mit Terraform-Providern oder HCL. Behandle Open Ontologies als eigenständiges Werkzeug für Schlussfolgerungen und Änderungen. Prüfe seine tatsächlichen Befehle und Belegformate, bevor du anhand dieser Analogie eine Integration entwirfst. ### Verhindert Open Ontologies jede Halluzination eines Agenten? Nein. Ein Herleitungsprüfer deckt festgelegte formale Schlussfolgerungen aus gelieferten Ausgangsaussagen unter unterstützten Regeln ab. Ein Agent kann weiterhin eine falsche Aussage extrahieren, ein nötiges Ziel auslassen, ein Ergebnis falsch beschreiben oder etwas Ungeprüftes behaupten. Die Anwendung muss die geprüften Tripel mit ihren freigegebenen Aussagen verbinden und die Quellbelege der Ausgangsaussagen erhalten. ### Kann dasselbe Herleitungszertifikat auch OWL-DL-Schlussfolgerungen zertifizieren? Der dokumentierte Pfad reason --certificate unterstützt rdfs, owl-rl und owl-rl-ext; owl-dl weist dieses Flag zurück. Das Projekt bietet weitere Prüfmechanismen, die du separat bewerten musst. Eine erfolgreiche Prüfung innerhalb eines unterstützten Regelfragments rechtfertigt keine Aussage darüber, dass jedes OWL-Konstrukt oder jede Engine-Antwort zertifiziert sei. ### Beweist ein Zertifikat, dass eigene Horn-Regeln korrekt sind? Ein Horn-Zertifikat mit übergebenen Regeln beweist eine Schlussfolgerung relativ zu diesen Regeln und den Ausgangsaussagen. Die Regeln bleiben Annahmen. Bewahre Urteile wie entailed_under_supplied_rules vollständig auf und prüfe die Regeltabelle samt Hash. Verkürzt du das Ergebnis auf ein allgemeines „bewiesen“, verbirgst du eine Annahme, die bei der Prüfung sichtbar bleiben muss. ### Bleiben bei lokaler MCP-Ausführung alle Daten auf meinem Gerät? Lokale Schlussfolgerung allein belegt keinen vollständig lokalen KI-Workflow. Werkzeugergebnisse gehen an den MCP-Client zurück, dessen Modell auf einem entfernten Server laufen kann. Die untersuchte Konfiguration unterstützt außerdem eine OpenAI-kompatible Embedding-API. Der [Schnellstart des Projekts](https://github.com/fabio-rovai/open-ontologies/blob/c7fd75f9491253c56e4d4f408ceac179de343e48/docs/quickstart.md) dokumentiert Modelldownloads für die Embedding-Initialisierung. Prüfe den gewählten Build, den Anbieter und den Datenfluss des Clients, bevor du einen rein lokalen Betrieb zusicherst. ### Erklärt derivations.tsv jede mögliche Begründung? Nein. Laut Zertifikatsleitfaden wird pro neu abgeleitetem Tripel ein Herleitungsschritt aufgezeichnet: der zuerst gefundene. Eine Schlussfolgerung kann weitere gültige Begründungen haben, die diese Datei nicht aufzählt. Nutze dafür die gesonderten Mechanismen des Projekts für Begründungen und Provenienz. Bewerte deren Garantien unabhängig davon, ob dieses einzelne Zertifikat erfolgreich geprüft wird. Modelle und Infrastruktur ## Weiterlesen Modellauswahl, Inferenzkosten, lokaler Betrieb, Kompression und Serving-Architektur. [Hier starten**LLMs in der EU selbst hosten: Wann sich Open Weights wirklich rechnen**](/de/blog/self-hosting-llms-eu-cost/) - [Cue Turn Detection: Telefonnummern, Benchmarks und Grenzen](/de/blog/cue-turn-detection-phone-numbers/) - [Google SAM heißt jetzt Agent Mesh: MCP-Tools vernetzen](/de/blog/google-sam-agent-mesh-mcp-tools/) - [EdgeQuake: PostgreSQL-GraphRAG als MCP-Gedächtnis für Agenten](/de/blog/edgequake-postgresql-graphrag-mcp-agent-memory/) - [BitNet auf der CPU: 2B4T, RAM-Bedarf und die 100B-Angabe](/de/blog/bitnet-cpu-llm-ram-requirements/) - [SuperPenguin: KI-Kosten pro PR, Kunde und Feature](/de/blog/superpenguin-ai-roi-cost-per-pr-customer/) [Nächster Artikel**Cue Turn Detection: Telefonnummern, Benchmarks und Grenzen**](/de/blog/cue-turn-detection-phone-numbers/) [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 min Lesezeit · 3. November 2026 Zuletzt geprüft 3. November 2026 [**Weiter**](/de/blog/graph-engineering-ai-agents/)