Google lança como open source o Scion, um testbed experimental de orquestração de agentes

 (googlecloudplatform.github.io)
10 pontos por GN⁺ 23 일 전 | 1 comentários | Compartilhar no WhatsApp
  • Plataforma experimental projetada para gerenciar agentes baseados em LLM executados simultaneamente em contêineres, abrangendo máquinas locais e clusters remotos
  • Cada agente opera como um processo isolado com identidade, credenciais e workspace independentes, conduzindo dinamicamente e em paralelo objetivos diversos como codificação, auditoria e testes
  • Definido como um "hipervisor para agentes", adota a filosofia de isolar externamente com contêineres, git worktrees e políticas de rede, em vez de injetar regras de comportamento no contexto
  • Integra os principais agentes como Gemini CLI, Claude Code, OpenCode e Codex por meio de adaptadores harness, com suporte a Docker, Podman, Apple Container e Kubernetes como runtimes
  • Rastreia o ciclo de vida do agente (Phase), a ação atual (Activity) e o estado detalhado (Detail) com um modelo de estado tridimensional, e demonstra cenários colaborativos com uma codebase de jogo de demonstração

O que é o Scion?

  • Um testbed experimental de orquestração para gerenciar grupos de agentes baseados em LLM executados simultaneamente em contêineres em máquinas locais, VMs remotas e clusters Kubernetes
  • Dá a cada agente identidade, credenciais e workspace independentes para executar objetivos diferentes, como pesquisa, codificação, auditoria e testes, como um grafo paralelo de tarefas em evolução dinâmica
  • O Google define o Scion como um "hipervisor para agentes", integrando memória de agentes, salas de chat e gerenciamento de tarefas como preocupações independentes (orthogonal)

Filosofia central de design: isolamento em vez de restrições

  • Em vez de limitar o comportamento do agente com regras, garante segurança com limites no nível da infraestrutura, como contêineres, git worktrees e políticas de rede
  • Os agentes podem rodar livremente no modo --yolo, enquanto a camada de isolamento atua como guardrail do lado de fora
  • Graças a essa abordagem, não é necessário injetar regras complexas no contexto do agente, permitindo que ele se concentre apenas em sua própria tarefa

Conceitos principais (glossário)

Como o Scion usa um sistema próprio de termos, é preciso entender primeiro os conceitos abaixo

  • Agent: processo isolado que executa o loop de LLM + Harness. É a unidade básica de execução do Scion e possui identidade, credenciais e workspace independentes
  • Grove: workspace do projeto onde os agentes existem. Corresponde ao diretório .scion no sistema de arquivos e pode estar na raiz do repositório git ou na pasta home do usuário
    • Groves baseados em git usam UUID v5 (gerado de forma determinística a partir da URL do repositório), e Groves nativos do Hub usam UUID v4
  • Hub: o plano de controle central da arquitetura hospedada do Scion. Atua como o "cérebro" que coordena o estado entre usuários, Groves e runtime brokers
    • Gerenciamento de identidade e autenticação baseado em OAuth, armazenamento em banco de dados central do estado de agentes/Groves/templates, despacho de comandos de ciclo de vida e visualização colaborativa via Web Dashboard
  • Profile: especificação de ambiente de execução que agrupa uma configuração de runtime e Harness. Ao alternar entre ambientes como "Local Docker" e "Production Kubernetes", basta trocar o Profile sem modificar o template
  • Harness: adaptador que integra ferramentas LLM específicas, como Gemini CLI, Claude Code e Codex, ao ecossistema do Scion. Faz com que comandos genéricos do Scion como start, stop, attach e resume funcionem de forma consistente em qualquer agente
  • Template: blueprint para criação de agentes. Define configuração padrão, system prompt e ferramentas, e fica armazenado em .scion/templates/
    • Além dos templates padrão incluídos (gemini, claude, opencode, codex), é possível criar templates de papéis personalizados como "auditor de segurança" e "especialista em React"
  • Runtime: camada de infraestrutura que executa os contêineres dos agentes. Suporta Docker, Podman, Apple Container e Kubernetes
  • Runtime Broker: nó computacional (servidor, laptop, cluster K8s) que se registra no Hub para fornecer capacidade de execução. Responsável por gerenciar o ciclo de vida do agente, sincronizar workspaces e fazer streaming de logs

Arquitetura: estrutura Manager-Worker

  • scion CLI: ferramenta no lado do host para orquestrar o ciclo de vida dos agentes. Oferece gerenciamento de Grove (workspace do projeto) e de templates (scion templates)
  • Agents: executam softwares de agentes como Gemini CLI, Claude Code e Codex dentro de contêineres de runtime isolados, como Docker
  • Fluxo básico de uso:
    1. scion init — cria o diretório .scion na raiz do projeto
    2. scion start <agent-name> "<task>" — inicia o agente
    3. scion attach <agent-name> — conecta-se interativamente à sessão do agente, ou usa scion logs para verificar a saída
    4. scion resume <agent-name> — reinicia um agente interrompido preservando o estado

Estratégia de workspace: método de isolamento com git

A forma de dar a cada agente um workspace git independente se divide em dois modelos

  • Modo local — Git Worktrees: usado ao executar sem Hub
    • Cria um worktree com branch dedicado no caminho ../.scion_worktrees/<grove>/<agent>
    • É montado em /workspace dentro do contêiner, compartilhando o mesmo histórico do repositório, mas mantendo um diretório de trabalho independente
    • Após concluir o trabalho, faz-se o merge manual com git merge <agent-branch>
  • Modo Hub — Git Init + Fetch: aplicado ao usar o Hub
    • O broker injeta SCION_GIT_CLONE_URL, SCION_GIT_BRANCH e GITHUB_TOKEN no contêiner
    • Dentro do contêiner, sciontool init inicializa o workspace, faz fetch do repositório via HTTPS e depois faz checkout da branch scion/<agent-name>
    • Não exige credenciais SSH do host, mas requer GITHUB_TOKEN
    • Garante comportamento consistente em todas as máquinas broker, independentemente de o repositório existir localmente ou não

Mecanismos de isolamento de recursos

  • Sistema de arquivos: monta um diretório home exclusivo por agente no contêiner
  • Shadow Mounts (tmpfs): bloqueia o acesso aos dados de configuração .scion e aos workspaces de outros agentes com shadow mounts tmpfs
  • Credenciais: credenciais sensíveis, como autenticação gcloud, são expostas de forma limitada apenas ao agente correspondente por meio de mount somente leitura ou injeção por variável de ambiente
  • Externalização de dados do Grove: dados de Grove não-git e diretórios home dos agentes são externalizados para impedir que um agente percorra (traverse) dados de outros agentes a partir do workspace

Modelo de estado do agente (3 dimensões)

O estado do agente é rastreado em três dimensões para distinguir eventos de infraestrutura do estado cognitivo do agente

  • Phase (etapa do ciclo de vida): created → provisioning → cloning → starting → running → stopping → stopped (ou error)
  • Activity (comportamento do agente durante running): idle, thinking, executing, waiting_for_input, blocked, completed, limits_exceeded, offline
    • completed, blocked e limits_exceeded são estados "sticky", mantidos até que o agente seja explicitamente reiniciado ou interrompido
    • blocked é definido pelo próprio agente e indica que ele está aguardando a conclusão de um subagente, evitando que o sistema interprete isso erroneamente como erro
    • offline ocorre quando o heartbeat do agente não é detectado por um certo período, e pode ser causado por falha na renovação do token de autenticação
  • Detail: contexto adicional da Activity atual (nome da ferramenta, mensagem, resumo da tarefa etc., em formato livre)

Sistema de plugins

  • Arquitetura de plugins baseada em hashicorp/go-plugin, com possibilidade de expandir o sistema, usando comunicação gRPC
  • Plugin de message broker: fornece um backend personalizado de entrega de mensagens para notificações de agentes e mensageria estruturada
  • Plugin de agent harness: permite implementar um harness personalizado para integrar novas ferramentas LLM ao Scion sem alterar a codebase principal
  • Atualmente em estágio inicial (foundational stage), com implementações de referência fornecidas para ambos os tipos de plugin

Leituras relacionadas

1 comentários

 
GN⁺ 23 일 전
Comentários do Hacker News

  • Quero muito testar o Scion desta vez
    Já usei o Gastown antes, do mesmo tipo, e os resultados foram bons, mas a variação era grande
    As principais reclamações sobre o Gastown eram: (1) caro, (2) uso obrigatório apenas de modelos Claude, (3) dificuldade para fazer backup ou conectar remotamente ao banco de dados interno, (4) perda de contexto frequente durante upgrades
    Mesmo assim, ele entregava resultados de conversa e colaboração “mágicos” em comparação com outras ferramentas do mercado

  • A abordagem do Google é interessante
    Eu criei uma plataforma de orquestração de agentes chamada Optio, integrada a sistemas de tickets como Notion, Github Issues, Jira e Linear, e projetada para que agentes de código levem o processo até o merge do PR
    O suporte do Scion a agentes de longa duração e comunicação entre contêineres é impressionante
    Mas eu construí em cima de k8s, então fico um pouco cético porque o Scion parece tentar reimplementar seu próprio control plane

  • A filosofia de “isolamento em vez de restrições” parece ser a direção certa
    Contêineres oferecem fronteiras, mas não permitem ver o que acontece dentro
    Fico curioso para saber quanto contexto de execução o Scion expõe. Caso contrário, pode acontecer algo como no ataque ao LiteLLM, em que o dano só é percebido depois da execução

    • Sou o principal desenvolvedor do Scion
      Há vários níveis de estado e telemetry
      Basicamente, um sistema de hooks coleta os dados e, quando há suporte a OpenTelemetry, os envia para um coletor em nuvem
      Algumas atividades são reportadas pelos próprios agentes, e essas informações são refletidas no control plane

  • O código estava enterrado no meio da documentação
    Tive que procurar o repositório no GitHub

    • Verdade, eu também tinha dado estrela no fim de março e esquecido; agora que vi de novo, parece bem interessante

  • A direção é parecida com a do Gastown, mas parece que faltam algumas funções principais
    Em especial, o recurso de formula foi um divisor de águas

    • Sou o principal desenvolvedor do Scion
      Os recursos ausentes são intencionais. O Scion está mais próximo do que o Gastown chama de “gascity” — uma estrutura em que o usuário traz seus próprios personagens e definições de orquestração
      Neste exemplo, trata-se de uma orquestração baseada em Markdown bastante simples
      O Scion atua como motor de jogo, e há um trabalho em andamento para portar o Gastown para cima do Scion

  • O projeto ainda está em fase experimental inicial, o que me deixa inseguro
    Dizem que o modo local é estável, mas os fluxos de trabalho baseados em Hub estão validados em cerca de 80%, e o runtime de Kubernetes ainda está bruto
    Então talvez o Gastown ainda seja a melhor escolha por enquanto

    • É difícil imaginar que o Gastown seja melhor do que qualquer outra coisa

  • Ao ver o título, pensei em outro SCION (arquitetura de internet)
    Veja o artigo na Wikipédia

  • Quero experimentar mais com agentes, mas a empresa só paga pelo Claude Code
    Além disso, pelos TOS, não se pode usar a API para outros fins
    Mais alguém está numa situação parecida? A cobrança por token também fica cara muito rápido

    • Isso basicamente executa o Claude Code dentro de um contêiner, então não viola os TOS

  • Muito legal! Eu também fiz algo parecido recentemente
    Brinquei com o Parallax e organizei o conteúdo relacionado neste blog