Warum OpenClaw einen GitHub-Workflow braucht
Agenten im OpenClaw-Stil sind nützlich, weil sie nach dem ersten Prompt weiterarbeiten. Genau diese Stärke macht GitHub-Disziplin unverzichtbar: Ein Agent kann Dutzende Dateien ändern, ein anderer Tests reparieren, und ein dritter den Diff prüfen. Ohne Branch- und Pull-Request-Muster bekommt das Team nur einen Stapel Änderungen ohne klaren Besitzer.
Office Claws ist keine native OpenClaw-Runtime. Wir nutzen dieselbe Betriebserkenntnis für Codex-gestützte Agenten: Eine Aufgabe bekommt einen Runner, einen Branch, einen Log-Stream und einen prüfbaren PR. Wenn du Runtimes vergleichst, beginne mit OpenClaw vs Codex und nutze dann den Workflow unten als sichere GitHub-Schicht um beide Setups.
Das OpenClaw-Branch-Muster
Gib jedem Agenten einen Branch, bevor er Code schreibt. Der Branch-Name sollte Reviewern erklären, was passiert ist, ohne den PR zu öffnen. Wir mögen diese Form:
agent/<ticket-or-topic>-<short-purpose>
fix/<bug>-agent
docs/<topic>-agentEin wenig Namensdisziplin verhindert zwei häufige Fehler: Agenten pushen auf main, und Menschen verlieren den Überblick, welcher Runner welchen Diff besitzt. In Office Claws ordnet die Desktop-Ansicht eine Aufgabe ihrem Runner und Log-Stream zu; der GitHub-Branch ist der passende Source-Control-Griff.
| Schritt | Besitzer | Gate | Vermeideter Fehler |
|---|---|---|---|
| Branch erstellen | Mensch oder Dispatcher | Branch-Name enthält Aufgabe | Agent ändert main |
| Agent starten | Isolierter Runner | Ein Worktree pro Aufgabe | Dateikollisionen zwischen Agenten |
| Draft-PR pushen | Agent | CI startet sofort | Versteckte nur-lokale Änderungen |
| Diff prüfen | Mensch oder Reviewer-Agent | Erforderliche Freigabe | Stille Architekturdrift |
| Mergen | Mensch | Grüne CI | Kaputter Produktions-Branch |
Die nützliche Regel ist einfach: Ein Agent darf Code vorschlagen, aber er trifft nicht die endgültige Integrationsentscheidung.
CI-Gates vor Agent-Review
Führe die langweiligen Checks aus, bevor du einen weiteren Agenten um Review bittest. Ein Reviewer-Agent ist viel besser bei Architektur, Grenzfällen und fehlenden Tests, wenn er keinen Kontext für einen TypeScript-Formatierungsfehler verbrennt.
Ein minimales GitHub-Actions-Gate für ein OpenClaw-nahes Web-Repo sieht so aus:
name: agent-pr
on:
pull_request:
branches: [main]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm run lint --if-present
- run: npm test --if-present
- run: npm run buildFür Office Claws-Nutzer zahlt sich hier der Desktop-Manager aus: Lass den Coding-Agenten auf einem VPS laufen, halte Provider-Schlüssel lokal, und mache GitHub zum neutralen Ort, an dem Menschen den finalen Diff prüfen. Siehe Office Claws für OpenClaw-Nutzer für die Management-Schicht und OpenClaw auf VPS für die Runner-Architektur.
Sichere Übergaben zwischen Agenten
Die Übergabe sollte ausdrücklich sein. Sage einem Reviewer-Agenten nicht „prüf das Repo“. Sage ihm, welcher PR, welche Tests bestanden haben, was geändert wurde und welches Risiko geprüft werden soll.
Review PR #42 on branch agent/billing-export.
CI is green. Focus on data-loss risk, auth boundaries, and migration rollback.
Do not push unless you create a separate reviewer branch.
Return: blocking issues, non-blocking suggestions, and merge recommendation.
Halte die Berechtigungen genauso ausdrücklich:
- Coding-Agenten dürfen nur in ihre eigenen Branches pushen.
- Reviewer-Agenten dürfen kommentieren, aber nicht mergen.
- Release-Tokens liegen nicht auf Agent-Runnern.
- Menschen behalten den finalen Merge-Button.
Dieses Modell passt zu OpenClaw, Codex oder jeder künftigen Agent-Runtime. Wichtig ist nicht die Marke des Agenten, sondern die Review-Grenze um den Code, den er schreibt.
Empfohlener Workflow
- Starte jede Aufgabe aus einem frischen Branch und isolierten Worktree.
- Lass den Agenten früh einen Draft-PR pushen, auch bevor die Arbeit fertig ist.
- Verlange CI vor Feedback durch Reviewer-Agenten.
- Halte Provider-Schlüssel und Release-Zugangsdaten außerhalb des Runners.
- Merge erst, nachdem ein Mensch PR-Zusammenfassung, Testausgabe und riskante Dateien gelesen hat.
Wenn du von spontanen OpenClaw-Sessions zu etwas wechselst, dem ein Team vertrauen kann, ist dieser GitHub-Workflow die erste Gewohnheit. Office Claws gibt Teams im OpenClaw-Stil Desktop-Management, VPS-Runner-Isolation, Codex-gestützte Ausführung und sicherere lokale Schlüsselverwaltung, damit diese Gewohnheiten leichter bleiben.
Weiterführende Lektüre
- OpenClaw vs Codex — wo welche Runtime passt.
- OpenClaw Desktop Manager — die Office Claws-Management-Schicht für Arbeit im OpenClaw-Stil.
- OpenClaw Security Best Practices — Schlüsselverwaltung, Runner-Isolation und Audit-Logs.