>> 2026 OpenClaw comme cerveau appelant les workflows Dify sur Mac mini M4 SlimVps 16 Go/256 Go : guide d'intégration avancé

OpenClaw comme cerveau qui appelle des workflows Dify conserve l’intention, la mémoire et les canaux dans la passerelle d’agent, tandis que les graphes multi-nœuds s’exécutent dans Dify — intégration avancée OpenClaw et workflows Dify sur un Mac mini M4 loué.

Introduction

OpenClaw comme cerveau signifie que la passerelle d’agent détient l’intention, la mémoire, les canaux et le routage d’outils, tandis que Dify exécute des workflows multi-nœuds (récupération RAG, branchement, nœuds de code, revue humaine) difficiles à reconstruire dans un seul prompt.

Dans une intégration OpenClaw et workflows Dify, l’utilisateur parle à OpenClaw via Telegram, Slack ou un webhook ; OpenClaw décide quand invoquer Dify ; Dify exécute le graphe lourd ; OpenClaw interprète le JSON et répond en langage naturel.

Un Mac mini M4 SlimVps (16 Go / 256 Go de base) est un hôte d’exploitation solide pour OpenClaw : chaîne d’outils macOS, exploitation centrée SSH, et nœuds proches de l’APAC (Hong Kong, Tokyo, Séoul, Singapour) lorsque Dify tourne dans la même région. Terminez le déploiement léger d’OpenClaw avant de câbler Dify — une passerelle stable sépare plus facilement les pannes d’outils HTTP des problèmes de canaux.

Ce guide est avancé : il suppose que vous maîtrisez déjà les canaux de passerelle et les limites de débit et que vous savez lire la récupération HTTP des modèles hébergés lorsque les appels LLM amont dans Dify échouent.

Pourquoi séparer OpenClaw et Dify

Gain concret : votre workflow Dify peut appeler trois API internes, exécuter un classifieur et renvoyer un schéma JSON — OpenClaw n’a besoin que d’un outil HTTP nommé run_ops_workflow au lieu de six instructions de prompt fragiles.

Selon les spécifications du Mac mini M4 d’Apple, les 16 Go de mémoire unifiée sont partagés entre OpenClaw, une pile Docker Dify locale et macOS — planifiez en conséquence (voir le tableau RAM ci-dessous).

Architecture et flux de données

Composants

Cycle de vie d’une requête

1. L’utilisateur envoie : « Résume le ticket #8842 et rédige une note de remboursement. »
2. Le planificateur OpenClaw choisit l’outil dify_refund_workflow.
3. HTTP POST vers le point de terminaison Workflow Run de Dify avec JSON inputs et response_mode: blocking (ou streaming si le canal gère des fragments).
4. Dify exécute les nœuds de récupération et LLM ; renvoie l’objet outputs.
5. OpenClaw mappe outputs.summary et outputs.draft dans la réponse du canal ; enregistre un extrait de transcription.

Paramètre de sécurité : liez OpenClaw à 127.0.0.1 conformément à la sécurité et le réseau. Atteignez Dify en TLS sur un nom d’hôte privé ou en loopback sur le même hôte — ne publiez pas l’interface d’administration Dify sur 0.0.0.0 sur un Mac loué.

Références officielles : documentation API Dify et le projet OpenClaw.

Topologies de déploiement sur Mac mini M4

Recommandation : commencez par la topologie A pendant sept jours ; passez à B seulement si les contrats exigent que toutes les charges restent sur l’hôte SlimVps. Surveillez le disque sous ~/.openclaw/ et les volumes Docker selon les budgets mémoire et disque.

Si l’auto-hébergement Dify tire modèles ou jeux de données via des liaisons transfrontalières congestionnées, placez Dify à HK/SG et gardez OpenClaw dans la même métropole — la latence RTT prime sur le CPU brut pour les appels de workflow bloquants.

Table de routage des workflows (politique du cerveau)

OpenClaw ne doit pas appeler Dify à chaque message. Définissez une table de routage que le planificateur peut citer :

Stockez les ID de workflow dans la configuration, pas dans les prompts. Faites pivoter les ID dans un seul fichier lorsque Dify publie la v4.

Guide en sept étapes

Étape 1 — Ligne de base de la passerelle OpenClaw

ssh user@your-slimvps-mac openclaw --version # expect 2026-era build curl -s http://127.0.0.1:11430/health

Critères de réussite : HTTP 200, plist launchd chargé, ≥25 Go libres sur le volume de démarrage.

Étape 2 — Publier un workflow Dify

Dans Dify Studio :

1. Construisez le workflow avec des variables d’entrée explicites (ticket_id, locale).
2. Ajoutez des variables de sortie (summary, draft, confidence).
3. Publiez → copiez la clé API et l’ID de workflow (ou l’ID d’application selon la version Dify).

Test depuis le Mac :

export DIFY_API_KEY="app-xxxxxxxx" curl -s -X POST "https://api.dify.ai/v1/workflows/run" \ -H "Authorization: Bearer $DIFY_API_KEY" \ -H "Content-Type: application/json" \ -d '{"inputs":{"ticket_id":"8842"},"response_mode":"blocking","user":"openclaw-smoke"}'

Critères de réussite : JSON avec data.outputs rempli en <30s depuis votre région SlimVps.

Étape 3 — Enregistrer l’outil HTTP OpenClaw

Ajoutez une définition d’outil (le fichier exact varie selon la build OpenClaw ; souvent sous ~/.openclaw/config/tools/) :

{ "name": "dify_refund", "description": "Exécuter le workflow de remboursement lorsque l'utilisateur mentionne un remboursement, une rétrofacturation ou un ID de ticket", "method": "POST", "url": "https://api.dify.ai/v1/workflows/run", "headers": { "Authorization": "Bearer ${DIFY_API_KEY}", "Content-Type": "application/json" }, "body_template": { "inputs": { "ticket_id": "{{ticket_id}}" }, "response_mode": "blocking", "user": "openclaw-{{session_id}}" } }

Injectez ${DIFY_API_KEY} via EnvironmentVariables de launchd, pas dans le plist lui-même.

Étape 4 — Mapper les sorties d’outil vers le texte du canal

Configurez les instructions de l’agent :

• Si confidence < 0.7, posez une question de clarification au lieu d’envoyer le brouillon.
• Tronquez draft à 4000 caractères pour Telegram.

Lancez une invocation manuelle d’outil depuis la CLI OpenClaw avant d’activer les canaux.

Étape 5 — Activer un canal

Suivez les canaux de passerelle : activez une surface, envoyez cinq messages de test, vérifiez que Dify n’est pas appelé pour les salutations.

Étape 6 — Observabilité

Journalisez chaque invocation :

Faites tourner les journaux chaque semaine sur les hôtes 256 Go.

Étape 7 — Durcissement production

• Réglez l’idempotence : passez un user stable ; évitez les brouillons de remboursement dupliqués lors des relances Telegram.
• Plafonnez les appels Dify concurrents à 2 sur 16 Go avec la topologie B.
• Documentez le repli : si Dify renvoie 5xx, répondez « workflow hors ligne » et appelez un humain — voir la matrice de récupération HTTP.

Budgets RAM et délais

Paliers de délai : 30s pour la fumée, 90s pour les opérations RAG, 120s pour les graphes remboursement/juridique. Le délai d’outil OpenClaw doit être ≥ délai interne Dify + 5s sinon vous verrez des échecs fantômes.

Dépannage

Erreur A — 401 Unauthorized depuis Dify

Schéma : les journaux d’outil OpenClaw montrent 401 immédiatement.

Correctif :

# Verify key on the Mac (same env launchd uses) launchctl print system/com.slimvps.openclaw-gateway | grep -i DIFY curl -s -o /dev/null -w "%{http_code}" -H "Authorization: Bearer $DIFY_API_KEY" \ https://api.dify.ai/v1/workflows/run

Faites pivoter la clé d’application dans Dify Studio ; mettez à jour l’environnement launchd ; launchctl kickstart -k system/com.slimvps.openclaw-gateway.

Erreur B — Délai d’outil alors que Dify tourne encore

Schéma : OpenClaw signale un échec d’outil ; l’historique Dify montre un succès 40s plus tard.

Correctif : augmentez le délai d’outil OpenClaw à 130s pour ce workflow, ou passez Dify en mode asynchrone avec un sous-workflow de sondage. Ne chaînez jamais deux graphes de 120s dans un même tour utilisateur sur des hôtes 16 Go.

Erreur C — Écart de schéma (outputs vide)

Schéma : HTTP 200 mais l’agent dit « je n’ai aucune donnée ».

Correctif : alignez les noms de variables de sortie Dify avec le mapping OpenClaw (summary vs text). Republiez le workflow ; incrémentez wf_*_v4 dans la table de routage.

Jalons de validation sur sept jours

Conclusion

L’intégration OpenClaw et workflows Dify fonctionne lorsqu’OpenClaw reste le cerveau (politique, canaux, mémoire) et Dify le muscle (graphes multi-étapes). Sur un Mac mini M4 SlimVps, commencez avec Dify Cloud et une passerelle localhost, appliquez les tables de routage et les paliers de délai, puis ne montez en charge que lorsque la RAM l’exige.

Consultez les tarifs SlimVps pour une location de validation de sept jours avant un engagement mensuel.

FAQ

Que signifie concrètement « OpenClaw comme cerveau » ?
OpenClaw détient la session, choisit les outils et formate les réponses. Dify exécute des workflows prédéfinis lorsque OpenClaw appelle l’outil HTTP — Dify ne remplace pas les connecteurs de canaux d’OpenClaw.

Puis-je faire tourner Dify et OpenClaw sur le même Mac mini M4 16 Go ?
Oui pour un pilote si Dify est léger et les appels concurrents restent ≤2. En production, les équipes séparent souvent Dify sur un autre hôte ou utilisent Dify Cloud pour éviter le swap lors des pics RAG.

Quelle API Dify OpenClaw doit-il appeler ?
Le point de terminaison REST Workflow Run publié pour votre espace, avec response_mode: blocking tant que vous n’avez pas implémenté le streaming partiel sur le canal.

Comment éviter les effets de bord dupliqués ?
Passez un identifiant user stable par session de chat, rendez les nœuds Dify idempotents si possible, et désactivez la relance automatique sur les outils paiement/remboursement.

Le trafic des workflows quitte-t-il le Mac SlimVps ?
Avec Dify Cloud, oui — les charges utiles sortent vers la région Dify. Avec un Dify auto-hébergé sur le même Mac, le trafic peut rester sur 127.0.0.1 si les deux services sont liés localement.

Où stocker les clés API ?
Dans les variables d’environnement launchd ou ~/.openclaw/secrets/ en permissions 600 — jamais dans les prompts de workflow ni dans git.

Articles connexes

• Déploiement léger OpenClaw
• Canaux de passerelle et limites de débit
• Récupération HTTP des modèles hébergés
• Sécurité et réseau
• Budgets mémoire et disque
• OpenClaw avec Ollama