Explicaciones de Funcionalidades 01: El Motor de Orchestration de Agent Argo

Del primer encargo al parche revisado

Agent Argo no consiste en un único modelo que trabaje durante mucho tiempo en una tarea. Es un sistema que traduce el trabajo de software en pasos comprensibles: planificar, dividir, editar, revisar, corregir y luego proponer la toma.

Con este artículo comienza la serie "Explicaciones de Funcionalidades". Hace comprensibles los mecanismos centrales de Agent Argo – no como promesas de marketing, sino según su uso real. El inicio es el Motor de Orchestration: el flujo que convierte una exigencia en un proceso de trabajo controlado.

1. Antes de comenzar: Calidad, Costos y Autonomía establecidos

Antes de que Argo trabaje en una tarea, son importantes dos decisiones. Están intencionadamente separadas:

1. ¿Cómo debe Argo equilibrar costos y calidad del resultado?
2. ¿Hasta qué punto puede actuar Argo de forma autónoma en el proyecto?

Esto evita un conflicto típico de objetivos: Un recorrido exhaustivo no debe obtener automáticamente más derechos de escritura. Y un recorrido autónomo no debe elegir automáticamente modelos costosos.

Los tres niveles para Costos y Calidad

El Router de modelos conoce tres modos comprensibles. Cambian cómo influyen el precio y el nivel del modelo en la selección; el skill requerido siempre es central.

Los perfiles operativos Rápido & económico, Equilibrado y Exhaustivo agrupan este modo del router con otras decisiones: por ejemplo, si el pensamiento colectivo se observa o se ejecuta activamente, si la verificación es vinculante y si Argo puede escalar más fuerte en caso de error.

Los tres niveles de Autonomía

La autonomía no regula qué considera Argo correcto, sino cuándo necesita a un humano para eso.

En el código, estas reglas son más precisas que readonly, confirm_write, auto_write y bypass. Los tres niveles las hacen manejables; la política del proyecto sigue siendo la última instancia. Puede excluir proveedores en la nube, permitir solo modelos locales, bloquear accesos a red, limitar comandos, proteger Secrets o establecer un límite de costos.

2. El Nivel Ejecutivo convierte el encargo en un plan

El usuario describe inicialmente el objetivo en lenguaje natural. El Nivel Ejecutivo de Argo recibe un resumen limitado del proyecto, el catálogo de modelos disponibles y información relevante del proyecto. Puede preguntar primero si hay preguntas abiertas o generar un plan.

Un plan no es solo una lista de tareas. Cada tarea recibe un rol, una descripción, dependencias y habilidades necesarias – por ejemplo coding, planning, qa_review o context_comprehension. Para tareas difíciles, también puede marcar una dificultad mayor. El Nivel Ejecutivo no nombra estrictamente un modelo: describe el trabajo, y el router decide después por tarea el modelo adecuado.

El plan permanece como la acuerdo legible por humanos sobre el proyecto, mientras la ejecución puede adaptarse.

3. Del plan se crea un Gráfico de Tareas

Después de la aprobación del plan, Argo convierte las tareas en un Gráfico de Tareas. Un nodo solo puede ejecutarse cuando sus dependencias se hayan completado exitosamente. Tareas independientes pueden correr en paralelo.

El Programador ordena nodos listos según una heurística de beneficio comprensible: calidad esperada menos penalidades de costos, tiempo y riesgo. Si un nodo está en el camino crítico, recibe prioridad en caso de empate, porque determina la duración total del recorrido.

En caso de alta incertidumbre o riesgo, Argo puede elegir antes de la ejecución un modo de pensamiento colectivo: desarrollar múltiples perspectivas, criticarse mutuamente y entregar un enfoque de trabajo fundamentado para el Worker. Si esto se registra o se ejecuta realmente, depende del perfil operativo elegido antes del recorrido.

4. Antes de cada tarea: Contexto adecuado, habilidades y modelo

Antes de que un Worker comience, Argo construye un contexto adaptado al rol y la tarea. Incluye archivos relevantes, resultados de dependencias y – si está activado – un paquete de memoria compacto junto con instrucciones de habilidades adecuadas. Argo no toma ciegamente todo el conocimiento del proyecto en el prompt. La memoria y las habilidades se eligen según relevancia, origen, actualidad, costos y estado de seguridad.

Luego, el Router de modelos selecciona un modelo. Primero se excluyen candidatos que no estén disponibles, que no tengan suficiente ventana de contexto, cuyo cupo esté agotado o que violen la política activa. De los modelos restantes, Argo evalúa cuatro factores:

• Ajuste de habilidades: ¿Cómo bien está evaluado un modelo para las habilidades necesarias? Si hay múltiples habilidades, se considera el promedio.
• Costos: ¿Cuánto cuesta la solicitud – o si está activo el rutas de costos, el resultado esperado?
• Nivel del modelo: Tareas difíciles, críticas de seguridad, arquitectura y revisiones pueden preferir una etapa flagship.
• Valores de experiencia: Después de suficientes resultados reales, entran en juego la tasa de éxito y repetición más reciente de una combinación modelo/habilidad.

Para el cálculo de costos, Argo puede usar el Costo Esperado de Éxito: precio directo, repeticiones esperadas, esfuerzo de verificación, posible re trabajo y una pequeña penalización de latencia. Un llamado individual barato no es automáticamente la solución más barata si falla con frecuencia o requiere re trabajo.

Una sugerencia explícita de modelo solo se acepta si está disponible, permitida por la política y lo suficientemente grande para el contexto. La planificación, delegación y comprensión del contexto del Nivel Ejecutivo usan un modelo fuerte, seleccionado específicamente para estas tres habilidades.

5. El Worker edita la tarea en pequeños pasos verificables

Un Worker no trabaja con una sola respuesta. Recorre un bucle limitado de ReAct:

1. El modelo sugiere acciones estructuradas – por ejemplo, leer archivos, buscar, ejecutar pruebas o escribir cambios.
2. El Ejecutor verifica permisos, ruta, riesgo de comandos y política activa.
3. Argo ejecuta solo acciones permitidas.
4. Los resultados, diferencias y mensajes de error fluyen como observación de vuelta al modelo.
5. Basado en esto, el Worker corrige su siguiente paso o cierra la tarea.

De esta manera, un agente puede leer primero el código afectado, hacer un cambio, ejecutar una prueba y incluir el resultado de la prueba en la próxima decisión. El flujo completo permanece visible en el registro del recorrido.

También la salida se verifica. Si un modelo entrega JSON de acción inválido, Argo puede solicitar un bucle de reparación limitado. En modo estricto, una salida defectuosa se rechaza permanentemente, en lugar de interpretar texto ambiguo como acción.

6. En caso de errores: Corregir de manera específica en lugar de repetir ciegamente

No cada tarea fallida significa que todo el recorrido falló. El Motor de Orchestration distingue causas de errores y reacciona controladamente:

• Un error temporal puede intentarse nuevamente dentro de límites fijos.
• Un veredicto de verificación duro proporciona su crítica específica como encargo para el próximo intento.
• Si está activada la cascada, el próximo intento toma las lecciones del anterior, en lugar de comenzar desde cero.
• Después de un error, Argo puede preferir un modelo más fuerte.
• Si un presupuesto se agota, no se inicia un intento ciego caro: El nodo termina con un resultado parcial documentado o se hace visible la escalada.

La estrategia de nodos decide finalmente si una tarea puede saltarse, falla controladamente o necesita una decisión del usuario. Las tareas dependientes reciben solo resultados parciales confirmados. Así, un error local no se convierte en un error silencioso que se propaga por el resto del plan.

7. Después de la implementación: Revisión, verificación y un posible ciclo adicional

Cuando las tareas planificadas se hayan editado, Argo revisa el estado integrado desde múltiples perspectivas:

• El Agente de QA puede leer archivos y ejecutar comandos de prueba.
• El Agente de Arquitectura verifica la estructura leyendo y permanece consciente sin derechos de escritura.
• Verificadores deterministas pueden ejecutar pruebas, comprobación de tipo o linting como oráculos objetivos.
• Los hallazgos basados en modelos y deterministas se combinan en un juicio general.

Si el QA, la Arquitectura o un verificador vinculante encuentran problemas, Argo asigna los hallazgos a las tareas afectadas. Solo estas tareas se reeditan con el feedback concreto. Luego vuelve la revisión y verificación. Sin modo de consenso, esta bucle es limitada; en un modo de consenso explícitamente elegido, continúa hasta que el usuario detenga o los revisores coincidan.

Un verificador en modo observador documenta hallazgos, pero no bloquea. En modo vinculante, un hallazgo duro puede impedir que el resultado se considere exitoso. Así, se elige la estricta por perfil operativo sin perder la trazabilidad.

8. Solo cuando el estado se verifica: Documentación y resumen del CEO

Después de un ciclo de trabajo y verificación completado, un agente de documentación puede registrar los cambios. Luego, el Nivel Ejecutivo crea el resumen para el usuario: ¿Qué se logró? ¿Qué quedó abierto? ¿Qué verificaciones funcionaron? ¿Qué archivos o decisiones están involucrados?

El resultado es más que un texto de chat. El recorrido genera una identificación compartida para plan, elección de modelos, costos, acciones, juicios de verificación, interrupciones del usuario y decisiones posteriores de parche. Así se puede rastrear cómo Argo llegó a un resultado.

9. Finalmente, el humano decide sobre el workspace real

Por defecto, Argo trabaja en un Worktree aislado. Los cambios allí están como un parche, no aún en el proyecto real. Dependiendo del nivel de autonomía, sucede uno de tres:

• El parche permanece para su aceptación, toma parcial, edición o rechazo.
• Un parche exitoso se toma automáticamente.
• En caso de conflictos con archivos modificados entre el tiempo, Argo se detiene visible; no sobrescribe cambios ajenos.

Un recorrido fallido no se aplica automáticamente. También una configuración muy autónoma no eleva la política: Protección de Secrets, reglas de comandos, límites de proveedores, límites de presupuesto y puertas humanas necesarias permanecen efectivas.

¿Qué hace el Motor de Orchestration?

El Motor de Orchestration no solo decide qué modelo responderá a continuación. Conecta la intención del usuario, configuraciones, planificación, paralelización, elección de modelos, uso de herramientas, corrección de errores, garantía de calidad y toma segura en un flujo cohesivo.

El estándar no es "máximo posible de agentes". Se crea trabajo adicional solo donde esté justificado: un modelo más fuerte para una decisión arquitectónica difícil, un segundo enfoque de pensamiento ante la incertidumbre, un retry objetivo después de una queja del Verificador o una aprobación humana antes de un efecto riesgoso.

El rumbo está establecido.