|
Mål |
Fråga dig själv: "Vilket resultat försöker jag uppnå?Inte: "Vilka verktyg behöver jag?", "Vilka anslutningsprogram ska jag använda?" eller "Vilket ämne ska jag skapa?"
Beskriv tydligt varför agenten bör finnas, vad den ska åstadkomma och vem målgruppen är. Fokusera på resultat. Låt agentens design utgå från problemet.
Förtydliga:- Problemet eller värdegap
- Målanvändare
- Förväntad påverkan
- Så ser framgång ut
Använd ett jobbet ska göras-format:
-
Som en<användare>
-
Jag behöver att<jobbet ska göras>
-
Så att<resultat>
|
-
Som nyanställd behöver jag förstå mina lokala HR-policyer så att jag kan hantera introduktionen med självförtroende.
-
Som IT-supportchef behöver jag behandla supportmejl automatiskt så att manuell triage minskar.
|
- Börja med egenskaper istället för resultat.
- Utforma för undantagsfall.
- Att hoppa över mätbara framgångskriterier.
|
|
Utlösare |
En agentutlösare är en specifik händelse, ett villkor eller en indata som signalerar att agenten ska påbörja sitt arbete eller sin uppgift. En mänsklig handling eller en automatiserad händelse kan aktivera utlösaren.
Läs mer: Hitta den utlösare som passar din händelse. |
- Ett användarmeddelande i chatten.
- Ett nytt mejl i en delad inkorg.
- En ny post i ett system.
- En schemalagd eller återkommande uppgift.
|
- Autonoma agenter kräver explicita utlösare. Utan dem körs inte agenten.
- Utlösaren beror på oförutsägbart användarbeteende, till exempel att användaren skriver in ett specifikt nyckelord eller en fras.
- Utlösaren saknar nödvändig kontext, till exempel när agenten startar men inte har tillräckligt med metadata (post-ID, användaridentitet) för att agera effektivt.
- Utlösare aktiveras oftare än scenariot faktiskt kräver, vilket leder till onödiga körningar och resursförbrukning.
- Utlösardesignen tar inte hänsyn till plattformens kvoter eller begränsningar, vilket gör att agenter når användningströsklar eller misslyckas vid belastning.
|
|
Verktyg och integrering |
Definiera vilka åtgärder agenten måste kunna utföra, inte bara vad den vet.
Verktyg möjliggör för agenten att hämta eller uppdatera data, anropa API:er, starta Workflow, skicka meddelanden och genomföra transaktionsprocesser. Lista de system som agenten är beroende av och deras respektive begränsningar (API:er, autentiseringsmodeller, hastighetsbegränsningar samt ägar-/SLA-gränser).
Tänk på förväntade resultat, kriterier för framgång och kvalitet, alternativ för återställning och felbeteende. Beroenden påverkar ofta genomförbarheten – hantera dem tidigt.
Läs mer: Mekanismer för att lägga till verktyg till agenter. |
- ServiceNow anslutningsprogram → hämta ärendedetaljer
- Microsoft Entra ID-anslutningsprogram → hämta användarens plats
- Jira API → uppdatera ärenden
- Outlook-anslutningsprogram → svara på e-post
|
- Ej logga åtgärder eller lagra utdata för revision.
- Att utgå från att API:erna är stabila och alltid tillgängliga.
- Övertillåtande verktyg.
- Att inte definiera återgångsbeteende för verktygsanrop (ingen validering av verktygsutdata, ingen återgång när verktyg misslyckas, ingen eskaleringsväg).
- Ignorera kvotgränser eller begränsning.
- Ingen kartläggning av beroenden (vem äger varje API, vad är servicenivåavtalet).
- Att inte validera förutsättningar innan handlingar utförs.
|
|
Kanaler |
En kanal är den specifika plattform eller det gränssnitt där din agent är implementerad och interagerar med användare.
Kanalen påverkar också användarnas förväntningar på latens, turordning och upplevelse. |
- Microsoft Teams
- SharePoint
- Microsoft 365 Copilot
- Webbchatt eller röstgränssnitt
|
- Att välja kanaler baserat på bekvämlighet eller enkelhet i distributionen, istället för hur och var användare faktiskt arbetar.
- Att utgå från att användarna anpassar sig till agentens kanal, istället för att möta användarna där de redan är.
- Att prioritera teknisk genomförbarhet framför användarupplevelse, vilket resulterar i låg användning även när agenten fungerar korrekt.
- Utforma "chatt-baserat" när den verkliga kanalen är e-post- eller arbetsflödesdriven (skapa ett konversations-UX när support faktiskt sker via Outlook, som glömmer att e-post är omgångsbaserat, inte konversationsbaserat)
- Att ignorera kanalspecifika begränsningar (Outlook kräver fullständiga svar, inte förtydligande frågor; Teams stödjer Adaptiva kort, e-post gör det inte)
|
|
Kunskap och data |
Dokumentera vilken information agenten behöver resonera kring och var kunskap eller data för närvarande finns tillgänglig. Tänk på datakvalitet och aktualitet, strukturerat kontra ostrukturerat innehåll, samt åtkomst- och behörighetsgränser.
Databeredskap är en av de vanligaste källorna till hinder i sena skeden om den inte åtgärdas tidigt. |
- Dokument
- Databaser
- Webbplatser
- Kunskapsbas
- Interna eller externa system
|
- Dålig eller inkonsekvent datastyrning. När ägandeskap, uppdateringsfrekvens och uppdateringsprocesser inte är definierade blir data snabbt föråldrad eller motsägelsefull.
- Att blanda ihop "dokument" med "kunskap": Att peka på stora dokumentarkiv som en sanningskälla utan att ta hänsyn till om dessa dokument är uppdaterade, välstrukturerade eller konsekvent märkta.
- Kunskapskällor motsäger varandra. Flera versioner av en policy, procedur eller dataset kan leda till att agenten får motstridiga instruktioner.
- Behörigheter och åtkomstkontroller är inte tydligt definierade. Känsligt innehåll exponeras oavsiktligt, eller så hänvisar agenten till kunskap som slutanvändare inte har tillgång till.
- Att utöka kunskapskällor utan att validera säkerhetsgränser kan leda till att agenter antingen delar för mycket eller misslyckas när åtkomsten är begränsad.
|
|
Flöden och orkestering |
Definiera hur arbetet är strukturerat och sekvenserat hos agenten: när deterministiska flöden eller ämnen ska användas, när man ska förlita sig på orkestrering och när mänsklig inblandning krävs. Målet är förutsägbart beteende, säker automatisering och tydlig eskalering.
När ska man använda flöden eller ämnen:- Insamling av data i flera steg
- Guidad felsökning eller beslutsträd
- Efterlevnads- eller policydrivna processer
- Högpåverkande eller irreversibla åtgärder
Ämnen är den primära mekanismen för deterministisk logik.
Definiera:- Vad agenten kan göra autonomt
- Vad som kräver mänskligt godkännande, granskning eller åsidosättande
- När agenten måste eskalera eller skjutas upp
- Hur mänsklig återkoppling återkopplas till förbättring
|
- Ask-Me-Anything-agenten: Minimala deterministiska flöden; förlitar sig huvudsakligen på orkestrering och generativt resonemang.
- Autonom agent: Använder flöden eller ämnen för att upprätthålla sekvensering, valideringar och kontrollfunktioner för kritiska steg.
- Godkännandeflöden: Agenten förbereder kontext och rekommendationer; människor godkänner eller åsidosätter åtgärder med stor påverkan.
|
- Överstrukturering av flöden, begränsning av flexibilitet, vilket gör att agenten upplevs som stel eller skör.
- Att understrukturera flöden, minska tillförlitligheten och göra resultaten oförutsägbara.
- Att inte uttryckligen använda ämnen för deterministisk logik, vilket leder till ad hoc eller inkonsekvent beteende.
- Ansvarsgränser mellan människa och agent blir otydliga, vilket resulterar i oklara eskaleringsvägar.
- Att överbelasta människor med godkännanden för lågriskåtgärder leder till flaskhalsar och minskad användning av agenter.
- Agenter som agerar utan tydliga "agera inte"-gränser, särskilt i gräns- eller högrisksituationer.
|
|
Instruktioner och beteende |
Intruktioner definierar:- Agentens roll och ansvarsområden
- Hur den resonerar och svarar
- När och hur den ska använda kunskap, verktyg eller andra agenter
- Sekvensen av handlingar den bör följa
- Ton, gränser och säkerhetsregler
Tydliga instruktioner kopplar samman kunskap, verktyg och flöden till ett sammanhängande, förutsägbart system.
Läs mer: Konfigurera högkvalitativa instruktioner för generativ orkestrering och Skriv effektiva instruktioner för förklarande agenter. |
- Roll och omfattning: "Du är IT-supportagent för e-post och ansvarar för att läsa inkommande e-postmeddelanden, extrahera ärendenummer och svara med validerad information från ServiceNow."
- Sekvenserat beteende: "Steg 1: Kontrollera kunskapsbasen gällande en befintlig policy eller känt problem." Steg 2: Om informationen inte hittas eller är ofullständig, anropa ServiceNow-verktyget för att hämta ärendeuppgifterna. Steg 3: Om nödvändig information fortfarande saknas, svara med ett 'jag vet inte'-svarsmönster och eskalera ärendet.
- Verktygsanvändningsregler: "Validera alltid extraherade ID-nummer med ett verktygsanrop innan du använder dem i svar."
- Felhantering: "Om kunskap saknas eller ett verktygsanrop misslyckas, gissa inte. Svara med en tydlig begränsning och nästa steg."
|
- Instruktionerna är för vaga. Till exempel specificerar inte "Hjälp användare med supportproblem" domän, gränser eller tillåtna åtgärder.
- Det saknas tydliga riktlinjer för när kunskap, verktyg eller andra agenter ska användas, vilket leder till inkonsekvent eller ineffektivt beteende.
- Instruktioner definierar inte handlingssekvensen, vilket gör att agenten blandar kunskap och verktygsresultat på oförutsägbara sätt.
- Regler för verktygsanvändning är inte explicit definierade, vilket kan leda till att verktyg anropas i onödan eller inte alls, eller att kunskap och verktygsresultat blandas på oförutsägbara sätt.
- Motstridiga instruktioner, såsom: "ställ alltid följdfrågor" och "svara endast med slutgiltiga svar."
- Ingen explicit "får inte göra"-vägledning, såsom att modifiera känsliga data, dela interna identifierare eller ge juridisk eller HR-rådgivning utan verifierade källor.
|
|
Agentarkitektur och sammansättning |
Använd flera agenter när:
- Domäner är stora eller distinkta
- Ägarskap skiljer sig mellan teamen
- Åtkomst eller behörigheter varierar
- Specialiserat resonemang krävs
Delegering förbättrar modularitet, tydlighet och långsiktig underhållsbarhet.
Läs mer: Utforska orkestreringsmönster med flera agenter. |
- En huvudagent delegerar biljettsökning till en IT-agent.
- En kunskapsagent hanterar dokumentkvalitetssäkring.
- En routingagent bestämmer vilken expertagent som ska kontaktas.
|
- Överdelegering (för många agenter) – till exempel att skapa en separat agent för varje liten uppgift – kan leda till arkitekturspridning och göra det svårt att underhålla, felsöka, säkra eller uppdatera agenterna.
- Underdelegering (monolitisk agent) – till exempel en enda agent som förväntas besvara HR-frågor, söka IT-ärenden, hantera felsökning och skapa inköpsorder och incidenter – kan leda till en monolitisk, fragil agent som är omöjlig att underhålla.
- Odefinierade delegeringsgränser. Till exempel vet huvudagenten inte när den ska lämna över, underordnade agenter vet inte vilka indata de ska förvänta sig, eller så överlappar ansvarsområdena (två agenter slår båda upp IT-ärenden).
|
|
Styrning och riskhantering |
Definiera hur agenten styrs, säkras och övervakas för att säkerställa att den agerar ansvarsfullt, säkert och förutsägbart under hela sin livscykel.
Denna definition inkluderar åtkomstkontroll, handlingsrättigheter, säkerhetsramar, ansvar och löpande tillsyn för att hantera både operativa och AI-relaterade risker från dag ett.
Läs mer: Identifiera styrningskrav och Tillämpa ansvarsfulla AI-principer. |
- Autentiserings- och åtkomstmodell: agenten använder användarnivåidentitet för att endast hämta den data en användare har behörighet att se, medan systemnivåidentiteter är begränsade till tydligt definierade tjänsteoperationer.
- Åtgärdsbehörigheter och skyddsåtgärder: Agenten kan uppdatera arbetsanteckningar eller utkast till svar, men kan inte genomföra irreversibla åtgärder (som att stänga ärenden eller skicka extern kommunikation) utan godkännande.
- Säkerhet och innehållsskydd: Känslig eller reglerad information upptäcks och blockeras från att delas eller åtgärdas med hjälp av plattformsskydd (till exempel skydd mot dataförlust eller säkerhetsfilter).
- Loggning, revision och spårbarhet: Alla agentåtgärder, verktygsanrop, nekanden och eskaleringar loggas och kan granskas för efterlevnad och granskning.
- Operativt ägande: agenten har en definierad ägare, sponsor och operativ förvaltare, med tillstånd och beteende som granskas regelbundet.
|
- Att designa styrning och riskkontroller för sent, vilket leder till blockerade implementeringar eller produktionsförseningar.
- Att ge agenter alltför många behörigheter "för bekvämlighetens skull", vilket ökar risken för dataexponering eller oavsiktliga handlingar.
- Underbehörighetsgivande agenter, vilket orsakar fel vid körning när nödvändiga system eller data är otillgängliga.
- Att inte integrera ansvarsfull AI i kärnbesluten om styrning.
- Svag operativ styrning, såsom: ingen tydlig ägare, ingen övervakningsplan eller ingen definierad process för incidenthantering.
- Det går inte att övervaka agentens beteende efter distribution, förutsatt att enbart skyddsåtgärderna är tillräckliga.
|
|
Utvärdering och optimering |
Definiera tester som simulerar verkliga scenarier för att mäta noggrannhet, relevans och kvaliteten på dina agenters svar. Ge ett förväntat svar och visa hur agentens svar överensstämmer med ditt svar eller det mest standardiserade svar.
Planera hur du ska mäta och förbättra prestandan:
- Noggrannhet och relevans
- Tidssparande eller effektivitet
- Införande och användning
- Tecken på tillfredsställelse och förtroende
- Citeringskvalitet
- Behörighetsefterlevnad
- Identifiering av felaktig information
- Beteende vid förtydligande frågor
Definiera vilken telemetri som ska samlas in:
- Verktygsanrop
- Agentåtgärder
- Fel och återförsök
- Feedback från användare
Behandla utvärdering som en del av designen, inte som en eftertanke. Läs mer: Utforma och implementera utvärdering av agenten. |
- Validera att biljettsökningen returnerar korrekt status och inte en föråldrad.
- Verifiera att citeringslänkar pekar på aktuellt godkänt innehåll.
- Verifiera att agenten vägrar lämna ut uppgifter om en annan persons ärende.
- Testa om agenten hittar på ett ärendenummer eller en KB-artikel.
- Mät antalet mejl som hanteras av den autonoma agenten per dag, och andelen användare som väljer agenten framför manuella kanaler.
|
- Genomför utvärderingar för sent (efter driftsättning).
- Ingen baslinje eller jämförelsevärde.
- Utvärderingar är inte kopplade till verkliga scenarier.
- Ingen regressionsdetektion.
- Ingen utvärdering av flera dialogvändor.
- Ingen utvärderare för verktygsanvändningens kvalitet.
- Kontrollerar bara "lyckade vägar".
- Telemetriluckor.
|
