Revue du module mira/cu/ (agent, crawler, actions, guard, browser, scraper) après le merge de la PR #17. Quatre axes d'amélioration identifiés, classés par valeur pour la démo (critère à 50 %). Chaque axe peut faire l'objet d'une branche/PR indépendante.
1. 🎯 Brancher le face-match dans le crawl (le plus gros gain démo)
Aujourd'hui le crawler récolte des images avec une description FR, mais ne fait aucun matching — or le pitch de Mira, c'est « retrouver les images de la victime ». La L2 a mergé le face-verifier avec un seam prévu pour ça (1d39f5b, « seam face-match analyzer »).
- Brancher chaque image récoltée sur le seam face-match pendant le crawl
- Émettre des événements
match en direct dans la live view (« ✅ correspondance 92 % »)
- C'est le beat qui transforme « un agent qui navigue » en « un agent qui trouve »
⚠️ Seam L2 → à coordonner avec la lane Backend avant d'y toucher.
2. 🛡 Robustesse — une erreur ponctuelle tue tout le crawl en live
- Pas d'isolation par page : un
goto qui timeout sur la page 3 remonte au try global de stream_crawl (mira/cu/crawler.py:171) et termine tout le crawl en error. → try/except par page : on note l'échec, on continue avec la frontière.
- Pas de retry sur l'API Gemini : un seul 429/503 transitoire dans
_run_cu_loop (mira/cu/agent.py:100) et le crawl est mort. → un retry avec backoff court.
response.candidates[0] non gardé (mira/cu/agent.py:103) : réponse vide/bloquée = crash brut au lieu d'un événement propre.
3. ⚡ Vitesse et coût de la boucle CU
- L'historique
contents accumule tous les screenshots PNG pleine taille à chaque étape (agent.py:115,158) — coût tokens et latence croissent à chaque action. Pratique recommandée Computer Use : ne garder que les ~3 derniers screenshots (élaguer les parts image des tours anciens, garder le texte).
- Double screenshot par étape : un PNG pour le modèle + un JPEG pour la frame live (
agent.py:83-87, 147-151). Une seule capture réutilisée = quelques centaines de ms gagnées par action.
_describe_page est séquentiel (~1-2 s/page, crawler.py:132) : prendre le screenshot puis lancer la description en tâche asyncio pendant le goto de la page suivante.
Estimation : 30-40 % de temps gagné sur un crawl de 6 pages (à ~20-40 s/page actuellement).
4. 🧭 Frontière agentique — l'agent choisit où aller
La file de liens est FIFO tronquée à MAX_LINKS=8 sans aucun tri (crawler.py:145) : le crawler peut griller son budget de 6 pages sur des pages sans intérêt.
- Faire classer les liens par l'agent (appel flash rapide : « lesquels de ces liens mènent probablement à des médias/profils ? ») — cohérent avec la décision 100 % Computer Use
- Early-stop quand l'objectif est atteint (N images cibles trouvées)
Priorisation proposée : axe 1 (face-match live) + axe 2 (robustesse, filet de sécurité pour le passage en live) d'abord ; axes 3 et 4 en bonus si le temps le permet.
Revue du module
mira/cu/(agent, crawler, actions, guard, browser, scraper) après le merge de la PR #17. Quatre axes d'amélioration identifiés, classés par valeur pour la démo (critère à 50 %). Chaque axe peut faire l'objet d'une branche/PR indépendante.1. 🎯 Brancher le face-match dans le crawl (le plus gros gain démo)
Aujourd'hui le crawler récolte des images avec une description FR, mais ne fait aucun matching — or le pitch de Mira, c'est « retrouver les images de la victime ». La L2 a mergé le face-verifier avec un seam prévu pour ça (
1d39f5b, « seam face-match analyzer »).matchen direct dans la live view (« ✅ correspondance 92 % »)2. 🛡 Robustesse — une erreur ponctuelle tue tout le crawl en live
gotoqui timeout sur la page 3 remonte autryglobal destream_crawl(mira/cu/crawler.py:171) et termine tout le crawl enerror. → try/except par page : on note l'échec, on continue avec la frontière._run_cu_loop(mira/cu/agent.py:100) et le crawl est mort. → un retry avec backoff court.response.candidates[0]non gardé (mira/cu/agent.py:103) : réponse vide/bloquée = crash brut au lieu d'un événement propre.3. ⚡ Vitesse et coût de la boucle CU
contentsaccumule tous les screenshots PNG pleine taille à chaque étape (agent.py:115,158) — coût tokens et latence croissent à chaque action. Pratique recommandée Computer Use : ne garder que les ~3 derniers screenshots (élaguer les parts image des tours anciens, garder le texte).agent.py:83-87,147-151). Une seule capture réutilisée = quelques centaines de ms gagnées par action._describe_pageest séquentiel (~1-2 s/page,crawler.py:132) : prendre le screenshot puis lancer la description en tâche asyncio pendant legotode la page suivante.Estimation : 30-40 % de temps gagné sur un crawl de 6 pages (à ~20-40 s/page actuellement).
4. 🧭 Frontière agentique — l'agent choisit où aller
La file de liens est FIFO tronquée à
MAX_LINKS=8sans aucun tri (crawler.py:145) : le crawler peut griller son budget de 6 pages sur des pages sans intérêt.Priorisation proposée : axe 1 (face-match live) + axe 2 (robustesse, filet de sécurité pour le passage en live) d'abord ; axes 3 et 4 en bonus si le temps le permet.