Wie Sie verhindern, dass sich mehrere Coding-Agenten gegenseitig überschreiben
Einen AI-Coding-Agenten auf einem Repository laufen zu lassen, fühlt sich wie Pair Programming an. Drei oder fünf Agenten auf demselben Repository laufen zu lassen, kann sich wie eine Merge-Konflikt-Fabrik anfühlen, wenn sie alle denselben Checkout teilen. Ein Agent wechselt die Branches, ein anderer bearbeitet dieselbe Datei, ein dritter führt einen Bereinigungsbefehl aus, und plötzlich weiß niemand mehr, welcher Diff zu welcher Aufgabe gehört.
Die Lösung ist kein größerer Prompt. Die Lösung ist ein Workflow. Ich behandle Agenten wie schnelle Junior-Entwickler mit Shell-Zugriff: nützlich, aber sie brauchen Grenzen.
Die Kurzfassung
- Verwenden Sie einen Git-Worktree pro Agent.
- Verwenden Sie einen Branch pro Aufgabe.
- Geben Sie jedem Agenten eine klare Zuständigkeitsgrenze für Dateien oder Module.
- Legen Sie gemeinsame Repository-Regeln in
AGENTS.md,CLAUDE.mdoder beides mit einem Symlink ab. - Blockieren Sie destruktive Git-Befehle, es sei denn, ein Mensch genehmigt sie.
- Führen Sie Merges über Pull Requests mit CI und Branch-Schutz durch.
Das ist genug Struktur für die meisten parallelen Agentenarbeiten.
Warum ein gemeinsamer Checkout zusammenbricht
Ein normaler Git-Checkout hat einen Arbeitsbaum, einen Index und einen aktuellen Branch. Das ist in Ordnung für einen Entwickler oder einen Agenten. Es wird unübersichtlich, wenn mehrere Agenten gleichzeitig agieren.
Wenn Agent A mitten in einem Auth-Refactoring steckt und Agent B git checkout main ausführt, ändert sich die Arbeitsumgebung von Agent A unter seinen Füßen. Wenn Agent C git reset --hard ausführt, können ungespeicherte Arbeiten verschwinden. Selbst harmlose Befehle wie git stash pop können nicht zusammenhängende Änderungen vermischen.
Sie können den Agenten sagen, dass sie diese Dinge nicht tun sollen, und das sollten Sie auch. Aber Dateisystem-Isolation ist stärker als Vertrauen.
Git-Worktrees für Isolation verwenden
Git-Worktrees ermöglichen es einem Repository, mehrere Arbeitsverzeichnisse zu haben, die mit derselben Historie verbunden sind. Jedes Verzeichnis kann auf seinem eigenen Branch liegen, während es dieselbe Objektdatenbank teilt. Sie vermeiden die Kosten und Verwirrung, das Repository fünfmal zu klonen, aber jeder Agent erhält seine eigenen Dateien.
git fetch origin
git worktree add ../site-auth -b agent/auth-refactor origin/main
git worktree add ../site-billing -b agent/billing-fix origin/main
git worktree add ../site-tests -b agent/test-coverage origin/main
git worktree listStarten Sie dann einen Agenten in jedem Verzeichnis. Agent A arbeitet in ../site-auth. Agent B arbeitet in ../site-billing. Agent C arbeitet in ../site-tests. Sie können Tests ausführen, Dateien bearbeiten und Commits erstellen, ohne die Checkouts der anderen zu ändern.
Dies ist auch das Muster, das Claude Code für parallele Sitzungen dokumentiert: separate Worktrees, separate Branches und isolierte Bearbeitungen. Die Hilfedokumente von Anthropic gehen weiter und beschreiben Worktree-gestützte parallele Sitzungen als gängigen Power-User-Workflow für die gleichzeitige Ausführung mehrerer Claude-Sitzungen.
Jedem Agenten eine eigene Oberfläche geben
Worktrees lösen Kollisionen auf Dateiebene. Sie lösen keine Konflikte auf Produktebene. Zwei Agenten können immer noch inkompatible Entscheidungen treffen, wenn die Aufgabe vage ist.
Bevor ich Agenten parallel starte, teile ich die Arbeit nach Zuständigkeiten auf. Nicht nur nach Dateinamen, sondern nach Verantwortung.
Sie sind verantwortlich für src/auth/** und tests/auth/**.
Bearbeiten Sie keine Dateien außerhalb dieses Umfangs.
Ändern Sie keine öffentlichen API-Formen, ohne vorher zu stoppen.
Führen Sie die Auth-Tests aus, bevor Sie "fertig" melden.
Öffnen Sie einen PR mit einer fokussierten Zusammenfassung.Dieser Prompt ist langweilig, genau deshalb funktioniert er. Agenten brauchen langweilige Grenzen mehr als clevere Prosa.
Die besten Aufteilungen erfolgen entlang natürlicher Modulgrenzen: Authentifizierung, Abrechnung, Suche, Dokumentation, UI-Komponenten, Migrationen, Tests. Die schlechteste Aufteilung ist, zwei Agenten überlappende Zuständigkeiten für denselben Dienst zu geben und zu hoffen, dass Git es später herausfindet.
AGENTS.md und CLAUDE.md als gemeinsame Regeln verwenden
Repository-Anweisungen sollten im Repository leben, nicht nur in einem Chatfenster. CLAUDE.md ist die Konvention, die Claude Code liest. AGENTS.md ist eine allgemeinere Konvention für Coding-Agenten. Wenn Sie beide Tools verwenden, halten Sie eine einzige Quelle der Wahrheit und verlinken Sie den anderen Namen darauf.
ln -s CLAUDE.md AGENTS.mdDiese Datei sollte die Build-Befehle des Repos, Testbefehle, Deployment-Hinweise, Stilregeln und alle harten Einschränkungen enthalten. Zum Beispiel: keine generierten Dateien bearbeiten, keine Migrationen ohne Genehmigung anfassen, npm run lint vor der Übergabe verwenden oder Blog-Codeblöcke in einer HTML-Zeile mit <br/>-Tags halten.
Der Punkt ist einfach: Jeder Agent sollte mit demselben lokalen Kontext beginnen.
Gefährliche Git-Befehle explizit machen
Ich lasse Agenten nicht mit destruktivem Git improvisieren. Diese Befehle sind in einem menschlich gesteuerten Terminal nützlich, aber im autonomen Arbeiten riskant:
git reset --hard
git checkout .
git clean -fd
git push --force
git stash popMeine Standardregel lautet: frei lesen, eng schreiben und vor destruktivem Git fragen. Agenten können git status, git diff, git log und normale Commits ausführen. Sie sollten keine Arbeit verwerfen, Force Pushs durchführen oder einen anderen Branch verschieben, es sei denn, die Aufgabe erfordert dies ausdrücklich.
Pull Requests als Übergabepunkt verwenden
Führen Sie Agentenarbeiten nicht zusammen, indem Sie Dateien zwischen Ordnern kopieren. Lassen Sie jeden Agenten einen Branch und einen Pull Request erstellen.
git status
git diff
npm test
git add src/auth tests/auth
git commit -m auth-refactor
git push origin agent/auth-refactor
gh pr createAuf GitHub können Branch-Schutzregeln Pull-Request-Reviews, Statusprüfungen, lineare Historie und Merge-Queues erfordern. Diese Kontrollen sind wichtiger, wenn Agenten schnell Code generieren können. Geschwindigkeit ist nur nützlich, wenn main vertrauenswürdig bleibt.
Ich mag kleine Agenten-PRs. Ein fokussierter 200-Zeilen-Diff ist überprüfbar. Ein 4.000-Zeilen-gemischter Refactor ist, wo sich Fehler verstecken.
In Abhängigkeitsreihenfolge mergen
Wenn Agent A eine API ändert und Agent B diese API konsumiert, mergen Sie zuerst A. Rebasen Sie dann B auf den aktualisierten Basis-Branch und lassen Sie B seine eigenen Konflikte lösen.
git fetch origin
git rebase origin/main
npm testDas hält das mentale Modell sauber. Der Agent, der die abhängige Arbeit besitzt, ist dafür verantwortlich, sich an die neue Basis anzupassen. Der menschliche Prüfer sieht einen kohärenten PR nach dem anderen.
Der Workflow, den ich morgen verwenden würde
mainaktualisieren.- Einen Worktree und Branch pro Agentenaufgabe erstellen.
- Jeden Agenten innerhalb seines eigenen Worktrees starten.
- Jedem Agenten eine schriftliche Zuständigkeitsgrenze geben.
- Jeden Agenten die relevanten Tests ausführen lassen.
- Jeden Branch pushen und einen PR öffnen.
- In Abhängigkeitsreihenfolge überprüfen, mergen und dann die abgeschlossenen Worktrees entfernen.
git worktree remove ../site-auth
git branch -d agent/auth-refactorMehrere Coding-Agenten können an derselben Codebasis arbeiten. Sie sollten nur nicht im selben Checkout arbeiten. Verwenden Sie Git für die Isolation, Pull Requests für die Überprüfung und Repository-weite Anweisungsdateien für gemeinsame Regeln. Das gibt Ihnen parallele Geschwindigkeit, ohne das Repository in einen Haufen mysteriöser Diffs zu verwandeln.