PT
Geodi, personagem oficial do GEODE em pixel art
Voltar à sala

GEODE

Autonomous Agent Harness

Da observação à próxima ação.

Um harness local de agentes autônomos ao qual se pode confiar pesquisa, trabalho com arquivos e tarefas agendadas.

2026.02.21 — present

Concepção, julgamento, verificação: Author · implementação: Claude · revisão: Codex

  • CLIPublicado · PyPI
  • Servidor MCPImplementado

Dos rollouts às evidências

Uma taxa de aprovação sozinha não explica uma execução. Preservo a ordem dos eventos, as chamadas de ferramenta e seus resultados, a linhagem de novas tentativas e as evidências de verificadores independentes, e depois conecto as partes que podem ser publicadas. Estes experimentos mostram como os contratos de registro e avaliação evoluíram.

Por experimento · em ordem de data

Os seis experimentos estão em ordem de data; não são um único processo de otimização conectado. O SIL não alimenta automaticamente o Crucible nem o Jev, e isto não afirma que o GEODE em produção continuou melhorando. As datas são as dos experimentos e dos snapshots de publicação, e as setas só são usadas para as etapas dentro de um experimento.

  1. June 3, 2026 to June 4, 2026SIL · busca de políticas externa

    Um KEEP de uma única auditoria foi reverificado por medição repetida

    PerguntaUma mutação de política melhorou o comportamento de uso de ferramentas além do ruído da auditoria?

    Experimento externo · fora do runtime do GEODE

    1. Linha de base · K=5
    2. Uma mutação de política
    3. Auditoria do Petri
    4. Medição repetida
      • Manter
      • Reverter
    O que mudou
    Neste experimento, medições repetidas foram somadas à auditoria única de uma mutação antes de decidir manter ou reverter. Foram acrescentadas sementes pareadas por dificuldade e uma linha de base K=5, e os braços never, random e gate separam a deriva sem mudança das mudanças aceitas.
    O que isso sustenta
    Medido de novo, o candidato mantido com uma única auditoria ficou pior que a linha de base (menor é melhor), então sua adoção foi revertida. Este experimento concluiu sem melhora robusta. É uma auditoria comportamental Petri broken_tool_use, não uma recompensa por conclusão de tarefa.

  2. July 11, 2026 to July 13, 2026Crucible · kernel de experimentos externo

    Permanecer na busca e chegar ao produto são vereditos separados

    PerguntaA evidência para manter um candidato na busca é a mesma que para promovê-lo e publicá-lo no produto?

    Kernel Crucible externo · checkout de medição separado

    1. Candidato · linhagem pai
    2. Verificação do contrato congelado
    3. Medição pareada
      • KEEPsó para um veredito selado separado
      • REJECT
      • INVALIDnull, não 0%
    O que mudou
    Candidatos rejeitados e inválidos são mantidos com sua linhagem pai, e a seleção no train, a elegibilidade selada e a autoridade de publicação do produto são registros separados.
    O que isso sustenta
    O r14 foi KEEP no train (seis unidades de tarefas, um ensaio cada, sem autoridade de promoção), mas seu veredito selado separado foi REJECT (sem autoridade de promoção nem de publicação do produto). O r35 é INVALID por cobertura incompleta e contaminação de infraestrutura; sem linhas pareadas, sua média fica null. Não é automodificação do runtime nem uma cadeia de implantação SIL → Crucible.

  3. July 21, 2026 · July 31, 2026Refinamento · publicação

    Os registros restantes foram classificados, e só o que pode ser compartilhado virou uma versão imutável

    PerguntaO que pode de fato ser reconstruído e o que pode ser compartilhado com segurança?

    1. Fonte privadaRegistro de sessão · evidências nativasresultado nativo · verificador incluído
      • Eventos normalizadosmanter ordem · identidade
    2. Eventos normalizadosidentidade · ordem · pares chamada-resultado
      • Candidato públicoallowlist · ocultar · digest
    3. Candidato públicoem revisão
      • Verificações de integridade · privacidadeverificar
    4. Verificações de integridade · privacidadepareamento · linhagem · escopo
      • Versão imutávelsó bytes revisados
    5. Repositório públicoVersão imutávelmanifest · resultados nativos referenciados por digest
      • Releitura remotaverificar o hash
    6. Releitura remotaSHA-256 fixado
    O que mudou
    O inventário de July 21, 2026 classificou por fonte os registros de diálogo, ferramentas, busca e decisão, e duplicatas da mesma fonte não foram contadas como exemplos independentes. A partir de July 31, 2026, geode.trajectory@1 e geode.trajectory-release@1 tornam explícitos a identidade, a ordem dos eventos, os pares chamada-resultado, a integridade do escopo e da reprodução e manifests vinculados ao conteúdo. Cópias públicas transformadas e originais mantêm digests separados.
    O que isso sustenta
    Aqui, refinamento significa normalização, correlação, ocultação explícita, linhagem e admissão à publicação. Não reconstrói raciocínio oculto nem declara um conjunto de dados pronto para treinamento. Um escopo completo não é reprodução byte a byte completa quando corpos privados são substituídos por digests.

  4. August 25, 2026Learning view

    Um rollout e suas evidências foram vinculados por identificadores

    PerguntaQual entrada, tentativa, sequência de eventos e recompensa formam um conjunto?

    geode.eval-learning-view@2 · unido por IDs e digests verificados, não uma ordem causal

    1. example
    2. rollout
    3. trajectory
    4. reward

    Os receipts do verificador nativo são donos da recompensa. As novas tentativas de infraestrutura são tentativas dentro de um único rollout.

    O que mudou
    Trajetórias imutáveis são reutilizadas por joins com escopo definido, e as recompensas continuam sendo rótulos derivados do avaliador. Novas tentativas de infraestrutura não acrescentam rollouts. Um 0 observado é preservado e uma recompensa ausente é null; tentativas inválidas ou abortadas ficam fora da seleção de recompensa. A validade é uma propriedade do rollout, não automaticamente uma recompensa null.
    O que isso sustenta
    Uma execução Terminal-Bench fast-3 com Harbor 0.8.0 (três tarefas, 3/3) e um diagnóstico Tau2 em três domínios (1/3, dois zeros válidos) estão vinculados na mesma estrutura. São candidatos para pós-treinamento, não conjuntos de dados usados no treinamento nem evidência de pesos melhorados, e um resultado de três tarefas não é a acurácia da suíte.

  5. August 27, 2026 to September 5, 2026Harbor · Terminal-Bench 2.1

    Um mesmo ensaio produziu separadamente o resultado e o registro de reprodução

    PerguntaComo a execução real de uma tarefa vira um resultado e uma reprodução inspecionável?

    1. Tarefa congelada · specfixada antes · cinco repetições
      • Ensaio isoladoinstruções · ambiente · limites
    2. Ensaio do Harbor 0.22.0 · execução realEnsaio isoladoGEODE como ator
      • Ações e estado finalexecutar
    3. Ações e estado finalcomportamento observado
      • Verificador da tarefaverificar o estado da tarefa
      • ATIF · projeção em eventos públicosprojetar os eventos registrados
    4. Verificador da tarefa
      • Recompensa nativa · receiptrecompensa
    5. Recompensa nativa · receipt
      • Análise da tentativa selecionadaseleção congelada
    6. ATIF · projeção em eventos públicospós-processamento · não é nova execução
    7. Análise da tentativa selecionadaregra de seleção congelada
    O que mudou
    A spec congelada, cada tentativa, o resultado selecionado, o verificador da tarefa e uma reprodução fiel, mas limitada, são mantidos como registros vinculados separados. O Harbor 0.22.0 executou cinco repetições com GPT-5.6 Sol/max, comparando o GEODE (então um adaptador com uma única ferramenta de terminal) com o Codex.
    O que isso sustenta
    Uma tarefa contém instruções, ambiente e testes; um ensaio é uma tentativa; um job agrupa ensaios. O verificador da tarefa decide a recompensa, e o juiz de conclusão interno do GEODE é feedback do runtime. A reprodução pública é uma projeção post hoc dos eventos de ferramenta registrados, não um PTY bruto nem uma nova execução, e nenhum comando foi inventado para as células ausentes. A métrica principal pré-registrada não pôde ser medida.

  6. September 24, 2026 to September 28, 2026Jev · delegação de decisões

    Um candidato correto ainda precisa de verificação da entrega

    PerguntaUm julgamento delegado preserva de fato a qualidade da tarefa e a entrega final?

    1. U8n · execução Noul · Harbor 0.22 · o Astra executa e repara, só o roteamento do julgamento mudaEstado de decisãocontrato da tarefa · candidato · observações de ferramentas
      • Julgamento · Noulentrada do julgamento
    2. Julgamento · NoulAstra ou Jev
      • GEODE consomeprobabilidades por condição
    3. GEODE consomesustentado: entregar; evidência ausente: reter
      • Entrega finalsustentado
      • Reparo do Astraevidência ausente · reter
    4. Entrega final
      • Verificação independente do resultadoresultado entregue
    5. Reparo do Astrapróximo candidato após o feedback
      • Julgamento · Nouljulgar de novo
      • Último candidato · preservadoúltimo candidato preservado
    6. Verificação independente do resultadooráculo de regras · resultado entregue
    7. Painéis fixos U3só julgamento · sem ator, ferramentas ou Harbor
    8. Diagnóstico post hoc · após a execuçãoÚltimo candidato · preservado
      • Diagnóstico por oráculo post hocverificação post hoc
    9. Diagnóstico por oráculo post hoccorreção do candidato · sem efeito na entrega
    O que mudou
    A aceitação do julgamento, a correção do candidato e a entrega final são registradas como resultados separados, e as linhagens de preparação, falha e reparo são preservadas na cópia pública. Os hashes originais e os da cópia pública transformada ficam separados.
    O que isso sustenta
    Nos 11 pares post hoc do estudo U8n interrompido, o último candidato estava correto nos dois braços, mas a entrega foi Astra 11/11 e Jev Noul 0/11: o julgamento de evidência ausente do Jev Noul reteve a entrega. É uma análise post hoc e não é generalizada. O recálculo numérico público, a inspeção da reprodução e uma nova execução real são três operações diferentes.