> **Can't find what you're looking for?** Use `search_docs` on the docs MCP server at `https://naturgy-comer-documentation-p5mde.vercel.app/api/mcp` to find what you need.

# Probar un agente

La validación de un agente combina un objetivo, un criterio y una prueba. Cada
pieza responde a una pregunta diferente y ninguna sustituye a las otras.

| Pieza | Pregunta |
| --- | --- |
| Objetivo | ¿Qué resultado debe obtener el cliente? |
| Criterio | ¿Qué conducta observable demuestra que se cumplió? |
| Prueba | ¿Qué escenario puede hacer pasar o fallar esa conducta? |

## Procedimiento

### 1. Seleccionar la versión

Identifica el flujo de trabajo, la organización y la versión que quieres
comprobar. Consulta la lista de versiones y distingue la versión viva de la
última versión editable. No ejecutes una prueba contra una versión implícita.

### 2. Leer el alcance

Obtén el inventario de nodos de la versión y elige el nodo que ejecuta la
capacidad. Comprueba sus herramientas, componentes, variables y salidas antes
de redactar el escenario.

### 3. Ejecutar la validación técnica

Usa la operación de prueba completa para detectar errores de configuración y,
si aparece un fallo, repite solo el nodo afectado. Registra el identificador de
la versión, el entorno, el nodo, la fecha y el mensaje de error.

### 4. Consultar evaluaciones

Para cada nodo de agente:

* lista las evaluaciones personalizadas existentes;
* revisa sus últimas ejecuciones y el razonamiento del juez;
* ejecuta una evaluación solo contra la versión seleccionada;
* separa un fallo del escenario, de la rúbrica y del comportamiento real.

Las suites adversarias se consultan y ejecutan por separado. Una evaluación
cooperativa no comprueba una prohibición.

### 5. Revisar el resultado

Un criterio grave debe tener al menos una prueba que falle cuando la conducta se
incumple. Cada acción necesita un caso correcto y una condición que impida
llamarla cuando no corresponde. Cada salida de la capacidad debe estar cubierta.

Un resultado rojo no demuestra por sí solo que el agente esté mal: primero
comprueba que la versión, el escenario, los datos y la rúbrica sean los
correctos.

### 6. Decidir qué queda abierto

Registra por separado:

* fallos confirmados del agente;
* errores de configuración;
* errores de la prueba o de su rúbrica;
* reglas de negocio todavía no cerradas;
* cobertura que aún no existe.

No conviertas una regla pendiente en un criterio. No publiques ni promociones una
versión desde esta guía.

## Objetivos

Escribe el objetivo como resultado para el cliente, no como actividad. Cada
capacidad puede necesitar objetivos de:

* **resolución:** lo que el cliente obtiene;
* **frontera:** lo que no pertenece a la capacidad y por dónde sale;
* **conducta:** lo que debe respetarse aunque la gestión termine bien.

## Criterios

Un criterio cubre una clase de fallos observable desde el nodo. Debe ser breve,
atómico y juzgable. Debe señalar el objetivo que cubre y el texto o regla que
lo justifica. Si hay dos reglas en conflicto, se registra la contradicción y no
se activa el criterio hasta resolverla.

## Dos familias de prueba

**Personalizada:** el interlocutor coopera y el escenario comprueba la respuesta,
la llamada a una herramienta o sus argumentos.

**Adversaria:** el interlocutor intenta forzar una conducta prohibida. No se usa
para medir la corrección de una herramienta; esa comprobación pertenece a una
prueba personalizada.

## Criterio de cobertura

Una batería está completa cuando cubre los objetivos, los criterios graves, las
acciones, las salidas y las prohibiciones relevantes. El número de escenarios no
es una medida suficiente. Los fallos menores solo se aceptan después de una
revisión explícita.

Para la aplicación concreta en ATC, consulta [Objetivo, criterio y
prueba](/use-cases/atc/how-to/testing) y el [contrato de evidencia](/use-cases/atc/reference/evidence).
Para comprobar la versión y la fecha de una lectura, consulta [Procedencia y
vigencia](/reference/source-map).