7a. Planification Stratégique

L'outil de Planification Stratégique (ECHO Strategic Planner, version 1.0) est le Kernel exécutif chargé de concevoir, d'ajuster et de piloter des plans d'action structurés pour la résolution d'objectifs complexes. Contrairement aux outils ad-hoc, la planification stratégique ECHO est conçue comme un contrat d'exécution persistant, tracé en base de données et intégré de manière proprioceptive dans le contexte de l'agent.

Architecture Technique & Flux

Le module strategic_planner.py encapsule l'intelligence de planification à travers un système robuste à triple niveau (Fichiers, Base de données SQLite, Contexte d'exécution) reposant sur une cascade de LLM.

ComposantSpécification Technique
Source12-owui-tools/strategic_planner.py
Version de l'outil1.0
Persistance PhysiqueFichiers Markdown (.md) stockés dans le Vault : ECHO_USERS_ROOT/{user_id}/plans/{chat_id}/
Registre de ContrôleBase SQLite par chat (identity.db / {chat_id}.db via EchoStateManager)
ProprioceptionInjection automatique du statut des plans dans le Registre registre_plan de
Algorithme LLMCascade cognitive descendante résiliente (PRO ? FLASH ? LITE)

La Cascade Cognitive Descendante (_cascade_call)

L'agent planificateur ne repose pas sur un seul modèle rigide. Pour garantir la continuité du service même en cas de saturation des quotas API (erreurs 429 ou 500), l'outil utilise la méthode asynchrone _cascade_call(). Le système commence par le modèle le plus puissant configuré, puis descend automatiquement vers le niveau inférieur :

  1. MODEL_PRO (Niveau de réflexion maximal THINKING_LEVEL_PRO) : Utilisé par défaut pour la rédaction initiale d'un plan complexe (via build_plan).
  2. MODEL_FLASH (Niveau de réflexion intermédiaire THINKING_LEVEL_FLASH) : Modèle par défaut pour les modifications rapides et la mise à jour des statuts (via update_plan).
  3. MODEL_LITE (Niveau minimal) : Modèle de repli ultime assurant la résilience opérationnelle globale.

La signature du modèle ayant effectivement rédigé ou mis à jour le plan est conservée dans les métadonnées de l'en-tête (YAML Frontmatter) sous la clé author_model.

Protocole de Discussion Préliminaire & Clé d'Appel

?? Règle d'or : Ne pas appeler build_plan précipitamment

Un plan stratégique est un contrat d'exécution. Un objectif vague produit un plan vague. L'agent a l'obligation stricte d'engager une phase de discussion et de clarification avec l'utilisateur AVANT de déclencher le planificateur :

Cycle de Vie d'un Plan (YAML Frontmatter)

Chaque plan d'action débute à l'état draft (brouillon non exécutable) lors de son initialisation par build_plan. Il doit ensuite être validé par l'utilisateur (via une mise à jour d'état) pour transiter vers les autres états définis dans les constantes d'ECHO :

Format de Persistance du Plan (Markdown structuré)

Les plans d'action générés respectent une structure stricte en Markdown avec un en-tête de métadonnées YAML (Frontmatter) : 

---
plan_id: 1716734567
chat_id: 1b066fa6-e3dd-41ee-a7d8-726b0d9ad406
created_at: 2026-05-26T15:00:00Z
goal: "Nom de l'objectif stratégique"
author_model: gemini-3.1-pro-preview
status: draft
---

## ?? Objectif
(Reformulation et cadrage précis de la mission)

## ?? Plan d'action
- [ ] Étape 1 : Libellé de l'étape
  - [ ] Sous-tâche 1.1 : Description (? `nom_outil` si recommandation d'outil)
  - [/] Sous-tâche 1.2 : En cours d'exécution
  - [x] Sous-tâche 1.3 : Terminée

## ?? Contraintes & Risques
- Contrainte A...
- Risque opérationnel B...

## ? Critères de succès
- Critère 1 : ...
- Critère 2 : ...

Les Outils du Plan (API Function Calling)

Quatre fonctions Python asynchrones sont exposées au Kernel pour gérer intégralement le cycle de vie des plans :

FonctionArgumentsDescription et Comportement
build_plan goal (str), context (str), planner_model (Literal) Génère le fichier Markdown du plan à l'état draft en appliquant le prompt système SYSTEM_PROMPT_BUILD. Persiste le fichier dans le dossier de l'utilisateur, l'ajoute dans le registre SQLite de contrôle via save_plan_record et retourne le contenu Markdown complet.
read_plan plan_id (str) Résout le chemin physique du plan via recherche glob ({plan_id}_*.md) dans le répertoire des plans du chat. Lit et retourne le fichier Markdown complet (Frontmatter inclus).
update_plan plan_id (str), instructions (str), planner_model (Literal) Modifie le contenu d'un plan existant en appliquant le prompt de réécriture SYSTEM_PROMPT_UPDATE. Permet de cocher/décochez des cases (en attente [ ], en cours [/], terminée [x], échouée [!], ignorée [-]) ou de changer le statut global du plan. Si le statut du Frontmatter change, le registre SQLite est mis à jour en conséquence.
delete_plan plan_id (str) Supprime définitivement le fichier physique Markdown du plan et nettoie la table du registre SQLite (via delete_plan_record). Cette opération est irréversible.

?? Intégration proprioceptive (registre_plan)

À chaque nouveau tour de discussion, le filtre de contexte d'ECHO interroge le registre SQLite pour ce chat spécifique. Les métadonnées actives de tous les plans existants sont injectées de manière transparente dans le bloc proprioceptif <environnement_contexte> sous la structure registre_plan. Cela garantit que le modèle a toujours conscience des plans en cours, de leur statut global et de leur identifiant unique sans avoir besoin de lire les fichiers physiques.

? Retour à l'Arsenal    Passer à la Web Intelligence ?