Google publie en open source Scion, un banc d’essai expérimental d’orchestration d’agents

• Plateforme expérimentale conçue pour gérer des agents basés sur des LLM s’exécutant simultanément dans des conteneurs, sur des machines locales comme sur des clusters distants
• Chaque agent fonctionne comme un processus isolé avec une identité, des identifiants et un espace de travail propres, afin de poursuivre de façon dynamique et parallèle divers objectifs comme le code, l’audit ou les tests
• Défini comme un « hyperviseur pour agents », le projet adopte une philosophie d’isolation externe via des conteneurs, des git worktrees et des politiques réseau, plutôt que d’injecter des règles de comportement dans le contexte
• Intègre les principaux agents comme Gemini CLI, Claude Code, OpenCode et Codex via des adaptateurs harness, avec prise en charge de Docker, Podman, Apple Container et Kubernetes comme runtimes
• Suit le cycle de vie des agents (Phase), leur comportement actuel (Activity) et leur état détaillé (Detail) via un modèle d’état en trois dimensions, et démontre des scénarios collaboratifs sur une base de code de jeu de démonstration

---

Qu’est-ce que Scion ?

• Banc d’essai expérimental d’orchestration qui gère des groupes d’agents basés sur des LLM s’exécutant simultanément dans des conteneurs, sur des machines locales, des VM distantes et des clusters Kubernetes
• Attribue à chaque agent une identité, des identifiants et un espace de travail indépendants, afin d’exécuter des objectifs différents comme la recherche, le code, l’audit ou les tests sous la forme d’un graphe de tâches parallèles à évolution dynamique
• Google définit Scion comme un « hyperviseur pour agents », qui unifie la mémoire des agents, les salons de discussion et la gestion des tâches comme des préoccupations indépendantes (orthogonales)

Philosophie de conception centrale : l’isolation plutôt que la restriction

• Au lieu de limiter le comportement des agents par des règles, la sécurité est assurée par des frontières au niveau de l’infrastructure, comme les conteneurs, les git worktrees et les politiques réseau
• Les agents peuvent s’exécuter librement en mode --yolo, tandis que la couche d’isolation joue le rôle de garde-fou depuis l’extérieur
• Cette approche évite d’avoir à injecter des règles complexes dans le contexte des agents, ce qui leur permet de se concentrer uniquement sur leur tâche

Concepts clés (glossaire)

Scion utilise sa propre terminologie ; il faut donc d’abord comprendre les concepts ci-dessous

• Agent : processus isolé qui exécute une boucle LLM + Harness. C’est l’unité d’exécution de base de Scion, avec une identité, des identifiants et un espace de travail indépendants
• Grove : espace de travail de projet dans lequel les agents existent. Correspond au répertoire .scion du système de fichiers, et peut se trouver à la racine d’un dépôt git ou dans le dossier personnel de l’utilisateur
  • Les Grove basés sur git utilisent UUID v5 (généré de façon déterministe à partir de l’URL du dépôt), tandis que les Grove natifs du Hub utilisent UUID v4
• Hub : plan de contrôle central de l’architecture Scion hébergée. Il joue le rôle de « cerveau » en coordonnant l’état entre les utilisateurs, les Grove et les brokers de runtime
  • Gère l’identité et l’authentification basées sur OAuth, stocke dans une base centrale l’état des agents, Grove et templates, distribue les commandes du cycle de vie et fournit une vue collaborative via un tableau de bord web
• Profile : spécification d’environnement d’exécution qui regroupe les paramètres d’un runtime et d’un Harness. Pour passer d’un environnement à un autre comme « Local Docker » ou « Production Kubernetes », il suffit de changer le Profile sans modifier le template
• Harness : adaptateur qui intègre un outil LLM spécifique, comme Gemini CLI, Claude Code ou Codex, dans l’écosystème Scion. Il garantit que les commandes génériques Scion comme start, stop, attach et resume fonctionnent de manière cohérente avec n’importe quel agent
• Template : modèle de création d’agent. Il définit la configuration par défaut, le prompt système et les outils, et est stocké dans .scion/templates/
  • En plus des templates fournis (gemini, claude, opencode, codex), il est possible de créer des templates de rôles personnalisés comme « auditeur sécurité » ou « expert React »
• Runtime : couche d’infrastructure qui exécute les conteneurs des agents. Prend en charge Docker, Podman, Apple Container et Kubernetes
• Runtime Broker : nœud de calcul (serveur, ordinateur portable, cluster K8s) enregistré auprès du Hub pour fournir de la capacité d’exécution. Il prend en charge la gestion du cycle de vie des agents, la synchronisation des espaces de travail et le streaming des logs

Architecture : structure Manager-Worker

• scion CLI : outil côté hôte qui orchestre le cycle de vie des agents. Il fournit aussi la gestion des Grove (espaces de travail de projet) et celle des templates (scion templates)
• Agents : exécutent des logiciels d’agent comme Gemini CLI, Claude Code et Codex dans des conteneurs runtime isolés tels que Docker
• Flux d’utilisation de base :
  1. scion init — crée le répertoire .scion à la racine du projet
  2. scion start <agent-name> "<task>" — lance un agent
  3. scion attach <agent-name> — se connecte de manière interactive à une session d’agent, ou consulte la sortie avec scion logs
  4. scion resume <agent-name> — redémarre un agent interrompu en conservant son état

Stratégie d’espace de travail : isolation via git

Il existe deux méthodes pour attribuer à chaque agent un espace de travail git indépendant

• Mode local — Git Worktrees : utilisé lors d’une exécution sans Hub
  • Crée un worktree avec une branche dédiée dans ../.scion_worktrees/<grove>/<agent>
  • Monté dans /workspace à l’intérieur du conteneur, il partage l’historique du même dépôt tout en conservant un répertoire de travail indépendant
  • Une fois le travail terminé, la fusion se fait manuellement avec git merge <agent-branch>
• Mode Hub — Git Init + Fetch : appliqué quand le Hub est utilisé
  • Le broker injecte SCION_GIT_CLONE_URL, SCION_GIT_BRANCH et GITHUB_TOKEN dans le conteneur
  • Dans le conteneur, sciontool init initialise l’espace de travail, récupère le dépôt en HTTPS, puis extrait la branche scion/<agent-name>
  • Les identifiants SSH de l’hôte ne sont pas nécessaires, mais GITHUB_TOKEN est requis
  • Garantit un comportement cohérent sur toutes les machines broker, que le dépôt soit ou non présent localement

Mécanismes d’isolation des ressources

• Système de fichiers : montage d’un répertoire personnel dédié à chaque agent dans le conteneur
• Shadow Mounts (tmpfs) : l’accès aux données de configuration .scion ou aux espaces de travail d’autres agents est bloqué via des shadow mounts tmpfs
• Identifiants : les identifiants sensibles, comme l’authentification gcloud, sont exposés de manière limitée à l’agent concerné uniquement, via un montage en lecture seule ou une injection par variable d’environnement
• Externalisation des données Grove : les données Grove non git et les répertoires personnels des agents sont externalisés, empêchant un agent de parcourir les données d’autres agents depuis l’espace de travail

Modèle d’état des agents (3 dimensions)

L’état des agents est suivi selon trois dimensions afin de distinguer les événements d’infrastructure de l’état cognitif de l’agent

• Phase (étape du cycle de vie) : created → provisioning → cloning → starting → running → stopping → stopped (ou error)
• Activity (comportement de l’agent pendant running) : idle, thinking, executing, waiting_for_input, blocked, completed, limits_exceeded, offline
  • completed, blocked et limits_exceeded sont des états « sticky », conservés jusqu’à ce que l’agent soit explicitement redémarré ou arrêté
  • blocked est défini par l’agent lui-même pour indiquer qu’il attend la fin d’un sous-agent, ce qui évite au système de le confondre avec une erreur
  • offline survient lorsqu’aucun heartbeat de l’agent n’est détecté pendant un certain temps ; cela peut être dû à un échec de renouvellement du jeton d’authentification
• Detail : contexte additionnel de l’Activity en cours (nom de l’outil, message, résumé de tâche, etc., en format libre)

Système de plugins

• Architecture de plugins basée sur hashicorp/go-plugin, permettant d’étendre le système, avec communication en gRPC
• Plugins de broker de messages : fournissent des backends personnalisés pour les notifications d’agents et la messagerie structurée
• Plugins de harness d’agent : permettent d’implémenter des harness personnalisés pour intégrer de nouveaux outils LLM dans Scion sans modifier le code de base
• Le projet est actuellement à un stade initial (foundational stage), avec des implémentations de référence fournies pour les deux types de plugins

[GN⁺]

Avis sur Hacker News

• J’ai vraiment envie d’essayer Scion
  J’avais déjà utilisé Gastown dans le même genre, et les résultats étaient bons, mais très variables
  Mes principaux reproches à Gastown sont : (1) c’est cher, (2) obligation d’utiliser uniquement les modèles Claude, (3) il est difficile de sauvegarder la base de données interne ou de s’y connecter à distance, (4) on subit souvent une perte de contexte lors des mises à niveau
  Malgré tout, il produit des résultats de conversation et de collaboration « magiques » par rapport aux autres outils du marché

• L’approche de Google est intéressante
  J’ai créé une plateforme d’orchestration d’agents appelée Optio, conçue pour s’intégrer à des systèmes de tickets comme Notion, Github Issues, Jira et Linear, et permettre à des agents de code d’aller jusqu’à la fusion de PR
  La prise en charge des agents de longue durée et de la communication inter-conteneurs dans Scion est impressionnante
  En revanche, je l’ai construit sur k8s, et Scion semble tenter de réimplémenter son propre control plane, ce qui me laisse un peu sceptique

• La philosophie du « l’isolation plutôt que les contraintes » semble aller dans la bonne direction
  Les conteneurs fournissent des frontières, mais on ne voit pas ce qui se passe à l’intérieur
  Je me demande jusqu’où Scion expose le contexte d’exécution. Sinon, on peut se retrouver dans une situation comme l’attaque LiteLLM, où l’on ne découvre les dégâts qu’après l’exécution

  • Je suis le développeur principal de Scion
    Il y a plusieurs niveaux d’état et de telemetry
    En gros, le système de hooks collecte les données et, lorsqu’OpenTelemetry est pris en charge, les envoie vers un collecteur cloud
    Certaines activités sont auto-déclarées par les agents eux-mêmes, et ces informations sont reflétées dans le control plane

• Le code était enfoui très profondément dans la documentation
  Il a fallu que je trouve le dépôt GitHub

  • Oui, pareil pour moi, je l’avais ajouté aux favoris fin mars puis oublié, et en y revenant cette fois, ça a l’air assez intéressant

• La direction est similaire à celle de Gastown, mais il semble manquer quelques fonctionnalités essentielles
  En particulier, la fonction formula changeait vraiment la donne

  • Je suis le développeur principal de Scion
    Les fonctionnalités absentes relèvent d’un choix de conception délibéré. Scion est plus proche de ce que Gastown appelle « gascity » — une structure dans laquelle les utilisateurs apportent eux-mêmes les personnages d’orchestration et leurs définitions
    Si l’on regarde cet exemple, on voit qu’il s’agit d’une simple orchestration basée sur Markdown
    Scion joue le rôle de moteur de jeu, et un portage de Gastown vers Scion est en cours

• Le projet en est encore au stade expérimental précoce, donc c’est inquiétant
  Le mode local est stable, mais les workflows basés sur Hub ne sont validés qu’à environ 80 %, et le runtime Kubernetes reste assez brut
  Du coup, Gastown est peut-être encore un meilleur choix pour le moment

  • J’ai du mal à imaginer que Gastown soit meilleur que quoi que ce soit d’autre

• En voyant le titre, j’ai pensé à un autre SCION (architecture Internet)
  Voir l’article Wikipédia

• J’aimerais faire davantage d’expérimentations avec les agents, mais mon entreprise ne paie que pour Claude Code
  En plus, selon les CGU, l’API ne doit pas être utilisée à d’autres fins
  D’autres sont dans le même cas ? Même la facturation au token devient vite chère

  • En pratique, cela exécute Claude Code dans un conteneur, donc ce n’est pas une violation des CGU

• Vraiment très cool ! J’ai moi aussi bricolé quelque chose de similaire récemment
  J’ai hacké Parallax, et j’en ai parlé sur ce blog