Files

Dom a679fbb62b 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>

2026-04-05 12:41:01 +02:00

4.5 KiB

Raw Blame History

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 :

{
  "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 :

Capturer la fenêtre active
Comparer titre de fenêtre (rapide, gratuit)
Si mismatch → décrire l'état via gemma4 (texte pur, pas d'image)
Comparer état décrit vs expected_state
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 :

Identifie le workflow appris ("traiter un dossier")
Liste les éléments (fichiers de janvier)
Pour chaque élément, instancie le template avec les variables
Lance l'acteur sur chaque instance
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

Phase 1 d'abord — enrichir l'enregistrement (intentions + variables + état)
Phase 2 ensuite — acteur qui décide pendant le replay
Phase 3 après — planificateur macro

Chaque phase est testable indépendamment.

4.5 KiB Raw Blame History