Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
Gäller för: Azure Logic Apps (Förbrukning + Standard)
Viktigt!
Funktionen för arbetsflöden för förbrukningsagenter är i förhandsversion och omfattas av de kompletterande användningsvillkoren för Förhandsversioner av Microsoft Azure.
Azure Logic Apps stöder arbetsflöden som slutför uppgifter med hjälp av agentloopar med stora språkmodeller (LLM). En agentloop använder en iterativ process för att lösa komplexa problem i flera steg. En LLM är ett tränat program som identifierar mönster och utför jobb utan mänsklig interaktion, till exempel:
- Analysera, tolka och resonera kring information, till exempel instruktioner, uppmaningar, indata och andra data.
- Fatta beslut baserat på resultat och tillgängliga data.
- Formulera och returnera svar tillbaka till promptern baserat på agentens instruktioner.
Du kan skapa arbetsflöden som använder autonoma eller konversationsagentslingor. Agentloopen använder naturligt språk för att kommunicera med dig och den anslutna modellen. Agenten använder också modellgenererade utdata för att utföra arbete med eller utan mänsklig interaktion. Modellen hjälper agentloopen att tillhandahålla följande funktioner:
- Acceptera information om agentens roll, hur du arbetar och hur du svarar.
- Ta emot och svara på instruktioner och begäranden eller frågor.
- Bearbeta indata, analysera data och göra val baserat på tillgänglig information.
- Välj verktyg för att slutföra de uppgifter som krävs för att uppfylla begäranden. Ett verktyg är i princip en sekvens med en eller flera åtgärder som slutför en uppgift.
- Anpassa dig till miljöer som kräver flexibilitet och är flytande, dynamiska, oförutsägbara eller instabila.
Med över 1 400 anslutningar som du kan använda för att skapa verktyg som en agentloop kan använda, stöder agentarbetsflöden en mängd olika scenarier som har stor nytta av agentloop och modellens kapaciteter. Baserat på ditt scenario skapar du antingen ett autonomt agentarbetsflöde utan mänsklig interaktion eller ett arbetsflöde för konversationsagenter med mänsklig interaktion för att bäst passa din lösnings behov.
Den här översikten beskriver följande områden:
- Arbetsflöden mellan agent och icke-agent
- Nyckelbegrepp för agentloop
- Arbetsflöden för autonom kontra konversationsagent
- Agentstruktur
- Exempelscenarier
- Autentisering och auktorisering
- Grundläggande faktureringsinformation
Arbetsflöden mellan agent och icke-agent
Arbetsflöden som använder agentslingor kan utvecklas utöver gränserna för icke-agentarbetsflöden. Agentarbetsflöden kan anpassas till miljöer där oväntade händelser inträffar, välja vilka verktyg som ska användas baserat på uppmaningar, indata och tillgängliga data, kontinuerligt förbättra deras prestanda, hantera ostrukturerade data, stödja komplexa scenarier och ge en högre nivå av anpassningsbarhet och flexibilitet. Arbetsflöden utan agent fungerar bäst i stabila miljöer, följer fördefinierade regler och utför uppgifter som är statiska, förutsägbara och repetitiva.
Följande tabell innehåller fler jämförelser mellan agentarbetsflöden och icke-agentarbetsflöden:
| Aspekt | Handläggare | Icke-agent |
|---|---|---|
| Logik | Gör välgrundade val om de uppgifter som ska utföras, baserat på indata och annan tillgänglig information, och vidta åtgärder. | Följ fördefinierade regler och fasta sekvenser. |
| Uppgiftshantering | Behandla uppgifter som separata entiteter | Ej tillämpligt |
| Datastruktur | Hantera och bearbeta ostrukturerade data. | Hantera och bearbeta strukturerade data med förutsägbara mönster. |
| Anpassningsförmåga | Identifiera och svara på föränderliga förhållanden och miljöer, fatta beslut och anpassa dig till nya indata i realtid. | Kan kämpa med miljöer som upplever oväntade eller dynamiska ändringar. |
Viktiga begrepp
Följande tabell innehåller grundläggande introduktioner till viktiga begrepp:
| Begrepp | Beskrivning |
|---|---|
| Agentloop | En fördefinierad åtgärd som använder en strukturerad iterativ process för att lösa komplexa problem i flera steg. Agentloopen åstadkommer det här målet genom att iterativt följa dessa steg: 1. Tänk: Samla in, bearbeta och analysera tillgänglig information och indata, till exempel text, bilder, ljud, sensordata och så vidare, från specifika datakällor. Använd orsaks-, logik- eller inlärningsmodeller för att förstå begäranden, skapa planer eller lösningar och välja den bästa åtgärden för att besvara eller uppfylla begäranden med hjälp av generativa AI-modeller. 2. Agera: Utifrån de val som gjorts och tillgängliga verktyg, slutför uppgifter i den digitala eller verkliga världen. 3. Learn (Valfritt): Anpassa sitt eget beteende över tid med hjälp av feedback eller annan information. En agent kan acceptera instruktioner, arbeta med tjänster, system, appar och data genom att anropa verktyg som du skapar med fördefinierade åtgärder i Azure Logic Apps och svara med resultaten. En agent kan bearbeta information, göra val och slutföra uppgifter med hjälp av en distribuerad modell, till exempel i Azure OpenAI Service. Obs! Ett agentarbetsflöde kan innehålla flera agenter i en sekvens. Du kan inte lägga till en agent direkt som ett verktyg i en annan agent. Mer information finns i Vad är en AI-agent? |
| Stor språkmodell (LLM) | Ett program tränat att identifiera mönster och utföra jobb utan mänsklig inblandning. Mer information finns i Vad är stora språkmodeller? |
| Verktyg | Ett verktyg innehåller en eller flera åtgärder som utför en uppgift för en agent. Ett verktyg kan till exempel skicka e-post, arbeta med datakällor, utföra beräkningar eller konverteringar, interagera med API:er och så vidare. Se till exempel Skapa verktyg för att hämta vädret. |
| Agentparameter | En parameter som du skapar på ett verktyg eller i en åtgärdsparameter, baserat på användningsfallet för agentparametern. Du skapar agentparametrar så att agenten kan skicka endast modellutdata som parameterindata för en åtgärd i ett verktyg. Du behöver inte agentparametrar för värden från källor utanför modellen. Agentparametrar skiljer sig från traditionella parametrar på följande sätt: – Agentparametrar gäller endast för det verktyg där du definierar dem. Den här begränsningen innebär att du inte kan dela agentparametrar med andra verktyg. Som jämförelse kan du dela traditionella parametrar globalt med drifts- och kontrollflödesstrukturer i ett arbetsflöde. – Agentparametrar använder inte lösta värden när arbetsflödet börjar köras. En agentparameter tar endast emot ett värde om agenten anropar verktyget med hjälp av specifika argument. Dessa argument blir agentparametrarna för att anropa verktyget. – En agent kan anropa samma verktyg flera gånger med olika agentparametervärden, även när verktyget finns i samma loop-iteration. Ett verktyg kan till exempel kontrollera vädret i både Seattle och London. Mer information finns i Skapa agentparametrar för åtgärden "Hämta prognos". |
| Kontext | En agent upprätthåller en logghistorik genom att behålla ett maximalt antal token eller meddelanden som kontext och skicka kontexten till modellen för nästa interaktion. Varje modell har olika begränsningar för kontextlängd . |
Arbetsflöden för autonom kontra konversationsagent
För att hjälpa dig att bättre förstå hur dessa agentarbetsflödestyper skiljer sig åt beskriver och visar följande avsnitt exempel för varje agentarbetsflödestyp. Båda arbetsflödestyperna använder en agentloop och verktyg för att hämta det aktuella vädret och skicka den informationen via e-post. Alla agenter har ett informationsfönster där du konfigurerar agenten med den modell du vill ha och ger instruktioner om agentens roller, dess funktioner och hur du svarar.
Arbetsflöde för autonom agent
Följande övergripande steg beskriver beteendet för ett grundläggande autonomt agentarbetsflöde:
Arbetsflödet börjar med alla tillgängliga utlösare som stöds.
Du kan också köra noll eller fler åtgärder mellan utlösaren och agenten.
Agenten accepterar systeminstruktioner och icke-mänskliga uppmaningar eller indata, till exempel utdata från utlösaren eller en föregående åtgärd.
Baserat på om du har ett arbetsflöde för förbrukning eller standardagent använder agenten en Azure OpenAI-modell eller LLM-API från följande källa för att tolka och förstå instruktionerna och begäran. Agenten använder också modellen för att bearbeta och analysera angivna indata.
Logik-app Modellkälla Consumption Microsoft Foundry Norm - Azure OpenAI Service-resurs
- Azure AI Foundry-projekt (förhandsversion)
- Azure API Management-konto med ett LLM-API (förhandsversion)Baserat på agentinstruktionerna hjälper modellen till att planera vilka verktyg som agenten behöver anropa för att utföra nödvändiga uppgifter.
Agenten returnerar verktygsresultatet och svarar på arbetsflödets anropare eller den angivna mottagaren.
Följande skärmbild visar ett grundläggande exempel på ett autonomt agentarbetsflöde:
Arbetsflöde för konversationsagent
Följande övergripande steg beskriver beteendet för ett grundläggande arbetsflöde för konversationsagenter:
Arbetsflödet börjar alltid med utlösaren med namnet När en chattsession startar.
Du kan också köra noll eller fler åtgärder mellan utlösaren och agenten.
Agenten accepterar systeminstruktioner och uppmaningar eller indata från människor via det integrerade chattgränssnittet, till exempel Vad är vädret i Seattle?
Baserat på om du har ett arbetsflöde för förbrukning eller standardagent använder agenten en Azure OpenAI-modell eller LLM-API från följande källa för att tolka och förstå instruktionerna och begäran. Agenten använder också modellen för att bearbeta och analysera angivna indata.
Logik-app Modellkälla Consumption Microsoft Foundry Norm - resurs för Azure OpenAI Service
- Azure API Management-konto med ett LLM-API (förhandsversion)Baserat på agentinstruktionerna hjälper modellen till att planera vilka verktyg som agenten anropar för nödvändiga uppgifter.
Agenten returnerar verktygets resultat och svarar via chattgränssnittet till den mänskliga promptern.
Följande skärmbild visar ett grundläggande exempel på konversationsagentarbetsflöde:
Följande skärmbild visar det integrerade chattgränssnittet som du kan komma åt från designerns verktygsfält eller menyn för arbetsflödets sidopanel i Azure-portalen:
Arbetsflöden för konversationsagenter stöder också en extern chattklient som andra kan använda utanför Azure-portalen. För att tillhandahålla och skydda åtkomsten för den här externa chattklienten måste du konfigurera produktionsautentisering och auktorisering.
Utforska agentarbetsflödesstruktur
Skapa ett nytt agentarbetsflöde genom att skapa en förbrukningslogikapp i Azure Logic Apps med flera klienter eller en standardlogikapp i Azure Logic Apps med en enda klientorganisation och välja någon av följande arbetsflödestyper:
- Autonoma agenter
- Konversationsagenter
Dessa arbetsflödestyper innehåller alla funktioner i förbruknings- eller standardtillståndskänsliga arbetsflöden och är utformade för att fungera specifikt med agentfunktioner. Dessa arbetsflödestyper innehåller automatiskt en tom agent.
Följande skärmbild visar till exempel ett nytt autonomt agentarbetsflöde:
Följande skärmbild visar ett nytt arbetsflöde för konversationsagent:
Om du har ett befintligt tillståndskänsligt arbetsflöde i Standard Logic Apps visar följande skärmbild hur du kan lägga till en agentåtgärd för att inkludera autonoma agent- och LLM-funktioner:
Medan arbetsflöden för förbrukningsagenten konfigureras automatiskt med en modell som ska användas, kräver standardagentarbetsflöden att du konfigurerar en anslutning till modellen som agenten ska använda:
Anmärkning
Anslutningsfönstret visar de olika anslutningskraven, baserat på din arbetsflödestyp och den valda modellkällan.
Agenten kräver att du anger instruktioner som beskriver de roller som agenten kan spela upp, uppgifter som agenten kan utföra och annan specifik normativ information som hjälper agenten att svara på frågor, svara på frågor och utföra begärda uppgifter, till exempel:
En tom agent som är ansluten till en modell kan svara på frågor som endast använder modellens funktioner, så att en agent inte behöver inkludera verktyg. Men för att agenten ska kunna använda åtgärder som är tillgängliga i Azure Logic Apps måste agenten skapa verktyg. Du kan börja skapa ett verktyg genom att först lägga till en åtgärd från anslutningsgalleriet.
Följande diagram visar galleriet där du kan bläddra bland och välja åtgärder för att skapa verktyg:
Följande diagram visar en väderagent som kan hämta väderprognosen och skicka prognosen via e-post:
Fler exempelscenarier
I följande avsnitt beskrivs några fler sätt som en agent kan utföra uppgifter i ett arbetsflöde:
Hypotekslåneagent
Tänk dig att din bank använder en låneagent som bearbetar lån självständigt eller med mänsklig inblandning vid behov genom att utföra följande uppgifter i en enda orkestrerad loop:
- Samtala med kunder för att besvara frågor.
- Granska låneansökningar.
- Samla in finansiell information för att bedöma låneberättigande.
- Hämta och analysera riskdata.
- Begär och sammanfatta fastighetsbedömningar när de skickas in.
- Inkludera mänskliga granskare för gränsfall.
- Godkänn eller avvisa ansökningar.
- Meddela beslut till relevanta parter.
Orderuppfyllelseagent
Anta att ditt företag använder en orderuppfyllelseagent för att utföra följande uppgifter:
- Kontakta kunderna för att besvara produktfrågor baserat på företagskunskaper.
- Skapa order men skicka dem vidare till människor när det behövs.
- Ge 24/7 stöd med intelligent eskalering.
Du kan också ha en agent som samordnar arbete mellan andra agenter. Du kan till exempel ha ett team med agenter, till exempel en författare, granskare och utgivare, som arbetar tillsammans för att skapa och distribuera försäljningsrapporter.
Agent för arbetsorder vid anläggningar
För att stödja ett internt anläggningsteam utför en arbetsorderagent följande uppgifter:
- Samtala med anställda och ange alternativ för tjänstbegäranden.
- Öppna arbetsorder baserat på val av medarbetare.
- Skicka arbetsorder till motsvarande tjänstteam.
- Uppdatera arbetsorder med jobbförlopp och status.
- Stäng arbetsorder när jobben är slutförda.
- Meddela lämpliga parter om slutförda jobb.
Autentisering och auktorisering
Icke-agentarbetsflöden interagerar vanligtvis med en liten, känd och förutsägbar uppsättning anropare. Konversationsagentarbetsflöden kommunicerar dock med ett bredare utbud av anropare, till exempel personer, agenter, MCP-servrar (Model Context Protocol), verktygskoordinatorer och externa tjänster. Den här bredare räckvidden ökar integreringsalternativen men medför olika säkerhetsutmaningar eftersom anropare kan komma från dynamiska, okända eller ej betrodda nätverk. När anropare kommer från nätverk som du inte kontrollerar, eller när identiteter är externa eller obundna identiteter, måste du autentisera och auktorisera varje anropare så att du kan skydda arbetsflöden för konversationsagenter eftersom de tillhandahåller en extern chattklient för att interagera med personer.
För icke-produktionsaktiviteter använder Azure-portalen en utvecklarnyckel för autentisering och auktorisering. Men när dina konversationsagentarbetsflöden är redo för produktion konfigurerar du motsvarande produktionsautentisering och auktorisering för din logikapptyp.
Autentisering och auktorisering av utvecklarnyckel
Endast för icke-produktionsaktiviteter, till exempel design, utveckling och snabb validering, tillhandahåller, hanterar och använder Azure-portalen en utvecklarnyckel för att köra arbetsflödet åt dig.
Vad är en utvecklarnyckel?
En utvecklarnyckel är en mekanism för bekvämlighetsautentisering som endast används av Azure-portalen för att köra arbetsflödet under design-, utvecklings- och snabbtestningsstegen i Azure-portalen. Under de här stegen kan du med utvecklarnyckeln hoppa över behovet av att manuellt konfigurera URL:er för enkel autentisering eller kopiera utlösaråteranrop med signaturer för delad åtkomst (SAS). Nyckeln är länkad till en specifik användare och klientorganisation baserat endast på en Azure Resource Manager-ägartoken, vilket är en åtkomsttoken som autentiserar begäranden till Azure Resource Manager REST API.
Portalen matar automatiskt in utvecklarnyckeln när du använder inbyggda testupplevelser i arbetsflödesdesignern, till exempel när du kör ett arbetsflöde, anropar utlösaren för begäran eller interagerar med ett arbetsflöde för konversationsagenter i det interna chattgränssnittet. Nyckeln är implicit bunden till en klientsession och en inloggad portalanvändare, så du kan inte distribuera nyckeln externt på grund av den här bindningen, som endast baseras på ARM-ägartoken.
Viktiga begränsningar för utvecklare
I följande lista beskrivs utvecklarnyckelns användnings- och designbegränsningar:
- Nyckeln ersätter inte Easy Auth, hanterad identitet, federerade autentiseringsuppgifter eller signerade url:er för återanrop i produktionsscenarier.
- Nyckeln är inte utformad för stora eller icke-betrodda användarpopulationer, agentverktyg eller automationsklienter.
- Nyckeln är inte en auktoriseringsmekanism per användare på grund av brist på detaljerade omfång och roller.
- Nyckeln styrs inte av principer för villkorsstyrd åtkomst vid utförande av begäranser, endast på portalens inloggningsnivå.
- Nyckeln är inte avsedd för programmatisk användning eller CI/CD-användning.
En jämförelse mellan utvecklarnyckel och Enkel autentisering finns i Enkel autentisering kontra utvecklarnyckel.
Användningsfall för utvecklarnycklar
I följande tabell beskrivs lämpliga och olämpliga scenarier för att använda utvecklarnyckeln:
| Lämpliga scenarier | Olämpliga scenarier |
|---|---|
| Snabbtestning i designern innan du formaliserar autentisering. | Arbetsflödet behöver deterministisk automatisering som använder tjänstens huvudnamn och Easy Auth eller signerad SAS i stället. |
| Kontrollera arbetsflödesstruktur, bindningar eller grundläggande utlösare och åtgärdsbeteende. | – Dina anropare i arbetsflödet inkluderar externa agenter, MCP-servrar eller konversationsklienter. – Du planerar att publicera arbetsflödets slutpunkt utanför din hyresgäst. |
| Tillfälliga sandbox- eller spike-prototyper som senare använder Easy Auth- eller SAS-URL-härdning. | Arbetsflödet kräver granskningsbara identiteter per användare, tokenåterkallning, principer för villkorsstyrd åtkomst eller tillämpning av lägsta behörighet. |
Produktionsautentisering och -auktorisering
När dina konversationsagentarbetsflöden är klara för produktion beskriver följande avsnitt alternativ för icke-produktion och produktion för att autentisera anropare och auktorisera deras åtkomst till agentarbetsflöden.
| Logik-app | Autentisering och auktorisering |
|---|---|
| Consumption | OAuth 2.0 med Microsoft Entra-ID |
| Norm | Enkel autentisering, även kallad App Service-autentisering, på din logikappresurs aktiverar en extern chattklient utanför Azure-portalen som andra kan använda när du har konfigurerat Easy Auth. Se Easy Auth för logikappen. |
Mer information om produktionsautentisering och -auktorisering finns på fliken för din logikapptyp.
OAuth 2.0 med Microsoft Entra-ID för din logikapp
För konsumtionsrelaterade arbetsflöden av konversationsagenter i produktion skyddar du åtkomsten till din chattklient med OAuth 2.0 med Microsoft Entra-ID genom att konfigurera en auktoriseringspolicy för agenter på din logikappresurs. Se Migrering till produktionsautentisering.
Fakturering
Förbrukning: Faktureringen använder modellen betalning per användning. Prissättningen för agentloopen baseras på antalet tokens som varje agentåtgärd använder och visas som Företagsenheter på din faktura. Specifik prisinformation finns i Prissättning för Azure Logic Apps.
Standard: Även om agentarbetsflöden inte medför extra avgifter debiteras användning av AI-modell. Mer information finns i Priskalkylatorn för Azure.