PT
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
Recorded evaluation · MCPMark PostgreSQL · 2026-07-04

Antes de mudar qualquer coisa, ele encontrou o que já existia.

A tarefa: segurança em nível de linha para um serviço social com cinco tabelas.

  1. PesquisaChamadas 1–12 · list_objects, get_object_details, execute_sqlLeu as cinco tabelas, quatro funções auxiliares já existentes, RLS desligado nas cinco, e as políticas, privilégios e papéis.
  2. AçãoChamada 13 · execute_sqlUma única transação: 20 políticas e RLS ligado, reaproveitando 3 funções auxiliares existentes e adicionando 3 funções.
  3. VerificaçãoHarness de avaliação · não é uma chamada do agente18 aprovados, 0 com falha. As 13 respostas de ferramentas em 9 turnos voltaram todas sem erro.
Saída do verificador, 18 linhas (literal)
  1. RLS enabled on users
  2. RLS enabled on channels
  3. RLS enabled on channel_moderators
  4. RLS enabled on posts
  5. RLS enabled on comments
  6. Users can update their own profile
  7. Users blocked from updating other users' profiles
  8. Channel owners can update their channels
  9. Non-owners blocked from updating channels
  10. Post authors can update their posts
  11. Channel moderators can update posts in their channels
  12. Unauthorized users blocked from updating posts
  13. Comment authors can update their comments
  14. Post authors can moderate comments on their posts
  15. Channel owners can add moderators
  16. Non-owners blocked from adding moderators
  17. Content visibility varies correctly based on user context
  18. Anonymous users can see 3 public user profiles (correct)

Uma execução passada em um sandbox de avaliação configurado, não um banco de dados em produção nem um incidente de segurança real. A contagem de linhas antes das políticas não está no registro, então nenhuma é mostrada. Registro público da execução (meta.json, commit 23e3428)

Revisar um resultado e repará-lo (inspirado no Reflexion, dentro da mesma tarefa) é uma capacidade do runtime atual do GEODE. Nenhum reparo desse tipo aparece neste registro: todas as respostas de ferramentas voltaram sem erro. Documentação do runtime (hook-system.md)

O modelo escolhe a próxima ação; o host mantém a fronteira de execução.

O runtime, desde a entrada de uma requisição em uma sessão, passando pela chamada ao modelo e pelas verificações de autoridade de cada chamada de ferramenta proposta, até a execução, os resultados e os registros. Ao escolher um fluxo, apenas o seu caminho é destacado, com etapas numeradas.

O modelo escolhe a próxima ação; o runtime verifica as permissões das ferramentas e decide quando o trabalho está concluído.

Os experimentos externos Scaffold Search / SIL começaram em May 15, 2026

É instalado pelo pacote geode-agent do PyPI ou pelo repositório público e executado em um terminal local. Também pode ser acessado como servidor MCP.

Arquitetura do runtime · desenhada a partir dos caminhos de código no commit fixado 9e2c041
Arquitetura do runtime do GEODEComponentes e conexões do processo do runtime do GEODE. As requisições chegam por IPC do terminal, mensageiros ou um host MCP externo e viram uma sessão; o AgenticLoop chama o modelo com o prompt de sistema, a conversa e os esquemas de ferramentas. Uma chamada de ferramenta proposta pelo modelo só é executada depois de passar pelas verificações de escopo, política, esquema, hook e aprovação do ToolExecutor, e seu resultado vira a próxima entrada do modelo. O checkpoint, a timeline e as linhas de evidência são armazenamentos separados.Usuário do terminalREPL · thin CLICanal de mensageiroSlack · Discord · TelegramHost MCP externoferramenta run_agentProvedores de LLMHTTPS · APIs de modelosArquivos · git · processosestado fora dos checkpointsServidores MCPglobal + projeto confiávelcore/serverCLIPoller · socket IPCpollers de mensageiroscore/mcp_server.pyrun_agent · execução únicasupervised/services.pySharedServices.create_sessionLaneQueue · session · globalcore/agent/loopAgenticLoop · seis fasesprompt de sistema · fontes declaradasmensagens · ConversationContextcore/llm/adaptersadapter.acomplete · classes de errotool_executor/processor.pyToolCallProcessorcore/tools/plan.pyBoundToolPlan · imutáveltool_executor/executor.pyescopo · política · esquemaPreToolUse · PostToolUseaprovação · HITLeffect receiptbloqueio de recurso · dispatchcore/toolshandlers de ferramentas · bash · computercore/mcp/manager.pyMCPServerManagermemory/session_checkpoint.pySQLite messages · state.jsonmemory/effect_receipts.pyEffectReceiptStoreobservability/session_timeline.pySessionTimeline · append-onlyagent/evidence_ledger.pyEvidenceLedger · JSONLcore/agent/verify.pyverify_turn_asynccore/hooksHookRegistry · decisõesHookSystem · observaçãoProcesso do runtime do GEODEdaemon serve · REPL · execução únicaEntrada · composição de sessãoLoop de execução · chamada ao modeloAutoridade das ferramentas · efeitosRegistros · recuperação · conclusão1 prompt · cli.sock · Usuário do terminal → CLIPoller · socket IPC12 create_session(IPC) · CLIPoller · socket IPC → SharedServices.create_session23 raia por requisição · CLIPoller · socket IPC → LaneQueue · session · global34ToolExecutor · AgenticLoop5arun(prompt)6prompt de sistema7mensagens8esquemas de ferramentas9StepSnapshot · requisição10HTTPS11 resposta · tool_use · adapter.acomplete · classes de erro → AgenticLoop · seis fases111lote pendente · salvamento por rodada2blocos tool_use3 aexecute · ToolCallProcessor → escopo · política · esquema34permitido · nível de segurança5PreToolUse · PostToolUse6pedido de aprovação7 negado antes da execução · tool_executor/executor.py → ToolCallProcessor78admissão do efeito · confirmação9chamada ao handler10 chamada MCP · bloqueio de recurso · dispatch → MCPServerManager1011 tools/call · MCPServerManager → Servidores MCP1112 mudanças em arquivos · git · processos · handlers de ferramentas · bash · computer → Arquivos · git · processos1213 resultado · erro pós-dispatch · tool_executor/executor.py → ToolCallProcessor1314tool_result15observação de chamada · resultado1lote pendente · salvamento por rodada2restauração na retomada3registro do turno4verificação de conclusão5PostVerify · Stop6linhas de evidência · best-effort7eventos cognitivos · de ciclo de vida1mensagem de canal2 create_session(DAEMON) · pollers de mensageiros → SharedServices.create_session23arun(message)4run_agent(prompt)5loop headless de execução única

Requisição → chamada ao modelo

Uma requisição do terminal chega por IPC, uma sessão é composta e o loop chama o modelo com o prompt de sistema, a conversa e os esquemas de ferramentas.

  1. Usuário do terminalprompt · cli.sockCLIPoller · socket IPCcore/server

    A CLI leve envia a requisição ao socket IPC do daemon serve (~/.geode/cli.sock). O REPL executa a mesma composição de sessão dentro do processo.

  2. CLIPoller · socket IPCcore/servercreate_session(IPC)SharedServices.create_sessionsupervised/services.py

    Cada conexão compõe uma sessão. O modo define o nível de HITL, o orçamento de tempo e as ferramentas negadas, e projeta o BoundToolPlan no provedor escolhido.

  3. CLIPoller · socket IPCcore/serverraia por requisiçãoLaneQueue · session · globalsupervised/services.py

    Antes de executar uma requisição, a raia da sessão e a raia global são ocupadas, o que limita as execuções concorrentes.

  4. SharedServices.create_sessionsupervised/services.pyToolExecutor · AgenticLoopAgenticLoop · seis fasescore/agent/loop

    Constrói o executor e o loop como um par que compartilha os hooks, o MCP, as skills e os bloqueios de recurso.

  5. LaneQueue · session · globalsupervised/services.pyarun(prompt)AgenticLoop · seis fasescore/agent/loop

    Executa um turno de usuário em seis fases: preparar a entrada, preparar a chamada, chamar o provedor, processar ferramentas, observar e compactar, encerrar.

  6. prompt de sistema · fontes declaradascore/agent/loopprompt de sistemaadapter.acomplete · classes de errocore/llm/adapters

    Construído a cada turno a partir de fontes declaradas, como seções escolhidas do GEODE.md e regras. A fachada de cinco níveis do ContextAssembler só é usada quando chamada explicitamente; não é a entrada do loop padrão.

  7. mensagens · ConversationContextcore/agent/loopmensagensadapter.acomplete · classes de errocore/llm/adapters

    A conversa e os resultados de ferramentas anteriores trafegam separados do prompt de sistema.

  8. BoundToolPlan · imutávelcore/tools/plan.pyesquemas de ferramentasadapter.acomplete · classes de errocore/llm/adapters

    Só as ferramentas do BoundToolPlan vinculado a esta etapa ficam visíveis ao modelo. É um snapshot imutável com uma geração e um hash de conteúdo.

  9. AgenticLoop · seis fasescore/agent/loopStepSnapshot · requisiçãoadapter.acomplete · classes de errocore/llm/adapters

    O StepSnapshot fixa o modelo, as ferramentas e os IDs de correlação desta chamada. O middleware de LLM não pode trocar um adaptador vinculado.

  10. adapter.acomplete · classes de errocore/llm/adaptersHTTPSProvedores de LLM

    Um adaptador por provedor faz a chamada. As falhas são classificadas e repetidas só dentro de um limite definido, ou encerram o turno com um motivo de término.

  11. adapter.acomplete · classes de errocore/llm/adaptersresposta · tool_useAgenticLoop · seis fasescore/agent/loop

    Texto sozinho vai para o término; tool_use vai para o processamento de ferramentas.

Autoridade da ferramenta → efeito → resultado

Uma proposta tool_use só é executada depois que todas as verificações passam; negações, resultados e erros voltam todos do executor e viram a próxima entrada do modelo.

  1. AgenticLoop · seis fasescore/agent/looplote pendente · salvamento por rodadaSQLite messages · state.jsonmemory/session_checkpoint.py

    Em uma sessão com checkpointing configurado (um checkpoint e um session id), o lote proposto é salvo antes de qualquer ferramenta rodar, e o lote não roda se não puder ser salvo. O lote concluído é salvo de novo. Chamadores sem checkpoint não têm essa garantia.

  2. AgenticLoop · seis fasescore/agent/loopblocos tool_useToolCallProcessortool_executor/processor.py

    Uma proposta do modelo não é permissão. Cada chamada recebe um ToolContext com a identidade do modelo e do adaptador do loop.

  3. ToolCallProcessortool_executor/processor.pyaexecuteescopo · política · esquematool_executor/executor.py

    Verifica em sequência o escopo da sessão, as reescritas do middleware de requisição, a política e o esquema. Uma reescrita que rebaixe o nível de segurança ou a classe de dados pessoais é negada.

  4. BoundToolPlan · imutávelcore/tools/plan.pypermitido · nível de segurançaescopo · política · esquematool_executor/executor.py

    Os handlers executáveis e os níveis de segurança vêm do BoundToolPlan projetado para a sessão.

  5. PreToolUse · PostToolUsetool_executor/executor.pyPreToolUse · PostToolUseHookRegistry · decisõescore/hooks

    Os hooks públicos decidem bloqueio, reescrita de argumentos ou pedido de permissão, e uma reescrita é seguida de novas verificações de escopo, política e esquema. Após a execução, um hook pode acrescentar contexto ou reter o resultado.

  6. aprovação · HITLtool_executor/executor.pypedido de aprovaçãoUsuário do terminal

    Em uma sessão IPC, o pedido de aprovação é repassado à CLI leve. Modos sem uma pessoa aplicam por padrão a política de negação; a única exceção é o computer use em DAEMON, quando um operador o habilita separadamente (bloqueado caso contrário).

  7. tool_executor/executor.pynegado antes da execuçãoToolCallProcessortool_executor/processor.py

    Uma rejeição de escopo, política ou esquema, um bloqueio por PreToolUse ou uma aprovação recusada volta como resultado de erro sem dispatch. Nesse caso, nenhum efeito desta chamada começou.

  8. effect receipttool_executor/executor.pyadmissão do efeito · confirmaçãoEffectReceiptStorememory/effect_receipts.py

    Efeitos como mudanças em arquivos, mensagens de saída ou ações administrativas são admitidos antes de rodar. Um resultado incerto não é executado de novo; pede uma reconciliação.

  9. bloqueio de recurso · dispatchtool_executor/executor.pychamada ao handlerhandlers de ferramentas · bash · computercore/tools

    Despacha para o handler vinculado depois de bloquear suas chaves de recurso. Uma chamada abortada no prazo pode continuar rodando fora.

  10. bloqueio de recurso · dispatchtool_executor/executor.pychamada MCPMCPServerManagercore/mcp/manager.py

    Só são chamadas as ferramentas MCP com política de recursos declarada.

  11. MCPServerManagercore/mcp/manager.pytools/callServidores MCP

    O catálogo de servidores vem das configurações globais e das configurações de projeto que passaram na verificação de confiança; essa verificação se aplica só às entradas de projeto. O gerenciador MCP aplica sua política de extensões e recursos.

  12. handlers de ferramentas · bash · computercore/toolsmudanças em arquivos · git · processosArquivos · git · processos

    As mudanças executadas ficam como estado externo. O checkpoint recupera só a conversa e não as desfaz.

  13. tool_executor/executor.pyresultado · erro pós-dispatchToolCallProcessortool_executor/processor.py

    Após o dispatch, resultados normais e erros (incluindo timeouts e resultados incertos) voltam por PostToolUse. Um erro ou timeout não significa que o trabalho externo parou ou foi desfeito.

  14. ToolCallProcessortool_executor/processor.pytool_resultmensagens · ConversationContextcore/agent/loop

    Resultados, negações e erros são igualmente serializados como tool_result e viram mensagens da próxima entrada do modelo.

  15. ToolCallProcessortool_executor/processor.pyobservação de chamada · resultadoSessionTimeline · append-onlyobservability/session_timeline.py

    Grava a chamada e seu resultado (ok ou erro) na timeline, incluindo chamadas negadas antes da execução. O registro é observação; não prova que um efeito externo começou ou teve sucesso.

Registros · recuperação · conclusão

O checkpoint, a timeline e as linhas de evidência são gravados separadamente. Não há transação compartilhada, e o checkpoint recupera só a conversa.

  1. AgenticLoop · seis fasescore/agent/looplote pendente · salvamento por rodadaSQLite messages · state.jsonmemory/session_checkpoint.py

    Em uma sessão com checkpointing configurado (um checkpoint e um session id), o lote proposto é salvo antes de qualquer ferramenta rodar, e o lote não roda se não puder ser salvo. O lote concluído é salvo de novo. Chamadores sem checkpoint não têm essa garantia.

  2. SQLite messages · state.jsonmemory/session_checkpoint.pyrestauração na retomadaAgenticLoop · seis fasescore/agent/loop

    Um único caminho de restauração traz de volta mensagens, estado cognitivo e contadores de guarda. O TaskGraph local do processo não é recuperado.

  3. AgenticLoop · seis fasescore/agent/loopregistro do turnoSessionTimeline · append-onlyobservability/session_timeline.py

    Um histórico de execução append-only, nunca reproduzido como estado.

  4. AgenticLoop · seis fasescore/agent/loopverificação de conclusãoverify_turn_asynccore/agent/verify.py

    A proposta de parada do modelo só vira conclusão por meio do Verify.

  5. verify_turn_asynccore/agent/verify.pyPostVerify · StopHookRegistry · decisõescore/hooks

    As decisões dos hooks públicos dizem se se continua com um reparo, e os reparos só acontecem dentro de um orçamento definido (dois por padrão).

  6. AgenticLoop · seis fasescore/agent/looplinhas de evidência · best-effortEvidenceLedger · JSONLagent/evidence_ledger.py

    Linhas de diagnóstico com dados ocultados. Os hashes servem à correlação; uma linha não prova que um efeito aconteceu, e não é gravada na mesma transação que a timeline ou o checkpoint.

  7. AgenticLoop · seis fasescore/agent/loopeventos cognitivos · de ciclo de vidaHookSystem · observaçãocore/hooks

    Os hooks de observação recebem e registram eventos; não decidem a execução.

Outros caminhos de entrada

Os mensageiros entram como sessões DAEMON do daemon serve; o run_agent de um host MCP externo entra em um loop headless de execução única construído à parte.

  1. Canal de mensageiromensagem de canalpollers de mensageiroscore/server

    Os pollers do daemon serve só processam mensagens de canais vinculados.

  2. pollers de mensageiroscore/servercreate_session(DAEMON)SharedServices.create_sessionsupervised/services.py

    Um modo sem pessoa para aprovar: aplicam-se a política de negação padrão e um orçamento de tempo. Só o computer use pode ser habilitado separadamente por um operador; sem isso, fica bloqueado.

  3. pollers de mensageiroscore/serverarun(message)AgenticLoop · seis fasescore/agent/loop

    Uma thread mantém um session id fixo e continua uma única cadeia de checkpoints.

  4. Host MCP externorun_agent(prompt)run_agent · execução únicacore/mcp_server.py

    Um host MCP externo chama o GEODE como ferramenta.

  5. run_agent · execução únicacore/mcp_server.pyloop headless de execução únicaAgenticLoop · seis fasescore/agent/loop

    Um executor e um loop headless construídos à parte, que contornam o SharedServices. A lista de negação padrão se aplica como está, então ferramentas como run_bash, delegate_task e computer são removidas; a exceção de computer use do DAEMON não existe aqui.

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, mensagens e resultados de ferramentas
  • Tracejada · composição de sessão, autoridade ou veredito; não é caminho de dados
  • Traço longo e ponto · registros e observação; nunca reproduzidos como estado
  • Traço curto · negação antes da execução, sem efeito
  • Linha preta grossa · o fluxo selecionado; os números dão a ordem
  • Caixa · fronteira dona do código, com o caminho de origem no cabeçalho
  • Chip interno · componente dessa fronteira
  • Caixa tracejada · fora do processo do runtime
  • Contorno laranja · onde um modelo decide
  • Loop de execução
  • Autoridade · vereditos
  • Armazenamentos de registros
  • Entrada · conexão · execução

Só são desenhadas as conexões cujas chamadas foram confirmadas. A fachada de cinco níveis do ContextAssembler, o TaskGraph e experimentos de pesquisa como Jev, SIL e Crucible não estão neste caminho do runtime. O cancelamento assíncrono não interrompe trabalho síncrono já iniciado nem desfaz efeitos que ocorreram.

Modelos suportados · por provedor

As opções do catálogo do código e os padrões distribuídos, não uma lista em que cada modelo passou por uma chamada real de API. As cadeias de fallback configuradas ficam vazias por padrão, e IDs exatos nunca são atualizados automaticamente para versões mais novas.

  • Anthropic

    API

    • PrincipalClaude Opus 5.5claude-opus-5-5Padrão
    • SecundárioClaude Sonnet 5claude-sonnet-5Padrão
    • EconômicoClaude Haiku 4.5claude-haiku-4-5-20251001Padrão
    Mostrar todos os 12 IDs do catálogo

    API

    • claude-fable-5-1
    • claude-opus-5-5padrão
    • claude-opus-5
    • claude-sonnet-5padrão
    • claude-haiku-4-5-20251001padrão
    • claude-fable-5
    • claude-opus-4-8
    • claude-opus-4-7
    • claude-opus-4-6
    • claude-opus-4-5
    • claude-sonnet-4-6
    • claude-sonnet-4-5-20250929

    O código rejeita a via OAuth por assinatura.

  • OpenAI

    API · assinatura do Codex

    • Padrão da API e do CodexGPT-6 Solgpt-6-solPadrão
    Mostrar todos os 11 IDs do catálogo

    API · assinatura do Codex

    • gpt-6-astra
    • gpt-6-solpadrão
    • gpt-6-luna
    • gpt-5.6-sol
    • gpt-5.6-terra
    • gpt-5.6-luna

    Somente API

    • gpt-5.5
    • gpt-5.3-codex
    • gpt-5.4
    • gpt-5.4-mini
    • gpt-5.4-nano

    Duas vias de acesso a um mesmo provedor; o catálogo define quais vias cada modelo permite.

  • Z.ai / GLM

    PAYG

    • PadrãoGLM-5.3glm-5.3Padrão
    Mostrar todos os 9 IDs do catálogo

    PAYG

    • glm-5.3padrão
    • glm-5.3-flash
    • glm-5.3-flashx
    • glm-5.2
    • glm-5.1
    • glm-5
    • glm-4.7
    • glm-4.7-flashx
    • glm-4.7-flash

    O código não admite a via GLM Coding Plan.

  • OpenRouter

    Serviço de roteamento

    • SeletorFree (smoke)openrouter/openrouter/freeRoteador
    • SeletorAuto (variable)openrouter/openrouter/autoRoteador

    Seleções do roteador, não um modelo fixo. IDs configurados explicitamente também podem ser mantidos.

  • TypeSafe / Jev

    Só decisão · separado da geração de texto

    • Diretojev-1.13.0Só decisão
    • Via OpenRoutertypesafe/jev-1.13Só decisão

    Um adaptador opcional que só faz julgamentos; não é um modelo raiz de geração de texto. O motor de julgamento padrão é llm, e o Jev precisa ser selecionado. As configurações próprias do estudo Jev seguem os registros da visão Jev.

FonteGEODE main 373d420Commit público de October 7, 2026 · verificado em October 8, 2026

Experimentos

Modelos e vias como registrados na época, não padrões atuais nem uma lista completa de compatibilidade.

  • Relatório de benchmark do GEODE

    July 31, 2026

    • GEODEGPT-5.6 Solgpt-5.6-solAssinatura OpenAI · high

  • Terminal-Bench 2.1 · especificação pareada do Harbor 0.22.0

    August 27, 2026

    • GEODE · native CodexGPT-5.6 Solgpt-5.6-solassinatura · max

    Uma especificação congelada; nem todo ensaio planejado virou resultado válido.

  • Execução arquivada do SIL run-2606-broken-tool-use

    • Scaffold alvoGPT-5.5gpt-5.5openai-codex
    • Auditor · juizClaude Opus 4.8claude-opus-4-8PAYG

    Um registro de papéis separados, não dois padrões intercambiáveis.