Geodi, el personaje oficial de GEODE en pixel art
Volver a la sala

GEODE

Autonomous Agent Harness

De la observación a la siguiente acción.

Un arnés local de agentes autónomos al que se pueden encargar investigación, trabajo con archivos y tareas programadas.

2026.02.21 — present

Diseño, juicio, verificación: Author · implementación: Claude · revisión: Codex

  • CLIPublicado · PyPI
  • Servidor MCPImplementado

Los escenarios de auditoría se producen mediante fases en un orden fijo.

El host controla el orden de las fases, y los agentes de rol de cada fase se reparten el trabajo. El conjunto de semillas resultante y la rúbrica seleccionada son las entradas de la auditoría de comportamiento de Petri.

Mapa de semillas · trazado a partir de las rutas de evals en el commit fijado 9e2c041
Generación de escenarios de auditoría de GEODE y auditoría de PetriCómo se escriben y auditan los escenarios de auditoría (semillas). El orquestador seed_generation controla el orden de las fases mientras los agentes de rol redactan, revisan y mejoran, y el resultado se exporta como un directorio survivors y archivos de metarrevisión. Una auditoría de Petri toma una selección de semillas y asigna tres roles de modelo separados: el auditor interpreta el escenario de la semilla, el objetivo es el andamiaje completo de GEODE y el juez puntúa la transcripción por dimensión en un log de Inspect. La medición de SIL lee ese resultado, y una medición conservada se convierte en evidencia de línea base para la siguiente generación.Modelo auditorinterpreta el escenario de la semillaModelo base objetivoel modelo que envuelve GEODEModelo juezpuntúa toda la transcripciónlog .eval de Inspectcopia archivada · resumenmedición de SIL · measure.pyla lee el capítulo “Búsqueda de políticas”baseline snapshotmedias por dim · evidenciahandoff pointerlatest_pointer.json · priorsseed_generation/orchestrator.pyorden de fases · PipelineStatecheckpoint · resumeagents/ · borradorSupervisor · estrategia de ejecuciónliterature_review · desactivado por defectoGenerator · semillas candidatasagents/ · revisiónProximity · deduplicaciónCritic · revisiónPilot · opcional · no en smokeRanker · Eloagents/ · mejoraEvolver · mejoraMeta-reviewer · priors siguientesrun_dir/survivors/ · copias .md de candidatossurvivors.json · Elo · pilotmeta_review.json · state.jsonpetri/seedssemillas incluidas · *.mdpetri/runner.pygeode audit · /audit · herramientaestimación de costo · dry-run por defectopetri/geode_target.pyGEODE como objetivo · AgenticLooppetri/judge_dimsjudge_dimensions · YAMLarchivos de estado fuera de una ejecuciónevals/seed_generationredacción de escenariosevals/petriejecución de auditoría1ejecutar las fases en orden2evidencia de línea base3 metarrevisión anterior · latest_pointer.json · priors → agents/ · borrador34 semillas candidatas · agents/ · borrador → agents/ · revisión45survivors · Elo6 siguiente iteración · desde Critic · Meta-reviewer · priors siguientes → Critic · revisión67 exportar los supervivientes · agents/ · mejora → run_dir/78puntero latest1--seed-select2semillas incluidas3 roles de modelo · tres puestos · geode audit · /audit · herramienta → Modelo auditor34diálogo del escenario de la semilla5 llamadas a modelos · GEODE como objetivo · AgenticLoop → Modelo base objetivo56transcripción7 judge_dimensions · judge_dimensions · YAML → Modelo juez78puntuaciones por dimensión1puntuaciones por dimensión2 medición · log .eval de Inspect → medición de SIL · measure.py23actualización de la línea base4evidencia de línea base

Redacción de escenarios

El orquestador controla el orden de las fases, los agentes de rol redactan y filtran candidatos, y el resultado se exporta mediante un contrato de archivos.

  1. orden de fases · PipelineStateseed_generation/orchestrator.pyejecutar · decidir: ejecutar las fases en ordenagents/ · borrador

    El orquestador controla el orden de las fases y la fusión del estado; el agente de rol de cada fase hace el trabajo. Dentro de una fase, el trabajo puede repartirse mediante SubAgentManager, y los subagentes no se anidan (profundidad 1).

  2. medias por dim · evidenciabaseline snapshotdatos: evidencia de línea baseagents/ · borrador

    Generator, Critic y Evolver leen las medias por dimensión, los errores estándar y la evidencia de la línea base seleccionada. La primera generación no tiene línea base y usa los prompts por defecto.

  3. latest_pointer.json · priorshandoff pointerdatos: metarrevisión anterioragents/ · borrador

    La metarrevisión de la ejecución anterior deja priors para la siguiente generación y dimensiones poco cubiertas que esta generación tiene en cuenta.

  4. agents/ · borradordatos: semillas candidatasagents/ · revisión

    Los candidatos de Generator pasan en orden por la deduplicación de Proximity, la revisión de Critic, Pilot (opcional; se omite en las ejecuciones smoke) y la clasificación Elo de Ranker.

  5. agents/ · revisióndatos: survivors · Eloagents/ · mejora

    Evolver mejora los candidatos mejor clasificados, y Meta-reviewer resume la ejecución en priors para la siguiente generación.

  6. Meta-reviewer · priors siguientesagents/ · mejoraejecutar · decidir: siguiente iteración · desde CriticCritic · revisiónagents/ · revisión

    Con max_iterations definido, tras Meta-reviewer los candidatos mejorados vuelven a pasar por Critic → Pilot → Ranker → Evolver → Meta-reviewer. Supervisor, Generator y Proximity no se vuelven a ejecutar; el valor por defecto es cero iteraciones.

  7. agents/ · mejoradatos: exportar los supervivientesrun_dir/

    Los cuerpos de los candidatos supervivientes se copian como archivos en survivors/, las puntuaciones Elo y pilot van a survivors.json, y la metarrevisión y el estado se escriben aparte.

  8. meta_review.json · state.jsonrun_dir/datos: puntero latestlatest_pointer.json · priorshandoff pointer

    Un único latest_pointer.json registra dónde están el seed_pool y el meta_review de esta ejecución. Las salidas por ejecución son las canónicas; el puntero es una ayuda best-effort para la siguiente ejecución, y una escritura fallida solo se anota en el log. No todas las ejecuciones tienen ambos campos.

Ejecución de auditoría

El auditor interpreta la semilla (una instrucción de escenario), el objetivo es el andamiaje de GEODE y el juez puntúa la transcripción. Los tres roles son puestos de modelo separados.

  1. survivors/ · copias .md de candidatosrun_dir/datos: --seed-selectgeode audit · /audit · herramientapetri/runner.py

    Una auditoría toma una selección de semillas (un directorio survivors, semillas incluidas, ids o tags) y la pasa a la tarea inspect_petri/audit de Inspect. La generación de semillas no inicia por sí misma una auditoría.

  2. semillas incluidas · *.mdpetri/seedsdatos: semillas incluidasgeode audit · /audit · herramientapetri/runner.py

    Las semillas incluidas en el repositorio pueden seleccionarse tal cual.

  3. geode audit · /audit · herramientapetri/runner.pyejecutar · decidir: roles de modelo · tres puestosModelo auditor

    Los modelos auditor, objetivo y juez se definen por separado. Por defecto es un dry run; las llamadas reales solo ocurren tras confirmar una estimación de costo. Cuando los tres roles comparten proveedor, se añade una marca de sesgo de mismo proveedor.

  4. Modelo auditordatos: diálogo del escenario de la semillaGEODE como objetivo · AgenticLooppetri/geode_target.py

    Una semilla es una instrucción de escenario para el auditor. El auditor dirige la conversación y solo puede crear herramientas y resultados de herramientas cuando target_tools está habilitado.

  5. GEODE como objetivo · AgenticLooppetri/geode_target.pydatos: llamadas a modelosModelo base objetivo

    Todo el AgenticLoop de GEODE (herramientas, hooks, memoria) se envuelve como una sola API de modelo, así que el objetivo auditado es el andamiaje de GEODE, no solo el modelo base.

  6. GEODE como objetivo · AgenticLooppetri/geode_target.pydatos: transcripciónModelo juez

    El juez lee una vez la transcripción completa de cada muestra y la puntúa por dimensión.

  7. judge_dimensions · YAMLpetri/judge_dimsejecutar · decidir: judge_dimensionsModelo juez

    El YAML de dimensiones del juez seleccionado fija las dimensiones de puntuación. Es una auditoría de comportamiento, una medición distinta de la finalización de tareas.

  8. Modelo juezdatos: puntuaciones por dimensiónlog .eval de Inspect

    El log .eval de Inspect y un resumen se archivan. Un fallo de archivado se anota y no bloquea el resultado de la auditoría.

Medición → siguiente generación

SIL usa las puntuaciones de auditoría para su veredicto, y una medición conservada se convierte en evidencia de línea base para la siguiente generación de semillas. Esto no significa que el enlace funcionara automáticamente en todas las campañas.

  1. Modelo juezdatos: puntuaciones por dimensiónlog .eval de Inspect

    El log .eval de Inspect y un resumen se archivan. Un fallo de archivado se anota y no bloquea el resultado de la auditoría.

  2. log .eval de Inspectregistrar · observar: mediciónmedición de SIL · measure.py

    El measure.py de SIL ejecuta el subproceso de auditoría y calcula el fitness a partir de su resultado.

  3. medición de SIL · measure.pydatos: actualización de la línea basemedias por dim · evidenciabaseline snapshot

    El ledger de SIL escribe una medición conservada como línea base. La generación de semillas lee esa evidencia cuando se selecciona una línea base (automática o explícitamente).

  4. medias por dim · evidenciabaseline snapshotdatos: evidencia de línea baseagents/ · borrador

    Generator, Critic y Evolver leen las medias por dimensión, los errores estándar y la evidencia de la línea base seleccionada. La primera generación no tiene línea base y usa los prompts por defecto.

Todas las conexiones con el mismo grosor. Elija un flujo para resaltar solo su recorrido, con pasos numerados.

  • Continua · dirección en que fluyen solicitudes, candidatos y resultados
  • Discontinua · ejecutar, decidir, autorizar, configurar
  • Raya larga y punto · registros y observación, aparte del veredicto
  • Línea negra gruesa · el flujo seleccionado; los números dan el orden
  • Recuadro · frontera de código o de registro, con su ruta en la cabecera
  • Chip interior · componente de esa frontera
  • Recuadro discontinuo · fuera de esa frontera
  • orquestador · entrada de auditoría
  • objetivo de auditoría · dimensiones de puntuación
  • salidas · archivos de estado
  • agentes de rol · semillas incluidas

El orquestador fija el orden de la primera pasada y el de las repeticiones. La configuración, los roles registrados y el punto de reanudación pueden omitir algunas fases, y no todas las campañas ejecutaron todas las fases. La ubicación de los archivos de estado depende del entorno, por lo que no se muestran rutas.

Tres roles
Una semilla es una instrucción de escenario, escrita por una persona o generada; el auditor es el modelo que la interpreta, el objetivo es el andamiaje de GEODE auditado y el juez es el modelo que puntúa la transcripción. Las puntuaciones y los logs son salidas del juez.
Qué se mide
Una auditoría de Petri puntúa dimensiones de comportamiento. No es una tasa de finalización de tareas ni una garantía de calidad del producto.