VS Code 1.144 porta la sessione di sviluppo oltre il coperchio del portatile

Inizi un compito di sviluppo alla scrivania, lo controlli da un altro dispositivo e torni più tardi per esaminare le modifiche. L'esperienza utile è un unico lavoro che prosegue, con le stesse istruzioni e decisioni visibili. Ricostruire una conversazione a ogni cambio di dispositivo è un'altra forma di lavoro di sviluppo.

VS Code 1.144 è diventato una versione stabile il 28 ottobre 2026. Le note di rilascio uniscono continuità delle sessioni degli agenti e gestione remota a funzioni con proprie etichette Preview o Experimental. Le sessioni cloud vengono eseguite sull'infrastruttura GitHub, quindi possono continuare mentre il portatile di sviluppo è offline. Note ufficiali di rilascio.

Questa guida spiega la differenza fra un client e il luogo in cui il lavoro viene eseguito, il contributo dell'Agent Host Protocol e come valutare una sessione continua attraverso un vero passaggio alla revisione del codice.

Schermata ufficiale di Remote Environments in Visual Studio Code 1.144. Used with permission from Microsoft. Fonte dell'immagine · Licenza e note sull'immagine.

Chiudere una finestra e fermare un processo di lavoro sono eventi diversi

Un'interfaccia di sviluppo mostra messaggi, file e richieste di approvazione. Il processo che svolge il compito può risiedere altrove. Separati questi ruoli, chiudere l'interfaccia non deve significare abbandonare il compito, purché l'host e il suo ambiente rimangano disponibili.

La panoramica Universe di Microsoft del 28 ottobre descrive l'Agent Host come un processo indipendente che gestisce sessioni, sistemi di esecuzione degli agenti, modelli, file e terminali. Indica che Agent Host Protocol ha raggiunto la versione 1.0 e collega i client allo stato di una sessione che continua. È una distinzione architetturale utile per valutare che cosa significhi davvero «continuare a lavorare».

Un host locale dipende ancora dalla macchina locale. Un host remoto dipende dalla macchina remota e dalle modalità di connessione. Una sessione cloud ha un ambiente ospitato separatamente. Scegli il luogo di esecuzione in base a ciò che deve rimanere disponibile quando il client se ne va.

Pensa al client come a una finestra sulla sala di controllo. Un'altra finestra può mostrare lo stesso lavoro, ma non sposta i macchinari sottostanti. Un telefono che visualizza una sessione non trasforma un computer locale in sospensione in un server sempre acceso.

La nostra lettura: la persistenza diventa utile quando l'identità del compito sopravvive insieme alla sua esecuzione. La sessione continua dovrebbe chiarire quale repository usa, quali modifiche ha prodotto e quale decisione attende. Tenere semplicemente vivo un processo è un risultato più limitato.

Spiegazione originale della responsabilità di client e host, basata sulla panoramica VS Code Universe. È un modello di pianificazione semplificato, non una topologia di rete.

AHP sincronizza la sessione osservata dalle interfacce

Il sito ufficiale di Agent Host Protocol, consultato il 2 novembre, descrive AHP come un protocollo di visualizzazione bidirezionale basato sullo stato. I client operano su uno stato di sessione condiviso; l'host trasmette le azioni e arbitra i conflitti. Alla riconnessione può consegnare le azioni mancate o un'istantanea attuale, così che l'interfaccia si aggiorni.

Questo conta perché una sessione dell'agente contiene più di una trascrizione. Può includere un'azione in attesa di approvazione, un terminale in esecuzione o un file modificato. Se due interfacce mostrano versioni incoerenti di questi fatti, chi gestisce la sessione può prendere la decisione sbagliata anche quando la generazione del codice è buona.

Gli esempi di riconnessione del protocollo mostrano come le azioni client in sospeso vengano riconciliate con lo stato dell'host. Per il lettore, l'implicazione pratica è semplice: riconnettersi dovrebbe recuperare la situazione attuale del lavoro, compreso il destino di una richiesta precedente. Non dovrebbe essere necessario indovinare se un'approvazione sia arrivata prima dell'interruzione di rete.

Un protocollo condiviso crea anche un confine per l'interoperabilità dei client. Un client deve comprendere lo stato della sessione e le azioni che mostra. L'esistenza di un protocollo non significa che ogni strumento possa già collegarsi a ogni fornitore o esporre tutte le funzioni allo stesso modo.

Un team che confronta interfacce dovrebbe esaminare le decisioni importanti nel proprio flusso. Il client alternativo mostra una richiesta di autorizzazione in sospeso? Identifica i file modificati e lo stato attuale del compito? Tornare nell'editor conserva lo stesso lavoro oppure avvia una seconda conversazione?

Versione stabile e capacità in anteprima sono etichette separate

La pagina di VS Code 1.144 identifica il rilascio come Stable, mentre Cloud Automations, generazione di immagini e connettori Copilot mantengono l'etichetta Preview; uso del computer e funzioni dell'insieme di lavoro sono contrassegnati Experimental. L'esperienza delle sessioni cloud richiede un piano Copilot a pagamento ed è soggetta alle politiche dell'organizzazione. Stato del rilascio e delle funzioni, 28 ottobre, consultato il 2 novembre.

Questa combinazione è comune in un editor estensibile: un'applicazione stabile può contenere singole funzioni con livelli di maturità diversi. La decisione di adozione appropriata riguarda la funzione e il flusso di lavoro, non soltanto il numero di versione.

Questa tabella è un confronto operativo, non una promessa di comportamento identico fra ambienti. I requisiti di una particolare estensione, modello e sistema di esecuzione continuano a contare. Prova la combinazione che il team intende usare.

Per una capacità sperimentale, scegli un esercizio separato e reversibile. Per valutare la continuità di base, parti dal flusso più piccolo che dimostri il passaggio. Combinare più funzioni nuove rende più difficile individuare quale parte abbia prodotto un risultato inatteso.

Tre compiti illustrativi mostrano dove la continuità aiuta

Uno sviluppatore può delegare una correzione circoscritta e rivederla più tardi

Immagina uno sviluppatore che chieda a una sessione cloud di correggere un test del parser fallito in un repository. L'istruzione indica l'errore, il comportamento rilevante e la verifica attesa. Lo sviluppatore controlla poi i progressi da un altro client supportato prima di tornare nell'editor per la revisione.

Il criterio di accettazione dovrebbe essere lo stesso di ogni modifica: la correzione risolve il comportamento, i controlli pertinenti passano e le differenze sono appropriate. La possibilità di continuare a portatile chiuso è utile perché cambia quando il lavoro può svolgersi. Non dimostra che il risultato sia pronto per essere integrato.

Per il passaggio, chiedi alla sessione di conservare il comando esatto del test e il suo esito. Un messaggio «test superati» è più difficile da valutare di un controllo nominato e legato a una revisione precisa. Chi esamina ha bisogno di prove sufficienti per capire il risultato senza ricostruire l'intera conversazione.

Se il compito si blocca per un'approvazione o un servizio mancante, la sessione dovrebbe rendere visibile quello stato. Un lavoro che rimane attivo ma non può avanzare è diverso da uno che sta producendo lavoro utile. La visibilità aiuta lo sviluppatore a decidere se intervenire, modificare l'ambito o lasciare il compito in attesa.

Un manutentore può indagare problemi separati senza mescolare i file

Un manutentore illustrativo potrebbe chiedere a una sessione di riprodurre un errore e a un'altra di esaminare la documentazione. Può sfruttare bene i tempi di attesa se i compiti hanno confini chiari. Crea anche l'esigenza di mantenere ogni risultato associato al proprio spazio di lavoro e contesto di revisione.

Definisci le responsabilità prima di iniziare. Indica file o sottosistema, ramo o spazio di lavoro e risultato previsto per ciascuna sessione. Se due compiti devono toccare lo stesso contratto, decidi come riconciliare le conclusioni prima di applicare entrambe le modifiche.

Esamina un risultato rispetto a uno stato noto del repository. Altrimenti, un test riuscito può dipendere da modifiche non revisionate di un'altra sessione. Un confine fra spazi di lavoro è prezioso perché rende più facile stabilire l'origine di un risultato positivo.

Il vantaggio è una coda di revisione più chiara, non semplicemente più agenti simultanei. Due indagini ben delimitate possono ridurre l'incertezza; diverse modifiche sovrapposte possono aumentarla. L'interfaccia Agents è utile quando aiuta il manutentore a capire quale situazione si stia sviluppando.

Un team può provare un compito cloud ricorrente prima di fidarsi della pianificazione

Per una prova illustrativa di automazione, considera una revisione periodica che individui collegamenti della documentazione bisognosi di attenzione. Parti da un rapporto in sola lettura e da un risultato specifico. Lascia che una persona lo esamini prima di ampliare il compito alla creazione di modifiche.

Lo stato Preview di Cloud Automations conta qui perché il lavoro ricorrente aggiunge una responsabilità operativa. Un compito che si comporta bene una volta può comunque richiedere limiti di frequenza, un responsabile e una risposta chiara agli errori prima di essere eseguito a intervalli. Verifica questi requisiti separatamente dalla qualità del testo generato.

Il team dovrebbe sapere dove ogni esecuzione registra revisione del repository, risultati e richieste esterne. Se non riesce a completarsi, la registrazione dovrebbe dire che cosa è rimasto irrisolto. Un compito ricorrente diventa utile quando il responsabile sa distinguere una situazione invariata da un controllo fallito.

Inizia con un repository e un ambito modesto. Amplia soltanto dopo aver osservato esecuzioni ordinarie, un'esecuzione bloccata intenzionalmente e una revisione dell'artefatto risultante. Sono passaggi proposti per una prova pilota, non affermazioni di test pratici del rilascio.

Il lavoro non salvato in commit richiede un passaggio esplicito

Le note di rilascio 1.144 precisano che le sessioni cloud usano uno spazio di lavoro separato e non copiano automaticamente le modifiche locali non salvate in commit. Dalla finestra Chat o Agents, l'utente può selezionare Cloud, scegliere un repository GitHub, proseguire la conversazione, rispondere alle approvazioni ed esaminare le modifiche; le sessioni esistenti si riaprono dall'elenco. Istruzioni per le sessioni cloud.

Questo spazio separato è un fatto importante per chi lavora in una copia locale molto attiva. Un file locale può essere essenziale al compito pur non esistendo nello stato del repository visibile alla sessione cloud. Prima di passare il lavoro, identifica la revisione di partenza prevista e il modo autorizzato di fornire altro materiale.

Non confondere un passaggio di interfaccia con un trasferimento di file. Continuare la stessa conversazione non prova che ogni file locale o servizio in esecuzione sia stato spostato. Una sessione può conservarne l'intento e avere comunque bisogno di un accesso esplicito al materiale necessario per eseguirlo.

Per una segnalazione illustrativa di errore, includi l'input che fallisce in una forma approvata e riproducibile. Specifica se l'agente debba usare dati di prova già nel repository o materiale appena fornito. Questo dà alla sessione un punto di partenza concreto ed evita una lunga indagine su uno stato del repository che non ha mai contenuto il problema.

La revisione finale dovrebbe controllare lo stesso confine al contrario. Stabilisci dove risiedono le modifiche proposte e come entreranno nel ramo di lavoro. Conserva le modifiche locali attive mentre esamini e applichi il risultato. Il vantaggio di uno spazio remoto non dovrebbe andare a scapito di lavoro locale incerto.

Flusso originale di accettazione per un compito di sviluppo continuo. Combina il confine documentato dello spazio cloud con la normale revisione ingegneristica; non riporta risultati di test indipendenti.

Un giro di dieci minuti dimostra meno di un compito completo

È facile valutare le parti visibili della continuità: una sessione appare in un elenco, un client si riconnette, arriva un messaggio. Sono controlli utili, ma l'obiettivo dello sviluppatore è un lavoro completato il cui stato sopravviva al passaggio.

Scegli un piccolo compito che possa concludersi con un artefatto esaminabile. Un dato di prova, una correzione della documentazione o una modifica isolata di comportamento possono funzionare se il repository offre un controllo evidente. Il compito dovrebbe essere abbastanza significativo da far emergere stato dello spazio e autorizzazioni senza rendere inutilmente ampia la prima prova.

1. Aggiorna e verifica la versione installata. Usa il percorso Check for Updates di VS Code e conferma la versione. Esamina le etichette delle singole funzioni nelle note ufficiali.
2. Scegli un ambiente di esecuzione autorizzato. Conferma accesso al repository, idoneità del piano e politica organizzativa. Decidi se il compito appartenga a un host locale, remoto o cloud.
3. Registra lo stato iniziale. Annota repository e revisione. Conserva le modifiche locali e identifica gli input necessari allo spazio scelto.
4. Fornisci un'istruzione circoscritta. Indica comportamento desiderato, ambito e comando di verifica. Definisci l'artefatto che ti aspetti di esaminare.
5. Esercita il passaggio. Lascia il client e riconnettiti tramite un'interfaccia supportata disponibile. Controlla stato, approvazioni in sospeso e nuovo lavoro della stessa sessione.
6. Torna al codice. Esamina differenze e prove di verifica. Conferma che i controlli riguardino la revisione che stai valutando.
7. Registra esito e limiti residui. Distingui riconnessione riuscita, compito completato e modifica accettata. Sono traguardi collegati con prove diverse.

Se il test fallisce, diagnostica il confine che ha ceduto. Un dato di prova mancante nel repository richiede una correzione dello spazio di lavoro; una chiamata bloccata a uno strumento richiede una decisione di autorizzazione; un host indisponibile richiede una decisione sull'ambiente di esecuzione. Ripetere lo stesso prompt risolve raramente un problema esterno al prompt.

Mantieni specifico questo primo risultato. «Questo compito è proseguito in questo ambiente e ha prodotto queste modifiche revisionate» è una conclusione operativa utile. Dice a un collega che cosa può essere ripetuto e dove contano le condizioni.

Una sessione persistente dovrebbe rendere più facile seguire le responsabilità

VS Code 1.144 porta più parti del flusso degli agenti in uno spazio continuo: il luogo in cui le istruzioni diventano azioni e le azioni diventano modifiche esaminabili. AHP offre ai client una direzione basata sullo stato condiviso, mentre il luogo di esecuzione determina che cosa può continuare dopo la disconnessione di un dispositivo.

Il miglioramento significativo è un lavoro che puoi lasciare, ritrovare e ancora comprendere. Quando la sessione conserva stato di partenza, decisioni e verifiche, il coperchio del portatile diventa un dettaglio di pianificazione anziché il confine del lavoro.

Fonti

• Note di rilascio di Visual Studio Code 1.144, versione Stable del 28 ottobre 2026; consultate il 2 novembre 2026.
• VS Code Wrapped: GitHub Universe 2026, 28 ottobre 2026.
• Microsoft Agent Host Protocol, specifica v1.0.0 e panoramica dello stato condiviso, consultati il 2 novembre 2026.

Conserva il materiale alla base di una decisione

Telli.sh è un'opzione per conservare il materiale di partenza autorizzato insieme agli appunti che hai verificato. Crea uno spazio per gli appunti.