Co jsou hostovaní agenti?

Při vytváření agentských aplikací pomocí opensourcových architektur obvykle spravujete řadu problémů, které se týkají kontejnerizace, nastavení webového serveru, zabezpečení, trvalosti paměti, škálování, instrumentace a vrácení verzí. Tyto úlohy jsou ještě náročnější v heterogenních cloudových prostředích.

Agenti hostovaní ve službě Foundry Agent Service řeší tyto výzvy pro uživatele Microsoft Foundry. Hostovaní agenti volají modely z katalogu modelů Foundry, aby prováděli logické úvahy, zatímco váš vlastní kód zpracovává orchestraci. Pomocí této spravované platformy můžete bezpečně a ve velkém nasazovat a provozovat agenty AI. Můžete použít vlastní kód agenta nebo upřednostňovanou architekturu agenta se zjednodušeným nasazením a správou.

Kdy použít hostované agenty

Zvolte hostované agenty spíše než agenty založené na promtách, když potřebujete:

  • Přineste svůj vlastní kód – použijte libovolný framework (Agent Framework, LangGraph, Sémantické jádro nebo vlastní kód) místo pouhých definic výzev.
  • Používejte vlastní protokoly – přijímejte webhooky nebo datové části, které nejsou OpenAI, pomocí protokolu Invocations.
  • Řízení výpočetních prostředků – zadejte procesor a paměť pro sandbox vašeho agenta.
  • Spouštění stavových úloh – ukládat soubory a stav během různých iterací prostřednictvím $HOME a koncového bodu /files.

Jak to funguje

Agenta zabalíte jako image kontejneru a nasdílíte ho do Azure Container Registry. Když nasadíte, služba agenta načte image, zřídí výpočetní prostředky, přiřadí vyhrazenou Microsoft Entra ID (identitu agenta) a zpřístupní vyhrazený koncový bod. Kód agenta za běhu zpracovává požadavky klientů a může volat modely Foundry, nástroje sady nástrojů a podřízené služby Azure pomocí své identity agenta. Platforma zpracovává škálování, trvalost stavu relace, pozorovatelnost a správu životního cyklu.

Důležité

Pokud používáte hostované agenty s jinými produkty a službami Microsoft, musíte si přečíst veškerou relevantní dokumentaci k těmto produktům a službám a porozumět souvisejícím rizikům a aspektům dodržování předpisů.

Pokud používáte hostovaného agenta se všemi servery třetích stran, agenty, kódem nebo modely bez Azure Direct ("Systémy třetích stran"), provedete to na vlastní nebezpečí. Systémy třetích stran nejsou Microsoft Produkty podle Microsoft Podmínek produktu a řídí se vlastními licenčními podmínkami třetích stran. Zodpovídáte za veškeré využití a související náklady.

Doporučujeme zkontrolovat veškerá data sdílená se systémy třetích stran a přijímat je ze systémů třetích stran a seznámit se s postupy třetích stran pro zpracování, sdílení, uchovávání a umístění dat. Podobně pokud se připojujete nebo integrujete s služby Microsoft a funkcemi, které nejsou součástí Foundry, je důležité si projít postupy jejich dat. Je vaší zodpovědností spravovat, jestli budou vaše data přetékat mimo dodržování předpisů a geografické hranice vaší organizace a případné související důsledky a že se zřídí příslušná oprávnění, hranice a schválení.

Zodpovídáte za pečlivou kontrolu a testování aplikací, které vytváříte v kontextu konkrétních případů použití, a za veškerá vhodná rozhodnutí a přizpůsobení. To zahrnuje implementaci vlastního zodpovědného zmírnění rizik umělé inteligence, jako jsou metaprompty, filtry obsahu nebo jiné bezpečnostní systémy, a zajištění toho, aby vaše aplikace splňovaly příslušné standardy kvality, spolehlivosti, zabezpečení a důvěryhodnosti. Podívejte se na poznámku k transparentnosti služby agenta Foundry.

Klíčové koncepty

Hostovaní agenti

Hostovaní agenti jsou kontejnerizované aplikace AI, které běží ve službě agentů. Na rozdíl od agentů založených na příkazovém řádku, které jsou definovány zcela prostřednictvím výzev a konfigurace nástrojů na portálu Foundry, jsou hostovaní agenti vaším vlastním kódem zabaleným jako image kontejneru. Zvolíte architekturu, řídíte chování modulu runtime a nasadíte image do Microsoft spravované infrastruktury.

Platforma automaticky spravuje životní cyklus kontejneru na základě aktivity, zřizuje prostředky při vytváření verze a ruší zřízení, když je dosažen časový limit nečinnosti.

Model izolace

Hostovaní agenti běží v sandboxech izolovaných pro každou relaci. Každá relace získá vyhrazený sandbox s trvalým souborovým systémem ($HOME a /files), který umožňuje škálování na nulovou úroveň se stavovým obnovením a předvídatelnými chladnými starty. Relace jsou navzájem izolované a stav se automaticky obnovuje, když se relace znovu aktivuje po nečinnosti.

Protokoly: Odpovědi, vyvolání a vyvolání (WebSocket)

Kontejnery hostovaného agenta můžou vystavit jeden nebo více protokolů. Každý protokol poskytuje odlehčená knihovna, která zpracovává server HTTP nebo WebSocket, kontroly stavu a integraci OpenTelemetry. Protokoly Responses, Invocations a Invocations (WebSocket) jsou k dispozici ve všech oblastech, které podporují hostované agenty.

Jaký protokol mám použít?

Scénář Protokol Proč
Konverzační chatovací robot nebo asistent Reakce Platforma spravuje historii konverzací, streamované události a životní cyklus relací – jako klienta použijte libovolnou sadu SDK kompatibilní s OpenAI.
Vícekrokový systém otázek a odpovědí s RAG nebo nástroji Reakce Integrované zpracování vláken ID konverzace a zpracování výsledků nástrojů
Zpracování na pozadí / asynchronní zpracování Reakce pozadí: pravda s platformou spravovaným dotazováním a zrušením — není potřeba žádný vlastní kód.
Agent publikovaný v Teams nebo Microsoft 365 Reakce + Činnosti Protokol Odpovědí využívá logiku agenta; platforma automaticky spojuje Odpovědi s Protokolem Aktivity pro dodání do kanálů.
Přijímač Webhooku (GitHub, Stripe, Jira atd.) Vyvolání Externí systém odesílá vlastní formát datové části – nemůžete ho změnit tak, aby odpovídal /responses.
Nekoverzační zpracování (klasifikace, extrakce, dávka) Vyvolání Vstup je strukturovaná data, ne chatovací zpráva. Libovolný JSON dovnitř, libovolný JSON ven.
Vlastní protokol streamování (AG-UI atd.) Vyvolání AG-UI a další protokoly agent-UI nejsou kompatibilní s OpenAI – potřebujete nezpracovaný ovládací prvek SSE.
Protokolový most (GitHub Copilot, proprietární systémy) Vyvolání Volající má vlastní protokol, který se nemapuje na /odpovědi.
Hlasový agent v reálném čase (vstup z mikrofonu, výstup hlasem) Vyvolání (WebSocket) Obousměrné streamování přes jedno trvalé připojení. Spárujte ve svém kontejneru s Pipecat, LiveKit nebo Voice Live. Viz Vytvoření hlasového agenta.

Tip

Těžko říct? Začněte odpověďmi. Koncový bod vyvolání můžete kdykoli přidat později – hostovaný agent může podporovat oba protokoly současně.

Porovnání protokolů

Reakce Vyvolání
Nejlepší pro Většina agentů – platforma spravuje historii konverzací, životní cyklus streamování a spouštění na pozadí. Agenti, kteří potřebují úplnou kontrolu nad HTTP, vlastní uživatelská data nebo dlouhodobé asynchronní pracovní postupy
Datová část Kontrakt kompatibilní s OpenAI /responses Libovolný JSON prostřednictvím /vyvolání – definujete schéma.
Klientská sada SDK Jakékoli SDK kompatibilní s OpenAI (Python, JS, C#) funguje ihned po vybalení." Vlastní klient – definujete kontrakt.
Historie relací Platforma spravovaná prostřednictvím ID konverzace Spravujete relace (v paměti, Cosmos DB atd.)
Streaming ResponseEventStream spravovaný platformou s událostmi životního cyklu Surové SSE – formátujte a zapisujte události přímo
Pozadí / dlouhotrvající Integrované (pozadí: true + dotazování spravované platformou) Ruční sledování úloh a vlastní koncové body dotazování

Další protokoly

Hostovaní agenti také podporují protokol Activity pro Teams a integraci kanálu Microsoft 365. Když použijete protokol Odpovědi pro logiku agenta a publikujete ho do kanálů Microsoft 365, jako je Teams, platforma automaticky propojí Odpovědi s protokolem Activity pro doručování v rámci kanálu—není potřeba žádné další zapojení. Protokol A2A podporuje delegování agenta mezi agenty. Podporované protokoly je možné kombinovat v jednom agentu.

Identita a koncový bod agenta

Každý hostovaný agent nasazený do projektu Foundry získá své vlastní vyhrazené ID Microsoft Entra (identitu agenta) a vyhrazený koncový bod — obojí se vytvoří automaticky při nasazení. Spravované identity ani směrování nemusíte konfigurovat ručně.

Koncový bod je k dispozici ihned po nasazení – publikování se nevyžaduje pro programový přístup:

  • Odpovědi: {project_endpoint}/agents/{name}/endpoint/protocols/openai/responses
  • Vyvolání: {project_endpoint}/agents/{name}/endpoint/protocols/invocations
  • Vyvolání (WebSocket): wss://{account}.services.ai.azure.com/api/projects/{project}/agents/{name}/endpoint/protocols/invocations_ws?api-version=v1
  • A2A (Preview):{project_endpoint}/agents/{name}/endpoint/protocols/a2a

Které koncové body jsou aktivní, závisí na protokolech deklarovaných v definici verze agenta. Tuto definici nastavte ve službě azure.ai.agent v azure.yaml při použití azd, nebo prostřednictvím sady SDK protocol_versions.

Jsou zapojeny dvě identity:

Identita Scope Účel
Microsoft Entra ID (identita agenta, na jednoho agenta) Automaticky vytvořeno v době nasazení Identita, s níž se kontejner agenta autentizuje během běhu. Používá se pro volání modelu, přístup k nástrojům a podřízené služby Azure.
Spravovaná identita projektu (celoprojektový) Systém přiřazený k projektu Foundry Používá se platformou pro operace infrastruktury (například Čtenář úložiště container Registry v registru kontejneru). Ne identita modulu runtime agenta.

Ve výchozím nastavení může identita agenta přistupovat k inferencím modelu prostřednictvím koncového bodu projektu a k úložišti relací. Pro externí prostředky (například vaše vlastní úložiště Azure) přiřaďte role RBAC ručně identitě Microsoft Entra ID agenta. Další informace najdete v tématu Přístup agenta nad rámec výchozích hodnot.

Při integraci prostřednictvím kanálů Microsoft 365 (například Teams) můžou hostovaní agenti pracovat ve dvou režimech identit v závislosti na způsobu jejich vyvolání:

  • Scénáře vyvolané uživatelem (interaktivní):: Pokud existuje token uživatele, platforma podporuje toky OAuth 2.0 on-Behalf-Of (OBO). V takovém případě může agent jménem uživatele volat následné služby pomocí delegovaných oprávnění uživatele v souladu se zásadami tenanta Microsoft Entra ID.

  • Autonomní scénáře nebo scénáře běžící na pozadí: Pokud není k dispozici žádný token uživatele, agent se ověřuje pomocí vlastní identity Microsoft Entra ID (identity agenta), obvykle prostřednictvím spravované identity, k přístupu ke službám na nižší úrovni.

V obou případech si agent zachovává své vyhrazené Microsoft Entra ID pro autentizaci, autorizaci a auditovatelnost. Další informace najdete v tématu Aplikace agenta a koncepty identit agenta.

Sezení a konverzace

Hostovaní agenti používají ke správě stavu relace a konverzace . Způsob práce závisí na protokolu.

Sezení

ID relace identifikuje logickou relaci s trvalým stavem, včetně $HOME a souborů nahraných prostřednictvím koncového bodu /files. Platforma zřizuje výpočetní kapacitu na vyžádání a obnovuje na ni trvalý stav.

  • Trvalost stavu: obsah $HOME a /files se zachovává napříč změnami a obdobími nečinnosti. Když je výpočetní systém nečinný a znovu uveden do provozu (na nové nebo stávající infrastruktuře), stav relace se automaticky vrátí.
  • Izolace: Každá relace je izolovaná od ostatních relací.
  • Automatický životní cyklus: Relace jsou vytvořeny při prvním použití. Platforma automaticky zřizuje a ruší přidělení výpočetních prostředků.
  • Životnost relace: Časový limit nečinnosti je 15 minut – pokud během této doby nedorazí žádný požadavek, platforma uvolní výpočetní prostředky a uloží stav relace. Relace bude trvale odstraněna po 30 dnech nečinnosti.
  • Rozhraní API pro správu relací: Výpis relací, ukončení relací a nahrávání nebo stahování souborů na relaci.

Konverzace

ID konverzace je trvalý záznam historie konverzací (zprávy, volání nástrojů a odpovědi) uložených v Foundry.

  • Trvalost: Historie konverzací se ukládá v Foundry a uchovává nezávisle na výpočetním stavu.
  • Přístup mezi kanály: Uživatelé mají přístup ke stejné konverzaci z dětského hřiště, rozhraní API, Teams nebo jiných publikovaných kanálů.

Jak relace a konverzace fungují s každým protokolem

Protokol odpovědí: ID konverzace je primární koncept. Platforma spravuje historii konverzací automaticky a přidruží ID relace ke každé konverzaci. Platforma vrátí ID relace klientovi, který ho může použít k nahrání souborů prostřednictvím koncového bodu /files, čímž zpřístupní tyto soubory výpočetním procesům konverzace.

Protokol vyvolání: primárním konceptem je ID relace. Klient spravuje ID relace přímo za účelem zachování stavu napříč interakcemi. Klient může nahrát obsah přes koncový bod /files pomocí ID relace a zpřístupnit ho pro relaci. Neexistuje žádná historie konverzací spravovaná platformou – stav spravujete ve vlastním kódu.

Životní cyklus relace výpočtů

Státu Co se stane
Aktivní Výpočetní funkce je spuštěná. Požadavky jsou směrovány na něj. obsah $HOME a /files jsou k dispozici.
Nečinný Žádné požadavky po dobu 15 minut. Výpočetní prostředky se zruší. Stav relace ($HOME, /files) je trvalý.
Obnoveno Stejné ID relace je opět použito. Platforma zřizuje nové výpočetní jednotky a obnovuje trvalý stav.

Zabezpečení a zpracování dat

Zacházejte s hostovaným agentem stejně jako s kódem produkční aplikace.

Důležité

Používejte systémy třetích stran na vlastní nebezpečí a vždy implementujte vhodná zodpovědná zmírnění rizik umělé inteligence. Zodpovídáte za správu všech dat, která můžou proudit mimo dodržování předpisů a geografické hranice vaší organizace. Další informace.

  • Neukládejte tajné kódy do imagí kontejnerů ani proměnných prostředí. Používejte spravované identity a připojení a ukládejte tajné kódy do spravovaného úložiště tajných kódů. Pokyny najdete v tématu Nastavte připojení Key Vault.
  • Buďte opatrní s nástroji a servery, které nejsou Microsoft. Pokud váš agent volá nástroje podporované službami jinými než Microsoft, mohou některá data proudit do těchto služeb. Zkontrolujte zásady sdílení, uchovávání a umístění dat pro všechny služby, které nejsou Microsoft, ke které se připojujete.

Podrobnosti o platformě

Verzování

Každé volání vytvoření verze vytvoří neměnnou verzi agenta – snímek obrazu kontejneru, přidělení prostředků, proměnné prostředí a konfigurace protokolu. Rozložení se vztahují na konkrétní verzi. Pokud chcete aktualizovat agenta, vytvoříte novou verzi a platforma ji nasadí. Všimněte si, že požadavky na vytvoření verze agenta beze změny parametrů verze agenta, jako je image kontejneru, proměnné prostředí atd., nebudou mít za následek vytvoření nové verze. Přenosy je možné rozdělit mezi verze s váženým nasazením pro podporu kanárských a modrozelených nasazení.

Proměnné prostředí jsou primárním mechanismem pro předávání konfigurace kontejneru za běhu (například koncový bod projektu, název nasazení modelu a vlastní nastavení). Nastaví se pro každou verzi a po vytvoření verze je neměnná.

Pozorovatelnost

Hostovaní agenti poskytují integrovanou pozorovatelnost. Platforma automaticky vloží připojovací řetězec pro Application Insights do kontejneru agenta prostřednictvím proměnných prostředí. Agenti, kteří používají knihovny protokolů, vytvářejí výchozí trasování OpenTelemetry, které se zobrazují v propojeném prostředku Application Insights v části Prozkoumat>Vyhledávání transakcí nebo Výkon.

Pokyny k konfiguraci a analýze najdete v tématu Povolení trasování v projektu.

Sada nástrojů v Foundry

Důležité

Přidání nástrojů přímo do definice hostovaného agenta se nepodporuje. V Foundry doporučujeme používat sady nástrojů.

Hostovaní agenti přistupují k nástrojům spravovaným Foundry (Interpret kódu, Vyhledávání na webu, Azure AI Vyhledávač, OpenAPI, vlastní připojení MCP, A2A) prostřednictvím koncového bodu Toolbox MCP zřízeného v projektu Foundry. Váš kód agenta se připojí k tomuto koncovému bodu pomocí standardních klientských knihoven MCP. Platforma nástroje automaticky nevkládá. Podrobnosti naleznete v sekci Zakládat nástroje založené na záměru ve Foundry. Pokud chcete propojit nástroje v hostovaném agentu s konsolidovanou podporou ověřování napříč předáváním identity OAuth, identitou agenta, klíčem a dalšími prostředky, použijte sadu nástrojů v Foundry.

Podpora jazyků

Hostovaní agenti podporují Python a C#. Můžete použít libovolnou architekturu agenta – knihovny protokolů jsou nezávislé na rozhraní. Ukázky využívající Microsoft Agent Framework, LangGraph a vlastní kód najdete v úložišti foundry-samples.

Velikosti sandboxu

Hostované sandboxy agentů podporují následující kombinace procesoru a paměti:

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

Úložiště relací

Každá relace má trvalou $HOME. Jeho obsah se zachová, když se po 15 minutách nečinnosti uvolní výpočetní prostředky, a obnoví se po obnovení relace, takže soubory zapsané v umístění $HOME přetrvají i během nečinnosti. Soubory nahrané prostřednictvím koncového bodu /files se zapisují do $HOME a sdílejí stejné úložiště. Každé relaci je přidělen celkový limit diskového prostoru až 20 GiB pro konfigurace s 1 vCPU a více; u nižších úrovní CPU se tento limit poměrně snižuje. Přibližně 20% tohoto rozpočtu je vyhrazené pro použití systému a není viditelné nebo dostupné pro vašeho agenta. Zbytek je rozdělen mezi bitovou kopii vašeho kontejneru, $HOME, a všechna ostatní zapisovatelná umístění ve vašem kontejneru.

Škálování a nastavení správné velikosti

Hostovaní agenti se škálují podle relace, nikoli podle repliky. Platforma vytvoří nový izolovaný sandbox virtuálního počítače pro každou relaci na vyžádání, spustí ho po dobu trvání relace (15minutový časový limit nečinnosti, maximální životnost 30 dnů) a po skončení relace ji vytrhne. Není třeba konfigurovat počet replik ani určovat velikost teplého fondu.

Vzhledem k tomu, že každá relace běží ve vlastním sandboxu, popisují hodnoty procesoru a paměti nastavené na verzi agenta jednu relaci, nikoli agregační nároky agenta. Fakturace se odvíjí od CPU a paměti spotřebovaných ve všech aktivních relacích, takže předimenzování násobí náklady počtem souběžných relací.

Chcete-li správně dimenzovat prostředky, spusťte reprezentativní zatížení a zkontrolujte využití prostředků v propojeném prostředku služby Application Insights:

  1. Na portálu Azure otevřete prostředek App Insights a vyberte Investigate>Performance.
  2. Zkontrolujte využití procesoru, dostupné paměti, frekvence požadavků a průměrnou dobu trvání požadavků v průběhu testovaného časového rozsahu.

Porovnejte pozorované špičky s přiděleným CPU a pamětí. Pokud trvalé špičky překročí přibližně 70 % alokace, zvyšte alokaci u další verze agenta; pokud špičky zůstávají výrazně pod touto hranicí, snižte ji, abyste snížili náklady. Vždy znovu testujte po změně, protože každá nová verze je neměnná.

Privátní sítě

Hostovaní agenti podporují nasazení v rámci síťových izolovaných prostředků Foundry a můžou pro odchozí provoz používat Azure Virtual Network poskytované zákazníkem. To umožňuje agentům v nasazeních Foundry izolovaných sítí přístup k privátním prostředkům, jako jsou databáze nebo interní rozhraní API. Další informace najdete v tématu Konfigurace virtuálních sítí.

Poznámka

Projekty Foundry vytvořené po 25. červnu 2026 podporují privátní (zabezpečenou síť) Azure Container Registry pro vaši image agenta. Projekty vytvořené před tímto datem vyžadují, aby registr zůstal dostupný přes svůj veřejný koncový bod. Stávající projekty nejsou ovlivněné. Další informace najdete v tématu Omezení.

Limity, ceny a dostupnost

Ceny

Fakturace spravovaného hostitelského modulu runtime je založená na spotřebě prostředků procesoru a paměti během aktivních relací. Aktuální sazby najdete na stránce s cenami Foundry.

Dostupnost oblastí

Hostovaní agenti jsou aktuálně k dispozici v následujících oblastech:

  • USA – východ 2
  • Střed USA – sever
  • Švédsko – střed
  • Kanada – střed
  • Kanada – východ
  • Jihovýchodní Asie
  • Polsko – střed
  • Jižní Afrika – sever
  • Korea – střed
  • Indie – jih
  • Brazílie – jih
  • USA – západ
  • USA – západ 3
  • Norsko – východ
  • Japonsko – východ
  • Francie – střed
  • Německo – středozápad
  • Švýcarsko – sever
  • Španělsko – střed
  • Austrálie – východ

Poznámka

Tento seznam se aktualizuje, jakmile budou k dispozici další oblasti.

Další kroky

Úkol Odkaz
Sestavení a nasazení prvního hostovaného agenta Rychlý start: Nasazení prvního hostovaného agenta
Nasazení pomocí sady Foundry SDK Nasazení hostovaného agenta pomocí sady Foundry SDK
Aktualizace, odstranění, vyvolání nebo streamování protokolů Správa hostovaných agentů
Nastavení trasování a monitorování Povolení trasování v projektu
Automatická optimalizace pokynů agenta Přehled optimalizátoru agentů
Vyhodnocení výkonu agenta Vyhodnocení agentů
Publikování do Teams, Microsoft 365 nebo vlastních aplikací Aplikace agentů
Procházení ukázek kódu Python ukázky a ukázky jazyka C#

Související obsah

  • Last updated on