Die meisten Leute nutzen Claude Code immer noch wie einen sehr teuren Praktikanten.
Sie geben ihm eine Aufgabe, warten auf eine Antwort und entscheiden dann manuell, was als Nächstes passiert.
Aber die Teams, die den größten Nutzen aus KI ziehen, bauen etwas, das einem kleinen verteilten System nahekommt.
Ein Agent grenzt das Problem ein.
Fünf günstigere Agenten suchen parallel.
Ein deterministisches Skript entfernt Duplikate.
Drei skeptische Agenten versuchen, die Ergebnisse zu widerlegen.
Ein Spitzenmodell fällt das endgültige Urteil.
Das ist Graph Engineering.
Bevor du weiterliest:
Lesezeichen für diesen Leitfaden, damit du zu den Graph-Mustern zurückkehren kannst, wenn du deine eigenen Claude-Workflows erstellst.
Und folge
@Gyome1_ -
Ich analysiere Claude Code, KI-Agenten und die Systeme, die aus einem Modell einen zuverlässigen Engineering-Workflow machen.
Ich habe Wochen damit verbracht, reale Agenten-Architekturen, Workflow-Diagramme und Produktionsmuster zu analysieren, um Graph Engineering in ein einziges praktisches Playbook zu verwandeln.
Anstatt einen längeren Prompt zu schreiben, entwirfst du den Pfad, den Informationen durch das System nehmen:
linear → aufteilen → reduzieren → verifizieren → synthetisieren
Jeder Agent wird zu einem Knoten mit einer begrenzten Aufgabe. Jede Kante trägt strukturierte Daten. Router entscheiden, welcher Zweig ausgeführt wird. Verifizierer lehnen schwache Ausgaben ab. Schleifen werden fortgesetzt, bis der Graph nichts Neues mehr findet.
Der wichtige Wandel ist, dass Claude Code nicht mehr wie eine einzige Intelligenz agieren muss, die eine riesige Checkliste abarbeitet.
Es kann den Orchestrierungscode generieren, eine Flotte spezialisierter Sub-Agenten starten, ihre Ausgaben durch verschiedene Modelle leiten und das Endergebnis erst zusammenstellen, nachdem die Beweise die Verifikation überstanden haben.
Die grundlegenden Muster sind nicht neu. Softwareentwickler nutzen seit Jahrzehnten DAGs, Pipelines, Barrieren, MapReduce und verteilte Worker.
Was sich geändert hat, ist das, was jetzt in jedem Knoten sitzt.
Ein Knoten kann ein Repository durchsuchen, eine Migration prüfen, eine Architekturentscheidung hinterfragen, Testfehler untersuchen oder fünfzig unabhängige Ergebnisse in einem einzigen belegten Bericht zusammenfassen.
Dieser Leitfaden zerlegt das gesamte System – vom einfachsten linearen Agenten bis hin zu Diamond-Graphen, Router-Knoten, adversarialen Verifizierer-Panels, konvergierenden Schleifen, Modell-Tiering und dynamischen Workflows, die direkt in Claude Code generiert werden.
Am Ende wirst du in der Lage sein, eine große Aufgabe zu betrachten und nicht mehr zu fragen:
"Welchen Prompt soll ich schreiben?"
1. GRAPH ENGINEERING BEGINNT MIT DER RECHNUNG
Graph Engineering wird oft als eine Möglichkeit präsentiert, mehr Agenten auszuführen.
Diese Darstellung übersieht den teuren Teil.
Du kannst zwanzig Claude-Agenten auf dasselbe Repository loslassen und erhältst zwanzig überlappende Berichte, wiederholte Kontexte, widersprüchliche Schlussfolgerungen und eine viel höhere API-Rechnung.
Ein nützlicher Graph kontrolliert, wo Berechnungen stattfinden, welches Modell welche Entscheidung trifft und wie unsichere Ergebnisse durch den Workflow wandern.
Stell dir vor, du bittest Claude Code, eine Produktionsmigration vorzubereiten:
Durchsuche das Repository, finde alle Abhängigkeiten, schlage die Migration vor, identifiziere Risiken, verifiziere den Plan und schreibe das finale Kurzbriefing.
Innerhalb eines einzigen Prompts wird dies zu einem langen, undurchsichtigen Prozess. Claude durchsucht die Codebasis, speichert Ergebnisse im Kontext, entwirft die Migration, überprüft seinen eigenen Plan und erstellt den Abschlussbericht.
Wenn der Bericht fehlschlägt, ist die Fehlerquelle schwer zu lokalisieren. Claude hat möglicherweise eine Datei übersehen, eine Abhängigkeit falsch verstanden, ein früheres Detail verloren oder während der Verifikation eine schwache Annahme akzeptiert.
Jede Stufe läuft möglicherweise auch auf demselben teuren Modell, selbst wenn Teile der Aufgabe einfache Extraktion oder Sortierung umfassen.
Graph Engineering öffnet diesen Workflow und gibt jeder Entscheidung einen sichtbaren Ort.
Die Inspektionszweige laufen gleichzeitig, weil sie dieselbe abgegrenzte Aufgabe verwenden und nicht von den Ausgaben der anderen abhängen.
Ihre Ergebnisse treffen in einer Reduktionsstufe zusammen, wo Duplikate verschwinden und Beweise zu einem kleineren Datensatz komprimiert werden.
Ein Router liest dann den Schweregrad. Routineänderungen durchlaufen eine leichte Überprüfung. Risikoreiche Ergebnisse erhalten eine tiefere Analyse von mehreren unabhängigen Prüfern, bevor sie das endgültige Modell erreichen.
Das Ergebnis ist ein Workflow, bei dem Latenz, Modellkosten, Kontextgröße und Verifikationstiefe durch die Struktur des Graphen gesteuert werden.
Ein Knoten sollte eine Entscheidung treffen
Ein nützlicher Knoten hat eine begrenzte Verantwortung.
Finde jeden Aufruf der veralteten API. Klassifiziere jedes Migrationsrisiko als niedrig, mittel oder hoch. Teste den Rollback-Plan auf Fehlerfälle.
Jeder Knoten benötigt eine klare Eingabe, eine definierte Ausgabe und eine begrenzte Entscheidungsoberfläche.
Ein Knoten, der das Repository durchsucht, die geschäftlichen Auswirkungen abschätzt, die Lösung entwirft und die Empfehlung schreibt, enthält immer noch mehrere versteckte Stufen. Das Debuggen bleibt schwierig, weil das Zwischenreasoning in einem einzigen Modellaufruf vergraben ist.
Kleinere Grenzen zeigen, wo Beweise in das System gelangt sind und wo sich ihre Bedeutung geändert hat.
Eine Kante sollte Beweise transportieren
Eine Kante repräsentiert Daten, die der nächste Knoten benötigt.
Der Scanner kann ein vorhersagbares Objekt zurückgeben:
1{2 "file": "src/auth/session.ts",3 "lines": [84, 119],4 "dependency": "legacySessionClient",5 "confidence": 0.94,6 "evidence": "Beide Aufrufstellen hängen von der veralteten Refresh-Methode ab."7}
Der Risikoklassifizierer erhält nun für jeden Fund die gleichen Felder. Er kann unvollständige Ergebnisse ablehnen, verwandte Dateien gruppieren und unsichere Beweise an eine andere Überprüfung weiterleiten.
Schemata reduzieren Interpretationsabweichungen zwischen Knoten. Freiformtexte zwingen jeden nachgelagerten Agenten, die Bedeutung des vorherigen Agenten zu rekonstruieren. Über mehrere Stufen hinweg können kleine Unklarheiten die endgültige Schlussfolgerung verändern.
Strukturierte Ausgaben halten die Beweise stabil, während sie sich durch den Graphen bewegen.
Einige Knoten sind gewöhnlicher Code
Angenommen, acht Suchagenten geben achtzig Ergebnisse zurück.
Der Workflow muss Arrays kombinieren, leere Antworten verwerfen, Duplikate entfernen und die verbleibenden Elemente sortieren.
Diese Operationen haben deterministische Antworten:
1const uniqueFindings = [2 ...new Map(3 results4 .flatMap(batch => batch ?? [])5 .map(item => [`${item.file}:${item.lines.join("-")}`, item])6 ).values()7];
Eine JavaScript-Transformation erledigt dies sofort und liefert bei jedem Durchlauf die gleiche Ausgabe. Das Senden derselben Aufgabe an ein anderes Modell verursacht Token-Kosten und schafft eine weitere Stelle, an der Beweise verschwinden können.
Modellknoten gehören zur Suche, Klassifikation, zum Vergleich, zur Überprüfung und zur Synthese. Code kann Validierung, Deduplizierung, Sortierung, explizite Routing-Regeln und andere vorhersagbare Transformationen übernehmen.
Diese Aufteilung wird zur Grundlage des Graphen.
Jeder Modellaufruf sollte einer Entscheidung entsprechen, die tatsächlich Urteilsvermögen erfordert.
2. DER DIAMANT: WIE ECHTE AGENTEN-GRAPHEN ARBEITEN BEWEGEN
Die meisten ernsthaften Agenten-Graphen nehmen irgendwann dieselbe Form an.
Eine Aufgabe beginnt mit einem gemeinsamen Umfang, teilt sich auf mehrere unabhängige Worker auf, wartet auf deren Ausgaben, komprimiert die Beweise und übergibt das Ergebnis an eine endgültige Entscheidung.
Diese Form ist der Diamant.
Die linke Seite ist Fan-Out.
Der mittlere Punkt, an dem alle Zweige zusammentreffen, ist die Barriere.
Die rechte Seite ist Fan-In.
Dieses Muster taucht überall auf, sobald eine Aufgabe für einen einzigen Kontextfenster zu groß wird.
Eine Repository-Prüfung kann nach Subsystem aufgeteilt werden. Ein Marktbericht kann nach Quelle aufgeteilt werden. Eine Rechercheaufgabe kann nach Hypothese aufgeteilt werden. Eine Migrationsüberprüfung kann nach API-Nutzung, Datenbankänderungen, Deployment-Risiko und Testabdeckung aufgeteilt werden.
Jeder Worker erhält denselben Umfang mit einer enger gefassten Aufgabe.
Der Graph wartet dann, bis genügend nützliche Beweise zurückgekommen sind.
Fan-Out sollte unabhängige Arbeit erzeugen
Ein Zweig gehört in das Fan-Out, wenn er von der gemeinsamen Eingabe ausgehen und ein nützliches Ergebnis liefern kann, ohne die Ausgabe eines anderen Zweigs zu lesen.
Für ein Sicherheitsaudit könnte die Aufteilung so aussehen:
Claude Code kann diese Aufrufe gleichzeitig mit einem Barriere-Primitiv wie parallel() starten.
1const findings = await parallel(2 checks.map(check => async () => {3 return agent({4 task: check.task,5 context: auditScope,6 schema: FINDING_SCHEMA7 });8 })9);
Die Orchestrierung bleibt in gewöhnlichem JavaScript. Jeder Zweig erhält eine begrenzte Aufgabe und gibt ein validiertes Objekt zurück.
Das Ergebnis kommt als eine Sammlung von Ausgaben, die gefiltert, inspiziert und an die nächste Stufe übergeben werden können.
Ein großes Fan-Out braucht dennoch einen Grund für jeden Zweig.
Das Aufteilen einer vagen Aufgabe in zwölf nahezu identische Agenten führt oft zu wiederholten Ergebnissen mit leicht unterschiedlicher Formulierung. Nützliche Parallelität entsteht aus verschiedenen Quellen, Perspektiven, Codebereichen oder Hypothesen.
Die Barriere schafft einen Entscheidungspunkt
Eine Barriere pausiert die nächste Stufe, bis die erforderlichen Zweige abgeschlossen sind.
Diese Pause ist wichtig, weil einige Entscheidungen von der gesamten Menge abhängen.
Ein Ranking-Knoten kann die wichtigste Sicherheitslücke nicht identifizieren, während die Hälfte des Repositorys noch untersucht wird. Ein Synthesemodell kann keinen vollständigen Migrationsplan schreiben, während die Deployment-Überprüfung noch läuft.
An der Barriere hat der Graph die Möglichkeit, den Zustand des Laufs zu inspizieren:
1const completed = findings.filter(Boolean);23if (completed.length < MIN_REQUIRED_RESULTS) {4 throw new Error("Unzureichende Audit-Abdeckung");5}
Hier werden Teilfehler sichtbar.
Ein Worker kann auslaufen, fehlerhafte Daten zurückgeben oder keine Ergebnisse liefern. Das Filtern von Nullwerten hält den Lauf am Laufen, aber Produktionsworkflows benötigen normalerweise eine klarere Richtlinie:
- wie viele erfolgreiche Zweige erforderlich sind;
- welche Zweige obligatorisch sind;
- ob ein fehlgeschlagener Knoten wiederholt werden soll;
- ob das Endergebnis als unvollständig markiert werden soll.
Die Barriere ist daher Teil des Zuverlässigkeitsmodells, nicht nur ein Synchronisationsmechanismus.
Reduzieren vor dem Synthetisieren
Nach dem Fan-Out kann der Graph Dutzende überlappender Ergebnisse enthalten.
Das direkte Senden aller Ergebnisse an ein Spitzenmodell erzeugt einen großen Kontext, wiederholt dieselben Beweise und macht es schwieriger, wichtige Details zu unterscheiden.
Die Reduktionsstufe bereitet die Beweise vor.
Einige Reduktionen können im Code erfolgen:
1const unique = deduplicateByKey(2 completed.flatMap(result => result.findings),3 finding => `${finding.file}:${finding.line}:${finding.type}`4);
Die nächste Ebene erfordert möglicherweise Urteilsvermögen:
1const curated = await agent({2 task: `3 Gruppiere verwandte Ergebnisse.4 Behalte alle Datei- und Zeilenverweise bei.5 Ordne jede Gruppe nach betrieblicher Auswirkung.6 Gib die stärksten Beweise für jede Schlussfolgerung zurück.7 `,8 input: unique,9 schema: CURATED_FINDINGS_SCHEMA10});
Reduktion kontrolliert, was das endgültige Modell erreicht.
Ein guter Reducer entfernt Wiederholungen, während er Beweise erhält. Ein aggressiver Reducer kann mehrere unterschiedliche Risiken zu einer vagen Zusammenfassung komprimieren und die für die Verifikation erforderlichen Details löschen.
Das sicherste Muster behält einen Link zwischen jeder reduzierten Behauptung und ihren Quellobjekten.
1{2 "risk": "Session-Refresh kann nach der Migration fehlschlagen",3 "severity": "high",4 "sourceFindingIds": ["AUTH-04", "API-11", "TEST-07"],5 "evidence": [6 "Drei Dienste rufen die veraltete Refresh-Methode auf",7 "Kein Fallback-Pfad vorhanden",8 "Integrationstests fehlen"9 ]10}
Jetzt erhält der Syntheseknoten einen kleineren Datensatz, ohne die Rückverfolgbarkeit zu verlieren.
3. ZUVERLÄSSIGKEIT IST TEIL DES GRAPHEN
Ein Graph kann schnell fertig sein und trotzdem eine schlechte Antwort liefern.
Sobald mehrere Agenten beginnen, dieselbe Aufgabe zu suchen, zu klassifizieren und zu überprüfen, wird das Hauptproblem zur Kontrolle.
Das System benötigt Regeln, um zu entscheiden, welche Ergebnisse tiefergehende Arbeit verdienen, welche Ausgaben abgelehnt werden sollten und wann der Workflow genug gesucht hat.
Nach Risiko routen
Ein Router-Knoten liest strukturierte Ausgaben und wählt den nächsten Zweig.
Die Klassifikation kann von einem Modell kommen, während der Zweig selbst explizit im Code bleibt.
1const route =2 finding.severity === "high"3 ? runFullAudit(finding)4 : runQuickReview(finding);
Dies hält teure Überprüfungen auf Ergebnisse mit bedeutenden Auswirkungen konzentriert.
Ein nützlicher Router verlässt sich auf Felder, die der Graph inspizieren kann: Schweregrad, Vertrauen, betroffene Systeme, finanzielles Risiko oder das Vorhandensein fehlender Beweise.
Unabhängige Verifikation hinzufügen
Ein Agent, der seine eigene Schlussfolgerung überprüft, bringt dieselben Annahmen in beide Stufen.
Ein stärkerer Graph sendet wichtige Ergebnisse an mehrere Prüfer mit unterschiedlichen Aufgaben.
Die Prüfer sollten keine Anweisungen erhalten, die ursprüngliche Antwort zu verbessern. Ihre Aufgabe ist es, nach Gründen zu suchen, warum sie unvollständig oder falsch sein könnte.
Der Graph kann Zustimmung verlangen, bevor ein Ergebnis weitergegeben wird:
1const accepted = votes.filter(vote => vote.approve).length >= 2;
Agenten isolieren, die Code ändern
Parallele Codierungsagenten können sich gegenseitig stören, wenn sie dasselbe Arbeitsverzeichnis bearbeiten.
Ein Agent kann eine Datei überschreiben, während ein anderer sie noch liest. Tests können gegen eine Mischung aus nicht zusammenhängenden Änderungen laufen.
Git-Worktrees geben jedem Zweig eine eigene Kopie des Repositorys.
1Haupt-Repository2 │3 ├→ worktree/auth-fix4 ├→ worktree/db-migration5 └→ worktree/test-repair
Jeder Agent kann Dateien ändern und Tests in seiner eigenen Umgebung ausführen. Ein späterer Knoten vergleicht die Patches, prüft auf Konflikte und wählt aus, was zusammengeführt werden soll.
Dies macht die Isolation zu einem Teil des Graphen und nicht zu einem manuellen Bereinigungsschritt.
Entdeckung konvergieren lassen
Einige Aufgaben können nicht in einem Durchlauf abgeschlossen werden.
Eine Repository-Prüfung kann eine Abhängigkeit aufdecken, die auf ein anderes Paket verweist. Dieses Paket kann eine weitere Aufrufstelle offenbaren. Der Graph benötigt eine kontrollierte Möglichkeit, die Suche fortzusetzen, ohne alles, was bereits gesehen wurde, zu wiederholen.
1const seen = new Set();2let dryRounds = 0;34while (dryRounds < 2) {5 const findings = await discoverNext([...seen]);6 const fresh = findings.filter(item => !seen.has(item.id));78 fresh.forEach(item => seen.add(item.id));9 dryRounds = fresh.length === 0 ? dryRounds + 1 : 0;10}
Das wichtige Detail ist die Deduplizierung gegen jedes zuvor gesehene Element.
Die Deduplizierung nur gegen bestätigte Ergebnisse erlaubt es, abgelehnte oder unsichere Elemente im nächsten Durchlauf zurückzukehren und dieselbe Arbeit erneut zu verbrauchen.
Die Schleife stoppt nach mehreren trockenen Durchläufen, einem festgelegten Budget oder einer maximalen Anzahl von Iterationen. Produktionsgraphen benötigen normalerweise alle drei.
Das Modell an den Knoten anpassen
Nicht jeder Knoten benötigt das stärkste verfügbare Modell.
Extraktion, einfache Klassifikation und enge Suchen können oft auf einer schnelleren Stufe ausgeführt werden. Architekturüberprüfung, adversariales Verifizieren und finale Synthese rechtfertigen möglicherweise ein stärkeres Modell.
Modell-Tiering wird zu einer weiteren Eigenschaft des Graphen.
Das Budget wird bestimmt durch wie viele Knoten laufen, wie oft sich Schleifen wiederholen, wie viel Kontext jede Kante überquert und welches Modell welche Stufe übernimmt.
Ein Graph mit zwanzig günstigen Suchaufrufen kann immer noch mehr kosten als ein einziger starker Aufruf. Die Architektur benötigt ein Token-Budget, bevor sie einen weiteren Zweig braucht.
Wissen, wann man aufhören sollte zu zeichnen
Kleine Aufgaben benötigen selten Router, Abstimmungsgremien, Worktrees und Konvergenzschleifen.
Der Overhead eines Graphen umfasst Orchestrierungscode, Schemata, Wiederholungen, Protokollierung, Zwischenspeicher und mehr Fehlerzustände, die es zu debuggen gilt.
Ein linearer Workflow ist normalerweise ausreichend, wenn ein Modell den relevanten Kontext halten kann, die Aufgabe wenige unabhängige Zweige hat und die Kosten einer falschen Antwort gering sind.
Graph Engineering wird nützlich, wenn die Aufgabe parallele Arbeit, teure Entscheidungen, große Beweismengen oder bedeutende Verifikationsanforderungen mit sich bringt.
Der vollständige Workflow könnte schließlich so aussehen:
Der Wert liegt darin, die Bewegung der Arbeit sichtbar zu machen.
Jeder Knoten hat eine begrenzte Verantwortung. Jede Kante trägt strukturierte Beweise. Jeder Zweig hat eine Existenzberechtigung. Jede Schleife hat eine Abbruchbedingung.
An diesem Punkt arbeitet Claude Code nicht mehr durch eine einzige lange Anweisung.
Es führt ein konstruiertes System aus.
