Automatiser sa Recherche ML avec OpenClaw : Cas Réel Research

Bon dimanche ! ☕

Aujourd'hui, on sort du simple “agent qui fait une tâche” pour regarder un cas plus ambitieux : transformer un workflow de recherche machine learning en chaîne agentique reproductible. Le projet s'appelle ARIS, il est public, très documenté, et surtout intéressant parce qu'il montre comment porter une méthode conçue pour Claude Code/Codex vers OpenClaw sans perdre le fil critique.

🎯 Le Cas : Recherche ML Autonome Pendant la Nuit

Auteur : wanshuiyin
Contexte : mainteneur d'un harness open source de recherche ML, avec contributions communautaires et adaptations multi-agents.
Objectif : automatiser une boucle complète de recherche — lecture de littérature, génération d'idées, plan d'expérience, exécution, audit critique et rédaction — avec des artefacts Markdown traçables.

📖 L'Histoire

Le problème de départ est très concret pour tout chercheur ML : les idées ne manquent pas, mais la friction est partout. Lire assez d'articles pour situer une piste, formuler une hypothèse testable, construire une matrice d'expériences, lancer le code, auditer les résultats, puis transformer tout ça en narration scientifique demande une discipline énorme. Une grande partie du travail se passe aussi “entre” les outils : notes, scripts, brouillons, commentaires de reviewers, tableaux d'ablation.

ARIS part d'une intuition simple : un agent seul peut produire vite, mais il risque de s'auto-convaincre. Le projet introduit donc une séparation executor/reviewer. L'executor avance — code, expériences, brouillon — tandis qu'un autre modèle joue le rôle de critique externe. Le README insiste sur cette différence de famille de modèles pour éviter la boucle de self-review trop complaisante.

Le projet a d'abord pris la forme de skills Markdown pour Claude Code, puis s'est élargi : Codex, Cursor, Trae, Antigravity, et une adaptation OpenClaw documentée dans docs/OPENCLAW_ADAPTATION.md. C'est cette adaptation qui rend le cas utile ici : elle ne prétend pas “installer un plugin magique”, elle traduit la méthode ARIS en phases conversationnelles et fichiers de sortie.

La solution finale ressemble moins à un bot qu'à un protocole de laboratoire. Chaque phase consomme un artefact et en produit un autre : lit_scan.md, idea_report.md, experiment_plan.md, runbook.md, review_loop.md, puis final_summary.md. C'est précisément ce qui la rend reproductible dans OpenClaw : l'état critique ne vit pas uniquement dans le contexte du modèle.

🔧 Le Setup Technique

Architecture Agent

Schéma conceptuel :

Session OpenClaw principale
  ├─ Phase 1 — scan littérature → outputs/lit_scan.md
  ├─ Phase 2 — génération d'idées → outputs/idea_report.md
  ├─ Phase 3 — plan expérimental → outputs/experiment_plan.md + outputs/runbook.md
  ├─ Phase 4 — boucle critique → outputs/review_loop.md
  └─ Synthèse finale → outputs/final_summary.md

Option recommandé :
  ├─ subagent executor pour les tâches longues
  ├─ reviewer séparé, idéalement autre modèle/famille
  └─ fichiers Markdown comme contrat entre les phases

Dans ARIS, les skills slash commands existent côté Claude Code/Codex. Dans OpenClaw, l'adaptation proposée remplace ces commandes par des tâches explicitement phasées. Le point clé : chaque étape doit écrire un fichier, sinon le workflow dérive.

Fichiers Clés

Guide d'adaptation OpenClaw

ARIS 的本质是「科研流程编排」：
- Workflow 1：文献 → 想法 → 新颖性/可行性评估
- Workflow 2：实验执行 → 自动评审循环 → 迭代修复

在 OpenClaw 中，可用“阶段化任务 + 文件化产出”替代 slash skill。

Contrat d'artefacts

/research-lit      → outputs/lit_scan.md
/idea-creator      → outputs/idea_report.md
/run-experiment    → outputs/experiment_plan.md / outputs/runbook.md
/auto-review-loop  → outputs/review_loop.md
full pipeline      → outputs/final_summary.md

Étapes de Mise en Place

1. Créer un workspace dédié :

mkdir -p aris-openclaw/outputs aris-openclaw/paper aris-openclaw/results
cd aris-openclaw

2. Ajouter un AGENTS.md court pour fixer les règles :

# Research Agent
- Toujours écrire les sorties dans outputs/
- Ne jamais inventer de résultat expérimental
- Citer les sources avec URL ou DOI
- Séparer hypothèses, observations et conclusions
- Limiter la boucle de review à 4 rounds sauf validation humaine

3. Lancer la phase littérature dans OpenClaw :

Exécute phase 1 : fais un scan de littérature sur “factorized gap in discrete diffusion LMs”.
Écris outputs/lit_scan.md avec 10 papiers, 5 gaps, et les sources vérifiables.

4. Enchaîner la génération d'idées :

Exécute phase 2 : lis outputs/lit_scan.md, propose 3 idées testables, classe Top1/Top2,
et écris outputs/idea_report.md avec hypothèse, MVP, signaux d'échec.

5. Préparer l'expérience :

Exécute phase 3 : transforme le Top1 en matrice d'expériences.
Écris outputs/experiment_plan.md et outputs/runbook.md avec commandes, jeux de données,
critères d'arrêt et métriques.

6. Lancer la boucle critique :

Exécute phase 4 : review loop maximum 4 rounds.
À chaque round : score, faiblesse principale, correction minimale, décision continuer/stop.
Mets à jour outputs/review_loop.md.

📊 Les Résultats

Gains mesurés ou observables :

• 9 571 étoiles GitHub au moment de la vérification du dépôt, signal fort d'adoption communautaire.
• 62 skills synchronisés mentionnés dans l'historique v0.4.1, ce qui montre une couverture large du cycle recherche.
• 3 soumissions communautaires listées dans le README, avec signaux de review simulée : un score CSPaper 8/10, un score Stanford Agentic Reviewer 7/10, et un papier UAV-CC en review.
• Une adaptation OpenClaw explicite, courte et reproductible, avec 5 artefacts de sortie nommés.

Limites rencontrées :

• Les scores d'AI-review ne sont pas des acceptations officielles : le README le précise lui-même.
• Le workflow peut coûter cher si on pousse les niveaux d'effort et les reviewers puissants.
• La qualité dépend fortement de la discipline fichier : si les outputs sont vagues, la phase suivante amplifie le flou.

🧐 Analyse Critique

✅ Ce qui est bien fait

• La séparation executor/reviewer est saine. ARIS ne demande pas au même modèle d'être juge et partie. Pour des workflows scientifiques, c'est probablement le garde-fou le plus important.
• Les artefacts Markdown rendent le système portable. On peut passer de Claude Code à OpenClaw parce que la logique métier n'est pas cachée dans un runtime propriétaire.
• Le workflow accepte les checkpoints. Les paramètres documentés incluent l'idée de pause humaine et de niveaux d'effort. C'est essentiel quand les expériences consomment du GPU ou quand une conclusion peut finir dans un papier.

⚠️ Points d'attention

• Risque de “review gaming”. Si l'objectif devient d'améliorer un score d'AI-review plutôt que la validité scientifique, l'agent optimise le mauvais signal.
• Traçabilité des sources obligatoire. Une recherche bibliographique automatisée sans vérification arXiv/CrossRef/Semantic Scholar peut halluciner des références plausibles.
• OpenClaw doit borner les boucles. Une boucle de review non limitée peut consommer temps, tokens et GPU sans amélioration proportionnelle.

💡 Améliorations possibles

• Ajouter un template SOUL.md OpenClaw officiel pour ARIS, avec règles anti-fabrication et contrats d'outputs.
• Créer une variante “lite” pour chercheurs solo : 5 papiers, 2 idées, 1 plan d'expérience, 1 round de review.
• Ajouter un audit final claims.json : chaque claim du résumé relié à une source, un log ou une métrique.

🎓 Ce qu'on en retient

Leçons clés :

1. Un bon agent long-running est d'abord un bon protocole : phases, fichiers, critères d'arrêt.
2. La critique indépendante vaut mieux qu'une grosse boucle de self-review.
3. OpenClaw brille quand le workflow est découpé en artefacts persistants plutôt qu'en prompts jetables.

Pour aller plus loin :

• Construire sa Mémoire Obsidian avec OpenClaw : Cas Réel Research
• Industrialiser ses Workflows avec OpenClaw : Cas Réel DevOps
• Source originale
• Adaptation OpenClaw

À dimanche prochain pour un nouveau cas ! 🦞