2026.07.14 (Mar)
2026.07.22 (Mer) mis Ă  jour

✹ RĂ©sumĂ© de GPT-5.6 Sol

Le rĂ©cit d’un objectif dĂ©coupĂ© en plusieurs Work Items, confiĂ©s Ă  diffĂ©rents workers, puis vĂ©rifiĂ©s et intĂ©grĂ©s par un coordinateur.

Des workers répétitifs aux workers fondés sur des Work Items

Dans un prĂ©cĂ©dent projet de collecte de donnĂ©es, j’avais dĂ©jĂ  sĂ©parĂ© les workers du coordinateur. À l’époque, les workers rĂ©pĂ©taient le mĂȘme batch selon un goal fixe, tandis que le coordinateur organisait pĂ©riodiquement les rĂ©sultats accumulĂ©s.

Cette fois, le fonctionnement Ă©tait diffĂ©rent. J’ai donnĂ© au coordinateur un objectif en langage naturel. Il a dĂ©fini les conditions de fin et les Work Items, puis rĂ©parti les fichiers et le pĂ©rimĂštre entre les workers.

Sessions Codex séparées entre un coordinateur et plusieurs workers

Chaque worker -W- a terminĂ© et vĂ©rifiĂ© sa tĂąche avant de transmettre un commit. Le coordinateur -C- a examinĂ© ces rĂ©sultats, les a intĂ©grĂ©s un par un, puis a de nouveau vĂ©rifiĂ© l’état complet.

Le coĂ»t d’intĂ©gration a augmentĂ© avec le nombre de workers

Le flux lui-mĂȘme Ă©tait simple.

Transmettre l'objectif
→ Le dĂ©couper en Work Items
→ ExĂ©cuter et vĂ©rifier dans chaque worker
→ Transmettre les commits
→ Le coordinateur examine et intùgre
→ VĂ©rifier de nouveau l'Ă©tat complet

Le principal avantage était la clarté de la responsabilité. Si une tùche échouait, les autres ne vacillaient pas avec elle, et je pouvais examiner chaque résultat sous forme de commit.

Le problĂšme est lui aussi apparu immĂ©diatement. En lançant trop de workers, tous les rapports sont arrivĂ©s d’un coup. Les sessions en double ont encore compliquĂ© la gestion. Davantage de parallĂ©lisme n’était pas automatiquement prĂ©fĂ©rable. Il fallait limiter le dĂ©coupage Ă  ce que le coordinateur pouvait rĂ©ellement absorber.

Ce jour-là, j’ai aussi remis à niveau les baselines d’Orchestrator et d’Acceptance, les Workflows et Skills communs, ainsi que les rùgles d’exploitation des sessions de workers et de coordinateur.

Ce que je veux automatiser dans OpenClaw

Flux d'Orchestrator qui répartit un objectif en langage naturel entre plusieurs exécutants et vérifie les résultats

Je ne cherche pas Ă  reproduire exactement dans le produit les sessions, Worktrees et Branches utilisĂ©es aujourd’hui. Je veux automatiser les dĂ©cisions qui se trouvent derriĂšre.

  • jusqu’oĂč dĂ©couper un objectif
  • qui possĂšde chaque rĂ©sultat
  • ce qu’il faut vĂ©rifier avant de considĂ©rer une tĂąche comme terminĂ©e
  • oĂč reprendre aprĂšs un Ă©chec

Dans OpenClaw, l’enjeu n’était pas le nombre de workers, mais un coordinateur capable de gĂ©rer la propriĂ©tĂ© des rĂ©sultats, leur vĂ©rification et les points de reprise.

Laisser un commentaire