Geodi, die offizielle Pixelfigur von GEODE
Zurück zum Saal

GEODE

Autonomous Agent Harness

Von der Beobachtung zur nächsten Handlung.

Ein lokales Harness für autonome Agenten, dem sich Recherche, Dateiarbeit und geplante Aufgaben übergeben lassen.

2026.02.21 — present

Entwurf, Urteil, Verifikation: Author · Implementierung: Claude · Review: Codex

  • CLIVeröffentlicht · PyPI
  • MCP-ServerImplementiert

Der Stoppvorschlag des Modells wird erst durch Verifikation zum Abschluss.

Bei einem auslieferbaren Stopp durchläuft ein Modell, das stoppen will, trotzdem die Abschlussverifikation. Das Ergebnis lautet erledigt, Fortsetzung im Budget oder Warten auf Review; Ausführungslimits, Abbruch und Fehler enden in einem eigenen gestoppten Zustand.

Abschlusskarte · gezeichnet nach den Codepfaden im fixierten Commit 9e2c041
GEODE-AbschlusskarteWie der Stoppvorschlag eines Modells zum Abschluss wird. Nur auslieferbare Stopps (natural, forced_text, actionable_partial) durchlaufen den PreVerify-Hook, eine Strukturprüfung und die gewählte Bewertungsinstanz (standardmäßig LLM judge, Jev bei Auswahl) sowie die Hooks PostVerify und Stop. Ein Bestehen wird als completed gespeichert; ein nachbesserbarer Fehlschlag setzt dieselbe Anfrage innerhalb eines Standardbudgets von zwei Versuchen fort. Ein unbrauchbares Urteil, der Versuch, einen Fehlschlag in ein Bestehen umzuwandeln, oder ein aufgebrauchtes Budget hält den Kandidaten zurück und pausiert die Session. Stopps durch Abbruch, Limit und Infrastruktur sowie Läufe von control workflows werden ohne Verifikation gespeichert.IPC · CLI-AufruferAntwort · Session-ZustandExterner Reviewerpending · nicht kontaktiertBewertungsmodellLLM judge · Jev Choiceipc_server/poller.pycontrol workflow · öffentliche Verifikation auslassenloop/agent_loop.pyarun · Modell-Turn_arun_once · Fortsetzung zur Nachbesserungloop/_guards.py · models.pyauslieferbarer Stopp · natural usw.Stopp durch Fehlschlag · Limit · Abbruchloop/_lifecycle.pyfinalize_and_return_asyncpolicy_action · Lesen des Urteilscontinuation-Budget · Standard 2core/hooks/public.pyPreVerify · STRENGTHENPostVerify · ACCEPT · REVISE · ESCALATEStop · CONTINUEmemory · observabilityCheckpoint · Session-ZustandTimeline · ledger-Entscheidungszeilencore/agent/verify.pyStrukturprüfung · empty_turnsemantisches Urteil · LLM oder Jevverification_error · schlägt geschlossen fehlGEODE-Runtime-ProzessEnde eines AgenticLoop-TurnsSchleife · Stoppkandidatenfinalization · Urteil1 Stoppvorschlag · arun · Modell-Turn → auslieferbarer Stopp · natural usw.12Abschlusskandidat3 PreVerify · finalize_and_return_async → PreVerify · STRENGTHEN34verify_turn_async5Urteilsanfrage6passed · rubric_misses7 PostVerify-Entscheidung · policy_action · Lesen des Urteils → PostVerify · ACCEPT · REVISE · ESCALATE78Stop · CONTINUE9completed · gespeichert10Antwort1passed · rubric_misses2 PostVerify-Entscheidung · policy_action · Lesen des Urteils → PostVerify · ACCEPT · REVISE · ESCALATE23Stop · CONTINUE4Nachbesserung · Versuch +11verification_error2 PostVerify-Entscheidung · policy_action · Lesen des Urteils → PostVerify · ACCEPT · REVISE · ESCALATE23ESCALATE · pending4Urteil · Belegzeilen1 Guards · Limits · arun · Modell-Turn → Stopp durch Fehlschlag · Limit · Abbruch12Stopp durch Fehlschlag · Abbruch3öffentliche Verifikation auslassen4nur speichern · keine Verifikation5Antwort

Verifikation → Abschluss

Nur ein auslieferbarer Stopp durchläuft PreVerify → Urteil → PostVerify → Stop. Weder der Stoppvorschlag des Modells noch eine Hook-Anweisung ist für sich ein Abschluss.

  1. arun · Modell-Turnloop/agent_loop.pyDaten: Stoppvorschlagauslieferbarer Stopp · natural usw.loop/_guards.py · models.py

    Antwortet das Modell mit Text ohne Tool-Aufruf, wird der Turn zum Stoppkandidaten natural (forced_text in der letzten erlaubten Runde). Der Stoppvorschlag eines Modells ist noch kein Abschluss.

  2. auslieferbarer Stopp · natural usw.loop/_guards.py · models.pyDaten: Abschlusskandidatfinalize_and_return_asyncloop/_lifecycle.py

    Nur natural, forced_text und actionable_partial sind auslieferbare Stopps, und nur sie gehen weiter zur öffentlichen Verifikation.

  3. finalize_and_return_asyncloop/_lifecycle.pyAusführen · Entscheiden: PreVerifyPreVerify · STRENGTHENcore/hooks/public.py

    Mit STRENGTHEN kann der PreVerify-Hook nur Anforderungen und Miss-Codes hinzufügen. Er kann das Urteil verschärfen, es aber nie bestehen lassen.

  4. finalize_and_return_asyncloop/_lifecycle.pyAusführen · Entscheiden: verify_turn_asyncStrukturprüfung · empty_turncore/agent/verify.py

    Zuerst kommt eine Strukturprüfung (leerer Turn, model_action_required); ein nicht nachbesserbarer Strukturfehler überspringt das semantische Urteil. Alte Einstellungen wie off oder rule_based werden zu llm_judge aufgelöst und können das Urteil nicht abschalten.

  5. semantisches Urteil · LLM oder Jevcore/agent/verify.pyDaten: UrteilsanfrageBewertungsmodell

    Die gewählte Bewertungsinstanz (standardmäßig LLM judge, Jev Choice bei Auswahl) wird einmal aufgerufen, ohne Tools, für höchstens 120 Sekunden und nie über das verbleibende Zeitbudget hinaus. Ein Kandidat, der persönliche Beobachtungen enthalten kann, wird nicht an eine Hilfs-Bewertungsinstanz gesendet.

  6. semantisches Urteil · LLM oder Jevcore/agent/verify.pyDaten: passed · rubric_missespolicy_action · Lesen des Urteilsloop/_lifecycle.py

    Das Urteil enthält Bestehen oder Nichtbestehen, Miss-Codes, eine reflection für den nächsten Versuch und ob eine Wiederholung sinnvoll ist. Ein semantisches Bestehen überdeckt nie eine fehlgeschlagene Strukturprüfung.

  7. policy_action · Lesen des Urteilsloop/_lifecycle.pyAusführen · Entscheiden: PostVerify-EntscheidungPostVerify · ACCEPT · REVISE · ESCALATEcore/hooks/public.py

    Der PostVerify-Hook entscheidet zwischen ACCEPT, REVISE und ESCALATE. Ein ACCEPT für einen Kandidaten, der die Verifikation nicht bestanden hat, wird zu escalate. Ohne Entscheidung gilt der Runtime-Standard (Bestehen → accept, wiederholbar → revise, sonst escalate).

  8. policy_action · Lesen des Urteilsloop/_lifecycle.pyAusführen · Entscheiden: Stop · CONTINUEStop · CONTINUEcore/hooks/public.py

    Nur wenn nicht eskaliert wird, kann die CONTINUE-Anweisung des Stop-Hooks eine Fortsetzung zur Nachbesserung verlangen. Eine Hook-Anweisung ist Eingabe für den nächsten Versuch, keine Befugnis.

  9. policy_action · Lesen des Urteilsloop/_lifecycle.pyDaten: completed · gespeichertCheckpoint · Session-Zustandmemory · observability

    Bei Bestehen und accept werden fortgesetzte Versuche zusammengeführt, das Ergebnis wird gespeichert und die Session als completed aufgezeichnet.

  10. finalize_and_return_asyncloop/_lifecycle.pyDaten: AntwortIPC · CLI-Aufrufer

    Gibt bei Abschluss die endgültige Antwort zurück, beim Warten auf Review eine leere Antwort mit EXTERNAL_VERIFICATION_REQUIRED und bei einem Stopp ohne Verifikation den Stoppgrund.

Nachbesserung im Budget

Ein nachbesserbarer Fehlschlag setzt dieselbe Anfrage fort. Das Standardbudget beträgt zwei Versuche; ist es aufgebraucht, wartet der Kandidat auf Review.

  1. semantisches Urteil · LLM oder Jevcore/agent/verify.pyDaten: passed · rubric_missespolicy_action · Lesen des Urteilsloop/_lifecycle.py

    Das Urteil enthält Bestehen oder Nichtbestehen, Miss-Codes, eine reflection für den nächsten Versuch und ob eine Wiederholung sinnvoll ist. Ein semantisches Bestehen überdeckt nie eine fehlgeschlagene Strukturprüfung.

  2. policy_action · Lesen des Urteilsloop/_lifecycle.pyAusführen · Entscheiden: PostVerify-EntscheidungPostVerify · ACCEPT · REVISE · ESCALATEcore/hooks/public.py

    Der PostVerify-Hook entscheidet zwischen ACCEPT, REVISE und ESCALATE. Ein ACCEPT für einen Kandidaten, der die Verifikation nicht bestanden hat, wird zu escalate. Ohne Entscheidung gilt der Runtime-Standard (Bestehen → accept, wiederholbar → revise, sonst escalate).

  3. policy_action · Lesen des Urteilsloop/_lifecycle.pyAusführen · Entscheiden: Stop · CONTINUEStop · CONTINUEcore/hooks/public.py

    Nur wenn nicht eskaliert wird, kann die CONTINUE-Anweisung des Stop-Hooks eine Fortsetzung zur Nachbesserung verlangen. Eine Hook-Anweisung ist Eingabe für den nächsten Versuch, keine Befugnis.

  4. continuation-Budget · Standard 2loop/_lifecycle.pyAusführen · Entscheiden: Nachbesserung · Versuch +1_arun_once · Fortsetzung zur Nachbesserungloop/agent_loop.py

    Nur mit einer Nachbesserungsanweisung und solange die Versuchsnummer unter dem Budget liegt (standardmäßig zwei), wird dieselbe Anfrage fortgesetzt. Ist das Budget erreicht, wird daraus escalate_budget_exhausted mit Warten auf Review.

Warten auf Review

Ein unbrauchbares Urteil, der Versuch, einen Fehlschlag in ein Bestehen umzuwandeln, oder ein aufgebrauchtes Budget hält den Kandidaten zurück und pausiert die Session.

  1. verification_error · schlägt geschlossen fehlcore/agent/verify.pyFehlschlag · kein Urteil: verification_errorpolicy_action · Lesen des Urteilsloop/_lifecycle.py

    Eine fehlende Bewertungsinstanz, ein Timeout oder eine ungültige Antwort wird zu verification_error: weder Bestehen noch Nachbesserungssignal. Ein unbrauchbares Urteil ersetzt nie einen Erfolg.

  2. policy_action · Lesen des Urteilsloop/_lifecycle.pyAusführen · Entscheiden: PostVerify-EntscheidungPostVerify · ACCEPT · REVISE · ESCALATEcore/hooks/public.py

    Der PostVerify-Hook entscheidet zwischen ACCEPT, REVISE und ESCALATE. Ein ACCEPT für einen Kandidaten, der die Verifikation nicht bestanden hat, wird zu escalate. Ohne Entscheidung gilt der Runtime-Standard (Bestehen → accept, wiederholbar → revise, sonst escalate).

  3. policy_action · Lesen des Urteilsloop/_lifecycle.pyAusführen · Entscheiden: ESCALATE · pendingExterner Reviewer

    Der Kandidat bleibt als pending_text erhalten und wird gewöhnlichen Antworten vorenthalten, der Checkpoint wird gespeichert und die Session pausiert. Kein externer Reviewer wird automatisch kontaktiert.

  4. policy_action · Lesen des Urteilsloop/_lifecycle.pyAufzeichnen · Beobachten: Urteil · BelegzeilenTimeline · ledger-Entscheidungszeilenmemory · observability

    Die Timeline erhält Entscheidungs-, Beleg- und pending-Zeilen, der evidence ledger eine verification_policy-Zeile. Das sind best-effort-Aufzeichnungen, kein Beweis für einen äußeren Effekt.

Stopps ohne Verifikation

Stopps durch Abbruch, Limit und Infrastruktur sowie Läufe von control workflows werden ohne öffentliche Verifikation gespeichert.

  1. arun · Modell-Turnloop/agent_loop.pyAusführen · Entscheiden: Guards · LimitsStopp durch Fehlschlag · Limit · Abbruchloop/_guards.py · models.py

    Guards wie Runden-, Zeit-, Kosten- und Kontextlimits, Abbruch und die Erkennung wiederholter Fehlschläge beenden den Turn mit einem Element der geschlossenen Menge TerminationReason. Ein in der Konfiguration deaktiviertes Limit wird nicht immer durchgesetzt.

  2. Stopp durch Fehlschlag · Limit · Abbruchloop/_guards.py · models.pyFehlschlag · kein Urteil: Stopp durch Fehlschlag · Abbruchfinalize_and_return_asyncloop/_lifecycle.py

    Stopps durch Abbruch, Infrastruktur und Limits haben keinen zu verifizierenden Kandidaten und werden daher ohne öffentliche Verifikation gespeichert.

  3. control workflow · öffentliche Verifikation auslassenipc_server/poller.pyAusführen · Entscheiden: öffentliche Verifikation auslassenfinalize_and_return_asyncloop/_lifecycle.py

    Verlangt ein IPC-Aufruf, die öffentliche Verifikation auszulassen, oder ist ein control workflow aktiv, ist die öffentliche Verifikation nur für diesen Lauf aus; danach wird der vorherige Wert wiederhergestellt.

  4. finalize_and_return_asyncloop/_lifecycle.pyDaten: nur speichern · keine VerifikationCheckpoint · Session-Zustandmemory · observability

    Auch ein Stopp ohne Verifikation speichert sein Ergebnis und den Checkpoint und sendet die Events zum Session-Ende.

  5. finalize_and_return_asyncloop/_lifecycle.pyDaten: AntwortIPC · CLI-Aufrufer

    Gibt bei Abschluss die endgültige Antwort zurück, beim Warten auf Review eine leere Antwort mit EXTERNAL_VERIFICATION_REQUIRED und bei einem Stopp ohne Verifikation den Stoppgrund.

Alle Verbindungen in gleicher Stärke. Wird ein Ablauf gewählt, ist nur sein Pfad hervorgehoben, mit nummerierten Schritten.

  • Durchgezogen · Richtung, in die Anfragen, Kandidaten und Ergebnisse fließen
  • Gestrichelt · ausführen, entscheiden, autorisieren, konfigurieren
  • Lang strichpunktiert · Aufzeichnungen und Beobachtung, getrennt vom Urteil
  • Kurz gestrichelt · ein Fehlschlag oder ein unbrauchbares Urteil
  • Dicke schwarze Linie · der gewählte Ablauf; Nummern geben die Reihenfolge an
  • Kasten · eine Code- oder Aufzeichnungsgrenze, Pfad in der Kopfzeile
  • Innerer Chip · eine Komponente in dieser Grenze
  • Gestrichelter Kasten · außerhalb dieser Grenze
  • Schleife · finalization
  • Stopps · Hooks · Urteil
  • Speichern · Aufzeichnungen
  • IPC-Einstieg

Gezeichnet sind nur Aufrufpfade im fixierten Commit 9e2c041. Ein Bestehen beim Bewertungsmodell ist vom Erfolg eines externen Benchmark-Verifiers getrennt; Abschluss ist hier eine Entscheidung innerhalb der Runtime.

Urteilsengine
Standard ist der LLM judge; Jev Choice urteilt nur, wenn judgment_engine auf jev gesetzt ist. In beiden Fällen ergibt eine unbrauchbare Bewertungsinstanz verification_error, nie einen Erfolg.
Was Hooks dürfen
PreVerify kann das Urteil nur verschärfen, PostVerify kann keinen gescheiterten Kandidaten bestehen lassen, und Stop kann nur dann eine Fortsetzung verlangen, wenn nicht eskaliert wird.
Warten auf Review
Warten auf Review hält fest, dass eine Entscheidung von außen nötig ist. Es benachrichtigt niemanden und bedeutet nicht, dass das Ergebnis freigegeben wurde.