CCG: Claude Code als Dirigent für Codex, Gemini und Kimi
多模型协作工作流引擎 — /ccg:go 一个命令，AI 自动分析意图、选择策略、编排 Codex + Gemini + Claude 协作执行
Auf einen Blick
- Was ist das?
- CCG ist eine Workflow-Engine, die Claude Code zur Orchestrierung mehrerer Modelle nutzt. Der Ansatz löst ein echtes Problem, bringt aber eine harte Abhängigkeit von externen CLI-Bridges mit.
- Für wen ist es gedacht?
- CCG passt zu Teams, die Claude Code bereits produktiv nutzen und wiederkehrende Aufgaben wie Review, Planung und parallele Implementierung an mehrere Modelle delegieren wollen, ohne selbst eine Orchestrierungsschicht zu bauen. Wer nur gelegentlich mit Claude Code arbeitet oder dessen Kontextfenster und Hook-Mechanik nicht kennt, sollte zuerst die Dokumentation lesen.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem CCG adressiert
Ein einzelnes Sprachmodell bearbeitet einen Auftrag wie "JWT-Authentifizierung ergänzen" in einem Durchlauf: Analyse, Plan, Implementierung, Review. Das ist bequem, aber die Fehler eines Modells bleiben die Fehler desselben Modells. CCG setzt an dieser Stelle an und macht Claude Code zum Leitorchestrator, der spezialisierte Arbeit an Codex, Grok, Kimi Code und Antigravity abgibt. Die Zielgruppe sind Entwickler, die Claude Code schon als Agenten einsetzen und die Grenzen eines einzelnen Modells bei Planung und Review kennen. Das Projekt ist ausdrücklich kein eigenständiger Editor und kein Ersatz für Claude Code, sondern eine Ergänzung, die als Kommando in eine bestehende Installation eingreift.
Der Ablauf hinter /ccg:go
Die README beschreibt den Ablauf an einem konkreten Beispiel. Nach dem Aufruf liest die Engine Projektkontext (git status, Tech-Stack, Dateistruktur), klassifiziert die Aufgabe nach Typ, Komplexität und Risiko, wählt eine Strategie und legt eine Aufgabendatei unter .ccg/tasks/add-jwt-auth/task.json an. Danach startet eine parallele Analyse mit Codex und Gemini, es entsteht ein Plan, und an dieser Stelle folgt ein HARD STOP, bis der Nutzer zustimmt. Erst dann werden Agent Teams für die Umsetzung gestartet. Bemerkenswert ist der Hook Engine genannte Teil: Er injiziert den Zustand in jeder Runde, damit Claude den Kontext auch nach einer Kompaktierung nicht verliert. Das ist der eigentlich interessante Mechanismus, weil lange Agentenläufe sonst genau an dieser Stelle auseinanderfallen.
Die Go-Bridge als harte Abhängigkeit
Zwischen Claude Code und den externen Modellen sitzt der codeagent-wrapper, ein kompiliertes Go-Binary. Laut README ist er die Brücke für parallele Analyse und Review. Das bedeutet: CCG ist nicht allein eine Sammlung von Prompt-Dateien, sondern enthält ausführbaren Code, der zur Plattform passen muss. Die Release namens preset liefert vorgebaute Binärdateien für diesen Wrapper. Wer auf einer exotischen Architektur arbeitet oder keine Binärdateien aus Releases ausführen darf, muss den Wrapper selbst bauen. Das ist eine reale Einstiegshürde, die in der README nicht als solche benannt wird.
Installation und Konfiguration
Der Einstieg läuft über npm und setzt Node.js in Version 20 oder höher voraus. Der Befehl lautet npx ccg-workflow und startet laut README einen Installationsdialog, der in etwa 60 Sekunden durchläuft. Im ersten Schritt wird ein API-Anbieter gewählt; die README nennt APIMart als Beispiel, das einen Anthropic-kompatiblen Endpunkt anbietet und damit als Provider für Claude Code selbst dienen kann. Für die DeepSeek-Harness-Variante gibt es eigene Unterbefehle: npx ccg-workflow dsh install richtet sie für alle gefundenen Profile ein, mit --profile <name> nur für ein einzelnes, und npx ccg-workflow dsh list zeigt, welche Profile sie bereits enthalten. Diese dsh-Variante liegt im Verzeichnis dsh-ccg und wird mit demselben Paket ausgeliefert, ohne zweite Installation. Wer die Aufgabenstruktur nachvollziehen will, findet sie nach dem ersten Lauf unter .ccg/tasks/.
Wo CCG an Grenzen stößt
Der HARD STOP vor der Implementierung ist bewusst gesetzt, aber er passt nicht in jede Umgebung. In einer Pipeline, die ohne menschliche Freigabe durchlaufen soll, blockiert genau dieser Schritt. Umgekehrt ist er die einzige im Material sichtbare Bremse, bevor Agent Teams Code schreiben. Ein zweiter Punkt: Die Qualität der Ausgabe hängt an den externen Providern. Fehlt ein Schlüssel für Codex oder Gemini, kann die parallele Analyse nicht in der beschriebenen Form stattfinden; die README schweigt dazu, wie CCG auf einen fehlenden Provider reagiert. Und wer bereits eine eigene Review-Kette mit anderen Modellen betreibt, gewinnt durch CCG wenig, weil die Orchestrierung dann doppelt existiert.
Was die dsh-Variante anders macht
Die DeepSeek-Harness-Variante ist kein bloßer Port. Sie bringt zwei Fähigkeiten, die auf der Claude-Code-Seite laut README nicht so sauber möglich sind. Erstens Model Panels: Ein Rolle bekommt mehrere Modelle, die dieselbe Aufgabe unabhängig beantworten und deren Antworten nebeneinander im Gespräch erscheinen. Es wird nicht abgestimmt und nicht gemittelt, die Abweichung ist das Ergebnis. Zweitens Live-Teammates: ccg_team heuert eine Rolle an, die über mehrere Runden bestehen bleibt, eigene Dateien besitzt und selbstständig Bericht erstattet. Eine kollidierende Anheuerung wird abgelehnt, nicht nur verwarnt, und jede Anheuerung muss vorher bestätigt werden. Der Unterschied zur Claude-Code-Seite liegt im Transport: hier läuft jeder Schritt als Provider-API-Aufruf, ohne externe CLI und ohne Kaltstart.
Alternative: direkt mit Claude Code arbeiten
Die naheliegende Alternative ist, Claude Code ohne CCG zu nutzen und Reviews manuell an ein zweites Modell zu geben. Der Unterschied liegt nicht in der Modellauswahl, sondern in der Zustandsführung. Ohne Hook Engine muss der Kontext nach jeder Kompaktierung neu aufgebaut werden, und die Aufgabenbeschreibung lebt in der Konversation statt in einer Datei wie .ccg/tasks/<name>/task.json. CCG macht den Zustand persistent und die Strategiewahl explizit. Wer nur kurze Aufträge ausführt, für die eine Kompaktierung nie eintritt, gewinnt durch diesen Mechanismus nichts und zahlt mit einer zusätzlichen Binärdatei im Werkzeugkasten.
Wartung, Lizenz und Aufwand
CCG steht unter der MIT-Lizenz. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber, dass Lizenz- und Urheberrechtshinweis erhalten bleiben. Wer den codeagent-wrapper selbst baut und weitergibt, sollte diesen Hinweis mitführen. Rechtlich verbindlich ist das nicht; im Zweifel gehört die Lizenzfrage zu einer Rechtsabteilung. Der Wartungsaufwand liegt weniger im Projekt selbst als in der Umgebung: Node.js muss mindestens in Version 20 vorliegen, der Go-Wrapper muss zur Plattform passen, und Änderungen an den externen Modell-APIs können die Bridge treffen. Das Repository ist nicht archiviert, der letzte Push stammt vom 3. September 2026, und der jüngste Release liefert vorgebaute Binärdateien. Ein Upgrade-Pfad oder eine Versionskompatibilitätsmatrix ist im vorliegenden Material nicht beschrieben.
Redaktionelles Fazit
CCG passt zu Teams, die Claude Code bereits produktiv nutzen und wiederkehrende Aufgaben wie Review, Planung und parallele Implementierung an mehrere Modelle delegieren wollen, ohne selbst eine Orchestrierungsschicht zu bauen. Wer nur gelegentlich mit Claude Code arbeitet oder dessen Kontextfenster und Hook-Mechanik nicht kennt, sollte zuerst die Dokumentation lesen. Vor dem Einsatz ist zu prüfen, ob der Go-Binary-Wrapper codeagent-wrapper auf der Zielplattform startet, welche Provider-Schlüssel tatsächlich hinterlegt sind und ob die HARD-STOP-Freigabe im eigenen Ablauf gewünscht ist.
Community-Notizen