I det udviklende landskab med flere agenter er agenter mest effektive, når de tildeles specifikke detaljerede opgaver. Dette kræver et forskelligt netværk af genanvendelige, specialiserede agenter. Kerneudfordringen er dog at koordinere disse utallige, heterogene agenter, der kan stamme fra forskellige kilder, for at samarbejde effektivt mod fælles forretningsmål. Uden en forenet platform fører denne kompleksitet til agentudvidelse og et kritisk mangel på ledelse.

Disse AI-agenter multipliceres hurtigt, integreres i SaaS-platforme, udvikles internt eller pakkes med populære LLM'er. Denne multiplikation resulterer i afbrudte organisationssiloer. Mens en agent optimerer opgaver i sine oprindelige applikationer, mangler den ofte en holistisk virksomhedsvisning. Denne manglende synlighed forhindrer agenter i effektivt at orkestrere, sikre og administrere handlinger på tværs af forskellige domæner og systemer.

MuleSoft Agent Fabric håndterer udfordringen med at administrere "agentudvidelse" og aktivere problemfri orkestrering af forskellige agenter, uanset deres oprindelse. Den etablerer de bedste fremgangsmåder for arkitektur og leverer det nødvendige værktøj til at oprette agentnetværket. Et agentnetværk refererer til en koordineret samling af AI-agenter, værktøjer og ressourcer, der samarbejder om at køre komplekse forretningsprocesser med flere trin.

MuleSoft Agent Fabric er en forenet platform, der giver enhver virksomhed en nem måde at finde, orkestrere, styre og observere enhver agent, uanset hvor den er bygget.

Søjler af MuleSoft Agent stof

Opdag: Agentregistrering leverer et centraliseret katalog over alle AI-agenter og værktøjer i hele organisationen. Den aktiverer udforskning og genbrug af interne, SaaS-integrerede og eksterne aktiver. Ved at levere en enkelt kilde til sandheden for alle agentaktiver eliminerer Agentregistrering redundans og sikrer, at udviklere kan udnytte eksisterende funktioner på en skala.

Orkestrat: MuleSoft Agent Broker er en intelligent distributionsløsning, der dynamisk matcher opgaver til den agent eller det værktøj, der passer bedst. Drevet af et LLM efter eget valg, koordineres det på tværs af agenter og værktøjer for at sikre, at komplekse anmodninger med flere trin og forretningsprocesser køres med høj pålidelighed og sporbare resultater.

Govern: MuleSoft Agent Governance bruger Flex Gateway og dens understøttelse af Model Context Protocol (MCP) og Agent2Agent (A2A)-protokollen. Med Flex Gateway kan virksomheder håndhæve sikkerheds- og compliancepolitikker for hver agent-agent- og agent-værktøjsinteraktion.

Bemærk: Agentvisualiser giver observation i realtid gennem et dynamisk, interaktivt kort over agentinteraktioner. Den sporer beslutninger, overvåger systemtilstanden og aktiverer dermed kontinuerlig optimering og pålidelig overvågning af hele agentøkosystemet.

Agent Fabric fremhæver en YAML-tilgang (specification-first), hvor brugere definerer agentnetværk gennem en metadatadescriptor (den "YAML-fil"). Denne YAML-fil er agnostisk for MuleSoft, og den adskiller definitionen af agentnetværket fra dens kørsel.

Hvert agentnetværk definerer et specifikt funktionelt område med dets agentaktiver, herunder deres driftsregler og politikker. YAML bruges til at aktivere de fire Agent Fabric-piller:

  1. Opdag: Udfyld agentregistreringen med eksisterende agentaktiver, f.eks.:
    1. Agenter, der er implementeret på tværs af forskellige platforme (MuleSoft eller andre)
    2. MCP-servere
    3. LLM-udbydere
  2. Orkestrer: Opret agentmæglere til orkestrering
  3. Govern: Anvend politikker på aktiverne til sikkerhed og styring
  4. Observe: Definer og genbrug forbindelser til de definerede aktiver. Observations- og overvågningsfunktioner er også tilgængelige for agentnetværk.

Brugerrejsen starter i Anypoint Code Builder. Brug den nye kommando, der er tilgængelig via kommandopaletten med navnet "MuleSoft: Opret et agentnetværksprojekt" for at oprette et nyt projekt. Denne kommando opretter et nyt projekt ("Agent Network"), der indeholder to filer.

  • agent-network.yaml: Denne fil definerer konfigurationen for systemet med flere agenter og aktiverer orkestrering af AI-agenter med eksterne værktøjer (via MCP) og agenter (via A2A-protokollen). Dette format giver en deklarativ måde at definere agentfunktioner, afhængigheder og integrationer på.

  • exchange.json: Alle agentnetværksprojekter har også en exchange.json-fil. Denne fil indeholder aktivmetadata, der er tilgængelige i Anypoint Exchange, efter dine agentnetværksaktiver er udgivet.

Udviklingen af dit agentnetværk følger en standardlivscyklus for softwareudvikling (SDLC), der involverer fire hovedfaser:

  1. Miljøopsætning: Opsætning af kørselsmiljø og gateways
  2. Projektoprettelse og design: Opret Agent Network-projektspecifikation
  3. Opbygning og offentliggørelse: Opbyg og udgiv aktiver til agentregistreringen
  4. Implementering: Implementer eller promover agentnetværket i et givent miljø

Når du har opbygget projektet og genereret den krævede MuleSoft-applikation og aktiver, skal du gøre dem tilgængelige i Exchange. I Anypoint Code Builder, udløse opbygning og udgivelse proces ved hjælp af "MuleSoft: Udgiv Agent Broker Project til Exchange”-kommando tilgængelig via kommandopaletten.

Udgivelsestrinet transformerer hvert agentaktiv i YAML-filen til en A2A-, MCP- eller LLM-specifikation og udgiver den til Exchange.

Endvidere udgiver systemet YAML to Exchange ved brug af en ny agent-netværksaktivtype. Du kan vise dette aktiv i brugergrænsefladen for agentregistreringen og søge efter det via Exchange API.

Se en agentnetværksfil, der definerer et agentnetværk for en virksomhed. Dette agentnetværk aktiverer netværket for bestillingsfuldførelse på tværs af Salesforce, Stripe, en anden bestillingsfuldførelsesagent og lager-MCP-server med en enkelt, policeadministreret oplevelse.

  • Opdag
    Udgiv eksisterende agenter og værktøjer (f.eks. Salesforce, Stripe, Bestillingsfuldførelse og Lager) som Exchange-aktiver til genbrug. Også YAML (order fulfillment definition), som er versioneret og kan deles, hvilket aktiverer hurtig tilpasning for roller, områder eller datterselskaber uden at genopbygge forløb.
  • Orkestrat
    En agentbroker bruger en LLM til at opdele bestillingsfuldførelsesprocessen i en række opgaver, f.eks. bekræftelse af kundedetaljer, tildeling af lager og beregning af forsendelsesomkostninger. Den eksekverer derefter dette arbejdsflow ved at kalde MCP- og A2A-agenter og sikrer, at der anmodes om menneskelige godkendelser, når der kræves det.
  • Styr
    Anypoint Flex-gateway håndhæver godkendelse, adgang med mindste rettigheder og guardrails. API Manager-politikker sikrer ensartede kontroller på tværs af alle opkald og dataudvekslinger.
  • Observe
    Overvågning og sporing giver end-to-end synlighed i status, fejl og forsinkelse. Visualisering viser, hvilke agenter der interagerede, og hvor flaskehalse forekom.
  • Trust and Compliance
    Centraliserede legitimationsoplysninger, revisionsspor og policeovertagelse understøtter sikkerhed, fortrolighed og bestemmelseskrav (PII-håndtering, godkendelser og adskillelse af opgaver).

Diagrammet viser de forskellige noder i agentnetværket (metadata), der er defineret i YAML.

  • Formål: Exchange er kataloget for agenter, værktøjer og andre aktiver. Dens primære mål er at løse "agentudvidelse" ved at levere et enkelt, administreret katalog til opdagelse, organisering og livscyklusstyring af heterogene agenter. Det gør det muligt for udviklere at finde og genbruge agenter, platformsejere til at vedligeholde synligheden og orkestratorer til at opdage funktioner.
  • Heterogen efter design: Anypoint Exchange understøtter nu tre nye aktiver - agenter, MCP'er og LLM'er. Exchange er designet til at være et universelt katalog til at registrere og administrere enhver type agent. Den understøtter A2A-kompatible agenter, MCP-servere og LLM-udbydere fra enhver kilde, herunder tredjepartsagenter, Agentforce og tilpassede MuleSoft-agenter.
  • Core Metadata: Hvert registreret aktiv har et basislinjesæt af uforanderlige metadata, herunder et entydigt navn og en entydig version, ejerskab og udgiver. Livscyklustilstande (udvikling, faseinddeling, produktion, udfaset) spores også.
  • Discovery:
    • Design-tid: Udviklere kan finde registrerede agenter enten gennem den eksisterende Exchange-brugergrænseflade eller via naturlig sprogsøgning med Vibes i Anypoint Code Builder.
  • Tagging og klassificering: Aktiver kan klassificeres efter type (agent, MCP, LLM, broker) og domæne (f.eks. HR, vejr) ved at bruge et grundlæggende nøgle-værdi-tagging-system, der aktiverer dynamisk linkning, søgning og valgpolitikker.
  • Katalog: Lageret understøtter både private og interne katalogmodeller for delingsagenter i en organisation.
  • Visualisering: Giver et visuelt værktøj til at understøtte netværksvisninger, der viser forbindelser for enkelte aktiver eller hele kortet over noder og links på tværs af organisationen med filtreringsfunktioner.

Mæglere i et agentnetværk kan henvise til registrerede agenter, MCP-servere og LLM-udbydere, der er lagret i Anypoint Exchange. Men hvis de ikke allerede er registreret, kan de erklæres i metadataene i agentnetværket (YAML), og de bliver registreret automatisk. I eksemplet er flere agenter, MCP-servere og LLM-udbydere erklæret og registreret i Anypoint Exchange.

En agentbroker er en intelligent distributionsagent, der koordinerer opgavedelegering på tværs af specialiserede agenter i en virksomhed. Det er defineret af de agenter og MCP-servere, som det bruger til at udføre opgaver.

En mægler er en specialiseret agent, der vises i Anypoint Exchange efter udgivelse af et agentnetværksaktiv og genbrug af andre mæglere.

Brokers er defineret i afsnittet brokers i YAML. De definerede mæglere er gennemsigtigt "kompileret" i en applikation, uden at kræve nogen forudgående Knowledge om Mule. Denne genererede applikation implementeres i CloudHub 2.0 (CH2) og udnytter den robuste CH2-infrastruktur.

Dette betyder, at agentmæglere drager fordel af CloudHub 2.0's etablerede ydeevneegenskaber, herunder dens logførings- og metrikfunktioner. Driftsmæssige aspekter, f.eks. "Omkostning til drift" og "Overvågning/Advarsel/Værktøj", er de samme som enhver anden arbejdsbelastning.

For scenarier, der kræver menneskelig intervention (Human-in-the-Loop), vedligeholdes tilstanden for hver interaktion ved brug af MuleSoft Object Store, en distribueret løsning, der er designet til effektiv tilstandsstyring i meget samtidige miljøer.

En brokerdefinition består af to afsnit: kort og specifikationer.

Kortet følger agent-til-agent-specifikationen (A2A). Blandt andet beskriver det agentens kontrakt, færdigheder og funktioner. Kortets URL udfyldes automatisk med værdien ${ingressgw.url}/broker-name. Ved implementering erstattes pladsholderen ${ingressgw.url} automatisk med URL'en for Anypoint Flex-gatewayen, der står foran agentens adgangsanmodninger.

Specifikationsafsnittet konfigurerer "kildekoden" for mægleren. Her kan udvikleren angive den LLM, der skal bruges, instruktioner, tilgængelige værktøjer, fejlhåndtering og vigtigst af alt de forskellige agenter og MCP-værktøjer, der er tilgængelige for denne mægler.

LLM udbydere

Dette afsnit er en del af specifikationen i hver broker. Dette er en reference til en af de LLM'er, der er defineret i afsnittet Services. Vi kan vælge, om vi vil dele en LLM på tværs af alle mæglere, eller om nødvendigt få forskellige mæglere til at bruge den LLM, der passer bedre til dets opgaver.

Brokers kan pege på LLM-udbydere. Vi kan vælge modeller af disse udbydere afhængigt af vores behov.

Instruktioner

Dette afsnit er valgfrit, og du kan bruge det til at angive instruktioner, der er specifikke for denne agent. Disse instruktioner fokuserer ofte på specifikke forretningsorienterede bekymringer. Forestil dig f.eks. en kundeserviceagent, der koordinerer administrationen af kunderapporterede hændelser:

Bemærk, at der ikke er behov for at give eksplicitte instruktioner – f.eks. "opdel meddelelsen i opgaver" eller "vælg det bedste værktøj" – da mægleren selv håndterer det. Disse instruktioner er kun nødvendige, når der beskrives specifikke forretningsprocesser.

Værktøjskonfiguration

Værktøjer giver agenter eksterne funktioner. Når en broker har brug for at få adgang til et eksternt system (der ikke er en anden agent, f.eks. en eksisterende API eller en SaaS-tjeneste), kontakter den en MCP-server (Model Context Protocol):

Der refereres til MCP-serveren med navnet på udvekslingsaktivet. Forbindelsesdetaljerne for den er angivet i serviceafsnittet.

Som standard har mægleren adgang til alle de værktøjer, der er tilgængelige i MCP-serveren. Ifølge vores observation kan de mest moderne LLM'er kun håndtere omkring 20-25 værktøjer pr. kontekst, før de begynder at generere unøjagtigheder (eller mister kontekst). Af denne årsag er det generelt en god fremgangsmåde at begrænse de tilgængelige værktøjer til det nødvendige minimum. Du kan anvende denne filtrering gennem de tilladte lister.

Agentlinks

Dette afsnit er den vigtigste del af hele definitionen. Afsnittet Links aktiverer interagentkommunikation og orkestrering. Dette betyder, at denne broker er afhængig af de agenter, der er linket hertil, til at udføre de relevante handlinger for at fuldføre brugerens mål.

Faktisk definerer dette afsnit et agent-netværk for samarbejde.

Agentstyring er en vigtig søjle for agentstrukturen, der er grundlæggende for opbygning af et betroet agentnetværk og sikring af sikkerhed og compliance.

For styring kræves der i alt to Flex-gateways (1 indgang og 1 udgang) i dit private område.

Styring etablerer de nødvendige strukturer, kontroller og beviser for sikkert at skalere hele livscyklussen for agentudvikling (ADLC). Specifikt implementerer ledelse nøgleprocesser som agentcertificering, katalogisering, livscyklusbeslutninger og håndhævelse af kørselspolitikker.

  • Katalog:
    • Udveksling: Understøtter registrering af agentformål, ejere, miljøer og data- og klassificeringsgrænser. Den registrerer også funktioner, værktøjer, ressourcer, meddelelser og eksterne afhængigheder med versioner.
  • Versionering og livscyklus:
    • Dokumenter og administrer semantisk versionering af agenter, værktøjer og aktiver under den komplette livscyklus for agentudvikling.
    • Versionsstyring hjælper med at administrere agentudfasningstider og understøtter dobbeltkørsel (hvor det er muligt), så du sikrer problemfri migrering.
  • Polic Enforcement:
    • Agentisk AI-arkitektur udvider angrebsoverfladen (samtalegrænseflade, meddelelser og nye protokoller som MCP). Ethvert kompromis med komponenter kan føre til overlappende effekter til flere systemer, der leverer komponenter som protokol, meddelelse, API eller værktøj.
    • Sikker implementering af virksomhedsagent-AI kræver en specialiseret tilgang, da disse autonome og uforudsigelige miljøer i sig selv udvider angrebsoverfladen gennem agent-til-agent-interaktioner. Selvom eksisterende sikkerhedsværktøjer til statiske systemer er vigtige, er de ikke længere tilstrækkelige i sig selv. Virksomheder skal proaktivt planlægge og implementere fire specifikke sikkerhedsløsninger, der hver direkte håndterer en kritisk forretningsrisiko, der er knyttet til agentisk AI.
    • Flex Gateway: Al A2A- og MCP-trafik distribueres gennem Flex Gateway, selvom målsystemet ikke er sikret, for at sikre, at politikker anvendes på hvert slutpunkt. Denne distribution er vigtig for at sikre agentkommunikation og integration med godkendelsesserver.
    • Politikpakker: Brugere kan definere og anvende pakker med foruddefinerede politikker på arbejdsflows før kørsel og håndhæve et ensartet sæt af sikkerheds- og driftspolitikker.
    • Typer af policer: Platformen understøtter forskellige indgående og udgående politikker, herunder:
      • A2A-politikker: Agentkort, personligt identificerbare oplysninger, Meddelelsesdekorator, Skemavalidering.
      • MCP-politikker: Attributbaseret adgangskontrol, skemavalidering, MCP-understøttelse.
      • LLM/AI-politikker: AI-meddelelsesdekorator, AI-meddelelsesbeskyttelse (filtrering af skadeligt indhold), AI-meddelelsesskabelon (anvende foruddefinerede skabeloner), begrænsning af AI-basistokenfrekvens.
      • Telemetrikpolitikker: A2A og MCP-telemetrie til at udvide Open Telemetry-løsninger til logdatasamling og -eksport.
  • Logning: Takket være automatisk sporing er logfiler på tværs af agentnetværket tilgængelige for at spore hver agentinteraktion, forklare adfærd og opbygge Trust.

Eksemplet viser en politik for meddelelseslogføring, som konfigureres ved brug af agentnetværksmetadata. Orderfullfillment-broker refererer til en eksisterende agent ved navn Salesforce-agent, og politikken for meddelelserne konfigureres ved brug af metadata. Bemærk, at Agent Fabric automatisk konfigurerer alle de politikker, der er omtalt under afsnittet "specifikationer" på Flex Gateway. Du kræver ikke yderligere trin.

I betragtning af den ikke-deterministiske karakter og kompleksiteten af LLM-agenter og multiagentimplementeringer er observation og overvågning afgørende.

  • Grundlæggende logfiler og spor: Ræsonnement og værktøjsudførelsessporing leveres gennem logfiler. Logfiler og sporinger fra arbejdsflowkørsler er synlige efter kørsel i Runtime Manager.
  • Metrikker: I den indledende fase udgiver platformen a2a_total_calls og mcp_total_calls som optællere med betegnelser (f.eks. sti, status, metode, værktøj) for at bestemme samlede, vellykkede og mislykkede opkald. Disse metrikker udgives fra politikkode ved brug af den oprindelige statistikgrænseflade for afsenderen (Flex Gateway), helst via eksisterende politikker som mcp_support_policy og a2a_agent_card_policy.
  • Forbedret observation (Future): Planer omfatter brug af Åben telemetri til distribueret sporing i fremtidige versioner. Mere avanceret observation omfatter:
    • Detaljeret anmodningssporing: Få end-to-end-synlighed i anmodninger, der omfatter meddelelser, planlægningsprocesser, handlinger, der er kaldt, og interaktioner med underagenter.
    • Agent Health Monitoring: Overvågning af agentoppetid, svarforsinkelse, gennemsnit, fejlfrekvenser og underliggende ressourceanvendelse (CPU, hukommelse, netværk, GPU).
    • Koordinering af flere agenter: Registrering af succesfrekvenser og fejlfrekvenser for agent-til-agent-interaktioner, registrering af cirkulære kaldemønstre (løkker) og sporing af pr. agent-metrikker som opgavefuldførelse og antal kald.
    • Omkostningssporing: Sporing af tokenanvendelse og tilknyttede omkostninger for hvert LLM-kald, ideelt pr. agent, med dashboards og advarsler.
    • Kognitive sporing: Registrering og visning af et detaljeret spor af en agents session, herunder interne tankeprocesser og alle værktøjsopkald, der fungerer som et uforanderligt revisionsspor.
    • Agentsessionsafspilning: En brugergrænseflade, der tillader visuel "genafspilning" af en agents kognitive sporing trin for trin for dyb fejlfinding.
    • DAG-visualisering: Levering af en DAG-visualisering (Directed Acyclic Graph) af agentarbejdsflowkørsel for komplekse multiagentinteraktioner.

Agentvisualiser bruges til at identificere dele af dit agentnetværk og se, hvordan de fungerer sammen.

  • Adskil nodetyper (agenter og MCP-servere).
  • Få vist kanterne for at se erklærede interaktioner og kørselsinteraktioner.
  • Brug lag til at fokusere visninger på specifikke miljøer
  • Åbn detaljekort for at undersøge metadata og metrikker for noder og adgangslogfiler og spor
  • Gennemse styringsindikatorer som Flex Gateway-beskyttelse og anvendte politikker.

Find detaljer om komponenterne i Agent Visualizer heri.

Med disse fire søjler sammen udvider MuleSoft Agent Fabric sikkerheden og kontrollen til enhver agent med indbygget styring. Den sætter agenter i stand til at handle overalt ved at udnytte nye protokoller som A2A (Agent til Agent) og MCP (Model Context Protocol) til at opbygge og udvide forretningsprocesserne. Vi forbinder alt - applikationer, data og systemer - for at styrke og styre agenter, når de handler på tværs af hele forretningen. Intelligente værktøjer understøtter oprettelse og udvidelse af forretningsprocesser eller API'er ved at bruge AI som standard eller ved at medbringe tredjeparts AI-værktøjer.

Brug af alle fire søjler sammen er ikke påkrævet, men anbefales. Du kan vælge søjler uafhængigt efter behov. Du kan f.eks. bruge Agent Fabric til registrering og styring uden at bruge orkestreringslaget. På samme måde kan du bruge mægleren til at orkestrere agenter, der er styret gennem en anden platform.

Diagrammet viser, hvordan alle fire komponenter interagerer med hinanden:

  1. Udgiv agentaktiverne til Anypoint Exchange til udforskning og genbrug, når du har defineret agentnetværket (brokere, agenter, MCP-servere) i agentnetværket YAML i Anypoint Code Builder.
  2. Implementer agentaktiverne i CloudHub 2.0 (administreret i Runtime Manager).
  3. Håndhæv politikker på indgående trafik til netværket med en overførsels-Flex-gateway, der findes foran broker- og API-slutpunkter.
  4. Håndhæv politikker, administrer forbindelser og udsend telemetridata med en udgående Flex-gateway. Denne gateway findes på udgående stier fra mæglere og agenter til eksterne tjenester.
  5. Indsaml logfiler, metrikker og sporinger fra Flex Gateway og kørselstider i Anypoint Monitoring.

Det er fristende at gøre alle specialiserede agenter tilgængelige med det samme i en flad, ubegrænset arkitektur med en enkelt orkester, der kan håndtere enhver opgave ved at have adgang til alle tilgængelige AI-aktiver. Denne tilgang viser sig dog hurtigt at være skadelig for det generelle systems effektivitet og pålidelighed. Ligesom princippet gælder for et overskud af individuelle værktøjer, mange agent muligheder indføre betydelige støj og kompleksitet for den centrale mægler agent (eller orkestrator). Denne øgede kompleksitet fører direkte til et mærkbart fald i både nøjagtigheden af mæglerens beslutningstagning (valg af den rigtige agent til jobbet) og determinismen af systemets svar (forudsigelige, ensartede resultater for lignende forespørgsler). Brokeragenten lider effektivt af indstillingspærring, hvilket fører til langsommere og mindre pålidelig distribution.

I stedet for en flad struktur går vi stærkt ind for en flerniveau hierarkisk tilgang til struktureringen af agentnetværket. Dette organisatoriske princip tilbyder adskillige vigtige fordele. For det første fremmer det i sig selv sporbarhed og styring. En hierarkisk struktur afspejler etablerede bedste fremgangsmåder for organisationen, hvilket gør det nemmere at overvåge forløbet af en anmodning, fejlfinde problemer ved at finde lag af fejl og administrere implementeringen og tilbagetrækningen af specifikke agenter eller undernetværk.

For det andet, og afgørende i konteksten af store sprogmodeller (LLM'er), der styrker disse agenter, hjælper et hierarki dramatisk med at holde kontekststststørrelser i kontrol. Ved at segmentere agentlandskabet tager agentagenten på ethvert givent lag kun det begrænsede sæt af agenter eller underbrokere med i betragtning direkte under det. Denne struktur forhindrer den primære orkestrator i at indlæse beskrivelsen, funktionerne og den historiske kontekst for hver agent i sin hukommelse, hvilket undgår risikoen for hurtigt at overskride LLMs kontekstvinduesgrænser og udløser forbudte omkostninger og forsinkelser.

Agentnetværket kan implementeres på flere måder. To af dem er:

  1. Conway's Law – Intuitiv måde at tilknytte den til den hierarkiske struktur i den virkelige verden.
  2. Domænestyret design - Mere fokuseret på forretningsdomæner

Indstilling 1: Tilknytning med hierarkisk struktur i den virkelige verden

I en hierarkisk organisation flyder kommunikationen lodret - fra managers til underordnede - og beslutninger er ofte centraliserede. I henhold til Conways lov:

  • De systemer eller softwarearkitekturer, der opbygges af sådanne organisationer, har også en tendens til at være lagdelt og hierarkisk.
  • Hvert team har en tendens til at designe delsystemer, der afspejler sine egne grænser og autoriteter.
  • Grænsefladerne mellem systemer afspejler kommunikationskanaler mellem afdelingerne.

Agentnetværket kan også intuitivt tilknyttes til den virkelige hierarkiske struktur i en stor virksomhed efter Conways lov.

  • Konceptionsmodellen: Ligesom en organisation har forskellige divisioner, afdelinger og lag af ledelse (f.eks. C-suite, vicedirektører, direktører, managers), kan et agentnetværk, der fungerer inden for et specifikt domæne, modelleres som et parallelt organisationsdiagram.
  • Noder og Blade: I dette hierarki:
    • Træstrukturens Blade er de specialiserede agenter eller MCP'er. De er de funktionelle enheder, der udfører det faktiske arbejde (f.eks. en "databaseforespørgselsagent", en "kundegodkendelsesagent", en "sentimentanalyseagent"). De repræsenterer de individuelle bidragydere eller arbejdsenheder i organisationen.
    • Alle andre noder i hierarkiet, herunder rod- og mellemlag, er brokeragenter (eller underorkestratorer). Disse agenter udfører ikke den endelige opgave, men er ansvarlige for distribution, uddelegering, aggregering og konfliktløsning i deres specifikke domæne eller lag. En mægler på højt niveau uddelegerer en opgave til en "Sales Domain Broker", som til gengæld uddelegerer til en "Salgsmulighedsstyringsmægler", som udfører opgaven via en "Salgsmulighedsstatusopdateringsagent" (arket).

Denne struktur sikrer, at kompleksiteten administreres lokalt, konteksten er indeholdt, og systemet skaleres forudsigeligt og pålideligt. Du kan introducere nye specialagenter i specifikke, relevante forgreninger af organisationstræet.

Overvej analogien af et organisationsdiagram for digital arbejde. Hver YAML-fil repræsenterer hver af de interne organisationer (medarbejderes succes, sikkerhed, økonomi osv.). I hver organisation (agent-netværk) har du muligvis en hierarkisk struktur, hvorigennem aktører samarbejder, job opdeles i opgaver og tildeles. I det forrige diagram flyder kommunikationen fra top til bund. Og bladene er ikke begrænset til forbrug udelukkende af et sæt af brokeragenter.

Modelering af agentnetværk baseret på det menneskelige organisationsdiagram bærer risikoen for at kræve hyppig omarkitektur, især i firmaer, der gennemgår hyppige omorganisationer. En alternativ tilgang er at organisere agenter efter funktionelt domæne. Denne gruppering kan kræve krydsning af traditionelle menneskelige organisationsgrænser. F.eks. involverer introduktion af nye medarbejdere it-handlinger for hardware og brugerprovisionering, mens en salgsbevægelse kræver både drift og marketing.

Nikhil Aggarwal er hovedarkitekt hos Salesforce, hvor han leder arkitektur for MuleSoft og Salesforce Automation Clouds. Nikhil har over 18 års erfaring med at levere produkter i stor skala og er passioneret for skalerbar arkitektur, intuitive udvikleroplevelser og opbygning af højtydende teams. Før Salesforce ledte han flere initiativer i Microsoft Power Platform, Dataverse og Office 365 fra koncept til lancering. Hans arbejde fortsætter med at forme, hvordan moderne virksomheder tilslutter systemer, automatiserer arbejdsflows og låser forretningsværdien op i den første æra af AI.

Mariano Gonzalez tilsluttede sig MuleSoft i sine tidlige dage tilbage i 2011, hvor han specialiserede sig i missionskritiske distribuerede systemer, integration, PaaS og cloud computing. I dag er Marianos fokus på at fremme AI-platforme med særlig opmærksomhed på styring, orkestrering, opdagelse og observation. Med mere end 20 år i it-branchen har Mariano fungeret som softwarearkitekt og teamleder, der designer og leverer BPM-, ERP- og integrationsløsninger på tværs af sektorerne landbrug, energi, regering, it, telekommunikation og indholdsstyring.

Pedro Colunga er Software Engineer Architect hos Salesforce, der er specialiseret i API og Metadata Architecture. Med fokus på den fulde platformslivscyklus spiller Pedro en nøglerolle i at forme, hvordan organisationer interagerer med systemintelligens, semantik og metadatastyrede løsninger. Pedro's 20-årige karriere, som inkluderer iværksættererfaring, strækker sig over firmaer som Fuego, BEA Systems, Oracle og TekGenesis, et firma, der senere blev overtaget af MuleSoft, hvor han konsekvent har drevet platformsbaseret arkitektur og leveret dyb ekspertise inden for områder som BPM, RAD og Integrations.

Gulal Kumar er Software Engineering Architect hos Salesforce med fokus på data- og integrationsarkitektur. Med over 20 års erfaring inden for integration og API'er, moderniseringsprogrammer, sikkerhed og AIML-initiativer giver han et væld af ekspertise. Gulal har været engageret i at fremme forretningstransformationsinitiativer, forbedre sikkerhed og modstandsdygtighed, fremme arkitektonisk ekspertise og føre AIML-initiativer på tværs af forskellige domæner.