Creare agenti ospitati con Microsoft Foundry Toolkit per Visual Studio Code

Usare Microsoft Foundry Toolkit per Visual Studio Code per creare un flusso di lavoro basato su codice da un esempio Microsoft Agent Framework. Eseguirlo localmente con Agent Inspector, quindi distribuirne il codice sorgente nel servizio Foundry Agent come agente ospitato. Tu mantieni il codice e le sue dipendenze. Foundry gestisce l'infrastruttura di hosting e il ridimensionamento.

I flussi di lavoro ospitati coordinano gli agenti nel codice. Differiscono dal servizio di workflow dichiarativo di Foundry in dismissione. Per altre route di creazione, vedere Creare un agente.

Prerequisiti

  • Installare Microsoft Foundry Toolkit per Visual Studio Code.

  • Selezionare un progetto Foundry con un modello distribuito. Usare un'area geografica supportata per l'agente ospitato.

  • Autorizzazione per usare il modello e distribuire gli agenti ospitati. Per la distribuzione del codice sorgente, il ruolo Foundry Project Manager a livello di progetto comprende le operazioni relative all’agente e le autorizzazioni per l’assegnazione dei ruoli. Vedere Autorizzazioni dell'agente ospitato.

    Importante

    I ruoli RBAC di Foundry sono stati recentemente rinominati. Foundry User, Foundry Owner, Foundry Account Owner e Foundry Project Manager erano precedentemente denominati Azure AI User, Azure AI Owner, Azure AI Account Owner e Azure AI Project Manager. È possibile che i nomi precedenti vengano visualizzati in alcune posizioni durante l'esecuzione della ridenominazione. Gli ID ruolo e le autorizzazioni di base sono invariati dalla ridenominazione.

  • interfaccia della riga di comando di Azure per la procedura di autenticazione locale in questo articolo.

  • Per la distribuzione dei contenitori, sono necessari l'accesso al registro e l'accesso all'immagine richiesti dalla configurazione di Registro Azure Container. Questi requisiti del Registro di sistema non si applicano a una distribuzione del codice sorgente.

  • Python 3.13 per il runtime ospitato configurato per l'esempio.
  • L'estensione Python per Visual Studio Code.

Il percorso di distribuzione principale usa Codice con modalità pacchetto remoto e non richiede una compilazione Docker locale. L'esecuzione locale invia comunque richieste di modello a Foundry e può comportare addebiti. Esamina i limiti e disponibilità del servizio e le note di rilascio del Toolkit per le funzionalità che usi.

Creare un flusso di lavoro dell'agente ospitato

Scegliere un esempio di Framework agente che usa il protocollo Responses. Non è prima necessario creare un agente di prompt separato. Per confrontare esempi, Agent Builder e la codifica assistita da Copilot, vedere Scegliere un percorso di creazione.

Usa il flusso di lavoro multi-agente (framework di agenti), che collega in sequenza uno scrittore, un revisore e un formattatore. La risposta finale proviene dal formattatore. Esaminare l'esempio di flusso di lavoro Python per l'implementazione completa e le indicazioni sul modello.

Usa Flusso di lavoro di traduzione, che collega in sequenza tre agenti di traduzione: dall'inglese al francese, dal francese allo spagnolo e dallo spagnolo all'inglese. Esaminare l'esempio di flusso di lavoro C# per l'implementazione completa.

  1. Nella visualizzazione Foundry Toolkit, seleziona Strumenti di sviluppo>Compila>Crea agente.

  2. In Crea il codice di un agente da esempi, selezionare Visualizza tutti gli esempi.

  3. In Crea agente ospitato da un esempio, filtra per Lingua, Framework = e Tipo di protocollo = . Cercare "workflow".

    La schermata seguente mostra la galleria con Basic Hosted Agent selezionato come esempio. Per questa guida, selezionare invece l'esempio del flusso di lavoro per la lingua.

    Schermata della raccolta di esempi dell'agente ospitato con Agente ospitato di base selezionato, esempi di flusso di lavoro e filtri per lingua, framework e protocollo.

  4. Selezionare l'esempio del flusso di lavoro per la lingua.

  5. Seleziona Avanti.

  6. In Crea scegliere la cartella dell'area di lavoro. Se la cartella contiene già file, immettere un Nome della cartella per una nuova sottocartella.

  7. Se viene visualizzato Il programma di installazione dell'ambiente, selezionare Setup with Microsoft Foundry (Installazione dell'ambiente) e quindi selezionare la sottoscrizione e il progetto. Quando un progetto predefinito è già selezionato, il modulo usa tale progetto.

  8. Selezionare una distribuzione del modello compatibile esistente.

    Lo screenshot seguente mostra le impostazioni del progetto di esempio con percorsi locali nascosti. Usa la destinazione desiderata e la distribuzione del modello richiesta per l'esempio.

    Screenshot della scheda Crea che mostra la cartella dell'area di lavoro, il nome della cartella, la distribuzione del modello e i controlli Crea con percorsi locali nascosti.

  9. Esaminare la destinazione e quindi selezionare Crea.

  10. Aprire il progetto generato in Visual Studio Code e leggerne README.md.

I riquadri Agent Framework, Copilot SDK e LangGraph in Crea agente aprono la scheda Crea con uno starter hello-world selezionato. Usare Esplora tutti gli esempi per scegliere un flusso di lavoro anziché uno di questi starter. Puoi anche aprire la galleria da My Resources>>>.

I nomi e i contenuti di esempio possono cambiare con il catalogo. Alcune versioni etichettano questi esempi come Flussi di lavoro. Usare il collegamento GitHub dell'esempio per verificare che sia stato selezionato il flusso di lavoro previsto.

Salta per ora genera il codice senza completare la configurazione del modello. Se lo si sceglie, configurare i valori di progetto e modello necessari prima di eseguire l'esempio. Distribuisci e usa un nuovo modello, se offerto, effettua il provisioning di una distribuzione del modello, non l'agente ospitato. La creazione dei file di progetto locale non distribuisce l'agente.

Configurare il progetto locale

Mantenere la cartella che contiene azure.yaml aperta come radice dell'area di lavoro. Controllare il percorso project del servizio hosted-agent in quel file per trovare la directory di origine.

Artefatto Purpose
azure.yaml Dichiara il servizio agente ospitato, la directory di origine, il runtime, i protocolli e le impostazioni di distribuzione.
main.py o Program.cs nella directory di origine Implementa il flusso di lavoro e avvia il server Risposte.
requirements.txt o il .csproj file Dichiara le dipendenze per la lingua selezionata.
.env nella directory di origine Contiene valori di progetto e modello locali. Il Toolkit lo crea da .env.example quando l'esempio fornisce tale file.
.vscode/launch.json e .vscode/tasks.json Configurare il server locale, l'allegato del debugger e Agent Inspector.

I layout di esempio possono cambiare. Usare i file generati README.md e azure.yaml invece di presumere che il codice e il file dell'ambiente si trovino nella directory radice dell'area di lavoro.

Installa le dipendenze

Usare i file di dipendenza dell'esempio generato. Mantenere l'interprete selezionato o l'SDK coerente con la configurazione di runtime.

  1. Eseguire Python: Crea ambiente... dal riquadro comandi per creare un ambiente virtuale o Python: selezionare interprete per selezionare un ambiente esistente Python 3.13. Per la configurazione e la selezione dell'ambiente, vedere Python ambienti in Visual Studio Code.

  2. Aprire un terminale con tale ambiente attivo. Passare alla directory di origine che contiene main.py e requirements.txt.

  3. Installa i pacchetti dell'esempio:

    python -m pip install -r requirements.txt

    I requisiti includono debugpy, che è usato dalla configurazione F5 generata. Riferimento: dipendenze del flusso di lavoro di Python.

  1. Eseguire C#: controllare i requisiti dell'area di lavoro dal riquadro comandi.

  2. In un terminale passare alla directory di origine che contiene il file e ripristinare i .csproj relativi pacchetti:

    dotnet restore

    Riferimento: dotnet restore.

Per i controlli e la configurazione del debugger, vedere Debug C# in Visual Studio Code.

Impostare il progetto e il modello

Esaminare il .env file nella directory di origine. Se non esiste, crearlo con i valori richiesti dall'esempio.

Variabile Value
FOUNDRY_PROJECT_ENDPOINT L'endpoint del progetto, nel formato https://<resource-name>.services.ai.azure.com/api/projects/<project-name>.
AZURE_AI_MODEL_DEPLOYMENT_NAME Il nome della distribuzione del modello in quel progetto, non solo il nome del catalogo del modello.

Entrambi gli esempi del flusso di lavoro vengono caricati .env durante l'avvio. L'endpoint del progetto non è un endpoint dell'account OpenAI Azure. Mantenere il file fuori dal controllo del codice sorgente e non inserire le credenziali nel codice dell'applicazione.

Eseguire l'autenticazione in locale

Gli esempi usano DefaultAzureCredential. Per il percorso delle credenziali interfaccia della riga di comando di Azure, accedere con un account che può accedere al modello del progetto:

az login

Riferimento: accedere con interfaccia della riga di comando di Azure.

L'accesso al toolkit seleziona il progetto per le operazioni di estensione. Il processo dell'agente locale richiede anche una credenziale compatibile. Per altre opzioni, vedere DefaultAzureCredential per Python o catene di credenziali per .NET.

Eseguire il flusso di lavoro ospitato in locale

Usare la configurazione di debug generata per avviare il server HTTP e aprire Agent Inspector. L'apertura di Agent Inspector da sola non avvia il server.

Usare questa richiesta di test: Create a slogan for a new electric SUV that is affordable and fun to drive. Il flusso di lavoro restituisce uno slogan formattato dopo che il redattore, il revisore e il formattatore hanno completato il proprio lavoro.

Usare questa richiesta di test: The quick brown fox jumps over the lazy dog. il flusso di lavoro esegue la catena di traduzione e restituisce una risposta.

  1. Tornare all'area di lavoro del progetto generata.
  2. Impostare un punto di interruzione nel codice del flusso di lavoro se si vuole esaminare l'esecuzione.
  3. Premere F5. Se richiesto, selezionare Debug Local Agent HTTP Server.
  4. Attendere che il server si avvii e che Agent Inspector si apra.
  5. Inviare la richiesta di test per l'esempio.
  6. Esaminare la risposta e ripetere con un'altra richiesta. Se si imposta un punto di interruzione, esaminare i valori e continuare l'esecuzione.

Dopo il funzionamento dell'esempio, modificare il flusso di lavoro e ripetere il test locale. Se si aggiungono strumenti, inviare una richiesta che richiede un risultato reale dello strumento ed esaminare la chiamata. Una risposta generata solo dal modello o una risposta simulata non dimostra che lo strumento in produzione funzioni.

Lo screenshot mostra un agente locale abilitato per gli strumenti, non uno dei due esempi del flusso di lavoro. Agent Inspector visualizza la risposta e le relative chiamate agli strumenti con un grafico a cascata della latenza e una cronologia dell’esecuzione. I dettagli di ispezione disponibili dipendono dall'agente in esecuzione e dalla relativa strumentazione.

Schermata di Agent Inspector collegato a localhost sulla porta 8088 con il protocollo Responses, le chiamate agli strumenti, un grafico a cascata della latenza e una cronologia dell’esecuzione.

Se si usa GitHub Copilot, è possibile eseguire /validate-microsoft-foundry-hosted-agent in Copilot Chat per esaminare il progetto rispetto alle procedure consigliate di Foundry. Questo comando Chat apre un report; non è un comando terminale o un sostituto per l'esecuzione del flusso di lavoro.

Le attività generate usano la porta 8088 per il server agente. Il debug di Python usa anche la porta 5679. Se all'avvio viene segnalato un conflitto di porta, termina il processo in conflitto di tua proprietà oppure modifica in modo coerente la configurazione del task generato.

Eseguire senza il debugger

Per eseguire manualmente, aprire un terminale nella directory di origine dell'esempio con le relative dipendenze, valori di ambiente e Azure credenziali disponibili.

python main.py

Riferimento: punto di ingresso del flusso di lavoro Python.

Impostare l'indirizzo HTTP per il server locale, quindi eseguirlo:

$env:ASPNETCORE_URLS = "http://localhost:8088"
dotnet run

Riferimento: URL del server di ASP.NET Core e dotnet run.

Quindi esegui Foundry Toolkit: Open Agent Inspector dalla Palette dei comandi e connettiti al server locale alla porta 8088. L'esecuzione di un esempio con python o dotnet run avvia un processo locale, non un contenitore.

Visualizzare l'esecuzione del flusso di lavoro dell'agente ospitato

Usa Agent Inspector per ispezionare gli eventi, le risposte e le chiamate agli strumenti emessi dal tuo agente in esecuzione. Quando il runtime genera eventi del flusso di lavoro, usare la visualizzazione del flusso di lavoro per esaminare la sequenza di passaggi.

I dettagli disponibili dipendono dalla strumentazione dell'esempio. Seguire le istruzioni di configurazione della telemetria dell'esempio per i requisiti relativi allo specifico runtime.

Questi passaggi usano il protocollo Risposte. Altri esempi richiedono client compatibili con il rispettivo protocollo: la vista Invocazioni HTTP non è un client WebSocket e gli esempi di attività Python usano Microsoft 365 Agents Playground. Seguire le istruzioni di test locali dell'esempio selezionato. La modifica di un nome di protocollo nella configurazione non aggiunge tale protocollo al server. Vedere Scegliere un protocollo dell'agente ospitato.

Distribuire l'agente ospitato su piattaforma

Dopo che il flusso di lavoro locale si comporta come previsto, distribuirlo dall'area di lavoro del progetto. Python e C# condividono la procedura di distribuzione. Inizia con Code e la modalità pacchetto Remote per caricare il codice sorgente e consentire a Foundry di ripristinare le dipendenze.

Preparare la configurazione della distribuzione

Rivedi e salva il servizio dell'agente ospitato in azure.yaml. Mantenere la configurazione del protocollo dell'esempio e dichiarare la distribuzione del modello e altre impostazioni di runtime necessarie.

La distribuzione ricava i valori di ambiente dichiarati dal file .env della directory di origine o dall'ambiente del processo. Non inoltra ogni voce locale .env . La piattaforma fornisce valori di runtime riservati, come FOUNDRY_PROJECT_ENDPOINT; non ridefinirli come impostazioni di distribuzione. Vedere Variabili di ambiente inserite dalla piattaforma.

Esaminare le regole di esclusione della directory sorgente prima di creare il pacchetto. Tieni .env, le credenziali, gli ambienti virtuali e le cache fuori dal pacchetto. Per la distribuzione ZIP, una radice .agentignore di origine sostituisce le regole in .gitignore e .dockerignore, quindi mantiene le esclusioni necessarie se si aggiunge tale file.

Importante

Non eseguire il commit né includere segreti nei pacchetti. L'accesso locale non trasferisce le autorizzazioni dell'utente all'agente distribuito. Configurare l'accesso all'identità di runtime dell'agente e alle connessioni supportate. Vedere Autorizzazioni dell'agente ospitato.

Distribuire il sorgente con la modalità pacchetto remoto

Usare la directory radice dell'area di lavoro generata in modo che il Toolkit possa leggere la configurazione del servizio e individuarne la directory sorgente.

  1. Arrestare la sessione di debug locale.

  2. Selezionare Strumenti di sviluppo>Build>Distribuisci in Microsoft Foundry. È anche possibile eseguire Foundry Toolkit: Distribuire l'agente ospitato dal riquadro comandi.

    Schermata di Deploy to Microsoft Foundry in Build, nella sezione Foundry Toolkit Developer Tools.

  3. Se viene visualizzato Foundry Project Setup, selezionare la sottoscrizione e il progetto, quindi selezionare Avanti. In caso contrario, verificare che il progetto predefinito sia la destinazione desiderata.

  4. In Informazioni di base selezionare Codice come Metodo di distribuzione e Remoto come modalità pacchetto.

  5. Selezionare Nuovo agente e immettere il nome dell'agente ospitato. Per aggiornare un agente distribuito, selezionare Agente esistente e scegliere l'agente.

    Schermata di Basics con Code deployment, Remote package mode e New agent selezionati, con il nome dell'agente nascosto.

  6. Seleziona Avanti.

  7. In Rivedi e distribuisci controllare lingua, versione del runtime, punto di ingresso e CPU e memoria rispetto all'esempio. Verificare che la directory di origine corrisponda al percorso del project servizio.

    Lo screenshot seguente mostra un esempio con Python 3.14 e il relativo punto di ingresso nascosto, non le impostazioni per questi esempi del flusso di lavoro. Per Python, usare Python 3.13 con python3 main.py. Per C#, usare .NET 10 e il punto di ingresso rilevato per il progetto generato.

    Schermata di Review + Deploy che mostra Python 3.14 come esempio, un punto di ingresso nascosto, CPU e memoria, e i controlli di distribuzione.

  8. Seleziona Distribuisci. Segui l'avanzamento nelle notifiche e nell'Output.

  9. Continuare a Testare il flusso di lavoro distribuito.

Associare il runtime alla configurazione di esempio e all'ambiente locale. Non accettare un runtime diverso solo perché è l'impostazione predefinita della procedura guidata.

Il Toolkit salva le scelte di distribuzione quando si invia il modulo. Queste impostazioni locali non dimostrano che la distribuzione cloud ha avuto esito positivo. L'aggiornamento di un agente esistente crea una nuova versione anziché modificare una versione precedente.

Scegliere un'altra modalità pacchetto ZIP

Il Toolkit offre queste opzioni di creazione di pacchetti di codice sorgente:

Modalità pacchetto Che succede Cosa preparare
Remoto Origine dei pacchetti toolkit. Foundry ripristina i requisiti di Python o il progetto .NET durante il provisioning. Origine, dichiarazioni di dipendenza e punto di ingresso compatibile.
In bundle Il Toolkit prepara i file sorgente ed esegue localmente il comando Package prima di creare il file ZIP. Foundry esegue il pacchetto preparato. Dipendenze di Linux compatibili e gli strumenti locali richiesti dal comando . Il comando Python predefinito installa le dipendenze compatibili in packages/; il comando .NET genera l'output di pubblicazione.

I runtime ZIP selezionabili sono Python 3.13, Python 3.14 e .NET 10. Abbina il runtime al tuo codice e alle relative dipendenze. Per i layout, i limiti e i requisiti del servizio, vedere Distribuire dal codice sorgente. Per i criteri di supporto del runtime, vedere Runtime supportati dell'agente ospitato.

Distribuire un'immagine del contenitore

Scegliere Contenitore in nozioni di base quando è necessaria un'immagine di runtime personalizzata o avere già un'immagine compatibile.

Scelta del registro Comportamento del toolkit
ACR predefinito Crea o riutilizza un registro per il progetto selezionato, quindi compila ed esegue il push dell'immagine tramite Registro Azure Container (ACR).
ACR personalizzato Usa un registro esistente che selezioni, quindi crea ed esegue il push dell'immagine tramite ACR.
Immagine ACR personalizzata Usa un riferimento a un'immagine ACR predefinita senza creare né caricare il codice sorgente.

Per le opzioni di compilazione, esaminare il dockerfile e il contesto di compilazione prima della distribuzione. Se si genera un Dockerfile nella procedura guidata, esaminare il file e selezionare Continua e distribuisci. Queste opzioni usano build remote di Azure Container Registry, non build Docker locali.

Le opzioni del Registro di sistema personalizzate usano un Registro di sistema nella sottoscrizione selezionata. Il percorso di build del registro personalizzato richiede l'accesso alla rete pubblica; il percorso dell'immagine predefinita ha requisiti distinti per la rete privata. La scelta di un'immagine non configura la connettività di rete.

Esaminare i requisiti dei contenitori e le linee guida sulla rete privata prima di usare un registro personalizzato. Queste distribuzioni sono destinate a Foundry Agent Service, non al percorso dell'agente ospitato in App contenitore di Azure dismesso. Per spostare un agente meno recente, seguire Eseguire la migrazione dall'anteprima dell'agente ospitato.

Testare il flusso di lavoro distribuito

Una richiesta di creazione riuscita non dimostra che il runtime è pronto o che i relativi strumenti e modelli siano raggiungibili. Testare la versione esatta distribuita.

  1. In Risorse personaliAgenti>>, selezionare il nome dell'agente.
  2. Selezionare la versione numerata appena distribuita.
  3. In Dettagli, attendere che lo stato della distribuzione indichi che l'agente è in esecuzione. In caso di errore, esaminare l'output della distribuzione prima di riprovare.
  4. Aprire Playground e inviare la stessa richiesta testata in locale.
  5. Esaminare la risposta. Se sono stati aggiunti strumenti, inviare una richiesta che richiede tali strumenti ed esaminare le chiamate.

Le esecuzioni locali e cloud usano credenziali, ambienti di dipendenza e percorsi di rete diversi. Una risposta locale con esito positivo non garantisce una risposta remota riuscita.

Esaminare e aggiornare l'agente distribuito

Usa il playground remoto per testare e ispezionare l'agente distribuito. A differenza dei test locali con Agent Inspector, le richieste in questo playground vengono eseguite sull'agente ospitato in Foundry.

  1. In Foundry Toolkit, seleziona Strumenti per sviluppatori>Build>Hosted Agent Playground.

    Schermata dell'area di test dell'agente ospitato in Build nella sezione Strumenti di sviluppo di Foundry Toolkit.

  2. Nell'elenco a discesa Agente ospitato selezionare l'agente distribuito e la versione da esaminare. Aprire Playground per inviare una richiesta e visualizzare i dettagli della risposta e della sessione.

    La schermata seguente mostra una risposta illustrativa di un agente distribuito, non l'output previsto di nessuno dei due esempi di flusso di lavoro. Gli identificatori dell'agente e della sessione sono nascosti.

    Schermata del playground dell'agente ospitato remoto con una risposta, i dettagli della sessione e le schede di ispezione, con gli identificatori dell'agente e della sessione nascosti.

Usare questi controlli per controllare e aggiornare l'agente. Le schede disponibili dipendono dal protocollo e dai servizi connessi.

Task Action
Rivedere i dettagli della distribuzione Aprire Dettagli per lo stato, la configurazione e l'endpoint copiabile.
Testare una versione Selezionare una versione numerata per le richieste del playground. Automatico usa la stessa selezione di versione dell'endpoint del servizio, che non corrisponde necessariamente alla versione più recente. La selezione non modifica il routing per altri client.
Esaminare i log di esecuzione Aprire Sessioni, selezionare una sessione e visualizzarne i log. I log di runtime richiedono una sessione; l'output di compilazione è separato. L'arresto di un flusso di log o l'annullamento di una richiesta non arresta l'agente ospitato.
Recuperare il codice distribuito Usare Scarica asset di codice per una distribuzione ZIP. Una distribuzione di immagini espone il riferimento all'immagine anziché un progetto di origine scaricabile.
Comportamento dell'aggiornamento Modificare e testare il codice locale, quindi ripetere la procedura di distribuzione con l'agente esistente per creare una nuova versione.

Usare tracce e valutazione, se disponibili, per l'analisi e la misurazione della qualità oltre una risposta riuscita. Rispettare i prerequisiti per il tracciamento dell'agente ospitato e la valutazione dell'agente ospitato.

Il deployment fornisce all'agente un endpoint per l'uso programmatico. Non è necessario un passaggio di pubblicazione separato per l'accesso all'API. La pubblicazione in Teams o Microsoft 365 è un'attività separata. Consulta l'endpoint dell'agente attuale e il modello di pubblicazione.

Troubleshooting

Usare l'errore segnalato e la configurazione di esempio per identificare il passaggio con esito negativo.

Sintomo Action
L'avvio locale non riesce perché manca un pacchetto. Confermare l'interprete o l'SDK selezionato, quindi installare le dipendenze dalla directory di origine dell'esempio.
Non è possibile trovare l'endpoint del progetto o il modello. Controlla FOUNDRY_PROJECT_ENDPOINT e AZURE_AI_MODEL_DEPLOYMENT_NAME. Non sostituire un endpoint dell'account o il nome del catalogo dei modelli.
L'autenticazione o l'autorizzazione non riesce. Controllare le credenziali locali e l'accesso al progetto. Verificare le autorizzazioni dell'agente ospitato per i requisiti dell'identità di distribuzione e di runtime.
Agent Inspector non riesce a connettersi. Verificare che il server sia stato avviato e che la porta 8088 sia disponibile. L'apertura di Inspector da sola non avvia il server.
Una distribuzione non va a buon fine. Esaminare l'errore di distribuzione e l'output di compilazione. Per il codice, verifica il runtime, il punto di ingresso, la modalità del pacchetto e le regole di esclusione. Per il contenitore, controllare le autorizzazioni per l'immagine e per il registro.
La risposta locale funziona, ma la versione distribuita non riesce. Confrontare l'ambiente distribuito e le autorizzazioni di identità con la configurazione locale. Ripetere il test sulla versione esatta distribuita.

Pulire le risorse

Arrestare la sessione di debug locale al termine dell'operazione. Se l'agente di test distribuito non è più necessario, seguire Gestire gli agenti ospitati per rimuoverlo.

L'eliminazione dell'agente rimuove le versioni e termina le sessioni attive. Non rimuove tutte le risorse Azure associate.

Eliminare solo le risorse cloud create per questo esercizio che non sono utilizzate da altre applicazioni. Non eliminare un progetto Foundry condiviso, una distribuzione di modelli o un registro contenitori.

Contenuti correlati

Usare queste guide per estendere il flusso di lavoro:

  • Last updated on