Agentforce-guiden till att uppnå tillförlitligt agentbeteende: ett ramverk för sex nivåer av determinism

Olfa Kharrat, chef för produktledning - Agentforce
Reinier van Leuken, Senior Director of Product Management - Agentforce

Förtroende har varit ett kärnvärde sedan Salesforce grundades 1999 och företaget har varit banbrytande med en ny teknikmodell inom cloud computing och SaaS. Företagen ger Salesforce sitt förtroende när de lagrar värdefulla företagsdata i molnet och känner sig trygga med att dessa data är skyddade och styrs av lämpliga åtkomstkontroller. Detta är fortfarande viktigt, men i en tid av agentisk AI blir definitionen av förtroende ännu bredare. I takt med att företag förlitar sig allt mer på autonoma agenter för att utföra kritiska affärsfunktioner måste agenter bli betrodda affärspartners vars arbete är korrekt, relevant och framför allt tillförlitligt.

Så hur bygger du en tillförlitlig agent? Tillförlitlighet innebär vanligtvis att samma indata ger samma resultat. Agenter fungerar dock inte nödvändigtvis så eftersom de drivs av stora språkmodeller (LLM:er) som till sin natur är icke-deterministiska. Det innebär att agenter kan utveckla kreativa lösningar som är skräddarsydda utifrån specifika omständigheter utan att varje tillstånd eller situation som uppstår behöver programmeras uttryckligen. Agenter behöver dock också styrning för att följa affärskrav och verksamhetsriktlinjer. När de utför affärsprocesser måste de visa att de är tillförlitliga och producera affärsresultat som överensstämmer med deterministiska begränsningar. Determinism innebär en stelhet och disciplin som står i konflikt med den autonomi och flexibilitet som agenter tillhandahåller. Nyckeln till att skapa bra agenter är därför att hitta rätt balans mellan kreativ flexibilitet och företagskontroll.

Detta dokument går igenom viktiga överväganden för utveckling av tillförlitliga agenter. Det definierar sex nivåer av agentisk kontroll och tillhandahåller bästa praxis för att få och behålla kontroll över agentiskt beteende för var och en av dessa nivåer. Vägledningen går igenom hur Agentforce-resonemangsmotorn fungerar. I takt med att Agentforce växer uppdateras detta dokument med senaste bästa praxis.

Detta dokument förutsätter grundläggande kännedom om att designa och skapa Agentforce-agenter. Som en introduktion till Agentforce rekommenderar vi följande:

• Gå igenom resurserna på agentforce.com.
• Följ spåret Bli en Agentblazer Champion . Detta spår utforskar centrala AI-koncept och hjälper dig att skapa en grundläggande agent för viktiga uppgifter.
• Läs mer om Agentforce på help.salesforce.com , särskilt Designa och implementera agenter . Denna inlärningskarta vägleder dig genom alla viktiga steg i livscykeln, från att idéutveckla lösningen till att konfigurera agenten och testa, distribuera och övervaka.

För att förstå agentiskt beteende bättre ska vi först jämföra agenter med deras stela motsvarigheter: chattbottar.

Chattbottar: stela regelföljare

Chattbottar följer förutbestämda beslutsträd som strukturerar de dialoger de kan delta i. Navigeringen genom dessa beslutsträd baseras på de svar som användaren ger. Svaret kan vara ett val från en förutbestämd uppsättning alternativ eller ett fritextsvar. Vid fritextsvar används en prediktiv modell för klassificering av syfte. Dessa träd kartlägger alla potentiella konversationsvägar och dikterar chattbottens svar i varje steg. Chattbottens beteende avgörs stelt av fördefinierade regler. Om en användares indata inte matchar en identifierad väg eller om den prediktiva modellen inte har tränats för att identifiera ett visst syfte svarar chattbotten inte på lämpligt sätt.

Agenter: adaptiva och intuitiva

Däremot utnyttjar agenter kraften hos LLM:er och deras avancerade funktioner inom naturlig språkbehandling (NLP). LLM:er gör det möjligt för agenter att förstå syftet bakom en användares indata, även om de formuleras på ett oväntat sätt. Baserat på förståelsen för syftet kan agenten välja den lämpligaste åtgärden bland en rad alternativ. En agent kan till och med formulera helt nya svar. Denna flexibilitet och anpassningsförmåga skiljer agenter från deras motsvarigheter chattbottarna.

En liknelse inom matlagning

Skillnaden mellan chattbottar och agenter kan liknas vid skillnaden mellan en nybörjare i köket och en erfaren kock.

• Nybörjaren (chattbotten) är beroende av ett detaljerat recept med exakta mått, steg-för-steg-instruktioner och specifika tillagningstider. Avvikelser från receptet leder till en matkatastrof. På samma sätt måste en chattbot fungera inom ramen för sitt förprogrammerade beslutsträd.
• Den erfarna kocken (agenten) har många års erfarenhet av matlagning och intuition. Med hjälp av en allmän förståelse för dina preferenser och en kort beskrivning av tillgängliga ingredienser kan de laga en läcker måltid som passar dina behov. De exakta stegen kan variera mellan gångerna och versionerna av maträtten kan ha små skillnader, men det övergripande resultatet är alltid tillfredsställande. På samma sätt kan en agent anpassa sin strategi baserat på kontexten för och syftet med användarens indata så att en interaktion blir lyckad.

Sammanfattningsvis ligger den grundläggande skillnaden mellan agenter och chattbottar i deras anpassningsförmåga och kapacitet att hantera oväntade indata.

Ett distinkt inslag i en agents intelligens är dess förmåga att orkestrera och utlösa de lämpligaste åtgärderna vid rätt tidpunkt. Tack vare denna flexibilitet behöver inte varje potentiell användarinteraktion programmeras i stor omfattning.

I Agentforce ingår ämnen, åtgärder och instruktioner och beskrivningar på naturligt språk i att skapa en agent.

Ämnen

Ämnen är de jobb som agenten ska utföra. Ämnen har attribut, till exempel en klassificeringsbeskrivning, omfattning och instruktioner, som definierar varje jobb och hur det görs. Ämnen innehåller åtgärder som agenten kan utföra samt instruktioner som styr hur dessa åtgärder utförs.

Åtgärder

Åtgärder är de fördefinierade uppgifter som agenten kan utföra för att göra sitt jobb. Det finns fem olika typer av åtgärder:

• kör Apex-kod
• anropa ett API
• utför ett flöde
• få ett LLM-svar på en promptmall
• anropa en prediktiv modell.

Instruktioner och beskrivningar på naturligt språk

En agents definition innehåller instruktioner på naturligt språk som beskriver agentens tillgångar och definierar de riktlinjer som den måste följa. Instruktioner skrivs för åtgärder och ämnen.

• Åtgärder. En åtgärd innehåller
  • instruktioner som beskriver vad åtgärden gör och meddelar resonemangsmotorn när åtgärden ska utföras
  • indata med en beskrivning på naturligt språk så att agenten kan förbereda dem
  • utdata med en beskrivning på naturligt språk av hur de ska formateras och användas.
• Ämne. Ett ämne innehåller instruktioner som styr hur dess åtgärder ska utföras på en högre nivå. Instruktioner kan till exempel ange skyddsräcken om tonfall, önskad åtgärdssekvens, möjliga förutsättningar eller när konversationer ska eskaleras till människor. Ämnet innehåller också en klassificeringsbeskrivning och en omfattningsavgränsning. Sammantaget säkerställer detta att agenten håller sig inom omfattningen för sin definierade roll och utför jobbet.
• Data. Agenter behöver data för att lyckas i sina jobb. Data kan vara strukturerade, till exempel CRM-data, eller ostrukturerade, till exempel företagskunskapsartiklar. Agenter får tillgång till data med hjälp av åtgärdsindata. En åtgärd kan till exempel anropa en promptmall som är grundad i CRM-data eller förstärkt med ostrukturerade deldata med hjälp av RAG-tekniker.

När dessa olika byggstenar har skapats korrekt hjälper de en agent att uppfylla sitt avsedda syfte samtidigt som den håller sig inom lämpliga gränser.

Agentforce-resonemangsmotorn orkestrerar dessa byggstenar i korrekt agentiskt beteende. Den utnyttjar de instruktioner och beskrivningar på naturligt språk som definieras i ämnen och åtgärder. Den bygger på ReAct, ett nytt resonemangsparadigm för LLM:er som introducerades 2022 av Yao et al. Detta paradigm imiterar mänsklig uppgiftshantering genom att resonera om ett problem, vidta åtgärder, observera åtgärdens resultat och upprepa cykeln tills uppgiften har slutförts.

Salesforce-agenter följer detta paradigm:

1. Resonera: Förstå användarnas syfte och se till att det överensstämmer med rätt ämne och åtgärder.
2. Agera: Inled rätt åtgärdskedja.
3. Observera: Utvärdera åtgärdens resultat i förhållande till användarens syfte. Om syftet inte har uppfyllts ska de resonera vidare baserat på det uppnådda resultatet hittills och på instruktionerna och beskrivningarna för ämnet/åtgärden. Om syftet har uppfyllts ska de ge det slutliga svaret och följa eventuella formateringsinstruktioner.
4. Upprepa: Upprepa dessa steg tills det sista instruerade steget har nåtts.

Resonemangsmotorn använder LLM:er i varje Resonera- och Observera-steg. Beroende på åtgärdstyp kan den också använda LLM:er i Agera-steget.

Denna sektion beskriver en skiktad strategi för att förbättra agenters determinism. Varje nivå bygger på den föregående, med ökad komplexitet och kapacitet som ger mer kontroll över agentens beteende.

Den första nivån fokuserar på att göra det möjligt för agenter att autonomt identifiera relevanta ämnen och sedan välja lämpliga åtgärder med hjälp av mål snarare än uttryckliga instruktioner. I den centrala mekanismen ingår att använda en kontextuell förståelse för att svara på användarindata. Även om alla typer av åtgärder tekniskt sett kan läggas till förutsätter vi på denna nivå att åtgärderna är promptåtgärder. Instruktionsfria ämnen med promptåtgärder ger ett snabbt och effektivt sätt att hantera vanliga frågor.

På denna nivå ligger fokus på att upprätta en baslinjenivå för agenters respons och autonomi genom dynamisk förståelse.

Denna nivå bygger vidare på grunden med val av instruktionsfria åtgärder. Här introduceras uttryckliga instruktioner som vägleder agenternas beteende. Exakta instruktioner ger en ökad kontroll över hur agenter reagerar på olika situationer. Instruktioner till agenter kan uttryckas som regler, riktlinjer, skyddsräcken och exempel. De ger agenten specifik vägledning om hur de ska hantera olika ämnen, utföra åtgärder och bearbeta deras utdata. Målet för denna nivå är att ge agenten tydlig vägledning för att öka enhetligheten och förbättra efterlevnaden av företagets riktlinjer och processer.

Grundning innebär att koppla agentens förståelse och svar till externa kunskapskällor. Grundning säkerställer att informationen som agenten tillhandahåller är mer korrekt, aktuell och relevant. På denna nivå integreras åtkomst till databaser, kunskapsbaser och andra informationsarkiv. När agentens svar grundas i verifierade data blir de mer tillförlitliga.

Denna nivå lägger till agenters förmåga att arbeta med variabler. Med hjälp av variabler kan agenter anpassa interaktioner, behålla kontext i flera interaktioner och dynamiskt justera sitt beteende baserat på specifika datapunkter som upprätthålls under agentsessionen. En agent kan till exempel samla in användarpreferenser, orderuppgifter och annan relevant information och sedan använda dessa data för att skräddarsy interaktionen. Med variabler blir agenter bättre på att hantera mer komplexa, mer föreskrivna och mer anpassade interaktioner.

Detta steg integrerar agenten med Salesforces kärnfunktioner: Apex, API:er och flöde. Genom integrering kan agenten utföra komplexa åtgärder inom Salesforce-ekosystemet, till exempel få åtkomst till och hantera data, utlösa arbetsflöden och interagera med andra system.

• Apex tillhandahåller programmatisk kontroll.
• API:er möjliggör sömlös integrering med andra applikationer.
• Flöden möjliggör automatisering av komplexa affärsprocesser.

På denna nivå omvandlas agenten till ett kraftfullt verktyg som kan utföra avancerade uppgifter och bidra direkt till affärsresultat.

Denna slutliga nivå bygger vidare på de tekniska integrationerna på nivå 5 och introducerar deterministiska resonemang för att överbrygga klyftan mellan sannolikhetsbaserad AI och stel affärslogik. Medan tidigare nivåer använder LLM:en för att avgöra vilket verktyg som ska användas kan du med agentskript ”hårdkoda” själva resonemangsprocessen. Genom att använda en arbetsyta i dokumentstil eller direktkod kan du definiera oföränderliga vägar, till exempel obligatoriska autentiseringsgrindar, villkorlig if/else-förgrening och framtvingade ämnesövergångar, som agenten måste följa oavsett användarindata. Med denna hybridresonemangsstrategi kan du placera en LLM:s konversationsflexibilitet mellan lager av garanterat utförande. Nivå 6 omvandlar agenten till en nolltillitspartner i företagsklass som kan hantera viktig efterlevnad, offentliggöranden av regler och komplexa beroenden i flera steg med absolut precision.

Utgå från en baslinje för agenters respons och autonomi, och tänk på en agent som bara består av ämnen och åtgärder med motsvarande beskrivningar. Vi kan använda denna exempelagent för att introducera resonemangsmotorns olika steg och för att visa hur den använder dessa beskrivningar för att välja rätt ämnen och sedan åtgärder som ska utföras. Genom att utelämna ämnesinstruktioner i detta exempel kan vi observera att agenter på denna första nivå har störst frihet jämfört med agenter på högre nivåer. På nivå ett kan agenten helt fritt välja den åtgärd som den anser är lämplig, enbart baserat på den pågående konversationen.

Gå igenom följande överväganden för resonemangsmotorn:

• Konfigurationsinställningarna är fasta för resonemangsmotorns LLM. Agentbyggare kan inte ändra dem. För närvarande kan agentbyggaren välja mellan en LLM från OpenAI och en LLM från Anthropic som finns på Salesforces infrastruktur för resonemang. Detta kan komma att ändras när fler modeller läggs till.
• Standardhistorik för resonemangsmotorn: När en begäran görs till resonemangsmotorn (steg 2–5) hämtar den automatiskt historiken för de senaste begärandena och svaren. Detta säkerställer att konversationskontexten upprätthålls för resonemangsmotorn. Förutom kundinteraktioner omfattar dessa anrop till planerar-LLM:en anrop till resonemangsmotor-LLM:en för andra begäranden, till exempel ämnesval.

Resonemangsprocessen består av fyra huvudsakliga steg:

1. ämnesval
2. åtgärdsval
3. agentisk loop
4. Grundningskontroll

Ämnen är utformade för att agenter ska klassificera rätt åtgärd eller åtgärdssekvens mer korrekt. Varje ämne bör bestå av semantiskt distinkta åtgärder som kan tillhöra en kortfattad ämnesbeskrivning och därmed tillhöra en liknande agentfunktion.

Rätt ämne väljs av resonemangsmotor-LLM:en (steg 2–3 i diagrammet). Den väljer det ämne vars klassificeringsbeskrivning matchar det senaste yttrandet bäst, med hjälp av en ämnesprompt. Denna ämnesprompt innehåller klassificeringsbeskrivningarna för alla ämnen och konversationshistoriken. Förutom yttranden och agentsvar innehåller konversationshistoriken utförda åtgärder och deras resultat. Dessutom innehåller prompten viktiga instruktioner som föreskriver analys inom ramen för konversationshistoriken och kräver att LLM:en anger sin tankeprocess.

Fler överväganden:

• Ytterligare ett dolt ämne för irrelevanta yttranden finns automatiskt tillsammans med de synliga ämnena. Detta ämne väljs när inget annat befintligt ämne överensstämmer med yttrandet. Det hjälper agenten att undvika felklassificering. Detta ämne har inga åtgärder. Det finns bara för att hjälpa resonemangsmotorn att formulera ett lämpligt svar senare.
• Det är bara ämnets namn och klassificeringsbeskrivning som används i ämnesprompten.
• Resonemangsmotor-LLM:en kan bara välja ett ämne åt gången.
• Konversationer kan oväntat ändra riktning. När ett yttrande tas emot går resonemangsmotorn vidare till steget för ämnesval. Det innebär att ett nytt ämne kan väljas vid varje nytt yttrande.

Syftet med ämnen är dubbelt:

1. minska risken för att resonemangsmotorn blir förvirrad genom att gruppera åtgärder, så att den inte väljer fel åtgärder
2. vägleda val och utförande av åtgärder med instruktioner (mer om det i nivå två: agentisk kontroll: lägg till instruktioner).

Genom att noggrant organisera agentförmågor i tydligt definierade ämnen som består av relaterade åtgärder fungerar agenten mer effektivt och förutsägbart. Det blir också enklare att uppdatera och utöka. Det finns två möjliga strategier för ämnesdesign: uppifrån och ner eller nerifrån och upp.

• Med strategin uppifrån och ner utformas ämnena först som jobb på hög nivå som agenten ska utföra och sedan definieras de enskilda åtgärderna för dessa ämnen.
• Med strategin nerifrån och upp definieras först alla enskilda åtgärder som sedan grupperas i ämnen.

Båda strategierna leder till goda resultat när de följs korrekt.

Strategin nerifrån och upp

Denna sektion går igenom strategin nerifrån och upp eftersom den stämmer väl överens med orsakerna till att resonemangsmotorn behöver ämnen från början.

Steg 1: Lista alla agentåtgärder

Börja med att lista alla specifika åtgärder som agenten bör kunna utföra. I denna fas är det bättre att vara mycket specifik snarare än för vag. Undvik att försöka gruppera eller förenkla åtgärder för tidigt. Målet är att skapa en heltäckande och granulär bild av vad agenten kan göra.

När det till exempel gäller en kundserviceagent kan den inledande listan innehålla följande:

• Returnera en order: används för att påbörja returprocessen för en order.
• Kontrollera lagertillgänglighet: används för att verifiera om en produkt finns i lager.
• Kontrollera policyer för produktbyte: används för att hämta information om bytesregler.
• Svara på frågor med kunskap: används för att svara på allmänna eller vanliga frågor.
• Kontrollera kampanjer: används för att kontrollera om det finns några tillgängliga kampanjer eller rabatter.
• Förutsäg leveransdatum: används för att uppskatta förväntat leveransdatum/-tid.
• Kontrollera orderstatus: används för att hitta aktuell status för en kunds order.
• Hitta kundorder: används för att hämta alla tidigare eller aktiva order för en specifik kund.
• Felsök tekniska problem: används för att lösa tekniska problem med en produkt eller tjänst.
• Hitta kundordervillkor: används för att hämta alla villkor som rör en order.
• Hitta kundtillgångar: används för att identifiera eller hämta tillgångar som är kopplade till en kund.
• Ändra leveransadress.

Observera att en åtgärd som ”Åtgärda kundklagomål” är för bred i detta läge. Åtgärder bör representera den lägsta granularitetsnivån i agenters beteende. Det kan finnas många typer av klagomål och de omfattas redan av olika åtgärder:

• Problem efter leverans, till exempel felsökning av skadade eller defekta produkter, omfattas redan av ”Felsök tekniska problem”.
• Problem före leverans, till exempel saknade leveranser, ändring av leveransdatum eller ändring av order, omfattas redan av åtgärder som ”Kontrollera orderstatus”, ”Förutsäg leveransdatum” eller ”Returnera en order”.
• Allmänna kundfrågor, till exempel policyförfrågningar, omfattas redan av ”Svara på frågor med kunskap” eller ”Kontrollera policyer för produktbyte”.

Steg 2: Markera åtgärdspar (eller -multiplar) som kan orsaka förvirring i resonemanget

Markera åtgärder som liknar varandra eftersom de kan orsaka förvirring för resonemangsmotorn. Deras beskrivningar kommer inte att vara tillräckligt olika semantiskt, och därför kommer resonemangsmotorn inte att veta vilken åtgärd den ska välja i steg 5.

”Felsök tekniska problem” och ”Svara på frågor med kunskap” har till exempel liknande beskrivningar, men deras funktion kan skilja sig avsevärt. Genom att markera sådana semantiska överlappningar blir det lättare att identifiera vilka åtgärder som ska separeras mellan flera ämnen.

Steg 3: Skapa inledande grupperingar av åtgärder i ämnen

När åtgärder har definierats tydligt och deras semantiska överlappningar har identifierats kan åtgärder grupperas i preliminära ämnen. Ett ämne är en logisk kategori av funktioner – en gruppering av åtgärder som tillsammans representerar en sammanhängande förmåga eller färdighet hos agenten.

När du skapar dessa grupperingar ska du

• undvika semantisk överlappning genom att använda så få ämnen som möjligt
• säkerställa att varje ämne innehåller åtgärder som är relaterade på ett meningsfullt sätt
• se till att stödjande åtgärder som måste utföras i en kedja finns i samma ämne.

Här är ett exempel på en inledande gruppering för en kundserviceagent:

Ämne 1:

• Returnera en order
• Kontrollera lagertillgänglighet
• Kontrollera policyer för produktbyte
• Kontrollera kampanjer
• Förutsäg leveransdatum
• Hitta kundordervillkor
• Kontrollera orderstatus
• Hitta kundorder
• Hitta kundtillgångar
• Svara på frågor med kunskap
• Ändra leveransadress

Ämne 2:

• Felsök tekniska problem
• Hitta kundtillgångar

Steg 4: Skriv klassificeringsbeskrivningar för ämnen och dela upp ämnen om det behövs

När du har den inledande grupperingen skriver du klassificeringsbeskrivningar för alla ämnen.

• Det är tydligt att ämne 2 i vårt exempel handlar om tekniska problem med produkter.
• Ämne 1 har dock en bredare omfattning. Det handlar till stor del om orderhantering men innehåller också vissa åtgärder som inte är relaterade till orderhantering, till exempel att kontrollera kampanjer och svara på frågor med kunskap. Ämne 1 kan inte beskrivas kort och koncist i en enda mening och därför bör ämnet delas upp i olika ämnen.

När vi har förfinat får vi följande:

• Ämne 1: Orderhantering: Beskriver åtgärder som rör hantering och ändring av kundorder och relaterad logistik, förutom allt som rör byte och retur.
  • Kontrollera lagertillgänglighet: avgör om en produkt finns i lager.
  • Förutsäg leveransdatum: uppskatta när en order levereras.
  • Kontrollera orderstatus: hitta statusen för en kunds order.
  • Hitta kundorder: hämta alla order som gjorts av en kund.
  • Ändra leveransadress.
• Ämne 2: Felsökning
  • Hitta kundtillgångar: hämta kundens registrerade enheter eller produkter.
  • Felsök tekniska problem: ge teknisk hjälp eller diagnostik.
• Ämne 3: Byte: Beskriver åtgärder som är relaterade till orderbyte och retur.
  • Returnera en order: påbörja processen för orderretur.
  • Kontrollera policyer för produktbyte: tillhandahåll bytesregler för produkter.
  • Hitta kundorder: hämta alla order som gjorts av en kund.
  • Hitta kundordervillkor: hämta alla villkor som rör en beställning.
• Ämne 4: Produktsupport: Beskriver övergripande åtgärder som används för hämtning och vidarebefordran av information.
  • Svara på frågor med kunskap: svara på allmänna kundförfrågningar med hjälp av kunskapsbasinformation.
  • Kontrollera kampanjer: visa aktuella kampanjer eller rabatter.

Sammanfattningsvis ska du först skapa en heltäckande lista över alla möjliga åtgärder och sedan markera semantisk överlappning mellan åtgärderna. Skapa sedan en uppsättning ämnen som åtminstone löser all semantisk överlappning (så att resonemangsmotorn inte blir förvirrad inom ramen för ett ämne). Skriv därefter alla ämnens klassificeringsbeskrivningar. Om ämnena har för bred omfattning delar du upp dem i mer granulära ämnen. Genom att implementera denna vägledning kan du skapa en agent som inte bara presterar bra, utan också är lätt att underhålla och utöka.

Denna struktur stöder bättre resonemang, mer exakt utförande och tydligare beslutsgränser inom agentens beteende. Den bygger också på samarbete mellan designers, ingenjörer och ämnesexperter för att göra agentens förmågor mer transparenta och modulära.

Fler överväganden för att skapa effektiva ämnen

• Optimalt antal ämnen: För att förbättra LLM:ernas prestanda när det gäller att klassificera rätt ämne är det generellt sett lämpligt att inte överskrida tio ämnen. Men detta är bara en tumregel. Dessutom bör varje ämne ha en tydlig och distinkt beskrivning. I slutändan beror det optimala antalet ämnen på det semantiska avståndet mellan ämnens klassificeringsbeskrivningar. Om ämnena har klassificeringsbeskrivningar som är mycket olika minimeras risken för ämnesöverlappning. Mer bästa praxis för att undvika överlappning mellan ämnen beskrivs här .
• Balansera ämnens storlek och tydlighet: Det är generellt sett bra att ha små ämnen när det gäller åtgärder och instruktioner för enklare klassificering, men det kan leda till förvirring att skapa för många ämnen med mycket liknande beskrivningar, precis som semantisk överlappning mellan åtgärder leder till felklassificering. Därför är det viktigt att ha tydligt semantiskt differentierade ämnesbeskrivningar. Du kan använda LLM:er för att skapa de differentierade klassificeringarna.
• Standardspråk och kontextuell tydlighet: LLM:er kanske inte känner till företags specifika betydelser och förkortningar. Använd standardspråk eller var mycket tydlig när du förklarar ords betydelser i din specifika kontext.
• Endast ämnets namn och beskrivning skickas i ämnesprompten. Därför påverkas inte ämnesvalet om ämnets omfattning eller instruktioner ändras.

Exempel i praktiken

Tänk dig att en serviceagent får en garantipolicybegäran som rör en klocka. Garantiproblemet verkar inte vara relaterat till produktbyte eller support. Orderhantering verkar vara det lämpligaste ämnet för att hantera denna begäran. Därför väljs det senare ämnet av resonemangsmotorn som det mest sannolika för att uppfylla begäran.

Efter ämnesvalet väljer resonemangsmotorn rätt åtgärder som ska utföras från det valda ämnet. Resonemangsmotor-LLM:en är återigen ansvarig för detta, med hjälp av en annan prompt som kallas observationsprompten. Syftet med observationsprompten är att hämta nästa steg i resonemangsprocessen. Nästa steg kan vara något av följande:

• starta en åtgärd
• begära åtgärdsindata från användaren
• begära förtydligande av användarens begäran
• skicka det slutliga svaret till användaren (uppfylla användarbegäran) när åtgärdsloopen har slutförts (mer information finns i resonemangssteg 3).

Indata till observationsprompten utgörs av alla beskrivningar av alla åtgärder från ämnet samt från konversationshistoriken.

Bästa praxis för åtgärdsdesign

Åtgärder är de fördefinierade uppgifter som agenten kan utföra för att göra sitt jobb. Åtgärder är de mest finkorniga definitionerna av arbete. Det finns fem olika typer av agentåtgärder: (1) utför Apex-kod, (2) anropa ett API, (3) utför ett flöde, (4) få ett LLM-svar på en promptmall och (5) anropa en prediktiv modell. De flesta av dessa åtgärder kan vara deterministiska. Ett undantag är att få ett svar på en promptmall (förutsatt att det externa systemet, flödes- eller Apex-åtgärden inte innehåller sannolikhetsbaserade element som promptanrop). Vi kommer att ta upp dessa frågor på den femte nivån av agentisk kontroll.

1. Kontrollera agentiskt beteende i promptåtgärder: Det finns två sätt att tillämpa kontroll över agentens beteende i promptåtgärder: (1) lägg till fler instruktioner i promptmallen genom promptteknik och (2) konfigurera hyperparametrarna för LLM:en som genererar promptsvaret, särskilt temperaturen (se dokumentationen ). Om temperaturen sänks minskar variationen i de genererade svaren, vilket ökar deras repeterbarhet och agenternas tillförlitlighet.
2. Optimalt antal åtgärder inom ett enda ämne: I likhet med det maximala antalet ämnen bör antalet åtgärder inom ett ämne inte överstiga tio. Men detta är återigen en tumregel. Den verkliga drivande faktorn är det semantiska avståndet mellan åtgärderna. När åtgärder tydligt kan särskiljas genom deras beskrivning kan detta tal vara större. Det finns dock inget numeriskt mått för semantiskt avstånd utan det beror på agentverktygets tolkning. Ju större skillnaden i betydelse är mellan åtgärdsbeskrivningarna, desto större blir det semantiska avståndet. Du bör alltid undvika överlappningar här.
3. Åtgärdsbeskrivningar: I motsats till vad namnet antyder fungerar ”åtgärdsinstruktionen” i själva verket som en instruktion som resonemangsmotor-LLM:en använder för att välja rätt åtgärd från ämnet. Observera att klassificeringarnas kvalitet kan förbättras avsevärt om semantiskt distinkta åtgärdsbeskrivningar används. Gå noggrant igenom dessa beskrivningar och jämför i synnerhet alla åtgärdsbeskrivningar som tillhör ett enda ämne.

Exempel i praktiken

Vi ska fortsätta med det tidigare exemplet där en serviceagent fick en fråga om garantipolicyn för en klocka. När ämnet Orderhantering har valts väljs den mest sannolika åtgärden. Eftersom detta är ämnet Orderhantering är det första logiska steget att söka efter ordern (vad finns det annars att hämta garantiinformation för?) genom att starta åtgärden för att söka efter order.

Ett användaryttrande kan utlösa flera åtgärder innan ett svar skickas tillbaka till användaren. Det beror på den agentiska loopen, som fortsätter att välja och utföra nästa lämpligaste åtgärd tills något av följande villkor har uppfyllts:

• Resonemangsmotor-LLM:en avgör om begäran är fullständig. I detta fall bedömer den att användarbegäran har uppfyllts av svaret. Observera att en del av denna kontroll omfattar en jordningskontroll som verifierar att svaret är grundat i åtgärdsutdata. Ingen information i svaret bör konstrueras av resonemangsmotor-LLM:en, eftersom det kan leda till hallucinationer eller på annat sätt felaktiga svar.
• Inga fler lämpliga åtgärder hittas.
• Maximalt antal tillåtna LLM-anrop för det aktuella steget nås. Detta antal bestäms av själva resonemangsmotorn.

Åtgärder omfattas inte av en specifik tidsgräns. Syftet med detta är att undvika avbrott när tider för åtgärdsutförande varierar beroende på deras komplexitet. Vissa åtgärder är helt enkelt mer komplexa att utföra än andra.

Exempel i praktiken

Efter att resonemangsmotorn har startat en ordersökning utvärderar den svaret som har genererats hittills. Sedan beslutar den att det behövs mer arbete innan ett svar kan skickas tillbaka till användaren. Den är på väg att söka efter garantipolicyn nu när ordern finns i konversationshistoriken.

Agenten inser dock därmed att kunden i själva verket har köpt två klockor, vilket hämtas av åtgärden ”ordersökning”. Därför väljer nu resonemangsmotorn i den agentiska loopen att be kunden att ange vilken klocka de behöver garantiinformation om.

Undvik överdrivet specifika manus

Undvik att skriva överdrivet specifika manus för hur agenter ska ha konversationer med användare. Överdrivet specifika manus kan hämma en agents förmåga att skapa förtroende, förstå unika användarbehov och reagera effektivt i realtid på dynamiska omständigheter. Dessutom kan långa instruktioner göra att agenten reagerar långsammare och förvirra resonemangsmotorn. Att framtvinga determinism via instruktioner är inte den lämpligaste strategin.

Vad du inte ska göra

Det finns till exempel ingen anledning att be en agent att undvika att hänvisa till konkurrenter i servicesvar. Detta kan leda till oönskat beteende, eftersom agenten även kan vägra att svara på frågor som rör integrering med en leverantör som också är en konkurrent. Istället kan instruktionen se ut som ”Vid diskussioner om konkurrenter, svara med företagets intresse i åtanke.” På så sätt undviks begränsande, villkorliga instruktioner som ”Nämn bara konkurrenten xyz när det gäller…” och istället utnyttjas LLM:ens resonemangsfunktioner. Detta exempel visar hur instruktioner kan ges på en högre, mer abstrakt nivå, ungefär som en mänsklig servicemedarbetare skulle utbildas efter att ha börjat på företaget.

Vi ska titta på några fler exempel på vad du inte ska göra. Här är några dåliga instruktioner som ges till en serviceagent som hanterar kandidatprofiler på en rekryteringswebbplats. Dessa instruktioner försöker förutse varje möjligt kundyttrande och bör därför undvikas:

Instruktion 1: Agenten får följande yttrande: ”Kan jag lägga till en bild i min profil?”, fråga omedelbart kunden: ”Vilken profiltyp har du?”

Instruktion 2: Om kunden anger en premiumprofil, svara ”Låt mig kontrollera dina kontraktsuppgifter” och sök sedan efter kontraktsuppgifter och kontrollera om det har avtalats att de kan uppdatera profilbilden.

Om det har avtalats att kandidaten kan göra det, svara ”Ja, det är möjligt. Jag kan uppdatera den åt dig. Kan du skicka din nya bild?” När bilden har tagits emot, uppdatera kandidatens profil med den. Om ändringar av profilbilden inte ingår i kontraktet, säg ”Detta är tyvärr inte möjligt. Jag vidarebefordrar dig till en mänsklig agent.”

Instruktion 3: Icke-premiumprofil: Om kunden anger en icke-premiumprofil, svara: ”Du kan inte uppdatera din bild. Meddela mig om du vill göra det, så överför jag dig till en mänsklig agent.”

Instruktion 4: Om profiltypen är oklar, svara: ”Jag förstod inte din profiltyp.”

Vad du ska göra istället

Istället för denna typ av detaljstyrning ska du använda en mer flexibel strategi som instruerar agenternas beteende. Utgå från följande bästa praxis:

1. Använd RAG-/kunskapsåtgärder för policyer och regler som finns i kunskapsartiklar (istället för att skriva dem som instruktioner). Relevant information hämtas vid rätt tidpunkt. I exemplet ovan innebär det att en kunskapsartikel med titeln ”Bilduppdatering” bör innehålla följande: ”Endast kandidater med en premiumprofil vars kontrakt tillåter bildändringar kan uppdatera sin bild.”
2. Beskriv de viktigaste riktlinjerna och skyddsräckena individuellt, oberoende av konversationen. Ge agenter en kort och koncis förklaring av det förväntade beteendet eller den aktuella proceduren.

Baserat på denna bästa praxis kan en bättre uppsättning instruktioner se ut så här:

Instruktion 1 : ”Använd kunskapsåtgärder för att kontrollera policyer vid begäranden om kontoändringar.”

Instruktion 2 : ”Svara inte på frågor för vilka ingen tillämplig policy hittades.”

Om riktlinjerna ovan tillämpas kan agentens resultat förbättras. Om kunden ber agenten om en profiländring förstår agenten nu att den behöver hämta den nödvändiga policyn från kunskapsbasen, tolka reglerna som hämtats, tillämpa dessa regler på kontexten och slutligen svara kunden. I motsats till överdrivet specifika manus är denna beteendestrategi mycket mer generell och allmänt tillämplig. Utan att behöva skriva ut varje möjlig konversation kan agenten nu flexibelt svara med önskat beteende på ett bredare spektrum av konversationsämnen.

Tillämpa åtgärdssekvens (gäller inte agentskript)

Observationsprompten innehåller instruktioner och åtgärdsbeskrivningar men utan någon definierad ordning. Om åtgärdssekvensen är viktig måste den uttryckligen anges i samma instruktion. Observera att med agentskript kan vi tillämpa en utförandeordning tack vare övergångar. Det förklaras närmare i sjätte kapitlet.

Vi ska fortsätta med exemplet om agenter på rekryteringswebbplatsen. Agenten bör kunna hantera intervjuplanering med lämplig intervjuare. För att göra det bör agenten först kontrollera rekryterarnas tillgänglighet och sedan föreslå tre möjliga tider för kandidaten.

I detta fall bör instruktionerna inte vara i separata rutor för att upprätthålla utförandets ordning:

1. Instruktion 1: Kontrollera intervjuarnas tillgänglighet.
2. Instruktion 2: Föreslå då lämpliga tider för kandidaten.

Dessa instruktioner fungerar inte eftersom resonemangsmotorn inte vet vad ”då”-satsen i instruktion 2 avser. Detta beror på att instruktionerna skickas till resonemangsmotorn som en grupp, inte i någon särskild ordning.

Istället bör sekvensdefinierande instruktioner kombineras till en sats och skrivas som nedan:

1. Instruktion 1: Kontrollera intervjuarnas tillgänglighet. Föreslå då lämpliga tider för kandidaten.

Tillämpa åtgärdsutdata utan att skriva om

Resonemangsmotorn i sig är en LLM. Den ansvarar för att generera det slutliga svaret enligt den agentiska loopen. Strategin behövs för att tillämpa agentinstruktioner som tillhandahåller skyddsräcken för svarsgenerering, eller för att kombinera utdata från flera åtgärder som var en del av den agentiska loopen, för att uppfylla användarbegäran.

Men när det förväntas att bara en promptåtgärd har utförts kan en instruktion implementeras för att instruera agenten att aldrig ändra en åtgärds utdata. Detta ger ett mer förutsägbart och tillförlitligt agentbeteende.

Det är avgörande att tillämpa denna strikta efterlevnad i godkända promptmallar i vissa scenarier, särskilt när enhetlighet, efterlevnad och fördefinierade meddelanden är viktiga. Här är två exempel:

• Reglerade branscher: Organisationer som är verksamma inom starkt reglerade sektorer (till exempel finans, hälso- och sjukvård eller juridik) kräver ofta strikt kontroll av all kundorienterad kommunikation. Godkända promptmallar säkerställer att svaren uppfyller juridiska och regulatoriska krav, vilket minimerar risken för feltolkning, skadeståndsskyldighet eller spridning av felaktig information.
• Förhandstestade och validerade svar: När promptmallar har genomgått noggranna tester och validering för att säkerställa noggrannhet, effektivitet och önskade resultat. Vid avvikelser från dessa mallar kan deras effektivitet och värde undergrävas. Strikt efterlevnad säkerställer att de beprövade meddelandena levereras på ett enhetligt sätt.

Denna instruktion begränsar agentens frihet att ändra åtgärders utdata. Se till att instruktionen hänvisar till promptmallens utdata (till exempel ”promptResponse”), som visas i denna ämnesplanerare.

Instruktionen i detta fall kan därför vara följande:

” Ändra inte promptResponse-utdata, oavsett agentens kanal. ”

Begränsningar av tillämpning av strikt efterlevnad:

När en interaktion kräver flera distinkta agentåtgärder är det inte möjligt att tillämpa strikt efterlevnad av en enda mall. Faktum är att resonemangsmotorn i detta scenario behöver konsolidera dessa åtgärder till ett enda svar och därför ändra varje enskild åtgärds utdata.

Optimalt antal instruktioner

Baserat på allmänna LLM-egenskaper varierar målantalet instruktioner mellan fem och tio, beroende på instruktionernas komplexitet och interaktion. Dessa instruktionsegenskaper påverkar antalet instruktioner som resonemangsmotorn kan följa:

• Tydlighet och specificitet: Väldefinierade regler är enklare att följa.
• Konflikter mellan regler: Om regler motsäger varandra krävs ytterligare logik för att lösa dem.
• Längd och komplexitet: Om varje regel kräver djupgående resonemang kan du dela upp dem i mindre instruktioner.

Om det är mycket viktigt att en instruktion följs uttryckligen kan du lägga till termer som visar deras betydelse:

• brådskande och viktigt (omedelbart, brådskande, kritiskt, viktigt, obligatoriskt)
• befogenhet och tillämpning (obligatoriskt, nödvändigt, strikt tillämpat)
• konsekvenser och varningar (överträdelse kommer att resultera i, underlåtenhet att följa kommer att leda till, bristande efterlevnad kan resultera i, strikta påföljder tillämpas, nolltolerans)
• tydlighet och direkthet (måste, otillåtet, förbjudet, inte tillåtet, alltid/aldrig).

Att grunda svar i data förbättrar agenternas tillförlitlighet och trovärdighet avsevärt. Grundade svar baseras snarare på faktainformation än spekulationer eller föråldrad kunskap. Retrieval Augmented Generation (RAG) är en allmänt använd teknik som gör det möjligt för en agent att få tillgång till och använda en kunskapsbas för att formulera mer exakta och kontextuellt relevanta svar. Baserat på en användares fråga använder en agent RAG för att hämta relevant information från tillämpliga datakällor och kompletterar sedan prompten med denna information innan den skickas till LLM. En agent som använder RAG har högre kvalitet, noggrannhet och övergripande nytta av agentinteraktioner, vilket ökar användarnas förtroende och nöjdhet. Bästa praxis för RAG beskrivs utförligt i en offentligt tillgänglig vitbok som heter Agentforce och RAG: bästa praxis för bättre agenter.

Kunskap kontra instruktioner

Det är viktigt att skilja mellan kunskap och instruktioner när det gäller att hitta rätt balans mellan vägledning och flexibilitet, eftersom de har olika syften:

• Kunskap: Du kan se kunskap som biblioteket med böcker som agenten har tillgång till när de genererar sina svar. Några exempel är dokument, kunskapsartiklar och rapporter. Observera att dessa kan omfatta policyer och allmänna företagsregler. Kunskap kan också avse transaktionsfiler, till exempel e-postmeddelanden, samtalsutskrifter och till och med historiken för (agent-)konversationer. Slutligen omfattar kunskap långtextfält i strukturerade data. Kunskap skickas vanligtvis till agenten via RAG.
• Instruktioner: Du kan se instruktioner som den minsta uppsättningen regler som klargör för agenten när varje åtgärd ska användas. Instruktioner kan också införa skyddsräcken för hela konversationen, till exempel obligatoriskt tonfall. Instruktionerna kan ofta göras mer kortfattade och flexibla utan att tydlighet eller syfte påverkas. Istället för att tillhandahålla ett stelt manus med specifika svar för varje möjligt kundscenario kan du implementera allmänna riktlinjer och principer som hjälper agenten att välja rätt åtgärder i en mängd olika situationer.

Retrieval Augmented Generation (RAG)

Retrieval Augmented Generation (RAG) fungerar som ett intelligent datalager för kunskap. Den ger agenter tillgång till information i olika format och tillhandahåller relevanta textfragment för att svara på frågor. Med hjälp av RAG kan agenter få mer exakta LLM-svar utan att överbelasta LLM-prompten med irrelevant innehåll eller överskrida dess kontextfönster.

Vid körning utför RAG tre steg:

1. Hämtning: AI-systemet söker i en stor databas eller kunskapskälla för att samla in relevant information till LLM-prompten. Detta görs med hjälp av semantisk sökning, en mer avancerad teknik jämfört med traditionell nyckelordsbaserad sökning. Till skillnad från nyckelordssökning, som matchar exakta termer, förstår semantisk sökning ordens betydelse eller kontext. Den identifierar relevant information baserat på koncepten eller relationerna mellan termer, snarare än att bara leta efter exakta ordmatchningar. Nyckelordssökning kan också ingå i denna hämtningsprocess, vilket stärker den semantiska sökningen med nyckelordsmatchning för specifik terminologi eller specifika namn. Denna typ av sökning kallas hybridsökning.
2. Förstärkning: Den hämtade informationen läggs till i prompten.
3. Generering: LLM:en genererar ett kontextuellt lämpligt och mer exakt svar tack vare prompten som förstärktes med hämtad kunskap.

I Agentforce kan RAG användas med eller utan en promptmall:

1. Promptbaserad RAG: Med denna strategi finns instruktionerna som anger hur svaret ska genereras i promptinstruktionerna i en promptmall. I detta fall beror svaret helt på vad LLM:en genererar. Förutom promptinstruktionerna finns det olika sätt att påverka svaret, till exempel LLM-konfigurationsinställningar i Einstein Studio, men resultatet är ändå inte deterministiskt.
2. Resonemangsmotorbaserad RAG: Istället för att använda en promptmall använder agenten en åtgärd som hämtar delar (via ett flöde eller en Apex-klass) och lagrar dem i en variabel (se nästa sektion). Med denna strategi genererar resonemangsmotorn (istället för LLM:en) svar direkt, grundat i hämtade data. Instruktionerna som styr svarsgenerering är agentinstruktioner snarare än promptmallinstruktioner. Variabeln med det hämtade innehållet kan fortfarande uttryckligen skickas som indata till en åtgärd. Den kan också ges till resonemangsmotorn genom att ge den standardåtkomst till variabelns innehåll. Denna strategi medför avvägningar. Det finns en potentiell risk för att överbelasta resonemangsmotorn med innehåll och ansvar. Dessutom är parametrarna för resonemangsmotorns LLM, till skillnad från en prompt, inte konfigurerbara. Å andra sidan kan resonemangsmotorn generera sitt svar med hjälp av både de hämtade delarna och konversationens historik.

Den rekommenderade metoden är alternativ 1. Det minskar antalet uppgifter som resonemangsmotorn ska utföra och förbättrar därmed svarskvaliteten. Nästa sektion utforskar ett undantag från denna regel, där innehållet bevaras under hela konversationen och därmed uttryckligen ges till en åtgärd.

Bästa praxis för RAG

• Undvik skriptade RAG-instruktioner: Istället för att länka instruktioner direkt till specifika artiklar för särskilda frågor kan du utnyttja RAG:s intelligens för att dynamiskt hitta den mest relevanta datakällan och det mest exakta textfragmentet. RAG:s matchningsprocess bygger på en bredare förståelse av frågan, inte bara exakt mappning mellan frågan och källan.
• Konsolidera ämnen: Gruppera relaterade frågekategorier under ett enda ämne. RAG kan effektivt identifiera relevanta svar baserat på frågetyp, även inom ett bredare ämne. Till exempel kan produktfrågor som underhålls- och batteriproblem aggregeras till ett mer heltäckande ämne.
• Lagra RAG-utdata i en variabel: När gränserna för antalet interaktioner kan nås ska RAG-utdata lagras i en variabel. Detta gör informationen tillgänglig för att vägleda agentinteraktioner utöver standardtröskelvärdet. Ett exempel på detta ges i nästa sektion.

Vissa affärsprocesser kräver ännu mer förutsägbart utförande, till exempel tillämpning av en specifik åtgärdssekvens eller villkor för att utlösa åtgärder eller ämnen.

För att uppnå detta deterministiska beteende kan variabler användas. Variabler fungerar som en strukturerad form av korttidsagentminne som kan utgöra åtgärdsindata eller -utdata. Dessutom kan en variabels tillstånd styra utlösandet av specifika ämnen och åtgärder.

Olika sätt som variabler stöder determinism

Variabler kan bidra till att uppnå guidad determinism för agenter på följande sätt:

1. Beständig dynamisk grundning: Variabler gör det möjligt för agenter att kontinuerligt uppdatera sin förståelse av världen samtidigt som de sparar viktig information som förblir opåverkad av efterföljande interaktioner. Denna metod säkerställer att viktig information, som kan vara ostrukturerade data som hämtas via RAG eller strukturerade data som användarprofilinformation, underhålls under hela konversationen, oberoende av konversationens längd.
2. Åtgärdsindata/-utdata: Variabler kan användas som både indata och utdata för åtgärder. Åtgärden hänvisar uttryckligen till variabler och åtgärdens utförande är inte beroende av resonemangsmotorn för att ange dessa indata och utdata, vilket ökar agentens determinism.
3. Filtrering: Variabler kan användas för att fastställa villkorligt utförande av åtgärder eller ämnen. Variabler möjliggör ett specifikt informationsflöde mellan åtgärder och determinism vid åtgärdsutförande. Denna förmåga är särskilt avgörande för säkerhetsregler där åtgärder inte kan påbörjas om specifika indatavariabler, till exempel e-post, inte har verifierats.

Typer av variabler i Agentforce

Agentforce har två typer av variabler:

• Kontextvariabler är systemgenererade variabler som innehåller information om användaren och konversationssessionerna.
• Anpassade variabler kan instansieras av användaren. De innehåller valfri typ av information som används för något av de tre sätten som variabler stöder determinism.

Variabeltyper stöder följande funktioner:

Vi ska fördjupa oss ytterligare i variabler med ett exempel på användningsfall: en kundorienterad felsökningsagent. I detta exempel används variabler för alla tre syften: beständig dynamisk grundning, åtgärdsindata/-utdata och filtrering.

I detta exempel hjälper agenten en kund att felsöka ett tekniskt enhetsproblem. Felsökning innebär vanligtvis att gå igenom ett antal steg. Agenten bör erbjuda en serviceupplevelse som efterliknar en mänsklig serviceagents arbete. För att göra det bör agenten inte ge kunden alla felsökningssteg på en gång. Istället bör den erbjuda steg-för-steg-instruktioner samt möjligheten att navigera mellan steg (inklusive att gå tillbaka till tidigare steg) baserat på hur kunden svarar.

En utmaning med detta är agentens förmåga att behålla alla felsökningssteg under hela konversationen. Med tanke på agentens begränsade minne på grund av det begränsade antalet interaktioner den kan lagra kan dessa steg tas bort från resonemangsmotorns kontext om konversationen blir lång.

Denna utmaning hanteras genom att använda en variabel för att grunda resonemangsmotorn dynamiskt i felsökningsstegen. Genom att hämta informationen och lagra den i en variabel förblir den tillgänglig och kan uppdateras under hela konversationen. Resonemangsmotorn använder informationen som lagras i denna variabel för dynamisk grundning.

I detta exempel innehåller ett ämne två åtgärder. Dessa två åtgärder behövs för att säkerställa ett enhetligt dataflöde. Den första åtgärden används för att fylla i variabeln som innehåller alla felsökningssteg. Den andra åtgärden använder den variabeln under själva felsökningen.

1. Åtgärd 1: ”Fyll i problemlösningssteg”. Detta är den inledande åtgärden, som utlöses av agentens första introduktion till problemet. Den använder Retrieval Augmented Generation (RAG) för att extrahera alla nödvändiga lösningssteg från en indexerad kunskapsbas. Åtgärden lagrar resulterande utdata i en variabel med namnet ”Lösningssteg”.
2. Åtgärd 2: ”Använd mitt i problemlösning”. Detta är en åtgärd baserad på en prompt vars utdata är det mest sannolika nästa felsökningssteg som ska användas under felsökningsprocessen. Agenten instrueras att använda denna åtgärd mitt i problemlösningen.

Den ursprungliga kundfrågan är indata till båda åtgärderna. Den andra åtgärden har andra indata: innehållet i variabeln ”Lösningssteg”. Denna variabel har angetts av den första åtgärden. Observera att den andra åtgärden inte kommer att hämta själva felsökningsstegen, utan istället hämta dem som indata från den första åtgärden via variabeln. Följande diagram visar dataflödet mellan dessa två åtgärder.

Åtgärden ”Använd mitt i problemlösning” hänvisar alltid till de ursprungliga felsökningsstegen som hämtas av åtgärden Problemlösningssteg. Detta dataflöde säkerställer att felsökningsstegen upprätthålls sammanhängande och alltid finns tillgängliga, oberoende av konversationens längd.

För att utföra de åtgärder som definieras i detta exempel behövs specifika instruktioner, till exempel ”Utför alltid ’Fyll i lösningssteg’ först”. Med tanke på den icke-deterministiska karaktären hos LLM:er som används av agenter kan detta dock leda till en annan ordning i vissa fall. För att säkerställa en deterministisk utförandeordning introducerar vi villkorliga filter för dessa variabler för att tillämpa rätt åtgärdssekvens. Agenten läser värdet av variabeln ”Lösningssteg” och definierar två filter beroende på om denna variabel har ett värde eller inte.

• Åtgärden Problemlösningssteg kan endast utföras om variabeln ”Lösningssteg” är tom.
• Åtgärden ”Använd mitt i problemlösning” kan endast utföras om variabeln ”Lösningssteg” har ett värde.

Dessa villkorliga filter tillämpar nu deterministiskt sekvensen för åtgärdsutförande: Åtgärden ”Använd mitt i problemlösning” måste vänta tills ”Problemlösningssteg” har slutförts, vilket säkerställer att variabeln ”Lösningssteg” alltid har ett värde.

För att säkerställa korrekt åtgärdsutförande krävs en tredje åtgärd för att återställa variabeln ”Lösningssteg” om problemet är helt löst. Därmed återställs agenten till nödvändigt tillstånd för att hjälpa till med ett annat, nytt problem. Denna tredje åtgärd har namnet ”Töm lösningsvariabeln”. Det fullständiga åtgärdsdiagrammet visas nedan.

Variabler är avgörande för att vår felsökningsagent ska kunna lösa kundproblem genom att möjliggöra följande:

• Beständig dynamisk grundning: Variabler lagrar felsökningssteg och säkerställer att de är tillgängliga under hela konversationen, oavsett längd och antal interaktioner. Det förhindrar att agenten glömmer kontexten.
• Dataflöde: Variabler underlättar dataflödet mellan åtgärder. Till exempel lagrar variabeln ”Lösningssteg” de hämtade felsökningsstegen från åtgärden Problemlösningssteg och tillhandahåller dem som indata till åtgärden ”Använd mitt i problemlösning”.
• Determinism: Variabler kan användas som filter för att tillämpa en specifik ordning för åtgärdsutförande. Till exempel utförs åtgärden Använd mitt i problemlösning endast om variabeln Lösningssteg har ett värde, vilket säkerställer att åtgärden Problemlösningssteg körs först.

I den generativa AI-eran är prediktiv AI fortfarande avgörande eftersom den utgör den grundläggande intelligens som vägleder, förbättrar och kontextualiserar generativa förmågor. Medan generativ AI fokuserar på att skapa nytt innehåll – såsom text, bilder eller videor – gör prediktiva modeller förutsägelser om framtiden baserat på indata från affärsdata i realtid. Några exempel på affärsresultat är sannolikhet för kundbortfall, sannolikhet för konvertering, sannolikhet för eskalering av ärenden, kundens livstidsvärde och ärendeklassificering. Förutsägelser kan förutse användarnas behov, anpassa utdata, verkställa beslut, optimera innehållsrelevans i realtid – allt genom att analysera trender och siffror. I applikationer som anpassad inlärning, hälso- och sjukvård eller finansiell planering säkerställer till exempel prediktiv AI att generativa utdata överensstämmer med individuella kontexter och sannolika framtida scenarier. Tillsammans skapar prediktiv och generativ AI en kraftfull synergi där framsynthet kombineras med kreativitet för att skapa mer intelligenta, adaptiva och kraftfulla tekniklösningar.

Så här integrerar du prediktiva modellutdata i agentarbetsflöden

Om du vill integrera prediktiva modellutdata i agentarbetsflöden lägger du bara till prediktiva modellåtgärder i Agentforce-tillgångarna. Modellverktyget gör det möjligt att skapa eller registrera prediktiva modeller (BYO) som sedan används av agenten för att ge förutsägelser. De resulterande förutsägelserna (samt prediktorerna) kan lagras i anpassade variabler. Agenter kan använda dessa variabelvärden som indata till, och villkora utförandet av, specifika åtgärder och ämnen.

Exempel på användningsfall som är integrerade med prediktiva modeller

• Segmentering: Utför klassificering i flera klasser för kundsegmentering och använd det resulterande segmentet för att filtrera vissa åtgärder. Förbehåll till exempel premiumåtgärder för kunder på premiumnivå.
• Sannolikhet för eskalering: Förutsäg sannolikheten för eskalering av ett serviceärende. Om denna sannolikhet överskrider ett visst tröskelvärde, tillåt utförande av åtgärder som löser ärendet snabbare eller eskalerar till mänskliga agenter snabbare.
• CPG: Planera endast en kampanj om försäljningsökningen (poäng som beräknas av en prediktiv modell) överskrider ett visst tröskelvärde.
• Handel: Föreslå endast en produkt om köpbenägenheten överskrider ett visst tröskelvärde.

Vissa affärsprocesser måste utföras i en exakt ordning och kräver inte användarindata under utförandet. I detta fall kan ett förutbestämt flöde av steg tillämpas via flöden, API:er eller Apex. Om du har ett befintligt flöde som är nödvändigt i produktionen är det en bra indikation på att det kan lagras och användas av agenten för att utföra den affärsprocessen. Alla exempel nedan omfattar förutbestämda sekvenser av steg som agenten kan utföra utan användarindata. Det agentiska beteendet i detta fall består i att identifiera vilken deterministisk process som ska utföras, hur nödvändiga indata ska samlas in och hur utdata ska tolkas och bearbetas.

Affärsprocesser med många sekventiella steg (fler än tre som tumregel) och många beroenden av variabler blir för komplexa och besvärliga att tillämpa med instruktioner. I detta fall är det möjligt att helt enkelt hårdkoda dem med hjälp av de deterministiska åtgärdstyper som anges i denna sektion. Observera slutligen att dessa implementeringar kan omfatta icke-deterministiska element, till exempel anrop av LLM:er med lösta promptmallar. Därför är de inte nödvändigtvis helt deterministiska, från början till slut, och de kan fortfarande ha de önskade flexibilitetsnivåerna som agenter är kända för.

Stegsekvensen i en marknadsföringsresa villkoras av fasta regler och är inte beroende av konversationsanvändarindata. Därför kan flödet användas som en Agentforce-åtgärd. En anropbar åtgärd kan skapas för att slutföra bakgrunds- eller händelseutlösta uppgifter från en lösningskomponent som kan anropa ett flöde eller en Apex-klass. Lägg till en anropbar åtgärd i ett flöde eller en Apex-klass och ange den uppgift som agenten slutför samt de villkor som utlöser agenten. Anropbara åtgärder kan också innehålla agentens kontextvariabler och vidarebefordra viktig information.

Salesforce-flöden kan användas för att automatisera rutinuppgifter, till exempel skapa uppföljningsuppgifter, skicka e-postpåminnelser eller uppdatera poster. Flöden gör arbetet mer effektivt och produktivt. Agenter kan också utföra flöden med hjälp av flödesåtgärder. Tack vare determinismen är flöden ett bra sätt att rikta agentiskt beteende när en affärsprocess behöver utföras i en viss sekvens. En bra indikation på att en flödesåtgärd är lämpligast är när ämnet annars skulle innehålla instruktioner som ”Gör först detta, gör sedan detta och gör slutligen detta”. Det blir besvärligt att hantera tillämpning av sekvenser med fler än tre steg via instruktioner och variabler.

Flöden kan också omfatta icke-deterministiska element genom att anropa promptar. En promptnod i flödet anropar en promptmall och samlar in svaret som kan vidarebefordras till andra element i flödet. Dessa ytterligare element kan återigen vara promptnoder, till exempel som sammanfattar föregående svar, vilket skapar en kedja av promptar. Detta är särskilt användbart när reglerna för promptkedja definieras av fasta element och inte är beroende av användarindata. Ett exempel är agentisk RAG där en fördefinierad sekvens av hämtningsverktyg eller promptar i ett flöde kan få åtkomst till specifika datakällor i en viss ordning, till exempel initialt hämta data från en användares landsdokument innan andra källor konsulteras efter behov. Denna kedjemekanism möjliggör en tillförlitlig och ordnad utvinning av relevant information.

I likhet med flöden är Apex- och API-åtgärder deterministiska på så sätt att en fördefinierad sekvens av åtgärder kan kodas. Dessa åtgärder kan omfatta icke-deterministiska element, till exempel anrop av promptmallar eller LLM-anrop. Men i sin definition utför de dessa steg deterministiskt, vilket minskar den agentiska variationen genom att anropa åtgärden vid rätt tidpunkt, samla in nödvändiga indata och bearbeta utdata. Dessa ansvarsområden måste ändå styras av agentiska instruktioner, så de är icke-deterministiska. Apex- och API-åtgärder är pro-kod-motsvarigheten till flödesåtgärder.

Från sannolikhetsbaserat till deterministiskt resonemang

På nivå 1 till 5 av determinism lade vi successivt till struktur i agentens miljö. Vi definierade vad den kunde göra (nivå 1, ämnen), guidade sedan hur den skulle bete sig (nivå 2, instruktioner), grundade den i sanning (nivå 3, data), hanterade dess tillstånd (nivå 4, variabler) och gav den stela verktyg (nivå 5, deterministiska åtgärder). Den centrala beslutsmotorn förblev dock i grunden sannolikhetsbaserad. Resonemangsmotorn bestämde fortfarande själv vilket verktyg som skulle väljas eller vilken fråga som skulle ställas härnäst, och för detta beslut förlitade vi oss helt på den stora språkmodellen (LLM).

Nivå 6, agentskript, förändrar denna arkitektur i grunden. Den introducerar möjligheten att hårdkoda själva resonemangsprocessen.

Med agentskript går vi från att prompta modellen till att skripta agenten. Det är inte en återgång till stela, gammaldags chattbottar. Istället kallar vi det hybridresonemang. Det gör att du kan placera LLM:ens kreativa, konversationsbaserade kraft mellan lager av oföränderlig, deterministisk logik. Du definierar uttryckligen den kritiska utförandevägen (”måsten”) samtidigt som du lämnar specifika fickor av frihet så att LLM:en kan hantera förståelse för naturligt språk och svarsgenerering.

När arbetsflöden utformas är det avgörande att undvika att använda LLM-baserade agenter som använder skript, bara för att ersätta deterministisk logik där nästa steg redan är tydliga och fasta. Om en process följer en förutsägbar väg utan behov av komplext resonemang för att avkoda efterföljande åtgärder leder införandet av en generativ modell till onödig latens, kostnad och utrymme för fel. Traditionella programmatiska flöden förblir överlägsna för processer som är helt deterministiska och inte kräver resonemang. Användning av en LLM för enkel routing eller linjära övergångar är ett alltför tekniskt val som äventyrar tillförlitligheten hos ett system som annars skulle kunna hanteras av ett standardiserat procedurflöde.

Som tumregel bör agentiska lösningar beaktas när systemet hanterar ostrukturerade indata som måste sammanställas från olika källor med hög variation (eventuellt inklusive konversationsindata) innan ett beslut kan fattas.

Men hur uppnår du den nivån av kontroll? Det finns två olika vägar som är utformade för både affärsarkitekten och den avancerade kodutvecklaren.

Du behöver inte nödvändigtvis skriva kod för att tillhandahålla determinism på nivå 6 till din agent. Salesforce tillhandahåller två modaliteter för att generera det underliggande agentskriptet, vilket demokratiserar tillgången till deterministiska resonemang.

Nivå 6 är tillgänglig direkt i agentbyggaren för affärsanalytiker, administratörer och användare med låg kod.

Vi har introducerat en arbetsyta i dokumentstil som fungerar som ett text-till-skript-gränssnitt. Istället för att skriva kod skriver du ämnets logik med strukturerat, naturligt språk. Byggaren tolkar sedan ditt syfte och kompilerar det till agentskript i bakgrunden.

• Du skriver: ”Kontrollera först om beställningen är äldre än 30 dagar. Om så är fallet, meddela användaren att vi inte kan ta emot returer och avsluta artigt konversationen. Om så inte är fallet, fråga om varans skick.”
• Systemet kompilerar automatiskt denna berättelse på naturligt språk till nödvändiga if/else-strukturer, variabelkontroller och end_conversation-kommandon.

Det gör att du kan skriva logiken på naturligt språk och låta plattformen konvertera den till kod, vilket säkerställer att även icke-programmerare kan tillämpa stela skyddsräcken och determinism.

Utvecklare som vill ha maximal precision kan även skriva agentskript direkt i agentbyggaren. Arbetsytan med berättelsen på naturligt språk kan vändas för att se det underliggande skriptet, så att utvecklaren nu kan koda skriptet direkt. Denna strategi möjliggör till och med en hybridredigeringsupplevelse: Vissa instruktioner skrivs på naturligt språk på arbetsytan, medan andra skriptas (eller befintliga modifieras) direkt med kod. Genom att gå fram och tillbaka mellan dessa två upplevelser ser du att de två modaliteterna alltid är perfekt samordnade.

Båda modaliteterna frigör den fulla potentialen hos nivå 6:

• Detaljerad spårning: Du kan gå igenom skriptkörningen för att se exakt var variabler har ändrats eller grenar har tagits.
• Komplex loophantering: Hantera sofistikerad logik för upprepade försök eller tillståndsändringar för flera variabler som är svåra att beskriva på naturligt språk.
• Versionskontroll: Behandla agentbeteende som kod, kompatibel med git- och CI/CD-pipelines för agentversionering.

Oavsett om du genererar agentskript via byggaren eller skriver det för hand resulterar det i samma utdata: Agentskript konverteras till ett agentdiagram som körs av Atlas resonemangsmotor.

För att behärska nivå 6 måste du förstå vad som händer under huven. Agentskript kontrollerar beteende genom specifika programmatiska strukturer inom resonemangsblock. Till skillnad från standardpromptar, som är förslag som LLM:en kan följa, är detta kommandon som utförs oavsett vad. Det är antingen före, under eller efter resonemangsprocessen, och de finns i flera olika typer av determinism. Vi går först igenom några av dessa mönster generellt och ger några lätta exempel. Sedan illustrerar vi dem ytterligare med exempel på arkitekturritningar av skriptade agenter.

På nivå 1–5 hoppades vi att agenten skulle göra något (utföra en åtgärd) före eller efter ett visst steg i processen. På nivå 6 tvingar vi den. Det som skrivs i before_reasoning- och after_reasoning-block utförs alltid före respektive efter att LLM:n anropas för att resonera baserat på instruktioner. Det kan vara att köra andra åtgärder, övergå till ämnen, ange variabler och så vidare.

Genom att använda run-kommandot i ett ämnes before_reasoning-instruktioner kan du exempelvis utföra en åtgärd även innan LLM:en anropas för att generera ett svar. Det säkerställer att data blir tillgängliga omedelbart, vilket eliminerar resonemangslatens eller risken för att agenten glömmer att anropa verktyget.

Skriptstrukturen:

Med villkorlig determinism kan du använda standardprogrammeringslogik för att styra flödet. Det är avgörande för efterlevnadsarbetsflöden där steg inte kan hoppas över eller omformas.

Skriptstrukturen:

I detta exempel får LLM:en aldrig möjlighet att hallucinera ett godkännande för en icke-VIP-användare. Grenen tas deterministiskt av motorn.

En annan kraftfull kontroll är möjligheten att tvinga ut agenten ur det aktuella ämnet och in i ett annat. Det förhindrar att agenten fastnar eller avleds till orelaterade konversationer.

Skriptstrukturen:

Denna övergång är inte ett förslag. Det är en hård omdirigering av utförandeflödet som är beroende av en variabels värde. Observera att även om omdirigeringen är hård och inte förhandlingsbar sker en normal resonemangsprocess igen inom ämnet som agenten nu tvingas till.

Dessutom har du med agentskript möjlighet att uttryckligen tvinga fram en övergång från en åtgärd till nästa omedelbart efter slutförandet. Denna funktionalitet säkerställer att agenten följer ett stelt, deterministiskt flöde snarare än att använda sannolikhetsbaserat eller autonomt beslutsfattande i varje steg. Genom att koppla samman dessa åtgärder i en fördefinierad sekvens kan du garantera att specifika uppgifter utförs i en exakt ordning, vilket ger total kontroll över agentens logik och beteende.

Agentskript ger dig direkt läs-/skrivåtkomst till agentens korttidsminne (variabler). Du kan uttryckligen ange variabler baserat på åtgärdsutdata, vilket förhindrar en visklek där en LLM kan misstolka ett verktygs JSON-utdata.

Skriptstrukturen:

För att verkligen förstå kraften hos agentskript måste vi se bortom enskilda kommandon och observera dem tillsammans. Följande arkitekturmönster (hämtade från vår samling med recept på agentskript ) visar hur nivå 6-determinism löser komplexa företagsutmaningar.

Problemet: Standardagenter drabbas ofta av resonemangslatens. De väntar på att användaren ska ställa en fråga och funderar sedan på vilket verktyg de ska använda. Sedan kanske de till och med frågar användarinformationen som redan kan ha hämtats, och först därefter anropar de åtgärden. Det ger en fördröjd och osammanhängande upplevelse. Agentskriptet: Determinism före resonemang.

Vi använder run-kommandot för att injicera data innan LLM:en ens vaknar.

Exempel: Agenten för prioritering i nödsituationer. Tänk dig en agent som hanterar en rapport om strömavbrott. I stället för att be om användarens adress och vänta kör skriptet automatiskt kommandot get_current_location_by_IP och check_grid_status så snart sessionen startar.

Resultatet: Agenten inleder inte med ”Hur kan jag hjälpa dig?” Den inleder med: ”Jag ser att du ringer från den norra sektorn där det finns en bekräftad transformatorbrand. Jag har redan lagt till ditt hushåll i prioritetslistan för återställning. Kör du en reservgenerator?”

Logiken:

Långa promptar (som ger agenten alla regler på en gång) leder till ökad sannolikhet för hallucinationer i resonemangsprocessen. Agenten glömmer regel A eftersom den tittar på regel Ö.

Agentskriptlösningen: Just-in-time-instruktionsinjicering med villkorlig grundning genom en kombination av RAG och villkorlig logik. Den visar bara agenten de regler som gäller för det exakta konversationsögonblicket.

Exempel: Tillhandahålla regler för okvalificerade erbjudanden. Varför ge agenten reglerna för att begära kredithöjningar när kundens kreditpoäng inte ens möjliggör det från början?

Logiken:

Villkorlig grundning är att eliminera risken för fel genom att ta bort den distraherande informationen helt när den inte behövs.

Problemet: I en komplex agentkonversation (till exempel en bolåneansökan, jobbscreeningintervju eller en teknisk felsökningssession) upprätthåller agenten en lista över frågor som måste besvaras så att all nödvändig information samlas in från användaren. Användare kommer dock ofta in på sidospår. En standardagent kan följa sidospåret och glömma att komma tillbaka till dessa måste-frågor, vilket leder till att ansökan eller konversationen blir ofullständig.

Kärnan i detta system är tillståndsbaserad navigering, som behandlar konversationen som en rigorös checklista som måste bockas av helt innan någon övergång kan ske.

Med tillståndsbaserad navigering går agenten mellan ämnen baserat strikt på aktuellt variabeltillstånd eller är låst inom ett ämne tills specifika villkor är uppfyllda. Det förhindrar att agenten följer otillåtna vägar, även när en användare försöker göra att konversationen spårar ur med sidospår. Om en användare till exempel ber om filialers öppettider i en viktig bolåneansökan försöker agenten inte bara hålla sig på rätt spår. Istället upptäcker skriptet avvikelsen och kan utlösa en framtvingad övergång till ett ämne för efterlevnadsåterställning. Genom att låsa agenten i ett specifikt ”logikrum” blir det matematiskt omöjligt för den att diskutera icke godkända ämnen eller avsluta en session innan alla måste-variabler har samlats in.

Exempel: Underhållsinspektören – en agent guidar en tekniker genom en säkerhetskontroll med tio punkter för en flygplansmotor. Teknikern säger: ”Vänta, jag märkte även en repa på flygkroppen.”

Beteendet:

1. Agenten bekräftar repan (naturligt språk).
2. Den loggar repan till en variabel (tillståndshantering).
3. Den vägrar att stänga sessionen eller byta ämne innan den bekräftar: ”Jag har noterat repan på flygkroppen, men vi kan inte gå till ”Exteriör” förrän du har bekräftat momentinställningen på intagsventilen. Vad var avläsningen?”

Logiken:

En guidad konversation bör dock vara mer än bara en sekventiell lista med frågor. Annars är agenten mer som ett ”formulär i förklädnad”. Dess primära värde ligger i intelligent prioritering – att använda initiala upptäcktsfrågor för att dirigera användaren till rätt formulär eller arbetsflöde.

Övergången från ett enkelt skript till ett robust agentskript blir logisk när komplexiteten ökar. Istället för att bara fråga börjar agenten att göra: Agenten kan till exempel extrahera felsökningssteg från dokumentation, navigera i interna policyer eller utföra API-anrop till externa system för att lösa problem i realtid.

Med introduktionen av agentskript som nivå 6 i ramverket för nivåer av determinism har du nu ett komplett spektrum av kontroll, från den öppna kreativiteten hos ett ämne på nivå 1 till den stela, koddrivna logiken hos ett agentskript på nivå 6.

Men att ha en hammare gör inte varje problem till en spik.

Det vanligaste misstaget är att tro att ”högre är bättre” och att agenter nu bör kontrolleras fullt ut med skript för alla frågor. Det är inte sant. Den verkliga konsten med agentarkitektur och -design ligger i rätt dimensionering av determinismen genom att tillämpa precis tillräcklig kontroll för att säkerställa säkerheten, utan att äventyra den konversationsflexibilitet som gör AI värdefull från första början. Överskripta inte dina agenter i sådan utsträckning att de blir glorifierade chattbottar.

Detta kapitel ger ett beslutsramverk som hjälper dig att avgöra när du ska använda den guidade autonomin på nivå 1–5 och när du ska tillämpa den skriptade precisionen på nivå 6. Detta är inte strikta lagar, utan snarare tumregler, och är avsedda att ge ett kontextuellt ramverk för hur du kan tänka kring de olika alternativen och nivåerna för determinism.

Vi kan förenkla beslutet genom att dela upp de sex nivåerna i två olika strategiska zoner:

• Filosofin: ”Förtroende, men verifiering”. Du ger agenten mål, data och verktyg (som kan vara deterministiska, se nivå 5), men du låter resonemangsmotorn välja den bästa vägen för att nå dit.
• Mekanismen: Sannolikhetsbaserat resonemang. Agenten analyserar användarens syfte och väljer dynamiskt det bästa verktyget för jobbet.
• Bäst för: Upptäckt, allmänna frågor och svar, lågriskuppgifter, breda tjänsteomfattningar.

Du bör använda de sannolikhetsbaserade standardbeteendena på nivå 1 till 5 i följande fall:

1. Den rätta vägen är inte alltid densamma

I många konversationsscenarier är en stel, hårdkodad väg faktiskt en nackdel eftersom rätt konversationsväg varierar. Vid dynamiska interaktioner, till exempel personlig shopping eller semesterplanering, finns det ingen enskild rätt sekvens – en användare kan prioritera pris, plats eller bekvämligheter i vilken ordning de vill. I dessa fall leder framtvingande av ett tillståndsbaserat skript till en frustrerande robotliknande upplevelse, så det är mer effektivt att använda instruktioner för att definiera agentens profil och mål samtidigt som användaren får leda flödet. Denna strategi ökar också hastigheten till marknaden avsevärt, eftersom det ofta är överdrivet att skapa komplexa nivå 6-skript med kapslade variabler och grenar för uppgifter som interna HR-agenter för vanliga frågor. Genom att grunda agenten i data och RAG kan du kringgå behovet av ett omfattande manuellt skript och låta hämtningsmotorn hantera konversationen dynamiskt baserat på din befintliga kunskapsbas.

2. Skalning genom modulär determinism: Undvika underhållsmardrömmen

När din agents omfattning når en enorm skala, till exempel hantering av 500 olika IT-supportfrågor med egna processer, är den primära utmaningen inte om du kan skapa ett enda deterministiskt agentiskt skript, utan om du bör göra det. Att försöka mappa alla möjliga permutationer av 500 uppgifter till ett enda gigantiskt agentskript leder till en underhållsmardröm. Varje gång en policy ändras eller ett nytt felsökningssteg läggs till riskerar du att förstöra ett enormt, sammankopplat logiknät.

Lösningen är att gå från ett monolitiskt skript till deterministiska åtgärder på nivå 5. Istället för att skripta hela konversationen skapar du robusta, isolerade flöden för de värdefulla åtgärderna på toppnivå, till exempel lösenordsåterställning eller kontoupplåsning. Sedan låter du resonemangsmotorn fungera som en trafikledare, som identifierar användarens syfte utifrån deras unika formulering och dirigerar dem till lämplig deterministisk åtgärd. Med denna strategi får du det bästa av två världar: Tillförlitligheten hos ett skript för kritiska uppgifter och en flexibel, skalbar arkitektur som inte kollapsar under sin egen vikt när uppgiftsbiblioteket växer.

• Filosofin: ”Vad du än gör och resonerar, i vilket fall som helst, gör exakt detta.” Du definierar vägen. Agenten är gränssnittet för att utföra din logik. Den placerar agentens kreativitet i lager av måste-logik.
• Mekanismen: Deterministiskt resonemang. ”Hjärnan” följer ett förkompilerat diagram – LLM:en används endast för resonemang, förståelse för naturligt språk och svarsgenerering där skriptet tillåter det.
• Bäst för: Efterlevnad, finansiella transaktioner, diagnostiska träd, viktiga arbetsflöden och hårt reglerade branscher.

Observera att inom de deterministiska spår som nivå 6 erbjuder är alla alternativ från nivå 1–5 fortfarande tillgängliga.

Du bör uppgradera till agentskript när ”mestadels rätt” inte räcker.

1. Måste-grindarna (säkerhet och autentisering)

Om en användare ber om att överföra pengar kan du inte förlita dig på att LLM:en förmodligen begär autentisering. Du behöver en matematisk garanti för att autentiseringsflödet körs före transaktionsflödet.

• Agentskriptlösningen: Använd run @actions.verify_identity i ett before_reasoning-block eller högst upp i skriptet för att framtvinga efterlevnad innan LLM:en genererar en enda token.

2. Regelefterlevnad

Inom branscher som hälso- och sjukvård eller finans måste agenter ofta läsa en ansvarsfriskrivning ordagrant eller ställa frågor i en lagstadgad order.

• Agentskriptlösningen: Hårdkoda offentliggörandet.

3. Komplexa flerstegsberoenden och obligatoriska åtgärdssekvenser

Om steg B kräver utdata från steg A, och steg C beror på en beräkning från steg B, är det riskabelt att förlita sig på att en LLM skickar dessa variabler via promptkontext i en visklek. När utförandet av en viss åtgärd är strikt obligatoriskt efter en annan åtgärd måste sekvensen dessutom vara hårdkodad.

• Agentskriptlösningarna: Använd set @variables.x = @outputs.y för att uttryckligen binda data mellan steg, vilket säkerställer perfekt återgivning. Använd satserna run och @utils.transition för att koda sekvensen.

4. Förhindra ämnesavledning

Vid kritisk felsökning (t.ex. ”Min pacemaker piper”) vill du inte att agenten ska bli distraherad om användaren plötsligt frågar: ”Hur är vädret?”

• Agentskriptlösningen: Använd @utils.transition för att låsa användaren i ämnet Nödprotokoll tills problemet är löst, vilket uttryckligen inaktiverar möjligheten till avledning.

De mest mogna agentarkitekturerna väljer inte det ena eller det andra – de använder nivå 6 som skelettet och nivå 1–5 som musklerna. Det mönster som sedan uppstår är lager av determinism. Du kan använda agentskript för att hantera den kritiska början och slutet av en konversation, samtidigt som du lämnar mitten öppen för flexibelt resonemang.

• Steg 1 (nivå 6): Agentskript framtvingar prioritering och autentisering.
  • Resultat: Användaren identifieras säkert och syftet klassificeras.
• Steg 2 (nivå 1–5): Agentskript överlämnar till ett standardämne.
  • Resultat: Agenten använder standard-RAG och åtgärder, instruktioner och kanske till och med variabler för att flexibelt lösa användarens problem.
• Steg 3 (nivå 6): Agenten upptäcker att problemet är löst och övergår tillbaka till agentskript för de avslutande åtgärderna.
  • Resultat: Agentskript framtvingar insamling av CSAT-poäng och kompatibla hejdå-formuleringar.

Slutlig rekommendation: Börja med nivå 1–5 för hastighet och upptäckt, och övervaka loggarna. Där du ser att agenten har svårt med konsekvens, inte kan följa en sekvens eller hallucinerar parametrar kan du selektivt förstärka det specifika arbetsflödet med nivå 6.

Agentskript är den sista pusselbiten i att tillhandahålla determinism till agenter. Det bekräftar att AI är sannolikhetsbaserad, men affärer är deterministiska. Genom att använda agentskript (oavsett om det är via arbetsytan som stöder agentbyggande på naturligt språk eller i direktkod) begränsar du inte agentens intelligens – du fokuserar den. Du skapar ett system där konsten med konversationer möter vetenskapen om processutförande, vilket säkerställer att dina viktigaste arbetsflöden körs exakt som de är utformade, varje gång.

Nivå 6 är också insikten att autonom inte betyder okontrollerad.

I flera år har branschen debatterat om regler kontra AI när det gäller beslutsfattande och processoptimering. De strikta reglernas grupp förespråkade förutsägbarhet. AI-gruppen förespråkade flexibilitet. Agentskript avslutar denna debatt genom att bevisa att rätt arkitektur inte är eller, utan och.

Genom att använda agentskript skapar du hybridagenter – system som har kods stela grundstomme och en LLM:s flexibla sinne. Framtiden för företags-AI handlar inte om större modeller. Den handlar om bättre kontroll. Med agentskript ligger kontrollen äntligen i dina händer.