NO
Geodi, GEODEs offisielle pikselfigur
Tilbake til salen

GEODE

Autonomous Agent Harness

Fra observasjon til neste handling.

En lokal harness for autonome agenter, som research, filarbeid og planlagte oppgaver kan overlates til.

2026.02.21 — present

Design, vurdering, verifisering: Author · implementering: Claude · gjennomgang: Codex

  • CLIPublisert · PyPI
  • MCP-serverImplementert

Modellens forslag om å stoppe blir fullføring bare gjennom verifisering.

Ved et leverbart stopp går en modell som ber om å stoppe, likevel gjennom fullføringsverifisering. Utfallet er ferdig, fortsett innenfor budsjett eller venter på gjennomgang; utførelsesgrenser, avbrudd og feil ender i en egen stoppet tilstand.

Fullføringskart · tegnet ut fra kodestiene ved fastlåst commit 9e2c041
GEODEs fullføringskartHvordan en modells forslag om å stoppe blir en fullføring. Bare leverbare stopp (natural, forced_text, actionable_partial) går gjennom PreVerify-hooken, en strukturell kontroll og den valgte bedømmeren (LLM judge som standard, Jev når den velges) samt PostVerify- og Stop-hooks. Et bestått resultat lagres som completed; en feil som kan repareres, fortsetter den samme forespørselen innenfor et standardbudsjett på to forsøk. En ubrukelig dom, et forsøk på å gjøre en feil om til bestått eller et oppbrukt budsjett holder tilbake kandidaten og setter sesjonen på pause. Stopp ved avbrudd, grenser og infrastruktur samt kjøringer i control workflow lagres uten verifisering.IPC · CLI-kallersvar · sesjonstilstandEkstern reviewerpending · ikke kontaktetBedømmermodellLLM judge · Jev Choiceipc_server/poller.pycontrol workflow · hopp over offentlig verifiseringloop/agent_loop.pyarun · modelltur_arun_once · fortsatt reparasjonloop/_guards.py · models.pyleverbart stopp · natural osv.stopp ved feil · grense · avbruddloop/_lifecycle.pyfinalize_and_return_asyncpolicy_action · tolkning av dommenfortsettelsesbudsjett · standard 2core/hooks/public.pyPreVerify · STRENGTHENPostVerify · ACCEPT · REVISE · ESCALATEStop · CONTINUEmemory · observabilitycheckpoint · sesjonstilstandtimeline · beslutningsrader i ledgercore/agent/verify.pystrukturell kontroll · empty_turnsemantisk vurdering · LLM eller Jevverification_error · lukker ved feilGEODEs runtime-prosessslutten av én AgenticLoop-turløkke · stoppkandidaterfinalisering · dom1 stoppforslag · arun · modelltur → leverbart stopp · natural osv.12fullføringskandidat3 PreVerify · finalize_and_return_async → PreVerify · STRENGTHEN34verify_turn_async5vurderingsforespørsel6passed · rubric_misses7 PostVerify-beslutning · policy_action · tolkning av dommen → PostVerify · ACCEPT · REVISE · ESCALATE78Stop · CONTINUE9completed · lagret10svar1passed · rubric_misses2 PostVerify-beslutning · policy_action · tolkning av dommen → PostVerify · ACCEPT · REVISE · ESCALATE23Stop · CONTINUE4reparasjon · forsøk +11verification_error2 PostVerify-beslutning · policy_action · tolkning av dommen → PostVerify · ACCEPT · REVISE · ESCALATE23ESCALATE · pending4dom · beleggrader1 guards · grenser · arun · modelltur → stopp ved feil · grense · avbrudd12stopp ved feil · avbrudd3hopp over offentlig verifisering4bare lagring · ingen verifisering5svar

Verifiser → fullfør

Bare et leverbart stopp går gjennom PreVerify → vurdering → PostVerify → Stop. Verken modellens stoppforslag eller en hook-instruks er i seg selv en fullføring.

  1. arun · modellturloop/agent_loop.pystoppforslagleverbart stopp · natural osv.loop/_guards.py · models.py

    Når modellen svarer med tekst uten et verktøykall, blir turen en natural-stoppkandidat (forced_text i den siste tillatte runden). En modells stoppforslag er ennå ikke en fullføring.

  2. leverbart stopp · natural osv.loop/_guards.py · models.pyfullføringskandidatfinalize_and_return_asyncloop/_lifecycle.py

    Bare natural, forced_text og actionable_partial er leverbare stopp, og bare disse går videre til offentlig verifisering.

  3. finalize_and_return_asyncloop/_lifecycle.pyPreVerifyPreVerify · STRENGTHENcore/hooks/public.py

    Med STRENGTHEN kan PreVerify-hooken bare legge til krav og mangelkoder. Den kan gjøre dommen strengere, aldri gi bestått.

  4. finalize_and_return_asyncloop/_lifecycle.pyverify_turn_asyncstrukturell kontroll · empty_turncore/agent/verify.py

    En strukturell kontroll kommer først (tom tur, model_action_required); en strukturell feil som ikke kan repareres, hopper over den semantiske vurderingen. Gamle innstillinger som off eller rule_based tolkes som llm_judge og kan ikke slå av dommen.

  5. semantisk vurdering · LLM eller Jevcore/agent/verify.pyvurderingsforespørselBedømmermodell

    Den valgte bedømmeren (LLM judge som standard, Jev Choice når den velges) kalles én gang, uten verktøy, i høyst 120 sekunder og aldri utover det gjenværende tidsbudsjettet. En kandidat som kan inneholde personlige observasjoner, sendes ikke til en hjelpebedømmer.

  6. semantisk vurdering · LLM eller Jevcore/agent/verify.pypassed · rubric_missespolicy_action · tolkning av dommenloop/_lifecycle.py

    Dommen inneholder bestått eller ikke bestått, mangelkoder, en refleksjon til neste forsøk og om et nytt forsøk er nyttig. Et semantisk bestått dekker aldri over en mislykket strukturell kontroll.

  7. policy_action · tolkning av dommenloop/_lifecycle.pyPostVerify-beslutningPostVerify · ACCEPT · REVISE · ESCALATEcore/hooks/public.py

    PostVerify-hooken avgjør ACCEPT, REVISE eller ESCALATE. En ACCEPT av en kandidat som ikke besto verifiseringen, blir escalate. Uten beslutning gjelder runtimens standard (bestått → accept, kan prøves på nytt → revise, ellers escalate).

  8. policy_action · tolkning av dommenloop/_lifecycle.pyStop · CONTINUEStop · CONTINUEcore/hooks/public.py

    Bare når det ikke eskaleres, kan Stop-hookens CONTINUE-instruks be om fortsatt reparasjon. En hook-instruks er input til neste forsøk, ikke en autoritet.

  9. policy_action · tolkning av dommenloop/_lifecycle.pycompleted · lagretcheckpoint · sesjonstilstandmemory · observability

    Ved bestått og accept slås de fortsatte forsøkene sammen, resultatet lagres, og sesjonen registreres som completed.

  10. finalize_and_return_asyncloop/_lifecycle.pysvarIPC · CLI-kaller

    Returnerer det endelige svaret ved completed; et tomt svar med EXTERNAL_VERIFICATION_REQUIRED ved venting på gjennomgang; stoppårsaken ved et stopp uten verifisering.

Reparasjon innenfor budsjett

En feil som kan repareres, fortsetter den samme forespørselen. Standardbudsjettet er to forsøk; når det er brukt opp, venter kandidaten på gjennomgang.

  1. semantisk vurdering · LLM eller Jevcore/agent/verify.pypassed · rubric_missespolicy_action · tolkning av dommenloop/_lifecycle.py

    Dommen inneholder bestått eller ikke bestått, mangelkoder, en refleksjon til neste forsøk og om et nytt forsøk er nyttig. Et semantisk bestått dekker aldri over en mislykket strukturell kontroll.

  2. policy_action · tolkning av dommenloop/_lifecycle.pyPostVerify-beslutningPostVerify · ACCEPT · REVISE · ESCALATEcore/hooks/public.py

    PostVerify-hooken avgjør ACCEPT, REVISE eller ESCALATE. En ACCEPT av en kandidat som ikke besto verifiseringen, blir escalate. Uten beslutning gjelder runtimens standard (bestått → accept, kan prøves på nytt → revise, ellers escalate).

  3. policy_action · tolkning av dommenloop/_lifecycle.pyStop · CONTINUEStop · CONTINUEcore/hooks/public.py

    Bare når det ikke eskaleres, kan Stop-hookens CONTINUE-instruks be om fortsatt reparasjon. En hook-instruks er input til neste forsøk, ikke en autoritet.

  4. fortsettelsesbudsjett · standard 2loop/_lifecycle.pyreparasjon · forsøk +1_arun_once · fortsatt reparasjonloop/agent_loop.py

    Med en reparasjonsinstruks, og bare så lenge forsøksnummeret er under budsjettet (to som standard), fortsetter den samme forespørselen. Ved budsjettet blir det escalate_budget_exhausted og venter på gjennomgang.

Venter på gjennomgang

En ubrukelig dom, et forsøk på å gjøre en feil om til bestått eller et oppbrukt budsjett holder tilbake kandidaten og setter sesjonen på pause.

  1. verification_error · lukker ved feilcore/agent/verify.pyverification_errorpolicy_action · tolkning av dommenloop/_lifecycle.py

    En manglende bedømmer, et tidsavbrudd eller et ugyldig svar blir verification_error: verken bestått eller et reparasjonssignal. En ubrukelig dom erstatter aldri et vellykket utfall.

  2. policy_action · tolkning av dommenloop/_lifecycle.pyPostVerify-beslutningPostVerify · ACCEPT · REVISE · ESCALATEcore/hooks/public.py

    PostVerify-hooken avgjør ACCEPT, REVISE eller ESCALATE. En ACCEPT av en kandidat som ikke besto verifiseringen, blir escalate. Uten beslutning gjelder runtimens standard (bestått → accept, kan prøves på nytt → revise, ellers escalate).

  3. policy_action · tolkning av dommenloop/_lifecycle.pyESCALATE · pendingEkstern reviewer

    Kandidaten beholdes som pending_text og holdes tilbake fra vanlige svar, checkpointet lagres, og sesjonen settes på pause. Ingen ekstern reviewer kontaktes automatisk.

  4. policy_action · tolkning av dommenloop/_lifecycle.pydom · beleggradertimeline · beslutningsrader i ledgermemory · observability

    Tidslinjen får beslutnings-, belegg- og pending-rader, og evidence ledger en verification_policy-rad. Dette er best-effort-logger, ikke bevis for en ekstern effekt.

Stopp uten verifisering

Stopp ved avbrudd, grenser og infrastruktur samt kjøringer i control workflow lagres uten offentlig verifisering.

  1. arun · modellturloop/agent_loop.pyguards · grenserstopp ved feil · grense · avbruddloop/_guards.py · models.py

    Guards som grenser for runder, tid, kostnad og kontekst, avbrudd og oppdagelse av gjentatte feil avslutter turen med ett medlem av den lukkede TerminationReason-mengden. En grense som er slått av i konfigurasjonen, håndheves ikke alltid.

  2. stopp ved feil · grense · avbruddloop/_guards.py · models.pystopp ved feil · avbruddfinalize_and_return_asyncloop/_lifecycle.py

    Stopp ved avbrudd, infrastruktur og grenser har ingen kandidat å verifisere og lagres derfor uten offentlig verifisering.

  3. control workflow · hopp over offentlig verifiseringipc_server/poller.pyhopp over offentlig verifiseringfinalize_and_return_asyncloop/_lifecycle.py

    Når et IPC-kall ber om å hoppe over offentlig verifisering eller en control workflow er aktiv, er offentlig verifisering slått av bare for den kjøringen, og den tidligere verdien gjenopprettes etterpå.

  4. finalize_and_return_asyncloop/_lifecycle.pybare lagring · ingen verifiseringcheckpoint · sesjonstilstandmemory · observability

    Et stopp uten verifisering lagrer likevel resultatet og checkpointet og sender ut hendelsene for sesjonsslutt.

  5. finalize_and_return_asyncloop/_lifecycle.pysvarIPC · CLI-kaller

    Returnerer det endelige svaret ved completed; et tomt svar med EXTERNAL_VERIFICATION_REQUIRED ved venting på gjennomgang; stoppårsaken ved et stopp uten verifisering.

Alle forbindelser med samme tykkelse. Velg en flyt for å fremheve bare dens vei, med nummererte steg.

  • Heltrukket · retningen forespørsler, kandidater og resultater flyter
  • Stiplet · kjøre, avgjøre, autorisere, konfigurere
  • Lang strek-prikk · logger og observasjon, atskilt fra dommen
  • Kort strek · en feil eller en ubrukelig dom
  • Kraftig svart linje · den valgte flyten; tallene angir rekkefølgen
  • Boks · en kode- eller logggrense, stien i overskriften
  • Indre chip · en komponent innenfor grensen
  • Stiplet boks · utenfor grensen
  • løkke · finalisering
  • stopp · hooks · dom
  • lagring · logger
  • IPC-inngang

Bare kallstier i fastlåst commit 9e2c041 er tegnet. En bedømmers bestått er atskilt fra en ekstern benchmark-verifikators suksess; fullføring er her en beslutning inne i runtimen.

Vurderingsmotor
Standarden er LLM judge; Jev Choice vurderer bare når judgment_engine er satt til jev. Uansett gir en ubrukelig bedømmer verification_error, aldri suksess.
Hva hooks kan gjøre
PreVerify kan bare gjøre dommen strengere, PostVerify kan ikke la en mislykket kandidat bestå, og Stop kan bare be om fortsettelse når det ikke eskaleres.
Venter på gjennomgang
Venter på gjennomgang registrerer at det trengs en ekstern beslutning. Det varsler ingen og betyr ikke at resultatet er godkjent.