Vad är värdbaserade agenter?

När du skapar agentiska program med ramverk med öppen källkod hanterar du vanligtvis många övergripande problem: containerisering, konfiguration av webbserver, säkerhet, minnesbeständighet, skalning, instrumentering och återställning av versioner. Dessa uppgifter blir ännu mer utmanande i heterogena molnmiljöer.

Värdbaserade agenter i Foundry Agent Service löser dessa utmaningar för Microsoft Foundry-användare. Värdbaserade agenter anropar modeller från Foundry-modellkatalogen för att utföra resonemang medan din anpassade kod hanterar orkestrering. Genom att använda den här hanterade plattformen kan du distribuera och använda AI-agenter på ett säkert och i stor skala. Du kan använda din anpassade agentkod eller ett prioriterat agentramverk med effektiv distribution och hantering.

Om du utforskar värdbaserade agenter med en AI-kodningsagent kan Microsoft Foundry Skill hjälpa dig att ansluta dessa begrepp till implementerings-, distributions- och driftuppgifter.

När värdbaserade agenter ska användas

Välj hostade agenter framför promptbaserade agenter när du behöver:

Bringa din egen kod – använd alla ramverk (Agent Framework, LangGraph, Semantic Kernel eller anpassad kod) i stället för definitioner med endast fråga.
Använd anpassade protokoll – acceptera webhooks eller icke-OpenAI-nyttolaster via anropsprotokollet.
Kontrollera beräkningsresurser – ange PROCESSOR och minne för agentens sandbox-miljö.
Kör tillståndskänsliga arbetsbelastningar – bevara filer och tillstånd mellan svängar via $HOME och /files-slutpunkten.
Kör långvariga arbetsflöden robust – bevara agenters pågående arbete vid processavbrott och spela upp strömmade resultat på nytt för klienter som återansluter.

Så här fungerar det

Du paketerar din agent som en containerbild och pushar upp den till Azure Container Registry. När du distribuerar hämtar Agent Service avbildningen, tilldelar en dedikerad Microsoft Entra ID (agentidentitet) och exponerar en dedikerad slutpunkt för agenten.

Vid körningstillfället tillhandahåller Agent Service beräkningsresurser för sessionen och dirigerar förfrågningar till din container. Din agentkod hanterar dessa begäranden och kan anropa Foundry-modeller, verktygslådan och underordnade Azure tjänster med hjälp av dess agentidentitet. Plattformen hanterar skalning, sessionstillståndspersistens, observerbarhet och livscykelhantering.

Följande diagram visar hur ansvaret delas upp. Du äger koden som körs i sandbox-miljön. Plattformen äger slutpunkten, identiteten, skalningen och sessionstillståndet runt den.

Viktigt

När du använder värdbaserade agenter med andra Microsoft produkter och tjänster måste du läsa all relevant dokumentation för sådana produkter och tjänster och förstå relaterade risker och efterlevnadsöverväganden.

Om du använder Hosted Agent med tredjepartsservrar, tredjepartsagenter, tredjepartskod eller modeller som inte är Azure Direct-modeller ("tredjepartssystem"), gör du det på egen risk. Tredjepartssystem är icke-Microsoft produkter enligt Microsoft produktvillkor och styrs av sina egna licensvillkor från tredje part. Du ansvarar för all användning och tillhörande kostnader.

Vi rekommenderar att du granskar alla data som delas med och tas emot från tredjepartssystem och är medvetna om metoder från tredje part för hantering, delning, kvarhållning och plats för data. På samma sätt är det viktigt att granska datarutinerna för Microsoft-tjänster och -funktioner utanför Foundry om du ansluter till eller integrerar med dem. Det är ditt ansvar att hantera om dina data kommer att flöda utanför organisationens efterlevnad och geografiska gränser och eventuella relaterade konsekvenser, och att lämpliga behörigheter, gränser och godkännanden etableras.

Du ansvarar för att noggrant granska och testa program som du skapar i samband med dina specifika användningsfall och fatta alla lämpliga beslut och anpassningar. Detta omfattar implementering av dina egna ansvarsfulla AI-åtgärder, till exempel metaprompter, innehållsfilter eller andra säkerhetssystem, och att se till att dina program uppfyller lämpliga kvalitets-, tillförlitlighets-, säkerhets- och tillförlitlighetsstandarder. Se transparensmeddelandet för Foundry Agent Service.

Viktiga begrepp

Värdbaserade agenter

Värdbaserade agenter är containeriserade AI-applikationer som körs på Agent Service. Till skillnad från promptbaserade agenter – som definieras helt och hållet via prompter och verktygskonfiguration i Foundry-portalen – är värdbaserade agenter din egen kod som paketeras som en containeravbildning. Du väljer ramverket, styr körningsbeteendet och distribuerar avbildningen till Microsoft-hanterad infrastruktur.

Plattformen hanterar automatiskt containerns livscykel baserat på aktivitet, etablerar resurser när du skapar en version och avetablerar när tidsgränsen för inaktivitet nås.

Isoleringsmodell

Värdbaserade agenter körs i session-isolerade sandboxar på virtuella maskiner. Varje session får en dedikerad sandbox-miljö med ett beständigt filsystem ($HOME och /files), vilket möjliggör skalning till noll aktivitet med tillståndsbevarande återupptagning och förutsägbara kalla starter. Sessioner isoleras från varandra och tillståndet återställs automatiskt när en session återupptas efter inaktivitet.

Protokoll: Svar, anrop och anrop (WebSocket)

Hostade agentcontainrar kan exponera ett eller flera protokoll. Varje protokoll tillhandahålls av ett lättviktsbibliotek som hanterar HTTP- eller WebSocket-servern, hälsokontroller och OpenTelemetry-integrering. Protokollen Svar, anrop och anrop (WebSocket) är tillgängliga i alla regioner som stöder värdbaserade agenter.

Vilket protokoll ska jag använda?

Scenario	Protokollet	Varför
Konversationschattrobot eller assistent	Svaren	Plattformen hanterar konversationshistorik, strömmande händelser och sessionslivscykel – använd alla OpenAI-kompatibla SDK:er som klient.
Q&A i flera omgångar med RAG eller verktyg	Svaren	Inbyggd trådning av konversations-ID och hantering av verktygsresultat.
Bakgrundsbearbetning och asynkron bearbetning	Svaren	`background: true` med plattformshanterad pollning och avbrytning. Välj detta separat när hanteraren måste kunna återhämta sig efter ett processavbrott.
Agent publicerad i Teams eller Microsoft 365	Svaren + Aktivitet	Protokollet Responses ger kraft till agentlogik; plattformen kopplar automatiskt Responses till Aktivitetsprotokollet för leverans till kanaler.
Webhook-mottagare (GitHub, Stripe, Jira osv.)	Anrop	Det externa systemet skickar ett eget nyttolastformat – du kan inte ändra det så att det matchar /responses.
Icke-konversationsbearbetning (klassificering, extrahering, batch)	Anrop	Indata är strukturerade data, inte ett chattmeddelande. Godtycklig JSON in, godtycklig JSON ut.
Anpassat direktuppspelningsprotokoll (AG-UI osv.)	Anrop	AG-UI och andra agent-UI-protokoll är inte OpenAI-kompatibla – du behöver rå SSE-kontroll.
Protokollbrygga (GitHub Copilot, patentskyddade system)	Anrop	Anroparen har ett eget protokoll som inte mappas till /responses.
Röstagent i realtid (mikrofon in, tal ut)	Anrop (WebSocket)	Dubbelriktad direktuppspelning över en enda beständig anslutning. Anslut till Pipecat, LiveKit eller Voice Live i din container. Se Skapa en röstagent.

Tips

Inte säker? Börja med Svar. Du kan alltid lägga till en slutpunkt för anrop senare – en värdbaserad agent kan stödja båda protokollen samtidigt.

Det protokoll du väljer avgör vilken nyttolast containern tar emot och hur mycket av sessionen, strömningen och bakgrundslivscykeln som plattformen hanterar åt dig. En enskild agent kan ha stöd för mer än ett protokoll, så det här valet är inte permanent. Använd följande beslutsträd för att välja en startpunkt.

Protokolljämförelse

	Svaren	Anrop
Bäst för	De flesta agenter – plattformen hanterar konversationshistorik, strömningslivscykel och bakgrundskörning	Agenter som behöver fullständig HTTP-kontroll, anpassade nyttolaster eller långvariga asynkrona arbetsflöden
Nyttolast	OpenAI-kompatibla svarskontrakt	Godtycklig JSON via /invocations – du definierar schemat
Klient-SDK	Alla OpenAI-kompatibla SDK:er (Python, JS, C#) fungerar direkt	Anpassad klient – du definierar kontraktet
Sessionshistorik	Hanteras av plattform via konversations-ID	Du hanterar sessioner (minnesinternt, Cosmos DB osv.)
Streaming	Plattformshanterat ResponseEventStream med livscykelhändelser	Raw SSE – du formaterar och skriver händelser direkt
Bakgrund/tidskrävande	Inbyggt bakgrundsläge och avsökning; valfri elastisk återställning för lagrade bakgrundssvar	Elastiska uppgifter i AgentServer SDK; du definierar slutpunkter för avsökning eller direktuppspelning

Bakgrundsläge och elastisk körning löser olika problem. Med bakgrundsläget kan arbetet fortsätta när den inledande begäran returneras. Elastisk körning bevarar arbete när värdprocessen stoppas. Information om återställningsmodellen och programansvaret finns i Motståndskraft för långvariga värdbaserade agenter.

Tilläggsprotokoll

Värdbaserade agenter stöder också protokollet Activity för Teams och Microsoft 365 kanalintegrering. När du använder protokollet Svar för agentlogik och publicerar till Microsoft 365-kanaler som Teams, omvandlar plattformen automatiskt Svar till aktivitetsprotokollet för kanalleverans – inget separat arbete krävs. A2A-protokollet stöder agent-till-agent-delegering. Protokoll som stöds kan kombineras i en enda agent.

Agentidentitet och slutpunkt

Varje värdbaserad agent som distribueras till ett Foundry-projekt får en egen dedicerad Microsoft Entra ID (agentidentitet) och dedicerad slutpunkt – båda skapade automatiskt vid distributionen. Du behöver inte konfigurera hanterade identiteter eller routning manuellt.

Slutpunkten är tillgänglig direkt efter distributionen – publicering krävs inte för programmatisk åtkomst:

Svar: {project_endpoint}/agents/{name}/endpoint/protocols/openai/responses
Anropningar: {project_endpoint}/agents/{name}/endpoint/protocols/invocations
Anrop (WebSocket): wss://{account}.services.ai.azure.com/api/projects/{project}/agents/{name}/endpoint/protocols/invocations_ws?api-version=v1
A2A (förhandsversion): {project_endpoint}/agents/{name}/endpoint/protocols/a2a

Vilka slutpunkter som är aktiva beror på de protokoll som deklareras i agentversionsdefinitionen. Ange denna definition i tjänsten i azure.ai.agent när du använder azure.yaml, eller via azd när du använder SDK:n.

Två identiteter är inblandade:

Identitet	Omfattning	Syfte
Microsoft Entra ID (agentidentitet, per-agent)	Skapas automatiskt vid distributionstillfället	Identiteten som agentcontainern autentiserar med vid körning. Används för modellanrop, verktygsåtkomst och underordnade Azure tjänster.
Projekt-hanterad identitet (projektomfattande)	Systemtilldelad i Foundry-projektet	Används av plattformen för infrastrukturåtgärder (till exempel Container Registry Repository Reader i containerregistret). Inte agentens körningsidentitet.

Agentidentiteten kan komma åt modellinferenser via projektets slutpunkt och sessionslagring som standard. För externa resurser (till exempel din egen Azure Storage) tilldelar du RBAC-roller manuellt till agentens Microsoft Entra ID. Mer information finns i Agentåtkomst utöver standardvärden.

När de är integrerade via Microsoft 365 kanaler (till exempel Teams) kan värdbaserade agenter arbeta i två identitetslägen beroende på hur de anropas:

Användaranropade scenarier (interaktiva): Om en användartoken finns stöder plattformen OAuth 2.0 On-Behalf-Of-flöden (OBO). I det här fallet kan agenten anropa underordnade tjänster för användarens räkning med hjälp av användarens delegerade behörigheter, med förbehåll för Microsoft Entra ID klientprinciper.
Autonoma eller bakgrundsscenarier: Om ingen användartoken finns tillgänglig autentiserar agenten sig med sitt eget Microsoft Entra-ID (agentidentitet), vanligtvis via hanterad identitet, för att komma åt efterföljande tjänster.

I båda fallen behåller agenten sina dedikerade Microsoft Entra ID för autentisering, auktorisering och granskning. Mer information finns i Agentprogram och Agentidentitetsbegrepp.

Sessioner och konversationer

Värdbaserade agenter använder sessioner och konversationer för att hantera tillstånd. Hur de fungerar beror på protokollet.

Sessioner

Ett sessions-ID identifierar en logisk session med beständiga tillstånd, inklusive $HOME och filer som laddas upp via slutpunkten /files. Plattformen tillhandahåller datorkapacitet vid behov och återställer lagrat tillstånd till den.

Tillståndsbeständighet: $HOME- och /files-innehåll sparas mellan svängar och över inaktiva perioder. När beräkningen går inaktiv och tas tillbaka (i ny eller befintlig infrastruktur) återställs sessionens tillstånd automatiskt.
Isolering: Varje session är isolerad från andra sessioner.
Automatisk livscykel: Sessioner skapas vid första användningen. Plattformen provisionerar och deprovisionerar resurser automatiskt.
Sessionslivslängd: Du kan konfigurera tidsgränsen för inaktivitet per agentversion från 5 till 60 minuter, med standardvärdet 15 minuter. Om ingen begäran tas emot inom det fönstret avetablerar plattformen beräkningen och bevarar sessionstillståndet. Plattformen tar bort en session permanent efter 30 dagars inaktivitet.
API:er för sessionshantering: Lista sessioner, avsluta sessioner och ladda upp eller ladda ned filer per session.

Samtal

Ett konversations-ID är en varaktig post med konversationshistorik (meddelanden, verktygsanrop och svar) som lagras i Foundry.

Beständighet: Konversationshistorik lagras i Foundry och bevaras oberoende av beräkningstillstånd.
Åtkomst mellan kanaler: Användare kan komma åt samma konversation från lekplatsen, API:et, Teams eller andra publicerade kanaler.

Hur sessioner och konversationer fungerar med varje protokoll

Svarsprotokoll: konversations-ID är det primära konceptet. Plattformen hanterar konversationshistorik automatiskt och associerar ett sessions-ID med varje konversation. Plattformen returnerar sessions-ID:t till klienten, som kan använda det för att ladda upp filer via slutpunkten /files, vilket gör dessa filer tillgängliga för konversationens beräkning.

Anropsprotokoll: sessions-ID är det primära konceptet. Klienten hanterar sessions-ID:t direkt för att upprätthålla tillståndet mellan interaktioner. Klienten kan ladda upp innehåll via slutpunkten /files med hjälp av sessions-ID:t för att göra det tillgängligt för sessionen. Det finns ingen plattformshanterad konversationshistorik – du hanterar tillstånd i din egen kod.

Livscykel för sessionsberäkning

Statligt	Vad händer
Aktiv	Beräkning körs. Begäranden dirigeras till den. $HOME- och /files-innehåll är tillgängliga.
Inaktiv	Inga begäranden om den konfigurerade tidsgränsen för inaktivitet. Plattformen avetablerar beräkningsresurser och sparar sessionstillstånd ($HOME, `/files`).
Återupptogs	Samma session-ID specificeras igen. Plattformen etablerar ny beräkning och återställer beständiga tillstånd.

Beräkning följer sessionen, inte den enskilda begäran. Plattformen etablerar en sandbox-miljö när en session startar och släpper den när den konfigurerade tidsgränsen för inaktivitet förflutit efter den senaste begäran. När sessionen återupptas återställer plattformen $HOME och /files, så att koden hittar de filer som den skrev tidigare. Följande diagram visar hur en begäran flyttas genom dessa tillstånd.

Säkerhets- och datahantering

Behandla en värdbaserad agent som kod för produktionsprogram.

Viktigt

Använd tredjepartssystem på egen risk och vidta alltid lämpliga skyddsåtgärder för ansvarsfull AI. Du ansvarar för att hantera alla data som kan flöda utanför organisationens efterlevnad och geografiska gränser. Läs mer.

Placera inte hemligheter i containeravbildningar eller miljövariabler. Använd hanterade identiteter och anslutningar och lagra hemligheter i ett hanterat hemligt arkiv. Mer information finns i Set up a Key Vault connection.
Var försiktig med verktyg och servrar som inte är Microsoft. Om din agent anropar verktyg som backas upp av icke-Microsoft-tjänster kan vissa data flöda till dessa tjänster. Granska principer för datadelning, kvarhållning och plats för alla icke-Microsoft tjänster som du ansluter.

Plattformsinformation

Versionshantering

Varje anrop för att skapa en version ger en oföränderlig agentversion. Versionen är en ögonblicksbild av containeravbildningen, resursallokering, miljövariabler och protokollkonfiguration. Om du vill uppdatera din agent skapar och distribuerar du en ny version.

En agentslutpunkt hanterar en version i taget och dirigerar 100% av sin trafik till den versionen. Trafikdelning mellan versioner stöds inte.

Miljövariabler är den primära mekanismen för att skicka konfigurationen till containern vid körning (till exempel projektslutpunkten, modelldistributionsnamnet och anpassade inställningar). De anges per version och är oföränderliga när versionen har skapats.

Observerbarhet

Värdagenter ger inbyggd observerbarhet. Plattformen injicerar automatiskt en Application Insights-anslutningssträng i din agentcontainer via miljövariabler. Agenter som använder protokollbiblioteken genererar OpenTelemetry-spårningar som standard, som visas i den länkade Application Insights-resursen under Undersöka>transaktionssökning eller prestanda.

Information om konfiguration och analys finns i Aktivera spårning i projektet.

Verktygslåda i Foundry

Värdagenter har full åtkomst till verktyg som hanteras av Foundry, inklusive Kodtolk, Webbsökning (med Grounding med Bing Custom Search), Azure AI-sökning, OpenAPI, MCP, A2A, Skills med mera. Du ansluter dessa verktyg via en MCP-slutpunkt för verktygslådan som etablerats i ditt Foundry-projekt i stället för att lägga till dem direkt i agentdefinitionen. Verktygslådan ger dig konsoliderad autentisering över OAuth-identitetsgenomströmning, agentidentitet, nyckelbaserad autentisering med mera. Om du använder Microsoft Agent Framework ansluter du via FoundryToolbox i Python eller AddFoundryToolboxes i .NET i stället för en allmän MCP-klient. Andra körmiljöer ansluter genom att använda standard-MCP-klientbibliotek. Mer information finns i "Kuratera avsiktsbaserad verktygslåda" i Foundry.

Språkstöd

Värdbaserade agenter stöder Python och C#. Du kan använda alla agentramverk – protokollbiblioteken är ramverksagnostiska. Exempel som använder Microsoft Agent Framework, LangGraph och anpassad kod finns i lagringsplatsen foundry-samples.

Sandbox-storlekar

Sandlådor för värdbaserade agenter stöder följande kombinationer av CPU och minne:

CPU	Memory
0,5 vCPU	1 GiB
1 vCPU	2 GiB
2 vCPU	4 GiB

Sessionslagring

Varje session har en beständig $HOME. Plattformen bevarar sitt innehåll när den avetablerar beräkning efter den konfigurerade tidsgränsen för inaktivitet. Plattformen återställer innehållet när sessionen återupptas, så filer som skrivs under $HOME överlever perioder av inaktivitet. Plattformen skriver filer som laddats upp via /files slutpunkten till $HOME, där de delar samma lagring. Varje session har en total diskbudget på upp till 20 GiB vid 1 vCPU eller större, vilket skalas ned proportionellt för mindre CPU-nivåer. Plattformen reserverar cirka 20% av den budgeten för systemanvändning, och den är inte synlig eller tillgänglig för din agent. Resten fördelas mellan din containeravbildning, $HOME och eventuella andra skrivbara platser i containern.

Skalning och rätt dimensionering

Värdbaserade agenter skalas per session, inte per replik. Plattformen skapar en ny VM-isolerad sandbox-miljö för varje session på begäran och håller beräkningen aktiv medan begäranden fortsätter. Varje begäran återställer den inaktiva timern. När den konfigurerade tidsgränsen för inaktivitet förflutit efter den senaste begäran avetablerar plattformen sandbox-beräkningen och bevarar sessionstillståndet.

Tidsgränsen för inaktivitet kan vara 5 till 60 minuter och är som standard 15 minuter. Plattformen tar bort en session permanent efter 30 dagars inaktivitet. Det finns inget replikantal att konfigurera och ingen varm pool att storleksanpassa.

Eftersom varje session körs i en egen sandbox-miljö beskriver de cpu- och minnesvärden som du anger i en agentversion en enda session, inte agentens aggregerade fotavtryck. Faktureringen baseras på förbrukad CPU och minne över alla aktiva sessioner, så överdimensionering multiplicerar kostnaden i takt med antalet samtidiga sessioner.

För att dimensionera rätt kör du en representativ arbetsbelastning och granskar resursanvändningen i den länkade resursen i Application Insights:

Öppna App Insights-resursen i Azure-portalen och välj Investigate>Performance.
Granska CPU, tillgängligt minne, begärandefrekvens och genomsnittlig varaktighet för begäran under det tidsintervall som du testade.

Jämför de observerade topparna med den processor och det minne som du allokerade. Om ihållande toppar överstiger ungefär 70 % av allokeringen, höj allokeringen för nästa agentversion. Om topparna ligger klart under, sänk allokeringen för att minska kostnaderna. Testa alltid igen efter en ändring, eftersom varje ny version är oföränderlig.

Privata nätverk

Värdbaserade agenter stöder distribution inom nätverksisolerade Foundry-resurser och kan använda en kundbaserad Azure Virtual Network för utgående trafik. Detta gör det möjligt för agenter i nätverksisolerade Foundry-distributioner att nå privata resurser, till exempel databaser eller interna API:er. Mer information finns i Konfigurera virtuella nätverk.

Observera

Foundry-projekt som skapats efter den 25 juni 2026 stöder en privat (nätverksskyddad) Azure Container Registry för din agentbild. Projekt som skapades före det datumet kräver att registret förblir nåbart över sin offentliga slutpunkt. Befintliga projekt påverkas inte. Mer information finns i Begränsningar.

Gränser, priser och tillgänglighet

Prissättning

Fakturering för hanterad värdkörning baseras på förbrukning av PROCESSOR- och minnesresurser under aktiva sessioner. Aktuella priser finns på sidan med foundry-priser.

Regiontillgänglighet

Värdbaserade agenter är för närvarande tillgängliga i följande regioner:

Australien, östra
Sydbrasiliens
Kanada Central
Canada East
Central US
East US
Östra USA 2
Frankrike Central
Tyskland Västcentral
Italy North
Japan, östra
Japan West
Korea Central
USA, norra centrala
Norge, östra
Polen Central
Sydafrika, norra
Södra centrala USA
Södra Indien
Sydostasien
Centrala Spanien
Centrala Sverige
Schweiz, norra
Switzerland West
UAE North
UK South
UK West
Västra centrala USA
West Europe
Västra USA
Västra USA 3