Geodi, il personaggio pixel ufficiale di GEODE
Torna alla sala

GEODE

Autonomous Agent Harness

Dall’osservazione all’azione successiva.

Un harness locale per agenti autonomi a cui affidare ricerca, lavoro sui file e attività pianificate.

2026.02.21 — present

Progettazione, giudizio, verifica: Author · implementazione: Claude · revisione: Codex

  • CLIPubblicato · PyPI
  • Server MCPImplementato

Dai rollout alle prove

Un tasso di successo da solo non spiega un’esecuzione. Conservo l’ordine degli eventi, le chiamate a strumenti e i loro risultati, la genealogia dei nuovi tentativi e le prove di verifica indipendente, poi collego le parti che si possono pubblicare. Questi esperimenti mostrano come si sono sviluppati i contratti di registrazione e di valutazione.

Per esperimento · in ordine di data

I sei esperimenti sono disposti in ordine di data; non sono un unico processo di ottimizzazione collegato. SIL non alimenta automaticamente Crucible o Jev, e non si afferma che il prodotto GEODE abbia continuato a migliorare. Le date sono quelle degli esperimenti e degli snapshot di pubblicazione, e le frecce si usano solo per le fasi all’interno di un esperimento.

  1. June 3, 2026 to June 4, 2026SIL · ricerca di policy esterna

    Un KEEP ottenuto da un solo audit è stato ricontrollato con misure ripetute

    DomandaUna mutazione di policy ha migliorato il comportamento nell’uso degli strumenti oltre il rumore dell’audit?

    Esperimento esterno · fuori dal runtime di GEODE

    1. Baseline · K=5
    2. Una mutazione di policy
    3. Audit Petri
    4. Misura ripetuta
      • Mantenere
      • Ripristinare
    Cosa è cambiato
    In questo esperimento, al singolo audit di una mutazione si è aggiunta una misura ripetuta prima di decidere se mantenere o ripristinare. Si sono aggiunti seed bilanciati per difficoltà e una baseline K=5, e i bracci never, random e gate separano le oscillazioni senza alcuna modifica dalle modifiche accettate.
    Cosa sostiene
    Rimisurato, il candidato mantenuto dopo un solo audit è risultato peggiore della baseline (più basso è meglio), quindi la sua adozione è stata annullata. L’esperimento si è concluso senza un miglioramento solido. È un audit comportamentale Petri broken_tool_use, non una ricompensa per il completamento del task.
  2. July 11, 2026 to July 13, 2026Crucible · kernel sperimentale esterno

    Restare nella ricerca e arrivare al prodotto sono verdetti separati

    DomandaLe prove per mantenere un candidato nella ricerca sono le stesse che servono per promuoverlo e rilasciarlo nel prodotto?

    Kernel Crucible esterno · checkout di misura separato

    1. Candidato · genealogia del genitore
    2. Controllo del contratto congelato
    3. Misura appaiata
      • KEEPsolo verso un verdetto sealed separato
      • REJECT
      • INVALIDnull, non 0%
    Cosa è cambiato
    I candidati rifiutati e invalidi sono conservati con la genealogia del genitore, e selezione train, idoneità sealed e autorità di rilascio del prodotto sono registri separati.
    Cosa sostiene
    r14 è stato KEEP in train (sei unità di task, un tentativo ciascuna, nessuna autorità di promozione), ma il suo verdetto sealed separato è stato REJECT (nessuna autorità di promozione nel prodotto né di rilascio). r35 è INVALID per copertura incompleta e contaminazione dell’infrastruttura; senza righe appaiate la sua media resta null. Non si tratta né di automodifica del runtime né di una catena di deployment SIL → Crucible.
  3. July 21, 2026 · July 31, 2026Raffinamento · pubblicazione

    I registri rimasti sono stati classificati, e solo ciò che si può condividere è diventato una release immutabile

    DomandaChe cosa si può davvero ricostruire, e che cosa si può condividere in sicurezza?

    1. Fonte privataRegistro di sessione · prove originalirisultato native · verifier incluso
      • verso Eventi normalizzatipreservare ordine · identità
    2. Eventi normalizzatiidentità · ordine · coppie chiamata-risultato
      • verso Candidato pubblicoallowlist · oscurare · digest
    3. Candidato pubblicoin revisione
      • verso Controlli di integrità · privacycontrollare
    4. Controlli di integrità · privacyappaiamento · genealogia · ambito
      • verso Release immutabilesolo byte revisionati
    5. Repository pubblicoRelease immutabilemanifest · risultati native referenziati per digest
      • verso Rilettura remotaverificare l’hash
    6. Rilettura remotaSHA-256 fissato
    Dall’esecuzione originale si costruiscono eventi che preservano ordine e identificatori, e i contenuti sensibili del candidato pubblico vengono rimossi o sostituiti da hash. Dopo il controllo delle coppie chiamata-risultato, dell’ambito e della genealogia, i file approvati e il manifest vengono pubblicati come release immutabile e gli hash remoti vengono controllati di nuovo.
    Cosa è cambiato
    L’inventory del July 21, 2026 ha classificato per fonte i registri di dialogo, strumenti, ricerca e verdetti, e i duplicati della stessa fonte non sono stati contati come esempi indipendenti. Dal July 31, 2026, geode.trajectory@1 e geode.trajectory-release@1 rendono espliciti identità, ordine degli eventi, coppie chiamata-risultato, integrità di ambito e di replay, e manifest legati al contenuto. Le copie pubbliche trasformate e gli originali mantengono digest separati.
    Cosa sostiene
    Raffinamento qui significa normalizzazione, correlazione, oscuramento esplicito, genealogia e ammissione alla pubblicazione. Non ricostruisce ragionamenti nascosti né dichiara un dataset pronto per l’addestramento. Un ambito completo non è un replay completo dei byte quando i contenuti privati sono sostituiti da digest.
  4. August 25, 2026Learning view

    Un rollout e le sue prove sono stati legati tramite identificatori

    DomandaQuale input, quale tentativo, quale sequenza di eventi e quale ricompensa vanno insieme?

    geode.eval-learning-view@2 · uniti tramite ID e digest verificati, non un ordine causale

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

    La ricompensa appartiene alle receipt del verifier native. Le ripetizioni per l’infrastruttura sono tentativi all’interno di un solo rollout.

    Cosa è cambiato
    Le traiettorie immutabili vengono riusate tramite join con ambito definito, e le ricompense restano etichette derivate di proprietà del valutatore. Le ripetizioni per l’infrastruttura non aggiungono rollout. Uno 0 osservato viene conservato e una ricompensa mancante è null; i tentativi invalidi o interrotti sono esclusi dalla selezione della ricompensa. La validità è una proprietà del rollout e non implica automaticamente una ricompensa null.
    Cosa sostiene
    Un’esecuzione Terminal-Bench fast-3 con Harbor 0.8.0 (tre task, 3/3) e una diagnostica Tau2 su tre domini (1/3, due zeri validi) sono legate nella stessa struttura. Sono candidati per il post-training, non dataset usati per l’addestramento né prove di pesi migliorati, e un risultato su tre task non è l’accuratezza della suite.
  5. August 27, 2026 to September 5, 2026Harbor · Terminal-Bench 2.1

    Un trial ha prodotto separatamente il risultato e il registro di replay

    DomandaCome si passa dall’esecuzione reale di un task a un risultato e a un replay ispezionabile?

    1. Task congelato · specfissato in anticipo · cinque ripetizioni
      • verso Trial isolatoistruzioni · ambiente · limiti
    2. Trial Harbor 0.22.0 · esecuzione realeTrial isolatoGEODE come actor
      • verso Azioni e stato finaleeseguire
    3. Azioni e stato finalecomportamento osservato
      • verso Verifier del taskcontrollare lo stato del task
      • verso ATIF · proiezione in eventi pubbliciproiettare gli eventi registrati
    4. Verifier del task
      • verso Ricompensa native · receiptricompensa
    5. Ricompensa native · receipt
      • verso Analisi del tentativo selezionatoselezione congelata
    6. ATIF · proiezione in eventi pubblicipost-elaborazione · non una nuova esecuzione
    7. Analisi del tentativo selezionatoregola di selezione congelata
    Un task e una spec congelati danno a un trial isolato istruzioni, ambiente e limiti; il verifier del task controlla lo stato lasciato da GEODE e produce la ricompensa. L’analisi usa solo il tentativo scelto da una regola congelata. Gli eventi registrati nella stessa esecuzione sono proiettati separatamente in ATIF e in eventi pubblici: è post-elaborazione, non una nuova esecuzione.
    Cosa è cambiato
    La spec congelata, ogni tentativo, il risultato selezionato, il verifier del task e un replay fedele ma di portata limitata sono conservati come registri separati e collegati. Harbor 0.22.0 ha eseguito cinque ripetizioni con GPT-5.6 Sol/max, confrontando GEODE (allora un adattatore con un solo strumento terminale) con Codex.
    Cosa sostiene
    Un task comprende istruzioni, ambiente e test; un trial è un tentativo; un job raggruppa i trial. Il verifier del task decide la ricompensa, e il giudizio interno di completamento di GEODE è un feedback del runtime. Il replay pubblico è una proiezione post hoc degli eventi degli strumenti registrati, non un PTY grezzo né una nuova esecuzione, e per le celle mancanti non sono stati inventati comandi. Il confronto primario preregistrato non è stato misurabile.
  6. September 24, 2026 to September 28, 2026Jev · delega delle decisioni

    Anche un candidato corretto richiede la verifica della consegna

    DomandaUn giudizio delegato preserva davvero la qualità del task e la consegna finale?

    1. U8n · esecuzione Noul · Harbor 0.22 · Astra esegue e ripara, cambia solo il percorso di giudizioStato di decisionecontratto del task · candidato · osservazioni degli strumenti
      • verso Giudizio · Noulinput del giudizio
    2. Giudizio · NoulAstra o Jev
      • verso GEODE usa il giudizioprobabilità per condizione
    3. GEODE usa il giudiziosoddisfatto: consegnare; prove mancanti: trattenere
      • verso Consegna finalesoddisfatto
      • verso Riparazione di Astraprove mancanti · trattenere
    4. Consegna finale
      • verso Controllo indipendente dell’esitorisultato consegnato
    5. Riparazione di Astracandidato successivo dopo il feedback
      • verso Giudizio · Noulgiudicare di nuovo
      • verso Ultimo candidato · conservatoultimo candidato conservato
    6. Controllo indipendente dell’esitooracle a regole · risultato consegnato
    7. Pannelli fissi U3solo giudizi · niente actor, strumenti né Harbor
    8. Diagnosi post hoc · dopo l’esecuzioneUltimo candidato · conservato
      • verso Diagnosi post hoc con oraclecontrollo post hoc
    9. Diagnosi post hoc con oraclecorrettezza del candidato · nessun effetto sulla consegna
    Nell’esecuzione reale lo stato di decisione va a un giudizio; GEODE lo usa e consegna quando le condizioni sono soddisfatte; con prove mancanti trattiene il risultato mentre Astra ripara e il giudizio viene ripetuto. Un oracle a regole indipendente verifica il risultato consegnato. A parte, dopo l’esecuzione, l’ultimo candidato conservato è stato diagnosticato con un oracle post hoc; quella diagnosi non ha alcun effetto sulla consegna. I pannelli fissi U3 sono un esperimento separato che confronta solo i giudizi, senza actor, strumenti né Harbor.
    Cosa è cambiato
    Accettazione del giudizio, correttezza del candidato e consegna finale sono registrate come esiti separati, e le genealogie di preparazione, fallimento e riparazione sono conservate nella copia pubblica. Gli hash originali e quelli pubblici trasformati restano separati.
    Cosa sostiene
    Nelle 11 coppie post hoc dello studio U8n interrotto, l’ultimo candidato era corretto in entrambi i bracci, eppure la consegna è stata Astra 11/11 e Jev Noul 0/11: il giudizio di Jev Noul per mancanza di prove ha trattenuto la consegna. È un’analisi post hoc e non viene generalizzata. Ricalcolo pubblico dei valori, ispezione del replay e nuova esecuzione dal vivo sono tre operazioni diverse.