Så väljer du rätt ramverk för AI-agenter inom företagsautomatisering

Vad är ramverk för AI-agenter och varför spelar de roll?

Ramverk för AI-agenter är den grundläggande programvara som används för att bygga autonoma agenter. Se dem som en AI:s chassi och motor, där du kan lägga till de verktyg och instruktioner som krävs för att utföra komplexa uppgifter utan ständig mänsklig inblandning. Ramverken är den enda meningsfulla bryggan mellan en obearbetad stor språkmodell (LLM) och en fungerande verksamhetsapplikation som faktiskt gör nytta.

I grunden ger ett ramverk AI:n förmågan att planera åtgärder, använda verktyg som API:er och databaser, minnas tidigare interaktioner och anpassa sin strategi för att nå ett mål.

Utan den strukturen måste ditt team bygga all komplex styrlogik från grunden för varje projekt, ett garanterat slöseri med tid och resurser. Och ramverken blir snabbt allt viktigare. Det är just de som förvandlar generativ AI från en smart innehållsgenerator till en aktiv deltagare som skapar värde i verksamheten.

Färdiga, testade komponenter minskar både utvecklingstid och kostnader kraftigt.

En annan syn: Varför de flesta AI-agentprojekt inte skapar värde

Det är svårt att undgå hajpen kring agentbaserad AI. Men i praktiken präglas många projekt av misslyckanden och besvikelse. Gapet mellan en imponerande demo och en automatiserad process som håller för produktion är där budgetar och utvecklarnas entusiasm tar slut. Vi ser det gång på gång.

Varför misslyckas så många? För att utmaningarna förändras så snart en agent lämnar den skyddade miljön i en Jupyter-notebook. Invändningarna vi oftast hör från driftteam handlar om hur sköra systemen är.

Deras syn brukar ändras när vi visar en tydlig väg till produktion, med noggrann utvärdering av verktyg och genomtänkt felhantering.

De flesta misslyckanden kan härledas till fyra förutsägbara problem som går att lösa. Först kommer orkestreringskaoset: logiken och felhanteringen mellan steg, verktyg och agenter blir en mardröm att underhålla. En analys på Medium visade att orkestreringsproblem stod för 12.54% av utvecklarnas problem.

Det andra är allvarlig brist på tillförlitlighet. När en process består av flera steg ökar risken för fel, och utan omfattande finjustering kan andelen lyckade körningar från början till slut sjunka till nedslående 35.8%.

Sedan kommer bristande insyn i systemets beteende. Om du inte kan se varför en agent misslyckades kan du inte åtgärda problemet, och de flesta ramverk saknar de verktyg för spårning och felsökning som behövs. Slutligen begränsas agenter av luckor i minne och kontext, vilket gör att de upprepar misstag och ber om samma information igen.

Det gör dem betydligt mindre användbara.

Om du inte utformar arkitekturen för att lösa de här problemen i produktionsmiljö från första dagen riskerar agentprojektet att bli ännu ett dyrt experiment.

Steg 1: Jämför de ledande ramverken: LangGraph, AutoGen och CrewAI

Valet av ramverk lägger grunden för hela ditt agentsystems arkitektur, funktioner och möjlighet att skala upp. Det finns dussintals alternativ, men tre har etablerat sig som de främsta valen för seriös utveckling med produktion i sikte: LangGraph, AutoGen och CrewAI. De bygger på helt olika synsätt och lämpar sig därför för olika typer av problem.

LangGraph: Tillståndsmaskinen för komplexa arbetsflöden

LangGraph bygger på det populära biblioteket LangChain och låter dig modellera hur agenter arbetar som en graf. Varje nod är en funktion eller ett verktyg. Kanterna beskriver övergångarna mellan dem.

I grunden är det en tillståndsmaskin, vilket gör strukturen särskilt kraftfull för uppgifter som kräver upprepade förlopp, komplexa förgreningar och tydlig tillståndshantering över tid. Om din process inte följer en enkel, linjär väg, utan kräver att en agent upprepar steg, omprövar sina val eller inväntar extern validering, är LangGraph rätt arkitektoniskt val.

• Passar bäst för: Avancerade agenter som körs länge, arbetar i cykler och kräver noggrann kontroll över sitt tillstånd. Exempel är kundsupportbottar som behöver lämna över till en människa och sedan fortsätta, eller komplexa flöden för databearbetning med återkommande validering.

AutoGen: Ramverket för samarbete mellan flera agenter

AutoGen kommer från Microsoft Research och är särskilt utvecklat för system där flera olika agenter samarbetar för att lösa ett och samma problem. Dess främsta styrka är att skapa komplexa samtal mellan specialiserade agenter. Vi definierar till exempel ofta en agent som skriver, en som granskar och en som planerar.

De diskuterar och kritiserar varandras arbete och förbättrar lösningen tills huvuduppgiften är klar. Vid komplex research, djupgående analys och kreativt syntesarbete ger det samarbetet mellan flera agenter genomgående bättre resultat än en enda agent som ska göra allt.

• Passar bäst för: Uppgifter som kräver olika perspektiv och gemensam problemlösning. Ett bra val för att ta fram omfattande rapporter, undersöka komplexa forskningsfrågor eller driva automatiserade team för programvaruutveckling.

CrewAI: Ett hierarkiskt team av specialister

CrewAI har ett tydligt rollbaserat upplägg för att bygga system med flera agenter. Du ger agenterna specifika jobb, som marknadsanalytiker eller annonstextförfattare, och organiserar dem sedan i ett team som följer en förutbestämd, hierarkisk process. Ramverkets huvudsyfte är att samordna de rollbaserade agenterna så att de utför uppgifter i en strukturerad ordning uppifrån och ned.

Det avgränsade upplägget gör det mycket snabbt att bygga prototyper och driftsätta team som arbetar enligt fasta processer.

Här är en enkel agentdefinition i CrewAI som visar hur ramverket utgår från roller och mål.

from crewai import Agent, Task, Crew


# Define the Researcher Agent
researcher = Agent(
 role='Senior Market Analyst',
 goal='Uncover a compelling new angle for our next marketing campaign for Product X',
 backstory='You are a world-class market analyst known for finding non-obvious insights.',
 verbose=True,
 allow_delegation=False
)


#. Define other agents and tasks.

• Passar bäst för: Automatisering av tydligt definierade affärsprocesser som kan delas upp i en följd av specialiserade roller. Särskilt användbart för att skapa marknadsföringsinnehåll, anpassa säljutskick och ta fram verksamhetsrapporter.

Jämförelse av funktioner

Steg 2: Utvärdera ramverken med en beslutsmodell för produktionsmiljö

Ett ramverk som fungerar utmärkt på ett hackathon över helgen är nästan alltid ett dåligt val för en verksamhetskritisk process. Låt dig inte luras. Hur snabbt du kan bygga en prototyp säger lockande lite om hur väl lösningen fungerar i produktion.

För att välja rätt måste du bedöma ramverken utifrån det som faktiskt spelar roll när systemet är i drift och ska hantera verkliga volymer och oförutsedda fel. Vi använder en beslutsmodell som betygsätter hur väl ramverken fungerar i drift, inte bara vilka funktioner de har. Det tvingar fram den nödvändiga, och ofta svåra, diskussionen om den totala ägandekostnaden i stället för att bara fokusera på den inledande utvecklingsinsatsen.

Använd modellen nedan för ditt projekt. Betygsätt varje ramverk från 1 (dåligt) till 5 (utmärkt) för dessa avgörande faktorer i produktionsmiljö.

Övningen gör en sak tydlig: vilket ramverk för AI-agenter som är ”bäst” beror helt på sammanhanget. Med CrewAI får du fram en prototyp snabbast. AutoGen är kraftfullt för komplex research där flera agenter samarbetar.

Men LangGraph ger den noggranna kontroll och insyn som krävs för företagsautomation som håller även när belastningen ökar.

Steg 3: Bygg för verkligheten: hantera kostnader, säkerhet och problem som uppstår efter driftsättning

Det verkliga arbetet börjar när agenten är ”klar”. Vi kallar det dag 2-problem. Skenande kostnader för språkmodeller, allvarliga säkerhetsbrister och driftfel som knappt går att felsöka är sådant som faktiskt får satsningar på AI-agenter att misslyckas.

Därför måste lösningen utformas för de här riskerna redan från början.

De höga kostnaderna för autonoma agenter

En tänkt arbetsbelastning inom kundsupport kan illustrera modellkostnaden. Uppskatta antalet ärenden, tokenförbrukning, modellpriser, omförsök, verktygsanrop och cacheträffar före lansering. Ersätt sedan antagandena med faktisk användningsdata.

Då får du ett spann att planera utifrån utan att framställa ett hypotetiskt system som ett uppmätt resultat.

Låt oss räkna på en agent som hanterar 5,000 supportärenden per månad.

Beräkningen omfattar bara de direkta API-kostnaderna. Du måste också räkna med drift, övervakningsprogram och utvecklarnas tid för löpande underhåll. En till synes låg kostnad per ärende kan snabbt bli en betydande driftkostnad som hotar hela projektet.

En säkerhetsorienterad arkitektur för AI-agenter

En AI-agent med tillgång till interna verktyg och företagsintern data innebär en stor säkerhetsrisk. Den skapar en ny, föränderlig angreppsyta för promptinjektion, datastöld och obehöriga åtgärder med potentiellt förödande följder. Tillämpa principen om minsta möjliga behörighet: ge agenten bara den åtkomst som krävs för uppgiften.

Vi kräver en säkerhetsorienterad arkitektur för AI-agenter där agenten är isolerad från verktygen den använder.

Arkitekturen upprätthåller viktiga säkerhetsgränser:

1. Indatasanering: Tar bort skadliga instruktioner från användarens frågor för att förhindra promptinjektion.
2. Agentens kärna: Den språkmodellbaserade beslutsprocessen. Den har ingen direkt åtkomst till några verktyg.
3. Åtkomstkontroll för verktyg: En regelmotor utan AI som kontrollerar varje verktygsanrop från agenten och avgör om agenten får använda det begärda verktyget med de angivna parametrarna.
4. Isolerad exekveringsmiljö: Kör godkända verktygsanrop i en isolerad miljö, till exempel en Docker-container, med egna begränsade behörigheter. Det hindrar ett komprometterat verktyg från att påverka resten av systemet.

Den här uppdelningen är avgörande. Agenten kan *begära* åtgärder, men åtkomstkontrollen och exekveringsmiljön *godkänner och utför* dem enligt fasta regler.

Hur bygger du en anpassad utvärderingssvit för din agent?

Hur vet du egentligen om din agent fungerar? Hur kan du bevisa att en ändring du just driftsatt förbättrade den i stället för att göra den betydligt sämre? Stickprov och magkänsla räcker inte.

Du behöver en systematisk utvärderingssvit som ger reproducerbara resultat och mäter prestationen mot konkreta affärsmål. Generella mått på träffsäkerhet är inte tillräckliga här. Området är nytt, men har tydliga paralleller till psykometri: vi bedömer inte bara om svaren är rätt eller fel, utan också agentens väg till beslutet, dess kostnadseffektivitet och dess förmåga att återhämta sig från fel som förr eller senare uppstår.

En egen utvärderingssvit skiljer ett moget AI-utvecklingsteam från ett oerfaret.

Så här gör du, steg för steg:

1. Definiera din referensuppsättning: Samla först 50-100 representativa testfall från verkligheten som du kan använda som facit. Varje fall ska innehålla indata (till exempel ett kundmejl) och önskat slutresultat (till exempel ett JSON-objekt som anger ärendekategori och tonläge).
2. Fastställ framgångsmått: Nöj dig inte med godkänt eller underkänt. Ta fram ett detaljerat bedömningsunderlag för varje testkörning.
3. Automatisera testramverket: Skriv ett skript som går igenom hela referensuppsättningen, kör varje fall genom agenten och sparar ett fullständigt förlopp med dess resonemang, verktygsanrop och slutsvar för analys.
4. Bygg automatiska utvärderare: Skapa en utvärderingsfunktion för varje mått i bedömningsunderlaget. Vissa kontroller kan göras direkt i kod, till exempel `is_json_valid(output)`. För mer nyanserade bedömningar kan du låta en kraftfull språkmodell, som GPT-4 eller Claude 3 Opus, agera opartisk granskare.
5. Analysera och förbättra: Kör hela utvärderingssviten efter varje större ändring i koden eller instruktionerna till modellen. Analysera de samlade resultaten och leta efter försämringar. En bra kontrollpanel visar inte bara den totala andelen godkända tester, utan också exakt vilka fall som misslyckas och ger dig underlag för att förstå varför.

Det är så du går från sköra, opålitliga agenter till robusta system som är redo för produktion.

Tyngdpunkten har flyttats från modellen till systemet runt den. De team som lyckas bäst bygger bättre system för utvärdering, övervakning och löpande förbättring, snarare än att enbart välja den bästa grundmodellen.