docs: Plan Acteur Intelligent V1 — architecture 3 niveaux
MACRO : planificateur LLM (décompose "traite les dossiers de janvier") MÉSO : acteur décisionnel (regarde, comprend, décide, agit) MICRO : grounding + exécution (localise et clique) Phase 1 = workflows comme templates avec variables Phase 2 = acteur qui compare états et décide Phase 3 = planificateur macro avec boucles Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Dom
146
docs/PLAN_ACTEUR_V1.md
Normal file
146
docs/PLAN_ACTEUR_V1.md
Normal file
@@ -0,0 +1,146 @@
|
||||
# Plan Acteur Intelligent — RPA Vision V3
|
||||
|
||||
**Date** : 5 avril 2026
|
||||
**Validé par** : Dom + Claude
|
||||
|
||||
---
|
||||
|
||||
## Vision finale
|
||||
|
||||
L'utilisateur dit : "Traite-moi tous les dossiers du mois de janvier"
|
||||
Le robot exécute. Autonome, adaptatif, intelligent.
|
||||
|
||||
---
|
||||
|
||||
## Architecture 3 niveaux
|
||||
|
||||
```
|
||||
MACRO → Planificateur LLM
|
||||
"traite les dossiers de janvier"
|
||||
→ décompose en étapes
|
||||
→ boucle sur les éléments
|
||||
→ rend compte des résultats
|
||||
|
||||
MÉSO → Acteur intelligent
|
||||
Pour chaque étape :
|
||||
→ regarde l'écran (gemma4)
|
||||
→ comprend l'état
|
||||
→ décide : agir / adapter / passer
|
||||
→ exécute l'action
|
||||
|
||||
MICRO → Grounding + exécution
|
||||
→ qwen2.5vl localise l'élément (bbox_2d)
|
||||
→ Bézier mouse + char-by-char typing
|
||||
→ Polling titre pour vérification
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## État actuel (5 avril 2026)
|
||||
|
||||
### MICRO — Opérationnel
|
||||
- Grounding qwen2.5vl:7b sur GPU (Ollama 0.16.3, port 11434)
|
||||
- Grounding sur fenêtre active (crop depuis screenshot live)
|
||||
- Template matching 80x80 pour icônes (seuil 0.90)
|
||||
- Position hint pour désambiguïser (en bas, en haut, à gauche)
|
||||
- Pré-vérification titre fenêtre (par nom d'application)
|
||||
- Post-vérification polling titre (max 10s)
|
||||
- Bézier mouse + frappe char-by-char (anti-bot)
|
||||
|
||||
### MÉSO — À construire
|
||||
- gemma4:e4b disponible sur GPU (Docker Ollama 0.20, port 11435)
|
||||
- Enrichissement build_replay : gemma4 lit les éléments sans OCR ✓
|
||||
- Auto-déchargement gemma4 après build ✓
|
||||
- Manque : boucle perception → compréhension → décision au replay
|
||||
|
||||
### MACRO — À concevoir
|
||||
- Pas encore démarré
|
||||
- Nécessite : workflows comme templates avec variables
|
||||
|
||||
---
|
||||
|
||||
## Plan d'implémentation
|
||||
|
||||
### Phase 1 : Workflow comme template (build_replay)
|
||||
|
||||
**Objectif** : l'enregistrement produit un template paramétrable
|
||||
|
||||
Pour chaque action, stocker :
|
||||
- `intention` : ce que l'utilisateur veut faire (gemma4)
|
||||
- `variables` : les données qui changent (nom de fichier, texte, date)
|
||||
- `expected_state` : description de l'écran avant l'action (gemma4)
|
||||
- `expected_result` : description de l'écran après l'action
|
||||
|
||||
Exemple :
|
||||
```json
|
||||
{
|
||||
"intention": "Ouvrir un fichier existant dans le Bloc-notes",
|
||||
"action": "click",
|
||||
"by_text": "voiture elec",
|
||||
"variables": {"filename": "voiture elec"},
|
||||
"expected_state": "Bloc-notes ouvert avec plusieurs onglets",
|
||||
"expected_result": "L'onglet du fichier est actif"
|
||||
}
|
||||
```
|
||||
|
||||
**Moteur** : gemma4 (Docker, port 11435) — une seule fois pendant le build
|
||||
**Impact** : le build_replay devient plus riche, pas de changement au replay
|
||||
|
||||
### Phase 2 : Acteur décisionnel (replay)
|
||||
|
||||
**Objectif** : l'acteur compare l'état attendu et décide
|
||||
|
||||
Avant chaque action :
|
||||
1. Capturer la fenêtre active
|
||||
2. Comparer titre de fenêtre (rapide, gratuit)
|
||||
3. Si mismatch → décrire l'état via gemma4 (texte pur, pas d'image)
|
||||
4. Comparer état décrit vs expected_state
|
||||
5. Décider : exécuter / adapter / passer
|
||||
|
||||
La décision est prise par gemma4 en **mode texte** (pas d'image = pas de VRAM) :
|
||||
```
|
||||
État attendu : "Bloc-notes ouvert avec un document vide"
|
||||
État actuel : "Bloc-notes ouvert avec du contenu existant"
|
||||
Action prévue : "Taper du texte"
|
||||
→ Décision : "Ouvrir un nouvel onglet avant de taper"
|
||||
```
|
||||
|
||||
**Moteur** : gemma4 texte (CPU, rapide) pour les décisions
|
||||
**Impact** : changement dans l'executor côté agent
|
||||
|
||||
### Phase 3 : Planificateur (macro)
|
||||
|
||||
**Objectif** : décomposer une instruction en étapes
|
||||
|
||||
L'utilisateur dit : "Traite les dossiers de janvier"
|
||||
Le planificateur :
|
||||
1. Identifie le workflow appris ("traiter un dossier")
|
||||
2. Liste les éléments (fichiers de janvier)
|
||||
3. Pour chaque élément, instancie le template avec les variables
|
||||
4. Lance l'acteur sur chaque instance
|
||||
5. Collecte les résultats
|
||||
|
||||
**Moteur** : LLM (gemma4 ou plus gros modèle)
|
||||
**Impact** : nouveau module de planification
|
||||
|
||||
---
|
||||
|
||||
## Contraintes techniques
|
||||
|
||||
| Ressource | Utilisation |
|
||||
|-----------|-------------|
|
||||
| GPU (12 GB) | Un seul modèle VLM à la fois |
|
||||
| Port 11434 (host) | qwen2.5vl:7b — grounding (replay) |
|
||||
| Port 11435 (Docker) | gemma4:e4b — compréhension (build + décision) |
|
||||
| Séquencement | Build (gemma4) → auto-unload → Replay (qwen2.5vl) |
|
||||
| Décisions replay | gemma4 en mode texte (CPU, pas de VRAM) |
|
||||
|
||||
---
|
||||
|
||||
## Ordre de réalisation
|
||||
|
||||
1. **Phase 1** d'abord — enrichir l'enregistrement (intentions + variables + état)
|
||||
2. **Phase 2** ensuite — acteur qui décide pendant le replay
|
||||
3. **Phase 3** après — planificateur macro
|
||||
|
||||
Chaque phase est testable indépendamment.
|
||||
Reference in New Issue
Block a user