Anthropic hat gerade den größten Fehler im Graph-Engineering behoben
AAI LABS
Computing/SoftwareInternet Technology
Transcript
00:00:00Es gibt einen neuen Begriff namens Graph Engineering, und auf X sprechen gerade alle darüber.
00:00:04Vor den Graphen drehte sich alles um Loop Engineering, wo man dem Agenten ein Ziel gibt und er
00:00:09eigenständig darauf hinarbeitet. Mit Graphen wird die Arbeit jedoch schneller erledigt und deckt auf einmal
00:00:14viel mehr ab, als ein Loop es je könnte. Es gibt dabei jedoch ein riesiges Problem:
00:00:18Ein einziger Fehler in einem kleinen Teil des Graphen stört das gesamte Ergebnis, und es ist schwer nachzuverfolgen,
00:00:23weil man am Ende nur das fertige Resultat sieht. Anthropic hat nun etwas veröffentlicht, das genau dieses
00:00:27Problem löst und dafür sorgt, dass Ihre Graphen ohne Fehler durchlaufen. Wenn Sie neu hier sind: Wir sind ein
00:00:32Softwareunternehmen, und das ist unser Kanal AI Labs, auf dem wir zeigen, wie Sie Ihr Unternehmen mit KI optimieren –
00:00:37und falls Sie kein eigenes haben, können Sie diese Fähigkeiten nutzen, um dafür bezahlt zu werden, es für andere zu tun.
00:00:42In diesem Video gehen wir auf Graph Engineering für alle ein, die es noch nicht kennen,
00:00:46und liefern Ihnen genau die Lösung, die Anthropic vorgeschlagen hat. Bevor wir Graph Engineering erklären,
00:00:52müssen Sie verstehen, was Loop Engineering eigentlich ist. Wenn Sie das bereits wissen, können Sie diesen Teil überspringen.
00:00:56Ein Loop ist im Grunde ein Arbeitszyklus, den Sie an den Agenten übergeben. Anstatt ihn durch
00:01:02jeden einzelnen Schritt selbst per Prompt zu führen, nennen Sie ihm das Endziel, und er gelangt eigenständig dorthin,
00:01:07wobei er sich unterwegs anpasst. Wir haben sie in unseren eigenen Workflows intensiv genutzt und bereits ein ganzes Video
00:01:12über Loop Engineering gemacht, in dem wir tiefer auf die verschiedenen Setups eingegangen sind. Aber Loops
00:01:17entwickeln sich nun zu sogenannten Graphen weiter. Das Problem bei Loops liegt in ihrer Bauweise.
00:01:22Ein Loop führt einen Arbeitsschritt aus, dann greift ein Verifizierungsschritt, um zu prüfen, ob alles so ist,
00:01:27wie es sein sollte. Sobald dieser bestanden ist, beginnt der nächste Schritt. Alles läuft linear ab, sodass jeder Schritt
00:01:32auf den vorherigen warten muss, selbst wenn die beiden gar nichts miteinander zu tun haben. Graph Engineering
00:01:37löst genau das. Anstatt linear abzulaufen, teilt ein Graph die Hauptaufgabe in kleinere
00:01:42Teile auf, und jeder Teil bekommt einen eigenen Agenten. Der erste Vorteil daraus ist Geschwindigkeit, da mehrere
00:01:47Agenten die Arbeit gleichzeitig erledigen, anstatt dass sich ein einzelner Agent durch alles durchkämpfen muss. Und das Aufteilen
00:01:52der Arbeit senkt auch die Kosten etwas, da Sie auswählen können, auf welchem Modell jeder Agent
00:01:56läuft. So verbrauchen Sie Ihr teuerstes Modell nicht mehr für Teile, die von Anfang an gar nicht so viel
00:02:01Intelligenz benötigt hätten. Das betrifft jedoch die Kosten pro Agent, nicht die Gesamtkosten. Ein Graph verbraucht weit mehr
00:02:07Token als ein einzelner Agent es je tun wird, weil eine ganze Gruppe von ihnen gleichzeitig arbeitet.
00:02:12Wenn Sie Graphen nutzen, sollten Sie damit rechnen, Ihre Limits viel schneller zu erreichen als gewohnt. Man kann
00:02:17dies also kaum mit den 20-Dollar-Plänen von Claude Code und Codex umsetzen. Falls Sie Claude Code nutzen,
00:02:22ist Ihnen das wahrscheinlich nicht ganz neu, da Sie mit dem dynamischen Workflow bereits einen Graphen gesehen haben.
00:02:27Ein dynamischer Workflow nimmt die übergebene Aufgabe und verteilt sie auf eine Reihe von Sub-Agenten,
00:02:33was im Grunde genau das ist, was ein Graph tut. Bevor wir zu den Formen kommen, die ein Graph annehmen kann, müssen Sie
00:02:38wissen, woraus er eigentlich besteht. Jeder Graph ist aus zwei Dingen aufgebaut: Knoten (Nodes) und Kanten (Edges). Ein Knoten ist
00:02:44im Grunde eine einzelne Teilaufgabe der größeren Gesamtaufgabe, und er läuft eigenständig. Es ist ein Agent,
00:02:49der eine Aufgabe in seinem eigenen, isolierten Kontextfenster erledigt und Rückmeldung gibt. Was all diese einzelnen Aufgaben
00:02:55verbindet, ist die Kante. Eine Kante steuert, wie die Daten von einem Knoten zum nächsten fließen, sodass die Ausgabe eines Agenten
00:03:01zum richtigen Zeitpunkt beim richtigen Agenten landet. Jeder Knoten muss also irgendwie mit dem Rest des Graphen
00:03:06verknüpft sein. Das sieht man bei einer Gruppe von Agenten, die alle dieselbe Arbeit überprüfen: Keiner von ihnen
00:03:10wartet je auf den anderen. Aber alle starteten bei derselben Arbeit, und jeder ihrer Berichte fließt
00:03:15am Ende an derselben Stelle zusammen. Daraus besteht also ein Graph. Hier sind die Formen, in denen diese Teile
00:03:20angeordnet werden können. Die erste ist eine Form, die wir auf diesem Kanal schon gezeigt haben, wobei wir damals den Namen
00:03:25falsch verwendet haben. Wir nannten es einen Loop, weil Graph Engineering damals noch gar kein Begriff war. Aber
00:03:30was wir tatsächlich hatten, war ein Graph, den wir als Schleife laufen ließen, und seine Form war ein Diamant. Eine Aufgabe an der
00:03:35Spitze teilt sich auf mehrere parallel laufende Sub-Agenten auf, und diese verengen sich dann wieder zu einem einzelnen
00:03:41Agenten, der alle ihre Ergebnisse zu einer Antwort zusammenführt. Dann gibt es den Fan-In-at-a-Barrier-Graphen,
00:03:46und das ist die Form, die man möchte, wenn eine Sache aus mehreren Blickwinkeln gleichzeitig beurteilt werden muss. Der Fan-Out-Teil
00:03:51sendet dasselbe Problem an eine Gruppe von Agenten, und jeder betrachtet es durch eine andere Brille.
00:03:56Nichts geht weiter, bis jeder dieser Agenten Bericht erstattet hat, und erst dann
00:04:00werden deren Korrekturen ausgeführt. Es gibt noch viele andere Formen. Aber jede dieser Formen stützt sich auf
00:04:05dieselbe Sache: Verifizierung. Wenn Sie diese Prüfungen nicht richtig einrichten, baut jeder nachfolgende
00:04:10Agent einfach auf einem Fehler auf. Bevor wir über Verifizierung sprechen, wäre es toll, wenn Sie den
00:04:15Kanal abonnieren und den Hype-Button drücken würden. Diese kleine Unterstützung hilft uns sehr weiter.
00:04:20Sobald man eine ganze Flotte von Agenten betreibt, gehen Dinge schief, die bei einem einzelnen nie passieren.
00:04:25Das größte Problem ist schlicht die Menge an Arbeit. Alle arbeiten gleichzeitig, sodass auf einmal ein riesiger
00:04:30Berg an Ergebnissen zurückkommt, den man am Ende nur schwer überprüfen kann. Das andere Problem ist,
00:04:34dass man nicht sieht, was passiert ist. Wenn etwas schiefgeht, hat man keine Möglichkeit zu erkennen, was die Ursache war.
00:04:39Nun verifizieren alle Agenten, was sie schreiben, ob man sie darum bittet oder nicht. Wenn Sie mit Code arbeiten,
00:04:44heißt das einfach, dass der Agent Ihre Tests ausführt und die zurückgemeldeten Fehler abfängt. Das erfasst aber nur schwere
00:04:49Fehler. Es prüft immer noch nicht, wie der Code geschrieben ist, und das ist wichtig: Wenn Claude
00:04:53ihn weiterhin so schreibt, wird das in Zukunft Probleme verursachen. Es gibt dafür einige integrierte
00:04:58Tools in Claude Code. Das erste ist der Verify-Skill, der den Code von Anfang bis Ende durchgeht
00:05:03und bestätigt, dass er sich tatsächlich wie vorgesehen verhält. Das zweite ist Tool Chaining, bei dem
00:05:08der Agent verschiedene Tools zur Verifizierung ausführt. Claude weiß bereits, welche Tools er ausführen muss, um
00:05:13Ihre Arbeit zu prüfen, liest also die Rückmeldungen und behebt die Fehler selbst. Er kann die genauen Befehle
00:05:18Ihres Projekts auch selbst herausfinden. Sie aber in Ihre Claude.md-Datei zu schreiben, erspart ihm das
00:05:24jedes Mal aufs Neue. Und das dritte ist ein Code-Review-Skill, der den Code
00:05:29gegen eine Reihe von Standards prüft. Nicht jeder Agent bringt einen mit, aber Sie können Ihren Agenten einfach bitten,
00:05:33Ihnen einen zu bauen, falls er keinen hat. Die am besten funktionierende Verifizierung ist jedoch die, die Sie selbst einrichten,
00:05:38anstatt sich komplett auf die integrierten Funktionen zu verlassen. Der schnellste Weg zur Erstellung eines Skills, der Ihre
00:05:44Arbeit verifiziert, ist das Skill-Creator-Plugin in Claude Code. Sie können diesen Claude-Code-Skill auch
00:05:49in Codex verwenden. Sie führen den Plugin-Befehl aus, suchen nach Skill Creator und installieren es. Von dort
00:05:54aus haben Sie zwei Optionen: Sie können es auf Benutzerebene (User Scope) installieren, sodass es verfügbar ist, egal in welchem
00:05:58Ordner Sie arbeiten. Oder Sie installieren es nur für das Projekt, an dem Sie gerade arbeiten.
00:06:03Da dies ein Skill ist, den Sie ständig nutzen werden, haben wir uns für die Benutzerebene entschieden. Danach
00:06:07laden Sie die Plugins mit dem Slash-Befehl neu, und Skill Creator ist einsatzbereit. Nun sagen Sie ihm,
00:06:12was gebaut werden soll – das ist der Teil, in dem Sie die Art von Verifizierung beschreiben, die Sie tatsächlich
00:06:17anstreben. Wir nutzen meist einen Review-Skill, um die fertige Arbeit mit dem abzugleichen, was wir ursprünglich
00:06:22angefordert haben. Und das ist in einem Graphen noch wichtiger, weil jeder Agent immer nur seinen eigenen Teil sieht.
00:06:28So erhält er eine Möglichkeit, diesen Teil mit den ursprünglichen Anforderungen abzugleichen. Ein Skill ist jedoch
00:06:32immer nur so gut wie das Modell, auf dem er läuft. Als wir das Verifizierungssystem für das UI unserer
00:06:37Community-Website bauten, ließen wir den Reviewer auf Haiku laufen, weil es günstig ist und die Aufgabe einfach genug
00:06:43aussah. Er lieferte eine lange Liste von Problemen. Rein nach der Anzahl der Funde sah es so aus,
00:06:47als hätte er großartige Arbeit geleistet. Dann ließen wir exakt dasselbe auf Opus laufen, und es bemängelte weit weniger Dinge.
00:06:53Das sah nach dem schlechteren Ergebnis aus – bis wir die Begründung lasen. Vieles von dem, was Haiku gemeldet hatte,
00:06:58hatten wir absichtlich so gelassen. Die meisten seiner Funde waren also völlig unnötig.
00:07:03Opus hatte das aus dem umliegenden Code erkannt, was Haiku komplett entgangen war. Der günstige
00:07:08Review hatte uns also nichts gespart, da nun die Überprüfung selbst überprüft werden musste. Übertragen Sie das
00:07:13nun auf einen Graphen, in dem eine ganze Reihe von Knoten ihre eigene Arbeit mit genau demselben Skill prüft:
00:07:18Sie hätten Agenten, die Zeit und Token damit verschwenden, Dinge zu korrigieren, die nie defekt waren. Und weil das
00:07:23über mehrere Agenten hinweg gleichzeitig passiert, könnten Sie unmöglich sagen, wer damit angefangen hat.
00:07:27Das gewählte Modell bestimmt also nicht nur die Qualität der Überprüfung, sondern die Qualität
00:07:31des gesamten Graphen. Der Knoten, der die Bewertung vornimmt, ist die eine Stelle, an der Token-Sparen alles
00:07:37kosten kann. Die andere Entscheidung ist, wie und wann dieser Skill aufgerufen wird. Und das
00:07:41unterteilt sie in drei Arten. Bevor wir jedoch tief in die Typen eintauchen, ein paar Worte von unserem Sponsor.
00:07:46Wenn Sie schon einmal Livedaten aus dem Web abgerufen haben, wissen Sie, dass Scraping echt mühsam ist: Man kämpft
00:07:51gegen Captchas und Rate-Limits, schlägt sich mit Proxys herum und flickt Layouts, die genau in dem Moment
00:07:56brechen, in dem man veröffentlicht. Deshalb nutzen wir SERP API, was all diese Probleme löst, damit Sie sich aufs Bauen konzentrieren können.
00:08:01Ein einziger API-Aufruf: Sie senden eine Anfrage und erhalten ein sauberes JSON-Objekt mit genau den Daten zurück, die Sie brauchen –
00:08:07mit über 99,9 % Uptime und rund 1,2 Sekunden Antwortzeit. Wenn Sie KI-Agenten bauen, können Sie
00:08:14die Google Search API auf einen Agenten richten, der aktuelle Infos braucht, oder die Google Scholar API für
00:08:20peer-reviewte Arbeiten mit vollständigen Metadaten nutzen, weshalb so viele Produktions-Agenten darauf setzen. Starten Sie mit
00:08:25250 kostenlosen Credits über den Link in der Beschreibung oder scannen Sie den QR-Code auf dem Bildschirm. Danke an SERP API für
00:08:32das Sponsoring dieses Videos. Die erste Art ist “Standalone”, also eine Art von Skill, die nur läuft, wenn Sie
00:08:37sie tatsächlich selbst ausführen. Ein Standalone-Skill ist dafür gebaut, etwas bereits Bestehendes tiefgehend zu analysieren, damit er
00:08:42ein fertiges Ergebnis gründlich überprüfen kann. Deshalb möchte man nicht, dass er nach jedem einzelnen Durchlauf feuert: Man würde
00:08:48Token für eine schwere Überprüfung von Arbeiten verschwenden, die noch gar nicht fertig sind. Ein Skill, den wir schon genutzt haben, ist der
00:08:53“thermonuclear code review” von Cursor. Er verteilt die Arbeit auf eine Reihe von Agenten und schickt jeden von ihnen unter
00:08:59einem anderen Sicherheitsaspekt durch den Code. Jeder Befund fließt an einer Stelle zusammen, damit man die Korrekturen
00:09:04gemeinsam abarbeiten kann – und das ist genau die Art von Review, die man erst ausführt, wenn die App fertig ist. Um so etwas zu bauen, nutzen Sie am besten
00:09:10Skill Creator, anstatt ihn nur per Prompt dazu aufzufordern, weil das Ergebnis getestet ist und sich dadurch leichter
00:09:15ihm zu vertrauen. Sagen Sie ihm im Prompt, welchen Bereich Sie überprüfen lassen möchten, und stellen Sie sicher, dass Sie erwähnen, dass die
00:09:20dass der Review umfassend sein soll, damit er weiß, dass Sie einen tiefen und keinen schnellen Durchgang wünschen. Ein Standalone-Skill
00:09:26nützt einem Knoten, der noch arbeitet, allerdings nichts, da Sie ihn selbst ausführen müssen. Genau dafür gibt es
00:09:31eingebettete (embedded) Skills. Ein eingebetteter Skill wird als Teil des bereits laufenden Workflows ausgelöst, ohne dass Sie danach
00:09:36fragen müssen. Sie könnten einen bauen, der immer dann greift, wenn jemand ein neues Feature anfordert. Er prüft,
00:09:41ob jede erstellte Komponente den im Skill festgelegten Regeln entspricht, und lässt den Abschluss der
00:09:45Implementierung erst zu, wenn sie gegen diese Regeln geprüft wurde. Sie können eingebettete Skills selbst
00:09:50bauen, aber Sie können keinen vorinstallierten nehmen und ihn automatisch aufrufen lassen – wie den
00:09:54Verify-Skill, über den wir vorhin gesprochen haben. Die Anweisungen, auf denen diese Skills basieren, liegen im Produkt selbst,
00:10:00und Sie können sie nicht anpassen. Um einen eigenen zu bauen, geben Sie Skill Creator einen Prompt mit der Anweisung, Verifizierungsschritte
00:10:05nach jeder Feature-Implementierung auszuführen. Weisen Sie ihn also an, das Feature von Anfang bis Ende zu testen, damit
00:10:10er erkennt, ob die neue Arbeit etwas beschädigt hat, das bereits funktionierte. Claude erstellt den Skill dann für
00:10:16Sie, und da Skill Creator ihn generiert hat, bringt er Referenzen und Skripte mit, die Skill Creator
00:10:21im Rahmen des Prozesses strukturiert und getestet hat. Um ein Feature zu verifizieren, nutzt Claude standardmäßig Browser-Testing,
00:10:26wobei er die Oberfläche prüft, indem er einen vollständigen Chrome-Browser öffnet, die Seite lädt und
00:10:31Screenshots davon macht. Wenn Sie Puppeteer oder Playwright eingebunden haben – also die Tools, die die meisten
00:10:36Nutzer verwenden, um einen Browser automatisch zu steuern –, machen diese dasselbe. Aber Chrome ist bekannt dafür, Arbeitsspeicher zu fressen
00:10:41und schwerfällig zu laufen. Um eine Seite innerhalb eines Workflows immer wieder zu prüfen, ist das so langsam, dass es
00:10:46echte Zeit kostet. Es gibt also einen leichtgewichtigeren Weg namens Chrome Headless Shell. Das ist im Grunde
00:10:52eine abgespeckte Version des Browsers, bei der alle überflüssigen Teile entfernt wurden. Der Agent steuert
00:10:57die Seite weiterhin an und macht seine Screenshots auf dieselbe Weise. Er erledigt das alles nur viel schneller als ein voller
00:11:02Chrome-Browser. Das können Sie direkt in den von Ihnen erstellten Verifizierungsskill einbauen. Jedes Feature,
00:11:07das der Agent baut, wird dann visuell geprüft, ohne dass Sie es jedes Mal neu einrichten müssen. Abgesehen davon
00:11:12ist der Skill, den wir in unserem eigenen Workflow am meisten nutzen, der sogenannte “Second Opinion”, und der Grund dafür ist einfach:
00:11:17Der Agent, der etwas gebaut hat, ist der denkbar schlechteste, um es zu überprüfen. Er beurteilt seine eigene Arbeit auf Basis
00:11:23desselben Kontextes, den er zum Bauen verwendet hat, und prüft daher nur darauf basierend. Eine frische Claude-Sitzung hat davon
00:11:28nichts gesehen. Sie liefert ein unvoreingenommenes Review und gibt eine ehrliche Antwort. Nun hat Claude zwar einen integrierten
00:11:33Advisor, der etwas Ähnliches tut, aber er liest den Chat, in dem Sie sich gerade befinden, und erbt
00:11:38somit genau diesen Kontext. Second Opinion ist für Fälle gedacht, in denen Sie die Überprüfung ohne diesen Kontext wünschen. Es funktioniert,
00:11:43indem aus der bereits laufenden Claude-Sitzung heraus eine weitere mit dem `-p`-Flag gestartet wird. Das ist das
00:11:48Flag, das im Hintergrund eine komplett separate Claude-Code-Sitzung startet, indem man ihr einen Prompt zur Bearbeitung
00:11:53übergibt. Es gibt jedoch ein paar Dinge, die Sie wissen müssen, wenn Sie dies nutzen möchten: Da eine
00:11:57völlig separate Sitzung gestartet wird, dauert es wirklich lange, bis eine Antwort zurückkommt,
00:12:02und das Modell spielt hier eine wichtigere Rolle als sonst wo, weil der ganze Sinn in einem klügeren, zweiten Blick liegt.
00:12:07Es lohnt sich also, Claude explizit anzuweisen, diese Sitzung auf Opus zu starten. Das gibt jedem Knoten in Ihrem
00:12:12Graphen die Möglichkeit, seine Arbeit von etwas prüfen zu lassen, das an der Erstellung nicht beteiligt war. Ein einzelner Skill kann
00:12:18jedoch nicht alles abdecken. Wenn man etwas richtig überprüft, betrachtet man es aus mehreren
00:12:22verschiedenen Blickwinkeln, und jeder Blickwinkel hat seine eigene Messweise. Man kann nicht alle Review-Arten in
00:12:27einen einzigen Skill stopfen, weil der Agent dann zu viele Prüfrichtungen hat und das Ergebnis am Ende schlechter statt besser
00:12:33wird. Man baut also für jeden Blickwinkel einen eigenen Skill und verkettet diese. Anthropics eigenes
00:12:38Team arbeitet genauso: Sie verketten den Code-Review-Skill mit dem Simplify-Skill und dem Verify-Skill,
00:12:43und alle drei werden mittlerweile mit Claude Code ausgeliefert. Darüber hinaus nutzen sie ihren eigenen Design-Skill,
00:12:49der das Interface mit der Datei design.md abgleicht – also der Datei, die jede
00:12:54Designentscheidung für das Produkt enthält. Das ist also eine Überprüfung aus vier Richtungen statt aus einer. Sie
00:12:59werden am selben Punkt landen: mit einem Stapel von Skills, die jeweils einen anderen Blickwinkel abdecken. Aber Sie können
00:13:04dem Agenten nicht einfach sagen, er solle alle auf einmal ausführen. Was Sie brauchen, ist ein weiterer Skill über den anderen,
00:13:09im Grunde ein Orchestrator-Skill, dessen einzige Aufgabe es ist, andere Skills auszuführen. Er startet einen Agenten für
00:13:15jeden Review-Skill, den Sie haben, und übergibt jedem seinen Skill. Alle überprüfen gleichzeitig in ihren
00:13:20eigenen, separaten Kontextfenstern. Dann führt er jeden Befund in einem Bericht zusammen, auf dessen Basis die korrigierenden
00:13:25Agenten arbeiten können. Wenn Sie dann einen Graphen bauen, müssen Sie im Prompt nur noch sagen, dass
00:13:30er diesen einen Skill nutzen soll. Jeder von ihm gestartete Knoten lädt diesen einzelnen Skill, und der gesamte Review fächert
00:13:35sich darunter von selbst auf. Wir haben ein Dokument zusammengestellt, das alle Möglichkeiten enthält, wie man
00:13:40Verifizierungen für Graphen im Detail einrichtet. Dieses Dokument sowie alle in diesem Video gezeigten Skills sind verfügbar
00:13:45in AI Labs Pro, unserer Community. Wenn Sie also Wert aus unserer Arbeit ziehen und den Kanal unterstützen
00:13:50möchten, ist das der beste Weg dafür. Der Link ist in der Beschreibung. Damit sind wir am Ende dieses
00:13:55Videos angelangt. Wenn Sie den Kanal unterstützen und uns helfen möchten, weiterhin Videos wie dieses zu machen, können Sie das tun,
00:14:00indem Sie unten den Super-Thanks-Button nutzen. Wie immer vielen Dank fürs Zuschauen und bis zum nächsten Mal.