FR
Geodi, personnage officiel de GEODE en pixel art
Retour à la salle

GEODE

Autonomous Agent Harness

De l’observation à l’action suivante.

Un harnais local d’agent autonome auquel confier recherche, travail sur fichiers et tâches planifiées.

2026.02.21 — present

Conception, jugement, vérification : Author · implémentation : Claude · revue : Codex

  • CLIPublié · PyPI
  • Serveur MCPImplémenté

La proposition d’arrêt du modèle ne devient un achèvement que par la vérification.

Pour un arrêt livrable, un modèle qui demande à s’arrêter passe tout de même par la vérification d’achèvement. L’issue est : terminé, poursuite dans le budget ou attente de revue ; limites d’exécution, annulation et erreurs aboutissent à un état d’arrêt distinct.

Carte de l’achèvement · tracée d’après les chemins de code au commit fixé 9e2c041
Carte de l’achèvement GEODEComment la proposition d’arrêt d’un modèle devient un achèvement. Seuls les arrêts livrables (natural, forced_text, actionable_partial) passent par le hook PreVerify, un contrôle structurel et le juge sélectionné (juge LLM par défaut, Jev s’il est choisi), puis par les hooks PostVerify et Stop. Une réussite est enregistrée comme terminée ; un échec réparable poursuit la même requête dans un budget par défaut de deux tentatives. Un verdict inutilisable, une tentative de transformer un échec en réussite ou un budget épuisé retient le candidat et met la session en pause. Les arrêts par annulation, limite et infrastructure, ainsi que les exécutions de control workflow, sont enregistrés sans vérification.IPC · appelant CLIréponse · état de sessionRelecteur externepending · non contactéModèle jugeLLM judge · Jev Choiceipc_server/poller.pycontrol workflow · vérification publique sautéeloop/agent_loop.pyarun · tour du modèle_arun_once · poursuite de réparationloop/_guards.py · models.pyarrêt livrable · natural, etc.arrêt par échec · limite · annulationloop/_lifecycle.pyfinalize_and_return_asyncpolicy_action · lecture du verdictbudget de poursuite · 2 par défautcore/hooks/public.pyPreVerify · STRENGTHENPostVerify · ACCEPT · REVISE · ESCALATEStop · CONTINUEmemory · observabilitycheckpoint · état de sessiontimeline · lignes de décision du ledgercore/agent/verify.pycontrôle structurel · empty_turnjugement sémantique · LLM ou Jevverification_error · fermé en cas d’échecProcessus runtime GEODEfin d’un tour d’AgenticLoopboucle · candidats à l’arrêtfinalisation · verdict1 proposition d’arrêt · arun · tour du modèle → arrêt livrable · natural, etc.12candidat à l’achèvement3 PreVerify · finalize_and_return_async → PreVerify · STRENGTHEN34verify_turn_async5demande de jugement6passed · rubric_misses7 décision PostVerify · policy_action · lecture du verdict → PostVerify · ACCEPT · REVISE · ESCALATE78Stop · CONTINUE9completed · enregistré10réponse1passed · rubric_misses2 décision PostVerify · policy_action · lecture du verdict → PostVerify · ACCEPT · REVISE · ESCALATE23Stop · CONTINUE4réparation · tentative +11verification_error2 décision PostVerify · policy_action · lecture du verdict → PostVerify · ACCEPT · REVISE · ESCALATE23ESCALATE · pending4verdict · lignes de preuve1 gardes · limites · arun · tour du modèle → arrêt par échec · limite · annulation12arrêt par échec · annulation3vérification publique sautée4enregistrement seul · sans vérification5réponse

Vérifier → terminer

Seul un arrêt livrable passe par PreVerify → jugement → PostVerify → Stop. Ni la proposition d’arrêt du modèle ni une instruction de hook ne constitue à elle seule un achèvement.

  1. arun · tour du modèleloop/agent_loop.pyproposition d’arrêtarrêt livrable · natural, etc.loop/_guards.py · models.py

    Quand le modèle répond en texte sans appel d’outil, le tour devient un candidat d’arrêt natural (forced_text au dernier round autorisé). La proposition d’arrêt d’un modèle n’est pas encore un achèvement.

  2. arrêt livrable · natural, etc.loop/_guards.py · models.pycandidat à l’achèvementfinalize_and_return_asyncloop/_lifecycle.py

    Seuls natural, forced_text et actionable_partial sont des arrêts livrables, et seuls ceux-ci passent à la vérification publique.

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

    Avec STRENGTHEN, le hook PreVerify peut seulement ajouter des exigences et des codes de manque. Il peut rendre le verdict plus strict, jamais le faire passer.

  4. finalize_and_return_asyncloop/_lifecycle.pyverify_turn_asynccontrôle structurel · empty_turncore/agent/verify.py

    Un contrôle structurel vient d’abord (tour vide, model_action_required) ; un échec structurel irréparable saute le jugement sémantique. D’anciens réglages comme off ou rule_based se résolvent en llm_judge et ne peuvent pas désactiver le verdict.

  5. jugement sémantique · LLM ou Jevcore/agent/verify.pydemande de jugementModèle juge

    Le juge sélectionné (juge LLM par défaut, Jev Choice s’il est choisi) est appelé une fois, sans outils, pendant 120 secondes au plus et jamais au-delà du budget de temps restant. Un candidat susceptible de contenir des observations personnelles n’est pas envoyé à un juge auxiliaire.

  6. jugement sémantique · LLM ou Jevcore/agent/verify.pypassed · rubric_missespolicy_action · lecture du verdictloop/_lifecycle.py

    Le verdict porte réussite ou échec, codes de manque, une réflexion pour la tentative suivante et l’utilité d’une nouvelle tentative. Une réussite sémantique ne couvre jamais un contrôle structurel échoué.

  7. policy_action · lecture du verdictloop/_lifecycle.pydécision PostVerifyPostVerify · ACCEPT · REVISE · ESCALATEcore/hooks/public.py

    Le hook PostVerify décide ACCEPT, REVISE ou ESCALATE. Un ACCEPT sur un candidat qui a échoué à la vérification devient escalate. Sans décision, la valeur par défaut du runtime s’applique (réussite → accept, réessayable → revise, sinon escalate).

  8. policy_action · lecture du verdictloop/_lifecycle.pyStop · CONTINUEStop · CONTINUEcore/hooks/public.py

    Ce n’est qu’en l’absence d’escalade que l’instruction CONTINUE du hook Stop peut demander une poursuite de réparation. Une instruction de hook est une entrée pour la tentative suivante, pas une autorité.

  9. policy_action · lecture du verdictloop/_lifecycle.pycompleted · enregistrécheckpoint · état de sessionmemory · observability

    Sur une réussite suivie d’un accept, les tentatives poursuivies sont fusionnées, le résultat est enregistré et la session est consignée comme completed.

  10. finalize_and_return_asyncloop/_lifecycle.pyréponseIPC · appelant CLI

    Renvoie la réponse finale si terminé ; une réponse vide avec EXTERNAL_VERIFICATION_REQUIRED en attente de revue ; le motif d’arrêt pour un arrêt sans vérification.

Réparation dans le budget

Un échec réparable poursuit la même requête. Le budget par défaut est de deux tentatives ; une fois épuisé, le candidat attend une revue.

  1. jugement sémantique · LLM ou Jevcore/agent/verify.pypassed · rubric_missespolicy_action · lecture du verdictloop/_lifecycle.py

    Le verdict porte réussite ou échec, codes de manque, une réflexion pour la tentative suivante et l’utilité d’une nouvelle tentative. Une réussite sémantique ne couvre jamais un contrôle structurel échoué.

  2. policy_action · lecture du verdictloop/_lifecycle.pydécision PostVerifyPostVerify · ACCEPT · REVISE · ESCALATEcore/hooks/public.py

    Le hook PostVerify décide ACCEPT, REVISE ou ESCALATE. Un ACCEPT sur un candidat qui a échoué à la vérification devient escalate. Sans décision, la valeur par défaut du runtime s’applique (réussite → accept, réessayable → revise, sinon escalate).

  3. policy_action · lecture du verdictloop/_lifecycle.pyStop · CONTINUEStop · CONTINUEcore/hooks/public.py

    Ce n’est qu’en l’absence d’escalade que l’instruction CONTINUE du hook Stop peut demander une poursuite de réparation. Une instruction de hook est une entrée pour la tentative suivante, pas une autorité.

  4. budget de poursuite · 2 par défautloop/_lifecycle.pyréparation · tentative +1_arun_once · poursuite de réparationloop/agent_loop.py

    Avec une instruction de réparation, et seulement tant que le numéro de tentative reste sous le budget (deux par défaut), la même requête se poursuit. Une fois le budget atteint, elle devient escalate_budget_exhausted et attend une revue.

En attente de revue

Un verdict inutilisable, une tentative de transformer un échec en réussite ou un budget épuisé retient le candidat et met la session en pause.

  1. verification_error · fermé en cas d’écheccore/agent/verify.pyverification_errorpolicy_action · lecture du verdictloop/_lifecycle.py

    Un juge absent, un délai dépassé ou une réponse invalide devient verification_error : ni réussite ni signal de réparation. Un verdict inutilisable ne tient jamais lieu de succès.

  2. policy_action · lecture du verdictloop/_lifecycle.pydécision PostVerifyPostVerify · ACCEPT · REVISE · ESCALATEcore/hooks/public.py

    Le hook PostVerify décide ACCEPT, REVISE ou ESCALATE. Un ACCEPT sur un candidat qui a échoué à la vérification devient escalate. Sans décision, la valeur par défaut du runtime s’applique (réussite → accept, réessayable → revise, sinon escalate).

  3. policy_action · lecture du verdictloop/_lifecycle.pyESCALATE · pendingRelecteur externe

    Le candidat est conservé comme pending_text et retenu des réponses ordinaires, le checkpoint est enregistré et la session mise en pause. Aucun relecteur externe n’est contacté automatiquement.

  4. policy_action · lecture du verdictloop/_lifecycle.pyverdict · lignes de preuvetimeline · lignes de décision du ledgermemory · observability

    La timeline reçoit des lignes de décision, de preuve et pending, et l’evidence ledger une ligne verification_policy. Ce sont des enregistrements best-effort, pas la preuve d’un effet extérieur.

Arrêts sans vérification

Les arrêts par annulation, limite et infrastructure et les exécutions de control workflow sont enregistrés sans vérification publique.

  1. arun · tour du modèleloop/agent_loop.pygardes · limitesarrêt par échec · limite · annulationloop/_guards.py · models.py

    Des gardes comme les limites de rounds, de temps, de coût et de contexte, l’annulation et la détection d’échecs répétés terminent le tour avec un membre de l’ensemble fermé TerminationReason. Une limite désactivée dans la configuration n’est pas toujours appliquée.

  2. arrêt par échec · limite · annulationloop/_guards.py · models.pyarrêt par échec · annulationfinalize_and_return_asyncloop/_lifecycle.py

    Les arrêts par annulation, infrastructure et limite n’ont pas de candidat à vérifier ; ils sont donc enregistrés sans vérification publique.

  3. control workflow · vérification publique sautéeipc_server/poller.pyvérification publique sautéefinalize_and_return_asyncloop/_lifecycle.py

    Quand un appel IPC demande de sauter la vérification publique ou qu’un control workflow est actif, la vérification publique est désactivée pour cette seule exécution, puis la valeur précédente est rétablie.

  4. finalize_and_return_asyncloop/_lifecycle.pyenregistrement seul · sans vérificationcheckpoint · état de sessionmemory · observability

    Un arrêt sans vérification enregistre tout de même son résultat et son checkpoint, et émet les événements de fin de session.

  5. finalize_and_return_asyncloop/_lifecycle.pyréponseIPC · appelant CLI

    Renvoie la réponse finale si terminé ; une réponse vide avec EXTERNAL_VERIFICATION_REQUIRED en attente de revue ; le motif d’arrêt pour un arrêt sans vérification.

Toutes les connexions avec la même épaisseur. Choisissez un flux pour ne mettre en évidence que son chemin, avec des étapes numérotées.

  • Trait plein · sens de circulation des requêtes, candidats et résultats
  • Tirets · exécuter, décider, autoriser, configurer
  • Trait mixte long · enregistrements et observation, distincts du verdict
  • Tiret court · échec ou verdict inutilisable
  • Trait noir épais · le flux sélectionné ; les numéros donnent l’ordre
  • Cadre · frontière de code ou d’enregistrement, chemin dans l’en-tête
  • Pastille intérieure · composant de cette frontière
  • Cadre en tirets · hors de cette frontière
  • boucle · finalisation
  • arrêts · hooks · verdict
  • sauvegarde · enregistrements
  • entrée IPC

Seuls les chemins d’appel du commit fixé 9e2c041 sont tracés. La réussite d’un juge est distincte du succès d’un vérificateur de benchmark externe ; l’achèvement est ici une décision interne au runtime.

Moteur de jugement
Par défaut, c’est le juge LLM ; Jev Choice ne juge que si judgment_engine vaut jev. Dans les deux cas, un juge inutilisable donne verification_error, jamais un succès.
Ce que peuvent les hooks
PreVerify ne peut que durcir le verdict, PostVerify ne peut pas faire passer un candidat en échec, et Stop ne peut demander une poursuite qu’en l’absence d’escalade.
En attente de revue
L’attente de revue consigne qu’une décision extérieure est nécessaire. Elle ne notifie personne et ne signifie pas que le résultat a été approuvé.