Crea un flujo de trabajo en n8n para cambios de código con aprobación humana y verificación mediante pruebas

El flujo de trabajo de un vistazo

Usa n8n para que un agente de IA proponga un cambio en el repositorio, pero supedita la operación de escritura a una aprobación humana. Después de una escritura aprobada, ejecuta las pruebas sobre el commit exacto resultante e informa del resultado. Mantén la fusión o el despliegue como una decisión independiente.

La distinción clave es aprobación de herramientas frente a aprobación de resultados. En n8n, un paso de revisión humana puede pausar un AI Agent antes de que se ejecute una herramienta seleccionada. La persona revisora ve la herramienta propuesta y sus parámetros; la aprobación ejecuta esa llamada, mientras que el rechazo la cancela e informa al agente. Este comportamiento se documenta en la guía de supervisión humana de n8n.

OneMux proporciona acceso a modelos de IA mediante una sola API compatible con OpenAI. Es una posible vía de acceso a modelos para este diseño, no una integración verificada con n8n. Consulta la documentación de la API de OneMux y contrasta la configuración de tu nodo de n8n con el endpoint y los parámetros que vayas a utilizar.

Qué necesitas antes de empezar

• Una instancia de n8n con un AI Agent, una conexión adecuada a un modelo de chat y acceso a un canal de revisión humana como Slack o n8n Chat.
• Una integración de repositorio o un servicio personalizado que pueda leer una revisión especificada y aplicar un patch a una rama que no sea de producción. Concede a su credencial de escritura solo el acceso necesario para ese repositorio y esa rama.
• Un ejecutor de pruebas aislado de las credenciales y los sistemas de producción. Debe aceptar un identificador de commit exacto y devolver un estado y un enlace o referencia a los resultados.
• Una cuenta de OneMux y acceso a su API si eliges OneMux para las llamadas al modelo. Consulta la guía de inicio rápido para conocer los datos de conexión vigentes y el catálogo de modelos para seleccionar un modelo disponible.
• Un repositorio con un comando de pruebas conocido, una rama predeterminada protegida y una persona autorizada para revisar los cambios propuestos.

Este es un patrón de implementación, no un flujo de trabajo importable. Las herramientas del repositorio, la integración del ejecutor, la elección del modelo y los campos concretos de n8n dependen de tu entorno. En particular, la documentación proporcionada no establece que un modelo específico de OneMux admita el comportamiento de tool calling que requiere un AI Agent de n8n. Verifica esa compatibilidad antes de depender de este diseño.

Diseña el flujo de trabajo en torno a una revisión exacta

Una secuencia práctica es la siguiente:

1. Recibir una solicitud. Obtén de la configuración de confianza del flujo de trabajo el repositorio, la descripción del problema, la rama de trabajo de destino, el commit base y el comando de pruebas permitido.
2. Leer y proponer. Permite que el agente inspeccione los archivos pertinentes en el commit base y prepare un patch. El acceso de lectura no debe permitir modificar el repositorio.
3. Revisar la escritura. Pasa la herramienta de aplicación del patch por la revisión humana de n8n. La persona revisora aprueba o rechaza la llamada propuesta a la herramienta.
4. Aplicar e identificar. Si se aprueba, el servicio de escritura comprueba que la rama siga apuntando al commit base aprobado, aplica el patch aprobado y devuelve el ID del nuevo commit. Si la base cambió, bloquea la operación y solicita una nueva propuesta y aprobación.
5. Verificar. Ejecuta las pruebas configuradas sobre ese nuevo commit exacto en un ejecutor aislado. Registra el comando, el commit, el estado y la referencia al resultado.
6. Informar. Envía el commit y el resultado de las pruebas a la persona revisora y a quien hizo la solicitud. Un resultado fallido, cancelado o ausente no equivale a una prueba superada.

Estos son controles recomendados, no funciones garantizadas por el paso de revisión humana de n8n. En particular, tu servicio de repositorio debe exigir la comprobación del commit base y garantizar que el patch aplicado sea el que se aprobó.

Configura la conexión al modelo

En n8n, elige una configuración de modelo de chat que admita un endpoint compatible con OpenAI configurable y el comportamiento de tool calling que necesita tu AI Agent. Usa el endpoint, el método de autenticación y el identificador de modelo indicados en la documentación vigente de OneMux. Guarda las credenciales en el sistema de credenciales de n8n, no en prompts ni en mensajes del flujo de trabajo.

Antes de conectar el acceso al repositorio, realiza una pequeña solicitud de prueba y comprueba que la respuesta llegue en el formato esperado por el nodo de n8n. Después, prueba una llamada inocua a una herramienta. Que algo sea compatible con OpenAI no significa que todos los endpoints, parámetros o formatos de llamada a herramientas sean intercambiables: la compatibilidad depende de que ambas partes admitan las solicitudes y respuestas necesarias. Esta configuración no se ha probado para este artículo.

Si la conexión al modelo disponible no admite las llamadas a herramientas del agente, no eludas la aprobación dando al modelo credenciales de escritura directas. Usa una configuración compatible o crea una transferencia independiente al servicio de escritura que se revise explícitamente.

Añade una aprobación humana a la escritura en el repositorio

En el nodo AI Agent, abre el conector Tools y busca Human review en el Tools Panel. Selecciona un canal de aprobación y configura sus credenciales. Conecta la herramienta que escribe en el repositorio al conector de herramientas del paso de revisión. Mantén separadas las herramientas de solo lectura cuando corresponda y coloca cualquier otra herramienta que pueda cambiar el estado externo detrás de su propia revisión o de un control equivalente.

La documentación de n8n indica que la persona revisora puede recibir el nombre de la herramienta y los parámetros proporcionados por la IA. Por ejemplo, configura el mensaje de revisión con:

Proposed tool: {{ $tool.name }}
Proposed parameters:
{{ JSON.stringify($tool.parameters, null, 2) }}

Usa una herramienta de escritura cuyas entradas revisables incluyan el repositorio, la rama, el commit base y el patch completo o una referencia inmutable al patch con un digest. Si el patch es demasiado grande para el canal, proporciona una ubicación de revisión segura y accesible y verifica que el servicio de escritura aplique el mismo contenido. Una instrucción vaga como «arregla las pruebas» no basta para aprobar un cambio específico en el repositorio.

Los valores documentados de $tool.parameters incluyen campos configurados con expresiones $fromAI(); no supongas que el mensaje muestra todas las credenciales fijas, los valores de configuración ocultos o los efectos posteriores. Mantén restringidos los ajustes fijos y ofrece a las personas revisoras otra forma de inspeccionarlos. Evita incluir secretos en los parámetros de la herramienta, ya que pueden aparecer en los mensajes de aprobación.

Añade una instrucción de sistema que nombre la herramienta sujeta a aprobación e indique al agente qué hacer en caso de rechazo. Por ejemplo:

Repository writes require human approval. Propose a patch against the
specified base commit and request the write tool only for that patch.
If approval is denied, do not retry the write or use another tool to make
the change. Tell the requester it was denied and ask for clarification.
Report test results only when supplied by the test runner.

Esta instrucción ayuda al agente a gestionar la revisión; no constituye una barrera de seguridad. Aplica los permisos y las restricciones de rama fuera del prompt.

Verifica el cambio aprobado

Activa el ejecutor de pruebas solo después de que el servicio de escritura devuelva un ID de commit. Configura el ejecutor para que extraiga ese ID, no el último commit de la rama, y ejecute un comando de una lista de permitidos definida por tu equipo. Para un repositorio cuyos responsables lo hayan elegido, un ejemplo de comando podría ser:

npm test

Ese comando es ilustrativo; usa las instrucciones de pruebas reales del proyecto. Trata el código del repositorio, los scripts de instalación de dependencias y la salida de las pruebas como contenido no confiable. Ejecútalos con acceso restringido a la red y al sistema de archivos, sin secretos de producción y con límites de tiempo y recursos. Que pase una batería de pruebas solo demuestra que las comprobaciones seleccionadas se superaron en ese entorno; no prueba que el cambio sea seguro o correcto.

Devuelve un resultado conciso que incluya la base aprobada, el nuevo commit, el comando de pruebas, el estado de éxito o fallo y un enlace a los registros. Si las pruebas fallan, el agente puede proponer un patch revisado, pero una nueva escritura necesita su propia aprobación. No fusiones automáticamente porque una persona revisora haya aprobado la llamada anterior a la herramienta.

Solución de problemas y límites operativos

La solicitud de aprobación carece de contexto útil

Comprueba qué entradas proporciona la IA y cuáles son visibles en $tool.parameters. Incluye la identidad del patch, la rama y la revisión base en la entrada revisable de la herramienta o proporciona un artefacto de revisión seguro e inmutable. Si la persona revisora no puede identificar la escritura exacta, debe rechazarla.

El agente no puede llamar a la herramienta

Primero prueba una herramienta inocua con independencia de los permisos del repositorio. Comprueba el nodo de n8n, el endpoint de OneMux, el modelo seleccionado y los parámetros necesarios para las llamadas a herramientas frente a su documentación vigente. Las fuentes proporcionadas no verifican ninguna combinación concreta de modelo y nodo.

La rama avanzó o las pruebas no terminaron

Rechaza una escritura desactualizada en lugar de aplicar un patch sobre una base diferente. Si se agota el tiempo de espera, se produce un error del ejecutor o falta el registro, informa de que la verificación está incompleta. Vuelve a ejecutar las pruebas sobre el mismo commit cuando corresponda; solicita una nueva aprobación si cambia la escritura propuesta.

Conclusión

El límite útil es preciso: una persona aprueba una escritura específica en el repositorio y un ejecutor aislado verifica el commit resultante. n8n proporciona el flujo documentado de pausa y aprobación a nivel de herramienta; el servicio de repositorio, el ejecutor, los permisos y el proceso de revisión aportan las demás salvaguardas. Usa OneMux como capa de acceso a modelos solo después de confirmar que el endpoint y los parámetros elegidos funcionan con tu configuración de n8n.

Fuentes

• n8n: Human-in-the-loop for tools — comportamiento de aprobación de herramientas, configuración, canales de revisión y variables de mensajes de revisión.
• Documentación de OneMux — consulta los datos actuales de conexión a la API.