Byg udvidelige AI-agenter: En dybdegående gennemgang af middleware-arkitektur

Introduktion

FlowHunt benytter LangChain-biblioteket på backenden, og i dette blogindlæg udforsker jeg LangChains middleware-arkitektur og hvordan den gør det muligt at bygge mere avancerede AI-agenter. Udviklingen af AI-agenter har nået et kritisk vendepunkt. Efterhånden som sprogmodeller bliver mere kraftfulde, stiger behovet for sofistikerede agentarkitekturer, der kan håndtere komplekse, flertrins arbejdsgange. LangChain 1.0 introducerer et paradigmeskifte i måden, udviklere bygger agenter på, gennem sin innovative middleware-arkitektur, der fundamentalt ændrer tilgangen til agenters udvidelighed og sammensætning. Denne dybdegående guide undersøger hele omskrivningen af deep agents oven på LangChain 1.0 og ser på, hvordan middleware forvandler agentudvikling fra en stiv, monolitisk tilgang til et fleksibelt, sammensætligt system, der sætter udviklere i stand til at bygge kraftfulde agenter skræddersyet til deres behov.

Forståelse af Deep Agents: Ud over simple værktøjskald

Før vi dykker ned i den tekniske arkitektur, er det vigtigt at forstå, hvad der adskiller deep agents fra konventionelle værktøjskaldende systemer. I sin kerne er deep agents sofistikerede værktøjskaldsløkker forbedret med specifikke indbyggede funktioner, der gør dem i stand til at håndtere komplekse, flertrins arbejdsgange med minimal menneskelig indgriben. Hvor simple værktøjskaldende agenter udfører opgaver sekventielt ved at kalde værktøjer og behandle resultater, tilføjer deep agents et lag af intelligens og struktur, der fundamentalt ændrer deres tilgang til problemløsning.

Deep agents hviler på fire centrale søjler. For det første giver planlægningskapabiliteter agenter mulighed for at oprette og følge strukturerede to-do-lister, så komplekse opgaver kan opdeles i håndterbare trin inden udførelse. Denne planlægningsfase er afgørende, fordi den gør det muligt for agenten at tænke hele arbejdsgangen igennem, identificere afhængigheder og optimere rækkefølgen af operationer. For det andet giver filsystemadgang agenter vedvarende lagerplads til at aflade kontekst, så de kan skrive information til filer til senere brug frem for at opbevare alt i samtalehistorikken. Dette er især værdifuldt ved håndtering af store datamængder eller opretholdelse af tilstand på tværs af flere operationer. For det tredje muliggør sub-agent spawning, at hovedagenten kan uddelegere arbejde til specialiserede sub-agenter for isolerede opgaver, hvilket skaber en hierarkisk struktur, der forbedrer effektiviteten og muliggør domænespecifik ekspertise. Endelig sikrer detaljerede systemprompter omfattende instruktioner i, hvordan disse værktøjer bruges effektivt, så agenten ikke blot kender til værktøjerne, men også hvornår og hvordan de bør bruges optimalt.

Disse funktioner har vist sig uvurderlige i produktionssystemer som Manus og Cloud Code, hvor agenter skal navigere i komplekse arbejdsgange, håndtere store mængder kontekst og træffe intelligente beslutninger om opgaveuddelegering. Formålet med deep agents-pakken er at demokratisere adgangen til denne avancerede arkitektur, så det bliver ligetil for udviklere at bygge kraftfulde agenter uden at skulle opfinde den dybe tallerken eller forstå alle implementeringsdetaljer.

Agentarkitekturens udvikling: Fra monolitisk til modulær

Den traditionelle tilgang til at bygge agenter involverede oprettelse af monolitiske strukturer, hvor al funktionalitet—planlægning, værktøjsstyring, tilstandshåndtering og prompt engineering—var tæt koblet i én kodebase. Denne tilgang førte til flere problemer: at udvide agenter krævede ændringer i kernelogikken, genbrug af komponenter på tværs af forskellige agenter var vanskeligt, og det var næsten umuligt at teste enkelte funktioner isoleret. Udviklere måtte enten acceptere begrænsninger eller kaste sig ud i omfattende refaktorering for at tilføje nye kapabiliteter.

LangChain 1.0 løser disse udfordringer med et banebrydende koncept: middleware. Middleware markerer et paradigmeskifte i agentarkitektur ved at introducere en stakbar abstraktion, der gør det muligt for udviklere at sammensætte agentfunktioner som byggeklodser. I stedet for at ændre kerneagentens løkke, opsnapper og udvider middleware bestemte punkter i agentens eksekveringsflow, hvilket muliggør ren ansvarsdeling og maksimal genanvendelighed. Denne arkitektoniske innovation forvandler agentudvikling fra en monolitisk alt-eller-intet tilgang til et modulært, sammensætligt system, hvor hver funktionalitet kan udvikles, testes og implementeres uafhængigt.

Det smukke ved middleware er dets stakbarhed. Udviklere kan definere flere middleware-komponenter og anvende dem i rækkefølge, hvor hvert lag tilføjer egne tilstandsudvidelser, værktøjer og systemprompt-modifikationer. Det betyder, at én agent kan drage fordel af planlægningskapabiliteter, filsystemadgang, sub-agent spawning og brugerdefinerede domæneforbedringer—alt sammen sammensat problemfrit. Rækkefølgen af middleware-applikationen har betydning, da hvert lag bygger oven på det foregående og skaber en kumulativ effekt, der resulterer i en yderst kapabel agent.

Hvordan middleware forvandler agentkapabiliteter

At forstå middleware kræver, at man undersøger, hvordan det modificerer den grundlæggende ReAct (Reasoning + Acting) agentløkke. ReAct-mønsteret, der er blevet standarden for værktøjskaldende agenter, indebærer, at modellen ræsonnerer sig frem til, hvilken handling den skal tage, udfører handlingen via et værktøj, observerer resultatet og gentager denne cyklus, indtil opgaven er fuldført. Middleware erstatter ikke denne løkke; det forstærker den på strategiske punkter.

Middleware fungerer gennem tre primære mekanismer. For det første udvider det tilstandsskemaet ved at tilføje nye nøgler og datastrukturer, som agenten kan tilgå og modificere. Dette tillader forskellige middleware-komponenter at vedligeholde egen tilstand uden at forstyrre hinanden. For det andet tilføjer det nye værktøjer til agentens værktøjskasse, så modellen får flere muligheder for at nå sine mål. For det tredje modificerer det model-forespørgslen, typisk ved at tilføje brugerdefinerede instruktioner til systemprompten, som forklarer, hvordan de nye værktøjer bruges, og hvornår de skal anvendes.

Denne tre-delte tilgang sikrer, at middleware-forbedringer er omfattende og velintegrerede. Bare at tilføje et værktøj uden at udvide tilstandsskemaet eller tilføje instruktioner ville være ineffektivt—modellen forstår måske ikke, hvordan værktøjet bruges, eller hvornår det er passende at kalde det. Ved at kombinere alle tre mekanismer skaber middleware en sammenhængende forbedring, som modellen effektivt kan udnytte.

Planlægningsmiddleware: Struktureret opgaveopdeling

Planlægningsmiddleware illustrerer, hvordan middleware-arkitektur muliggør sofistikerede agentkapabiliteter. Denne middleware udvider agentens tilstandsskema med en to-do-liste, en simpel men kraftfuld datastruktur, der gør det muligt for agenter at opretholde en struktureret handlingsplan. Implementeringen er elegant i sin enkelthed: middleware tilføjer blot én nøgle til tilstandsskemaet, men denne nøgle åbner op for betydelige muligheder.

For at gøre planlægningsværktøjet effektivt tilbyder middleware et write-to-dos værktøj, der gør det muligt for modellen at oprette, opdatere og administrere to-do-listen. Når agenten står over for en kompleks opgave, kan den bruge dette værktøj til at bryde opgaven ned i mindre, mere overkommelige trin. I stedet for at forsøge at løse alt på én gang, laver agenten en plan, udfører hvert trin og opdaterer planen undervejs. Denne strukturerede tilgang har flere fordele: den gør agentens ræsonnement gennemsigtigt og auditérbart, muliggør bedre fejlhåndtering (hvis et trin fejler, kan agenten justere de resterende trin), og resulterer ofte i mere effektiv eksekvering, fordi agenten har gennemtænkt hele arbejdsgangen.

Vigtigt er det, at planlægningsmiddleware ikke blot tilføjer et værktøj—den modificerer også systemprompten med detaljerede instruktioner i at bruge write-to-dos værktøjet effektivt. Disse instruktioner forklarer, hvornår planlægning er passende, hvordan man strukturerer en god plan, og hvordan planen opdateres, efterhånden som agenten gør fremskridt. Denne systempromptforbedring er essentiel, fordi den styrer modellens adfærd og sikrer, at planlægningsværktøjet bruges strategisk og ikke tilfældigt.

Filsystem-middleware: Kontekstaflastning og persistens

Hvor planlægningsmiddleware fokuserer på opgaveopdeling, løser filsystem-middleware en anden, men lige så vigtig udfordring: at styre kontekst og bevare tilstand på tværs af operationer. Filsystem-middleware udvider agentens tilstand med en files-ordbog, der skaber et virtuelt filsystem, som agenten kan læse fra og skrive til.

I modsætning til planlægningsmiddleware, der kun tilbyder ét værktøj, giver filsystem-middleware flere værktøjer til forskellige filoperationer. Agenten kan liste filer for at se, hvad der er tilgængeligt, læse filer for at indlæse information i konteksten, skrive nye filer for at lagre data og redigere eksisterende filer for at opdatere gemte oplysninger. Denne multi-værktøjs tilgang afspejler, at filsysteminteraktioner er mangfoldige og kræver forskellige operationer i forskellige scenarier.

Filsystem-middleware er især værdifuld til håndtering af store datamængder eller til at bevare tilstand på tværs af flere operationer. I stedet for at opbevare alt i samtalehistorikken (hvilket ville forbruge tokens og måske overskride kontekstgrænser), kan agenten skrive information til filer og hente den, når der er behov for det. For eksempel kunne en agent, der arbejder på et forskningsprojekt, skrive resultater til filer, organisere dem efter emne og derefter hente relevante filer, når der skal drages konklusioner. Denne tilgang forbedrer effektiviteten markant og gør det muligt for agenter at arbejde med langt større datamængder, end hvis alt skulle være i kontekstvinduet.

Som med planlægningsmiddleware inkluderer filsystem-middleware brugertilpassede systemprompter, der forklarer, hvordan filsystemværktøjerne bruges effektivt. Disse prompter giver vejledning i, hvornår information bør skrives til filer, hvordan filer organiseres til let genfinding, og bedste praksis for administration af det virtuelle filsystem.

Sub-agent middleware: Uddelegering og specialisering

Sub-agent middleware udgør den mest avancerede del af deep agents-arkitekturen. Denne middleware gør det muligt for hovedagenten at oprette specialiserede sub-agenter til isolerede opgaver, hvilket skaber en hierarkisk struktur, der forbedrer effektiviteten og giver plads til domænespecifik ekspertise. Implementeringen er mere kompleks end planlægnings- eller filsystem-middleware, da den skal håndtere flere scenarier og konfigurationer.

I sin kerne tilbyder sub-agent middleware et task-værktøj, der gør det muligt for hovedagenten at uddelegere arbejde til sub-agenter. Når hovedagenten beslutter, at en opgave bør håndteres af en sub-agent, kalder den task-værktøjet, specificerer hvilken sub-agent der skal tage opgaven, og giver relevante informationer. Sub-agenten udfører derefter opgaven og returnerer et omfattende svar til hovedagenten. Denne uddelegeringsmodel har flere fordele: den isolerer konteksten (sub-agenten ser kun informationer relevante for dens opgave), den muliggør specialisering (forskellige sub-agenter kan have forskellige værktøjer og prompter), og ofte resulterer det i renere og mere effektiv eksekvering.

Sub-agent middleware understøtter to primære anvendelsestilfælde for oprettelse af sub-agenter. Det første er kontekstisolation, hvor en generalistisk sub-agent får de samme værktøjer som hovedagenten, men får en snæver, fokuseret opgave. Sub-agenten løser denne opgave og returnerer et rent, omfattende svar uden mellemliggende værktøjskald eller kontekst, der ville gøre hovedagentens samtalehistorik uoverskuelig. Denne tilgang sparer tokens og tid ved at undgå unødvendig kontekstophobning. Det andet tilfælde er domænespecialisering, hvor en sub-agent oprettes med en brugerdefineret prompt og et specifikt udvalg af værktøjer, der er skræddersyet til et bestemt domæne eller opgavetype. For eksempel kan en forskningsagent have en sub-agent specialiseret i litteraturgennemgang med adgang til akademiske databaser, mens en anden sub-agent specialiserer sig i dataanalyse og har adgang til statistiske værktøjer.

Middleware understøtter to måder at definere sub-agenter på. Værktøjskaldende sub-agenter oprettes fra bunden med en brugerdefineret prompt og en specifik liste af værktøjer. Disse sub-agenter kan have helt andre værktøjer end hovedagenten og dermed opnå ægte specialisering. Udviklere kan også specificere en brugerdefineret model for hver sub-agent, hvilket muliggør brug af forskellige modeller til forskellige opgaver. Brugerdefinerede sub-agenter giver endnu større fleksibilitet ved at lade udviklere indsætte eksisterende LangGraph-grafer direkte som sub-agenter. Dette er især værdifuldt for udviklere, der allerede har bygget avancerede agentarbejdsgange og ønsker at eksponere dem for hovedagenten som sub-agenter.

Vigtigt er det, at sub-agenter også modtager middleware, så de drager fordel af planlægning, filsystemadgang og andre forbedringer. Det betyder, at sub-agenter ikke er begrænset til simple værktøjskald—de kan være lige så avancerede som hovedagenten, med egne planlægningskapabiliteter, filsystemadgang og endda deres egne sub-agenter.

Kontekststyring og summariseringsmiddleware

Efterhånden som agenter deltager i længere samtaler og håndterer mere komplekse opgaver, bliver kontekstvinduet en kritisk begrænsning. Summariseringsmiddleware løser denne udfordring ved automatisk at håndtere konteksten, når den bliver for stor. Denne middleware overvåger samtalehistorikken og, når antallet af tokens nærmer sig vinduets grænse, komprimerer den automatisk historikken ved at opsummere ældre beskeder og bevare de nyeste.

Summariseringsmiddleware er essentiel for produktionsagenter, der skal bevare kontekst gennem længere samtaler. Uden denne ville agenterne til sidst ramme kontekstgrænser og miste adgang til vigtig historik. Med summariseringsmiddleware kan agenter bevare overblikket over tidligere interaktioner og samtidig holde sig inden for tokenbegrænsningen. Middleware balancerer intelligent behovet for at bevare nylig kontekst (som ofte er mest relevant) med behovet for at opsummere ældre kontekst (som kan komprimeres uden at miste kritisk information).

Denne tilgang til kontekststyring afspejler et bredere princip i agentdesign: kontekst er en værdifuld ressource, der skal håndteres omhyggeligt. Hver token brugt på kontekst, er en token der ikke kan bruges på ræsonnement eller værktøjsoutput. Ved automatisk at opsummere kontekst når nødvendigt, sikrer summariseringsmiddleware, at agenter kan fungere effektivt, selv i langvarige scenarier.

Human-in-the-Loop: Middleware til forretningskritiske applikationer

For forretningskritiske applikationer, hvor agenter skal kalde følsomme værktøjer (som at sende e-mails, eskalere problemer eller foretage finansielle transaktioner), leverer human-in-the-loop middleware vigtige sikkerhedsforanstaltninger. Denne middleware gør det muligt for udviklere at angive, hvilke værktøjer der skal afbrydes før eksekvering, så mennesker kan gennemgå og godkende (eller ændre) værktøjskald, før de udføres.

Human-in-the-loop middleware accepterer en værktøjskonfiguration, der specificerer, hvilke værktøjer der skal afbrydes, og hvilke handlinger mennesker kan foretage på disse værktøjskald. For eksempel kan udviklere konfigurere middleware til, at mennesker skal godkende handlingen, redigere parametre eller give feedback til agenten, før et følsomt værktøj sender en e-mail. Dette skaber et samarbejdende workflow, hvor agenten håndterer ræsonnement og planlægning, men mennesker bevarer kontrollen over kritiske handlinger.

Denne middleware illustrerer, hvordan middleware-arkitekturen gør det muligt for udviklere at tilføje avancerede governance- og sikkerhedsfunktioner uden at ændre kernelogikken. Forskellige applikationer har forskellige krav til menneskelig overvågning, og middleware-tilgangen gør det muligt for hver applikation at konfigurere det nødvendige niveau for menneskelig involvering.

Byg udvidelige agenter med tilpasset middleware

Selvom LangChain 1.0 leverer flere forudbyggede middleware-komponenter, ligger den sande styrke i middleware-arkitekturens udvidelighed. Udviklere kan oprette tilpasset middleware ved at udvide agentens middleware-baseklasse og dermed tilføje nye tilstandsnøgler, værktøjer og systemprompt-modifikationer skræddersyet til deres behov.

Udvikling af tilpasset middleware følger samme mønster som det indbyggede middleware: udvid tilstandsskemaet med nye nøgler, tilføj værktøjer der opererer på denne tilstand, og modificer systemprompten med instruktioner i, hvordan de nye værktøjer bruges. Dette konsistente mønster gør det ligetil at udvikle nye middleware-komponenter, der integrerer problemfrit med eksisterende.

For eksempel kan en udvikler, der bygger en agent til kundeservice, oprette tilpasset middleware, der tilføjer et kundedatabaseværktøj til opslag af kundeinformation, et ticket management-værktøj til oprettelse og opdatering af supportsager samt et vidensbaseværktøj til at hente relevant dokumentation. Denne tilpassede middleware udvider agentens kapabiliteter på en måde, der er specifik for kundeservice, men stadig drager fordel af planlægning, filsystem og sub-agent kapabiliteter fra det indbyggede middleware.

Muligheden for at skabe tilpasset middleware betyder, at udviklere aldrig er begrænset af de indbyggede funktioner. Hvis en agent har brug for et specifikt værktøj eller tilstandshåndtering, kan udvikleren implementere det som middleware og integrere det problemfrit med resten af agentarkitekturen.

FlowHunt og forenklet agentudvikling

Mens LangChain 1.0 giver det arkitektoniske fundament for avancerede agenter, tager platforme som FlowHunt agentudviklingen til næste niveau ved at tilbyde et no-code interface til opbygning, udrulning og styring af AI-agenter. FlowHunts AI Agent-komponent udnytter principperne i middleware-baseret arkitektur og gør det muligt for udviklere at bygge kraftfulde agenter uden at skrive kode.

FlowHunts tilgang til agentudvikling matcher middleware-filosofien: sammensætning, udvidelighed og brugervenlighed. I stedet for at udviklere skal forstå detaljerne i middleware-implementeringen, leverer FlowHunt et visuelt interface, hvor agentkapabiliteter sammensættes ved at forbinde komponenter. Platformen håndterer den underliggende middleware-orkestrering, så udviklere kan fokusere på at definere, hvad agenten skal gøre, frem for hvordan det skal implementeres.

FlowHunts agenter kan konfigureres med planlægningskapabiliteter, filsystemadgang, sub-agent spawning og brugerdefinerede værktøjer—alt sammen via et intuitivt visuelt interface. Dette demokratiserer agentudviklingen og gør den tilgængelig for udviklere, der ikke har dyb LangChain- eller agentarkitektur-ekspertise. Desuden tilbyder FlowHunt funktioner som detaljerede agentlogs, agenthistorik og udgiftssporing, der hjælper udviklere med at forstå og optimere deres agenters opførsel.

Praktisk implementering: Oprettelse af en deep agent

At forstå teorien bag middleware-arkitektur er værdifuldt, men det er i den praktiske implementering, at styrken for alvor viser sig. At oprette en deep agent med LangChain 1.0 indebærer brugen af create_deep_agent-funktionen, som tilbyder et forudbygget interface til at konstruere agenter med alle de ovenfor beskrevne kapabiliteter.

Create_deep_agent-funktionen accepterer flere centrale parametre. Udviklere angiver værktøjer, som agenten skal have adgang til, brugerdefinerede instruktioner, der definerer agentens adfærd og mål, samt sub-agenter, som hovedagenten kan uddelegere arbejde til. Funktionen bruger derefter agent builderen til at konstruere agenten ved at anvende den relevante middleware i rækkefølge.

Det er agent builderen, hvor magien opstår. Den starter med at vælge en model (som standard Claude Sonnet 3.5, men kan tilpasses til enhver understøttet model) og anvender derefter middleware i en specifik rækkefølge. Planlægningsmiddleware anvendes først og udvider tilstanden med en to-do-liste samt tilføjer write-to-dos værktøjet. Filsystem-middleware anvendes derefter og tilføjer filsystemværktøjer og tilstand. Sub-agent middleware anvendes som det tredje, hvilket muliggør opgaveuddelegering. Til sidst anvendes summariseringsmiddleware til at håndtere kontekststyring.

Denne sekventielle anvendelse af middleware er afgørende: hvert middleware-lag bygger oven på det foregående og skaber en kumulativ effekt. Systemprompten udvides med instruktioner fra hver middleware i rækkefølge, så modellen modtager omfattende vejledning i brugen af alle tilgængelige funktioner. Tilstandsskemaet udvides med hvert middleware, så agenten kan vedligeholde flere typer tilstand. Værktøjssættet udvides med hvert middleware, så modellen får flere muligheder for at nå sine mål.

Udviklere kan tilpasse denne proces ved at vælge, hvilke middleware der skal anvendes. Hvis en agent ikke har brug for filsystemadgang, kan filsystem-middleware udelades. Hvis en agent ikke behøver sub-agenter, kan sub-agent middleware springes over. Denne fleksibilitet sikrer, at agenter kun konfigureres med de kapabiliteter, de faktisk har brug for, uden unødig overhead.

Avancerede mønstre: Multi-agent orkestrering

Når agentapplikationer bliver mere avancerede, har udviklere ofte behov for at orkestrere flere agenter, der arbejder sammen for at løse komplekse mål. Middleware-arkitekturen muliggør elegante løsninger til multi-agent orkestrering gennem sub-agent systemet.

Et stærkt mønster er hierarkisk uddelegering, hvor en hovedagent opdeler en kompleks opgave i delopgaver og uddelegerer hver delopgave til en specialiseret sub-agent. For eksempel kan en forskningsagent uddelegere litteraturgennemgang til én sub-agent, dataanalyse til en anden og syntese til en tredje. Hver sub-agent er optimeret til sin specifikke opgave med brugerdefinerede prompter og værktøjer, der passer til domænet. Hovedagenten koordinerer hele arbejdsgangen og sikrer, at sub-agenter udføres i den rigtige rækkefølge og at deres output integreres korrekt.

Et andet mønster er paralleleksekvering, hvor flere sub-agenter arbejder på forskellige aspekter af et problem samtidig. Selvom den nuværende implementering behandler sub-agenter sekventielt, understøtter arkitekturen mønstre med paralleleksekvering, hvor flere sub-agenter oprettes, og deres resultater aggregeres. Dette er især værdifuldt for opgaver, der kan opdeles i uafhængige delopgaver.

Et tredje mønster er iterativ forfinelse, hvor hovedagenten opretter sub-agenter til at generere indledende løsninger og derefter bruger deres output til at forfine tilgangen og oprette yderligere sub-agenter til dybere analyse. Dette mønster er værdifuldt i komplekse problemløsningsscenarier, hvor flere iterationer af analyse og forfinelse fører til bedre løsninger.

Disse mønstre viser, hvordan middleware-arkitekturen muliggør avancerede multi-agent systemer uden at udviklere skal bygge kompleks orkestreringslogik fra bunden. Sub-agent middleware håndterer mekanikken i uddelegering og kommunikation, så udviklere kan fokusere på at definere workflow og kapabiliteter for hver agent.

Tokeneffektivitet og omkostningsoptimering

En af de mest praktiske fordele ved deep agents-arkitekturen er dens effekt på tokeneffektivitet og omkostningsoptimering. Ved at kombinere planlægning, filsystemadgang og sub-agent uddelegering kan deep agents løse komplekse opgaver og samtidig bruge væsentligt færre tokens end mere simple agenter.

Planlægning reducerer tokenforbrug ved at lade agenter gennemtænke arbejdsgangen før eksekvering og dermed undgå spild på udforskning og tilbagesporing. I stedet for at prøve sig frem og lære af fejl kan agenter lægge en effektiv plan fra starten. Filsystemadgang reducerer tokenforbrug ved at lade agenter aflade kontekst til vedvarende lager frem for at opbevare alt i samtalehistorikken. Information, der ikke er umiddelbart nødvendig, kan skrives til filer og hentes senere, så det aktive kontekstvindue holdes slankt. Sub-agent uddelegering reducerer tokenforbrug ved at isolere kontekst—sub-agenter ser kun information, der er relevant for deres specifikke opgave, og undgår ophobning af irrelevant kontekst, der ville forbruge tokens.

Summariseringsmiddleware optimerer yderligere tokenforbruget ved automatisk at komprimere samtalehistorikken, når den bliver for stor. I stedet for at miste adgang til historisk information eller overskride kontekstgrænser, opsummerer middleware ældre beskeder, så den væsentlige information bevares, og tokens frigøres til aktuel ræsonnering.

For organisationer, der kører agenter i stor skala, oversættes disse forbedringer i tokeneffektivitet direkte til besparelser. En agent, der bruger 30% færre tokens til at løse den samme opgave, medfører 30% lavere API-omkostninger. Ganget op over tusindvis af agentkørsler bliver disse besparelser betydelige.

Udvidelighed og fremtidssikring

Middleware-arkitekturen giver en tydelig vej til fremtidige forbedringer og udvidelser. Når nye kapabiliteter opstår eller nye brugstilfælde opdages, kan de implementeres som middleware uden at forstyrre eksisterende agenter. Dette fremtidssikrer agentapplikationer mod teknologiske ændringer og muliggør hurtig iteration på nye funktioner.

Hvis eksempelvis en ny kapabilitet til realtidssøgning på nettet bliver tilgængelig, kan udviklere implementere den som middleware, der tilføjer et søgeværktøj og relevante systemprompt-instruktioner. Eksisterende agenter kan straks drage fordel af denne nye funktionalitet blot ved at tilføje søge-middleware til deres opsætning. Tilsvarende, hvis nye modeller bliver tilgængelige med andre funktioner eller prisstrukturer, kan agenter opdateres til at bruge de nye modeller uden ændringer i