GitHub war nicht für KI-Agenten gemacht (also hat Cloudflare ein eigenes Tool gebaut)

BBetter Stack
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00Cloudflow arbeitet an etwas namens Artifacts, einem verteilten Dateisystem, das
00:00:05Git-kompatibel und speziell für Agenten entwickelt ist. Es ermöglicht das programmgesteuerte Erstellen, Forken
00:00:10oder Löschen von Tausenden Repos, egal wie groß oder klein sie sind, für Dinge wie parallele
00:00:15PR-Reviews, automatisches Refactoring großer Codebasen und Agenten-Arbeitsbereiche pro Sitzung.
00:00:20Aber da dies auf Durable Objects aufbaut, bedeutet das, dass man JavaScript verwenden muss
00:00:25und keinen Zugriff auf einen Shell-Befehl zum Ausführen von Git hat?
00:00:28Abonnieren und lasst es uns herausfinden!
00:00:33GitHub wurde für Menschen gebaut, nicht für Agenten, was bedeutet, dass sie keine der sozialen
00:00:37Aspekte brauchen, wie Follower oder Diskussionen. Aber Agenten sind sehr gut in Git, es steckt in ihrem
00:00:42Trainingsdaten.
00:00:43Cloudflare hat also eine einfache Git-Implementierung in Zig gebaut, sie zu Wasm kompiliert und auf ein
00:00:49Durable Object gelegt, um als Git-Server zu fungieren.
00:00:52Der Client selbst kann derweil alles sein, was man möchte, wie etwa ein Worker, der Isomorphic Git
00:00:57innerhalb eines Workers verwendet, oder das Git-Protokoll und sogar der HTTP-Client, sodass man sich
00:01:03auch damit verbinden kann, wenn man kein JavaScript verwendet.
00:01:05Nun, zum Zeitpunkt der Aufnahme habe ich leider keinen Zugriff auf Artifacts, da es
00:01:10sich in der privaten Beta befindet. Aber es gibt viel Dokumentation dazu, was bedeutet, dass ich eine Demo mit
00:01:15Code aus dieser Dokumentation erstellen kann, und vielleicht könnt ihr, sobald es in der öffentlichen Beta ist,
00:01:19prüfen, ob mein Code tatsächlich funktioniert.
00:01:20Was wir also tun werden, ist ein Tool zu bauen, das eine Liste von Aufgaben für ein bestimmtes
00:01:24Repo entgegennimmt und all diese Aufgaben parallel ausführt, indem das Repo mehrfach geforkt
00:01:29und jede Aufgabe auf einem eigenen Artefakt in einem Cloud-Repo auf einem Durable Object ausgeführt wird.
00:01:34Schauen wir mal, wie das funktioniert.
00:01:35Ich habe damit begonnen, die Dokumentation für Artifacts und die ersten Schritte für Worker zu befolgen,
00:01:39also habe ich diesen Befehl verwendet. Der Text hier nach diesem Befehl ist nur der Name des Projekts
00:01:44und kann beliebig sein.
00:01:45Ich bin also all diese Schritte durchgegangen, was mir diesen grundlegenden Worker-Code geliefert hat.
00:01:49Und Worker für Artifacts sind etwas performanter als die Verwendung der REST-API, da sie
00:01:53weniger Roundtrips benötigen.
00:01:55Danach muss man die Artifacts-Bindings zur wrangler.jsonc- oder toml-Datei hinzufügen
00:02:00und dann die Typen neu generieren.
00:02:02Die Dokumentation hier konzentriert sich auf das Erstellen eines neuen Repos, verwendet also das Artifacts-Binding
00:02:07mit der create-Methode und einem Repo-Namen.
00:02:09Es erstellt den Namen, was einem das Token und den Remote gibt.
00:02:13Der Remote ist also der Speicherort des Artefakts, und das Token oder Auth-Token wird ebenfalls benötigt,
00:02:17um Zugriff darauf zu erhalten.
00:02:18Natürlich kann man das Git-Protokoll mit dem Remote und dem Token verwenden, um mit
00:02:22dem Artefakt zu interagieren.
00:02:23Aber wir werden etwas anderes tun.
00:02:25Anstatt ein brandneues Repo in einem Artifacts-Durable-Object zu erstellen, werden wir zuerst
00:02:29prüfen, ob bereits eines namens "baseline" existiert.
00:02:31Wenn es nicht existiert, werden wir ein Git-Repo importieren, ihm den Namen "baseline"
00:02:35geben und dann diesen Wert hier zurückgeben.
00:02:39Und wenn ihr euch die API-Dokumentation für die Worker-Bindings anseht, werdet ihr weitere
00:02:43Parameter sehen, die der Import-Methode hinzugefügt werden können.
00:02:45Sobald wir das existierende Repo zurückgegeben haben, können wir einige sehr coole Dinge
00:02:49damit anstellen.
00:02:50Hier sind die Aufgaben, die ich für das Repo erledigen möchte. Ich habe sie zwar hartcodiert,
00:02:53aber sie könnten auch über eine Eingabe oder eine Art UI hinzugefügt werden.
00:02:56Und hier, innerhalb des Worker-Standard-Exports, habe ich das Anthropic-SDK sowie mein
00:03:00Baseline-Repo.
00:03:02Ich werde die Aufgaben durchlaufen und hier das Repo mit
00:03:06diesem Namen forken.
00:03:07Dann haben wir diese Funktion, die ich später noch erkläre, aber sie führt die Aufgabe innerhalb
00:03:10des geforkten Repos aus, lässt den Agenten die Änderung vornehmen und gibt die Zusammenfassung des Agenten zurück.
00:03:15Also das Letzte, was der Agent gesagt hat. Nach jeder For-Schleife gebe ich diese
00:03:19Informationen zurück.
00:03:20Ich gebe den Namen der Aufgabe, den Namen des Forks, den Remote und das Token zurück,
00:03:23sodass wir jederzeit darauf zugreifen können, um zu sehen, ob die Änderung gut ist, sowie die Zusammenfassung
00:03:27dessen, was getan wurde.
00:03:28Im Moment bieten die Worker-Bindings noch nicht die Möglichkeit, zu pullen, zu committen und zu pushen.
00:03:33Deshalb musste ich das in meinem Code mit Isomorphic Fetch lösen und ein In-Memory-Speichersystem
00:03:38verwenden, um die Änderungen temporär zu speichern.
00:03:39Zurück im Agenten-Code: Wir erstellen unser Dateisystem im Arbeitsspeicher und haben dann ein
00:03:43System-Prompt, das den Agenten anweist, die relevanten Änderungen vorzunehmen und dann den Code
00:03:47zu committen.
00:03:48Wir werden also das geforkte Repo unter Verwendung des bereitgestellten Remotes sowie des Tokens
00:03:51clonen.
00:03:52Und dann definieren wir einige Tools: lesen, schreiben und committen.
00:03:55Hier wählen wir das Modell aus, geben ihm einen System-Prompt und übergeben dann die Aufgabe
00:03:59als Benutzernachricht.
00:04:00Der Rest des Codes ist eure Standard-Agentenschleife.
00:04:02Wenn es also einen Tool-Aufruf gibt, stoppen wir die Überlegung und führen den Tool-Aufruf aus – in unserem Fall lesen, schreiben
00:04:07oder committen, was nach dem Commit auch den Push des Codes durchführt.
00:04:10Der Vorteil eines Artefakts besteht darin, dass dieser gesamte Code im Durable Object existiert,
00:04:14gespeichert in der SQLite-Datenbank des Objekts. Sollte das Durable Object ausfallen, können die Informationen
00:04:20jederzeit aus der SQLite-Datenbank abgerufen werden, sobald es wieder online ist.
00:04:23Und weiter unten setzen wir die Überlegung des Modells nach dem Tool-Aufruf fort, bevor wir die
00:04:27letzte Nachricht des Modells zurückgeben.
00:04:29Ich weiß, es ist sehr schwer, sich das alles vorzustellen, ohne dass ich den Code
00:04:32ausführen kann, aber hoffentlich könnt ihr erahnen, was mit Artefakten und ihrem vollen Potenzial
00:04:37möglich ist.
00:04:38Stellt euch vor, ihr hättet ein UI, um alle Änderungen in diesen Artefakten zu sehen,
00:04:42und ihr könntet mit einzelnen Agenten oder einem zentralen Orchestrator-Agenten kommunizieren, um Änderungen
00:04:46an den verschiedenen Repos vorzunehmen.
00:04:48Wo wir gerade bei einem Orchestrator-Agenten sind: Wir könnten einen einzelnen Worker haben, der
00:04:52alle diese Änderungen orchestriert und sie in das Haupt-Repo mergt, nachdem ein Reviewer-Agent den
00:04:56Code durchgesehen hat.
00:04:57Wir können sogar Artefakte mit dynamischen Workern kombinieren, sodass Agenten den von ihnen geänderten Code ausführen können,
00:05:02um zu sehen, ob er funktioniert.
00:05:03Und wenn es kein JavaScript-Code ist, können wir Cloudflare-Sandboxes verwenden, um jede gewünschte Sprache
00:05:07und sogar Shell-Befehle auszuführen.
00:05:09Ganz zu schweigen von der Cloudflare-Browser-Option, die einen Puppeteer-Browser ausführt, damit das
00:05:13Modell ihn sich ansehen kann, um zu prüfen, ob der implementierte Code bei einer Frontend-Änderung korrekt ist.
00:05:18Ich hatte ehrlich gesagt viel Spaß daran, über die Möglichkeiten von Artefakten nachzudenken, auch wenn
00:05:21ich sie noch nicht ausführen kann.
00:05:22Aber eines ist mir aufgefallen: Es gibt keinen git-diff-Befehl.
00:05:25Er ist weder in der Worker-Bindings-API noch in Isomorphic Git verfügbar.
00:05:30Vielleicht ist der einzige Weg, einen Git-Diff zu machen, das Git-Protokoll, oder sie fügen es in
00:05:35Zukunft hinzu.
00:05:36Auf jeden Fall: Wenn man es ohne das Git-Protokoll tun möchte, könnte man wohl
00:05:40Isomorphic Git verwenden, um mit git log den Git-Tree zu finden, diesen zu durchlaufen und
00:05:45die Unterschiede zu vergleichen.
00:05:46Davon abgesehen halte ich das für ein sehr cooles Release von Cloudflare.
00:05:50Und obwohl es bereits andere Dateisystem-Tools wie S3-Dateien, ZeroFS und JuiceFS gibt,
00:05:55glaube ich nicht, dass diese Optionen Git-kompatibel sind, was ein sehr cooles Feature
00:05:59und agentenfreundlicher ist.
00:06:01Wo wir gerade bei S3 sind: Wenn ihr es jemals lokal auf eurem Rechner ausführen wolltet, dann seht euch
00:06:05dieses Video von Josh an, das euch genau zeigt, wie das geht.

Key Takeaway

Cloudflare Artifacts bietet eine hochperformante, Git-kompatible Infrastruktur auf Durable Objects, die KI-Agenten ermöglicht, massiv parallele Code-Modifikationen direkt in Cloud-Repositories durchzuführen.

Highlights

Cloudflare Artifacts fungiert als Git-kompatibles, verteiltes Dateisystem auf Basis von Durable Objects, das speziell für KI-Agenten konzipiert ist.

Die Architektur ermöglicht das programmgesteuerte Erstellen, Forken und Löschen tausender Repositories für parallele Arbeitsabläufe wie automatisches Refactoring.

Git-Operationen innerhalb der Artifacts-Implementierung basieren auf Zig und sind zu WebAssembly (Wasm) kompiliert, um direkt in Cloudflare-Umgebungen zu laufen.

Daten in Artefakten werden in der SQLite-Datenbank der Durable Objects persistiert, wodurch sie nach Objektausfällen sofort wieder abrufbar sind.

Das System integriert sich mit externen Agenten-Frameworks über das Git-Protokoll oder HTTP-Clients, was die Nutzung abseits von JavaScript ermöglicht.

Timeline

Konzeption von Artifacts als Agenten-Infrastruktur

  • GitHub-Funktionen wie soziale Interaktionen sind für automatisierte Agenten irrelevant.
  • Die Implementierung nutzt Zig-Code, der zu Wasm kompiliert auf Durable Objects läuft.

Herkömmliche Git-Plattformen sind auf menschliche Zusammenarbeit ausgelegt. Cloudflare adressiert diesen Mangel durch ein natives Git-Server-Modell für Agenten. Die Architektur nutzt Durable Objects als Host, wobei Client-seitig Worker oder HTTP-Clients für den Zugriff fungieren.

Technische Integration und Workflow-Automatisierung

  • Artifacts-Bindings reduzieren Roundtrips im Vergleich zur klassischen REST-API erheblich.
  • Workflows nutzen ein Baseline-Repo als Ausgangspunkt für parallele Forks.

Die Entwicklung umfasst das Erstellen von Workern, die via Artifacts-Bindings direkt mit Repositories interagieren. Repositories werden auf Anfrage geforkt, wobei das System Auth-Token und Remote-URLs für den Git-Zugriff generiert. Dies ermöglicht eine skalierbare Struktur für parallele Aufgaben.

Agenten-Agentur und Ausführungsumgebungen

  • Isomorphic Fetch ermöglicht In-Memory-Speicherung bei fehlenden nativen Pull-Push-Funktionen.
  • Cloudflare-Sandboxes und Browser-Optionen ergänzen Artefakte um Ausführungs- und Validierungsmöglichkeiten.

Da bestimmte Git-Operationen wie Push oder Commit innerhalb der Bindings noch in Entwicklung sind, erfolgt die Zwischenspeicherung in einem In-Memory-Dateisystem. Zur Validierung von Änderungen können ergänzende Tools wie Cloudflare-Sandboxes oder Browser-Puppeteer genutzt werden, um Code-Ergebnisse direkt zu verifizieren. Die SQLite-Integration sorgt für die notwendige Persistenz der Arbeitszustände.

Community Posts

View all posts