SoClaw Intégration de reconquête

SoClaw est le système de reconquête autonome de Flash : une liste de travail interne de membres à fort potentiel et à risque, un ensemble d'outils MCP contrôlés et une compétence de décision. Vous l'utilisez en exécutant un agent OpenClaw — un environnement d'exécution open source que vous hébergez vous-même — qui charge la compétence SoClaw et gère la boucle via une clé d'agent limitée et à portée restreinte.

Ce guide est destiné à cet opérateur/intégrateur. Pour une présentation générale de l'activité, consultez la page produit SoClaw. Les outils de reconquête s'appuient sur le même serveur MCP contrôlé, décrit dans le guide d'intégration MCP.

Outils de reconquête (ensemble d'outils winback)

Les trois outils d'écriture sont rate-only — protégés par le commutateur de pause instantanée et une limite de taux d'écriture, sans plafond de valeur par appel car ils n'ont aucune valeur nominale. Référencez chaque outil comme Flash:<tool_name>.

Leviers financiers — liés à une tâche

Ce sont les outils d'écriture standard Flash. Un agent de récupération DOIT réussir le test task_id de la tâche revendiquée ; sans cela, l'écriture de récupération est refusée avec le code WINBACK_TASK_REQUIRED. L'identifiant de la tâche (task_id) rend l'écriture idempotente et active le mécanisme de blocage côté serveur. Une action financière par tâche.

Déploiement autonome de l'environnement d'exécution OpenClaw et de la compétence SoClaw

Flash permet de reconquérir système (la liste de travail, la MCP outils, l'application des mesures de sécurité) et les SoClaw compétence (doctrine décisionnelle + guide pratique). Vous fournissez l'environnement d'exécution : auto-hébergement d'un OpenClaw agent, pointez-le vers Flash's MCP Serveur avec votre clé d'agent et chargez la compétence. L'auto-hébergement vous offre un contrôle opérationnel — configuration, surveillance, gestion des versions et suppression de la clé — mais il ne permet pas de gérer les problèmes liés à l'hébergement. Non intéressé(e) assouplir le modèle de sécurité : MCP Le côté considère l'agent comme externe, quoi qu'il arrive.

Enregistrez Flash comme serveur HTTP MCP (la clé du serveur doit être exactement flash) :

export FLASH_WINBACK_KEY="fl_live_your_agent_key_here"

# in the OpenClaw runtime's MCP config
{
  "mcpServers": {
    "flash": {
      "type": "http",
      "url": "https://flash.socialhub.ai/api/mcp",
      "headers": { "Authorization": "Bearer ${FLASH_WINBACK_KEY}" }
    }
  }
}

Téléchargez la compétence SoClaw (SKILL.md + doctrine · leviers · flux de travail · référence), déposez-la dans le répertoire des compétences de votre environnement d'exécution OpenClaw et exécutez la boucle :

SoClaw gère également une liste de décisions au-delà de la reconquête client — approbation (examen des commandes par canal) et fraude (parrainage au sein du même foyer) — via la même boucle de location (claim_agent_task → get_agent_task → complete_agent_task). Les effets sont traités par les écritures idempotentes existantes de Flash ; chaque décision peut également être transmise à un humain.

Autocontrôles :

• L'agent ne doit voir que les outils de reconquête et les leviers autorisés par les autorisations de sa clé ; rien d'autre.
• Un premier claim_winback_task renvoie une tâche avec un bail, ou NO_TASKS_AVAILABLE / WINBACK_DISABLED — les deux sont des conditions d'arrêt normales, pas des échecs.
• Un appel de coupon/points sans task_id doit revenir WINBACK_TASK_REQUIRED — confirmez que votre boucle ancre toujours le levier à la tâche réclamée.

Gestion des erreurs et codes

Deux canaux. Une erreur de protocole (JSON-RPC : méthode incorrecte / outil inconnu) indique généralement un nom d'outil erroné ; vérifiez le préfixe Flash: et l'orthographe. Un résultat isError: true constitue une limite stricte et lisible : transmettez-la une seule fois et passez à l’étape suivante. Ne tentez jamais de la contourner.

Encore une précision : meta.hasData: false provenant d’un outil de mesure correspond à un succès, et non à une erreur — cela signifie « aucune donnée pour cette fenêtre », jamais 0.

Classement Uplift – comment la liste de travail est ordonnée

La priorité de la liste de travail est valeur à risque × augmentation lorsqu'un modèle d'amélioration convient à l'équipe, et valeur à risque pure dans le cas contraire. Le changement est automatique, décidé par scan – il n’y a rien à configurer.

Le modèle est un modèle logistique à deux facteurs (two-model uplift), ajusté par équipe à chaque analyse à partir des données de validation aléatoires propres au programme — uniquement les lignes d'attribution matures, avec la même définition de conversion pour les deux bras :

uplift(x) = P(convert | treated, x) − P(convert | holdout, x)

Les classements sont déterministes (aucun échantillonnage aléatoire) : les mêmes données produisent toujours le même classement.

Exemples de portes – toutes doivent être réussies avant que le modèle soit fiable

• ≥ 200 rangées matures traitées
• ≥ 50 lignes matures holdout
• ≥ 20 conversions
• Convergence des deux solutions logistiques

En dessous du seuil any, le modèle est rejeté pour cette analyse (null) et le classement se base uniquement sur la valeur à risque (zéro changement de comportement), et non sur une estimation dégradée. Une estimation d'amélioration négative (un effet inverse mesuré) ramène la priorité de la tâche à 0 ; la tâche reste visible dans la liste des tâches, avec les chiffres expliquant pourquoi.