Analyse approfondie · Environ 8 min de lecture
Qwen Code v0.26.1 : des contrôles explicites pour la reprise et l’automatisation
Cette version relie la reprise durable de l’espace de travail, les vérifications avant les tâches planifiées et des commandes de session plus claires, tout en conservant des limites importantes d’activation volontaire et de fournisseur.
- Publié ici
- Mis à jour ici
- Date de la source
- Source vérifiée
Qwen Code v0.26.1, publié le 24 octobre, modifie plusieurs points où une session d’agent peut reprendre, lancer une tâche planifiée ou conserver son état. Les notes décrivent des contrôles de reprise et d’automatisation, ainsi que des changements d’interface, de fournisseurs et de gestion des sessions. Pour les développeurs, la question utile est la condition réellement vérifiée par chaque contrôle.
Écouter les actualités
Écoutez cet article ou poursuivez la lecture des actualités.
Préparation de la lecture…
Voix de l’appareil
La voix est traitée par votre navigateur ou appareil. AISubHub n’envoie pas le texte à une API audio. Les voix et la lecture écran verrouillé dépendent de l’appareil.
La reprise peut répéter une courte phrase.
En bref
- La reprise de Managed Workspace attend le règlement durable de l’état, présente les raisons et les actions valides dans WebShell et contrôle l’envoi des messages ; la compression manuelle des sessions Managed liées à un espace de travail est réservée aux sessions inactives et conserve l’historique d’audit.
- Les contrôles de tâches planifiées peuvent exécuter une commande shell hors du modèle, se propager dans le daemon et Web Shell et utiliser une sonde Runtime avant qu’une automatisation Managed ne prenne un travail en charge.
- La persistance du jeton du daemon exige une activation explicite, tout comme le cache global de prompts d’Anthropic ; le cache par session reste la valeur par défaut. QQBot rétablit l’isolation par groupe dans la portée thread, ce qui constitue un changement incompatible.
1. La reprise exige un état réglé avant le message suivant
Les notes officielles conditionnent la poursuite de Managed Workspace au règlement durable de l’état et donnent dans WebShell les raisons de reprise, les actions valides et un contrôle d’envoi des messages. Elles relient ainsi la conversation visible à une décision de reprise : le retour d’une session dans l’interface ne signifie pas, à lui seul, qu’elle peut accepter l’instruction suivante. Un autre correctif détecte les sessions Harness bloquées par la reprise même si leurs signaux de présence continuent. La présence d’un processus actif et l’autorisation de reprendre doivent donc être examinées séparément.
Hypothèse d’AISubHub : un développeur se reconnecte après l’interruption d’une opération d’outil et souhaite envoyer une précision. Il est utile de vérifier la raison de reprise et l’action disponible avant de renvoyer un message, plutôt que de considérer une interface réactive comme une preuve d’achèvement. La version ajoute aussi une compression manuelle du contexte par l’API publique et le panneau d’utilisation de WebShell pour les sessions Managed liées à un espace de travail, uniquement lorsqu’elles sont inactives et en conservant l’historique d’audit. Cette restriction compte pour planifier l’entretien du contexte : un tour actif n’est pas une fenêtre admissible pour la compression.
2. Les tâches planifiées disposent de vérifications hors du modèle
La version décrit un contrôle de tâches planifiées fondé sur une commande shell exécutée hors du modèle, transmet ce contrôle au daemon et à Web Shell et ajoute une sonde Runtime avant qu’une automatisation Managed ne prenne un travail en charge. Les sondes de surveillance des PR sont également placées derrière ce contrôle. La distinction architecturale tient au lieu de la décision : un prérequis peut être vérifié avant l’admission du travail, au lieu de compter uniquement sur le modèle pour se souvenir d’une instruction après avoir commencé.
Pour un observateur de PR hypothétique d’AISubHub, une équipe pourrait utiliser le mécanisme de contrôle pris en charge pour évaluer un prérequis nécessaire avant une exécution. Les notes n’établissent ni vérification universelle, ni contrat exact sur les codes de sortie, ni couverture de toutes les dépendances ; chaque équipe doit encore vérifier sa configuration. Les changements internes ajoutent des tests sur les annulations répétées avec la même clé d’idempotence et sur le refus d’un second déclenchement lorsqu’un tour est en cours. Ce sont des modifications de tests documentées ; AISubHub ne les a pas exécutées et n’a pas confirmé indépendamment leurs résultats en production.
3. La persistance et l’isolation sont deux choix distincts
La persistance du jeton du daemon est explicitement facultative. Selon les notes, qwen daemon start --save-token enregistre le bearer token dans un fichier accessible uniquement à son propriétaire, qwen daemon token le gère et daemon stop le supprime. Sur le plan opérationnel, la commodité au redémarrage doit donc être traitée comme un paramètre de cycle de vie choisi, et la suppression documentée doit être vérifiée dans un environnement contrôlé. L’annonce ne rend pas la persistance automatique par défaut, n’établit pas de coffre chiffré d’identifiants et ne justifie pas de placer des jetons dans les fichiers du projet.
QQBot possède une autre frontière d’état : la section des changements incompatibles rétablit l’isolation des sessions par groupe dans la portée thread. Les équipes utilisant plusieurs groupes devraient revoir leur correspondance entre conversations et sessions avant la mise à jour. Dans une hypothèse d’AISubHub où deux groupes discutent de dépôts différents, il faut vérifier la séparation attendue entre groupes plutôt que supposer qu’une configuration de portée thread partage un historique unique. C’est une question de compatibilité lors de la mise à jour, et non une preuve que l’option de persistance du daemon contrôle l’isolation des conversations de QQBot.
4. La configuration des modèles ne prouve pas un droit d’accès
Les changements de fournisseurs ont des périmètres précis. L’intégration officielle de DeepSeek utilise désormais deepseek-flash, accepte les images pour ce modèle exact et aligne la correspondance des niveaux d’effort sur son API. Les préréglages Alibaba ModelStudio Token Plan ajoutent des variantes de deepseek-v4.1-flash et glm-5.3, tandis que le préréglage Standard ajoute deepseek-v4.1-flash, glm-5.3 et la découverte de modèles ; tous deux retirent les entrées indisponibles. Il s’agit de changements d’intégration et de préréglages dans Qwen Code. Ils n’établissent ni lancement mondial d’un modèle, ni disponibilité sur chaque endpoint, ni inclusion dans l’abonnement de chaque lecteur.
La portée globale du cache de prompts d’Anthropic exige désormais une activation volontaire sur chaque URL de base, alors que le cache par session reste le comportement par défaut. Il faut vérifier explicitement cette portée lors d’une migration de configuration ; les notes ne fournissent aucune mesure de taux de cache, de coût ou de latence. Les applications hôtes qui intègrent le système peuvent aussi afficher les modèles indisponibles sous forme de lignes désactivées dans l’éditeur, avec des indications au survol ou au focus et des actions facultatives de l’hôte. Un nom de modèle visible peut donc signaler une restriction. Il ne prouve pas que le compte actuel peut le sélectionner ou l’utiliser.
5. Vérifier le parcours opérationnel et le niveau de preuve
Les mises à jour d’OpenTUI alignent sur Ink la saisie, l’édition, les brouillons, les lignes d’état, Vim, l’historique et la sortie en direct, y compris la gestion de la complétion, des files d’attente et de l’annulation. Les sessions Managed peuvent gérer des serveurs MCP sans être recréées, et la version ajoute une interface de cycle de vie des sessions ainsi que la lecture d’exports. Une vérification ciblée de mise à jour devrait suivre un véritable flux : modifier un brouillon, mettre une saisie en file et l’annuler, examiner un état de reprise et effectuer une action prise en charge de gestion des serveurs MCP dans la même session. Ce sont des vérifications proposées, pas des actions réalisées pour cet article.
Il faut distinguer les niveaux de preuve. Les notes énumèrent des contrôles de sélection de CI, des scénarios de test de défaillance et une stabilisation des tests de temporisation ; l’entrée consacrée au test du watchdog d’inactivité Java laisse explicitement inchangé le comportement à l’exécution. Elles ajoutent aussi une proposition de conception bilingue pour un profil facultatif de confinement des processus locaux Linux, avec des conditions d’éligibilité et un comportement de blocage en cas d’échec. Une proposition ne confirme pas un comportement par défaut déjà déployé. Selon l’analyse d’AISubHub, des frontières explicites d’admission et d’état rendent la revue de configuration plus concrète, mais les seules notes ne prouvent pas que chaque défaillance est résolue et ne quantifient aucune amélioration.
Pourquoi cela compte
Analyse d’AISubHub : les développeurs peuvent examiner séparément la reprise, l’admission des tâches, la persistance, le choix des fournisseurs et les opérations de session. Un compte rendu de migration utile doit indiquer le prérequis, l’état visible attendu et le résultat observé dans l’environnement propre à l’équipe.
Limites et disponibilité
Cet article repose sur les notes officielles de v0.26.1 et leur élément public de date de publication. AISubHub n’a pas inspecté les pull requests liés ni les implémentations du code, n’a pas exécuté les binaires ou les tests cités et n’a pas réalisé de benchmarks. L’accès aux fournisseurs et les droits d’abonnement exigent une confirmation distincte ; le confinement Linux est décrit comme une proposition de conception. Le Full Changelog de la version compare v0.26.0 et v0.26.1 ; AISubHub n’a pas inspecté indépendamment ce diff lié.
Sources et preuves
Date de la source: · Source vérifiée:
Articles assistés par IA, vérifiés avec les sources primaires citées. Les affirmations des fournisseurs sont attribuées ; la présence ne vaut pas recommandation.