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 uvažování, 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

Pokud potřebujete, zvolte hostované agenty namísto agentů založených na výzvách:

  • Přineste si vlastní kód – použijte libovolný rámec (Agent Framework, LangGraph, Sémantické jádro nebo vlastní kód) místo pouze výzvových definic.
  • Používejte vlastní protokoly – přijímejte webhooky nebo datové části jiné než OpenAI prostřednictvím protokolu Invocations.
  • Řízení výpočetních prostředků – zadejte procesor a paměť pro sandbox vašeho agenta.
  • Provoz stavových úloh – zachování souborů a stavu mezi jednotlivými spuštěními 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 od klientů a může volat modely Foundry, nástroje sady nástrojů Foundry 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é agenty se servery, agenty, kódem nebo modely třetích stran, které nejsou Azure modely Direct ("Systémy třetích stran"), uděláte 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. Zkontrolujte všechna data sdílená se systémy třetích stran a přijatá od těchto systémů. Mějte na paměti postupy třetích stran pro zpracování, sdílení, uchovávání a umístění dat. Je vaší zodpovědností spravovat, zda vaše data přesahují rámec souladu s Azure a geografickými hranicemi vaší organizace a jaké to může mít související důsledky. Microsoft nemá žádnou odpovědnost za používání systémů třetích stran a zodpovídáte za implementaci vlastního zodpovědného zmírnění rizik umělé inteligence, jako jsou metaprompty, filtry obsahu nebo jiné bezpečnostní systémy.

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 výzev, 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, přidělování prostředků při vytváření verze a odebrání prostředků při dosažení časového limitu nečinnosti.

Model izolace

Hostiovaní agenti běží ve VM-izolovaných sandboxech pro jednotlivé relace. Každá relace získá vyhrazený sandbox s trvalým systémem souborů ($HOME a /files), který umožňuje škálování na nulu se stavovým obnovením a předvídatelnými studenými starty. Relace jsou navzájem izolované a stav se automaticky obnoví, když se relace obnoví po nečinnosti.

Protokoly: Odpovědi a vyvolání

Hostované kontejnery agentů zpřístupňují jeden nebo oba protokoly. Každý protokol poskytuje odlehčená knihovna, která zpracovává integraci serveru HTTP, kontrol stavu a OpenTelemetry.

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ícekolová otázka a odpověď s RAG nebo nástroji Reakce Integrované přiřazení ID konverzací k vláknům a manipulace s výsledky nástrojů.
Zpracování na pozadí / asynchronní zpracování Reakce na pozadí: true se spravovaným vyčítáním a rušením platformou – není potřeba žádný vlastní kód.
Agent publikovaný do Teams nebo M365 Reakce + Činnosti Protokol odpovědí využívá logiku agenta; Protokol aktivit zpracovává integraci kanálu Teams.
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 /odpovědi.
Nekomunikační zpracování (klasifikace, extrakce, dávkové) 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í entita má vlastní protokol, který nesouvisí s /odpovědi.

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í zásilky nebo dlouhotrvající asynchronní pracovní postupy
Náklad Smlouva kompatibilní s OpenAI /responses Libovolný JSON prostřednictvím /vyvolání – definujete schéma.
Klientská sada SDK Kterákoliv sada SDK kompatibilní s OpenAI (Python, JS, C#) funguje okamžitě bez nutnosti dalšího nastavování Vlastní klient – definujete kontrakt.
Záznam relací Platforma spravovaná prostřednictvím ID konverzace Spravujete relace (v interní paměti, Cosmos DB atd.)
Streaming ResponseEventStream spravovaný platformou s událostmi životního cyklu Nezpracovaný SSE – formátujete a zapisujete události přímo
Proces běžící na pozadí / dlouho trvají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 Aktivit pro Teams a integraci kanálu M365 (obvykle se používá společně s Odpověďmi) a protokol A2A pro delegování agent-agent. Všechny čtyři protokoly – odpovědi, vyvolání, aktivita a A2A – je možné kombinovat v jednom agentovi.

Identita a koncový bod agenta

Každý hostovaný agent nasazený do projektu Foundry získá svůj vlastní vyhrazený Microsoft Entra ID (identita agenta) a vyhrazený koncový bod – oba se vytvoří automaticky v době 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/v1/responses
  • Vyvolání: {project_endpoint}/agents/{name}/endpoint/protocols/invocations

Které koncové body jsou aktivní, závisí na protokolech deklarovaných v definici verze agenta (nastavené v agent.yaml při použití azd nebo prostřednictvím container_protocol_versions při použití sady SDK).

Jsou zapojeny dvě identity:

Identita Scope Účel
Microsoft Entra ID (identita agenta, na jednoho agenta) Automaticky vytvořeno v době nasazení Identita, pomocí které se kontejner agenta ověřuje za běhu. Používá se pro volání modelu, přístup k nástrojům a podřízené služby Azure.
Projektově spravovaná identita (projektová úroveň) Systém přiřazený k projektu Foundry Používá se platformou pro operace infrastruktury (například Container Registry Repository Reader na registru kontejneru). Ne identita modulu runtime agenta.

Při nasazení s azd je vyžadovaná role RBAC (Azure AI uživatel na úrovni účtu) automaticky přiřazena Microsoft Entra ID agenta. Pro externí prostředky (například vlastní Azure Storage) přiřadíte RBAC ručně k Microsoft Entra ID agenta.

Při integraci prostřednictvím kanálů Microsoft 365 (například Teams) mohou hostovaní agenti také pracovat s identitou uživatele prostřednictvím funkce zastoupení (OBO). Microsoft Entra ID agenta může vyměnit token uživatele za účelem volání podřízených služeb jako uživatele, a to v souladu se zásadami tenanta. 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 zajišťuje výpočet na vyžádání a obnovuje na něj přetrvávající stav.

  • Trvalost stavu: obsah $HOME a /files se zachovávají napříč sekvencemi a obdobími nečinnosti. Když výpočetní prostředky přejdou do nečinnosti a vrátí se (v nové nebo existující infrastruktuře), stav relace se automaticky obnoví.
  • Izolace: Každá relace je izolovaná od ostatních relací.
  • Automatický životní cyklus: Session se vytvoří při prvním použití. Platforma automaticky zřizuje a ruší výpočetní prostředky.
  • Životnost relace: Relace se uchovávají po dobu až 30 dnů. Časový limit nečinnosti je 15 minut – pokud během této doby nepřijde žádný požadavek, platforma uvolní výpočetní prostředky a zachová stav relace.
  • 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 a zpřístupnění těchto souborů výpočetním prostředkům konverzace.

Protokol vyvolání: ID relace je primární koncept. 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, aby ho zpřístupnil pro relaci. Neexistuje žádná historie konverzací spravovaná platformou – stav spravujete ve vlastním kódu.

Životní cyklus relace výpočetních prostředků

Státu Co se stane
Aktivní Výpočetní funkce je spuštěná. Požadavky se na ni směrují. obsah $HOME a /files jsou k dispozici.
Nečinnost Žádné požadavky po dobu 15 minut. Výpočetní prostředky jsou odinstalovány. Stav relace ($HOME, /files) je trvalý.
Obnoveno Na stejné ID relace se znovu odkazuje. Platforma zřizuje nové výpočetní prostředky a dochází k obnovení perzistentního stavu.

Zabezpečení a zpracování dat

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

Důležité

Pokud používáte Službu agenta Foundry k hostování agentů, kteří pracují s modely, servery nebo agenty třetích stran, provedete to na vlastní nebezpečí. Doporučujeme zkontrolovat všechna data sdílená s modely, servery nebo agenty třetích stran a porozumět postupům třetích stran pro uchovávání a umístění dat. Je vaší zodpovědností spravovat, zda vaše data přesahují rámec souladu s Azure a geografickými hranicemi vaší organizace a jaké to může mít související důsledky.

  • 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 agent volá nástroje, které nejsou služby Microsoft, můžou do těchto služeb proudit některá data. 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í při vytváření verze produkuje neměnnou verzi agenta – což je snímek image kontejneru, přidělení prostředků, proměnných prostředí a konfigurace protokolu. Tato nasazení odkazují 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. Můžete rozdělit provoz mezi verze s váženým uváděním do provozu pro podporu kanárských a modro-zelený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á.

Sada nástrojů Foundry

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 ve vašem projektu Foundry. Váš agentový kód se připojí k tomuto koncovému bodu pomocí standardních MCP klientských knihoven – platforma nevkládá nástroje automaticky. Podrobnosti najdete v části Spravujte sadu nástrojů založenou na záměru ve 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é agenty podporují přidělení procesoru a paměti v rozsahu od 0,25 vCPU / 0.5 GiB až 2 vCPU / 4 GiB.

Privátní sítě

Hostovaní agenti podporují nasazení v rámci prostředků Foundry izolovaných v síti. Další informace najdete v tématu Konfigurace virtuálních sítí. Mějte na paměti, že Azure Container Registry držící image agenta musí být momentálně dostupné přes jeho veřejný koncový bod. Služba ACR zabezpečená privátní sítí se v současné době nepodporuje.

Limity, ceny a dostupnost (Preview)

Hostovaní agenti jsou aktuálně ve verzi Preview.

Omezení ve verzi Preview

Omezení Scope Výchozí hodnota Nastavitelný
Maximální počet aktivních souběžných relací podle předplatného na oblast 50 Ano, s žádostmi o kvótu na podpora Microsoftu

Ceny

Fakturace spravovaného runtime hostingu je založena na využití 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
  • 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
  • Š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í, spuštění nebo přenos protokolů Správa hostovaných agentů
Nastavení trasování a monitorování Povolení trasování v projektu
Vyhodnocení výkonu agenta Vyhodnocovače agentů
Publikování do Teams, M365 nebo vlastních aplikací Aplikace agentů
Procházení ukázek kódu Python samples · C# samples

Související obsah

  • Last updated on