Aller au contenu
~/benhattab
Retour aux projets
Open sourceOpen source2025 — présent

Orchestra

Le système d'exploitation des agents de code

Un CLI Go qui pilote plusieurs agents de code (Claude Code, OpenCode, Mimo…) derrière une seule interface supervisée. Il route chaque tâche vers l'agent le plus adapté, valide le résultat par build → lint → test, laisse l'agent réparer ses propres échecs, et ne garde rien sans votre accord explicite.

Go
binaire unique
MIT
open source
4
étapes de CI
Rôle

Auteur et mainteneur — projet open source sous licence MIT

Stack
Go 1.22+CLITUIgit worktreesGitHub ActionsGoReleaserMIT
Liens
Le problème

J'utilise plusieurs agents de code au quotidien, et je passais mon temps à faire à la main ce qu'aucun d'eux ne fait : choisir lequel lancer selon la tâche, vérifier que le résultat compile et passe les tests avant de le croire, relancer quand ça casse, et empêcher trois agents de se marcher dessus sur le même dépôt. Le goulot d'étranglement n'était plus la génération de code — c'était la supervision.

L'approche

Orchestra part d'un principe simple : un agent n'a pas fini quand il a répondu, il a fini quand la vérification passe. Chaque exécution est donc suivie d'une boucle build → lint → test définie par l'utilisateur. Si elle échoue, l'agent reçoit la sortie d'erreur et retente. Ce qui remonte à l'humain est déjà vérifié.

La parallélisation passe par les worktrees git. Une grosse demande est décomposée en étapes ; les étapes indépendantes s'exécutent simultanément, chacune dans son propre worktree isolé. Aucun conflit possible, et l'arbre de travail principal reste intact tant que rien n'a été approuvé.

Rien n'est écrit sans un `y`. Le diff est présenté, l'humain tranche. Cette contrainte a façonné tout le reste du design — elle est la raison d'être de l'outil, pas une option de sécurité ajoutée après coup.

Comme il exécute les mêmes tâches à travers plusieurs agents, Orchestra peut aussi les comparer : un mode benchmark mesure les agents les uns contre les autres sur le même travail, et l'historique de chaque exécution est conservé.

Architecture
  1. 01

    Routeur

    Distingue une question d'une tâche de code. Les questions reçoivent une réponse directe ; les tâches sont dirigées vers l'agent le plus adapté.

    internal/engine

  2. 02

    Ordonnanceur

    Décompose une demande en étapes, identifie celles qui sont indépendantes et les lance en parallèle dans des worktrees isolés.

    internal/scheduler

  3. 03

    Validateur

    Exécute la commande de vérification fournie (`--test`). En cas d'échec, renvoie la sortie à l'agent pour auto-réparation.

    build → lint → test

  4. 04

    Portail d'approbation

    Affiche le diff et attend un `y`. Aucune écriture sur le dépôt réel avant cette confirmation.

    diff review

  5. 05

    Dashboard TUI

    Vue plein écran sur les agents, l'historique des exécutions, les benchmarks et le chat.

    orchestra dashboard

  6. 06

    Distribution

    Binaires précompilés via GoReleaser, script d'installation en une ligne, `go install`, et CI GitHub Actions qui impose build, vet, test et gofmt.

    GoReleaser · Actions

Arbitrages

Écrit en Go

Un outil qui supervise des agents de code doit démarrer instantanément, se distribuer en un seul binaire sans runtime, et gérer des dizaines de processus concurrents sans effort. Go répond aux trois. Un CLI Node ou Python aurait imposé une installation à mes utilisateurs et une gestion de concurrence bien plus lourde.

Les worktrees git plutôt que des conteneurs

Pour isoler des agents qui modifient le même dépôt, la réponse habituelle est Docker. Les worktrees coûtent quelques centaines de millisecondes au lieu de plusieurs secondes, partagent l'historique git, et n'exigent aucun démon sur la machine de l'utilisateur. Pour de l'isolation en écriture — le seul besoin réel ici — c'est le bon niveau d'abstraction.

Points clés
  • Route automatiquement les tâches vers l'agent le plus adapté, et répond directement aux questions simples
  • Valide chaque résultat par build → lint → test, avec auto-réparation par l'agent en cas d'échec
  • Décompose les grosses demandes et exécute les étapes indépendantes en parallèle dans des worktrees git isolés
  • Rien n'est conservé sans validation explicite du diff par l'humain
  • Mode benchmark pour comparer les agents entre eux sur un travail identique
  • CI GitHub Actions imposant build, go vet, go test et gofmt à chaque push