Traiter les Sous-agents OpenClaw comme des Fonctions sans État plutôt que comme des Membres d'Équipe Persistants

Un développeur sur r/openclaw décrit le changement de son modèle mental lorsqu'il travaille avec des équipes multi-agents dans OpenClaw. Traiter initialement les sous-agents comme des employés juniors avec des noms, des histoires personnelles et des attentes de mémoire a conduit à des semaines de confusion et de flux de travail rompus.
L'analogie de la fonction
La percée est venue de la reconnaissance que les sous-agents ne sont pas des mini-moi ou des membres d'équipe persistants—ce sont des fonctions. Plus précisément :
- Les sous-agents sont des appels de fonction sans état, pas des membres d'équipe persistants
- Ce sont des outils spécialisés, pas des versions juniors du développeur
- Ils fonctionnent sur le principe entrée → sortie pure, sans mémoriser le contexte
- Ils renvoient des valeurs à l'appelant plutôt que de communiquer entre eux
La source fournit des exemples de code contrastant les mauvaises et bonnes approches :
# MAUVAIS : Traiter le sous-agent comme un objet persistant
frank = Agent("Frank")
frank.build_feature()
frank.fix_it() # Suppose que Frank se souvient
BON : Traiter le sous-agent comme un appel de fonction
result = frank_task(
instructions="Construire la page de connexion",
context={"requirements": reqs, "design": mockup}
)
frank_task s'exécute, renvoie une sortie, se termine
Implications pratiques
Ce changement de modèle mental a plusieurs implications concrètes :
1. SOUL.md comme docstring de fonction : Au lieu de profils de personnalité, SOUL.md devient un document de spécification :
# frank_task()Objectif : Construire des fonctionnalités Next.js Entrées : exigences (dict), design (optionnel) Sorties : {code, tests, notes} Contraintes : Pas d'appels API externes sans approbation
2. Passage d'état explicite pour l'itération : Puisque les sous-agents ne mémorisent pas le contexte, vous devez transmettre toutes les informations nécessaires dans les paramètres :
# MAUVAIS
frank_fix("corriger le bug") # naît, essaie, meurt
frank_fix("toujours cassé") # nouvelle naissance, pas de contexte
BON
result = frank_fix({
"code": previous_output,
"issues": ["la validation de connexion échoue", "CSS mobile cassé"],
"test_cases": failing_tests
}) # Contexte complet dans les paramètres
3. Le coordinateur comme programme principal : Le développeur devient une fonction d'orchestration plutôt qu'un manager d'équipe :
def build_feature(spec):Appeler les fonctions en séquence
code = frank_build(spec) tests = quinn_audit(code)
if tests["passed"]: return deploy(code) else: # Itérer avec un contexte explicite fixed = frank_fix({ "code": code, "failures": tests["failures"] }) return deploy(fixed)
Parallèles avec la conception logicielle
Cette approche s'aligne avec les principes établis de conception logicielle :
- Responsabilité unique : Chaque sous-agent fait une seule chose
- Fonctions pures : Même entrée → même sortie
- Testabilité unitaire : Tester la sortie de chaque sous-agent indépendamment
- Composabilité : Enchaîner les sous-agents comme quinn_test(frank_code(spec))
- Sans état : Pas de dépendances cachées
Le développeur note que la valeur n'est pas "plus d'agents = plus d'intelligence" mais "fonctions spécialisées = architecture plus propre".
Résultats après le changement
Après avoir adopté ce modèle, le développeur a construit :
- Une base de données de 11 249 salles de sport en 2 semaines
- 5 agents spécialisés (pas 5 généralistes)
- Un CRM avec des flux de travail de souscription
- Un engagement quotidien sur Moltbook
Tout cela en utilisant des sous-agents sans état et un coordinateur qui maintient le contexte.
📖 Read the full source: r/openclaw
👀 See Also

Limites de débit de l'API Claude : Fenêtres horaires, gestion du contexte et surcharge MCP
L'analyse des limites de débit de l'API Claude révèle des restrictions plus strictes pendant les heures de pointe (5h-11h PT / 8h-14h ET en semaine), avec la gestion du contexte et l'utilisation du serveur MCP ayant un impact significatif sur la consommation de tokens. Les stratégies pratiques incluent le travail en dehors des fenêtres de pointe, le démarrage de nouvelles conversations pour chaque nouvelle tâche et l'audit des intégrations MCP.

Connecteur Todoist supprimé de Claude, configuration personnelle requise
Le connecteur officiel Todoist n'est plus disponible dans Claude. Les utilisateurs peuvent ajouter Todoist comme connecteur personnalisé en utilisant l'URL MCP https://ai.todoist.net/mcp, mais cela nécessite un abonnement Claude Pro ou Max.

Correction d’automatisation de navigateur à distance avec configuration du nœud OpenClaw
Utilisez un nœud OpenClaw local pour éviter les maux de tête liés au CDP/RDP — exécutez le navigateur visible, conservez votre IP et vos cookies.

OpenClaw Memory Journey : Recherche intégrée vs MemPalace pour le rappel de session en temps réel
Un développeur compare la recherche intégrée, QMD et MemPalace sur Mac Intel. L'indexation en temps réel pose problème ; il adopte une stratégie de rappel fractionné avec réindexation cronée.