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.

När värdbaserade agenter ska användas

Välj värdbaserade 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.

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, etablerar beräkning, tilldelar en dedikerad Microsoft Entra ID (agentidentitet) och exponerar en dedikerad slutpunkt. Vid körning hanterar agentkoden begäranden från klienter 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.

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 värdbaserade agenter med servrar, agenter, kod eller modeller från tredje part 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. Granska alla data som delas med och tas emot från tredjepartssystem. Var medveten om tredje parts metoder för hantering, delning, kvarhållning och lagring av data. Det är ditt ansvar att hantera om dina data flödar utanför organisationens Azure efterlevnad och geografiska gränser och eventuella relaterade konsekvenser. Microsoft har inget ansvar gentemot dig eller andra när det gäller användning av system från tredje part, och du ansvarar för att implementera dina egna ansvarsfulla AI-åtgärder, till exempel metaprompter, innehållsfilter eller andra säkerhetssystem.

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 och anrop

Värdbaserade agentcontainrar exponerar ett eller båda av två protokoll. Varje protokoll tillhandahålls av ett lättviktsbibliotek som hanterar HTTP-servern, hälsokontroller och OpenTelemetry-integrering.

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 plattformhanterad polling och annullering – ingen anpassad kod behövs.
Agent publicerad i Teams eller M365	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.

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 ha stöd för båda protokollen samtidigt.

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	Inbyggd (bakgrund: true + plattformsstyrd polling)	Manuell aktivitetsspårning och anpassade slutpunkter för avsökning

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. Alla fyra protokoll – svar, anrop, aktivitet och A2A – 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/v1/responses
Anropningar: {project_endpoint}/agents/{name}/endpoint/protocols/invocations

Vilka slutpunkter som är aktiva beror på de protokoll som deklareras i agentversionsdefinitionen (anges i agent.yaml när du använder azd eller via container_protocol_versions när du använder SDK).

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.

När du distribuerar med azd tilldelas den nödvändiga RBAC-rollen (Azure AI-användare i kontoomfånget) till agentens Microsoft Entra ID automatiskt. För externa resurser (till exempel din egen Azure Storage) tilldelar du RBAC manuellt till agentens Microsoft Entra ID.

När de är integrerade via Microsoft 365 kanaler (till exempel Teams) kan värdbaserade agenter också arbeta med användaridentiteten å OBO:s vägnar. Agentens Microsoft Entra ID kan byta ut en användartoken för att anropa underordnade tjänster som användaren, med förbehåll för klientprinciper. 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: Sessioner sparas i upp till 30 dagar. Tidsgränsen för inaktivitet är 15 minuter – om ingen begäran kommer in i det fönstret avetablerar plattformen beräkningen och bevarar sessionstillståndet.
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 på 15 minuter. Datorkraft avvecklas. Sessionstillståndet ($HOME, /files) sparas.
Återupptogs	Samma session-ID specificeras igen. Plattformen etablerar ny beräkning och återställer beständiga tillstånd.

Säkerhets- och datahantering

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

Viktigt

Om du använder Foundry Agent Service som värd för agenter som interagerar med modeller, servrar eller agenter från tredje part gör du det på egen risk. Vi rekommenderar att du granskar alla data som delas med tredjepartsmodeller, servrar eller agenter och förstår metoder från tredje part för kvarhållning och plats för data. Det är ditt ansvar att hantera om dina data flödar utanför organisationens Azure efterlevnad och geografiska gränser och eventuella relaterade konsekvenser.

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 – en ögonblicksbild av containeravbildningen, resursallokering, miljövariabler och protokollkonfiguration. Implementeringar refererar till en viss version. Om du vill uppdatera din agent skapar du en ny version och plattformen distribuerar den. Observera att begäranden om att skapa agentversion utan att ändra agentversionsparametrarna, till exempel containeravbildning, miljövariabler osv. inte resulterar i att en ny version skapas. Du kan dela trafik mellan versioner med viktade distributioner för att stödja kanarie- och blågröna distributioner.

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ärdbaserade agenter får åtkomst till Foundry-hanterade verktyg (kodtolkare, webbsökning, Azure AI-sökning, OpenAPI, anpassade MCP-anslutningar, A2A) via en Toolbox MCP-slutpunkt etablerad i ditt Foundry-projekt. Din agentkod ansluter till den här slutpunkten med hjälp av mcp-standardklientbibliotek – plattformen matar inte in verktyg automatiskt. Mer information finns i "Kuratera avsiktsbaserad verktygslåda" i Foundry. Vi rekommenderar att kunder använder verktygslådan i Foundry för att ansluta verktyg i en värdbaserad agent med konsoliderat autentiseringsstöd för OAuth Identity-genomströmning, agentidentitet, nyckelbaserad med mera.

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

Värdbaserade agentsandlådor stöder processor- och minnesallokeringar från 0,25 vCPU/0,5 GiB till 2 vCPU/4 GiB.

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

Den Azure Container Registry som innehåller din agentbild måste för närvarande vara nåbar över den offentliga slutpunkten. Privat nätverksskyddad ACR stöds inte för närvarande.

Gränser, priser och tillgänglighet (förhandsversion)

Värdbaserade agenter är för närvarande i förhandsgranskning.

Begränsningar under förhandsversionen

Gräns	Omfattning	Standardvärdet	Justerbar
Maximalt antal aktiva samtidiga sessioner	per region och prenumeration	50	Ja, med kvotbegäranden till Microsoft Support

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:

Östra USA 2
USA, norra centrala
Centrala Sverige
Kanada Central
Sydostasien
Polen Central
Sydafrika, norra
Korea Central
Södra Indien
Sydbrasiliens
Västra USA
Västra USA 3
Norge, östra
Japan, östra
Frankrike Central
Schweiz, norra
Centrala Spanien
Australien, östra