Google veröffentlicht Scion, ein experimentelles Open-Source-Testbed für Agent-Orchestrierung

 (googlecloudplatform.github.io)
10 Punkte von GN⁺ 22 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Experimentelle Plattform, die dafür entwickelt wurde, gleichzeitig in Containern laufende LLM-basierte Agenten über lokale Maschinen und Remote-Cluster hinweg zu verwalten
  • Jeder Agent läuft als isolierter Prozess mit eigener Identität, eigenen Zugangsdaten und eigenem Workspace und verfolgt unterschiedliche Ziele wie Coding, Audits und Tests dynamisch und parallel
  • Wird als „Hypervisor für Agenten“ definiert und verfolgt die Philosophie, Agenten nicht über Verhaltensregeln im Kontext, sondern extern über Container, git-Worktrees und Netzwerkrichtlinien zu isolieren
  • Integriert wichtige Agenten wie Gemini CLI, Claude Code, OpenCode und Codex über Harness-Adapter und unterstützt Docker, Podman, Apple Container und Kubernetes als Laufzeitumgebungen
  • Verfolgt Agenten-Lebenszyklen mit einem dreidimensionalen Zustandsmodell aus Phase, aktueller Aktivität und Detailstatus und demonstriert Kollaborationsszenarien anhand einer Demo-Game-Codebasis

Was ist Scion?

  • Ein experimentelles Orchestrierungs-Testbed zur Verwaltung von Gruppen LLM-basierter Agenten, die gleichzeitig in Containern auf lokalen Maschinen, Remote-VMs und Kubernetes-Clustern laufen
  • Weist jedem Agenten eine eigene Identität, eigene Zugangsdaten und einen eigenen Workspace zu und führt unterschiedliche Ziele wie Recherche, Coding, Audits und Tests als dynamisch evolvierenden parallelen Task-Graphen aus
  • Google beschreibt Scion als „Hypervisor für Agenten“ und integriert Agenten-Speicher, Chaträume und Task-Management als unabhängige (orthogonale) Belange

Zentrale Designphilosophie: Isolation statt Einschränkung

  • Statt das Verhalten von Agenten durch Regeln zu begrenzen, wird Sicherheit durch Grenzen auf Infrastrukturebene wie Container, git-Worktrees und Netzwerkrichtlinien erreicht
  • Agenten dürfen frei im --yolo-Modus laufen, während die Isolationsschicht die Guardrails von außen übernimmt
  • Dadurch entfällt die Notwendigkeit, komplexe Regeln in den Agenten-Kontext einzuspeisen, sodass sich Agenten auf ihre eigentliche Aufgabe konzentrieren können

Kernkonzepte (Glossar)

Scion verwendet ein eigenes Begriffssystem; die folgenden Konzepte sollte man daher zuerst verstehen

  • Agent: Ein isolierter Prozess, der einen LLM- plus Harness-Loop ausführt. Die grundlegende Ausführungseinheit von Scion mit eigener Identität, eigenen Zugangsdaten und eigenem Workspace
  • Grove: Der Projekt-Workspace, in dem Agenten existieren. Entspricht dem .scion-Verzeichnis im Dateisystem und kann sich im Root eines git-Repositorys oder im Home-Verzeichnis des Nutzers befinden
    • git-basierte Groves verwenden UUID v5 (deterministisch aus der Repository-URL erzeugt), Hub-native Groves UUID v4
  • Hub: Die zentrale Control Plane der gehosteten Scion-Architektur. Fungiert als „Gehirn“, das den Status zwischen Nutzern, Groves und Runtime-Brokern koordiniert
    • Bietet OAuth-basierte Identitäts- und Authentifizierungsverwaltung, zentrale DB-Speicherung von Agent-, Grove- und Template-Status, Dispatching von Lifecycle-Kommandos und kollaborative Ansichten über ein Web-Dashboard
  • Profile: Eine Spezifikation der Ausführungsumgebung, die eine bestimmte Runtime mit Harness-Konfigurationen bündelt. Beim Wechsel zwischen Umgebungen wie „Local Docker“ und „Production Kubernetes“ muss nur das Profile getauscht werden, nicht das Template
  • Harness: Ein Adapter, der bestimmte LLM-Tools wie Gemini CLI, Claude Code oder Codex in das Scion-Ökosystem integriert. Sorgt dafür, dass allgemeine Scion-Kommandos wie start, stop, attach und resume bei jedem Agenten konsistent funktionieren
  • Template: Die Blaupause zur Erstellung eines Agenten. Definiert Standardkonfiguration, System-Prompt und Tools und wird in .scion/templates/ gespeichert
    • Neben den mitgelieferten Templates (gemini, claude, opencode, codex) lassen sich benutzerdefinierte Rollen-Templates wie „Sicherheitsauditor“ oder „React-Experte“ erstellen
  • Runtime: Die Infrastrukturschicht, die Agenten-Container ausführt. Unterstützt Docker, Podman, Apple Container und Kubernetes
  • Runtime Broker: Ein beim Hub registrierter Compute-Knoten (Server, Laptop oder K8s-Cluster), der Ausführungskapazität bereitstellt. Zuständig für Agenten-Lifecycle-Management, Workspace-Synchronisierung und Log-Streaming

Architektur: Manager-Worker-Struktur

  • scion CLI: Ein Tool auf Host-Seite zur Orchestrierung des Agenten-Lebenszyklus. Bietet Grove-Verwaltung (Projekt-Workspace) und Template-Verwaltung (scion templates)
  • Agents: Führen Agentensoftware wie Gemini CLI, Claude Code und Codex in isolierten Runtime-Containern wie Docker aus
  • Grundlegender Nutzungsablauf:
    1. scion init — erstellt im Projekt-Root das Verzeichnis .scion
    2. scion start <agent-name> "<task>" — startet den Agenten
    3. scion attach <agent-name> — interaktive Verbindung zur Agentensitzung herstellen, oder Ausgabe mit scion logs prüfen
    4. scion resume <agent-name> — startet einen unterbrochenen Agenten unter Beibehaltung seines Status neu

Workspace-Strategie: git-Isolationsmodell

Für jeden Agenten gibt es zwei Möglichkeiten, einen unabhängigen git-Workspace bereitzustellen

  • Lokaler Modus — Git Worktrees: Wird bei Betrieb ohne Hub verwendet
    • Erstellt einen Worktree mit dediziertem Branch unter ../.scion_worktrees/<grove>/<agent>
    • Wird innerhalb des Containers nach /workspace gemountet und hat dadurch ein eigenes Arbeitsverzeichnis bei gemeinsam genutzter Repository-Historie
    • Nach Abschluss der Arbeit erfolgt das manuelle Mergen mit git merge <agent-branch>
  • Hub-Modus — Git Init + Fetch: Gilt bei Nutzung des Hub
    • Der Broker injiziert SCION_GIT_CLONE_URL, SCION_GIT_BRANCH und GITHUB_TOKEN in den Container
    • Im Container initialisiert sciontool init den Workspace, lädt das Repository per HTTPS per fetch und checkt anschließend den Branch scion/<agent-name> aus
    • SSH-Zugangsdaten des Hosts sind nicht erforderlich, GITHUB_TOKEN hingegen schon
    • Gewährleistet konsistentes Verhalten auf allen Broker-Maschinen, unabhängig davon, ob das Repository lokal vorhanden ist

Mechanismen zur Ressourcenisolation

  • Dateisystem: Für jeden Agenten wird ein eigenes Home-Verzeichnis in den Container gemountet
  • Shadow Mounts (tmpfs): Blockieren per tmpfs-Shadow-Mounts den Zugriff auf .scion-Konfigurationsdaten oder die Workspaces anderer Agenten
  • Zugangsdaten: Sensible Credentials wie gcloud-Authentifizierung werden per Read-only-Mount oder Umgebungsvariablen nur dem jeweiligen Agenten eingeschränkt offengelegt
  • Externalisierung von Grove-Daten: Nicht-git-Grove-Daten und Agenten-Home-Verzeichnisse werden externalisiert, damit Agenten im Workspace nicht auf Daten anderer Agenten traversieren können

Agenten-Zustandsmodell (3D)

Der Agentenstatus wird in drei Dimensionen verfolgt, um Infrastrukturereignisse und den vom Agenten wahrgenommenen Zustand zu unterscheiden

  • Phase (Lifecycle-Phase): created → provisioning → cloning → starting → running → stopping → stopped (oder error)
  • Activity (Agentenverhalten während running): idle, thinking, executing, waiting_for_input, blocked, completed, limits_exceeded, offline
    • completed, blocked und limits_exceeded sind „sticky“ Zustände und bleiben bestehen, bis der Agent explizit neu gestartet oder gestoppt wird
    • blocked wird vom Agenten selbst gesetzt und zeigt an, dass er auf den Abschluss eines untergeordneten Agenten wartet, damit das System dies nicht fälschlich als Fehler interpretiert
    • offline tritt auf, wenn über einen bestimmten Zeitraum kein Agenten-Heartbeat erkannt wird; Ursache kann eine fehlgeschlagene Erneuerung des Authentifizierungs-Tokens sein
  • Detail: Zusätzlicher Kontext zur aktuellen Activity (Tool-Name, Nachricht, Task-Zusammenfassung usw. im Freiformat)

Plugin-System

  • Erweiterbare Plugin-Architektur auf Basis von hashicorp/go-plugin mit gRPC zur Kommunikation
  • Message-Broker-Plugins: Stellen benutzerdefinierte Message-Delivery-Backends für Agentenbenachrichtigungen und strukturiertes Messaging bereit
  • Agent-Harness-Plugins: Ermöglichen die Implementierung benutzerdefinierter Harnesses, um neue LLM-Tools ohne Änderungen an der Core-Codebasis in Scion zu integrieren
  • Befindet sich derzeit noch in einer frühen Grundaufbauphase (foundational stage); für beide Plugin-Typen gibt es Referenzimplementierungen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 22 일 전
Hacker-News-Kommentare

  • Ich will Scion unbedingt ausprobieren
    Ich habe früher Gastown aus derselben Kategorie genutzt; die Ergebnisse waren gut, aber die Schwankungen waren groß
    Meine größten Beschwerden über Gastown waren: (1) teuer, (2) erzwingt ausschließlich Claude-Modelle, (3) die interne Datenbank lässt sich nur schwer sichern oder remote anbinden, (4) bei Upgrades kommt es häufig zu Kontextverlust
    Trotzdem liefert es diese „magischen“ Ergebnisse bei Unterhaltung und Zusammenarbeit, mehr als andere Tools auf dem Markt

  • Googles Ansatz ist interessant
    Ich habe eine Agent-Orchestration-Plattform namens Optio gebaut, die sich in Ticketsysteme wie Notion, Github Issues, Jira und Linear integriert und so entworfen ist, dass Code-Agenten sogar PR-Merges durchführen
    Beeindruckend an Scion sind die Unterstützung für langlaufende Agenten und die Kommunikation zwischen Containern
    Allerdings habe ich auf k8s aufgebaut, und Scion scheint seine eigene Control Plane neu zu implementieren, deshalb bin ich etwas skeptisch

  • Die Philosophie „Isolation statt Einschränkung“ scheint die richtige Richtung zu sein
    Container setzen zwar Grenzen, aber man sieht nicht, was intern ausgeführt wird
    Ich frage mich, wie viel Ausführungskontext Scion offenlegt. Sonst könnte es wie bei LiteLLM-Angriffen sein, wo man den Schaden erst nach der Ausführung bemerkt

    • Ich bin der Hauptentwickler von Scion
      Es gibt Zustände und Telemetry auf mehreren Ebenen
      Grundsätzlich sammelt ein Hook-System die Daten, und wenn OpenTelemetry unterstützt wird, werden sie an einen Cloud-Collector weitergeleitet
      Manche Aktivitäten werden vom Agenten selbst gemeldet, und diese Informationen spiegeln sich in der Control Plane wider

  • Der Code war tief in der Dokumentation vergraben
    Man musste erst das GitHub-Repository finden

    • Stimmt, ich hatte es Ende März auch mit einem Stern markiert und dann vergessen; jetzt, wo ich wieder darauf gestoßen bin, wirkt es ziemlich interessant

  • Die Richtung ist ähnlich wie bei Gastown, aber ein paar Kernfunktionen scheinen zu fehlen
    Besonders die Formula-Funktion war ein Game Changer

    • Ich bin der Hauptentwickler von Scion
      Die fehlenden Funktionen sind bewusstes Design. Scion ist näher an dem, was Gastown als „gascity“ bezeichnet — eine Struktur, bei der die Nutzer ihre eigenen Orchestrierungs-Charaktere und Definitionen mitbringen
      Dieses Beispiel zeigt eine einfache Markdown-basierte Orchestrierung
      Scion übernimmt die Rolle einer Game Engine, und es wird daran gearbeitet, Gastown auf Scion zu portieren

  • Das Projekt wirkt noch wie ein frühes Experiment, was mich nervös macht
    Der lokale Modus ist stabil, aber der Hub-basierte Workflow sei nur zu etwa 80 % validiert, und die Kubernetes-Runtime sei noch rau
    Deshalb ist Gastown im Moment vielleicht die bessere Wahl

    • Es ist schwer vorstellbar, dass Gastown besser sein soll als irgendetwas anderes

  • Beim Titel musste ich an ein anderes SCION (Internet-Architektur) denken
    Siehe Wiki-Artikel

  • Ich würde gern mehr mit Agenten experimentieren, aber meine Firma bezahlt nur für Claude Code
    Außerdem darf man die API laut TOS nicht für andere Zwecke verwenden
    Gibt es noch jemanden in einer ähnlichen Situation? Selbst tokenbasierte Abrechnung wird schnell teuer

    • Das läuft im Grunde so, dass Claude Code innerhalb eines Containers ausgeführt wird, also ist es kein Verstoß gegen die TOS

  • Wirklich cool! Ich habe vor Kurzem auch etwas Ähnliches gebaut
    Ich habe an Parallax herumgehackt und das Ganze in einem Blogpost zusammengefasst