|
Mål |
Spør deg selv, «Hvilket resultat prøver jeg å oppnå?Ikke: «Hvilke verktøy trenger jeg?», «Hvilke koblinger bør jeg bruke?», eller «Hvilket emne skal jeg bygge?»
Beskriv tydelig hvorfor agenten skal eksistere, hva den skal oppnå, og hvem målgruppen er. Fokuser på resultater. La agentens utforming følge av problemet.
Klargjør:- Problemet eller verdigapet
- Målbrukere
- Den forventede effekten
- Hva som kjennetegner suksess
Bruk Jobs-To-Be-Done-formatet:
-
Som< bruker>
-
Jeg trenger at jobben<blir gjort>
-
Slik at<resultatet>
|
-
Som nyansatt må jeg forstå mine lokale HR-retningslinjer slik at jeg trygt kan navigere onboarding.
-
Som IT-supportleder trenger jeg å behandle supporteposter automatisk slik at manuell triage reduseres.
|
- Å starte med funksjoner i stedet for resultater.
- Utforming for kanttilfeller.
- Unnlater å inkludere målbare suksesskriterier.
|
|
Utløsere |
En agentutløser er den spesifikke hendelsen, betingelsen eller inndataen som signaliserer at agenten skal starte sitt arbeid eller oppgave. En menneskelig handling eller en automatisert hendelse kan utløse utløseren.
Finn ut mer: Finn utløseren som passer til hendelsen din. |
- En brukermelding i nettprat
- En ny e-post i en delt innboks.
- En ny post i et system.
- En planlagt eller tilbakevendende jobb.
|
- Autonome agenter krever eksplisitte triggere. Uten dem kjøres ikke agenten.
- Trigger avhenger av uforutsigbar brukeratferd, f.eks. at brukeren skriver inn et spesifikt nøkkelord eller frase.
- Triggeren mangler nødvendig kontekst, f.eks. at agenten starter, men ikke har nok metadata (post-ID, brukeridentitet) til å handle effektivt.
- Triggere aktiveres oftere enn nødvendig for scenarioet, noe som fører til unødvendige kjøringer og økt ressursforbruk.
- Triggerdesign tar ikke hensyn til plattformkvoter eller -begrensninger, noe som gjør at agenter når bruksterskler eller feiler under belastning.
|
|
Verktøy og integreringer |
Definer hvilke handlinger agenten må kunne utføre, ikke bare hva den vet.
Verktøy gjør det mulig for agenten å hente eller oppdatere data, kalle API-er, utløse arbeidsflyter, sende meldinger og fullføre transaksjonsoperasjoner. Angi systemene agenten er avhengig av og deres begrensninger (API-er, autentiseringsmodeller, hastighetsgrenser og eierskap/SLA-grenser).
Vurder forventede resultater, suksess- og kvalitetskriterier, fallback og feiloppførsel. Avhengigheter har ofte stor betydning for gjennomførbarheten—adresser dem tidlig.
Mer informasjon: Mekanismer for å legge til verktøy til agenter. |
- ServiceNow-kobling → få billettdetaljer
- Microsoft Entra ID-kontakt → hente brukerposisjon
- JIRA API → oppdater arbeidselementer
- Outlook Connector → svar på e-post
|
- Manglende logging av handlinger eller lagring av utdata for revisjon.
- Antar at API-ene er stabile og alltid tilgjengelige.
- Over-tillatelse av verktøy.
- Definerer ikke verktøykall-fallback-atferd (ingen validering av verktøyets utdata, ingen fallback når verktøy feiler, ingen eskaleringsvei).
- Manglende hensyn til hastighetsgrenser eller throttling.
- Manglende avhengighetskartlegging (hvem eier hvert API, hva er tjenestenivåavtalen).
- Å ikke validere forutsetninger før man utfører handlinger.
|
|
Kanaler |
En kanal er den spesifikke plattformen eller grensesnittet hvor agenten din er utplassert og samhandler med brukerne.
Kanalen bidrar også til å forme brukerforventninger rundt ventetid, turtaking og brukeropplevelse. |
- Microsoft Teams
- SharePoint
- Microsoft 365 Copilot
- Nettprat eller talebaserte grensesnitt
|
- Å velge kanaler basert på praktiske hensyn eller enkel implementering, snarere enn hvordan og hvor brukerne faktisk jobber.
- Å anta at brukerne tilpasser seg agentens kanal, i stedet for å møte brukerne der de allerede er.
- Å prioritere teknisk gjennomførbarhet over brukeropplevelse, noe som resulterer i lav adopsjon selv når agenten fungerer riktig.
- Å designe «nettprat-først» når den egentlige kanalen er e-post- eller arbeidsflytdrevet (utvikle en samtaleorientert brukeropplevelse når støtte faktisk skjer via Outlook; glemme at e-post er turbasert, ikke samtalebasert)
- Å overse kanalspesifikke begrensninger (Outlook krever komplette svar, ikke oppklarende spørsmål; Teams støtter Dynamiske kort, men e-post gjør ikke det)
|
|
Kunnskap og data |
Dokumentér informasjonen agenten trenger å resonnere over, og stedet hvor kunnskapen eller dataene er tilgjengelig nå. Vurder datakvalitet og ferskhet, strukturert versus ustrukturert innhold, og tilgangs- og tillatelsesgrenser.
Dataklarhet er en av de vanligste kildene til hindringer i sene faser hvis det ikke adresseres tidlig. |
- Bilag
- Databaser
- Nettsteder
- Kunnskapsbase
- Interne eller eksterne systemer
|
- Dårlig eller inkonsekvent datastyring. Når eierskap, oppdateringsfrekvens og oppdateringsprosesser ikke er definert, blir data raskt utdatert eller motstridende.
- Forveksler «dokumenter» med «kunnskap». Å peke på store dokumentarkiver som en sannhetskilde uten å vurdere om disse dokumentene er oppdaterte, godt strukturerte eller konsekvent merket.
- Kunnskapskilder er i motstrid med hverandre. Flere versjoner av en retningslinje, prosedyre eller datasett fører til at agenten får motstridende instruksjoner.
- Tillatelser og tilgangskontroller er ikke eksplisitt utformet. Sensitivt innhold avsløres utilsiktet, eller agenten viser til kunnskap som sluttbrukerne ikke har tilgang til.
- Å utvide kunnskapskilder uten å validere sikkerhetsbarrierer, noe som resulterer i at agenter enten deler for mye eller feiler når tilgangen er begrenset.
|
|
Flyter og Iverksetting |
Definer hvordan arbeidet organiseres og sekvenseres i agenten: når det skal brukes deterministiske flyter eller emner, når man skal benytte orkestrering, og når menneskelig involvering er nødvendig. Målet er forutsigbar atferd, sikker automatisering og tydelig eskalering.
Når man bør bruke flyter eller emner:- Flertrinns datainnsamling
- Veiledet feilsøking eller beslutningstrær
- Etterlevelses- eller retningslinjedrevne prosesser
- Høyvirknings- eller irreversible handlinger
Emner er den primære mekanismen for deterministisk logikk.
Definere:- Hva agenten kan gjøre autonomt
- Hva som krever menneskelig godkjenning, gjennomgang eller overstyring
- Når agenten må eskalere eller utsette
- Hvordan menneskelig tilbakemelding flyter tilbake til forbedring
|
- Ask-Me-Anything-agent: Minimale deterministiske flyter; bygger hovedsakelig på orkestrering og generativ resonnement.
- Autonom agent: Bruker flyter eller emner for å håndheve sekvensering, valideringer og rekkverk for kritiske trinn.
- Godkjenningsarbeidsflyter: Agenten forbereder kontekst og anbefalinger; Mennesker godkjenner eller overstyrer handlinger med stor innvirkning.
|
- Overstrukturering av arbeidsflyter, begrense fleksibilitet, og at agenten oppleves rigid eller skjør.
- For lite strukturering av arbeidsflyter, reduserer påliteligheten og gjør utfallene uforutsigbare.
- Manglende eksplisitt bruk av emner for deterministisk logikk, noe som fører til ad hoc- eller inkonsekvent atferd.
- Utydelig ansvarsfordeling mellom mennesker og agent, noe som fører til uklare eskaleringsveier.
- Overbelaste mennesker med godkjenninger for lavrisikotiltak, skape flaskehalser og motvirke bruk av midler.
- Agenter som handler uten tydelige "ikke handle"-grenser, spesielt i grensetilfeller eller høyrisikoscenarioer.
|
|
Instruksjoner og virkemåte |
Instruksjoner definer:- Agentens primære rolle og ansvar
- Hvordan den resonnerer og reagerer
- Når og hvordan den bør bruke kunnskap, verktøy eller andre agenter
- Rekkefølgen av handlinger den bør følge
- Tone, grenser og sikkerhetsregler
Klare instruksjoner kobler kunnskap, verktøy og arbeidsflyter sammen til et sammenhengende og forutsigbart system.
Lær mer: Konfigurer høykvalitetsinstruksjoner for generativ iverksetting og Skriv effektive instruksjoner for deklarative agenter. |
- Rolle og omfang: «Du er IT Email Support Agent og har ansvar for å lese innkommende postboksmeldinger, hente ut saksnumre og svare med validert informasjon fra ServiceNow.»
- Sekvens: "Trinn 1: Sjekk kunnskapsbasen for en eksisterende retningslinje eller et kjent problem." Trinn 2: Hvis informasjonen ikke blir funnet eller er ufullstendig, kall ServiceNow-verktøyet for å hente ut saksdetaljene. Trinn 3: Hvis nødvendige data fortsatt mangler, svar med et 'jeg vet ikke'-mønster og send saken videre.
- Verktøybruksregler: "Valider alltid uttrukne ID-er med et verktøykall før du bruker dem i svar."
- Feilhåndtering: «Hvis kunnskap mangler eller et verktøykall mislykkes, unngå å gjette.» Svar med en tydelig begrensning og neste trinn.
|
- Instruksjonene er for vage. F.eks., "Hjelp brukere med supportproblemer" spesifiserer ikke domene, grenser eller tillatte handlinger.
- Ingen klarhet i når kunnskap skal brukes, verktøy versus andre agenter, noe som fører til inkonsekvent eller ineffektiv atferd.
- Instruksjonene angir ikke rekkefølgen på handlingene, noe som får agenten til å blande kunnskaps- og verktøyresultater på uforutsigbare måter.
- Verktøybruksregler er ikke eksplisitt definert, noe som kan føre til at verktøy blir kalt unødvendig eller ikke i det hele tatt, eller at kunnskap og verktøyresultater blandes på uventede måter.
- Motstridende instruksjoner, som «still alltid oppklarende spørsmål» og «svar kun med endelige svar.»
- Ingen eksplisitt veiledning om hva som ikke er tillatt, for eksempel å endre sensitiv informasjon, dele interne identifikatorer eller gi juridisk eller HR-rådgivning uten verifiserte kilder.
|
|
Agentarkitektur og sammensetning |
Bruk flere agenter når:
- Domener er store eller distinkte
- Eierskapet varierer mellom teamene
- Tilgang eller rettigheter varierer
- Spesialisert resonnering er nødvendig
Delegasjon forbedrer modularitet, klarhet og langsiktig vedlikehold.
Les mer: Utforsk mønstre for iverksetting med flere agenter. |
- En hovedagent delegerer billettoppslag til en IT-agent.
- En kunnskapsagent håndterer dokument-QA.
- En rutingagent bestemmer hvilken ekspertagent som skal kontaktes.
|
- Overdelegering (for mange agenter)—f.eks. å opprette en egen agent for hver liten oppgave—kan føre til arkitekturspredning og gjøre det vanskelig å vedlikeholde, feilsøke, sikre eller oppdatere agentene.
- Underdelegering (én stor agent)—for eksempel en enkelt agent som forventes å svare på HR-spørsmål, sjekke IT-saker, håndtere feilsøking og opprette innkjøpsordrer og hendelser—kan føre til en monolittisk, skjør agent som er umulig å vedlikeholde.
- Udefinerte delegasjonsgrenser. Hovedagenten vet for eksempel ikke når den skal overlevere, underordnede agenter vet ikke hvilke inndata de kan forvente, eller ansvarsområdene overlapper (to agenter slår begge opp IT-saker).
|
|
Styring og risikohåndtering |
Definer hvordan agenten styres, sikres og overvåkes for å sikre at den oppfører seg ansvarlig, trygt og forutsigbart gjennom hele livssyklusen.
Denne definisjonen inkluderer tilgangskontroll, handlingstillatelser, sikkerhetsbarrierer, ansvarlighet og løpende tilsyn for å håndtere både operative og AI-relaterte risikoer fra dag én.
Les mer: Innhent styringskrav og anvend prinsipper for ansvarlig KI. |
- Autentiserings- og tilgangsmodell: Agenten bruker identitet på brukernivå for kun å hente data brukeren har tillatelse til å se, mens identitet på systemnivå er begrenset til klart definerte tjenesteoperasjoner.
- Handlingsrettigheter og sikkerhetsbarrierer: Agenten kan oppdatere arbeidsnotater eller utkast til svar, men kan ikke utføre irreversible handlinger (som å lukke saker eller sende ekstern kommunikasjon) uten godkjenning.
- Sikkerhets- og innholdsbeskyttelse: Sensitive eller regulerte opplysninger identifiseres og blokkeres fra å bli delt eller brukt ved hjelp av plattformens beskyttelsesfunksjoner (f.eks. datatapsforebygging eller innholdsfiltre).
- Logging, revisjon og sporbarhet: Alle agenthandlinger, verktøyanrop, avslag og eskaleringer loggføres og kan revideres for etterlevelse og gjennomgang:
- Operasjonelt eierskap: Agenten har en definert eier, sponsor og driftsansvarlig, med tillatelser og atferd som gjennomgås regelmessig.
|
- Å utforme styrings- og risikokontroller for sent i prosessen, noe som fører til blokkerte implementeringer eller produksjonsforsinkelser.
- Å gi agenter for mange tillatelser «for enkelhets skyld», noe som øker risikoen for dataeksponering eller utilsiktede handlinger.
- Å gi agenter utilstrekkelige tillatelser, noe som fører til feil under kjøring når nødvendige systemer eller data er utilgjengelige.
- Å ikke integrere Responsible AI-bekymringer i kjernestyringsbeslutninger.
- Svak operasjonell styring, for eksempel ingen klar eier, ingen overvåkingsplan eller ingen definert prosess for hendelseshåndtering.
- Å unnlate å overvåke agentens atferd etter utplassering, og anta at bare kontrollmekanismer er tilstrekkelige.
|
|
Evaluering og optimalisering |
Definer tester som simulerer virkelige scenarioer for å måle nøyaktighet, relevans og kvalitet på agentsvarene dine. Gi et forventet svar og vis hvordan agentens svar samsvarer med ditt svar eller det forventede eller det vanligste svar.
Planlegg hvordan du skal måle og forbedre ytelsen:
- Nøyaktighet og relevans
- Tid spart eller effektivitet
- Adopsjon og bruk
- Tilfredshet og tillitssignaler
- Siteringskvalitet
- Etterlevelse av tillatelser
- Oppdagelse av feil informasjon
- Avklaring av spørsmålsatferd
Definer hvilken telemetri som skal samles inn:
- Verktøykall
- Agenthandlinger
- Feil og nye forsøk
- Brukertilbakemelding
Behandle evaluering som en del av designet, ikke som en ettertanke. Les mer: Design og operasjonalisering av agent-evaluering. |
- Kontroller at billettoppslaget returnerer riktig status og ikke en utdatert status.
- Valider at siteringslenker peker til nåværende godkjent innhold.
- Valider at agenten nekter å oppgi detaljer om en billett tilhørende en annen person.
- Test om agenten dikter opp et saksnummer eller en KB-artikkel.
- Mål antall e-poster som behandles av den autonome agenten per dag, og prosentandelen brukere som velger agenten fremfor manuelle kanaler.
|
- Å kjøre evalueringer for sent (etter utplassering).
- Ingen baseline eller benchmark.
- Evalueringer er ikke knyttet til reelle scenarioer.
- Ingen regresjonsdeteksjon.
- Ingen evaluering av flere dialogrunder.
- Ingen evaluator for kvaliteten på verktøybruk.
- Sjekker bare «lykkelige veier».
- Telemetrimangler.
|
