Qwen Code Mise à jour hebdomadaire : Agent Team collaboration parallèle, Durable /loop survit au redémarrage, /cd changer de répertoire

Qwen Code a publié quatre versions officielles v0.18.0~v0.18.3 cette semaine, avec plus de 100 PRs fusionnés, couvrant quatre directions :

Collaboration multi-Agent parallèle. Avant, /fork exécutait des Agents en arrière-plan, mais chaque Agent travaillait isolément sans communication, et vous deviez assembler les résultats vous-même. Le mode Agent Team permet au modèle de créer des équipes nommées, de générer plusieurs coéquipiers en parallèle, d’échanger des messages, de partager des listes de tâches, et finalement le leader consolide un rapport unique. Les coéquipiers sont persistants — après avoir terminé une tâche ils peuvent attendre la suivante, pas des subagents one-shot qui disparaissent après exécution.

Tâches planifiées survivant au redémarrage. Avant, les tâches /loop périssaient avec la session — disparaissant silencieusement après redémarrage. Durable /loop persiste les tâches planifiées dans des fichiers, les récupérant automatiquement au prochain lancement, avec les tâches périodiques manquées exécutées une fois en rattrapage.

Changement de répertoire en session, sans redémarrage. /cd <path> change le répertoire de travail de la session actuelle sans quitter le CLI, les fichiers de session migrent automatiquement vers le nouveau workspace, le contexte système/directory se recharge automatiquement. Avant, vous deviez redémarrer pour changer de répertoire de projet.

✨ Nouvelles fonctionnalités

Agent Team : Plusieurs Agents collaborant en parallèle, échangeant des messages, partageant des tâches

Avant, le /fork de Qwen Code pouvait exécuter des Agents en arrière-plan, mais chaque Agent était isolé — vous安排 trois Agents pour reviewer le code en parallèle, ils n’avaient aucun canal de communication, et vous deviez assembler les trois résultats manuellement.

Cette semaine, le mode Agent Team a été ajouté (expérimental, opt-in). Une fois activé, le modèle peut créer des équipes nommées et générer plusieurs « coéquipiers » pour travailler en parallèle. Les coéquipiers et le leader peuvent échanger des messages et partager des listes de tâches, le leader consolidant finalement un rapport unifié. Les coéquipiers sont persistants, pas des subagents one-shot — ils peuvent terminer une tâche et attendre la suivante, plutôt que de disparaître après exécution.

Désactivé par défaut (activer via le paramètre experimental.agentTeam ou la variable d’environnement QWEN_CODE_ENABLE_AGENT_TEAM=1). Une fois activé, le modèle obtient des outils de collaboration d’équipe (créer/supprimer des équipes, envoyer des messages aux coéquipiers, créer/mettre à jour/lister les tâches partagées), et l’outil Agent ajoute un paramètre name pour générer des coéquipiers nommés persistants plutôt que des subagents disposable.

Ce que vous pouvez faire avec :

• Avoir trois reviewers examiner le code en parallèle (un pour la gestion des erreurs, un pour les conditions de concurrence, un pour les cas limites), et obtenir un rapport consolidé
• Coordonner une équipe pour construire une petite application de favoris
• Les coéquipiers rapportent automatiquement au leader après complétion, le leader vous donne un résumé unifié

Voir PR #4844 

Durable /loop : Tâches planifiées survivant au redémarrage

Avant, toutes les tâches /loop périssaient avec la session — programmer « vérifier mon PR toutes les 30 minutes » disparaissait silencieusement après redémarrage de Qwen Code. Cette semaine, les tâches /loop peuvent survivre aux redémarrages.

Quand une requête implique la persistance (« vérifier mon PR chaque heure »), la tâche est sauvegardée par projet dans ~/.qwen/tmp/<hash-projet>/scheduled_tasks.json (pas dans le workspace, n’apparaît pas dans git status), et automatiquement récupérée au prochain lancement. Le défaut reste session-only, les rappels temporaires n’écrivent pas de fichiers.

Les rappels one-shot ayant expiré pendant l’indisponibilité : au redémarrage le modèle confirme avant exécution, ne lance jamais silencieusement. Les tâches périodiques manquées exécutent un cycle de rattrapage après démarrage puis retrouvent le rythme normal. Quand plusieurs sessions existent pour le même projet, une seule déclenche les tâches persistantes ; si le holder crash, un autre prend le relai en quelques secondes. Les tâches périodiques expirent automatiquement après 7 jours (supprimées après le dernier trigger).

Ce que vous pouvez faire avec :

• « Vérifier mon PR chaque heure » → continue après redémarrage, pas besoin de reprogrammer
• Les tâches périodiques manquées sont automatiquement rattrapées une fois au redémarrage
• Les rappels temporaires /loop 5m remind me périssent toujours avec la session, n’écrivent pas de fichiers

Voir PR #5004 

/cd : Changer de répertoire sans redémarrer le CLI

Avant, si vous vouliez que l’Agent travaille depuis un autre répertoire de projet, vous deviez quitter et redémarrer. Le changement entre plusieurs repos ou workspaces parent/enfant était peu pratique, sans possibilité de déplacer le contexte de tool actif dans une session.

Cette semaine, la commande slash /cd <path> a été ajoutée. Elle valide le répertoire cible, gère la confirmation de confiance, met à jour les roots de workspace et le service cwd, migre les fichiers transcript/runtime/worktree de la session actuelle vers le nouveau répertoire de session workspace, et recharge le contexte système/directory. La complétion de chemin fonctionne toujours.

Ce que vous pouvez faire avec :

• /cd ../another-project changer vers le projet adjacent, les fichiers de session migrent automatiquement
• /cd /path/to/parent-repo naviguer dans la session, pas de redémarrage nécessaire
• Les chemins non approuvés déclenchent une confirmation, cohérente avec le flux de confiance au premier démarrage

Voir PR #4890 

Thinking réductible : Le processus de raisonnement ne domine plus l’écran

Avant, les blocs thinking du modèle affichaient toujours le texte de raisonnement complet, occupant un espace écran massif. Cette semaine, passage à un affichage en trois états :

• Phase streaming : fenêtre de défilement fixe de 4 lignes montrant le contenu de raisonnement en direct + timer (« ∴ Thinking… 8s »)
• Réduit après complétion (défaut) : une ligne affichant la durée totale (« ∴ Thought for 15s »)
• Développer pour voir : un raccourci clavier dédié pour les blocs thinking sera attribué ultérieurement ; actuellement Ctrl+O déclenche le toggle compactMode, partageant la même touche avec l’expansion thinking, les raccourcis indépendants développer/reduire seront découplés dans un PR ultérieur

Le paramètre thinkingDisplayMode a été supprimé, remplacé par un seul mode réductible. Les blocs thinking sont uniquement dans l’history UI, pas envoyés à l’API, le comportement session resume est inchangé.

Ce que vous pouvez faire avec :

• Le raisonnement complexe se réduit à une ligne, ne clutter pas la vue
• Ctrl+O pour développer et voir le processus de raisonnement complet du modèle à tout moment
• La phase streaming a un timer, montrant combien de temps le modèle a pensé

Voir PR #4598 

MCP Approval Gate : La configuration MCP au niveau projet ne se connecte plus automatiquement

Avant, les serveurs MCP déclarés dans le .mcp.json du projet ou .qwen/settings.json du workspace se connectaient automatiquement — ouvrir un repo contenant un .mcp.json malveillant pouvait démarrer le serveur avant que vous l’inspectiez.

Cette semaine, un gate d’approbation a été ajouté. Les serveurs MCP du projet .mcp.json et du scope workspace doivent être approuvés avant connexion. Les décisions d’approbation sont persistées dans <QWEN_HOME>/mcpApprovals.json, indexées par root de projet + nom de serveur, et liées à un hash de config. Modifier le command/args/URL/environment/headers d’un serveur change le hash, le reverting à pending — n’hérite pas silencieusement des anciennes approbations.

Modèle de priorité des serveurs MCP : user/default settings < project .mcp.json < workspace/system settings < session (ACP/IDE) < --mcp-config. La config projet peut override la config user mais pas la config system entreprise.

Ce que vous pouvez faire avec :

• Ouvrir un nouveau repo, les serveurs MCP au niveau projet s’affichent comme « Pending approval », pas de connexion auto
• qwen mcp approve <name> ou qwen mcp approve --all pour approbation batch
• Modifier la config serveur requiert automatiquement une nouvelle approbation (binding hash)
• qwen mcp list pour voir le statut d’approbation de tous les serveurs

Voir PR #4713 

Permission Bubbling des Agents de fond : Les tâches de fond ne refusent plus automatiquement les confirmations

Avant, les Agents de fond nécessitant une confirmation de permission pour des appels de tools (comme git push, rm) étaient automatiquement refusés avec « background agents cannot prompt for confirmation », puis la session parent relançait en foreground — essentiellement le run de fond était wasted, revenant en foreground.

Cette semaine, approvalMode: bubble a été ajouté. Quand une config subagent définit approvalMode: bubble, les Agents de fond rencontrant des appels de tools nécessitant confirmation bubble la requête vers l’UI Background tasks de la session parent. Vous pouvez ouvrir les détails depuis le footer pill pour approuver. Après approbation l’Agent continue l’exécution ; après refus il se termine normalement. bubble est une valeur approvalMode subagent-only, pas une option session-level. En contexte headless/ACP/SDK il reste automatiquement refusé (pas d’UI pour répondre).

Ce que vous pouvez faire avec :

• Un subagent custom déclare approvalMode: bubble, les tâches de fond ne refusent plus automatiquement
• Le footer pill affiche « ⚠ needs approval », presser ↓ pour ouvrir les détails et approuver (autorisation unique seulement, pas d’option « always allow »)
• Après approbation l’Agent continue et retourne les résultats, pas besoin de relancer en foreground

Voir PR #4955 

/compress-fast : Pas d’appel LLM, compression de contexte instantanée

Avant, /compress dépendait d’une requête latérale LLM pour générer un résumé (~2-5 secondes, consommant ~30K tokens). Trop lent pour les déploiements de modèles locaux ou les utilisateurs qui voulaient juste reclaimer rapidement de l’espace.

Cette semaine, /compress-fast a été ajouté, purement rule-driven : force la microcompaction pour nettoyer les anciens résultats de tools et contenu média (conserve les N plus récents), puis strippe toutes les parties thinking des réponses du modèle. Zéro appel API, zéro overhead de tokens, réponse instantanée. Écrit un checkpoint chat_compression dans JSONL, comportement --resume identique à /compress.

Ce que vous pouvez faire avec :

• /compress-fast reclaim immédiatement des milliers de tokens, pas de délai pas de coût
• Idéal pour les longues sessions après beaucoup d’appels de tools quand vous voulez rapidement reclaimer de l’espace
• /compress reste disponible — utilisez-le quand vous avez besoin de qualité de résumé sémantique
• Deux /compress-fast consécutifs, le second indique « No compression needed »

Voir PR #4893 

Plus de nouvelles fonctionnalités

🔧 Corrections importantes

🎉 Contributeurs

Merci aux contributeurs de cette semaine :

Pour questions ou suggestions, feedback sur GitHub Issues  !