Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för: Azure Logic Apps (Förbrukning + Standard)
Viktigt!
Funktionen för agentiska arbetsflöden för förbrukning är i förhandsversion och omfattas av de kompletterande användningsvillkoren för Förhandsversioner av Microsoft Azure.
Den här artikeln behandlar AI-agentiska arbetsflöden som automatiserar förutsägbara och stabila affärsprocesser. För oförutsägbara eller svårdefinierade processer, se Azure Logic Apps Automation.
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 kontakter som du kan använda för att bygga verktyg för en agentslinga att använda, stöder agentsdrivna arbetsflöden en mängd olika scenarier som drar stor nytta av agentslinga och modellens kapabiliteter. Baserat på ditt scenario skapar du antingen ett autonomt agentiskt arbetsflöde utan mänsklig interaktion eller ett konversationsagentiskt arbetsflöde med mänsklig interaktion för att bäst passa din lösnings behov.
Den här översikten beskriver följande områden:
- Agentiska kontra icke-agentiska arbetsflöden
- Agentloop-nyckelkoncept
- Autonoma kontra konversationsbaserade agentiska arbetsflöden
- Agentstruktur
- Exempelscenarier
- Autentisering och auktorisering
- Grundläggande faktureringsinformation
Redo att bygga nu? Gå direkt till:
Agentiska kontra icke-agentiska arbetsflöden
Arbetsflöden som använder agentloopar kan utvecklas bortom de begränsningar som gäller för icke-agentiska arbetsflöden:
Agentiska arbetsflöden kan anpassa sig till miljöer där oväntade händelser inträffar, välja verktyg baserat på prompts och tillgänglig data, hantera ostrukturerad data, erbjuda större anpassningsbarhet och flexibilitet, kontinuerligt förbättra sin prestanda och stödja komplexa scenarier.
Icke-agentiska arbetsflöden fungerar bäst i stabila miljöer, följer fördefinierade regler och utför statiska, förutsägbara och repetitiva uppgifter.
Följande tabell innehåller fler jämförelser mellan agentiska arbetsflöden och icke-agentiska arbetsflö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 avsnitt introducerar de viktigaste begreppen. För en praktisk genomgång av dessa koncept, se:
| 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 agentiskt arbetsflö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 definierar i ett verktyg eller i en åtgärdsparameter så att agenten kan skicka modellbaserade utdata som indata för en åtgärd i det verktyget. Agentparametrar är begränsade till ett verktyg, tar emot värden endast när agenten anropar verktyget och kan ta olika värden varje gång agenten anropar samma verktyg. För detaljer och exempel, se Create agent parameters. |
| 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 . |
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 upplö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 loopiteration. Ett verktyg kan till exempel kontrollera vädret i både Seattle och London.
Autonoma kontra konversationsagentiska arbetsflöden
För att hjälpa dig att bättre förstå hur dessa agentiska arbetsflödestyper skiljer sig åt beskriver och visar följande avsnitt exempel för varje agentisk arbetsflö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.
Autonomt agentiskt arbetsflöde
Följande övergripande steg beskriver beteendet för ett grundläggande autonomt agentiskt arbetsflö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 promptar eller indata, såsom utdata från triggern eller en föregående åtgärd.
Agenten använder en Azure OpenAI-modell eller LLM-API från följande källa för att tolka och förstå instruktionerna och begäran, beroende på om du använder ett Consumption- eller Standard-agentiskt arbetsflöde. Agentloopen använder också modellen för att bearbeta och analysera de tillhandahållna indatana.
Logik-app Modellkälla Consumption Microsoft Foundry Norm - Azure OpenAI Service-resurs
- Microsoft Foundry-projekt (förhandsversion)
- Azure API Management-konto med ett LLM-API (förhandsversion)Modellen hjälper till att planera vilka verktyg agenten behöver använda för att utföra de nödvändiga uppgifterna, baserat på agentens instruktioner.
Agenten returnerar verktygsresultatet och svarar på arbetsflödets anropare eller den angivna mottagaren.
Följande skärmbild visar ett grundläggande exempel på autonomt agentiskt arbetsflöde:
Konversationsagentiskt arbetsflöde
Följande övergripande steg beskriver beteendet för ett grundläggande konversationsagentiskt arbetsflöde:
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?
Agenten använder en Azure OpenAI-modell eller LLM-API från följande källa för att tolka och förstå instruktionerna och begäran, beroende på om du använder ett Consumption- eller Standard-agentiskt arbetsflöde. Agentloopen använder också modellen för att bearbeta och analysera de tillhandahållna indatana.
Logik-app Modellkälla Consumption Microsoft Foundry Norm - Azure OpenAI Service-resurs
- 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å ett konversationsagentiskt arbetsflö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:
Konversationsagentiska arbetsflöden 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.
Agentisk arbetsflödesstruktur
Skapa ett nytt agentdrivet arbetsflöde genom att skapa en konsumtionslogikapp i Azure Logic Apps med flera klienter eller en standardlogikapp i Azure Logic Apps med en enskild hyresgäst och sedan 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 agentiskt arbetsflöde:
Följande skärmbild visar ett nytt konversationsagentiskt arbetsflöde:
För att bygga ett av dessa arbetsflöden steg för steg, se:
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:
Även om förbrukningsagentiska arbetsflöden 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 exempel på agentiska arbetsflödesscenarier
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 jobbets framsteg och status.
- Stäng arbetsorder när jobben är slutförda.
- Meddela lämpliga parter om slutförda jobb.
Autentisering och auktorisering
Samtalsbaserade agentiska arbetsflöden kommunicerar med ett brett spektrum av uppringare, såsom personer, agenter, Model Context Protocol (MCP)-servrar, verktygsmäklare och externa tjänster. Dessa uppringare kan komma från dynamiska, okända eller opålitliga nätverk, så du måste autentisera och auktorisera varje uppringare.
Välj det alternativ som passar det skede du befinner dig i:
- Design och testning: Azure-portalen använder en utvecklarnyckel för autentisering och auktorisation åt dig.
- Produktion: Ställ in produktionsautentisering och auktorisation 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 konversationsagentiskt arbetsflöde 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 konversationsagentiska arbetsflöden är redo för produktion beskriver följande avsnitt alternativ för icke-produktion och produktion för att autentisera anropare och auktorisera deras åtkomst till agentiska arbetsflö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 förbrukningskonversationsagentarbetsflöden i produktion skyddar du åtkomsten till din chattklient med OAuth 2.0 med Microsoft Entra ID genom att ställa in en agentauktoriseringsprincip 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 agentiska arbetsflöden inte medför extra avgifter medför AI-modellanvändning avgifter. Mer information finns i Priskalkylatorn för Azure.