2026 VPS Linux cloud multi-agents : LangGraph vs OpenClaw Gateway, systemd et dépannage par niveaux FAQ

La semaine dernière, une équipe a repris la topologie Supervisor + Worker de notre article sur l’architecture de pipeline multi-agent et l’a déployée telle quelle sur un Linux VPS. En journée, tout semblait propre: événements Slack reçus, réponses générées, démonstration convaincante. Puis, après un redémarrage de maintenance, les symptômes classiques sont apparus: validations humaines perdues, reprise depuis de vieux checkpoint, exécutions Cron en double et incohérence entre état canal et état graphe. Le problème n’était pas le LLM, mais l’absence de séparation d’exploitation.

En production, multi-agent ne veut pas dire "lancer plus de processus Python". Il faut séparer les responsabilités: LangGraph pour la topologie, les transitions d’état, la persistance checkpoint, la reprise via thread_id et les interrupt; OpenClaw Gateway pour l’ingress (IM/Webhook), la planification, les frontières d’accès et l’observabilité 24/7. Cet article est un guide opérationnel: matrice de choix, topologie minimale, contrat de handoff, base systemd et méthode L0-L3 de diagnostic. Pour les détails de runbook Gateway, voir la FAQ OpenClaw Linux; pour le budget token, lire aussi l’article coût des agents IA.

Pourquoi séparer orchestration et couche d’exécution sur VPS

En local, une boucle Planner -> Coder -> Reviewer peut suffire. Sur un Linux VPS exposé à des usages réels, quatre contraintes apparaissent très vite:

• Entrées multiples - commandes chat, webhooks, messages directs, tâches planifiées.
• États longue durée - une validation humaine peut arriver plusieurs heures plus tard; le checkpoint doit survivre aux redémarrages.
• Isolement des privilèges - le processus d’entrée ne doit pas porter les secrets MCP à fort impact.
• Observabilité par domaine - TLS/403 côté Gateway, boucles de nœuds et conflits d’état côté LangGraph.

La règle de base est donc: LangGraph en service interne privé, OpenClaw Gateway en service distinct. Gateway normalise les événements entrants, applique les politiques d’accès et déclenche des runs explicites. LangGraph reste l’autorité de l’état conversationnel et de la reprise. Cette séparation réduit le rayon d’impact en incident et simplifie fortement les revues de sécurité.

Matrice de topologie: trois formes VPS fréquentes

Trois modèles reviennent en pratique. Le bon choix dépend de la disponibilité canal 24/7, de la persistance d’état et de l’emplacement des outils lourds.

Le modèle A est le plus rapide à mettre en place, mais il devient fragile sans persistance stricte du checkpoint. Le modèle B est souvent plus robuste à moyen terme: VPS pour ingress + orchestration, cloud Mac pour les exécutions coûteuses. Le modèle C reste pertinent pour des parcours simples, à condition de ne pas lui demander des patterns de supervision avancés.

Référence côté LangGraph: documentation multi-agent. Côté OpenClaw: configuration Gateway.

Topologie minimale reproductible (forme A)

Chemin d’implémentation court, validé sur des déploiements réels:

1. Service LangGraph API - encapsuler le graphe via FastAPI, écouter sur 127.0.0.1:8123, persister checkpoint sur stockage durable.
2. Service OpenClaw Gateway - installer via la documentation CLI, terminer TLS au niveau Nginx/Caddy.
3. Règle de pont - événement entrant -> normalisation Gateway -> appel run structuré côté graphe.
4. Deux unités systemd - langgraph-api.service et openclaw.service séparées avec redémarrage indépendant.

# /etc/systemd/system/langgraph-api.service
                [Unit]
                Description=LangGraph multi-agent API
                After=network-online.target

                [Service]
                User=deploy
                WorkingDirectory=/opt/langgraph-app
                Environment=CHECKPOINT_DIR=/var/lib/langgraph-checkpoints
                ExecStart=/opt/langgraph-app/.venv/bin/uvicorn main:app --host 127.0.0.1 --port 8123
                Restart=on-failure
                RestartSec=5

                [Install]
                WantedBy=multi-user.target

Après activation, vérifiez avec ss -lntp que seul le proxy expose 443. L’API d’orchestration ne doit pas être accessible publiquement. Cette discipline "surface minimale" réduit les attaques triviales et facilite les interventions en production.

Contrat de handoff: que transmettre du Gateway au graphe

Les incidents de séparation viennent souvent d’un payload non maîtrisé. Fixez un schéma versionné:

• thread_id - clé stable entre fil canal et état graphe.
• intent - enum explicite: new_task, approve, cancel, status.
• payload - contexte structuré (repo, chemins, instruction). Pièces lourdes via stockage objet.
• caller_scope - contexte canal/utilisateur pour une deuxième vérification d’autorisation côté graphe.

Le modèle memory/checkpoint de LangGraph est fait pour les workflows long-courrier. Gardez Gateway aussi stateless que possible. Deux machines d’état concurrentes produisent tôt ou tard des incohérences difficiles à diagnostiquer.

Diagnostic L0-L3: séparer avant de corriger

Quand on vous dit "le bot ne répond plus", suivez un ordre fixe au lieu de modifier toutes les couches d’un coup.

L0: systemd et sockets

Vérifier systemctl status openclaw langgraph-api, puis les ports. Si LangGraph est tombé, le Gateway peut encore recevoir les événements, ce qui masque le vrai problème.

L1: logs canal et bridge OpenClaw

Analyser openclaw logs pour réception webhook, signature, URL de pont. TLS/403/retry relèvent d’abord de cette couche.

L2: trace LangGraph et checkpoint

Interroger le même thread_id pour identifier le nœud bloquant. Les erreurs de permission/montage checkpoint ressemblent à des sessions "toujours neuves".

L3: workers externes et MCP

Dans la forme B, vérifier réseau, NO_PROXY, expiration des secrets et quotas hôtes. Réinstaller Gateway n’aide pas si l’échec est dans la couche d’exécution distante.

Checklist pré-prod (30 minutes)

• LangGraph écoute en privé; seule l’entrée Gateway est publique.
• checkpoint sur stockage durable sauvegardé.
• Timeout Gateway->graphe inférieur à la fenêtre de retry canal.
• Liste blanche d’outils par nœud; nœud Reviewer sans droits d’écriture prod.
• Test de reboot: reprise interrupt et absence de double Cron.
• Trace id unique de l’ingress jusqu’aux logs workers.

FAQ