Valg av agentvert

Når du evaluerer driftskvalitet, pålitelighet og kostnader, bør du vurdere valget av agentvert, for eksempel Microsoft 365 Copilot (deklarative agenter), Copilot Studio (egendefinerte agenter) eller Azure. Hold denne avgjørelsen adskilt fra prosessen med agentforfatting. Hvor en agent kjører eller hostes, avgjør dens orkestreringsevner, modelltilgang og driftsfunksjoner. Disse funksjonene påvirker svarkvaliteten, ytelsen og kostnadene for å betjene løsningen i stor skala.

Denne artikkelen forklarer hvordan agentvertsplattformer påvirker løsningens kapasitet. Du lærer hvordan ulike redigeringsmetoder kan opprette agenter på samme vertsplattform samtidig som du opprettholder konsekvent kvalitet og virkemåte, hvordan én enkelt redigeringsmetode kan opprette agenter på forskjellige plattformer med ulike kvalitets- og atferdsresultater, og hvordan verten former kostnadsprofilen til løsningen.

Kostnad som en vurdering av anvendelighet

Behandle kostnader som en driftskarakteristikk med jevn tilstand, ikke et engangsanskaffelsespørsmål. To løsninger kan gi identiske svar mens de varierer etter en størrelsesorden i kostnader, fordi kostnaden drives av hvordan agenten kjører, ikke bare hva den returnerer. Vertsplattformen løser i stor grad spakene som er tilgjengelige for deg:

• Tokenforbruk per samhandling. Hver instruksjon, kunnskapssnutt og verktøydefinisjon som modellen behandler på en gitt sving, faktureres på denne svingen. Stående kontekst som lastes inn på hver samhandling, betales på hver samhandling, uansett om den er relevant eller ikke.
• Antall modellrunder. Orchestrator bestemmer hvor mange ganger modellen aktiveres for å fullføre en oppgave. Flere løkker for verktøyanrop og mer omplanlegging betyr mer slutning.
• Modellvalg. Større resonneringsmodeller koster mer per token og legger til ventetid. Verten bestemmer hvilke modeller som er tilgjengelige, og om du kan rute forskjellige trinn til forskjellige modeller.
• Determinisme. Arbeid som er deterministisk, trenger ikke modellslutning i det hele tatt. Hvis du flytter den til kode eller handlinger, fjernes både tokenkostnaden og variasjonen.

Inndelingene som følger, bryter ned kontrollene som mest påvirker kostnadene: orkestreringssele, modellvalg og hvordan du arkitektinstruksjoner kontra deterministiske handlinger.

Microsoft 365 Copilot-drift

Microsoft 365 Copilot gir et administrert vertsmiljø for deklarative agenter med innebygde styrings-, sikkerhets- og samsvarsfunksjoner. Denne plattformen tilbyr konsistente ytelsesegenskaper uavhengig av hvilken forfattermetode du bruker for å lage agenten.

Du kan for eksempel redigere deklarative agenter ved hjelp av funksjonen Agent Builder i Microsoft 365 Copilot, Copilot Studio eller Microsoft 365 Agents Toolkit. Agentverten bestemmer alternativene for orkestrering, katalog og språkmodeller som er tilgjengelige for utvikleren. Disse alternativene er de største faktorene for responskvalitet. Forfatter- og opprettelsesplattformer bør være det sekundære kriteriet for en løsning i den operative steady state-fasen.

Ulike forfatterplattformer tilbyr varierende nivåer av operasjonelle kapasiteter tilpasset ulike organisatoriske behov og utviklingslivssykluser. Så lenge den underliggende agentverten forblir Microsoft 365 Copilot (deklarative agenter), forblir kvaliteten konsekvent etter hvert som du går gjennom forskjellige redigeringslerreter for å møte dine driftsbehov.

Tabellen nedenfor oppsummerer vurderinger for hvilken forfatterplattform man bør bruke for deklarative agenter som et illustrativt eksempel.

Når en agent for eksempel trekker på Arbeids-IQ for kontekst, henting eller handlinger, faktureres denne bruken variably, med kredittkostnadsskaleringen til kompleksiteten i scenarioet, inkludert kontekststørrelse, resonneringsdybde og antall trinn.

Vurder andre faktorer som utviklerløft og feilsøkingsverktøy (ikke vist i tabellen). Husk at disse faktorene i stor grad påvirkes av organisasjonens sikkerhetsnivå og dens kapasitet for en bestemt utviklingsplattform.

Hev Microsoft 365 Copilot deklarative agenter bygget i Agent Builder til en deklarativ agent forfattet med Microsoft 365 Agents Toolkit. Denne strategien opprettholder Microsoft 365 Copilot som orchestrator for å sikre konsekvent agentatferd. Hvis en eksperimentell egendefinert agent som er innebygd i Copilot Studio oppfyller beviset på konseptevalueringskriterier og kildekontroll kreves for virksomhetsoperasjoner, bør du forfremme agenten til en administrert pipeline i Power Platform. Denne fremgangsmåten sikrer at Copilot Studio Orchestrator forblir den primære mekanismen for å opprettholde agentatferd.

Orkestrering og agentrammeverk

Orchestratoren, eller selen, er kjøretidsløkken som planlegger trinn, velger og aktiverer verktøy, administrerer kontekstvinduet og bestemmer når en oppgave er fullført. Det er den største enkeltdriveren for både responskvalitet og driftskostnader, fordi den styrer hvor mange modellsvinger som forekommer, hvor mye kontekst som akkumuleres på hver sving, og hvordan verktøyresultatene mates tilbake til modellen.

Fordi vertsplattformen leverer orchestratoren, løser vertsbeslutningen i stor grad kostnads- og ventetidskonvolutten:

• Microsoft 365 Copilot gir en administrert orchestrator. Du får forutsigbar, lisensinvertert kostnad og konsekvent atferd, med begrenset kontroll over selve løkken.
• Copilot Studio gir konfigurerbar orkestrering (for eksempel emner og generativ orkestrering). Kostnadsområder fra lisensbasert til forbruksbasert avhengig av hvor mye generativt arbeid du delegerer til modellen.
• Azure og pro-code gir deg full kontroll over løkken. Evaluer kostnaden for vedlikehold av kode sammenlignet med å utnytte en godt vedlikeholdt sele eller SDK som Copilot SDK.

Når verten eksponerer dem, er de viktigste orkestreringsspakene:

• Snu budsjettet. Begrens eller juster antallet planleggings- og verktøyanropsvisninger orchestratoren tar før du returnerer.
• Parallelle kontra sekvensielle verktøykall. Kjør uavhengige verktøykall samtidig for å redusere ventetiden. Konsolider anrop når det er mulig for å redusere antall utvekslinger.
• Kontekstbehandling. Beskjær, oppsummer eller avgrens samtalen til et vindu for å hindre at konteksten vokser uten grenser, noe som holder tokenkostnaden per tur konstant i stedet for at den øker kumulativt.
• Hurtigbufring. Gjenbruk hurtiglagrede promptprefikser på tvers av samtaleomganger eller økter for å unngå ny fakturering for stabil kontekst.

Modellvalg

Modellen du velger, påvirker kostnaden per token og ventetid, og den er i stor grad uavhengig av redigeringsmetoden. Større resonneringsmodeller gir resultater av høyere kvalitet på komplekse oppgaver, men koster mer per token og reagerer saktere. Samsvar modellen med oppgavevansker i stedet for å bruke det mest kapable alternativet for hver oppgave.

Arkitekt for modellruting når verten støtter det:

• Reserver modeller for grenser for virkelig harde trinn, for eksempel tvetydig resonnement, syntese eller åpen generasjon.
• Send deterministiske eller enkle deloppgaver, som klassifisering, ekstrahering, formatering og rutebeslutninger, til mindre, billigere og raskere modeller.
• Bland modeller i én enkelt agent når orchestratoren støtter modellvalg per trinn, slik at hvert trinn bare betaler for den funksjonaliteten den trenger.

Vertsplattformen bestemmer hvilke modeller som er i katalogen, om du kan rute per trinn, det maksimale kontekstvinduet (større vinduer tillater mer kontekst, men koster mer per sving), og om hurtigbufring av ledetekst er tilgjengelig. Valider disse funksjonene som en del av vertsbeslutningen, fordi de angir hvilken kostnadsoptimalisering på modellnivå du kan utføre senere.

Arkitekt for kostnadsoptimalisering

Utover å velge en vert, orchestrator og modell, har hvordan du strukturerer en agents instruksjoner og handlinger en direkte, regelmessig kostnadsinnvirkning. To prinsipper veileder kostnadseffektiv utforming:

1. Ikke betal modellslutning for arbeid som er deterministisk. Samle deterministiske handlinger i skript, handlinger eller koblinger i stedet for å beskrive dem som instruksjoner for naturlig språk som modellen må tolke på hver kjøring. Koden kjøres én gang, billig, med forutsigbare utdata, ingen tokenkostnader og mindre variasjon. Bruk av naturlig språk for samme prosedyre koster slutning hver gang og kan gi inkonsekvente resultater.

2. Ikke betal stående tokenkostnad for instruksjoner du sjelden bruker. Forhåndslastede instruksjoner på agentnivå faktureres ved hver sving av hver samhandling, selv når de er irrelevante for brukerens forespørsel. Innlasting av veiledning og kunnskap ved behov, bare når oppgaven samsvarer, betyr at du betaler for den konteksten når den faktisk brukes, ikke kontinuerlig. Dette mønsteret for progressiv fremlegging holder opprinnelige kostnader for hver samhandling lav.

Tabellen nedenfor oppsummerer når du skal forhåndslaste instruksjoner til agenten kontra når du skal sende arbeid til deterministiske skript eller behovsbetingede ressurser.

En kostnadseffektiv agent holder instruksjonene som alltid er aktive, på et minimum og med fokus på identitet og sikkerhet. Den håndterer faste prosedyrer som skript eller handlinger, og gir spesialisert kunnskap og oppgavespesifikk veiledning som behovsbetingede ressurser som bare lastes inn når det er relevant. Denne tilnærmingen reduserer tokenkostnaden for hver samhandling, gjør virkemåten mer forutsigbar og holder kjerneledeteksten mindre og enklere å vedlikeholde uten å ofre funksjonaliteten.

Neste trinn:

Lær hvordan du kan måle agentkvalitet, validere ytelse på tvers av ulike scenarioer, og sikre operasjonell beredskap før utrulling ved å bruke evalueringsrammeverk.