Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.
Mission Control per Agenti di Codifica: Un’Esperienza Unificata in VS Code
Un singolo assistente di codifica è facile da capire. Diversi agenti che lavorano in posti diversi non lo sono.
Un agente viene eseguito localmente in VS Code. Un altro lavora su un problema GitHub nel cloud. Un agente CLI vive nel terminale. Un agente di codifica di terze parti può avere un modello di sessione diverso e limiti diversi. Senza una vista condivisa, gli sviluppatori spendono più tempo a tracciare il lavoro che a supervisionarlo.
L’esperienza unificata dell’agente di VS Code affronta il problema di coordinamento con Agent Sessions: un unico posto per avviare agenti, visualizzare il loro stato, aprire le loro conversazioni e intervenire quando il piano cambia.
Si tratta meno di aggiungere un altro agente e più di rendere più gestibili più agenti.
Una Vista per Diversi Tipi di Lavoro
L’articolo di origine descrive quattro partecipanti distinti: GitHub Copilot locale, Copilot Coding Agent nel cloud, GitHub Copilot CLI e OpenAI Codex per i sottoscrittori Copilot idonei.
Hanno diverse forze:
- Un agente locale può ispezionare l’area di lavoro corrente e apportare modifiche rapide.
- Un agente di codifica cloud può lavorare in modo asincrono su un problema e aprire una richiesta pull.
- Un agente CLI si adatta a flussi di lavoro pesanti del terminale e a comandi operativi.
- Un altro provider può offrire un modello o uno stile di ragionamento diverso.
Agent Sessions offre a questi compiti una casa comune. Puoi vedere cosa è in esecuzione, cosa sta facendo e da dove riprendere la conversazione.
Tale visibilità è importante perché il lavoro autonomo non rimuove il coordinamento. Rende il coordinamento un compito di ingegneria di prima classe.
Le Interruzioni Sono Parte del Flusso di Lavoro
La fonte fa una semplice osservazione: “È comune inviare un prompt e rendersi conto di aver dimenticato qualcosa di importante.” In precedenza, la scelta era spesso aspettare o annullare. Con gli editor di chat, puoi aprire una sessione attiva e aggiungere informazioni mentre l’agente sta lavorando.
Questo è più vicino a una vera collaborazione. I requisiti cambiano. Un test rivela un’ipotesi. Un revisore nota che un’API deve rimanere compatibile con le versioni precedenti. L’agente utile non è quello che non ha mai bisogno di correzione; è quello che può assorbire la correzione senza perdere l’intero compito.
Per il lavoro .NET, un’interruzione potrebbe essere semplice come:
Keep the existing public route unchanged. Add the new behavior behind the application service,
use the existing ProblemDetails convention, and add a test for the old response shape.
L’istruzione è breve perché il repository contiene già il contesto più ampio. La sessione è il luogo per correggere la direzione, non per ribadire l’intero sistema.
Agenti Personalizzati Trasformano le Abitudini del Team in Ruoli
VS Code introduce anche agenti specializzati come Plan. Invece di implementare immediatamente, un agente di pianificazione pone domande su ambito, componenti, librerie e vincoli prima di produrre una specifica di implementazione.
Quel modello è utile oltre a un agente integrato. Un team può definire ruoli focalizzati:
- Ricerca raccoglie prove e scrive un breve record di decisione.
- Revisione verifica un cambiamento rispetto alle convenzioni del repository.
- Test identifica i casi mancanti e propone un piano di test.
- Architettura confronta le opzioni senza modificare i file.
Una piccola definizione di agente personalizzato potrebbe assomigliare a questa:
type: agent
name: plan
description: "Refines vague requests into clear implementation specs"
prompt: |
Ask about scope, constraints, existing patterns, and edge cases.
Produce a concise specification before any implementation begins.
La parte utile non è il YAML. È la separazione esplicita delle responsabilità. Un agente di pianificazione non dovrebbe modificare silenziosamente il codice di produzione. Un agente di revisione non dovrebbe riscrivere il design che dovrebbe valutare.
I Subagenti Riducono le Collisioni di Contesto
Le lunghe conversazioni accumulano contesto non correlato. I subagenti forniscono uno spazio di lavoro isolato per un’attività di ricerca limitata, quindi restituiscono il risultato alla sessione principale.
Questo è un buon adattamento per domande come:
Analyze the API project and recommend an authentication strategy.
Return trade-offs and a decision record. Do not edit files.
L’agente principale rimane concentrato sull’implementazione mentre l’agente di ricerca gestisce una domanda più ristretta. Lo stesso principio si applica ai team: una delegazione chiara produce risultati migliori che lanciare diversi agenti con autorità sovrapposta.
L’Avvertenza: Più Agenti Significano Più Coordinamento
Agent Sessions può mostrare attività, ma non può risolvere la proprietà in conflitto. Due agenti che modificano la stessa area possono ancora creare un problema di unione. Un agente cloud e un agente locale possono fare ipotesi incompatibili. Un agente personalizzato può produrre una raccomandazione che un altro agente ignora.
Stabilisci i confini:
- Un agente è proprietario dell’implementazione per un determinato ramo.
- Gli agenti di ricerca restituiscono artefatti, non modifiche non tracciate.
- Le richieste pull rimangono il confine di revisione.
- I nomi degli agenti e i prompt indicano cosa possono cambiare.
- L’output della sessione viene mantenuto quando spiega una decisione importante.
La Mia Opinione
Il futuro multi-agente non è una coda di finestre di chat. È un piccolo team con ruoli, consegne e responsabilità.
Agent Sessions è prezioso perché riconosce quella realtà. Dà agli sviluppatori una superficie di controllo per il lavoro che sta già accadendo nell’editor, nel terminale e nel cloud. Il prossimo guadagno di produttività verrà meno dall’avere più agenti e più dal rendere i loro confini leggibili.
Per un team .NET, inizierei con un agente di pianificazione e un agente di implementazione. Usa l’output della pianificazione come specifica del problema o della richiesta pull, quindi lascia che l’agente di implementazione lavori all’interno di quel confine. Misura la rielaborazione prima di aggiungere più ruoli.
Il miglior mission control è ancora quello che rende la proprietà ovvia.
