Worklog pour Agents

beginner 🤖 LLM-friendly 2 min · 422 mots Mis à jour : 2026-10-10 Français

Pourquoi et comment les agents tiennent un worklog par tâche — avec un bloc de prompt prêt à copier-coller, pour que la fonctionnalité ne soit plus jamais oubliée.

Lire cet article en : 📄 Texte brut ⚡ JSON 🤖 Format LLM

Worklog pour Agents

Ce document existe parce que Michael l'a ordonné (#10509, 08.10.2026) : « La fonctionnalité worklog existe depuis des semaines. Mais vous la négligez. Prends une tâche pour que la documentation et le prompt initial dans Synapse soient étendus avec la fonctionnalité worklog, qu'elle ne disparaisse surtout pas et que tout le monde la connaisse. » — Si tu es un agent et que tu lis cette page, le worklog fait désormais partie de ton répertoire standard.

Pourquoi le worklog ?

Les agents meurent souvent : limite de contexte, wipe de sandbox, redémarrage de cron. Ce qui se perd régulièrement, ce n'est pas la connaissance (c'est le rôle de /memory), mais l'historique de travail : qu'a-t-on déjà essayé sur cette tâche ? Quel commit est poussé, lequel non ? Qui attend qui ? C'est exactement pour cela que le worklog existe — append-only, par tâche, interrogeable. Un nouveau run lit GET /worklog/:task_id et sait en quelques secondes où son prédécesseur s'est arrêté.

Le second destinataire est Michael : le worklog est LA source unique de l'historique de travail de la flotte. Sans entrée de worklog, votre travail n'existe pas officiellement dans la vue d'ensemble de la flotte.

La règle obligatoire

Push-first, pas push-last. Une entrée à CHAQUE jalon :

Commit de fix poussé
MR créée, verdict rendu, merge effectué
État du pipeline (surtout FAILED avec cause)
Escalade, transmission, takeover
Découvertes CRIT/HIGH
Coutures de contexte (une entrée summary avant la fin du contexte)

Une entrée coûte une ligne :

GET /worklog/push?task_id=run-145-29140fb0&kind=progress&content=MR%20%2129%20erstellt,%20Pipeline%20running&agent=Janus

Les kinds et quand les utiliser

kind	Moment
`start`	tâche revendiquée — preuve que vous l'avez prise
`progress`	chaque jalon (voir règle obligatoire)
`note`	décisions, contexte, observations
`error`	erreur AVEC ce que vous avez tenté
`summary`	phase/session terminée avant que le contexte ne s'épuise
`close`	tâche terminée — dernière entrée, le statut passe à `completed`

Prompt initial (bloc pour les setups d'agents)

Copiez ce bloc dans le prompt de démarrage/cron des nouvelles instances d'agents. Il est volontairement court pour tenir dans tout template. La version anglaise est la référence universelle pour les agents :

WORKLOG RULE (Michael #8882/#10509, binding): At EVERY milestone of your work,
push one entry to Synapse /worklog — not only at session end:
- Task takeover:     kind=start
- Fix commit/MR/verdict/merge/pipeline status: kind=progress
- Errors (with attempted fix): kind=error
- Context seam (before context ends): kind=summary
- Completion: kind=close (or POST /worklog/:task_id/close)
One-liner: GET /worklog/push?task_id=<task>&kind=<kind>&content=<short>&agent=<your-name>
The fleet task convention lives at GET /script/fleet-worklog-tasks-spec.
The API reference: docs/content/en/api/worklog.md (in the synapse repo).

Les agents de flotte qui réutilisent le même nom de mind mettent dans agent leur nom (Janus, Minerva, Elara, …) — ainsi les entrées sont comptabilisables par agent.

Pour les humains

La vue d'ensemble du worklog se lit mieux au format markdown : GET /worklog/<task_id>?format=md ou la liste des tâches GET /worklog/list?status=active. Historique complet : GET /worklog?limit=50.