Explications de fonctionnalités 01 : Orchestration Engine

De la première commande au patch vérifié

Agent Argo ne consiste pas en un unique modèle qui travaille le plus longtemps possible sur une tâche. C'est un système qui traduit le travail logiciel en étapes compréhensibles : planifier, diviser, traiter, vérifier, corriger et seulement alors présenter à la reprise.

Avec cet article commence la série "Explications de fonctionnalités". Elle rend compréhensibles les mécanismes centraux d'Agent Argo -- non comme promesse marketing, mais le long de leur utilisation réelle. Le coup d'envoi est donné par l'Orchestration Engine : le déroulement qui fait d'une exigence un processus de travail contrôlé.

1. Avant le démarrage : définir qualité, coûts et autonomie

Avant qu'Argo ne traite une tâche, deux décisions sont importantes. Elles sont volontairement séparées l'une de l'autre :

1. Comment Argo doit-il pondérer coûts et qualité de résultat ?
2. Dans quelle mesure Argo peut-il agir de manière autonome dans le projet ?

Cela évite un conflit d'objectifs typique : un passage approfondi ne doit pas automatiquement obtenir plus de droits d'écriture. Et un passage autonome ne doit pas automatiquement choisir des modèles coûteux.

Les trois niveaux pour coûts et qualité

Le routeur de modèles connaît trois modes compréhensibles. Ils modifient l'importance du prix et du niveau de modèle dans la sélection ; la compétence requise reste toujours centrale.

Les profils d'exploitation Rapide & peu coûteux, Équilibré et Approfondi regroupent ce mode de routeur avec d'autres décisions : par exemple, si la réflexion commune n'est qu'observée ou activement exécutée, si la vérification est contraignante et si Argo peut escalader plus fortement en cas d'échec.

Les trois niveaux d'autonomie

L'autonomie ne règle pas ce qu'Argo considère comme correct, mais quand il a besoin d'un humain pour cela.

Dans le code, ces règles sont implémentées plus précisément sous readonly, confirm_write, auto_write et bypass. Les trois niveaux les rendent utilisables ; mais la policy du projet reste toujours l'instance finale. Elle peut par exemple exclure des fournisseurs cloud, n'autoriser que des modèles locaux, bloquer les accès réseau, limiter les commandes, protéger les secrets ou fixer une limite de coûts.

2. Le niveau CEO transforme la commande en plan

L'utilisateur décrit d'abord l'objectif en langage naturel. Le niveau CEO d'Argo reçoit pour cela un aperçu de projet limité, le catalogue de modèles disponibles et des informations de projet pertinentes. Il peut d'abord poser des questions en cas de points ouverts ou générer un plan.

Un plan ne contient pas seulement une liste de tâches. Chaque tâche reçoit un rôle, une description, des dépendances et des compétences requises -- par exemple coding, planning, qa_review ou context_comprehension. Pour des tâches difficiles, un niveau de difficulté plus élevé peut aussi être noté. Le niveau CEO ne désigne pas rigidement un modèle : il décrit le travail, le routeur décide ensuite par tâche du modèle approprié.

Le plan reste ainsi l'accord lisible par l'humain sur l'entreprise, tandis que l'exécution peut rester adaptative.

3. Du plan naît un graphe de tâches

Après validation du plan, Argo transforme les tâches en graphe de tâches. Un nœud ne peut démarrer que lorsque ses dépendances sont terminées avec succès. Des tâches indépendantes peuvent s'exécuter en parallèle.

L'ordonnanceur trie les nœuds prêts selon une heuristique d'utilité compréhensible : qualité attendue moins pénalités de coûts, temps et risque. Si un nœud se trouve sur le chemin critique, il reçoit la priorité en cas d'égalité, car il détermine la durée totale du passage.

En cas d'incertitude ou de risque élevé, Argo peut sélectionner un mode de réflexion commune avant le traitement : plusieurs perspectives développent des approches, se critiquent mutuellement et livrent une approche de travail justifiée pour le worker. Si cela n'est que protocollé ou réellement exécuté, cela est décidé par le profil d'exploitation choisi avant le passage.

4. Avant chaque tâche : contexte adapté, compétences adaptées, modèle adapté

Avant le démarrage d'un worker, Argo construit un contexte adapté au rôle et à la tâche. Sont inclus les fichiers pertinents, les résultats des dépendances et -- si activé -- un paquet mémoire compact ainsi que des guides de compétences appropriés. Argo ne reprend pas aveuglément tout le savoir du projet dans le prompt. Mémoire et compétences sont sélectionnés selon pertinence, origine, actualité, coûts et statut de sécurité.

Puis le routeur de modèles choisit un modèle. D'abord sont exclus les candidats qui ne sont pas accessibles, n'ont pas de fenêtre de contexte suffisante, dont le contingent est épuisé ou qui violent la policy active. Des modèles restants, Argo évalue quatre facteurs :

• Adéquation des capacités : Dans quelle mesure un modèle est-il bien évalué pour les compétences requises ? Pour plusieurs compétences, on considère la moyenne.
• Coûts : Combien coûte la requête -- ou, avec routage de coûts actif, le résultat vraisemblablement réussi ?
• Niveau de modèle : Les tâches difficiles, critiques pour la sécurité, d'architecture et de revue peuvent privilégier un niveau flagship.
• Valeurs d'expérience : Après suffisamment de vrais résultats, entrent en ligne de compte le taux de réussite et de répétition le plus récent d'une combinaison modèle/competence.

Pour le calcul des coûts, Argo peut utiliser l'Expected Cost of Success : prix direct, répétitions attendues, effort de vérification, retouches possibles et une petite pénalité de latence. Un appel unique bon marché n'est donc pas automatiquement la solution la plus avantageuse s'il échoue plus souvent ou déclenche des retouches.

Une recommandation de modèle explicite n'est acceptée que si elle est disponible, autorisée par la policy et assez grande pour le contexte. La planification, la délégation et la compréhension de contexte du niveau CEO utilisent à nouveau un modèle fort, spécialement sélectionné pour ces trois capacités.

5. Le worker traite la tâche en petits étapes vérifiables

Un worker ne travaille pas avec une seule réponse. Il parcourt une boucle ReAct limitée :

1. Le modèle propose des actions structurées -- par exemple lire des fichiers, rechercher, exécuter des tests ou écrire des modifications.
2. L'exécuteur vérifie autorisation, chemin, risque de commande et policy active.
3. Argo exécute seulement les actions autorisées.
4. Résultats, diffs et messages d'erreur reviennent comme observation au modèle.
5. Sur cette base, le worker corrige son étape suivante ou termine la tâche.

Ainsi un agent peut par exemple d'abord lire le code concerné, puis effectuer une modification, exécuter un test et intégrer le résultat du test dans la décision suivante. Le déroulement complet reste visible dans le journal de passage.

La sortie elle-même est aussi vérifiée. Si un modèle livre un JSON d'action invalide, Argo peut demander une boucle de réparation limitée. En mode strict, une sortie durablement erronée est rejetée de manière contrôlée, au lieu d'interpréter un texte flou comme action.

6. En cas d'erreurs : corriger ciblé au lieu de répéter aveuglément

Tout tâche échouée ne signifie pas que tout le passage a échoué. L'Orchestration Engine distingue les causes d'erreur et réagit de manière contrôlée :

• Une erreur temporaire peut être retentée dans des limites fixes.
• Un verdict de vérification dur livre sa critique concrète comme mandat pour la prochaine tentative.
• Avec la cascade activée, la prochaine tentative reprend les connaissances de la précédente, au lieu de repartir de zéro.
• Après un échec, Argo peut privilégier un modèle plus fort.
• Si un budget est épuisé, aucune tentative aveugle coûteuse n'est lancée : le nœud se termine avec un résultat partiel documenté ou est escaladé visiblement.

La stratégie de nœud décide finalement si une tâche peut être sautée, échoue de manière contrôlée ou nécessite une décision utilisateur. Les tâches dépendantes reçoivent exclusivement des résultats partiels confirmés. Ainsi une erreur locale ne devient pas une erreur silencieuse qui se propage dans le reste du plan.

7. Après la réalisation : revue, vérification et cycle supplémentaire possible

Sont les tâches planifiées traitées, Argo vérifie l'état intégré sous plusieurs angles :

• L'agent QA peut lire des fichiers et exécuter des commandes de test.
• L'agent architecture vérifie la structure en lecture seule et reste consciemment sans droits d'écriture.
• Des vérificateurs déterministes peuvent exécuter tests, vérification de types ou linting comme oracles objectifs.
• Les constats basés sur modèle et déterministes sont fusionnés en un verdict global.

Si QA, architecture ou un vérificateur contraignant trouvent des problèmes, Argo attribue les constats aux tâches concernées. Seules ces tâches sont retraitées avec le feedback concret. Suit à nouveau revue et vérification. Sans mode consensus, cette boucle est limitée ; dans un mode consensus expressément choisi, elle continue jusqu'à ce que l'utilisateur arrête ou que les vérificateurs approuvent.

Un vérificateur en mode observation documente les constats, mais ne bloque pas. En mode contraignant, un verdict dur peut empêcher que le résultat soit considéré comme réussi. Ainsi la rigueur peut être choisie par profil d'exploitation, sans abandonner la traçabilité.

8. Seulement quand l'état est vérifié : documentation et résumé CEO

Après un cycle de travail et de vérification terminé, un agent de documentation peut consigner les modifications. Ensuite, le niveau CEO crée le résumé pour l'utilisateur : Qu'a-t-on fait ? Qu'est-ce qui est resté ouvert ? Quelles vérifications ont tourné ? Quels fichiers ou décisions sont concernés ?

Le résultat est plus qu'un texte de chat. Le passage porte une désignation commune pour plan, choix de modèle, coûts, actions, verdicts de vérification, interruptions utilisateur et décisions de patch ultérieures. Ainsi on peut retracer comment Argo est parvenu à un résultat.

9. À la fin, l'humain décide sur le vrai workspace

Par défaut, Argo travaille dans un worktree isolé. Les modifications s'y trouvent comme patch, pas silencieusement dans le vrai projet. Selon le niveau d'autonomie, se passe ensuite l'une de trois choses :

• Le patch reste prêt pour acceptation, reprise partielle, retouche ou rejet.
• Un patch réussi est automatiquement repris.
• En cas de conflits avec des fichiers modifiés entre-temps, Argo s'arrête visiblement ; il n'écrase pas de modifications étrangères.

Un passage échoué n'est pas automatiquement appliqué. Une configuration très autonome ne lève pas non plus la policy : protection des secrets, règles de commandes, limites de fournisseurs, limites de budget et Human Gates nécessaires restent en vigueur.

Ce que réalise l'Orchestration Engine

L'Orchestration Engine ne décide pas seulement quel modèle répond ensuite. Elle relie intention utilisateur, réglages, planification, parallélisation, choix de modèle, utilisation d'outils, correction d'erreurs, assurance qualité et reprise sûre en un déroulement cohérent.

La mesure n'est pas "le plus d'agents possible". Du travail supplémentaire n'apparaît que là où il est justifié : un modèle plus fort pour une décision d'architecture difficile, une deuxième approche de réflexion en cas d'incertitude, un retry ciblé après une critique de vérificateur ou une validation humaine avant un effet risqué.

Le cap est ainsi fixé.