Geodi, personagem oficial do GEODE em pixel art
Voltar à sala

GEODE

Autonomous Agent Harness

Da observação à próxima ação.

Um harness local de agentes autônomos ao qual se pode confiar pesquisa, trabalho com arquivos e tarefas agendadas.

2026.02.21 — present

Concepção, julgamento, verificação: Author · implementação: Claude · revisão: Codex

  • CLIPublicado · PyPI
  • Servidor MCPImplementado

A proposta de parada do modelo só vira conclusão por meio da verificação.

Em uma parada entregável, um modelo que pede para parar ainda passa pela verificação de conclusão. O resultado é concluído, continuar dentro do orçamento ou aguardando revisão; limites de execução, cancelamento e erros terminam em um estado de parada separado.

Mapa de conclusão · desenhado a partir dos caminhos de código no commit fixado 9e2c041
Mapa de conclusão do GEODEComo a proposta de parada de um modelo vira conclusão. Só as paradas entregáveis (natural, forced_text, actionable_partial) passam pelo hook PreVerify, por uma verificação estrutural e pelo juiz selecionado (juiz LLM por padrão, Jev quando escolhido), e pelos hooks PostVerify e Stop. Uma aprovação é salva como concluída; uma falha reparável continua a mesma requisição dentro de um orçamento padrão de duas tentativas. Um veredito inutilizável, uma tentativa de transformar falha em aprovação ou um orçamento esgotado retém o candidato e pausa a sessão. Paradas por cancelamento, limite e infraestrutura e execuções de control workflow são salvas sem verificação.IPC · chamador da CLIresposta · estado da sessãoRevisor externopending · não contatadoModelo juizLLM judge · Jev Choiceipc_server/poller.pycontrol workflow · pular a verificação públicaloop/agent_loop.pyarun · turno do modelo_arun_once · continuação de reparoloop/_guards.py · models.pyparada entregável · natural etc.parada por falha · limite · cancelamentoloop/_lifecycle.pyfinalize_and_return_asyncpolicy_action · leitura do vereditoorçamento de continuação · padrão 2core/hooks/public.pyPreVerify · STRENGTHENPostVerify · ACCEPT · REVISE · ESCALATEStop · CONTINUEmemory · observabilitycheckpoint · estado da sessãotimeline · linhas de decisão do ledgercore/agent/verify.pyverificação estrutural · empty_turnjulgamento semântico · LLM ou Jevverification_error · fechado em caso de falhaProcesso do runtime do GEODEfim de um turno do AgenticLooploop · candidatos a paradafinalização · veredito1 proposta de parada · arun · turno do modelo → parada entregável · natural etc.12candidato a conclusão3 PreVerify · finalize_and_return_async → PreVerify · STRENGTHEN34verify_turn_async5pedido de julgamento6passed · rubric_misses7 decisão do PostVerify · policy_action · leitura do veredito → PostVerify · ACCEPT · REVISE · ESCALATE78Stop · CONTINUE9completed · salvo10resposta1passed · rubric_misses2 decisão do PostVerify · policy_action · leitura do veredito → PostVerify · ACCEPT · REVISE · ESCALATE23Stop · CONTINUE4reparo · tentativa +11verification_error2 decisão do PostVerify · policy_action · leitura do veredito → PostVerify · ACCEPT · REVISE · ESCALATE23ESCALATE · pending4veredito · linhas de evidência1 guardas · limites · arun · turno do modelo → parada por falha · limite · cancelamento12parada por falha · cancelamento3pular a verificação pública4só salvar · sem verificação5resposta

Verificar → concluir

Só uma parada entregável passa por PreVerify → julgamento → PostVerify → Stop. Nem a proposta de parada do modelo nem uma instrução de hook é, por si só, uma conclusão.

  1. arun · turno do modeloloop/agent_loop.pydados: proposta de paradaparada entregável · natural etc.loop/_guards.py · models.py

    Quando o modelo responde em texto sem chamada de ferramenta, o turno vira candidato a parada natural (forced_text na última rodada permitida). A proposta de parada de um modelo ainda não é conclusão.

  2. parada entregável · natural etc.loop/_guards.py · models.pydados: candidato a conclusãofinalize_and_return_asyncloop/_lifecycle.py

    Só natural, forced_text e actionable_partial são paradas entregáveis, e só elas seguem para a verificação pública.

  3. finalize_and_return_asyncloop/_lifecycle.pyexecutar · decidir: PreVerifyPreVerify · STRENGTHENcore/hooks/public.py

    Com STRENGTHEN, o hook PreVerify só pode acrescentar requisitos e códigos de falta. Pode tornar o veredito mais rigoroso, nunca aprová-lo.

  4. finalize_and_return_asyncloop/_lifecycle.pyexecutar · decidir: verify_turn_asyncverificação estrutural · empty_turncore/agent/verify.py

    Primeiro vem uma verificação estrutural (turno vazio, model_action_required); uma falha estrutural irreparável pula o julgamento semântico. Configurações antigas como off ou rule_based resolvem para llm_judge e não podem desligar o veredito.

  5. julgamento semântico · LLM ou Jevcore/agent/verify.pydados: pedido de julgamentoModelo juiz

    O juiz selecionado (juiz LLM por padrão, Jev Choice quando escolhido) é chamado uma vez, sem ferramentas, por no máximo 120 segundos e nunca além do orçamento de tempo restante. Um candidato que possa conter observações pessoais não é enviado a um juiz auxiliar.

  6. julgamento semântico · LLM ou Jevcore/agent/verify.pydados: passed · rubric_missespolicy_action · leitura do vereditoloop/_lifecycle.py

    O veredito traz aprovação ou falha, códigos de falta, uma reflexão para a próxima tentativa e se uma nova tentativa é útil. Uma aprovação semântica nunca cobre uma verificação estrutural que falhou.

  7. policy_action · leitura do vereditoloop/_lifecycle.pyexecutar · decidir: decisão do PostVerifyPostVerify · ACCEPT · REVISE · ESCALATEcore/hooks/public.py

    O hook PostVerify decide ACCEPT, REVISE ou ESCALATE. Um ACCEPT de um candidato que falhou na verificação vira escalate. Sem decisão, vale o padrão do runtime (aprovação → accept, repetível → revise, caso contrário escalate).

  8. policy_action · leitura do vereditoloop/_lifecycle.pyexecutar · decidir: Stop · CONTINUEStop · CONTINUEcore/hooks/public.py

    Só quando não há escalonamento a instrução CONTINUE do hook Stop pode pedir uma continuação de reparo. Uma instrução de hook é uma entrada para a próxima tentativa, não uma autoridade.

  9. policy_action · leitura do vereditoloop/_lifecycle.pydados: completed · salvocheckpoint · estado da sessãomemory · observability

    Com aprovação e accept, as tentativas continuadas são mescladas, o resultado é salvo e a sessão é registrada como completed.

  10. finalize_and_return_asyncloop/_lifecycle.pydados: respostaIPC · chamador da CLI

    Retorna a resposta final quando concluído; uma resposta vazia com EXTERNAL_VERIFICATION_REQUIRED quando aguarda revisão; o motivo de parada em uma parada sem verificação.

Reparo dentro do orçamento

Uma falha reparável continua a mesma requisição. O orçamento padrão é de duas tentativas; quando se esgota, o candidato aguarda revisão.

  1. julgamento semântico · LLM ou Jevcore/agent/verify.pydados: passed · rubric_missespolicy_action · leitura do vereditoloop/_lifecycle.py

    O veredito traz aprovação ou falha, códigos de falta, uma reflexão para a próxima tentativa e se uma nova tentativa é útil. Uma aprovação semântica nunca cobre uma verificação estrutural que falhou.

  2. policy_action · leitura do vereditoloop/_lifecycle.pyexecutar · decidir: decisão do PostVerifyPostVerify · ACCEPT · REVISE · ESCALATEcore/hooks/public.py

    O hook PostVerify decide ACCEPT, REVISE ou ESCALATE. Um ACCEPT de um candidato que falhou na verificação vira escalate. Sem decisão, vale o padrão do runtime (aprovação → accept, repetível → revise, caso contrário escalate).

  3. policy_action · leitura do vereditoloop/_lifecycle.pyexecutar · decidir: Stop · CONTINUEStop · CONTINUEcore/hooks/public.py

    Só quando não há escalonamento a instrução CONTINUE do hook Stop pode pedir uma continuação de reparo. Uma instrução de hook é uma entrada para a próxima tentativa, não uma autoridade.

  4. orçamento de continuação · padrão 2loop/_lifecycle.pyexecutar · decidir: reparo · tentativa +1_arun_once · continuação de reparoloop/agent_loop.py

    Com uma instrução de reparo, e só enquanto o número da tentativa estiver abaixo do orçamento (dois por padrão), a mesma requisição continua. Ao atingir o orçamento, vira escalate_budget_exhausted e aguarda revisão.

Aguardando revisão

Um veredito inutilizável, uma tentativa de transformar falha em aprovação ou um orçamento esgotado retém o candidato e pausa a sessão.

  1. verification_error · fechado em caso de falhacore/agent/verify.pyfalha · sem veredito: verification_errorpolicy_action · leitura do vereditoloop/_lifecycle.py

    Um juiz ausente, um timeout ou uma resposta inválida vira verification_error: nem aprovação nem sinal de reparo. Um veredito inutilizável nunca substitui o sucesso.

  2. policy_action · leitura do vereditoloop/_lifecycle.pyexecutar · decidir: decisão do PostVerifyPostVerify · ACCEPT · REVISE · ESCALATEcore/hooks/public.py

    O hook PostVerify decide ACCEPT, REVISE ou ESCALATE. Um ACCEPT de um candidato que falhou na verificação vira escalate. Sem decisão, vale o padrão do runtime (aprovação → accept, repetível → revise, caso contrário escalate).

  3. policy_action · leitura do vereditoloop/_lifecycle.pyexecutar · decidir: ESCALATE · pendingRevisor externo

    O candidato é mantido como pending_text e retido das respostas comuns, o checkpoint é salvo e a sessão é pausada. Nenhum revisor externo é contatado automaticamente.

  4. policy_action · leitura do vereditoloop/_lifecycle.pyregistrar · observar: veredito · linhas de evidênciatimeline · linhas de decisão do ledgermemory · observability

    A timeline recebe linhas de decisão, de evidência e pending, e o evidence ledger uma linha verification_policy. São registros best-effort, não prova de um efeito externo.

Paradas sem verificação

Paradas por cancelamento, limite e infraestrutura e execuções de control workflow são salvas sem verificação pública.

  1. arun · turno do modeloloop/agent_loop.pyexecutar · decidir: guardas · limitesparada por falha · limite · cancelamentoloop/_guards.py · models.py

    Guardas como limites de rodadas, tempo, custo e contexto, cancelamento e detecção de falhas repetidas encerram o turno com um membro do conjunto fechado TerminationReason. Um limite desativado na configuração nem sempre é aplicado.

  2. parada por falha · limite · cancelamentoloop/_guards.py · models.pyfalha · sem veredito: parada por falha · cancelamentofinalize_and_return_asyncloop/_lifecycle.py

    Paradas por cancelamento, infraestrutura e limite não têm candidato a verificar, então são salvas sem verificação pública.

  3. control workflow · pular a verificação públicaipc_server/poller.pyexecutar · decidir: pular a verificação públicafinalize_and_return_asyncloop/_lifecycle.py

    Quando uma chamada IPC pede para pular a verificação pública ou um control workflow está ativo, a verificação pública fica desligada só naquela execução e o valor anterior é restaurado depois.

  4. finalize_and_return_asyncloop/_lifecycle.pydados: só salvar · sem verificaçãocheckpoint · estado da sessãomemory · observability

    Uma parada sem verificação ainda salva o resultado e o checkpoint e emite os eventos de fim de sessão.

  5. finalize_and_return_asyncloop/_lifecycle.pydados: respostaIPC · chamador da CLI

    Retorna a resposta final quando concluído; uma resposta vazia com EXTERNAL_VERIFICATION_REQUIRED quando aguarda revisão; o motivo de parada em uma parada sem verificação.

Todas as conexões com a mesma espessura. Escolha um fluxo para destacar só o caminho dele, com etapas numeradas.

  • Contínua · direção em que fluem requisições, candidatos e resultados
  • Tracejada · executar, decidir, autorizar, configurar
  • Traço longo e ponto · registros e observação, separados do veredito
  • Traço curto · falha ou veredito inutilizável
  • Linha preta grossa · o fluxo selecionado; os números dão a ordem
  • Caixa · fronteira de código ou de registro, com o caminho no cabeçalho
  • Chip interno · componente dessa fronteira
  • Caixa tracejada · fora dessa fronteira
  • loop · finalização
  • paradas · hooks · veredito
  • salvamento · registros
  • entrada IPC

Só são desenhados os caminhos de chamada do commit fixado 9e2c041. A aprovação de um juiz é distinta do sucesso de um verificador de benchmark externo; aqui, a conclusão é uma decisão dentro do runtime.

Motor de julgamento
O padrão é o juiz LLM; o Jev Choice só julga quando judgment_engine é definido como jev. Em ambos os casos, um juiz inutilizável gera verification_error, nunca sucesso.
O que os hooks podem fazer
O PreVerify só pode tornar o veredito mais rigoroso, o PostVerify não pode aprovar um candidato que falhou e o Stop só pode pedir continuação quando não há escalonamento.
Aguardando revisão
Aguardar revisão registra que é necessária uma decisão externa. Não notifica ninguém nem significa que o resultado foi aprovado.