Multiagentsystem: definition, funktion och exempel

Detaljerad definition

Ett multiagentsystem är flera AI-agenter som arbetar tillsammans på samma uppdrag i stället för att en ensam agent gör allt. IBM beskriver det som flera agenter som utför uppgifter för en användares eller ett annat systems räkning, där var och en behåller sin egen beslutsförmåga samtidigt som de samarbetar mot ett gemensamt resultat. Google Cloud går i samma riktning: en arkitektur där flera agenter arbetar tillsammans på komplexa uppgifter, var och en med en ofta specialiserad roll, vilket gör det möjligt att dela upp ett stort workflow i mer hanterbara delar.

Det som verkligen skiljer ett multiagentsystem från en enkel agent som anropar andra agenter som verktyg är kommunikationen. IBM betonar just det: agenterna interagerar antingen direkt med varandra, eller indirekt genom att förändra en delad miljö eller ett delat minne. Utan det utbytet har man en samling isolerade agenter, inte ett system.

Det finns en nyansskillnad mellan källorna om vad "samarbeta" betyder. IBM skiljer på två logiker: en kooperativ logik, där agenterna delar ett gemensamt mål (det klart dominerande fallet i företagsanvändning), och en konkurrensinriktad eller förhandlande logik, ärvd från den akademiska forskningen om multiagentsystem, där agenter med divergerande intressen förhandlar med varandra (ett scenario som nämns för leveranskedjor till exempel). Google Cloud och Microsoft fokuserar för sin del nästan uteslutande på den kooperativa, företagsorienterade versionen: specialiserade agenter som fördelar ett arbete mot ett gemensamt mål. Det är också den vinkel som den här ordlistan utgår från.

Så fungerar det

Konkret kombinerar ett multiagentsystem tre ingredienser.

Först rollfördelningen. Varje agent har ett kompetensområde: en agent som analyserar, en agent som skriver, en agent som kontrollerar. Den här specialiseringen förhindrar att en enda agent bär på en systemprompt som är för tung, med för många verktyg och för mycket kontext att hantera samtidigt.

Sedan kommunikationen. Agenterna utbyter mellanresultat, data, ibland förfrågningar om förtydligande. Enligt Microsoft kan den här kommunikationen följa flera mönster: en sekventiell kedja där varje agent bearbetar föregående agents utdata, ett parallellt läge där flera agenter arbetar samtidigt med samma ämne innan resultaten sammanställs, eller ett kollektivt diskussionsläge där agenterna debatterar i en delad tråd innan de konvergerar.

Till sist koordinationen. Det är orkestreringens roll: någon, eller något, måste bestämma vilken agent som agerar när, och hur man samlar ihop allt i slutet. Utan koordination producerar flera parallella autonoma agenter mest kaos.

Microsoft påminner om en användbar poäng innan man ger sig in i ett multiagentsystem: varje tillagd komplexitetsnivå (en agent med fler verktyg, sedan flera orkestrerade agenter) medför också mer latens, högre kostnader och fler sätt att gå sönder. Bästa praxis är fortfarande att utgå från den enklaste nivå som täcker behovet, och bara lägga till agenter om en enda agent verkligen inte klarar av uppgifternas mångfald eller de säkerhetsgränser som krävs.

Konkret exempel med Atako

På plattformen Atako för två konkreta mekanismer en enskild agent närmare en multiagent-logik, utan att göra varje agent till ett svårhanterligt maskineri.

Den första är underagenterna. För en komplex uppgift kan en Atako-agent delegera en delmängd av arbetet till en tillfällig underagent, som existerar under tiden deluppgiften pågår. Den underagenten förbrukar ingen extra plats, och allt dess arbete visas som synliga steg i föräldraagentens aktivitetstidslinje. Du behåller alltså en enda, läsbar vy, även när flera "underhjärnor" jobbar bakom kulisserna.

Den andra är meddelanden mellan agenter. Två agenter inom samma företag kan skicka meddelanden till varandra på en dedikerad kanal för att delegera arbete eller dela resultat, precis den typ av direkt kommunikation som IBM beskriver i sin definition av multiagent. Den här delegeringen är inte oändlig: delegeringsdjupet har ett tak, och kvoter mot loopar hindrar två agenter från att skicka samma uppgift fram och tillbaka i det oändliga.

Det finns också en organisatorisk dimension. Atakos Organization-sida gör det möjligt att representera ett organisationsschema med team och hierarkiska positioner, där varje position kan tilldelas en aktiv agent, en människa, eller stå vakant. Observera dock: att tilldela en agent till en position är en visuell referens, inte ett tillstånd. En agents verkliga åtkomst (delade filer, tillåtna integrationer) beror enbart på dess grants, inte på dess plats i organisationsschemat.

För ett berättande exempel på den här logiken tillämpad i ett företag går vår artikel multiagentsystem: när flera agenter är bättre än en igenom resonemanget i detalj.

Vanliga misstag

Blanda ihop flera agenter med ett multiagentsystem. Att skapa fem agenter som körs var för sig, utan att någonsin utbyta information, ger inte ett multiagentsystem. Det är bara fem agenter. Koordinationen och kommunikationen är den del som räknas.

Multiplicera agenter innan man behöver dem. En välutrustad agent, en autonom agent som klarar av flera steg själv, räcker ofta. Att lägga till fler agenter ökar latensen och felytan utan garanterad vinst.

Glömma skyddsräckena mot loopar. Två agenter som delegerar arbete till varandra kan, utan någon gräns, gå runt i cirklar i det oändliga. Ett begränsat delegeringsdjup och kvoter mot loopar, som de Atako tillämpar på sina meddelanden mellan agenter, är ingen teknisk detalj: det är det som förhindrar att ett multiagentsystem skenar och förbrukar budget i onödan.

Tro att fler agenter betyder mer autonomi. Ett dåligt övervakat multiagentsystem är inte mer pålitligt än en ensam agent, det är bara svårare att granska. Insyn i vem som gjort vad (tidslinje, integrationsloggar) förblir avgörande, oavsett hur många agenter som är inblandade.

Läs vidare

Multiagentsystemet är arkitekturen. Agentorkestreringen är mekanismen som driver den i vardagen: vem som bestämmer, i vilken ordning, med vilken tillsyn. Att förstå det ena hjälper sällan utan att förstå det andra, därför är det värt att läsa båda definitionerna tillsammans innan du ger dig in i en arkitektur med flera agenter.