Eine Gemini-CLI-Sitzung ist ein einzelner Agent, der in einem Verzeichnis arbeitet. Sobald Sie eine zweite Aufgabe gleichzeitig laufen lassen wollen – einen Bugfix, während ein Refactoring läuft, Tests, die geschrieben werden, während ein Feature landet –, öffnen Sie ein weiteres Terminal. Dann ein drittes. Nach einer Stunde haben Sie vier Tabs, vier Arbeitsverzeichnisse und keine klare Antwort auf eine einfache Frage: Welcher Agent macht was, und welcher hat gerade die Datei angefasst, die Sie bearbeiten wollten?
Mehrere Gemini-Aufgaben nebeneinander laufen zu lassen, ist nicht schwer anzufangen. Schwer ist es, den Überblick zu behalten. Jede Instanz ist für sich schnell; der Preis ist die Koordination, und genau die liefert Ihnen das Terminal nie.
Dieser Artikel führt durch das manuelle Setup für parallele Gemini-CLI-Agenten, benennt den Fehlerfall, der bei jedem Schritt lauert, und zeigt, wo ein Task-Board übernimmt. Dieses Task-Board ist Sharkly, eine All-in-One-Plattform für Agent-Steuerung und -Management. Sharkly ersetzt die Gemini CLI nicht. Es ergänzt die Runtimes, die Ihr Team ohnehin nutzt, um eine gemeinsame Ebene für Aufgaben, Computer, Kontext und Review – damit parallele Runs zuweisbar und nachvollziehbar bleiben, statt sich über unzählige Tabs zu verteilen.
Was „parallele Agenten“ bei der Gemini CLI bedeuten
Die Gemini CLI führt einen Agenten pro Prozess aus. Sie liest das aktuelle Verzeichnis, lädt eine etwaige GEMINI.md-Kontextdatei und arbeitet Ihren Prompt in diesem einen Arbeitsbaum ab. Es gibt keinen eingebauten Dispatcher, der ein Ziel auf mehrere Sub-Agenten verteilt und deren Arbeit anschließend für Sie zusammenführt.
In der Praxis bedeutet „parallele Gemini-Agenten“ also eines: mehrere gemini-Prozesse laufen gleichzeitig, jeder in seiner eigenen isolierten Umgebung, jeder an seiner eigenen Aufgabe. Die Gemini CLI ist Open Source und lässt sich kostenlos mit einem persönlichen Google-Konto betreiben – genau deshalb starten viele Leute gleich vier davon. Der Engpass war nie das Starten. Er besteht darin, vier unabhängige Runs davon abzuhalten, im selben Repository zusammenzustoßen, und eine Stunde später zu wissen, was jeder einzelne hervorgebracht hat.
Das ist dasselbe Koordinationsproblem, auf das Sie bei Claude Code oder Codex stoßen. Die Runtime ändert sich, das Chaos nicht.
Das manuelle Setup, Schritt für Schritt
Hier ist die kleinste funktionierende Variante paralleler Gemini-CLI-Nutzung – inklusive der Stelle, die bei jedem Schritt bricht.
Schritt 1: Geben Sie jedem Agenten seinen eigenen Arbeitsbaum. Betreiben Sie nicht zwei Agenten im selben Ordner. Nutzen Sie einen git worktree pro Aufgabe, damit jedes Checkout physisch getrennt ist:
git worktree add ../repo-auth feature/auth
git worktree add ../repo-tests chore/tests
git worktree add ../repo-bugfix fix/login-redirect
Fehlerfall, wenn Sie das überspringen: Zwei Agenten, die dasselbe Checkout bearbeiten, überschreiben sich mitten im Lauf gegenseitig. Der eine formatiert eine Datei neu, mit der der andere gerade zur Hälfte durch ist, und beide hinterlassen den Baum in einem Zustand, den keiner von beiden wollte. Worktrees geben jedem Agenten einen sauberen Branch und ein sauberes Verzeichnis. Mehr dazu in git worktrees für KI-Coding-Agenten.
Schritt 2: Starten Sie eine Gemini CLI pro Worktree. Öffnen Sie in jedem Verzeichnis ein Terminal und starten Sie eine Sitzung:
cd ../repo-auth && gemini
Für unbeaufsichtigte Runs nutzen Sie den nicht-interaktiven Modus, damit der Agent einen einzelnen Prompt entgegennimmt und sich beendet:
cd ../repo-tests && gemini -p "Add unit tests for the session module. Run the suite before finishing."
Fehlerfall: Eine interaktive Sitzung bleibt beim ersten Berechtigungs-Prompt stehen und wartet. Sie kommen zwanzig Minuten später zurück und finden einen Agenten vor, der nichts getan hat, weil er ein Ja gebraucht hätte. Legen Sie vorab fest, welche Runs interaktiv und welche headless laufen, und geben Sie den headless-Runs einen Prompt, der einen eigenen Verifikationsschritt enthält.
Schritt 3: Isolieren Sie den Kontext pro Aufgabe. Jeder Worktree kann seine eigene GEMINI.md mit den Regeln für diese Aufgabe mitbringen: was angefasst werden darf, was unberührt bleibt, wie Tests ausgeführt werden.
Fehlerfall: Eine gemeinsame Kontextdatei für alle Agenten sorgt dafür, dass eine Anweisung, die für die Auth-Aufgabe gedacht war, in die Test-Aufgabe durchsickert. Grenzen Sie den Kontext auf den Baum ein, zu dem er gehört.
Schritt 4: Behalten Sie das Kontingent im Blick. Jede laufende Instanz zehrt an denselben Konto-Limits. Vier Agenten, die sich durch ein großes Refactoring arbeiten, stoßen schneller an Rate Limits als einer – und ein gedrosselter Agent scheitert still in einem Tab, in das Sie gerade nicht schauen.
Fehlerfall: Ein Run hängt wegen eines Kontingentfehlers fest, und Sie merken es erst, wenn Sie in diesen Tab schauen. Es gibt keine gemeinsame Ansicht, die Ihnen sagt, dass ein Agent gestoppt wurde. Wenn Sie aufwendigere Aufgaben dem passenden Modell zuordnen, behandelt welches Modell für welche Coding-Aufgabe genau diese Abwägung.
Bei drei oder vier Aufgaben funktioniert das. Echte Branches, echte Isolation, echte Parallelität, kein zusätzliches Tooling.
Wo das Do-it-yourself-Setup nicht mehr skaliert
Das manuelle Setup scheitert nicht an der Ausführung, sondern an allem drumherum. Sehen Sie, was passiert, wenn die Zahl der Aufgaben steigt.
Sie verlieren die Landkarte. Vier Terminals können Sie im Kopf behalten. Bei acht über zwei Repositories hinweg geht das nicht mehr. Welcher Tab ist der Auth-Agent? Ist der Testlauf fertig geworden oder an einem Kontingentfehler gescheitert? Das Monitoring parallel laufender Coding-Agenten ist eine Aufgabe, für die das Terminal nie gebaut wurde.
Die Ergebnisse verstreuen sich. Jeder Agent hinterlässt seine Arbeit als Diff auf einem Branch und eine Wand aus Scrollback in einem Tab, das Sie später schließen. Es gibt keine gemeinsame Aufzeichnung darüber, was jeder Run geändert hat, warum, oder ob er seine eigenen Tests bestanden hat. Wenn eine Kollegin fragt, was der Login-Fix bewirkt hat, lebt die Antwort in einem Terminal, das es nicht mehr gibt.
Das Review hat kein Zuhause. Parallele Agenten erzeugen parallele Diffs, und jeder einzelne braucht noch einen Menschen, der ihn annimmt. Vier Branches ohne Zusammenfassung, ohne Verifikationsergebnisse und ohne Kontext zu lesen, dauert länger, als die Agenten schnell waren. Die Geschwindigkeit, die Sie bei der Ausführung gewonnen haben, geben Sie beim Review wieder her.
Hier ist das ehrliche Entscheidungspaar. Wenn Sie ab und zu drei oder vier Gemini-Aufgaben laufen lassen, bleiben Sie beim oben beschriebenen Worktree-Setup; es ist einfach und funktioniert, und ein Task-Board wäre nur unnötiger Overhead. Greifen Sie dann zu einem, wenn parallele Runs zur Normalität werden: mehrere Agenten, mehr als ein Repository, mehr als eine Person, die den Fortschritt sehen muss, und ein Review, das nachvollziehbar sein muss statt aus dem Gedächtnis zu kommen. Ein Vergleich der Tools zur Verwaltung paralleler Agenten lohnt sich an diesem Punkt.
Was ein Task-Board bringt
Ein Task-Board ändert die Arbeitseinheit von „einem Terminal-Tab“ zu „einer Aufgabe“. Genau dieser Wechsel fehlt dem Do-it-yourself-Setup.
Mit Sharkly weisen Sie eine Aufgabe einem Agenten zu, der von der Gemini CLI angetrieben wird. Der Agent übernimmt die Aufgabe, arbeitet in einem isolierten Worktree, und Ausführung, Blocker, Ergebnisse und Folge-Diskussionen landen in der Zeitleiste der Aufgabe, statt in privaten Terminals zu verschwinden. Lassen Sie mehrere gleichzeitig laufen, ist jeder eine Zeile, die Sie sehen, statt ein Tab, das Sie suchen müssen. Die Gemini CLI schreibt weiterhin den Code; Sharkly verwaltet die Zuweisung, die verbundenen Computer, den Kontext und das Review über alle Runs hinweg.
Die Arbeitsteilung bleibt klar. Agenten recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab. Automatisierung endet dort, wo das Urteilsvermögen des Teams gefragt ist, und jeder Run kommt mit einer Änderungszusammenfassung und seinen eigenen Verifikationsergebnissen zurück, sodass das Annehmen oder Ablehnen eines Diffs ein Blick ist statt eine archäologische Grabung. Kontext, Fortschritt, Blocker, Ergebnisse und menschliches Review bleiben vom Request bis zum Release sichtbar.
Sie behalten, was Sie schon haben. Sharkly verlangt nicht, dass Sie die Gemini CLI aufgeben oder sich auf eine Runtime festlegen. Weil es anbieterneutral ist, laufen auf demselben Task-Board Claude-Code- und Codex-Agenten neben Ihren Gemini-Agenten – so übersteht Ihr Workflow auch den nächsten besten Agenten, der auf den Markt kommt. Genau darum geht es bei dieser Neutralität: Sie verwalten Ihre Agenten an einem Ort, statt bei jedem neuen Release das Ökosystem zu wechseln.
Die Checkliste, die Sie heute durchgehen können
Gehen Sie das durch, bevor Sie Ihre nächste Runde paralleler Gemini-Aufgaben starten:
- [ ] Ein git worktree pro Aufgabe; niemals zwei Agenten in einem Checkout.
- [ ] Eine auf jede Aufgabe zugeschnittene
GEMINI.md, nicht eine gemeinsame Datei für alle. - [ ] Headless-Runs nutzen
gemini -pmit einem integrierten Verifikationsschritt, damit sie nicht an einem Prompt hängen bleiben. - [ ] Eine bekannte Obergrenze für gleichzeitige Instanzen, damit das gemeinsame Kontingent keinen Run drosselt, den Sie nicht sehen können.
- [ ] Ein einziger Ort, der die Frage beantwortet „welcher Agent arbeitet woran, und was ist fertig“, ohne dass Sie jedes Tab öffnen müssen.
- [ ] Jeder abgeschlossene Run hinterlässt eine Änderungszusammenfassung und Testergebnisse, die ein Mensch prüfen kann – nicht nur einen Diff auf einem Branch.
Die ersten vier Punkte können Sie heute Abend mit Worktrees und Terminals umsetzen. Bei den letzten beiden stößt ein manuelles Setup an seine Grenzen. Wenn Sie bereits mehrere Gemini-CLI-Agenten gleichzeitig laufen lassen, gibt Ihnen Sharkly einen Ort, an dem Sie ihre Aufgaben zuweisen, ihren Fortschritt verfolgen und ihre Ergebnisse prüfen können. Sie können die Koordinationsschicht selbst bauen – oder Ihre bestehenden Coding-Agenten über Sharkly laufen lassen und direkt zum Teil springen, der skaliert.
