Valg af agent host

Når du evaluerer driftsmæssig kvalitet, pålidelighed og omkostninger, skal du overveje valget af agentvært, f.eks. Microsoft 365 Copilot (deklarative agenter), Copilot Studio (brugerdefinerede agenter) eller Azure. Hold denne beslutning adskilt fra agentforfattningsmetoden. Hvor en agent kører eller hostes, bestemmer dens orkestreringsmuligheder, modeladgang og driftsfunktioner. Disse funktioner påvirker svarkvaliteten, ydeevnen og omkostningerne ved at betjene løsningen i stor skala.

Denne artikel forklarer, hvordan agenthost-platforme påvirker løsningens kapacitet. Du lærer, hvordan forskellige oprettelsesmetoder kan oprette agenter på den samme værtsplatform, samtidig med at du bevarer ensartet kvalitet og funktionsmåde, hvordan en enkelt oprettelsesmetode kan oprette agenter på forskellige platforme med forskellige kvalitets- og adfærdsmæssige resultater, og hvordan værten former løsningens omkostningsprofil.

Omkostninger som en driftsmæssig overvejelse

Behandl omkostninger som en stabil driftsmæssig egenskab, ikke et engangskøbsspørgsmål. To løsninger kan give identiske svar, mens de varierer i størrelsesorden i omkostninger, fordi omkostningerne er drevet af , hvordan agenten kører, ikke kun hvad den returnerer. Værtsplatformen fastlægger i høj grad de muligheder, der er tilgængelige for dig:

• Tokenforbrug pr. interaktion. Hver instruktion, videnstykke og værktøjsdefinition, som modellen behandler på en given tur, faktureres på den pågældende tur. Stående kontekst, der indlæser hver interaktion, betales for hver interaktion, uanset om det er relevant eller ej.
• Antal modeldrejninger. Orchestratoren bestemmer, hvor mange gange modellen aktiveres for at fuldføre en opgave. Flere løkker med værktøjskald og mere omplanlægning betyder mere inferens.
• Modelvalg. Større ræsonneringsmodeller koster mere pr. token og tilføjer ventetid. Værten bestemmer, hvilke modeller der er tilgængelige, og om du kan dirigere forskellige trin til forskellige modeller.
• Determinisme. Arbejde, der er deterministisk, behøver slet ikke modelforudseelse. Hvis du flytter den til kode eller handlinger, fjernes både tokenomkostningen og variationen.

De efterfølgende afsnit opdeler de kontrolelementer, der påvirker omkostningerne mest: orkestreringssele, modelvalg, og hvordan du udformer instruktioner i forhold til deterministiske handlinger.

Microsoft 365 Copilot hosting-tjeneste

Microsoft 365 Copilot leverer et administreret hostingmiljø for deklarative agenter med indbyggede funktioner til styring, sikkerhed og overholdelse af angivne standarder. Denne platform tilbyder konsistente præstationskarakteristika uanset hvilken forfattermetode du bruger til at oprette agenten.

Du kan f.eks. oprette deklarative agenter ved hjælp af funktionen Agent Builder i Microsoft 365 Copilot, Copilot Studio eller Microsoft 365 Agents Toolkit. Agentværten bestemmer de muligheder for orkestrering, katalog og sprogmodel, som udvikleren har adgang til. Disse muligheder er de største indflydelsesfaktorer for responskvaliteten. Forfatter- og oprettelsesplatforme bør være det sekundære kriterium for en løsning i den operationelle stationære fase.

Forskellige forfatterplatforme tilbyder varierende niveauer af operationelle kapaciteter, der passer til forskellige organisatoriske behov og udviklingslivscyklusfaser. Så længe den underliggende agentvært forbliver Microsoft 365 Copilot (deklarative agenter), forbliver kvaliteten konsistent, når du gennemgår forskellige oprettelseslærreder for at opfylde dine driftsmæssige behov.

Følgende tabel opsummerer overvejelser for, hvilken forfatterplatform man skal bruge til deklarative agenter som et illustrativt eksempel.

Når en agent f.eks. bruger Arbejds-IQ til kontekst, hentning eller handlinger, faktureres dette forbrug variereligt, hvor kreditomkostningsskaleringen skaleres til scenariets kompleksitet, herunder kontekststørrelse, begrundelsesdybde og antal trin.

Overvej andre faktorer som udviklerløfte og fejlfindingsværktøjer (ikke vist i tabellen). Husk, at disse faktorer i høj grad påvirkes af din organisations sikkerhedsposition og dens kapacitet for en bestemt udviklingsplatform.

Hæv Microsoft 365 Copilot deklarative agenter, der er indbygget i Agent Builder, til en deklarativ agent, der er oprettet med Microsoft 365 Agents Toolkit. Denne strategi bevarer Microsoft 365 Copilot som orchestrator for at sikre ensartet agentfunktionsmåde. Hvis en eksperimentel brugerdefineret agent, der er indbygget i Copilot Studio, opfylder kriterierne for evaluering af koncepter, og der kræves kildekontrol til virksomhedshandlinger, skal du sende agenten til et administreret pipeline i Power Platform. Denne fremgangsmåde sikrer, at Copilot Studio Orchestrator forbliver den primære mekanisme til vedligeholdelse af agentens funktionsmåde.

Orkestrering og agentudnyttelse

Orchestratoren eller selen er den kørselsløkke, der planlægger trin, vælger og aktiverer værktøjer, administrerer kontekstvinduet og beslutter, hvornår en opgave er fuldført. Det er den største enkeltfaktor for både svarkvalitet og driftsomkostninger, fordi den styrer, hvor mange modeldrejninger der opstår, hvor meget kontekst der akkumuleres på hver tur, og hvordan værktøjsresultater føres tilbage til modellen.

Da værtsplatformen leverer orchestratoren, løser værtsbeslutningen stort set dine omkostninger og ventetidskonvolutten:

• Microsoft 365 Copilot leverer en administreret orchestrator. Du får forudsigelige, licens-inkluderede omkostninger og ensartet funktionsmåde med begrænset kontrol over selve løkken.
• Copilot Studio leverer konfigurerbar orkestrering (f.eks. emner og generativ orkestrering). Omkostningerne spænder fra licensbaseret til forbrugsbaseret afhængigt af, hvor meget generativt arbejde du uddelegerer til modellen.
• Azure og pro-kode giver dig fuld kontrol over løkken. Evaluer omkostningerne ved kodevedligeholdelse sammenlignet med at udnytte en velholdt sele eller SDK, f.eks. Copilot SDK.

Når værten fremviser dem, er nøgleorkestreringshåndtagene:

• Periodebudget Begræns eller juster, hvor mange planlægnings- og værktøjskaldsiterationer orkestratoren kan udføre, før den returnerer.
• Parallelle kontra sekventielle værktøjskald. Samtidig kørsel af uafhængige værktøjskald reducerer ventetiden. konsolidering af dem reducerer drejninger.
• Kontekststyring. Beskæring, opsummering eller opdeling af samtalen i vinduer forhindrer, at konteksten vokser ubegrænset, hvilket holder tokenomkostningen pr. interaktion stabil i stedet for at akkumulere.
• Cachelagring. Genbrug af cachelagrede prompt-præfikser på tværs af omgange eller sessioner undgår genfakturering for den stabile kontekst.

Modelvalg

Den model, du vælger, påvirker omkostningerne og ventetiden pr. token, og den er stort set uafhængig af oprettelsesmetoden. Større ræsonneringsmodeller giver resultater af højere kvalitet på komplekse opgaver, men koster mere pr. token og reagerer langsommere. Tilpas modellen til opgavevanskelighederne i stedet for at angive den mest kompatible indstilling for hver opgave.

Arkitekt til modeldistribution, når værten understøtter den:

• Reserve grænse ræsonnering modeller til virkelig hårde trin, såsom tvetydig ræsonnering, syntese, eller åben generation.
• Distribuer deterministiske eller enkle underopgaver , f.eks. klassificering, udtrækning, formatering og routingbeslutninger, til mindre, billigere og hurtigere modeller.
• Bland modeller i en enkelt agent , når orchestratoren understøtter valg af model pr. trin, så hvert trin kun betaler for den funktionalitet, det har brug for.

Værtsplatformen bestemmer, hvilke modeller der er i kataloget, om du kan distribuere pr. trin, det maksimale kontekstvindue (større vinduer tillader mere kontekst, men koster mere pr. tur), og om cachelagring er tilgængelig. Valider disse funktioner som en del af værtsbeslutningen, da de bestemmer, hvilken omkostningsoptimering på modelniveau du kan udføre senere.

Arkitektur til omkostningsoptimering

Ud over at vælge en vært, orkestrer og model har den måde, du strukturerer en agents instruktioner og handlinger på, en direkte, tilbagevendende omkostningsvirkning. To principper styrer omkostningseffektivt design:

1. Du skal ikke betale modelforudseelse for arbejde, der er deterministisk. Saml deterministiske handlinger i scripts, handlinger eller forbindelser i stedet for at beskrive dem som instruktioner i naturligt sprog, som modellen skal fortolke ved hver kørsel. Kode udføres én gang, billigt, med forudsigeligt output og ingen tokenomkostninger eller variabilitet. Ræsonnement gennem den samme procedure i naturligt sprog betaler inferens hver gang og risikerer inkonsekvente resultater.

2. Du skal ikke betale omkostninger for stående token for instruktioner, du sjældent bruger. Forudindlæste instruktioner på agentniveau faktureres på hver tur i hver interaktion, selv når de er irrelevante for brugerens anmodning. Indlæsning af vejledning og viden efter behov, kun når opgaven matcher, betyder, at du betaler for den kontekst, når den faktisk bruges, ikke løbende. Dette mønster for gradvis offentliggørelse holder de oprindelige omkostninger for hver interaktion lave.

I følgende tabel opsummeres, hvornår du skal forudindlæse instruktioner i agenten i forhold til, hvornår du skal pushe arbejde til deterministiske scripts eller ressourcer efter behov.

I praksis holder en omkostningseffektiv agent altid sine instruktioner minimale og fokuserer på identitet og sikkerhed, udtrykker faste procedurer som scripts eller handlinger og fremviser specialiseret viden og opgavespecifik vejledning som ressourcer efter behov, der kun indlæses, når det er relevant. Resultatet er lavere omkostninger pr. interaktionstoken, mere forudsigelig funktionsmåde og en mindre, nemmere at vedligeholde kerneprompt – uden at gå på kompromis med funktionaliteten.

Næste trin

Lær at måle agentens kvalitet, validere præstation på tværs af forskellige scenarier og sikre operationel beredskab før udrulning ved at bruge evalueringsrammer.