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 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.

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 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 plattformhanterad polling och annullering – ingen anpassad kod behövs.
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.

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. 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: 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. En session tas bort 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 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

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 – 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

Viktigt

Det går inte att lägga till verktyg direkt i den värdbaserade agentens definition. Vi rekommenderar att du använder verktygslådor 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. Om du vill ansluta verktyg i en värdbaserad agent med konsoliderat autentiseringsstöd för OAuth Identity-genomströmning, agentidentitet, nyckelbaserad med mera använder du verktygslådan 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. Innehållet bevaras när beräkningsresursen avetableras efter 15 minuters inaktivitet och återställs när sessionen återupptas, så att filer som skrivs under $HOME finns kvar under inaktiva perioder. Filer som laddas upp via /files slutpunkten skrivs till $HOME och delar samma lagring. Varje session allokeras en total diskbudget på upp till 20 GiB vid 1 vCPU eller större, vilket skalas ned proportionellt för mindre CPU-nivåer. Cirka 20% av den budgeten är reserverad för systemanvändning och ä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 vid behov en ny VM-isolerad sandlådemiljö för varje session, kör den under sessionens varaktighet (inaktivitetstimeout på 15 minuter, maximal livslängd 30 dagar) och avvecklar den när sessionen avslutas. 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:

  1. Öppna App Insights-resursen i Azure-portalen och välj Investigate>Performance.
  2. 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:

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

Observera

Den här listan uppdateras när ytterligare regioner blir tillgängliga.

Nästa steg

Uppgift Länk
Skapa och distribuera din första värdbaserade agent Snabbstart: Distribuera din första värdbaserade agent
Distribuera med hjälp av Foundry SDK Distribuera en värdbaserad agent med hjälp av Foundry SDK
Uppdatera, ta bort, anropa eller strömma loggar Hantera värdbaserade agenter
Konfigurera spårning och övervakning Aktivera spårning i projektet
Optimera agentinstruktioner automatiskt Översikt över agentoptimerare
Utvärdera agentprestanda Agentutvärderingar
Publicera till Teams, Microsoft 365 eller anpassade appar Agentapplikationer
Bläddra bland kodexempel Python exempel och C#-exempel

Relaterat innehåll

  • Last updated on