ccg-workflow : orchestrer Codex et Gemini depuis Claude Code
多模型协作工作流引擎 — /ccg:go 一个命令，AI 自动分析意图、选择策略、编排 Codex + Gemini + Claude 协作执行
En bref
- De quoi s’agit-il ?
- Un moteur de workflow qui transforme Claude Code en chef d'orchestre multi-modèles, avec un binaire Go comme pont. La promesse est claire, la mécanique l'est moins, et le README s'arrête au milieu d'une phrase.
- À qui s’adresse-t-il ?
- ccg-workflow s'adresse aux équipes déjà installées dans Claude Code qui veulent déléguer l'analyse et la revue à d'autres modèles sans quitter leur terminal. Passez votre chemin si vous cherchez un orchestrateur indépendant de Claude Code, ou si vous ne voulez pas dépendre de plusieurs fournisseurs d'API à la fois.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 1 jour.
- En quel langage est-il écrit ?
- Principalement Go, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : un seul modèle pour toutes les tâches
Claude Code exécute tout avec Claude. Pour une revue de code, une analyse d'architecture ou une implémentation parallèle, cela signifie un seul point de vue et un seul fournisseur. ccg-workflow part de ce constat : le README décrit Claude comme le orchestrateur principal qui délègue le travail spécialisé à Codex (OpenAI), Grok (xAI), Kimi Code (Moonshot) et Antigravity. La cible est donc l'équipe qui a déjà adopté Claude Code et veut ajouter d'autres modèles sans changer d'interface. Ce n'est pas un outil pour qui cherche un orchestrateur neutre : Claude reste au centre, et tout passe par lui.
Ce que fait réellement /ccg:go
Le README donne un exemple complet. Vous tapez /ccg:go add JWT authentication to this API. Le moteur lit le contexte du projet (git status, stack technique, arborescence), classe la demande (feature, complexité L, backend, risque élevé), sélectionne une stratégie nommée full-collaborate, puis crée un fichier .ccg/tasks/add-jwt-auth/task.json. Vient ensuite une analyse à deux modèles, Codex et Gemini en parallèle, qui produit un plan. À ce stade, le README mentionne un HARD STOP pour approbation. C'est le point le plus intéressant du design : l'orchestration automatique s'arrête net avant l'implémentation, et rien ne se construit sans validation. Après approbation, des Agent Teams Builders sont lancés pour l'implémentation parallèle. Le README se termine sur Runs et ne va pas plus loin, donc la phase de vérification finale n'est pas documentée dans le matériel fourni.
Le pont Go et le Hook Engine
Deux composants portent l'architecture. Le codeagent-wrapper est un binaire Go compilé qui sert de pont entre Claude et les modèles externes. Le Hook Engine, lui, injecte de l'état à chaque tour pour que Claude ne perde pas le contexte, y compris après une compaction. C'est un détail qui compte : dans un workflow long avec plusieurs modèles, la perte de contexte est le mode de défaillance le plus courant. Le choix d'un binaire Go plutôt qu'un script Node est cohérent avec la distribution de la release preset, qui fournit des binaires précompilés pour codeagent-wrapper. Le dépôt est en Go, mais le paquet publié est npm, et Node.js >= 20 est requis selon les badges du README.
Installation et configuration
L'installation tient en une commande : npx ccg-workflow. Le README annonce 60 secondes. Une variante existe pour DeepSeek Harness, livrée dans le même paquet : npx ccg-workflow dsh install, avec une option --profile <name> pour un profil unique, et npx ccg-workflow dsh list pour voir quels profils disposent de l'outil. Le README indique aussi qu'on peut choisir l'option D. DeepSeek Harness depuis npx ccg-workflow. Le fichier d'état des tâches est .ccg/tasks/<nom-de-tache>/task.json. Le README mentionne par ailleurs qu'APIMart expose un endpoint compatible Anthropic et peut servir de fournisseur d'API pour Claude Code : on lance npx ccg-workflow, on choisit APIMart à l'étape 1, et on colle sa clé. Aucune documentation de configuration plus fine (fichiers de stratégie, seuils de complexité, matrice de rôles) n'apparaît dans le matériel fourni.
Le HARD STOP comme garde-fou, et ses angles morts
Le HARD STOP pour approbation est le garde-fou central : l'analyse multi-modèles tourne librement, mais l'implémentation attend un feu vert humain. C'est un choix défendable, surtout pour des tâches classées à risque élevé. Il a un coût : chaque tâche passe par une interruption manuelle, ce qui rend l'outil mal adapté à des corrections triviales où lancer deux modèles puis attendre une validation coûte plus cher que l'édition elle-même. Le classificateur d'intention est l'autre point de fragilité. Le README montre une classification en catégories (feature, complexité L, backend, risque élevé) sans documenter comment ces catégories sont déterminées ni comment les corriger si la classification est fausse. Une mauvaise classification envoie la tâche vers la mauvaise stratégie, et le matériel fourni ne dit pas s'il existe un moyen de forcer une stratégie manuellement.
Ce que le README ne dit pas
L'exemple de flux se coupe sur Runs. La phase de vérification, la gestion des échecs partiels quand un des modèles parallèles ne répond pas, et le comportement du Hook Engine après compaction sont annoncés mais pas détaillés dans le matériel disponible. Le README mentionne une matrice de rôles pour la partie DeepSeek Harness, avec sept outils de délégation épinglés à un rôle, chacun sur son propre modèle avec sa propre persona. Deux fonctions y sont décrites comme difficiles à reproduire côté Claude Code : les panels de modèles, où plusieurs modèles répondent indépendamment au même brief et sont affichés côte à côte sans vote ni moyenne, et les coéquipiers vivants, où ccg_team embauche un rôle qui persiste entre les tours et possède ses propres fichiers. Le README précise qu'une embauche en collision est refusée, pas signalée par un avertissement, et que chaque embauche demande une approbation. Ce sont des choix de conception précis, mais ils concernent la branche DeepSeek Harness, pas le flux Claude Code principal.
Alternatives et différence d'approche
L'alternative la plus directe est d'utiliser Claude Code seul, avec des sous-agents. La différence n'est pas la parallélisation, que Claude Code sait déjà faire, mais la diversité des modèles : ccg-workflow fait intervenir Codex, Grok, Kimi Code et Antigravity, donc des fournisseurs distincts avec des pondérations d'entraînement distinctes. Si votre besoin est d'obtenir un second avis sur une revue de code, cette diversité a une valeur réelle. Si votre besoin est simplement d'exécuter plusieurs tâches en parallèle, Claude Code seul suffit et vous évitez le binaire pont, la dépendance à plusieurs clés d'API et l'installation npm. L'autre différence tient à la persistance : le fichier task.json dans .ccg/tasks/ donne un état sur disque, ce que les sous-agents de Claude Code ne produisent pas nativement.
Coût de maintenance et licence
Le projet est sous licence MIT, ce qui autorise la modification et la redistribution, y compris dans un contexte commercial, à condition de conserver la notice de copyright. Le README ne contient aucune clause supplémentaire ni restriction de marque. Sur la maintenance, le dernier push daté est le 2026-09-03, même jour que la release preset fournissant les binaires précompilés de codeagent-wrapper, ce qui suggère une activité récente au moment de la rédaction. Le coût réel se situe ailleurs : chaque exécution consomme des appels API chez plusieurs fournisseurs, et le README ne fournit aucun chiffre de consommation par tâche. Le suivi de version porte sur deux artefacts distincts, le paquet npm et le binaire Go, ce qui crée un risque de désynchronisation lors des mises à jour. Vérifiez que les deux correspondent avant de mettre à jour en production.
Conclusion éditoriale
ccg-workflow s'adresse aux équipes déjà installées dans Claude Code qui veulent déléguer l'analyse et la revue à d'autres modèles sans quitter leur terminal. Passez votre chemin si vous cherchez un orchestrateur indépendant de Claude Code, ou si vous ne voulez pas dépendre de plusieurs fournisseurs d'API à la fois. Avant d'adopter, vérifiez deux choses concrètes : que le binaire codeagent-wrapper se compile sur votre plateforme, et que le fichier .ccg/tasks/<nom>/task.json contient bien l'état que vous attendez après une première exécution de /ccg:go.
Notes de la communauté