Wat zijn gehoste agents?

Wanneer u agentische toepassingen bouwt met behulp van opensource-frameworks, beheert u doorgaans veel geavanceerde problemen: containerisatie, webserverinstallatie, beveiliging, geheugenpersistentie, schalen, instrumentatie en terugdraaiacties van versies. Deze taken worden nog lastiger in heterogene cloudomgevingen.

Gehoste agents in Foundry Agent Service lossen deze uitdagingen op voor Microsoft Foundry-gebruikers. Gehoste agents roepen modellen aan uit de Foundry-modelcatalogus om redenering uit te voeren terwijl uw aangepaste code indeling verwerkt. Met dit beheerde platform kunt u AI-agents veilig en op schaal implementeren en gebruiken. U kunt uw aangepaste agentcode of een voorkeursagentframework gebruiken met gestroomlijnde implementatie en beheer.

Wanneer moet u gehoste agents gebruiken

Kies gehoste agents boven agents op basis van prompts wanneer u het volgende moet doen:

• Bring your own code - gebruik elk framework (Agent Framework, LangGraph, Semantic Kernel of aangepaste code) in plaats van alleen prompt-definities.
• Gebruik aangepaste protocollen - accepteer webhooks of niet-OpenAI-payloads via het Invocations-protocol.
• Rekenresources beheren: geef CPU en geheugen op voor de sandbox van uw agent.
• Stateful workloads uitvoeren : bestanden en status behouden via $HOME en het eindpunt /files.

Hoe het werkt

Je verpakt je agent als een container-image en uploadt deze naar Azure Container Registry. Wanneer u implementeert, haalt Agent Service de installatiekopie op, stelt de rekencapaciteit in, wijst een toegewezen Microsoft Entra ID (agentidentiteit) toe, en stelt een toegewezen eindpunt beschikbaar. Tijdens runtime verwerkt uw agentcode aanvragen van clients en kunnen Foundry-modellen, Werksethulpprogramma's en downstream-Azure-services aanroepen met behulp van de agentidentiteit. Het platform verwerkt schalen, sessiestatuspersistentie, waarneembaarheid en levenscyclusbeheer.

Sleutelbegrippen

Gehoste agents

Gehoste agents zijn in containers geplaatste AI-toepassingen die worden uitgevoerd op agentservice. In tegenstelling tot promptgebaseerde agents, die volledig worden gedefinieerd via prompts en toolconfiguratie in de Foundry-portal, zijn gehoste agents uw eigen code, verpakt als een containerafbeelding. U kiest het framework, beheert het runtimegedrag en implementeert de image in door Microsoft beheerde infrastructuur.

Het platform beheert automatisch de levenscyclus van de container op basis van activiteit, door resources in te richten wanneer u een versie maakt en deze vrij te geven wanneer de inactiviteitstime-out is bereikt.

Isolatiemodel

Gehoste agents worden per sessie uitgevoerd in VM-geïsoleerde sandboxes. Elke sessie krijgt een toegewezen sandbox met een permanent bestandssysteem ($HOME en /files), waardoor scale-to-zero wordt ingeschakeld, met stateful hervatten en voorspelbare koude starts. Sessies worden van elkaar geïsoleerd en de status wordt automatisch hersteld wanneer een sessie wordt hervat na inactiviteit.

Protocollen: Antwoorden en aanroepen

Gehoste agentcontainers maken een of beide protocollen beschikbaar. Elk protocol wordt geleverd door een lichtgewicht bibliotheek die de HTTP-server, statuscontroles en OpenTelemetry-integratie afhandelt.

Welk protocol moet ik gebruiken?

Protocolvergelijking

Aanvullende protocollen

Gehoste agents ondersteunen ook het Activiteitenprotocol voor integratie van Teams- en M365-kanalen (meestal gebruikt naast antwoorden) en het A2A-protocol voor agent-naar-agentdelegering. Alle vier protocollen, antwoorden, aanroepen, activiteiten en A2A, kunnen worden gecombineerd in één agent.

Agentidentiteit en eindpunt

Elke gehoste agent die is geïmplementeerd in een Foundry-project krijgt een eigen dedicated Microsoft Entra ID (agentidentiteit) en dediceerd eindpunt, beide automatisch gemaakt tijdens de implementatie. U hoeft beheerde identiteiten of routering niet handmatig te configureren.

Het eindpunt is direct na de implementatie beschikbaar. Publicatie is niet vereist voor programmatische toegang:

• Antwoorden: {project_endpoint}/agents/{name}/endpoint/protocols/openai/v1/responses
• Aanroepen: {project_endpoint}/agents/{name}/endpoint/protocols/invocations

Welke eindpunten actief zijn, is afhankelijk van de protocollen die zijn gedeclareerd in de definitie van de agentversie (ingesteld in agent.yaml wanneer u azd gebruikt of via container_protocol_versions wanneer u de SDK gebruikt).

Er zijn twee identiteiten betrokken:

Wanneer u implementeert met azd, wordt de vereiste RBAC-rol (Azure AI-gebruiker op accountbereik) automatisch toegewezen aan de Microsoft Entra ID van de agent. Voor externe resources (bijvoorbeeld uw eigen Azure Storage) wijst u RBAC handmatig toe aan de Microsoft Entra ID van de agent.

Wanneer deze is geïntegreerd via Microsoft 365-kanalen (bijvoorbeeld Teams), kunnen gehoste agents ook werken met een OBO-gebruikersidentiteit (on-behalf-of). De Microsoft Entra ID van de agent kan een gebruikerstoken uitwisselen om downstreamservices aan te roepen als gebruiker, afhankelijk van tenantbeleid. Zie Agent-toepassingen en agentidentiteitsconcepten voor meer informatie.

Sessies en gesprekken

Gehoste agents gebruiken sessies en gesprekken om de status te beheren. Hoe ze werken, is afhankelijk van het protocol.

Sessies

Een sessie-id identificeert een logische sessie met persistente status, inclusief $HOME en bestanden die zijn geüpload via het eindpunt /files. Het platform voorziet in computercapaciteit op aanvraag en herstelt de opgeslagen status daarop.

• Statuspersistentie: $HOME- en /files-inhoud blijven behouden over omdraaiingen en over niet-actieve perioden. Wanneer de berekening niet actief wordt en terug wordt gebracht (op een nieuwe of bestaande infrastructuur), wordt de status van de sessie automatisch hersteld.
• Isolatie: elke sessie is geïsoleerd van andere sessies.
• Automatische levenscyclus: sessies worden gemaakt bij eerste gebruik. De inrichting van het platform wordt automatisch uitgevoerd en de inrichting ongedaan gemaakt.
• Levensduur van de sessie: sessies blijven tot 30 dagen bestaan. De time-out voor inactiviteit is 15 minuten. Als er binnen dat venster geen verzoek binnenkomt, worden de compute-resources vrijgegeven en wordt de sessiestatus behouden.
• Api's voor sessiebeheer: sessies weergeven, sessies beëindigen en bestanden per sessie uploaden of downloaden.

Gesprekken

Een gespreks-id is een duurzaam overzicht van gespreksgeschiedenis (berichten, hulpprogramma-oproepen en antwoorden) die zijn opgeslagen in Foundry.

• Persistentie: gespreksgeschiedenis wordt opgeslagen in Foundry en blijft onafhankelijk van de rekenstatus behouden.
• Toegang via meerdere kanalen: gebruikers hebben toegang tot hetzelfde gesprek vanuit de speeltuin, API, Teams of andere gepubliceerde kanalen.

Hoe sessies en gesprekken werken met elk protocol

Protocol voor antwoorden: gespreks-id is het primaire concept. Het platform beheert de gespreksgeschiedenis automatisch en koppelt een sessie-id aan elk gesprek. Het platform retourneert de sessie-id naar de client, die deze kan gebruiken om bestanden te uploaden via het /files-eindpunt, waardoor deze bestanden beschikbaar zijn voor de berekening van het gesprek.

Protocol voor aanroepen: sessie-id is het primaire concept. De client beheert de sessie-id rechtstreeks om de status tussen interacties te behouden. De client kan inhoud uploaden via het eindpunt /files met behulp van de sessie-id om deze beschikbaar te maken voor de sessie. Er is geen platformbeheerde gespreksgeschiedenis: u beheert de status in uw eigen code.

Levenscyclus van sessie berekenen

Beveiliging en gegevensverwerking

Behandel een gehoste agent zoals productieapplicatiecode.

• Plaats geen geheimen in containerinstallatiekopieën of omgevingsvariabelen. Gebruik beheerde identiteiten en verbindingen en sla geheimen op in een beheerd geheim archief. Zie Een Key Vault-verbinding instellen voor hulp.
• Wees voorzichtig met niet-Microsoft hulpprogramma's en servers. Als uw agent hulpprogramma's aanroept die worden ondersteund door niet-Microsoft-services, kunnen sommige gegevens naar die services stromen. Controleer het beleid voor het delen, bewaren en locatie van gegevens voor alle niet-Microsoft service waarmee u verbinding maakt.

Platformdetails

Versiebeheer

Elke aanroep voor het maken van een versie produceert een onveranderbare agentversie: een momentopname van de containerinstallatiekopie, resourcetoewijzing, omgevingsvariabelen en protocolconfiguratie. Implementaties verwijzen naar een specifieke versie. Als u uw agent wilt bijwerken, maakt u een nieuwe versie en implementeert het platform deze. Houd er rekening mee dat aanvragen voor het maken van agentversies zonder wijzigingen in de agentversieparameters, zoals containerinstallatiekopieën, omgevingsvariabelen, enzovoort, ertoe leiden dat er geen nieuwe versie wordt gemaakt. U kunt verkeer splitsen tussen versies met gewogen uitrol ter ondersteuning van kanarie- en blauwgroene implementaties.

Omgevingsvariabelen zijn het primaire mechanisme voor het doorgeven van configuratie aan uw container tijdens runtime (bijvoorbeeld het projecteindpunt, de naam van de modelimplementatie en aangepaste instellingen). Ze worden ingesteld per versie en kunnen onveranderbaar zijn zodra de versie is gemaakt.

Werkset in Foundry

Gehoste agents hebben toegang tot met Foundry beheerde hulpprogramma's (Code Interpreter, Web Search, Azure AI Zoeken, OpenAPI, aangepaste MCP-verbindingen, A2A) via een Toolbox MCP-eindpunt ingericht in uw Foundry-project. Uw agentcode maakt verbinding met dit eindpunt met behulp van standaard MCP-clientbibliotheken. Het platform injecteert geen hulpprogramma's automatisch. Voor details, zie de op intentie gebaseerde gereedschapskist in Foundry cureren. We raden klanten aan de toolbox in Foundry te gebruiken voor het verbinden van hulpprogramma's in een gehoste agent met geconsolideerde verificatieondersteuning voor OAuth Identity Passthrough, agentidentiteit, sleutelgebaseerd en meer.

Taalondersteuning

Gehoste agents ondersteunen Python en C#. U kunt elk agentframework gebruiken. De protocolbibliotheken zijn frameworkneutraal. Zie de opslagplaats foundry-samples-opslagplaats voor voorbeelden die gebruikmaken van Microsoft Agent Framework, LangGraph en aangepaste code.

Sandbox-grootten

Gehoste agent-sandboxes ondersteunen CPU- en geheugentoewijzingen, variërend van 0.25 vCPU/0,5 GiB tot 2 vCPU/4 GiB.

Privénetwerken

Gehoste agents ondersteunen implementatie binnen netwerk-geïsoleerde Foundry-resources. Zie Virtuele netwerken configureren voor meer informatie. Houd er rekening mee dat het Azure Container Registry met uw agentafbeelding momenteel bereikbaar moet blijven via het openbare eindpunt. Een via een privénetwerk beveiligde ACR wordt momenteel niet ondersteund.

Limieten, prijzen en beschikbaarheid (preview)

Gehoste agents zijn momenteel in preview.

Beperkingen tijdens preview

Prijzen

Facturering van beheerde hostingruntime is gebaseerd op het verbruik van CPU- en geheugenbronnen tijdens actieve sessies. Zie de pagina Met prijzen van Foundry voor actuele tarieven.

Beschikbaarheid van regio's

Gehoste agents zijn momenteel beschikbaar in de volgende regio's:

• East US 2
• VS - noord-centraal
• Zweden - centraal
• Canada - centraal
• Azië - zuidoost
• Polen - centraal
• Zuid-Afrika - noord
• Centraal Korea
• Zuid-India
• Brazilië - zuid
• West VS
• West US 3
• Noorwegen - oost
• Japan Oost
• Frankrijk - centraal
• Zwitserland - noord
• Spanje - centraal
• Australië - oost

Volgende stappen

Verwante inhoud

• Runtime-onderdelen van de agent
• Levenscyclus van agentontwikkeling
• Agent-identiteitsconcepten in Microsoft Foundry
• Hulpprogramma's ontdekken in Foundry Tools
• Azure Container Registry documentatie