Wie Sharkly Agenten parallel ausführt – ohne Merge-Konflikte

Lässt man zwei Coding-Agents im selben Checkout laufen, trifft man binnen einer Stunde auf das typische Fehlerbild. Der eine Agent wechselt den Branch, während der andere mitten im Editieren steckt. Gestagte Änderungen verschwinden in einem Commit, zu dem sie nicht gehören. Tests laufen erfolgreich gegen eine Datei, die der andere Agent zur Hälfte umgeschrieben hat. Nichts davon ist die Schuld des Modells. Ein Git-Arbeitsverzeichnis ist gemeinsam genutzter, veränderlicher Zustand – und zwei Prozesse, die solchen Zustand ohne Koordination verändern, werden ihn früher oder später beschädigen.

Die Standardlösung ist bekannt: Jeder Agent bekommt sein eigenes Arbeitsverzeichnis. Git-Worktrees erlauben es einem Repository, gleichzeitig mehrere ausgecheckte Verzeichnisse bereitzustellen, sodass parallele Branches nie dieselben Dateien auf der Festplatte anfassen. Viele Teams skripten das per Hand; unser Leitfaden zur Verwendung von Git-Worktrees mit KI-Coding-Agents führt durch dieses DIY-Setup.

In diesem Beitrag geht es um den anderen Weg: darum, was passiert, wenn Isolierung, Verzeichnisvorbereitung, Nebenläufigkeitsgrenzen und Aufräumen von der Plattform übernommen werden statt von Ihren Shell-Skripten.

TL;DR

Sharkly führt KI-Agents parallel und ohne Merge-Konflikte aus, indem jeder Task-Run sein eigenes isoliertes Verzeichnis auf einem verbundenen Computer erhält. Ein lokaler Dienst auf diesem Computer nimmt jeden in der Warteschlange stehenden Run entgegen, bereitet das Task-Verzeichnis vor (bei repository-basierter Arbeit ein separates Git-Worktree pro Run), startet die ausgewählte Runtime und überträgt Fortschritt, Trace-Events und das Ergebnis zurück an den Task. Nebenläufigkeitsgrenzen am Agent und am Computer begrenzen, wie viele Runs gleichzeitig laufen, und nichts wird von selbst gemergt: Das Ergebnis geht zurück an den Task, wo eine Person die Änderung prüft und über Merge- und Release-Schritt entscheidet. Agents teilen sich nie ein Arbeitsverzeichnis, sodass parallele Tasks die Änderungen der jeweils anderen nicht überschreiben können.

Das Fehlerbild, das Sharkly verhindern soll

Es lohnt sich, genau zu benennen, was schiefgeht, wenn Agents sich ein Checkout teilen, denn jedes Symptom entspricht einem Teil der Lösung.

Der Branch-Zustand ist pro Arbeitsverzeichnis global: Wenn Agent A seinen eigenen Branch auscheckt, ändern sich für Agent B mitten im Run die Dateien unter den Füßen. Auch der Index ist global, sodass git add und git commit Arbeit aus verschiedenen Tasks vermischen. Nicht versionierter Zustand kollidiert: Build-Ausgaben und Dependency-Installationen des einen Runs verfälschen die Testergebnisse eines anderen. Und es sammelt sich Aufräumschuld an, weil jede Ad-hoc-Kopie des Repositories, die angelegt wurde, um die ersten drei Probleme zu umgehen, auf der Festplatte liegt, bis sich ein Mensch an sie erinnert.

Ein einzelnes gemeinsam genutztes Verzeichnis kann immer nur einen Agent sicher ausführen. Wenn Sie das mit tmux-Panes und Disziplin jonglieren, erklärt unser Beitrag zum parallelen Ausführen mehrerer Claude Code Agents, warum diese Obergrenze so schnell erreicht ist.

Der Ausführungs-Stack: Agent, Computer, Runtime, Task

Sharkly ist kein Ersatz für Claude Code, Codex oder andere Ausführungswerkzeuge. Es ergänzt die Ebene für gemeinsame Tasks, Computer, Kontext, Steuerung und Review um die Tools, die Ihr Team bereits nutzt. Diese Positionierung als Ebene bestimmt, wie die parallele Ausführung funktioniert, denn Sharklys Aufgabe ist es, Runs zu koordinieren, nicht Code zu schreiben.

Vier Rollen teilen sich die Arbeit, und jede hat genau eine Aufgabe:

• Der Agent legt fest, wie Arbeit behandelt werden soll: seine Anweisungen, Skills, Repositories und Run-Einstellungen. Ein Agent ist nicht der Ausführungs-Host.
• Der Computer stellt den Host und die lokalen Ressourcen bereit: einen lokalen Rechner, einen Remote-Server, einen Container oder einen unterstützten Cloud-Host. Der begleitende Beitrag zu Computers in Sharkly behandelt deren Verbindung.
• Die Runtime führt die eigentliche Agent-Session aus. Sie ist das konkret auf diesem Computer installierte Tool, etwa Claude Code, Codex oder Gemini CLI.
• Der Task bleibt der gemeinsame Datensatz für das Team: Ziel, Status, Diskussion, Ausführungs-Trace und Ergebnis.

Zusammengehalten werden sie von einem kleinen lokalen Dienst auf dem Computer. Er registriert den Computer, erkennt installierte Runtimes, nimmt in der Warteschlange stehende Runs entgegen, bereitet für jeden Run das Task-Verzeichnis vor, startet die Runtime und meldet Ergebnisse zurück. Er baut die Verbindung zum Server auf, sodass ein typisches Setup keinen eingehenden Port benötigt.

Genau diese Trennung macht Parallelität beherrschbar. Weil das Arbeitsverzeichnis pro Run vom lokalen Dienst vorbereitet und nicht vom Agent gewählt wird, können zwei Agents, die zwei Tasks zugewiesen sind, dasselbe Repository auf demselben Computer ansprechen, ohne je die Dateien des jeweils anderen zu sehen. Wie Agents konfiguriert werden, erfahren Sie unter Agents in Sharkly.

Was passiert, wenn ein Run startet

Weisen Sie einem Agent einen Task zu und verschieben Sie ihn aus dem Backlog, prüft Sharkly die Ausführungsbereitschaft, stellt einen geeigneten Run in die Warteschlange und schickt ihn an den ausgewählten Computer. Von da an übernimmt der lokale Dienst. Bevor die Runtime startet, muss er gegebenenfalls auf freie Nebenläufigkeitskapazität warten, ein isoliertes temporäres Verzeichnis vorbereiten oder auf ein freies spezifiziertes warten, die konfigurierten Repositories abrufen, die erlaubten Umgebungsvariablen bereitstellen und den Runtime-Aufruf zusammenbauen.

Erst dann startet die Runtime. Der Run durchläuft explizite Zustände: Queued, Dispatched, Waiting for local directory, Running und schließlich Completed, Failed oder Canceled. Diese Zustände erscheinen im Ausführungsprotokoll des Tasks, sodass die Frage „Warum ist bisher nichts passiert?“ eine nachprüfbare Antwort hat statt einer Vermutung. Ein Run, der wegen einer ausgeschöpften Nebenläufigkeitsgrenze in Queued hängt, sieht anders aus als einer, der in Waiting for local directory feststeckt – und der Unterschied zeigt Ihnen, an welcher Schraube Sie drehen müssen.

Beachten Sie, was fehlt: An keiner Stelle entscheidet der Agent, wo ausgeführt wird. Der Agent bringt die Anweisungen, die Infrastruktur bringt die Isolation.

Isolierte Worktrees: So funktioniert der Temporary-Modus

Agents unterstützen zwei Modi für das Arbeitsverzeichnis, und der für paralleles Arbeiten konzipierte Modus ist der Temporary-Modus. Jeder Task erhält ein isoliertes Verzeichnis, und bei repository-basierter Arbeit kann der lokale Dienst für jeden Run aus seinen zwischengespeicherten Repository-Daten ein separates Git-Worktree vorbereiten.

Dieser eine Satz enthält die gesamte Geschichte der Konfliktvermeidung. Ein Worktree gibt jedem Run sein eigenes ausgechecktes Verzeichnis und seinen eigenen Branch-Zustand, während die zugrunde liegenden Repository-Objekte geteilt werden. Die vier oben genannten Fehlerbilder verschwinden konstruktionsbedingt: kein gemeinsamer Branch-Zeiger, kein gemeinsamer Index, keine gemeinsamen Build-Artefakte und Verzeichnisse, die die Plattform später aufräumen kann. Weil Worktrees aus zwischengespeicherten Daten statt aus einem frischen Clone entstehen, bleiben die Startkosten vertretbar – auch wenn ein Run weiterhin Netzwerkzugriff benötigt, um das Repository zu aktualisieren.

Die Dokumentation sagt klar, wann das sinnvoll ist: Der Temporary-Modus wird für parallele Codeänderungen empfohlen und für jede Situation, in der mehrere Tasks gleichzeitig dieselbe Codebasis verändern könnten.

Eine Grenze sollte man klar benennen: Isolation verhindert Kollisionen im Arbeitsverzeichnis, nicht semantische Konflikte. Wenn zwei Tasks dieselbe Funktion umschreiben, laufen beide Runs sauber in ihren eigenen Worktrees durch – und bei der Review muss trotzdem ein Mensch die Überschneidung auflösen. Die Lösung dafür ist, Tasks so zuzuschneiden, dass sie nicht am selben Nachmittag auf denselben Code zielen: eine Planungsentscheidung, keine Infrastrukturentscheidung.

Wann Isolation die falsche Wahl ist: der Specified-Modus

Den zweiten Modus gibt es, weil ein frisches Verzeichnis pro Run nicht umsonst ist. Im Specified-Modus läuft der Agent in einem konfigurierten absoluten lokalen Verzeichnis aus seinem Pool und nutzt das dort bereits vorhandene Repository, die Dependencies und Caches wieder. Er ist nur auf lokalen Computern verfügbar.

Dieser Tausch hat eine harte Konsequenz: Ein spezifiziertes Verzeichnis bedient immer nur einen Run, und wenn alle konfigurierten Verzeichnisse belegt sind, wartet der nächste Run. Ein Agent, der im Specified-Modus mehrere Tasks gleichzeitig ausführen muss, braucht mehrere Verzeichnisse in seinem Pool.

Isolation erkauft Sicherheit mit Vorbereitungsaufwand; Wiederverwendung erkauft Geschwindigkeit mit Serialisierung. Sharkly lässt Sie pro Agent explizit wählen – besser, als den Kompromiss in einem beschädigten Arbeitsverzeichnis zu entdecken.

Nebenläufigkeitsgrenzen: parallel, aber begrenzt

Unbegrenzte Parallelität ist selbst ein Fehlerbild. Jeder gleichzeitige Run verbraucht CPU, Speicher, Festplatte, Kapazität des Modell-Anbieters und Repository-Bandbreite; acht Agents, die einen Laptop in die Knie zwingen, liefern schlechtere Ergebnisse als drei, die entspannt laufen.

Sharkly begrenzt die Nebenläufigkeit auf zwei Ebenen. Der Computer hat als Host ein Limit für die Task-Nebenläufigkeit, und jeder Agent hat eine maximale Anzahl parallel laufender Tasks plus einen Timeout pro Task. Die Standardwerte sind konservativ: Im Temporary-Modus erhält ein Agent 50 Prozent des Computer-Limits, im Specified-Modus entspricht der Wert der Anzahl der konfigurierten Verzeichnisse. Setzt man ihn höher als die Anzahl der Verzeichnisse, warnt das Produkt, dass Schreibzugriffe zwischen Tasks kollidieren können. Diese Warnung ist die These dieses Beitrags, komprimiert in ein Dialogfenster.

Die Empfehlung der Dokumentation zum Anheben der Limits ist die nüchterne Sorte: Erhöhen Sie die Nebenläufigkeit erst, wenn der aktuelle Computer und die Runtime die bestehende Last zuverlässig bewältigen.

Fortschritts-Streaming und Review vor dem Merge

Isolation wäre ein Nachteil, wenn sie auch Unsichtbarkeit bedeutete. Fünf Agents in fünf versteckten Verzeichnissen – genau so verschwindet Arbeit in privaten Terminals. Deshalb fließt alles, was ein Run produziert, zurück in den gemeinsamen Datensatz.

Während ein Run aktiv ist, zeigt der Task seinen Ausführungsstatus. Die Activity führt Kommentare und Task-Änderungen in einer Timeline zusammen; das Ausführungsprotokoll hält fest, wann der Run begonnen und geendet hat, die Tool-Aufrufe und Runtime-Events, die Auslösequelle und alle Fehlerdetails; der Bericht des Agents wird als Kommentar gespeichert, der mit seinem Ausführungs-Trace verknüpft ist. Kontext, Fortschritt, Blocker und Ergebnisse bleiben von der Anfrage bis zum Release sichtbar, obwohl die Dateiänderungen in einem Verzeichnis stattfanden, das nie ein Mensch geöffnet hat.

Dann kommt das Gate. Hier wird nichts von selbst gemergt. Agents recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab. Wenn ein Run abgeschlossen ist, kann der Agent den Task auf menschliche Review warten lassen, was im Posteingang der verantwortlichen Person auftaucht. Isolierte Worktrees machen die parallele Ausführung sicher; das Review-Gate macht sie vertrauenswürdig.

Ein weiteres Element schließt den Kreis: das Aufräumen. Agent-Runs hinterlassen Arbeitsverzeichnisse und Artefakte auf dem Computer, und ein konfigurierbares Cleanup räumt abgeschlossene Runs nach einem Aufbewahrungszeitraum auf, mit einem Mindestwert für freien Speicherplatz als Sicherheitsnetz. Laufende oder in der Warteschlange befindliche Arbeit, gepinnte Runs und fehlgeschlagene Runs, die noch untersucht werden müssen, werden nie angetastet. Genau diese Pflichtaufgabe vergessen DIY-Setups zuverlässig, bis die Festplatte voll ist.

Was Sharkly automatisiert – und was das DIY-Setup selbst übernimmt

Wenn Sie unseren DIY-Leitfaden zu Worktrees gelesen haben, ist die Zuordnung direkt. Das git worktree add, das Sie pro Agent skripten, wird zum lokalen Dienst, der pro Run ein isoliertes Verzeichnis vorbereitet. Die Ermessensfrage „Wie viele Agents sind zu viele?“ wird zu expliziten Nebenläufigkeitsgrenzen mit Warnungen, wenn eine Einstellung unsicher ist. Das git worktree prune, das Sie vergessen, wird zum aufbewahrungsbasierten Cleanup. Und der Teil, den kein Skript liefert – ein gemeinsamer Datensatz darüber, welcher Run was getan hat und ob ein Mensch ihn abgenommen hat –, ist der Task selbst.

Auch hier gilt die ehrliche Abwägung. Ein Solo-Entwickler, der zwei Agents auf einer Maschine laufen lässt, braucht vielleicht keine Plattform; ein Worktree-Skript und Disziplin tragen ihn weit genug. Zu Sharkly greifen Sie, wenn die Koordination mehr kostet als das Tippen: mehrere Personen, die Arbeit zuweisen, mehrere Computer, Runs, die Warteschlangen und Review brauchen. In beiden Fällen behalten Sie die Runtimes, die Sie bereits haben; die Modellnutzung läuft weiter über die Abonnements oder API-Keys, die in diesen Tools konfiguriert sind.

Der Einstieg ist bewusst klein gehalten. Verbinden Sie einen Computer, erstellen Sie einen Agent im Temporary-Modus und weisen Sie ihm einen risikoarmen Task zu. Der Leitfaden für den Einstieg führt in etwa zehn Minuten durch den ersten Durchlauf, die Sharkly-Dokumentation behandelt jedes Konzept ausführlich, und Was Sharkly ist beschreibt die Plattform rund um die Ausführung.

FAQ

Wie verhindert Sharkly Merge-Konflikte zwischen parallelen Agents?

Jeder Task-Run erhält sein eigenes isoliertes Verzeichnis auf dem Computer, und repository-basierte Runs können jeweils ein eigenes Git-Worktree erhalten, das der lokale Dienst vorbereitet. Agents teilen sich weder ein Checkout noch einen Index oder unversionierte Dateien, sodass gleichzeitige Runs die laufende Arbeit des jeweils anderen nicht überschreiben können. Überschneidungen, bei denen zwei Tasks bewusst denselben Code ändern, löst weiterhin ein Mensch zum Zeitpunkt der Review auf.

Muss ich Git-Worktrees selbst einrichten, um Sharkly zu nutzen?

Nein. Im Temporary-Modus bereitet der lokale Dienst das Task-Verzeichnis für jeden Run vor, einschließlich Worktrees für repository-basierte Arbeit. Sie konfigurieren den Modus einmal am Agent; es gibt keine Worktree-Befehle, die pro Run geskriptet werden müssten. Um den zugrunde liegenden Mechanismus zu verstehen, lesen Sie die Git-Worktree-Dokumentation.

Wie viele Agents können auf einem Computer parallel laufen?

Der Computer hat sein eigenes Limit für die Task-Nebenläufigkeit, und jeder Agent hat eine maximale Anzahl parallel laufender Tasks. Standardmäßig erhält ein Agent im Temporary-Modus 50 Prozent des Computer-Limits, einer im Specified-Modus einen Slot pro konfiguriertem Verzeichnis. Runs über dem Limit hinaus warten in der Warteschlange.

Werden die Änderungen des Agents von Sharkly automatisch gemergt?

Nein. Ergebnis, Belege und Trace des Runs gehen zurück an den Task, und eine Person prüft die Änderungsübersicht, bevor irgendetwas ausgeliefert wird. Die prüfende Person nimmt an, fordert Änderungen an oder entscheidet über den Merge- und Release-Schritt. Die Automatisierung endet dort, wo das Urteilsvermögen des Teams gefragt ist.

Wann sollte ich den Specified-Modus statt isolierter Worktrees verwenden?

Nutzen Sie ihn, wenn die Vorbereitung eines frischen Verzeichnisses pro Run wirklich teuer ist: ein sehr großes Repository, kostspieliger generierter Zustand oder Caches oder Tooling, das an einen lokalen Pfad gebunden ist. Akzeptieren Sie, dass jedes spezifizierte Verzeichnis immer nur einen Run bedient. Für alles andere ist der Temporary-Modus die empfohlene Standardeinstellung.