Análisis en profundidad · Unos 8 min de lectura
Qwen Code v0.26.1: controles explícitos para la recuperación y la automatización
La versión conecta la recuperación duradera del espacio de trabajo, las comprobaciones previas a tareas programadas y controles de sesión más claros, manteniendo límites importantes de activación voluntaria y de proveedor.
- Publicado aquí
- Actualizado aquí
- Fecha de la fuente
- Fuente revisada
Qwen Code v0.26.1, publicado el 24 de octubre, modifica varios puntos en los que una sesión de agente puede continuar, iniciar trabajo programado o conservar estado. Las notas describen controles de recuperación y automatización junto con cambios de interfaz, proveedores y gestión de sesiones. Para los desarrolladores, la pregunta útil es qué condición comprueba realmente cada control.
Escucha las noticias
Escucha este artículo o continúa con las noticias.
Preparando la lectura…
Voz del dispositivo
El navegador o dispositivo procesa la voz. AISubHub no envía el texto a una API de audio. Las voces y la reproducción con pantalla bloqueada dependen del dispositivo.
Al continuar puede repetirse una frase breve.
Resumen
- La recuperación de Managed Workspace espera a que el estado duradero quede resuelto, muestra motivos y acciones válidas en WebShell y controla el envío de mensajes; la compresión manual de sesiones Managed vinculadas a un espacio de trabajo solo se permite en reposo y conserva el historial de auditoría.
- Los controles de tareas programadas pueden ejecutar un comando de shell fuera del modelo, propagarse por el daemon y Web Shell y utilizar una sonda de Runtime antes de que una automatización Managed reclame trabajo.
- La persistencia del token del daemon requiere activación explícita, al igual que la caché global de prompts de Anthropic; la caché por sesión sigue siendo la predeterminada. QQBot restaura el aislamiento por grupo bajo el ámbito thread como cambio incompatible.
1. La recuperación necesita un estado resuelto antes del siguiente mensaje
Las notas oficiales vinculan la continuación de Managed Workspace a una resolución duradera del estado y proporcionan en WebShell motivos de recuperación, acciones válidas y un control del envío de mensajes. Así se conecta la conversación visible con una decisión de recuperación: que una sesión reaparezca en la interfaz no significa, por sí solo, que pueda aceptar la siguiente instrucción. Otra corrección detecta sesiones de Harness bloqueadas por la recuperación incluso si siguen emitiendo señales de actividad. Por tanto, la actividad del proceso y el permiso para reanudar deben examinarse por separado.
Supuesto hipotético de AISubHub: un desarrollador se reconecta tras una operación de herramienta interrumpida y quiere enviar una indicación adicional. Conviene comprobar el motivo de recuperación y la acción disponible antes de volver a enviar, en vez de interpretar una interfaz que responde como prueba de finalización. La versión también añade compresión manual de contexto mediante la API pública y el panel emergente de uso de WebShell para sesiones Managed vinculadas a un espacio de trabajo; solo está disponible cuando están inactivas y conserva el historial de auditoría. Esa restricción importa al planificar el mantenimiento del contexto: un turno activo no es una ventana apta para comprimirlo.
2. El trabajo programado incorpora comprobaciones fuera del modelo
La versión describe un control de tareas programadas basado en un comando de shell ejecutado fuera del modelo, lo propaga por el daemon y Web Shell y añade una sonda de Runtime antes de que una automatización Managed reclame trabajo. Las sondas de seguimiento de PR también quedan detrás del control de tareas programadas. La diferencia arquitectónica reside en dónde se decide: se puede comprobar un requisito previo antes de admitir trabajo, en lugar de depender únicamente de que el modelo recuerde una instrucción después de empezar.
En un seguidor de PR hipotético de AISubHub, el equipo podría usar el mecanismo de control admitido para evaluar un requisito necesario antes de una ejecución. Las notas no establecen una comprobación universal, un contrato exacto de códigos de salida ni cobertura de todas las dependencias; cada equipo debe verificar su propia configuración. Los cambios internos añaden pruebas sobre cancelaciones repetidas con la misma clave de idempotencia y sobre el rechazo de un segundo disparo mientras un turno está en curso. Son cambios de pruebas documentados; AISubHub no los ha ejecutado ni ha confirmado de forma independiente resultados en producción.
3. Persistencia y aislamiento son decisiones distintas
La persistencia del token del daemon es expresamente opcional. Según las notas, qwen daemon start --save-token guarda el bearer token en un archivo accesible solo para su propietario, qwen daemon token lo administra y daemon stop lo elimina. La consecuencia operativa es tratar la comodidad al reiniciar como una opción de ciclo de vida elegida y comprobar la eliminación documentada en un entorno controlado. El anuncio no convierte la persistencia en predeterminada, no establece una bóveda cifrada de credenciales ni justifica guardar tokens en archivos del proyecto.
QQBot tiene otra frontera de estado: la sección de cambios incompatibles restaura el aislamiento de sesiones por grupo bajo el ámbito thread. Los equipos que utilizan varios grupos deberían revisar cómo vinculan conversaciones y sesiones antes de actualizar. En un supuesto de AISubHub con dos grupos que hablan de repositorios distintos, conviene verificar la separación esperada entre grupos en lugar de suponer que una configuración con ámbito thread comparte un solo historial. Es una cuestión de compatibilidad al actualizar, no una prueba de que la opción de persistencia del daemon controle el aislamiento de conversaciones de QQBot.
4. La configuración de modelos no acredita derechos de acceso
Los cambios de proveedores tienen ámbitos precisos. La integración oficial de DeepSeek pasa a usar deepseek-flash, acepta imágenes para ese modelo exacto y ajusta la correspondencia de niveles de esfuerzo a su API. Los preajustes de Alibaba ModelStudio Token Plan incorporan variantes de deepseek-v4.1-flash y glm-5.3, mientras que el preajuste Standard añade deepseek-v4.1-flash, glm-5.3 y descubrimiento de modelos; ambos eliminan entradas no disponibles. Son cambios de integración y preajustes de Qwen Code. No acreditan un lanzamiento mundial del modelo, disponibilidad en todos los endpoints ni inclusión en la suscripción de cada lector.
El ámbito global de caché de prompts de Anthropic pasa a requerir activación voluntaria en cada URL base, mientras que la caché por sesión sigue siendo la predeterminada. Al migrar la configuración hay que comprobar expresamente el ámbito; las notas no ofrecen mediciones de aciertos de caché, coste o latencia. Las aplicaciones anfitrionas que integran el sistema también pueden mostrar los modelos no disponibles como filas deshabilitadas en el editor, con indicaciones al pasar el puntero o enfocar y acciones opcionales del anfitrión. Por tanto, un nombre visible puede comunicar una restricción: no demuestra que la cuenta actual pueda seleccionarlo o utilizarlo.
5. Verificar el recorrido operativo y el nivel de evidencia
Las actualizaciones de OpenTUI alinean con Ink la entrada, la edición, los borradores, las líneas de estado, Vim, el historial y la salida en vivo, incluido el manejo de completado, colas y cancelaciones. Las sesiones Managed pueden administrar servidores MCP sin volver a crearse, y la versión añade una interfaz del ciclo de vida de las sesiones y lectura de exportaciones. Una comprobación de actualización acotada debería recorrer un flujo real: editar un borrador, poner entradas en cola y cancelarlas, inspeccionar un estado de recuperación y realizar una acción admitida de gestión de servidores MCP dentro de la misma sesión. Son comprobaciones propuestas, no acciones realizadas para este artículo.
Conviene separar los niveles de evidencia. Las notas enumeran controles de selección de CI, escenarios de pruebas de fallos y estabilización de pruebas temporales; la entrada del test del watchdog de inactividad de Java deja expresamente sin cambios el comportamiento en ejecución. También añaden una propuesta de diseño bilingüe para un confinamiento opcional de procesos locales de Linux, con requisitos de aptitud y comportamiento de cierre seguro ante fallos. Una propuesta no confirma un comportamiento predeterminado ya desplegado. El análisis de AISubHub es que unas fronteras explícitas de admisión y estado hacen más concreta la revisión de configuración, pero las notas por sí solas no prueban que todos los fallos estén resueltos ni cuantifican una mejora.
Por qué importa
Análisis de AISubHub: los desarrolladores pueden revisar la recuperación, la admisión de tareas, la persistencia, la selección de proveedores y las operaciones de sesión como decisiones distintas. Un registro de migración útil debe indicar el requisito previo, el estado visible esperado y el resultado observado en el entorno del propio equipo.
Límites y disponibilidad
Este artículo se basa en las notas oficiales de v0.26.1 y en su elemento público de fecha de publicación. AISubHub no inspeccionó los pull requests enlazados ni las implementaciones de código, no ejecutó binarios ni las pruebas enumeradas y no realizó benchmarks de rendimiento. El acceso a proveedores y los derechos de suscripción requieren confirmación aparte; el confinamiento de Linux se describe como una propuesta de diseño. El Full Changelog de la versión compara v0.26.0 con v0.26.1; AISubHub no inspeccionó de forma independiente ese diff enlazado.
Fuentes y pruebas
Fecha de la fuente: · Fuente revisada:
Contenido editorial asistido por IA y contrastado con fuentes primarias. Las afirmaciones del proveedor se atribuyen; la inclusión no implica recomendación.