Multiagentsystem: definition, funktion og eksempler

Detaljeret definition

Et multiagentsystem er flere AI-agenter, der arbejder sammen om samme opgave, i stedet for én agent der gør det hele. IBM beskriver det som flere agenter, der udfører opgaver på vegne af en bruger eller et andet system, hver med sin egen beslutningsevne, mens de samarbejder mod et fælles resultat. Google Cloud er på linje: en arkitektur hvor flere agenter arbejder sammen om komplekse opgaver, hver med en ofte specialiseret rolle, hvilket gør det muligt at opdele et stort workflow i mere håndterbare stykker.

Det, der virkelig adskiller et multiagentsystem fra en simpel agent, der kalder andre agenter som værktøjer, er kommunikationen. IBM understreger dette: agenterne interagerer enten direkte med hinanden eller indirekte ved at ændre et delt miljø eller en delt hukommelse. Uden denne udveksling har man en samling af isolerede agenter, ikke et system.

Der findes en nuance mellem kilderne om, hvad "samarbejde" betyder. IBM skelner mellem to logikker: en kooperativ logik, hvor agenterne deler et fælles mål (langt det dominerende tilfælde i virksomhedsanvendelser), og en konkurrence- eller forhandlingslogik, arvet fra akademisk forskning i multiagentsystemer, hvor agenter med divergerende interesser forhandler indbyrdes (et scenarie nævnt for forsyningskæder for eksempel). Google Cloud og Microsoft koncentrerer sig næsten udelukkende om den virksomhedsorienterede kooperative version: specialiserede agenter der fordeler et arbejde mod et fælles mål. Det er også den vinkel, denne ordliste holder sig til.

Sådan fungerer det

Konkret kombinerer et multiagentsystem tre elementer.

Først fordelingen af roller. Hver agent har et kompetenceområde: en agent der analyserer, en agent der skriver, en agent der kontrollerer. Denne specialisering undgår, at én agent bærer en systemprompt, der er overbelastet med for mange værktøjer og for meget kontekst på samme tid.

Dernæst kommunikationen. Agenterne udveksler mellemresultater, data, nogle gange anmodninger om afklaring. Ifølge Microsoft kan denne kommunikation følge flere mønstre: en sekventiel kæde hvor hver agent behandler den foregåendes output, en samtidig tilstand hvor flere agenter arbejder parallelt på samme emne, før resultaterne samles, eller en fælles diskussionstilstand hvor agenterne debatterer i en delt tråd, før de konvergerer.

Endelig koordinationen. Det er orkestreringens rolle: nogen, eller noget, skal beslutte, hvilken agent der handler hvornår, og hvordan man samler det hele til sidst. Uden koordination producerer flere autonome agenter i parallel primært kaos.

Microsoft påpeger et nyttigt punkt, før man kaster sig ud i et multiagentsystem: hvert kompleksitetsniveau, der tilføjes (en agent med flere værktøjer, derefter flere orkestrerede agenter), medfører også mere latenstid, flere omkostninger og flere måder at gå i stykker på. Bedste praksis er stadig at starte med det simpleste niveau, der løser behovet, og først tilføje agenter, hvis en enkelt agent virkelig ikke kan håndtere opgavernes mangfoldighed eller de nødvendige sikkerhedsgrænser.

Konkret eksempel fra Atako

På platformen Atako bringer to konkrete mekanismer en enkelt agent tættere på en multiagent-logik, uden at gøre hver agent til en uoverskuelig maskine.

Den første er underagenterne. Ved en kompleks opgave kan en Atako-agent uddelegere en delmængde af arbejdet til en midlertidig hjælpe-underagent, der eksisterer i den tid, delopgaven varer. Denne underagent bruger ikke en ekstra slot, og alt dens arbejde fremgår som synlige trin i den overordnede agents aktivitetstidslinje. Du bevarer altså et samlet og læsbart overblik, selv når flere "underhjerner" arbejder bag kulisserne.

Den anden er beskeder mellem agenter. To agenter fra samme virksomhed kan sende hinanden beskeder på en dedikeret kanal for at uddelegere arbejde eller dele resultater, præcis den type direkte kommunikation IBM beskriver i sin definition af multiagent. Denne uddelegering er ikke uendelig: uddelegeringsdybden er begrænset, og anti-loop-kvoter forhindrer to agenter i uendeligt at sende den samme opgave frem og tilbage.

Der er også en organisatorisk dimension. Atakos Organization-side gør det muligt at afbilde et organisationsdiagram med teams og hierarkiske positioner, hvor hver position kan tildeles en aktiv agent, et menneske eller stå ledig. Vær dog opmærksom på: at tildele en agent til en position er en visuel reference, ikke en tilladelse. En agents reelle adgang (delte filer, godkendte integrationer) afhænger udelukkende af dens grants, ikke af dens plads i organisationsdiagrammet.

For et fortællende eksempel på denne logik anvendt i en virksomhed uddyber vores artikel multiagentsystemer: når flere agenter er bedre end én ræsonnementet.

Almindelige fejl

At forveksle flere agenter med et multiagentsystem. At oprette fem agenter, der hver kører for sig selv, uden nogensinde at udveksle information, udgør ikke et multiagentsystem. Det er bare fem agenter. Koordination og kommunikation er det, der tæller.

At mangedoble antallet af agenter, før man har brug for dem. En velfunderet agent, med en autonom agent, der selv kan håndtere flere trin, er ofte nok. At tilføje flere agenter tilføjer latenstid og fejlmulighed uden garanteret gevinst.

At glemme værn mod loops. To agenter, der gensidigt uddelegerer arbejde til hinanden, kan uden grænser køre i ring i det uendelige. En begrænset uddelegeringsdybde og anti-loop-kvoter, som dem Atako anvender på sine beskeder mellem agenter, er ikke en teknisk detalje: det er det, der forhindrer et multiagentsystem i at løbe løbsk og bruge budget forgæves.

At tro, at flere agenter betyder mere autonomi. Et dårligt overvåget multiagentsystem er ikke mere pålideligt end en enkelt agent, det er bare sværere at revidere. Overblikket over, hvem der gjorde hvad (tidslinje, integrationslogs), forbliver uundværligt, uanset hvor mange agenter der er involveret.

Lær mere

Multiagentsystemet er arkitekturen. Agentorkestrering er den mekanisme, der driver den i dagligdagen: hvem der beslutter, i hvilken rækkefølge, med hvilken supervision. At forstå det ene hjælper sjældent uden at forstå det andet, derfor er det en god idé at læse begge definitioner sammen, før du kaster dig ud i en arkitektur med flere agenter.