IT
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

Gli scenari di audit nascono da fasi in un ordine fisso.

L’host detiene l’ordine delle fasi, e in ogni fase gli agenti di ruolo si dividono il lavoro. Il pool di seed risultante e la rubrica scelta diventano input dell’audit comportamentale Petri.

Mappa dei seed · disegnata dai percorsi evals al commit fissato 9e2c041
Generazione di scenari di audit e audit Petri di GEODECome si scrivono e si sottopongono ad audit gli scenari di audit (seed). L’orchestratore seed_generation detiene l’ordine delle fasi mentre gli agenti di ruolo redigono, revisionano e migliorano, e il risultato viene esportato come directory survivors e file di meta-review. Un audit Petri riceve una selezione di seed e assegna tre ruoli di modello separati: l’auditor interpreta lo scenario del seed, il target è l’intero scaffold di GEODE e il judge valuta il transcript per dimensione in un log di Inspect. La misura SIL legge quel risultato, e una misura mantenuta diventa prova di baseline per la generazione successiva.Modello auditorinterpreta lo scenario del seedModello base del targetil modello che GEODE avvolgeModello judgevaluta l’intero transcriptLog .eval di Inspectarchivio · riepilogoMisura SIL · measure.pyletto dal capitolo «Ricerca di policy»baseline snapshotmedie per dimensione · provehandoff pointerlatest_pointer.json · priorsseed_generation/orchestrator.pyordine delle fasi · PipelineStatecheckpoint · resumeagents/ · bozzaSupervisor · strategia di esecuzioneliterature_review · disattivato di defaultGenerator · seed candidatiagents/ · revisioneProximity · deduplicazioneCritic · revisionePilot · opzionale · non in smokeRanker · Eloagents/ · miglioramentoEvolver · miglioramentoMeta-reviewer · priors successivirun_dir/survivors/ · copie .md dei candidatisurvivors.json · Elo · pilotmeta_review.json · state.jsonpetri/seedsseed inclusi · *.mdpetri/runner.pygeode audit · /audit · strumentostima dei costi · dry-run di defaultpetri/geode_target.pyGEODE come target · AgenticLooppetri/judge_dimsjudge_dimensions · YAMLfile di stato fuori da un’esecuzioneevals/seed_generationstesura degli scenarievals/petriesecuzione dell’audit1eseguire le fasi in ordine2prove di baseline3 meta-review precedente · latest_pointer.json · priors → agents/ · bozza34 seed candidati · agents/ · bozza → agents/ · revisione45survivors · Elo6 iterazione successiva · da Critic · Meta-reviewer · priors successivi → Critic · revisione67 esportazione dei survivors · agents/ · miglioramento → run_dir/78puntatore latest1--seed-select2seed inclusi3 ruoli di modello · tre posti · geode audit · /audit · strumento → Modello auditor34dialogo dello scenario del seed5 chiamate al modello · GEODE come target · AgenticLoop → Modello base del target56transcript7 judge_dimensions · judge_dimensions · YAML → Modello judge78punteggi per dimensione1punteggi per dimensione2 misura · Log .eval di Inspect → Misura SIL · measure.py23aggiornamento della baseline4prove di baseline

Stesura degli scenari

L’orchestratore detiene l’ordine delle fasi, gli agenti di ruolo redigono e filtrano i candidati, e il risultato viene esportato tramite un contratto su file.

  1. ordine delle fasi · PipelineStateseed_generation/orchestrator.pyeseguire le fasi in ordineagents/ · bozza

    L’orchestratore detiene l’ordine delle fasi e l’unione dello stato; l’agente di ruolo di ciascuna fase svolge il lavoro. All’interno di una fase il lavoro può essere distribuito tramite SubAgentManager, e i sub-agenti non scendono oltre (depth 1).

  2. medie per dimensione · provebaseline snapshotprove di baselineagents/ · bozza

    Generator, Critic ed Evolver leggono medie, errori standard e prove per dimensione della baseline selezionata. La prima generazione non ha baseline e usa i prompt predefiniti.

  3. latest_pointer.json · priorshandoff pointermeta-review precedenteagents/ · bozza

    La meta-review dell’esecuzione precedente lascia priors per la generazione successiva e dimensioni poco coperte, che questa generazione prende in considerazione.

  4. agents/ · bozzaseed candidatiagents/ · revisione

    I candidati di Generator passano in ordine per la deduplicazione di Proximity, la revisione di Critic, Pilot (opzionale; saltato nelle esecuzioni smoke) e la classifica Elo di Ranker.

  5. agents/ · revisionesurvivors · Eloagents/ · miglioramento

    Evolver migliora i candidati meglio classificati, e Meta-reviewer riassume l’esecuzione in priors per la generazione successiva.

  6. Meta-reviewer · priors successiviagents/ · miglioramentoiterazione successiva · da CriticCritic · revisioneagents/ · revisione

    Con max_iterations impostato, dopo Meta-reviewer i candidati migliorati ripassano per Critic → Pilot → Ranker → Evolver → Meta-reviewer. Supervisor, Generator e Proximity non vengono rieseguiti; il predefinito è zero iterazioni.

  7. agents/ · miglioramentoesportazione dei survivorsrun_dir/

    I testi dei candidati sopravvissuti vengono copiati come file in survivors/, i punteggi Elo e pilot vanno in survivors.json, e meta-review e stato vengono scritti separatamente.

  8. meta_review.json · state.jsonrun_dir/puntatore latestlatest_pointer.json · priorshandoff pointer

    Un unico latest_pointer.json registra dove si trovano seed_pool e meta_review di questa esecuzione. Gli output per esecuzione sono canonici; il puntatore è un aiuto best-effort per l’esecuzione successiva, e una scrittura fallita viene solo registrata nel log. Non ogni esecuzione ha entrambi i campi.

Esecuzione dell’audit

L’auditor interpreta il seed (un’istruzione di scenario), il target è lo scaffold di GEODE e il judge valuta il transcript. I tre ruoli sono posti di modello separati.

  1. survivors/ · copie .md dei candidatirun_dir/--seed-selectgeode audit · /audit · strumentopetri/runner.py

    Un audit riceve una selezione di seed (una directory survivors, seed inclusi, id o tag) e la passa al task inspect_petri/audit di Inspect. La generazione dei seed non avvia da sé un audit.

  2. seed inclusi · *.mdpetri/seedsseed inclusigeode audit · /audit · strumentopetri/runner.py

    I seed inclusi nel repository possono essere selezionati così come sono.

  3. geode audit · /audit · strumentopetri/runner.pyruoli di modello · tre postiModello auditor

    I modelli auditor, target e judge si impostano separatamente. Il predefinito è un dry-run; le chiamate reali avvengono solo dopo la conferma di una stima dei costi. Quando tutti e tre i ruoli condividono un provider, viene aggiunto un indicatore di bias da stesso provider.

  4. Modello auditordialogo dello scenario del seedGEODE come target · AgenticLooppetri/geode_target.py

    Un seed è un’istruzione di scenario per l’auditor. L’auditor conduce la conversazione e può creare strumenti e risultati degli strumenti solo se target_tools è abilitato.

  5. GEODE come target · AgenticLooppetri/geode_target.pychiamate al modelloModello base del target

    L’intero AgenticLoop di GEODE (strumenti, hook, memoria) viene avvolto come un’unica API di modello, quindi il target dell’audit è lo scaffold di GEODE, non il solo modello base.

  6. GEODE come target · AgenticLooppetri/geode_target.pytranscriptModello judge

    Il judge legge una volta il transcript completo di ogni campione e lo valuta per dimensione.

  7. judge_dimensions · YAMLpetri/judge_dimsjudge_dimensionsModello judge

    Lo YAML delle dimensioni del judge selezionato stabilisce le dimensioni di valutazione. È un audit comportamentale, una misura diversa dal completamento dei task.

  8. Modello judgepunteggi per dimensioneLog .eval di Inspect

    Il log .eval di Inspect e un riepilogo vengono archiviati. Un fallimento dell’archiviazione viene annotato e non blocca il risultato dell’audit.

Misura → generazione successiva

SIL usa i punteggi dell’audit per il suo verdetto, e una misura mantenuta diventa prova di baseline per la generazione successiva dei seed. Ciò non significa che il collegamento sia stato eseguito automaticamente in ogni campagna.

  1. Modello judgepunteggi per dimensioneLog .eval di Inspect

    Il log .eval di Inspect e un riepilogo vengono archiviati. Un fallimento dell’archiviazione viene annotato e non blocca il risultato dell’audit.

  2. Log .eval di InspectmisuraMisura SIL · measure.py

    measure.py di SIL esegue il sottoprocesso di audit e calcola la fitness dal suo risultato.

  3. Misura SIL · measure.pyaggiornamento della baselinemedie per dimensione · provebaseline snapshot

    Il ledger di SIL scrive una misura mantenuta come baseline. La generazione dei seed legge quelle prove quando una baseline è selezionata (automaticamente o esplicitamente).

  4. medie per dimensione · provebaseline snapshotprove di baselineagents/ · bozza

    Generator, Critic ed Evolver leggono medie, errori standard e prove per dimensione della baseline selezionata. La prima generazione non ha baseline e usa i prompt predefiniti.

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
  • Tratto lungo e punto · registri e osservazione, separati dal verdetto
  • 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
  • orchestratore · ingresso dell’audit
  • target dell’audit · dimensioni di valutazione
  • output · file di stato
  • agenti di ruolo · seed inclusi

L’orchestratore fissa l’ordine del primo passaggio e quello della ripetizione. Configurazione, ruoli registrati e punto di ripresa possono saltare alcune fasi, e non ogni campagna ha eseguito ogni fase. La posizione dei file di stato dipende dall’ambiente, quindi non sono indicati percorsi.

Tre ruoli
Un seed è un’istruzione di scenario, scritta da una persona o generata; l’auditor è il modello che la interpreta, il target è lo scaffold di GEODE sottoposto ad audit e il judge è il modello che valuta il transcript. Punteggi e log sono output del judge.
Cosa si misura
Un audit Petri assegna punteggi a dimensioni comportamentali. Non è un tasso di completamento dei task né una garanzia di qualità del prodotto.