Actividad en clase: simular la colaboración multi-Agent y la pasarela de aceptación automatizada

Esta página es un simulacro de clase: varios Agent se reparten el trabajo en torno a una misma tarea de desarrollo y todas las modificaciones candidatas que generan se envían de forma unificada a la pasarela de pruebas automatizadas y aceptación; solo las modificaciones que cumplen con criterios de aceptación ejecutables pueden entrar en la línea base histórica, mientras que las no conformes se bloquean y devuelven con retroalimentación reproducible. El objetivo no es que los Agent «discutan hasta encontrar lo correcto», sino completar el ciclo de ingeniería «desarrollo colaborativo → aceptación automática → herencia histórica».

Objetivos del simulacro

Comprender la división de tareas en el desarrollo colaborativo multi-Agent, la convergencia de modificaciones candidatas y el papel de la pasarela de aceptación al bloquear modificaciones no conformes.
Experimentar la sustitución de la aprobación subjetiva por pruebas ejecutables y condiciones de aceptación, observando qué candidatas entran en la línea base y cuáles requieren reintento.
Debatir cuestiones avanzadas: si las reglas de aceptación son reproducibles, si la retroalimentación es accionable, el riesgo de bloqueos falsos y de omisiones, y la granularidad de la descomposición frente al coste de colaboración.

Reparto de roles y flujo básico

El grupo de clase puede dividirse en Agent de planificación/descomposición, Agent de implementación, Agent de generación de pruebas y Agent de revisión/coordinación. Una misma tarea puede generar varias modificaciones candidatas, que la pasarela resolverá de forma unificada.

Descomposición de tareas: dividir el objetivo en subtareas verificables de forma independiente, por ejemplo «validación de interfaz → corrección del algoritmo → pruebas de regresión».
Implementación en paralelo: varios Agent de implementación envían parches candidatos y el Agent de pruebas genera casos límite.
Aceptación automática: se ejecutan pruebas automatizadas, comprobaciones estáticas y de contrato, y la pasarela de aceptación decide según criterios ejecutables.
Herencia histórica: las modificaciones aprobadas se integran en la línea base histórica y sirven de base para el trabajo posterior de los Agent; las rechazadas conservan el motivo del fallo y la información de reproducción para reintentarlas.

Criterios de la pasarela de aceptación

Los criterios de la pasarela deben ser ejecutables y no quedarse en «parece correcto». Se bloquean especialmente las modificaciones que incumplen el contrato de interfaz, introducen regresiones, no cubren condiciones límite o violan restricciones de calidad. Una retroalimentación útil debe incluir al menos: casos fallidos, registros, pasos de reproducción, comportamiento esperado y restricciones relevantes.

Herencia histórica y observaciones avanzadas

Una vez que las modificaciones aprobadas entran en la línea base, los Agent posteriores no tienen que empezar de cero; las rechazadas se convierten en ejemplos negativos consultables que evitan repetir errores. Al evaluar este tipo de sistemas colaborativos hay que prestar especial atención a si las reglas de aceptación son reproducibles, si la retroalimentación es accionable y a los distintos riesgos que conllevan los bloqueos falsos y las omisiones. Una granularidad de descomposición demasiado fina eleva el coste de fusión y aceptación, mientras que una demasiado gruesa provoca que las candidatas se solapen; lo más sólido es dividir según los límites «verificables de forma independiente».

Recordatorio del simulacro

Si falta la pasarela o los criterios son ambiguos, la colaboración multi-Agent puede no ser más eficiente y volverse caótica por la ausencia de una resolución unificada. El valor del control automatizado está en sustituir la aprobación subjetiva por evidencia reproducible.

Simulacro de colaboración multi-Agent y pasarela de aceptación

Este diagrama del simulacro muestra cómo los parches candidatos producidos en paralelo por los roles de planificación y descomposición, implementación, generación de pruebas y revisión/coordinación se envían de forma unificada a la pasarela de pruebas automatizadas y aceptación para su resolución. Las modificaciones que cumplen criterios ejecutables se integran en la línea base histórica para que los Agent posteriores las hereden; las rechazadas conservan casos fallidos, registros y pasos de reproducción como ejemplos negativos consultables para reintentos, sustituyendo así la aprobación subjetiva por evidencia reproducible.

Pregunta 1

¿Cuál es el concepto central de «Actividad en clase: simular la colaboración multi-Agent y la pasarela de aceptación automatizada»?

Omitir el concepto y pasar directamente a la siguiente sección.

Profundizar mediante un simulacro en la comprensión del desarrollo colaborativo multi-Agent y de los mecanismos de aceptación automatizada.

Pregunta 2

Respecto a «experimentar cómo las pruebas automatizadas y la pasarela de aceptación bloquean modificaciones no conformes», ¿cuál de las afirmaciones es la más razonable?

Profundizar mediante un simulacro en la comprensión del desarrollo colaborativo multi-Agent y de los mecanismos de aceptación automatizada.

Omitir el concepto y pasar directamente a la siguiente sección.

Pregunta 3

Respecto a «profundizar mediante un simulacro en la comprensión del desarrollo colaborativo multi-Agent y de los mecanismos de aceptación automatizada», ¿cuál de las afirmaciones es la más razonable?

Poder explicar con pruebas o ejemplos: profundizar mediante un simulacro en la comprensión del desarrollo colaborativo multi-Agent y de los mecanismos de aceptación automatizada.

Cambiar todos los factores a la vez para comparar resultados.

Omitir los materiales y memorizar la respuesta directamente.

Sacar conclusiones solo por intuición, sin necesidad de observación ni pruebas.

Pregunta 4

Respecto a «Actividad en clase: simular la colaboración multi-Agent y la pasarela de aceptación automatizada», ¿cuál de las afirmaciones es la más razonable?

Omitir los materiales y memorizar la respuesta directamente.

Cambiar todos los factores a la vez para comparar resultados.

Sacar conclusiones solo por intuición, sin necesidad de observación ni pruebas.

Poder explicar con pruebas o ejemplos: actividad en clase: simular la colaboración multi-Agent y la pasarela de aceptación automatizada

Pregunta 5

Respecto a «simular la división de tareas en el desarrollo colaborativo multi-Agent», ¿cuál de las afirmaciones es la más razonable?

Poder explicar con pruebas o ejemplos: simular la división de tareas en el desarrollo colaborativo multi-Agent

Omitir los materiales y memorizar la respuesta directamente.

Sacar conclusiones solo por intuición, sin necesidad de observación ni pruebas.

Cambiar todos los factores a la vez para comparar resultados.

Caso: varios Agent corrigen el fallo del servicio de pagos ante entradas límite

Lee el escenario y completa las dos tareas de análisis.

Un servicio de pagos falla cuando la cantidad introducida es negativa o una cadena demasiado larga. El equipo trabaja con colaboración multi-Agent: el Agent de planificación divide el trabajo en validación de interfaz, corrección del algoritmo y pruebas de regresión; los Agent de implementación A y B envían parches candidatos; el Agent de pruebas genera casos límite; la pasarela de aceptación ejecuta pruebas, comprobaciones estáticas y de contrato. Si una candidata no cubre entradas fuera de rango, se devuelve junto con registros de fallo y pasos de reproducción; si se aprueba, se integra en la línea base histórica.

Diseña para este escenario un conjunto de reglas ejecutables para la pasarela de aceptación que cubran al menos interfaz, regresión, límites y restricciones de calidad.

Respuesta:
Ejemplo de reglas ejecutables: capa de interfaz: el campo de importe debe rechazar números negativos y cadenas que superen el límite de longitud, devolviendo un código de error unificado, y las pruebas de contrato deben validar la structure de entrada y salida; capa de regresión: ejecutar los casos existentes de pago correcto, reembolso y conciliación, exigiendo que todos pasen y que no haya fallos nuevos; capa de límites: debe incluir casos con 0, números negativos, importe máximo permitido, cadenas demasiado largas, cadenas vacías y caracteres especiales, verificando que no haya fallos y que los errores sean explicables; restricciones de calidad: superar las comprobaciones estáticas, cobertura de rutas críticas no inferior al umbral acordado y sin alertas de alta gravedad. Todas las reglas deben expresarse como pruebas o scripts ejecutables y poder reproducirse en integración continua.

Si la pasarela bloquea por error una modificación correcta o deja pasar por error una modificación incorrecta, ¿qué riesgos genera cada caso y cómo reducirlos?

Respuesta:
Un bloqueo falso impide que una candidata correcta entre en la línea base, desperdicia el trabajo del Agent de implementación, reduce la eficiencia colaborativa y puede llevar al equipo a relajar los criterios; una omisión deja que los defectos entren en la línea base histórica y que los Agent posteriores trabajen sobre una base errónea, amplificando el riesgo de regresión. Cómo reducirlos: definir primero condiciones de aceptación reproducibles y conservar la evidencia de fallo; revisar por muestreo los resultados de bloqueo para distinguir defectos de prueba de defectos de implementación; convertir los nuevos casos fallidos en un conjunto de regresión; y combinar casos límite, comprobaciones de contrato y validación progresiva para reducir ambos tipos de riesgo.