Planifier l’exécution de prompts

Utilisez /loop et les outils de planification cron pour exécuter des prompts de manière répétée, surveiller un statut ou définir des rappels ponctuels au sein d’une session Qwen Code.

Les tâches planifiées permettent à Qwen Code de réexécuter automatiquement un prompt à intervalle régulier. Utilisez-les pour surveiller un déploiement, suivre une PR, vérifier l’avancement d’un build long, ou vous rappeler de faire quelque chose plus tard dans la session.

Les tâches créées depuis le terminal sont limitées à la session : elles vivent dans le processus Qwen Code actuel et disparaissent lorsque vous quittez. Rien n’est écrit sur le disque.

Les canaux de messagerie utilisent un planificateur persistant séparé afin que les résultats puissent être renvoyés vers le chat d’origine après le tour en cours. Voir Scheduled Channel Loops pour les commandes de canal, le comportement de persistance et les contraintes de livraison.

Astuce : Les tâches planifiées sont activées par défaut. Pour les désactiver, définissez experimental.cron: false dans vos paramètres, ou définissez QWEN_CODE_DISABLE_CRON=1 dans votre environnement.

Workspace dans le Web Shell

La page Scheduled Tasks affiche le workspace de chaque tâche sur sa carte. Lors de la création ou de la modification d’une tâche, le champ Workspace indique où elle s’exécute. Avec un seul workspace, ce champ est en lecture seule ; si un Web Shell intégré a un workspace fixé par son hôte, il affiche également Fixed by host. Survolez l’étiquette du workspace pour voir son chemin complet.

Avec plusieurs workspaces, choisissez un workspace lors de la création d’une tâche. Une tâche existante reste dans son workspace d’origine. Les étiquettes de workspace nécessitent des informations de workspace provenant du démon ou de l’hôte ; une étiquette manquante ne signifie pas que la tâche s’exécute sans workspace.

Livrer les résultats des tâches du Web Shell à un canal

Dans qwen serve, ouvrez Scheduled Tasks et créez ou modifiez une tâche dans son workspace. Choisissez une destination d’exécution persistante (une session dédiée, ou la session actuelle lorsqu’elle est disponible), puis choisissez un Delivery Channel, un type de destination utilisateur ou chat, et un ID de destination. Les contacts observés récents sont des suggestions optionnelles ; vérifiez le nom du canal, son type et l’ID brut avant d’en sélectionner un. Vous pouvez également saisir directement un ID. Si un ID contient des espaces au début ou à la fin, le formulaire vous avertit et propose Remove surrounding whitespace ; il ne modifie jamais l’ID automatiquement. Le canal configuré doit prendre en charge l’envoi vers cette destination.

La livraison est désactivée par défaut. Configurer un canal seul n’active pas la livraison pour une tâche. Lorsqu’elle est activée, la réponse finale d’une exécution planifiée réussie est envoyée via le canal sélectionné ; cela ne garantit pas la réception ni n’ajoute de tentatives durables ou d’alertes d’échec. La carte de tâche affiche une ligne de livraison uniquement lorsqu’elle a une destination enregistrée.

Pour supprimer la livraison, modifiez la tâche et sélectionnez Delivery off sous Delivery Channel. Modifier d’autres champs préserve la cible enregistrée, y compris une cible qui n’est plus trouvée dans les contacts récents. Les échecs de chargement ou les canaux manquants ne l’effacent pas. Changer le workspace lors de la création d’une tâche réinitialise la destination brouillon ; une tâche existante reste dans son workspace d’origine.

Si la prise en charge de la livraison devient indisponible après avoir changé une destination, choisissez Discard delivery changes pour restaurer la destination d’origine et continuer à modifier les autres champs de la tâche. Pour une nouvelle tâche, cela supprime la destination brouillon. La sauvegarde laisse alors toute configuration de livraison existante inchangée.

Les tâches qui créent une nouvelle session pour chaque exécution (per_run) ne prennent pas en charge la livraison. Passer à ce mode maintient votre destination brouillon visible et vous demande de désactiver explicitement la livraison ou de revenir à un mode persistant avant de sauvegarder. Les contrôles de livraison nécessitent la capacité channel_delivery du démon ; les destinations existantes restent visibles avec les anciens démons, mais ne peuvent pas y être modifiées.

Planifier un prompt récurrent avec /loop

Le skill intégré /loop est le moyen le plus rapide de planifier un prompt récurrent. Passez un intervalle optionnel et un prompt, et Qwen Code configure une tâche cron qui s’exécute en arrière-plan tant que la session reste ouverte.

/loop 5m check if the deployment finished and tell me what happened

Qwen Code analyse l’intervalle, le convertit en expression cron, planifie la tâche, et confirme la cadence ainsi que l’ID de la tâche. Il exécute ensuite immédiatement le prompt une première fois — vous n’avez pas à attendre le premier déclenchement cron.

Syntaxe des intervalles

Les intervalles sont optionnels. Vous pouvez les placer au début, à la fin, ou les omettre entièrement.

Les unités prises en charge sont s pour les secondes, m pour les minutes, h pour les heures et d pour les jours. Les secondes sont arrondies à la minute supérieure car cron a une granularité d’une minute. Les intervalles qui ne se divisent pas uniformément dans leur unité, comme 7m ou 90m, sont arrondis à l’intervalle propre le plus proche, et Qwen Code vous indique celui qu’il a choisi.

Boucler sur une autre commande

Le prompt planifié peut lui-même être une commande ou l’invocation d’un skill. Cela est utile pour réexécuter un workflow que vous avez déjà packagé.

/loop 20m /review-pr 1234

À chaque déclenchement de la tâche, Qwen Code exécute /review-pr 1234 comme si vous l’aviez tapé.

Mode autonome

Exécuter /loop sans prompt démarre une boucle autonome au lieu de répéter un prompt fixe. Qwen Code agit comme un intendant du travail déjà établi dans la conversation — il fait avancer votre travail pendant votre absence :

/loop

Un /loop nu (sans prompt, sans intervalle) exécute une boucle autonome à son propre rythme ; /loop <intervalle> sans prompt exécute la même boucle autonome sur une cadence fixe (par ex. /loop 10m). À chaque déclenchement, il fait avancer ce que la conversation a déjà mis en place — terminer ce que vous avez commencé, maintenir une PR en cours (répondre aux fils de review, corriger une CI qui échoue, résoudre les conflits), et honorer les engagements de suivi. Il n’agit que sur le travail déjà établi dans l’historique : il n’invente jamais de nouveau travail ni n’apporte de modifications irréversibles (push, delete, send) sans autorisation explicite, et il s’arrête une fois que tout est calme.

Gérer les boucles

/loop prend également en charge deux sous-commandes pour gérer les tâches existantes :

/loop list

Liste toutes les tâches planifiées avec leurs IDs et expressions cron.

/loop clear

Annule toutes les tâches planifiées d’un seul coup.

Définir un rappel ponctuel

Pour les rappels ponctuels, décrivez ce que vous voulez en langage naturel au lieu d’utiliser /loop. Qwen Code planifie une tâche à déclenchement unique qui s’auto-supprime après son exécution.

remind me at 3pm to push the release branch

in 45 minutes, check whether the integration tests passed

Qwen Code fixe l’heure de déclenchement à une minute et une heure spécifiques à l’aide d’une expression cron et confirme quand il se déclenchera.

Réveiller la session uniquement en cas de changement

Une tâche récurrente peut embarquer une gate : une commande shell qui s’exécute à chaque déclenchement, en dehors du modèle. Si elle n’affiche rien et sort avec 0, le déclenchement est ignoré — aucun tour ne s’exécute et rien n’est ajouté à la conversation. Si elle affiche du contenu, le prompt de la tâche s’exécute avec cette sortie jointe et marquée comme des données produites par la commande. Une commande qui échoue, affiche des données binaires ou s’exécute pendant plus de 60 secondes est signalée une fois, puis comptée silencieusement jusqu’à ce qu’elle réussisse à nouveau ou soit bloquée ; CronList affiche le compteur.

Utilisez une gate pour les surveillances généralement silencieuses, avec une commande qui maintient son propre curseur et n’affiche que ce qui a changé :

every 2 minutes, run ./check-pr.sh 15057 as a gate; when it prints something, handle the events it lists

Qwen Code appelle CronCreate avec gate: "./check-pr.sh 15057" et confirme la commande de la même manière qu’une commande Monitor : une seule fois, lors de la création de la tâche, avec l’option de toujours l’autoriser. La commande s’exécute ensuite sans surveillance depuis le répertoire du projet avec l’environnement de la session. Une tâche durable avec gate continue de fonctionner après un redémarrage lorsque la commande est en lecture seule, qu’une règle Monitor(...) ou Bash(...) sauvegardée l’autorise, ou que la session s’exécute en mode auto ou yolo ; sinon le prochain déclenchement signale la règle à ajouter au lieu d’exécuter la commande. Cette règle est celle que l’option « toujours autoriser » de Monitor sauvegarderait, et pour une commande composée (un test de substitution de commande, un if, un heredoc), elle peut ne pas couvrir chaque partie ; placez une telle sonde dans un script et autorisez le script à la place. Une règle de refus pour la commande arrête la gate dans tous les modes.

Une gate doit se terminer au premier plan, donc une commande qui place une partie d’elle-même en arrière-plan avec & est refusée, tout comme une commande composée uniquement de commentaires. Une gate s’exécute déjà dans un shell, donc écrivez la commande elle-même plutôt qu’un wrapper shell autour : bash -c '…' est refusé, afin que les règles de permission vérifient exactement le texte qui s’exécute ; l’erreur nomme la commande qu’elles auraient vérifiée. La vérification de & lit le texte plutôt que de l’exécuter, donc en cas de doute elle refuse : un & dans un commentaire, un heredoc ou (( … )) est également refusé, donc placez une telle commande dans un script et utilisez le script comme gate. Une syntaxe qu’elle ne peut pas suivre (eval, un script pipé dans sh) est détectée lorsque la gate s’exécute : une gate qui se termine sans rien sur stdout alors que quelque chose qu’elle a démarré en arrière-plan détient toujours son stdout est signalée comme un échec, et non ignorée silencieusement, et ce qu’elle a laissé s’exécuter dans son groupe de processus est arrêté (sur Linux et macOS ; une partie qui est passée dans son propre groupe de processus, comme le fait setsid, n’est pas arrêtée). Sous la sandbox d’exécution shell bwrap (non disponible pour les sessions qwen serve), la partie arrière-plan se termine avec la commande, donc seule la vérification du texte s’applique ici.

Rédigez un prompt avec gate sous forme d’instructions (« for each event in the gate output, … »), et non comme un slash command. Dans un démon qwen serve, le formulaire de tâche planifiée du Web Shell offre la même commande gate, la carte de tâche affiche ses résultats récents, et « Run now » sur une tâche avec gate demande au modèle d’exécuter la gate lui-même d’abord, exactement comme écrit, et de suivre la tâche uniquement lorsque la commande sort avec 0 et affiche quelque chose sur la sortie standard (un déclenchement planifié ignore les avertissements sur la sortie d’erreur, et le modèle devrait faire de même) ; une tâche liée à la conversation actuelle du démon (sessionMode: "current") peut également porter une gate.

Gérer les tâches planifiées

Demandez à Qwen Code en langage naturel de lister ou d’annuler des tâches, ou référencez directement les outils sous-jacents.

what scheduled tasks do I have?

cancel the deploy check job

Sous le capot, Qwen Code utilise ces outils :

Chaque tâche planifiée possède un ID de 8 caractères que vous pouvez passer à CronDelete. Une session peut contenir jusqu’à 50 tâches planifiées à la fois.

Fonctionnement de l’exécution des tâches planifiées

Le planificateur vérifie chaque seconde les tâches échues et les met en file d’attente lorsque la session est inactive. Un prompt planifié se déclenche entre vos tours, et non pendant que Qwen Code est en train de répondre. Si Qwen Code est occupé lorsqu’une tâche arrive à échéance, le prompt attend la fin du tour en cours. Une tâche avec gate exécute d’abord sa commande gate et n’est mise en file d’attente que lorsque la commande affiche une sortie.

Toutes les heures sont interprétées dans votre fuseau horaire local. Une expression cron comme 0 9 * * * signifie 9h du matin où que vous exécutiez Qwen Code, et non UTC.

Jitter

Pour éviter que chaque session n’interroge l’API au même moment exact, le planificateur ajoute un petit décalage déterministe aux heures de déclenchement :

• Les tâches récurrentes se déclenchent avec un retard allant jusqu’à 10 % de leur période, plafonné à 15 minutes. Une tâche horaire peut se déclencher n’importe quand entre :00 et :06.
• Les tâches ponctuelles planifiées au début ou à la fin de l’heure (minute :00 ou :30) se déclenchent jusqu’à 90 secondes en avance.

Le décalage est dérivé de l’ID de la tâche, de sorte que la même tâche obtient toujours le même décalage. Si le timing exact est important, choisissez une minute qui n’est pas :00 ou :30, par exemple 3 9 * * * au lieu de 0 9 * * *, et le jitter ponctuel ne s’appliquera pas.

Expiration des tâches récurrentes

Par défaut, les tâches récurrentes expirent automatiquement 7 jours après leur création. La tâche se déclenche une dernière fois, puis s’auto-supprime. Cela limite la durée d’exécution d’une boucle oubliée.

Pour modifier cette limite, définissez experimental.cronRecurringMaxAgeDays dans vos paramètres, ou définissez la variable d’environnement QWEN_CODE_CRON_MAX_AGE_DAYS (la variable d’environnement est prioritaire — pratique pour les déploiements cloud ou conteneurisés où la modification de settings.json est peu pratique). Une valeur de 0 désactive entièrement l’expiration, de sorte que les tâches s’exécutent jusqu’à ce que vous les supprimiez — utile pour les déploiements de démons à long terme qui hébergent des rapports quotidiens, des résumés ou une surveillance continue. La limite configurée s’applique également aux tâches durables restaurées depuis le disque après un redémarrage.

Les tâches ponctuelles n’expirent pas selon un minuteur — elles se suppriment simplement après s’être déclenchées une fois.

Référence des expressions cron

CronCreate accepte les expressions cron standard à 5 champs : minute heure jour-du-mois mois jour-de-la-semaine. Tous les champs prennent en charge les caractères génériques (*), les valeurs uniques (5), les pas (*/15), les plages (1-5) et les listes séparées par des virgules (1,15,30).

Le jour de la semaine utilise 0 ou 7 pour dimanche, jusqu’à 6 pour samedi. Lorsque le jour du mois et le jour de la semaine sont tous deux contraints (aucun n’est *), une date correspond si l’un ou l’autre des champs correspond — cela suit la sémantique standard de vixie-cron.

La syntaxe étendue comme L, W, ?, et les alias de noms tels que MON ou JAN n’est pas prise en charge.

Limites

La planification limitée à la session comporte des contraintes inhérentes :

• Les tâches ne se déclenchent que lorsque Qwen Code est en cours d’exécution et inactif. Fermer le terminal ou laisser la session se terminer annule tout.
• Pas de rattrapage pour les déclenchements manqués. Si l’heure planifiée d’une tâche passe alors que Qwen Code est occupé par une requête de longue durée, elle se déclenche une seule fois lorsque Qwen Code redevient inactif, et non une fois par intervalle manqué.
• Pas de persistance entre les redémarrages. Redémarrer Qwen Code efface toutes les tâches limitées à la session.