Avvio rapido: creare agenti serverless con Funzioni di Azure

In questa guida rapida si distribuiscono agenti serverless in funzioni Azure usando l'interfaccia della riga di comando di Azure Developer (azd). L'esempio include due agenti:

Agente di chat che è possibile usare per testare l'app distribuita in un browser. Questo agente può eseguire codice Python in modalità sandbox e navigare sul web.
Un agente attivato dal timer che raccoglie i post di blog Microsoft recenti, li riepiloga e può inviare un messaggio di posta elettronica tramite strumenti MCP da un server MCP gestito per un connettore di Microsoft 365 Outlook.

Il progetto utilizza il runtime degli agenti serverless funzioni di Azure. È possibile definire gli agenti nei file markdown, configurare le impostazioni predefinite del runtime a livello di app in agents.config.yaml, connettere server MCP remoti in mcp.jsone distribuire l'app come qualsiasi altra app per le funzioni.

Il modello effettua il provisioning di un'app per funzioni a consumo flessibile, di un account di archiviazione, del monitoraggio, di un progetto Microsoft Foundry e della distribuzione di modelli, di un pool di sessioni dinamiche di app contenito Azure e delle assegnazioni di identità necessarie. Quando il recapito della posta elettronica è abilitato, viene anche effettuato il provisioning di un namespace del connettore, di una connessione a Microsoft 365 Outlook e di un server MCP gestito per il connettore.

Il completamento di questa guida introduttiva può comportare un costo ridotto nell'account Azure perché l'app usa il piano Flex Consumption e le risorse correlate Azure.

Prerequisiti

Azure Developer CLI (azd).
interfaccia della riga di comando di Azure. È anche possibile eseguire comandi di interfaccia della riga di comando di Azure in Azure Cloud Shell.
Un account Azure con una sottoscrizione attiva. Creare un account gratuito.
Autorizzazioni per creare gruppi di risorse, app per funzioni, identità gestite, risorse Microsoft Foundry, distribuzioni di modelli, pool di sessioni di App contenitore di Azure, namespace dei connettori e connessioni nella propria sottoscrizione.
Per abilitare il recapito tramite posta elettronica, un account Microsoft 365 a cui è possibile accedere, che può inviare un messaggio di posta elettronica e che è possibile usare come indirizzo del destinatario per verificare l'output dell'agente.

Inizializzare il progetto

Usare il azd init comando per creare un progetto locale dal repository di esempio.

In Visual Studio Code aprire una cartella o un'area di lavoro in cui si vuole creare il progetto.
Nel terminale eseguire questo azd init comando:
```
azd init --template Azure-Samples/functions-quickstart-serverless-agents-azd -e serverless-agents
```
Questo comando recupera i file del progetto dal repository di esempio serverless agents e inizializza il progetto nella cartella corrente. Il flag -e assegna un nome all'ambiente corrente azd, che tiene traccia dello stato di distribuzione e viene usato nei nomi delle risorse Azure.
Abilitare il recapito tramite posta elettronica impostando l'indirizzo di posta elettronica del destinatario usato dall'agente timer. Più avanti in questa guida introduttiva è necessario accedere a un account Microsoft 365 per autorizzare la connessione Microsoft 365 Outlook che invia il messaggio di posta elettronica.
```
azd env set TO_EMAIL <recipient@example.com>
```
Sostituire <recipient@example.com> con il proprio indirizzo di posta elettronica o con un altro destinatario consentito dai criteri di posta elettronica dell'organizzazione. Alcune organizzazioni limitano la posta elettronica basata sul connettore a destinatari interni o bloccano i destinatari esterni, quindi l'invio del messaggio di test a se stessi è l'opzione più affidabile.

Note

Il recapito tramite posta elettronica è facoltativo nell'esempio. Se si salta questa impostazione, azd up non crea il namespace del connettore, la connessione Microsoft 365 Outlook o il server MCP gestito. L'agente timer continua a essere eseguito e restituisce il riepilogo nella risposta finale, così da poter verificare l'esecuzione nei log o in Application Insights.

Esaminare il progetto

Prima di eseguire la distribuzione, esaminare i file di progetto che definiscono l'app agente serverless:

File o cartella	Purpose
`src/main.agent.md`	Definisce l'agente di chat e abilita gli endpoint predefiniti per l'interfaccia utente della chat di debug. Questo agente può usare l'esecuzione di codice in modalità sandbox Python e non usa il server MCP gestito Microsoft 365 Outlook.
`src/daily_microsoft_blog_summary.agent.md`	Definisce l'agente di riepilogo del blog attivato dal timer Microsoft. Il front matter YAML dichiara il trigger timer e il corpo markdown contiene le istruzioni dell'agente.
`src/agents.config.yaml`	Definisce le impostazioni predefinite di runtime a livello di applicazione, inclusi la distribuzione del modello e l'endpoint del pool di sessioni dinamiche di App contenitore di Azure utilizzato dagli agenti dell'applicazione.
`src/mcp.json`	Elenca i server MCP remoti disponibili per gli agenti. In questo modello `src` è la radice del progetto dell'app per le funzioni e questo file include l'endpoint server MCP gestito per Microsoft 365 Outlook quando il recapito della posta elettronica è abilitato.
`infra/`	Contiene i file Bicep usati da `azd` per effettuare il provisioning dell'app per funzioni, dell'archiviazione, del monitoraggio, delle risorse Foundry, della distribuzione del modello, del pool di sessioni, delle risorse facoltative del namespace del connettore e della configurazione dell'identità.
`src/function_app.py`	File di bootstrap necessario per l'host di Functions. In genere non è necessario modificare questo file.

L'agente attivato dal timer è definito in daily_microsoft_blog_summary.agent.md. L'intestazione dichiara la pianificazione del timer e le istruzioni in markdown indicano all'agente di raccogliere i post recenti del blog Microsoft, creare un riepilogo e inviare un'e-mail quando TO_EMAIL è configurato.

Distribuzione su Azure

Usa azd up per eseguire il provisioning delle risorse di Azure e distribuire l'app per le funzioni.

Nel terminale eseguire questo comando dalla radice del progetto inizializzato:
```
azd up
```
Quando richiesto, selezionare la sottoscrizione e la località Azure da usare per il gruppo di risorse.

Il template usa le impostazioni di distribuzione predefinite del modello Microsoft Foundry, a meno che non si personalizzino i parametri Bicep.

Al termine del comando, l'app viene distribuita in una nuova app per le funzioni in Azure. Il risultato della distribuzione include collegamenti alle risorse create.

Autorizzare la connessione

Quando si imposta TO_EMAIL, la distribuzione crea un namespace del connettore con una connessione Microsoft 365 Outlook e un server MCP gestito. Questa configurazione consente all'agente timer di inviare messaggi di posta elettronica tramite gli strumenti del connettore senza codice API Outlook personalizzato. Prima che l'agente possa inviare un messaggio di posta elettronica, autorizzare la connessione accedendo a un account Microsoft 365 in grado di inviare messaggi di posta elettronica.

Se non è stato impostato TO_EMAIL, ignorare questa sezione.

Nel portale Azure cercare Connector Namespace.
Aprire la risorsa spazio dei nomi del connettore creata da azd. La risorsa si trova nel gruppo di risorse creato da azd, il cui nome inizia con rg- e include il nome dell'ambiente scelto durante azd init (serverless-agents se è stato usato il comando di esempio).

Selezionando la risorsa, si apre il portale Connector Namespaces, un ambiente separato per esplorare e gestire le connessioni, i trigger e i server MCP nello spazio dei nomi.
Nel portale Connector Namespaces, individuate il connettore Microsoft 365 Outlook, quindi aprite la connessione creata dalla distribuzione.
Selezionare Authenticate e quindi accedere con l'account Microsoft 365 che può inviare un messaggio di posta elettronica.

Al termine dell'autenticazione, l'identità gestita dell'app per le funzioni può chiamare il server MCP gestito, che usa la connessione autorizzata per inviare messaggi di posta elettronica.

Usa l'agente di debug della chat

L'esempio include un agente di chat che può usare l'esecuzione di codice Python tramite il pool di sessioni dinamiche di App contenitore di Azure. L'interfaccia utente della chat è una superficie di debug per testare l'app agente distribuita.

Dopo il completamento di azd up, aprire l'endpoint dell'app per funzioni visualizzato nell'output della distribuzione e quindi andare a /agents/main/. Quando l'interfaccia utente della chat viene caricata, richiede una chiave di funzione in modo che possa chiamare l'endpoint della chat dell'agente.

Ottenere la chiave di funzione predefinita per l'app:

az functionapp keys list \
  --resource-group <RESOURCE_GROUP> \
  --name <FUNCTION_APP_NAME> \
  --query "functionKeys.default" \
  --output tsv

Incollare la chiave restituita nel prompt dell'interfaccia utente della chat.

Provare a porre all'agente di chat una domanda che trae vantaggio dalle informazioni pubbliche correnti o dall'esecuzione del codice. Ad esempio, chiedere What's the weather in Seattle right now? o Compare the current weather in Seattle and New York.

L'agente di chat non usa il server MCP gestito Microsoft 365 Outlook. Il recapito tramite posta elettronica viene usato solo dall'agente di riepilogo del blog attivato dal timer.

Eseguire l'agente del timer su richiesta

L'agente viene eseguito automaticamente in base alla pianificazione del timer. Per testarla immediatamente, eseguire manualmente la funzione attivata dal timer dal portale di Azure.

Nel portale Azure aprire l'app per le funzioni creata da azd.
Nel pannello Panoramica selezionare Funzioni e quindi selezionare la funzione dell'agente attivata dal timer denominata daily_microsoft_blog_summary.
Selezionare Codice e test.
Selezionare Log per aprire il flusso di log per questa funzione.
Selezionare Test/Esegui, lasciare il corpo della richiesta come {}e quindi selezionare Esegui.

La richiesta restituisce una risposta accettata e l'esecuzione della funzione viene avviata in background.

Monitorare l'esecuzione

Torna al riquadro Logs in Code + Test per la funzione attivata tramite timer. I log mostrano l'esecuzione della funzione e i messaggi di runtime. A seconda del livello di log di runtime, è anche possibile visualizzare l'attività del modello e degli strumenti.

È anche possibile usare Application Insights per esaminare l'esecuzione dopo l'inserimento dei dati di telemetria:

Nel menu a sinistra dell'app per le funzioni selezionare Application Insights.
Aprire la risorsa di Application Insights associata.
Usare La ricerca transazioni o i log per trovare l'esecuzione avviata quando è stata eseguita manualmente la funzione.

L'esecuzione viene completata quando i log indicano che l'esecuzione della funzione è stata completata correttamente. Se l'invio di e-mail è abilitato e la connessione a Microsoft 365 Outlook è autorizzata, controllare la posta in arrivo del destinatario per verificare la presenza del riepilogo del blog Microsoft. In caso contrario, esaminare la risposta finale dell'agente nei log delle funzioni o in Application Insights.

Pulire le risorse

Al termine, usare questo comando per eliminare l'app per le funzioni e le risorse correlate da Azure:

azd down

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-06-03