Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo illustra come distribuire un agente Hosted in Foundry Agent Service da Python o .NET codice sorgente, senza compilare o eseguire il push di un'immagine del contenitore. Carichi un .zip del tuo codice (e facoltativamente le tue dipendenze) e Agent Service lo esegue così com'è oppure crea le dipendenze per te nel cloud.
Tip
Per la maggior parte degli scenari, eseguire la distribuzione con l'interfaccia della riga di comando di Azure Developer CLI (azd) o Foundry Toolkit per VS Code. Questi strumenti svolgono automaticamente le operazioni più complesse per te: creano il pacchetto del codice sorgente, lo caricano, verificano periodicamente la presenza di active e configurano automaticamente il controllo degli accessi basato sui ruoli. Per iniziare, seguire la guida introduttiva: Distribuire il primo agente ospitato e scegliere Codice (o Codice sorgente (caricamento ZIP)) quando viene richiesto un metodo di distribuzione.
Usare le procedure SDK e REST in questo articolo quando è necessario distribuire agenti di codice sorgente a livello di codice, dall'SDK di Python o .NET SDK nelle proprie applicazioni oppure direttamente tramite l'API REST per strumenti personalizzati, automazione indipendente dal linguaggio o integrazione con sistemi di recapito continuo esistenti. In questo articolo vengono completate le attività seguenti:
- Scegli una modalità di risoluzione delle dipendenze e crea il pacchetto del codice sorgente.
- Creare l'agente, attendere che raggiunga
activee richiamarlo. - Aggiornamento, informazioni sulla versione, download e visualizzazione in streaming dei log per l'agente distribuito.
Se è necessario il controllo completo dell'immagine di runtime o si dispone già di un Dockerfile funzionante, usare il percorso basato su contenitore: Distribuire un agente ospitato.
Importante
La distribuzione del codice sorgente per gli agenti ospitati è in anteprima. Le funzionalità, la disponibilità dell'area e le API possono cambiare prima della disponibilità generale.
Prerequisiti
- Un progetto Microsoft Foundry in un'area geografica supportata.
- interfaccia della riga di comando di Azure versione 2.80 o successiva, con accesso effettuato al tenant proprietario del progetto.
pipda Python 3.13 o versione successiva, per creare localmente un pacchetto sorgente.La
azure-ai-projectsversione 2.2.0 o successiva eazure-identityi pacchetti.pip install "azure-ai-projects>=2.2.0" azure-identity
Runtime supportati
Il code_configuration.runtime campo nella definizione dell'agente accetta i valori seguenti. Selezionare il runtime che corrisponde ai file binari nel file ZIP, ovvero le ruote x86_64 Linux per Python o il TargetFramework dell'output dotnet publish per .NET.
| Language | Valori di runtime |
|---|---|
| Python |
python_3_13, python_3_14 |
| .NET | dotnet_10 |
Criteri di supporto per le versioni del linguaggio
Il runtime del servizio Agent comprende l'immagine del contenitore generata dalla piattaforma per ogni valore di code_configuration.runtime. Per mantenere completamente supportati gli agenti distribuiti, Foundry allinea il supporto linguistico dell'agente ospitato con il supporto end-of-life per ogni lingua. Il supporto termina alla data di fine del supporto della community per la versione della lingua. Microsoft potrebbe ritirare un valore code_configuration.runtime in precedenza quando i vincoli della piattaforma (ad esempio l'immagine di base sottostante) lo richiedono.
Per le tempistiche di fine supporto upstream, consultare:
- Python: Status delle versioni di Python (python.org).
- .NET: criteri di supporto .NET e .NET Core.
Fase di ritiro
Dopo una data di fine vita del linguaggio, è comunque possibile creare, aggiornare ed eseguire agenti ospitati che usano il valore di runtime ritirato. Tuttavia, tali agenti non possono usufruire del supporto, delle nuove funzionalità o delle patch di sicurezza finché non li aggiorni a un runtime supportato impostando un valore code_configuration.runtime corrente e redistribuendoli.
Autorizzazioni necessarie
Per distribuire un agente ospitato, è necessario disporre del ruolo Foundry Project Manager a livello di progetto. Questo ruolo concede le autorizzazioni del piano dati per creare e aggiornare gli agenti, oltre alla possibilità di creare assegnazioni di ruolo per l'identità dell'agente creata dalla piattaforma, se necessario. Per una suddivisione dettagliata delle autorizzazioni coinvolte, vedere Riferimento alle autorizzazioni dell'agente ospitato.
Importante
I ruoli di Controllo degli accessi in base al ruolo 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.
L'agente viene eseguito con un'identità gestita assegnata dalla piattaforma ed è separata dall'identità dell'utente. Questa identità può accedere alle funzionalità di inferenza del modello tramite l'endpoint del progetto e all'archiviazione delle sessioni per impostazione predefinita. Per le risorse esterne (ad esempio una propria archiviazione di Azure), assegnare manualmente i ruoli RBAC al Microsoft Entra ID dell'agente. Per altre informazioni, vedere Accesso dell'agente oltre le impostazioni predefinite.
Per le chiamate REST, includere l'intestazione della funzionalità di anteprima nelle richieste di modifica (Creazione, Aggiornamento, Eliminazione) mentre la funzionalità è in anteprima:
Foundry-Features: CodeAgents=V1Preview,HostedAgents=V1Preview
Le richieste GET oggi funzionano anche senza questa intestazione, ma, per sicurezza, includerla in ogni chiamata: l'intestazione controlla il comportamento di anteprima e potrebbe essere applicata in modo più rigoroso prima della GA.
Ciclo di vita dell'implementazione
Ogni distribuzione del codice sorgente segue la stessa sequenza: creazione del pacchetto -> crea o aggiorna -> verifica fino a active -> invocazione. Il percorso del codice sorgente usa code_configuration nella definizione dell'agente. Il percorso basato su immagine usa container_configuration invece. Queste due opzioni si escludono a vicenda in una singola versione.
Scegliere il percorso adatto al flusso di lavoro. Se non si è certi, iniziare con l'interfaccia della riga di comando di Azure Developer o VS Code, è il percorso consigliato per la maggior parte dei clienti.
| Percorso | Ideale per | Imballaggio |
|---|---|---|
| Azure Developer CLI o VS Code | La maggior parte delle distribuzioni, incluse le prime distribuzioni e il ciclo interno più veloce. | Gli strumenti compilano e caricano automaticamente il file ZIP. |
| PYTHON SDK | Distribuzione tramite codice da applicazioni Python o automazione. | Si compila il zip; l'SDK lo carica. |
| .NET SDK | Distribuzione tramite codice da app .NET o tramite automazione. | L'SDK crea un file ZIP di una cartella per te. |
| API REST | Strumenti personalizzati, automazione indipendente dal linguaggio e sistemi CD. | Crei l'archivio ZIP e invii la richiesta multipart. |
Scegliere la modalità di risoluzione delle dipendenze
Prima di iniziare, selezionare un valore per code_configuration.dependency_resolution. Questa scelta influisce su ciò che viene inserito nell'archivio ZIP.
| Value | Behavior | Usa quando |
|---|---|---|
remote_build |
Il servizio Agent installa le dipendenze da requirements.txt (Python) o ripristina il file di progetto (.NET) durante il provisioning. |
Vuoi un upload ridotto e il loop interno più semplice possibile. Consigliato per gli utenti per la prima volta. |
bundled |
Il file ZIP viene eseguito così com'è. Fornisci dipendenze Linux precompilate in packages/ (Python) o nell'output di dotnet publish (.NET). |
Servono build riproducibili, le dipendenze sono private o solo wheel, oppure il progetto non si ripristina correttamente sul server. |
Per la modalità in bundle, vedere Creare manualmente il pacchetto zip per i comandi di compilazione locale.
Requisiti del firewall per le reti virtuali private
Se si protegge il progetto con una rete virtuale privata, aggiornare i criteri di rete per consentire le connessioni in uscita agli endpoint seguenti prima della distribuzione.
Tutte le distribuzioni di codice sorgente richiedono l'accesso in uscita a:
mcr.microsoft.com*.login.microsoft.com
La risoluzione delle dipendenze bundled richiede anche l'accesso in uscita a:
deb.debian.orgpackages.microsoft.com
Senza questi percorsi in uscita, il provisioning non può scaricare ciò di cui ha bisogno e la distribuzione non va a buon fine. Per la configurazione di rete, vedere Distribuire un agente ospitato in una rete virtuale.
Eseguire la distribuzione usando l'interfaccia della riga di comando per sviluppatori di Azure o VS Code
La CLI per sviluppatori di Azure (azd) e il Foundry Toolkit per VS Code automatizzano l'intero ciclo di distribuzione del codice sorgente: impacchettano il codice sorgente in un file ZIP, ne calcolano l'hash SHA-256, lo caricano, verificano ripetutamente lo stato di active e configurano per te il controllo degli accessi basato sui ruoli. Questi strumenti sono il percorso consigliato per la maggior parte dei clienti e il ciclo interno più veloce.
Per una procedura dettagliata, vedere Avvio rapido: Distribuire il primo agente ospitato. Scegliere Codice (o Codice sorgente (caricamento ZIP)) quando la guida introduttiva richiede un metodo di distribuzione.
Selezionare la distribuzione del codice sorgente
Quando si esegue azd ai agent init in modo interattivo, lo strumento richiede di scegliere una modalità di distribuzione. Scegliere il codice da distribuire dall'origine come caricamento ZIP anziché compilare un'immagine del contenitore. La distribuzione del codice è la modalità predefinita per Python e .NET agenti ospitati. Foundry Toolkit per VS Code richiede il metodo di distribuzione nello stesso modo.
Per selezionare la distribuzione del codice sorgente in modo non interattivo, ad esempio in una pipeline CI/CD, passare --deploy-mode code. Questa modalità richiede --runtime e --entry-pointe accetta un valore facoltativo --dep-resolution di remote_build (impostazione predefinita) o bundled:
azd ai agent init --no-prompt --project-id "<project-resource-id>" \
--deploy-mode code --runtime python_3_13 --entry-point main.py
Dopo l'inizializzazione, azd scrive le impostazioni di distribuzione del codice sorgente nel codeConfiguration campo del azure.ai.agent servizio in azure.yaml:
services:
my-agent:
host: azure.ai.agent
project: src/my-agent
kind: hosted
codeConfiguration:
runtime: python_3_13
entryPoint:
- python
- main.py
dependencyResolution: remote_build
Eseguire azd up per effettuare il provisioning e la distribuzione. Usa --deploy-mode container solo quando vuoi creare o fare riferimento a un'immagine container.
Usare l'SDK o i percorsi REST nelle sezioni seguenti quando è necessario distribuire a livello di codice dalla propria applicazione o integrarsi con gli strumenti esistenti.
Distribuire dal codice sorgente
Selezionare la lingua o l'interfaccia. Ogni scheda illustra lo stesso ciclo di vita: creare l'agente, eseguire il polling fino a raggiungere active, richiamarlo e scaricare il codice distribuito.
Utilizza l'SDK Python per distribuire agenti basati su codice sorgente dalle tue applicazioni o automazioni. Si compila il file ZIP manualmente e si passano i byte e SHA-256 all'SDK, che lo carica ed espone le stesse operazioni di creazione, polling, richiamo e download dell'API REST. La distribuzione del codice richiede azure-ai-projects la versione 2.2.0 o successiva.
La distribuzione del codice sorgente usa l'interfaccia client in anteprima beta, quindi crea il client con allow_preview=True.
Compilare il file ZIP
L'SDK di Python carica un file ZIP compilato. Usare le stesse regole di layout e risoluzione delle dipendenze descritte in Creare manualmente il pacchetto zip. Il payload minimo remote_build è un file ZIP piatto con main.py e requirements.txt nella radice.
Creare l'agente
import hashlib
from pathlib import Path
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import (
CodeConfiguration,
CreateAgentVersionFromCodeContent,
CreateAgentVersionFromCodeMetadata,
HostedAgentDefinition,
ProtocolVersionRecord,
)
from azure.identity import DefaultAzureCredential
# Format: "https://<account>.services.ai.azure.com/api/projects/<project>"
PROJECT_ENDPOINT = "your_project_endpoint"
AGENT_NAME = "my-code-agent"
ZIP_PATH = Path("agent-code.zip")
code_zip_bytes = ZIP_PATH.read_bytes()
code_zip_sha256 = hashlib.sha256(code_zip_bytes).hexdigest()
credential = DefaultAzureCredential()
project = AIProjectClient(
endpoint=PROJECT_ENDPOINT,
credential=credential,
allow_preview=True,
)
content = CreateAgentVersionFromCodeContent(
metadata=CreateAgentVersionFromCodeMetadata(
description="Hello-world code agent",
definition=HostedAgentDefinition(
cpu="1",
memory="2Gi",
code_configuration=CodeConfiguration(
runtime="python_3_13",
entry_point=["python", "main.py"],
dependency_resolution="remote_build",
),
protocol_versions=[
ProtocolVersionRecord(protocol="responses", version="1.0.0")
],
environment_variables={"AZURE_AI_MODEL_DEPLOYMENT_NAME": "gpt-5.4-mini"},
),
),
code=(ZIP_PATH.name, code_zip_bytes, "application/zip"),
)
created = project.beta.agents.create_version_from_code(
agent_name=AGENT_NAME,
content=content,
code_zip_sha256=code_zip_sha256,
)
print(f"Created version: {created.version}")
Per il protocollo Invocations, impostare la voce protocol_versions su ProtocolVersionRecord(protocol="invocations", version="1.0.0"). Per il protocollo Invocazioni (WebSocket), usa ProtocolVersionRecord(protocol="invocations_ws", version="1.0.0"). Per la modalità bundled, impostare dependency_resolution="bundled" e includere nel file ZIP le dipendenze precompilate. Per altre informazioni, vedere Creare dipendenze Linux in locale.
Eseguire il polling per l'attività attiva
I metodi di distribuzione del codice (create_version_from_code e download_code) si trovano nell'area di anteprima project.beta.agents , ma le operazioni di lettura ed eliminazione, get_version ad esempio sono in project.agents.
import time
while True:
version = project.agents.get_version(
agent_name=AGENT_NAME, agent_version=created.version
)
status = version["status"]
print(f"Status: {status}")
if status == "active":
break
if status == "failed":
raise RuntimeError(f"Provisioning failed: {version.get('error')}")
time.sleep(5)
Per l'elenco completo dei valori di stato e per sapere come leggere l'oggetto in caso di errore, vedere error.
Invocare l'agente
Dopo che la versione raggiunge active, associare un client OpenAI all'endpoint dell'agente e chiamarlo. Questo esempio usa il protocollo Responses:
openai_client = project.get_openai_client(agent_name=AGENT_NAME)
response = openai_client.responses.create(input="Hello! What can you do?")
print(response.output_text)
Per il protocollo Invocations, chiamare direttamente l'endpoint invoke con un token bearer, come mostrato in Invocare l'agente.
Scaricare il file ZIP distribuito
Verificare esattamente ciò che viene distribuito scaricando il file ZIP e confrontando sha-256 con il valore caricato:
import hashlib
from pathlib import Path
out_path = Path(f"{AGENT_NAME}-{created.version}.zip")
sha = hashlib.sha256()
with open(out_path, "wb") as f:
for chunk in project.beta.agents.download_code(
agent_name=AGENT_NAME, agent_version=created.version
):
f.write(chunk)
sha.update(chunk)
print(f"Downloaded {out_path} (matches upload: {sha.hexdigest() == code_zip_sha256})")
Per un esempio eseguibile completo, vedere gli esempi Python hosted-agent.
Creare manualmente il pacchetto zip
Se si usa azd, ignorare questa sezione,azd compila automaticamente il file ZIP. Leggilo se usi l'API REST, se passi alla risoluzione delle dipendenze raggruppata o se ti serve il pieno controllo sui contenuti caricati.
Il file ZIP deve essere piatto nella radice, ovvero nessuna cartella wrapper di primo livello.
Selezionare la scheda relativa alla lingua dell'agente.
layout Python (modalità di compilazione remota)
Il servizio installa le dipendenze nel cloud da requirements.txt.
agent-code.zip
+-- main.py
+-- requirements.txt
layout di Python (modalità integrata)
Le dipendenze predefinite di Linux vengono fornite in packages/.
agent-code.zip
+-- main.py # entry point
+-- requirements.txt
+-- packages/ # extracted modules (not raw .whl files)
+-- azure/identity/__init__.py
+-- requests/__init__.py
Compilare le dipendenze di Linux in locale (incluso, Python)
Usare il tag della piattaforma manylinux2014_x86_64 in modo che pip scarica le ruote Linux anche da Windows o macOS.
Bash
pip install -r requirements.txt \
--target packages/ \
--platform manylinux2014_x86_64 \
--python-version 3.13 \
--implementation cp \
--only-binary=:all:
zip -r agent-code.zip main.py requirements.txt packages/
PowerShell/Windows cmd
pip install -r requirements.txt --target packages --platform manylinux2014_x86_64 --python-version 3.13 --implementation cp --only-binary=:all:
tar -a -c -f agent-code.zip main.py requirements.txt packages
--only-binary=:all: forza le ruote (nessuna creazione dell'origine). Il --python-version deve corrispondere al valore di runtime nella definizione dell'agente.
Avvertimento
Errori comuni di pacchettizzazione che causano session_creation_failed o ModuleNotFoundError:
- Racchiudere la sorgente in una cartella (
my-agent/main.pyanzichémain.pyalla radice). - Inclusi file grezzi
.whlinpackages/anziché i moduli estratti. - Raggruppamento di binari di Windows (
.pyd,.dll) per un runtime Linux.
Limits
| Limit | Value |
|---|---|
| Dimensione massima del file ZIP (caricamento multiparte) | 250 MB |
Per le combinazioni supportate di cpu e memory, vedere Dimensioni della sandbox.
Troubleshooting
| Sintomo | Causa possibile | Correzione |
|---|---|---|
401 Unauthorized |
Token mancante o con ambito errato | Acquisire un token con --resource https://ai.azure.com. |
403 Forbidden |
Il chiamante non dispone del controllo degli accessi basato sui ruoli per il progetto | Concedere Agente consumer Foundry (solo per l'invocazione) o Utente Foundry (anche per lo sviluppo) a livello di progetto. |
409 conflict su Crea (Agent '<name>' already exists) |
Il nome dell'agente esiste già | Usare Update (POST /agents/{name}) o selezionare un nuovo nome. |
400 bad_request (CPU and Memory must be specified as a valid resource tier) in Creazione o aggiornamento |
cpu
/
memory non sono uno dei livelli supportati |
Impostare cpu e memory su una coppia valida tra le dimensioni della sandbox. |
400 bad_request (Agent version is still being provisioned) all'invocazione |
Una nuova versione è in fase di distribuzione e la versione attiva sta per essere sostituita | Verificare ripetutamente la versione status fino a active, quindi riprovare. |
424 session_not_ready all'invocazione |
Container avviato, ma /readiness non ha restituito HTTP 200 entro il timeout |
Trasmettere i log con :logstream, correggere il probe di idoneità o l'errore di avvio, ridistribuire. |
409 conflict nell'agente DELETE (Agent has active sessions) |
Le sessioni aperte bloccano l'eliminazione | Attendere che le sessioni diventino inattive oppure aggiungere &force=true per eliminare le sessioni a catena. |
Versione bloccata in creating (>10 minuti, build remota) |
La compilazione del server non è riuscita o non è stata risolta requirements.txt |
Passare a dependency_resolution: bundled e precompilare localmente. |
| La distribuzione non riesce in una rete virtuale privata | Gli endpoint in uscita necessari sono bloccati dal firewall | Consenti gli endpoint indicati in requisiti del firewall per le reti virtuali private, quindi ridistribuisci. |
Transizioni di versione a failed |
Layout zip non valido, errore di sintassi o (remote_build) errore di ripristino/compilazione |
Leggere prima l'oggetto error della versione: error.code classifica l'errore e error.message contiene la riga di errore di ripristino o compilazione sottostante (pip per Python, NuGet per .NET) e un collegamento per la risoluzione dei problemi. Verificare la struttura di cartelle. Usare :logstream solo dopo l'avvio del contenitore. |
ModuleNotFoundError in fase di esecuzione |
packages/ mancante, contiene file .whl non elaborati o contiene file binari Windows |
Ricostruisci con pip install --target packages/ --platform manylinux2014_x86_64 --only-binary=:all:. |
409 AgentNotCodeBased al momento del download |
Agent è basato su immagini | Usare la documentazione sulla distribuzione basata su contenitori. |
Pulire le risorse
Se è stata creata la struttura del progetto da Avvio rapido con azd, eseguire azd down dalla radice del progetto per rimuovere l'intero ambiente di cui è stato eseguito il provisioning.
Per eliminare un agente distribuito con l'SDK o l'API REST, usare il percorso corrispondente riportato di seguito.
# Delete one version
project.agents.delete_version(agent_name=AGENT_NAME, agent_version=created.version)
# Delete the agent and all its versions
project.agents.delete(agent_name=AGENT_NAME)
Avvertimento
L'eliminazione di un agente rimuove tutte le relative versioni e termina le sessioni attive. Non è possibile annullare questa azione.
Passaggi successivi
- Informazioni di riferimento sulle autorizzazioni dell'agente ospitato
- Distribuire un agente ospitato in una rete virtuale