Il vostro team vuole trasformare i risultati di un deposito dimostrativo in un rapporto. L'agente può leggere i test, preparare un documento e, ora, interagire con un'applicazione desktop. Ma chi decide che il documento è pronto per essere condiviso? Il passaggio da un file locale a un'azione in un altro software obbliga a definire ciò che si delega realmente.
Prendiamo uno scenario fittizio: preparare un rapporto di test in uno spazio senza account personale, poi fermarsi prima di qualsiasi condivisione. Questo percorso proposto non è stato eseguito. Serve a distinguere tre decisioni: accedere a un'applicazione, preparare un'operazione e autorizzarne l'effetto.
Due annunci, due domande diverse
Il 1° ottobre 2026, GitHub annuncia in anteprima pubblica le interazioni di Copilot con applicazioni desktop, in Copilot CLI e Copilot app su macOS e Windows. L’accesso si basa su autorizzazioni dell’applicazione e controlli amministrativi. Questo annuncio non copre il controllo del desktop su Linux.
Lo stesso giorno, i flussi di lavoro dinamici passano in anteprima pubblica. Consentono di descrivere l'orchestrazione in codice: fasi, parallelismo e punti di revisione. Il perimetro include la CLI, l'app e l'SDK, l'intero insieme di strumenti destinato a integrare Copilot in un programma. Nella CLI, l'annuncio chiede di attivare le funzionalità sperimentali.
| Oggetto annunciato | Domanda da porre prima del pilota |
|---|---|
| Interazione con il desktop | Quali applicazioni e quali operazioni sono accessibili? |
| Flusso di lavoro dinamico | In quale ordine vengono eseguite le fasi e dove si fermano? |
| Autorizzazione applicativa | Quale perimetro tecnico apre esattamente? |
| Revisione del risultato | Chi convalida il documento e l'effetto aziendale previsto? |
Queste questioni rimangono distinte. Un'orchestrazione programmata può organizzare un'analisi che sbaglia. Un permesso di applicazione può aprire diverse azioni di cui solo una è desiderata. L'ordine del processo e la correttezza del risultato si verificano separatamente.
Descrivere l'azione prima di aprire l'accesso
Nel nostro esempio, « produrre il rapporto » sembra semplice. Tuttavia, questo può significare leggere un file, creare un documento, sovrascrivere un documento esistente o trasmettere informazioni. La vostra istruzione deve nominare l'input, l'output, la posizione autorizzata e la condizione di arresto.
Una prima missione potrebbe essere: leggere solo i risultati sintetici del deposito di test, redigere un documento nella cartella di dimostrazione e mostrare un'anteprima. La condivisione esterna rimane una fase distinta. L'ambito diventa comprensibile per la persona che rilegge, anche se non conosce lo strumento dell'agente.
La matrice seguente è una proposta Partitech per questo pilota. Non descrive impostazioni automatiche di Copilot.
| Operazione | Autorizzazione proposta | Prova da rileggere |
|---|---|---|
| Leggere i risultati sintetici | Nella cartella del pilota | Elenco dei file utilizzati |
| Preparare un rapporto | In una nuova posizione locale | Documento e fonti corrispondenti |
| Modificare un rapporto esistente | Dopo un confronto esplicito | Differenza prima/dopo |
| Condividere il documento | Nuova decisione umana | Destinatario, contenuto e canale |
| Eliminare i dati di lavoro | Procedura separata | Elenco esatto degli elementi interessati |
Per ogni operazione, esaminate il suo costo in caso di errore e la sua reversibilità. Correggere un titolo locale richiede poco sforzo. Rimuovere un documento trasmesso a un terzo può diventare impossibile. Questa differenza deve tradursi in un confine visibile nel percorso, piuttosto che in una frase generale sulla prudenza.
Rendere l'orchestrazione leggibile dal team
Un workflow è il percorso che segue il compito. Descrivendolo in un programma, è possibile rendere espliciti alcuni passaggi: raccogliere gli input, richiedere un'analisi, controllare la sua struttura e poi presentare un risultato a una persona.
Ecco un pseudocodice concettuale, senza sintassi SDK e senza chiamata eseguibile. Illustra il nostro processo proposto; non è un esempio testato dell'interfaccia GitHub.
identifier les fichiers autorisés
vérifier que les entrées sont présentes
produire une proposition de rapport
contrôler les références et les sections attendues
présenter le rapport et les changements prévus
attendre une décision explicite
si la décision autorise une action précise : exécuter cette action
sinon : arrêter en conservant le brouillon
Il programma può imporre una fase di revisione. Non sostituisce la revisione stessa. Una struttura corretta può contenere una conclusione errata; un riferimento può puntare al test sbagliato. Chiedete quindi che ogni affermazione utile rimandi a un elemento verificabile e che una mancanza di risultato venga segnalata piuttosto che completata con un'ipotesi.
Un risultato strutturato significa qui che l'uscita distingue constatazione, fonte e limite. Questo contratto facilita un controllo indipendente: un altro strumento o un altro lettore può confrontare le sezioni con i file di input. Non trasforma le frasi in prove.
La documentazione dei flussi di lavoro dinamici rimane il riferimento per un'implementazione. Verificate la sua versione al momento di scrivere il codice. Un prototipo di orchestrazione non deve riprendere una firma supposta di un SDK a partire da un semplice schema didattico.
Posizionare la revisione prima dell'effetto
Il confine corretto si trova appena prima del cambiamento che coinvolge il team. Nel pilota, la bozza può essere preparata automaticamente, poi la revisione deve mostrare il documento completo, le fonti utilizzate e l’azione prevista. Mostrare solo « continuare? » non permette di decidere correttamente.
Un'approvazione deve riguardare un oggetto definito. Se il contenuto, il destinatario o la posizione cambiano dopo la revisione, la decisione precedente non copre più esattamente l'operazione. Prevedete allora una nuova presentazione. Questo principio rientra nel nostro metodo di qualificazione; non presuppone che tutte le interfacce Copilot lo applichino automaticamente.
Organizzate anche l'arresto. Che cosa rimane quando si annulla una sessione? Dove ritrovare la bozza? Come sapere se un'operazione è già stata eseguita? Una ripresa cieca rischia di replicare un'azione. Prima di rilanciare, verificate lo stato reale dell'uscita e la fase raggiunta.
L'ambiente di dimostrazione deve rendere gli errori osservabili senza coinvolgere i vostri account abituali. Utilizzate file fittizi e un'applicazione di test, rimuovete gli accessi inutili e affidate la revoca a una persona identificata. Il pilota non richiede né acquisto, né email, né pubblicazione reale.
Testare i rifiuti tanto quanto il percorso previsto
Il nostro protocollo di qualificazione inizia con il caso autorizzato: gli input sono presenti, il documento è preparato e il processo si interrompe al punto previsto. Registrate il risultato osservato senza qualificarlo come successo globale. Questo primo tentativo verifica un solo percorso.
Aggiungete poi una voce assente, un file fuori dal perimetro e una richiesta di condivisione non autorizzata. L’obiettivo è vedere se il sistema si ferma indicando ciò che manca, invece di ampliare la sua missione. Esaminate anche un documento esterno contenente un’istruzione ingannevole, per esempio che chieda di cambiare il destinatario. Il documento deve rimanere un dato da analizzare; non diventa una nuova autorizzazione.
La traccia minima deve permettere di ricostruire le entrate, le decisioni e gli effetti. Evitate di raccogliere indistintamente il contenuto di tutti i documenti. Definite le persone che possono consultare queste tracce e la loro durata di conservazione nel vostro processo esistente.
Il nostro articolo sulla sandbox e le tracce Copilot app spiega gli annunci di settembre. Fornisce un contesto utile, ma i suoi meccanismi non dimostrano automaticamente la copertura delle interazioni con il desktop annunciate il 1° ottobre.
Decidete di proseguire quando il team sa spiegare il perimetro autorizzato, verificare la bozza, interrompere il percorso e ritrovare uno stato di ripresa affidabile. Se manca uno di questi elementi, aggiustate il pilota prima di aggiungere applicazioni. La nuova capacità diventa utile quando il confine della delega rimane visibile.
Fonti e data di verifica
Fonti GitHub riaperte il 6 ottobre 2026 : interazione con il desktop, flussi di lavoro dinamici e documentazione concettuale. Le anteprime possono evolversi. Matrice, scenario e pseudocodice sono proposte originali Partitech, senza risultato di esecuzione rivendicato.