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

L’accettazione dei candidati e l’autorità di rilascio sono giudizi separati.

Crucible è un kernel sperimentale separato dalla ricerca di policy. Un commit candidato viene validato rispetto alle superfici consentite e a un contratto congelato, i task appaiati vengono aggregati in un checkout di misura separato, e il risultato è KEEP, REJECT o INVALID.

Mappa di Crucible · disegnata dal commit fissato 9e2c041 e dagli artefatti pubblici 23e3428
Mappa di Crucible di GEODEUn kernel sperimentale che tiene accettazione dei candidati, idoneità sealed e rilascio del prodotto come autorità separate. Il supervisor riceve un commit candidato da un produttore, lo controlla rispetto alla superficie consentita e al frozen evaluator, ed esegue task tau2 in un checkout di misura isolato. promotion.py aggrega i risultati appaiati per task e family preregistrati in KEEP, REJECT o INVALID; KEEP sposta solo l’head di ricerca. La valutazione sealed giudica un train bundle su un disjoint test pack usato una sola volta; anche ELIGIBLE arriva solo a un eligible ref, senza autorità di rilascio.Modelli actor · userr14 · r35: gpt-5.4/highAmbiente tau2task · utente simulatoRilascio del prodotto GEODEnessuna connessione · autorità separatasearch/producerscomando del produttore · configuratoreplay producersearch/supervisor.pypropose → preflightevaluate → decide → recordcontract.pysuperficie consentita · candidate difffrozen evaluator · preregistratoattempt/feedback.jsoncodici di fallimento · ID dei task trainmeasurement checkoutisolato dal produttoreassays/esecuzione tau2 · receiptverifier dei taskpromotion.pyaggregato paired · task · familyKEEP · REJECT · INVALIDattestation/bundle.pytrain bundle · KEEP ricalcolatoattestation/sealed.pydisjoint test pack · usato una voltaELIGIBLE · release_authority nonerefs/cruciblesearch/* headeligible/*geode-eval-artifactsr14 · train KEEP → sealed REJECTr35 · INVALID · 0 coppie · nullevolve/cruciblekernel sperimentale esterno · separato da SILsearch · verdetto trainattestation · sealed1 richiedere un candidato · propose → preflight → search/producers12 un commit candidato · search/producers → propose → preflight23 superficie consentita · controllo del diff · propose → preflight → superficie consentita · candidate diff34checkout isolato5esecuzione con contratto fisso6dialogo actor · utente7chiamate al modello8paired evidence9aggregazione preregistrata10KEEP · l’head avanza1paired evidence2aggregazione preregistrata3REJECT · INVALID4codici di fallimento · ID dei task1record · ref receipt2 solo train bundle · una volta · train bundle · KEEP ricalcolato → disjoint test pack · usato una volta23 solo eligible ref · ELIGIBLE · release_authority none → eligible/*31verdict.json pubblico2sealed decision.json

Verdetto train

Un candidato entro la superficie consentita viene misurato in un checkout isolato con un contratto fisso, e regole preregistrate decidono tra KEEP, REJECT e INVALID.

  1. propose → preflightsearch/supervisor.pyeseguire · decidere: richiedere un candidatosearch/producers

    Il supervisor di ricerca chiede un candidato a un produttore. Il candidato di r14 era un candidato precedente (r13) riapplicato dal replay producer, non uno nuovo generato da un LLM.

  2. search/producersdati: un commit candidatopropose → preflightsearch/supervisor.py

    Un produttore restituisce un singolo commit candidato entro i percorsi consentiti.

  3. propose → preflightsearch/supervisor.pyeseguire · decidere: superficie consentita · controllo del diffsuperficie consentita · candidate diffcontract.py

    Il candidate diff deve restare entro la superficie consentita dal contratto, e il frozen evaluator viene verificato. In r14 e r35 il bersaglio consentito era un solo file, tau2_agent_policy.md; core e l’implementazione di Crucible erano fissati come percorso dell’evaluator.

  4. evaluate → decide → recordsearch/supervisor.pyeseguire · decidere: checkout isolatoisolato dal produttoremeasurement checkout

    Il candidato viene controllato in un checkout di misura separato dal produttore.

  5. isolato dal produttoremeasurement checkouteseguire · decidere: esecuzione con contratto fissoesecuzione tau2 · receiptassays/

    Baseline e candidato girano con lo stesso contratto, lo stesso seed e gli stessi task.

  6. esecuzione tau2 · receiptassays/dati: dialogo actor · utenteAmbiente tau2

    L’agente GEODE (actor) dialoga, nell’ambiente dei task tau2, con l’utente simulato di proprietà dell’evaluator.

  7. esecuzione tau2 · receiptassays/dati: chiamate al modelloModelli actor · user

    In r14 e r35 sia l’actor sia l’utente simulato erano gpt-5.4/high (abbonamento).

  8. verifier dei taskassays/dati: paired evidenceaggregato paired · task · familypromotion.py

    I risultati del verifier dei task sono conservati come coppie baseline–candidato.

  9. frozen evaluator · preregistratocontract.pyeseguire · decidere: aggregazione preregistrataaggregato paired · task · familypromotion.py

    I risultati appaiati vengono aggregati per task e per family preregistrata, mentre budget, copertura, infrastruttura e condizioni di sicurezza si controllano separatamente.

  10. KEEP · REJECT · INVALIDpromotion.pyeseguire · decidere: KEEP · l’head avanzasearch/* headrefs/crucible

    Con KEEP il successivo head di refs/crucible/search/* diventa il candidato. La promotion_authority di un verdetto train è none.

Rifiuto · invalido · feedback

REJECT e INVALID mantengono l’head, e il candidato successivo riceve solo codici di fallimento e ID fissi dei task train. INVALID non è un punteggio pari a zero.

  1. verifier dei taskassays/dati: paired evidenceaggregato paired · task · familypromotion.py

    I risultati del verifier dei task sono conservati come coppie baseline–candidato.

  2. frozen evaluator · preregistratocontract.pyeseguire · decidere: aggregazione preregistrataaggregato paired · task · familypromotion.py

    I risultati appaiati vengono aggregati per task e per family preregistrata, mentre budget, copertura, infrastruttura e condizioni di sicurezza si controllano separatamente.

  3. KEEP · REJECT · INVALIDpromotion.pydati: REJECT · INVALIDcodici di fallimento · ID dei task trainattempt/feedback.json

    In caso di rifiuto o invalidità resta l’head precedente, e il candidato e i suoi registri vengono conservati. La media di un INVALID è null, non zero.

  4. codici di fallimento · ID dei task trainattempt/feedback.jsondati: codici di fallimento · ID dei tasksearch/producers

    Il feedback al candidato successivo è limitato a codici di fallimento e ID fissi dei task train; non vengono passate traiettorie né risposte dell’evaluator.

Idoneità sealed · autorità separata

Il KEEP di train sposta solo l’head di ricerca. L’idoneità sealed arriva solo all’eligible ref; rilascio del prodotto e deployment sono autorità separate al di fuori di Crucible.

  1. evaluate → decide → recordsearch/supervisor.pydati: record · ref receipttrain bundle · KEEP ricalcolatoattestation/bundle.py

    Un train bundle è valido solo se contratto, prove di baseline e candidato, il KEEP ricalcolato, la genealogia della proposta, il registro del supervisor e la receipt del ref applicato sono tutti collegati. Non è un altro nome per un miglioramento.

  2. train bundle · KEEP ricalcolatoattestation/bundle.pyeseguire · decidere: solo train bundle · una voltadisjoint test pack · usato una voltaattestation/sealed.py

    La valutazione sealed usa una sola volta un test pack disgiunto da train, con zero tentativi ripetuti per l’infrastruttura.

  3. ELIGIBLE · release_authority noneattestation/sealed.pyeseguire · decidere: solo eligible refeligible/*refs/crucible

    Anche ELIGIBLE scrive solo refs/crucible/eligible/*, e release_authority è fissato a none.

Registri pubblici · r14 · r35

r14 è stato train KEEP e poi sealed REJECT; r35 (July 13, 2026) è stato INVALID per copertura incompleta e contaminazione dell’infrastruttura (0 righe appaiate, media null), con l’head invariato.

  1. KEEP · REJECT · INVALIDpromotion.pydati: verdict.json pubblicogeode-eval-artifacts

    Gli artefatti pubblici sono registri normalizzati fissati a 23e3428. L’hash preregistrato della configurazione train di r14 differisce dai byte della configurazione pubblica, quindi l’intera catena originale non è stata ricertificata.

  2. attestation/sealed.pydati: sealed decision.jsonr14 · train KEEP → sealed REJECTgeode-eval-artifacts

    r14: KEEP su telecom train, 6 task × 1 tentativo (6 righe appaiate, nessuna autorità di promozione), poi un verdetto sealed separato di REJECT (nessuna autorità di rilascio).

Tutte le connessioni con lo stesso peso. Scegliendo un flusso se ne evidenzia solo il percorso, con passi numerati.

  • Continua · la direzione in cui scorrono richieste, candidati e risultati
  • Tratteggiata · eseguire, decidere, autorizzare, configurare
  • Linea nera spessa · il flusso scelto; i numeri danno l’ordine
  • Riquadro · un confine di codice o di registro, con il percorso nell’intestazione
  • Chip interno · un componente in quel confine
  • Riquadro tratteggiato · fuori da quel confine
  • supervisor di ricerca
  • contratto · verdetto · attestazione
  • ref · registri
  • produttori · esecuzione

Crucible è un kernel separato da SIL; le due ricerche non sono un’unica pipeline che promuove i candidati dell’altra. Il riquadro del rilascio del prodotto non ha connessioni in ingresso.

Tre autorità
Il KEEP di train sposta l’head di ricerca, un ELIGIBLE sealed registra un eligible ref, e il rilascio del prodotto è una decisione separata al di fuori di Crucible. Un verdetto precedente non concede mai un’autorità successiva.
null non è zero
r35 prevedeva 9 task × 3 tentativi (27 righe per braccio) ma ha avuto 0 coppie confrontabili, quindi media e miglioramento sono null. Non sono 27 task falliti né un tasso di successo dello 0%.