Ce que nous avons appris en créant des systèmes d'orchestration d'agents (à la dure)

DEV - 21/01
Nous avons passé une semaine à itérer sur la conception d'agents autonomes. Nous avons commencé avec des vibrations et des mots à la mode. Nous avons terminé...

Nous avons passé une semaine à itérer sur la conception d'agents autonomes. Nous avons commencé avec des vibrations et des mots à la mode. Nous avons terminé avec les scripts shell et les arbres de travail git. Voici ce qui a survécu.

Le point de départ : l’ingénierie des vibrations

Notre première tentative s'appelait "The Omni-Orchestrator" (oui, vraiment). Il avait une fonction de valeur :

Valeur utilisateur = (Qualité du résultat × Vitesse) / (Coût du jeton + Friction utilisateur)
Entrer en mode plein écran Quitter le mode plein écran

Il « instancie dynamiquement des sous-personnes » comme « Senior Rust Engineer » et « Legal Researcher ». Il promettait une « auto-optimisation récursive ».

La critique a été brutale :

« Dynamic Sub-Personas » est du théâtre. Vous n'instanciez rien, vous vous incitez simplement à jouer un rôle. "Senior Rust Engineer" vs "Claude qui connaît Rust" n'a aucune différence. C'est un pansement rapide qui s'évapore après une seule réponse.

Et:

"Récursif, auto-optimisant" : aucun mécanisme. Où est la boucle de rétroaction ? Où est la mesure ? Comment sait-il que ça va mieux ? Ce sont des vibrations, pas de l'architecture.

Note : 5/10. Bons concepts, pas d'exécution.

La première vraie amélioration : la gestion de l’État

La version 2 a ajouté une chose qui a tout changé : un fichier journal.

[ISO_TIMESTAMP] | [ÉTAT] | [ITERATION_ID] | [ACTION] | [RÉSULTAT] | [ARTEFACTS]
Entrer en mode plein écran Quitter le mode plein écran

Cela semble trivial. Ce n'était pas le cas. Le système d'origine n'avait pas de mémoire. Chaque réponse a recommencé. Maintenant, il y avait de la persévérance. Vous pourriez planter au milieu d'une tâche et reprendre. Vous pourriez vérifier ce qui s'est passé.

L'examen notait :

C’est la plus grande amélioration. L'original n'avait aucune mémoire. Maintenant, il y a de la persévérance. Vérifiable. Reprise. Cela seul rend la v2 viable là où la v1 ne l'était pas.

Leçon : Les fichiers sont votre base de données. Si l’état n’est pas écrit, il n’existe pas.

Tuer la métrique floue : TDD comme critère d'acceptation

La fonction value était élégante et inutile. Comment mesurez-vous la « qualité des résultats » ? Ce n'est pas le cas.

La version 2 l'a remplacé par quelque chose de binaire : un test qui échoue, puis réussit.

ÉTAT 2 : CONFIGURATION PILOTÉE PAR TEST Objectif : Créer le signal de défaillance. Actions : 1. Créer le script de test défini dans l'ÉTAT 1 2. Exécuter le test 3. Vérifier : Le test doit échouer. ÉTAT 3 : BOUCLE D'EXÉCUTION Objectif : Réussir le test. Porte de sortie : to...
[Courte citation de 8% de l'article original]
Loading...