Loops und autonome Runs in Gemini CLI

# Loops und autonome Runs in Gemini CLI

Manche Coding-Arbeit besteht nur darin, denselben Schritt zu wiederholen, bis eine Bedingung erfüllt ist: Code korrigieren, Tests laufen lassen, Fehler lesen, wieder korrigieren. Gemini CLI kann diesen ganzen Zyklus in einem agentischen Loop für Sie übernehmen, Dateien bearbeiten und Befehle ausführen, bis die Aufgabe wirklich erledigt ist oder ein Guardrail eingreift. In dieser Lektion geht es darum, diesen Loop bewusst, unbeaufsichtigt und sicher zu betreiben.

Der Loop ist der Standard, kein Trick

Wenn Sie Gemini CLI eine Aufgabe geben, antwortet es nicht einmal und hört dann auf. Es plant, ruft Tools auf (Datei lesen, Datei schreiben, Shell-Befehl ausführen), beobachtet das Ergebnis und entscheidet über die nächste Aktion. Dieser Zyklus aus Beobachten und Handeln wiederholt sich, bis das Modell davon ausgeht, dass das Ziel erreicht ist.

Das ist das ReAct-Muster (reason + act), verdrahtet mit einer echten Shell. Die wichtige Verschiebung für Sie: Sie prompten nicht mehr für Text. Sie übergeben ein Ziel und eine Reihe von Tools und lassen den Agenten dann gegen echtes Feedback von Ihrer Maschine iterieren.

Ein einzelner Request ist richtig, wenn der Output die Antwort ist: „erkläre diese Funktion“, „schreibe eine Regex“. Ein Loop ist richtig, wenn Erfolg durch eine externe Prüfung definiert ist, die der Agent nicht fälschen kann:

• Iterieren, bis die Test-Suite durchläuft.
• Dasselbe Refactoring über 40 Dateien hinweg im Batch anwenden.
• Lint- und Typfehler beheben, bis der Build clean ist.
• Eine Dependency hochziehen und dann jedem daraus entstehenden Bruch nachgehen.

Der Unterschied liegt darin, ob es eine überprüfbare Stop-Bedingung gibt. Wenn ja, schlägt ein Loop einen Chat, weil der Agent seine eigene Arbeit an der Realität bewertet.

Non-interactive Runs

Der interaktive Modus ist die REPL, die Sie schon kennen. Für Automatisierung wollen Sie den Non-interactive-Modus: ein Befehl, kein Hin und Her, Ende wenn fertig. Verwenden Sie das Flag -p (prompt).

gemini -p "Run the test suite with 'npm test'. If anything fails, \
read the output, fix the code, and re-run until all tests pass. \
Do not modify test files." --model gemini-2.5-flash

Der Agent besitzt nun den gesamten Loop. ErErThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → führt npm test aus, parst Fehler, bearbeitet Quellcode und startet neu, so lange bis alles grün ist oder ein Guardrail auslöst.

Zwei Flags sind hier am wichtigsten:

• --model wählt die Stufe. Greifen Sie zu Flash bei engen, klar abgegrenzten Loops (schnelle, günstige Iteration). Wechseln Sie zu Pro, wenn das Reasoning wirklich schwer ist: verworrene Fehler, Architekturentscheidungen, unklare Specs.
• --yolo genehmigt Tool-Calls automatisch, sodass der Loop nie zur Bestätigung anhält. Mächtig und gefährlich. Dazu unten mehr.

Weil es ein einfacher Befehl ist, lässt sich der Non-interactive-Modus direkt in CI, cron oder einen Git-Hook einsetzen. Das bedeutet „autonom“ in der Praxis: kein Mensch in der REPL.

Scheduling und unbeaufsichtigte Trigger

Gemini CLI hat keinen eingebauten Scheduler. Sie verdrahten es mit den Tools, die Sie ohnehin betreiben. Das ist ein Feature, keine Lücke: Die CLI bleibt ein kombinierbarer Unix-Bürger.

Ein nächtlicher Dependency-und-Test-Durchlauf per cron:

# 2:00 AM daily: attempt upgrades, keep tests green, open a PR
0 2 * * * cd /srv/app && gemini -p "$(cat prompts/nightly-deps.txt)" \
  --yolo --model gemini-2.5-flash >> logs/nightly.log 2>&1

Oder ein GitHub-Actions-Job, der zeitgesteuert oder über issue-Labels ausgelöst wird und Gemini CLI triagieren und einen Fix-Branch entwerfen lässt. Das Muster ist identisch: Ein externer Trigger startet einen Non-interactive Run, und der Run übernimmt das Looping.

Die offizielle Flag-Referenz und Konfiguration finden Sie in der Gemini CLI Dokumentation.

Durchgerechnetes Beispiel: iterieren, bis der Build durchläuft

Hier ist ein sauberer, eingegrenzter autonomer Run, den Sie anpassen kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen. ErErThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → begrenzt die Arbeit, verbietet riskante Schritte und produziert ein überprüfbares Ergebnis statt still nach main zu pushen.

#!/usr/bin/env bash
set -euo pipefail

BRANCH="auto/fix-build-$(date +%Y%m%d-%H%M)"
git switch -c "$BRANCH"

gemini --yolo --model gemini-2.5-flash -p '
Goal: make the build and tests pass.
Steps:
  1. Run "npm run build" and "npm test".
  2. If either fails, read the error, make the smallest fix, re-run.
  3. Repeat until both succeed.
Rules:
  - Never edit files under /tests or /node_modules.
  - Never touch package.json versions.
  - If unresolved after 8 attempts, stop and summarize what remains.
'

# Human review gate: agent branched, we decide the merge.
git push -u origin "$BRANCH"
echo "Review the PR before merging: $BRANCH"

Lesen Sie nach, was das sicher statt leichtsinnig macht:

• Die Stop-Bedingung ist extern und objektiv. „Both succeed“ wird über die Exit-Codes von build und test entschieden, nicht über die Meinung des Modells.
• Die Versuchsgrenze steht im Prompt. „8 attempts, then stop and summarize“ verhindert eine Endlosspirale bei einem nicht behebbaren Fehler.
• Gesperrte Pfade sind explizit. Der Agent kann Tests nicht dadurch grün machen, dass ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → sie löscht, ein klassischer Failure Mode.
• Das Ergebnis landet auf einem Branch. Kein autonomer Run berührt Ihren main-Branch. Ein Mensch öffnet und merged den PR.

Der letzte Punkt ist die ganze Philosophie. Autonomie gilt für die Arbeit. Der Merge bleibt Ihrer.

Stop-Bedingungen: wie Loops tatsächlich enden

Ein agentischer Loop endet aus einem von vier Gründen. Planen Sie für alle vier.

1. Erfolg. Die überprüfbare Bedingung ist erfüllt (Tests grün, Dateien verarbeitet). Das ist der Happy Path.

2. Versuchs- oder Turn-Limit. Sie haben gesagt, nach N Versuchen soll Schluss sein. Setzen Sie das immer. Loops ohne Deckel sind der Grund, warum man um 3 Uhr morgens einen Runaway entdeckt.

3. Kosten- oder Token-Grenze. Der Run stößt an ein Budget, das Sie gesetzt haben (nächster Abschnitt).

4. Harter Fehler, von dem der Agent sich nicht erholen kann. Fehlende Credentials, ein nicht existierender Befehl, eine Berechtigungsmauer.

Der gefährliche Fall ist keiner davon: Der Agent glaubt, ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → macht Fortschritt, dreht aber im Kreis mit demselben kaputten Fix. Deshalb schlägt „smallest fix, re-run“ plus Versuchsgrenze ein offenes „keep going“. Begrenzen Sie jede Dimension: Versuche, Zeit und Geld.

Kostengrenzen und Budgetkontrolle

Ein unbeaufsichtigter Loop, der in jedem Turn ein Modell aufruft, kann still und leise Kosten auftürmen. Drei Verteidigungsebenen, von der günstigsten zur härtesten:

Wählen Sie das Modell passend zur Aufgabe. Flash bewältigt die meisten Iterate-until-green-Loops zu einem Bruchteil der Pro-Kosten. Schicken Sie keinen Linter-Fix-Loop an Pro.

Begrenzen Sie den Loop im Prompt. Weniger Versuche bedeuten weniger Turns, also weniger TokenTokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.Vollständige Definition ansehen →. Ein enges, konkretes Ziel konvergiert schneller als ein vages.

Erzwingen Sie die Obergrenze auf Account-Ebene. Wenn Sie über die bezahlte Gemini API oder Vertex AI arbeiten, setzen Sie Budgets und Alerts in der Plattform, nicht nur in Ihrem Prompt. In Google Cloud benachrichtigen Sie Budgets und Alerts auf Vertex AI (oder stoppen die Ausgaben), unabhängig davon, was der Agent entscheidet. Das ist Ihr echter Backstop: Limits auf Prompt-Ebene kann ein verwirrter Agent wegargumentieren, eine Billing-Grenze nicht.

Eine praktische Regel: Führen Sie --yolo nie auf einem bezahlten Key aus, ohne vorher einen harten Budget-Alert konfiguriert zu haben. Die Prompt-Grenze schützt Sie vor Logikfehlern. Die Billing-Grenze schützt Sie vor allem anderen.

Review Gates für unbeaufsichtigte Arbeit

Je beängstigender die Befugnisse eines autonomen Runs, desto mehr braucht ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → ein Gate zwischen „Agent fertig“ und „Änderung ist live“. Ein Review Gate ist jeder Checkpoint, an dem ein Mensch oder eine automatisierte Prüfung zustimmen muss, bevor die Arbeit weiterläuft.

Staffeln Sie diese vom geringsten zum größten Vertrauen:

1. Approval-Prompts (interaktiv)

Der Standard. Die CLI hält vor jedem Write oder Shell-Befehl an und fragt. Gut für Exploration, nutzlos für unbeaufsichtigte Runs, weil niemand da ist, um Ja zu sagen.

2. Sandboxing (das Container-Gate)

Bevor Sie zu --yolo greifen, begrenzen Sie den Blast Radius. Führen Sie den Agenten mit aktiviertem Sandboxing aus, sodass Tool-Calls in einem isolierten Container laufen und nicht direkt auf Ihrer Maschine. Selbst ein verwirrter Loop kommt nicht an Dateien oder Netzwerke außerhalb der Box. Aktivieren Sie es und begrenzen Sie das Arbeitsverzeichnis:

gemini --sandbox --yolo -p "$(cat prompts/refactor.txt)"

Kombinieren Sie Sandboxing mit einem Scratch-Git-Checkout, und der Agent kann buchstäblich nichts beschädigen, was Ihnen wichtig ist.

3. Das Branch-und-PR-Gate

Wie im durchgerechneten Beispiel: Autonome Runs schreiben auf einen Feature-Branch und öffnen einen Pull Request. Ihre bestehende CI (Tests, Security Scans) läuft auf dem PR, und ein Mensch genehmigt den Merge. Das ist der Sweet Spot für die meisten Teams: volle Autonomie innerhalb des Loops, volle Kontrolle an der Grenze.

4. CI als objektiver Richter

Vertrauen Sie nicht dem „Ich bin fertig“ des Agenten. Lassen Sie Ihre PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen → entscheiden. Die Aufgabe des Agenten ist, einen Branch zu produzieren, der die CI besteht. Fällt die CI durch, wird der PR nicht gemerged, Punkt. Damit wird Ihre bestehende Test- und Lint-Infrastruktur zur Schiedsinstanz für autonome Arbeit, und genau darin ist sie gut.

Batch-Loops über viele Dateien

Der andere klassische Loop ist nicht „bis eine Bedingung“, sondern „für jedes Element“. Gleiche Mechanik, andere Form.

gemini --yolo --model gemini-2.5-flash -p '
For every *.py file under /src:
  - Add type hints to all public functions.
  - Run "mypy" on the file after editing.
  - If mypy errors, fix and re-check that file before moving on.
Skip files that already pass mypy cleanly. Report a table of files
changed and files skipped when finished.
'

Beachten Sie die Verifikation pro Element (mypy nach jeder Bearbeitung). Das hält den Batch ehrlich: Der Agent belegt jede Datei, bevor ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → weitergeht, statt alle 40 zu bearbeiten und zu hoffen. Wenn ein Batch groß und unabhängig ist, ist das dramatisch besser als 40 separate Chat-Sessions, weil der Agent Kontext und seine eigenen Qualitätsprüfungen mitführt.

Für strukturierte, wiederholbare Pipelines jenseits von Ad-hoc-CLI-Runs (mehrere spezialisierte Agenten, reichere Orchestrierung, Evaluation) steigen Sie auf das Agent Development Kit (ADK) um. Die CLI ist der schnelle Weg; ADK ist der Ort für Produktions-Loops mit sauberem Testing und Deployment.

Wann ein Loop das falsche Werkzeug ist

Autonomie ist nicht kostenlos, greifen Sie also nicht reflexartig danach:

• Es gibt keine objektive Prüfung. Wenn Erfolg „mach den Text besser“ heißt, gibt es nichts, woran der Loop sich messen kann. Das ist ein einzelner Request mit menschlichem Review.
• Jeder Schritt braucht Urteilsvermögen. Die Migration eines Payments-Flows ist kein Loop, den Sie laufen lassen. Es ist eine Reihe von Entscheidungen, die Sie interaktiv mit dem Agenten treffen.
• Die Kosten einer falschen autonomen Aktion sind hoch und keine Sandbox fängt sie vollständig ab. Dann bleibt der Mensch im Turn.

Der Loop verdient sein Geld genau dann, wenn die Prüfung günstig und objektiv ist und die Arbeit stumpf. Das ist der Großteil der Plackerei in einer Codebase, und deshalb ist es relevant.

Key Takeaways

• Nutzen Sie einen Loop, wenn Erfolg extern überprüfbar ist (Tests, Build, Lint, Typprüfungen) und die Arbeit repetitiv. Nutzen Sie einen einzelnen Request, wenn der Output die Antwort ist oder jeder Schritt Urteilsvermögen braucht.
• Unbeaufsichtigt laufen lassen mit `gemini -p`, für Scheduling in cron oder CI verdrahten und die Modellstufe zur Aufgabe passend wählen (Flash für enge Loops, Pro für hartes Reasoning).
• Begrenzen Sie jeden Loop auf drei Achsen: Versuche (im Prompt), Zeit und Geld (Budgets und Alerts auf der Gemini APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen → oder Vertex AI). Eine Prompt-Grenze schützt gegen Logikfehler; eine Billing-Grenze schützt gegen alles andere.
• Führen Sie `--yolo` nie nackt aus. Grenzen Sie es mit --sandbox ein und lassen Sie autonome Arbeit auf einem Branch und PR landen, damit Ihre bestehende CI der objektive Richter ist und ein Mensch den Merge verantwortet.
• Verbieten Sie die Abkürzungen explizit (keine Tests bearbeiten, keine Versionen hochziehen), damit der Agent die Stop-Bedingung nicht auf dem falschen Weg erfüllen kann.