2026-07-31T13:17:52.176Z

Depuración Interactiva y Dirección de Sistemas de AI Multiagente: Cierre cada reinicio

Convierta el rebobinado y la edición de múltiples agentes en una sucursal auditable con cobertura de puntos de control, conciliación de efectos, aprobación y un nuevo recibo de resultados.

La depuración interactiva y la dirección de sistemas de AI multiagente no deben tratarse como edición de transcripciones. Un restablecimiento seguro crea una nueva sucursal con su propio linaje, evidencia de estado restaurado, registro de autoridad y recibo de resultados. Si un navegador—espacio de trabajo, cola, credencial o destino externo no se pueden restaurar o conciliar, el estado correcto es incierto, no " listo.” Esa es la lección práctica a tomar de Depuración Interactiva y Dirección de Sistemas de AI Multiagente, el documento CHI 2025 detrás del código abierto de Microsoft AGDebugger. La investigación hace que rebobinar y editar sea utilizable para la depuración de múltiples agentes. Una implementación operativa necesita un límite más: un restablecimiento puede recrear un estado interno lo suficientemente cerca como para probar una hipótesis, pero no puede deshacer automáticamente un correo electrónico, revertir un ticket, anular la publicación de una página o probar que la nueva sucursal completó la tarea del usuario. El valor predeterminado razonable es un recibo de dirección con seis compuertas: 1. el padre y la rama tienen identidades distintas; 2. el punto de control cubre todas las claves de estado de agente y herramienta requeridas; 3. los efectos después del punto de control se revierten o concilian; 4. el operador está autorizado para realizar la intervención; 5. la configuración del agente está anclada para la nueva rama; 6. la sucursal reanudada obtiene un nuevo recibo de resultados. Solo los cinco primeros hacen una rama listo para reanudar . El sexto lo hace verificado . Un reinicio es una bifurcación, no un rebobinado El documento de AGDebugger parte de un problema concreto. Cinco desarrolladores de agentes describieron dificultades para localizar errores en conversaciones largas, falta de controles de depuración interactivos y una iteración lenta en las configuraciones de los agentes. Los autores crearon un sistema que permite al desarrollador revisar los mensajes, restablecer a un punto anterior, editar un mensaje anterior y comparar las ramas de conversación resultantes. Luego, un estudio de dos partes con 14 participantes examinó el diagnóstico y las estrategias de manejo. Esta es una interacción más fuerte que buscar registros. Un desarrollador puede hacer dos preguntas falsificables en el límite de falla: ¿qué sucede si el mismo estado se ejecuta nuevamente y qué sucede si cambia un mensaje específico? El documento informa sobre tres formas comunes de orientación en su estudio: agregar detalles, simplificar una tarea y cambiar un plan. Pero el detalle de la implementación importa más que la asequibilidad de la edición. AGDebugger comprueba el estado del agente antes de procesar un mensaje. Al restablecer, restaura el punto de control correspondiente y crea una nueva sesión. Los mensajes y puntos de control anteriores a la bifurcación permanecen compartidos; los nuevos mensajes y puntos de control pertenecen a la rama. Eso es linaje, incluso si la interfaz parece un rebobinado. Tratar la operación como una rama le da al operador tres invariantes útiles: la ejecución fallida original permanece inspeccionable; el punto exacto de bifurcación es inmutable; la edición y todos los efectos posteriores pertenecen a una nueva sesión. Sin esas invariantes, una transcripción editada puede reescribir la evidencia utilizada para diagnosticar el incidente. La "ejecución exitosa" resultante puede ser imposible de reproducir porque nadie puede decir qué historial, indicador, esquema de herramienta o configuración del modelo lo produjo. El registro de sucursal no necesita contenido de mensaje: Los identificadores Hash y las clases de edición gruesa son suficientes para un rastro de evidencia. No exporte solicitudes, argumentos de herramientas, secretos o datos de usuario simplemente para demostrar que existe una bifurcación. Restaurar la cobertura estatal antes de cambiar de plan Eliminar mensajes de una transcripción no es una restauración de estado. El documento dice que los agentes de AGDebugger implementan métodos de guardado y carga de estado. El estado de un agente web puede incluir una URL y una posición de ventana gráfica; otros agentes pueden necesitar un estado diferente. También describe la política de puntos de control como "lo suficientemente buena", porque la restauración completa del JavaScript del navegador y el estado de la aplicación remota puede ser poco práctica o imposible. Esa limitación debería estar al lado del botón de reinicio, no en una autopsia. Defina las claves de estado requeridas por el flujo de trabajo antes de que comience una ejecución. Para un pequeño equipo de investigación y publicación, podrían ser: Este punto de comprobación está incompleto porque falta la cola de aprobación. Una repetición de la transcripción podría hacer que la sucursal vuelva a preguntar, omita una decisión existente o actúe como si se transfiriera la autoridad. El operador debería ver restore uncertain , no un control de currículum verde. La cobertura es necesaria pero no suficiente. Para cada clave de estado, registre una huella digital de revisión o sin contenido y un resultado de restauración: Clave de estado Evidencia antes del reinicio Prueba de restauración requerida Memoria del agente hash de revisión y punto de control la revisión cargada coincide con la bifurcación Navegador origen, hash de ruta y clase de sesión local se puede acceder a la ruta esperada y la clase de sesión es válida Espacio de Trabajo confirmación del repositorio y resumen del estado sucio revisión exacta más cambios locales intencionales Registro de herramientas hash de esquema y recuento de capacidades se reconocen las coincidencias o desviaciones actuales del registro Cola de aprobación ID de recibo de la decisión y estado se conservan las decisiones pendientes y resueltas Es posible que un sistema remoto en vivo se haya movido desde el punto de control. Eso no siempre es un fracaso. Es una razón para etiquetar la evidencia. Si el navegador puede volver a la página grabada pero el registro subyacente de la página ha cambiado, la fidelidad de la instantánea es parcial. El operador aún puede ejecutar una rama de diagnóstico, pero no debe presentarla como una repetición exacta. La configuración es parte del estado. Fije los roles de agente, los identificadores de modelo, el conjunto de herramientas, las indicaciones del sistema y las reglas de enrutamiento utilizadas por la sucursal. De lo contrario, una edición exitosa solo demuestra que alguna combinación desconocida funcionó. Mantenga la configuración original inmutable y registre el delta intencional. Conciliar efectos antes de reproducir una llamada de herramienta Un punto de control restaura el estado bajo el control del depurador. No invierte el mundo exterior. Supongamos que la sucursal matriz creó un ticket después del punto de control y luego no produjo el informe público prometido. Restablecer antes de que la herramienta llame y reproduzca puede crear un segundo ticket. La ausencia de respuesta no es evidencia de que la primera llamada no haya tenido ningún efecto. Antes de reanudar, enumere cada operación posterior al punto de control con un efecto externo y clasifíquela: reverted : el efecto original se deshizo de forma segura; reconciled : el efecto permanece y la nueva rama lo reutilizará u omitirá; pending : falta evidencia de destino; irreversible : el efecto no se puede deshacer y necesita una nueva decisión humana. Cualquier cosa pending o irreversible bloquea la reproducción automática en ese límite. Utilice teclas de operación estables donde el destino las admita. Para una operación de publicación, consulte el destino mediante un ID de borrador inmutable antes de crear otro. Para un correo electrónico, conserve el ID del mensaje del proveedor sin el cuerpo del mensaje. Para un cambio de repositorio, compare la confirmación esperada o el hash de árbol. Para un ticket, recupere el ticket mediante la clave de idempotencia de la solicitud. La intervención del operador también necesita un límite de autoridad. Editar un plan es de bajo riesgo cuando la sucursal está confinada a un accesorio local. Es materialmente diferente cuando la edición cambia destinatarios, presupuesto, permisos, objetivos de producción o acciones destructivas. Dirija esas ediciones a un propietario autorizado y mantenga la sucursal en needs approval hasta que llegue el recibo de la decisión. Esperar esa decisión no está estancado. Reanudar repetidamente mientras se desconoce la autoridad o el estado de destino es la falla. Ejecute el recibo de dirección contra casos inconvenientes El artefacto que lo acompaña es un clasificador determinista y accesorio sin contenido. No ejecuta AGDebugger ni pretende reproducir su estudio de usuarios. Prueba la decisión operativa que rodea a un reinicio. Ejecútelo localmente: El accesorio contiene ocho ramas. El clasificador producido: La prueba agrega una novena afirmación: una rama cuyo ID es igual a su padre se rechaza como invalid lineage . La precedencia es deliberada. El estado faltante bloquea la interpretación del efecto porque el operador no puede establecer el punto de partida de la rama. El bloque de efectos no conciliados se reanuda antes de considerar la aprobación. La aprobación y una configuración fija hacen que la sucursal esté lista, no en buen estado. Después de reanudar, el entregable esperado aún necesita un verificador determinista. Cambie un campo y el resultado debería moverse de manera predecible. Agregue la clave de cola de aprobación faltante a la restauración parcial y podrá avanzar. Marque un ticket pendiente con efecto conciliado y la sucursal podrá llegar a la puerta de la autoridad. Conjunto outcomeVerified a falso después de una respuesta final fluida y el resultado permanece false success . Esto produce una distinción operativa importante: "Listo para reanudar" significa que el límite de intervención está controlado. "Verificado" significa que la nueva sucursal completó el trabajo previsto. No combine esos estados en una insignia verde. Lo que el experimento no prueba El artefacto valida una regla de decisión, no la fidelidad de la instantánea. No puede probar que un navegador se restauró exactamente, que un LLM tomará el mismo camino o que nunca ocurrió un efecto secundario indocumentado. Una integración real necesita adaptadores de estado específicos del tiempo de ejecución y consultas de destino. El estudio AGDebugger también tiene un alcance limitado: cinco entrevistados formativos, 14 participantes del estudio, dos tareas de estudio y un prototipo de investigación construido sobre AutoGen. Sus hallazgos justifican el patrón de interacción; no establecen una reducción de la tasa de incidentes para cada arquitectura multiagente. El documento en sí identifica desafíos abiertos que incluyen desacoplar la dirección de la implementación de un agente y determinar si una edición tuvo un efecto. Esos límites fortalecen la regla de operación. Utilice el reinicio interactivo para aislar una hipótesis, no para fabricar certeza. Preservar el padre, bifurcar explícitamente, restaurar lo que se puede probar, etiquetar lo que no, conciliar los efectos externos, requerir autoridad y verificar el nuevo resultado en su destino. Sidewisp se encuentra actualmente en versión preliminar privada. Sus adaptadores de monitoreo de producción y ejecutor de recuperación generalmente no se envían. El método aquí es un patrón operativo inspeccionable, no una afirmación de que Sidewisp ya controla o dirige equipos de agentes en vivo. La dirección del producto de Sidewisp mantiene la autoridad humana, la evidencia y la verificación de resultados como elementos centrales para una recuperación segura. Si opera sistemas multiagente en la actualidad, comience con un flujo de trabajo propenso a fallas. Defina sus claves de estado y el libro mayor de efectos externos antes del próximo incidente. El primer punto de control útil no es el que puede reproducir más historial; es el que puede explicar exactamente qué se restauró, qué quedó cambiado, quién autorizó la sucursal y cómo se verificó el resultado final.