AI-agentruntime til koordineret arbejde | Dweve Nexus

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Coding agent og operatørassistance. Demomålinger er illustrative.

Terminal, søgning, lint, test, git og mere.

Specialiserede agenter samarbejder på tværs af områder.

Hvert trin registreres med tidsstempler.

Politikker, kontroller og tests kører altid.

Gennemgå diffs, anmod om ændringer, endelig godkendelse.

Afspil enhver session bit-for-bit, når noget skal gennemgås.

Autonome agenter, der skriver kode og holder styr på kvitteringer

til at håndtere netværkstimeouts, 5xx-svar og idempotente-sikre betingelser. Ren hjælpefunktion, fuldt enhedstestet.

Input, politik, ræsonnement på ét artefakt

dannet omkring én opgave, og den viser sit arbejde

intention, omfang, indhold, etik, anomali, runtime

objekt obj-281 · team 5 specialister · cyklus 1/1

Runtime til eksekverbare organisationer · ét objekt, ét dannet team, ét spor

kør beslutning · hold betaling til leverandør v-281

handl · godkendelsesgate · beslutning #4f9e2c

underskriv · M. Bos, ops-3 · 2026-04-12 09:14 CET

konto · begrænsningsspor forseglet, afspilbart ende til ende

Arbejdende, episodisk, semantisk, proceduremæssig, vidensbase

Dweve Nexus, eksekverbare organisationer

Giv Nexus et mål, der i dag krydser mennesker, systemer, regler og godkendelser. Se, hvordan arbejdet nedbrydes, hvordan organisationen dannes, hvordan autoritet tildeles, hvordan fejl inddæmmes, og hvordan hvert bidrag vender tilbage til ét ansvarligt resultat.

Pipeline, fan-out, delegering, blackboard, debat

Dweve Nexus, runtime til eksekverbare organisationer

Nexus er en Python multi-agent runtime til arbejde, der har brug for mere struktur end en prompt-løkke. Implementeringen adskiller agenter, opgavelivscyklus, arbejdsgange, hukommelse og kapabilitetsbaseret routing i distinkte komponenter. Python-byggere, DweveScript og en CLI definerer og kører dette arbejde.

Brug Python-byggerne, DweveScript eller CLI til at definere agenter, opgaver og arbejdsgange for det arbejde, du skal koordinere.

Komponenter til koordineret agentarbejde

Arbejds-, episodisk, semantisk, proceduremæssig og vidensbaseret

Dweve Nexus, hver opgave får sit eget team

De fleste AI-værktøjer giver hver opgave til den samme assistent. Nexus fungerer anderledes. Bag Fabric danner det et team omkring det, du spurgte om, sender hver del til den specialist, der passer til den, og returnerer ét resultat gennem den samtale, du allerede har åbnet. Du spørger én gang. Nexus organiserer alt bagved.

Spørg én gang. Lad Nexus danne teamet, dele arbejdet, samle delene og returnere ét resultat. Organisationen arbejder for dig. Autoriteten forbliver hos dig.

Typede overdragelser holder runtime'en sammenhængende. Den, der kvitterer for arbejdet, læser noget andet.

Den nuværende implementering leverer Python-buildere til agenter og en DweveScript-kompiler til deklarative agent- og workflowdefinitioner. Dens CLI parser, kompilerer og kører DweveScript-filer. Disse er komplementære grænseflader til den samme Python-implementering, snarere end påstande om tilsvarende Rust-, TypeScript- eller Go-klienter. En definition skrevet i én af dem er den samme definition, når den læses fra den anden, så et team kan bevæge sig mellem den deklarative fil og builderen uden at vedligeholde to beskrivelser af den samme organisation.

Ved siden af punkt-til-punkt-beskeder kører en typet event bus, som er det, en gruppe agenter faktisk koordinerer om: opgaveanmodninger og resultater, accept og afvisning, krav og frigivelser samt livscyklus- og sundhedshændelser, hvor abonnenter kan filtrere, videresende, droppe og transformere det, de modtager. To slags tilstand holdes bevidst uden for individuelle beskeder. En blackboard er en erklæret struktur, som agenter læser og skriver, så et bidrag er læsbart for noget andet end den, der skrev det.

Hændelser og den tilstand, der er beregnet til at blive delt

En overdragelse i Nexus er en værdi med en form snarere end et afsnit, som én agent håber, en anden kan parse. Protokollaget bærer A2A-kompatible typer for beskeder, opgaver, artefakter, kapabiliteter, færdigheder, roller og statusser, og JSON er én måde at lægge dem på en ledning snarere end typesystemet selv. Værktøjer og eksterne systemer ankommer via kontrakt, og Model Context Protocol understøttes som én af de grænser, hvor en kunde ønsker det. En modtagende komponent kan validere formen, før den handler, og sporet holder overdragelsen inspekterbar. JSON er et transportvalg; det erstatter ikke kontrakten.

Replay svarer på, hvad der skete. Det, delene giver hinanden, er lige så stramt typet.

Nexus har separate komponenter til routing, workflowudførelse, kommunikation, ræsonnering, hukommelse, sikkerhed og genoprettelse. Denne adskillelse gør det muligt at inspicere den relevante komponent, når arbejde opfører sig uventet, snarere end at behandle enhver fejl som et promptproblem. Hver komponent registrerer, hvad den besluttede i det øjeblik, den besluttede det, så spørgsmålet efter en hændelse er, hvilken komponent der ændrede sig, snarere end hvilken sætning der var dårligt formuleret. Det er den registrering, et replay læser tilbage.

Captured replay genbruger de registrerede output fra hvert eksternt kald og rekonstruerer det oprindelige kørselsforløb, hvilket tester runtime'ens egne beslutninger med omverdenen holdt stille. Live replay kalder afhængighederne igen og sammenligner, hvilket er den test, der kan fejle, og derfor den, der er værd at køre. Captured replay svarer på, om runtime'en traf de samme beslutninger med omverdenen holdt stille. Live replay svarer på, om dagens afhængigheder stadig producerer det samme resultat. Sammenligningen er derfor en test af miljøet, ikke en anden kopi af historien.

Alt det kan overvåges live. Det, runtime'en beslutter for sig selv, er afgjort, før den kører.

Strukturerede hændelser udsendes pr. enhed, og deploymentet beslutter, hvilken butik der modtager dem: begrænset hukommelse på et udviklingsmiljø, en vedvarende butik i produktion og append-only eller manipulationssikker lagring, hvor registreringen skal kunne holde til nogen uden for bygningen. Hver af dem kaldes det, de er. Runtime'en kalder ikke almindelige mutable logs immutable, hvilket er forskellen mellem beviser, nogen accepterer, og en påstand, de tester. Hændelser bevarer deres enhed og lagringsposition.

De forskellige slags enheder stiller forskellige spørgsmål, og asymmetrien er det nyttige. Det giver mening at spørge en agent, hvor rask den er, men det giver ikke mening at spørge en operation om det samme, for en operation er enten blokeret eller ej, og dens helbred er kun helbredet hos den, der er indeni. En arbejdsenhed har en deadline og et antal forsøg, og en gruppe har ingen af delene: det, en gruppe har, er et medlemskab og en registrering af, hvad den har arbejdet på. Da ingen af disse sæt matcher, besvarer én flad strøm af linjer alle fire dårligt.

Et produktionsspørgsmål handler sjældent om, hvad en log sagde. Det handler om, hvilken arbejdsenhed der overskred sin deadline, hvilken agent der er usund, hvilken del af operationen der er blokeret, og på hvad. Nexus rapporterer tilstand om de samme ting, som det udfører, så spørgsmålet går til den, der ejer svaret, i stedet for at blive samlet ud af linjer, der tilfældigvis nævner det. Det gør spørgsmålet adresserbart uden at afspille en samtale. Tilstanden tilhører den enhed, der ejer arbejdet, så en overskredet deadline, en usund agent eller en blokeret operation kan undersøges ud fra dens registrering og aktuelle tilstand.

Gendannelse er noget, du får at vide om. At observere den, mens den kører, er et andet krav.

To konsekvenser, en ingeniør kan bruge. Fordi ventetiden er et deterministisk fikspunkt beregnet ud fra forsøgsnummeret snarere end et træk fra en tilfældig kilde, er tidsplanen for en mislykket kørsel en del af det, der afspilles, så en diskussion om, hvor lang tid i går tog, har et svar snarere end en teori. Og fordi kredsløbet tilhører agenten snarere end arbejdstypen, stopper en fejlende afhængighed routing til ét sted, mens det samme arbejde forbliver routbart alle andre steder. Hver substitution skrives ned, mens den sker: omdirigeringen navngiver erstatningsagenten og den tilstand, der fulgte med, så en reddet kørsel bagefter læses som ét stykke arbejde med en gendannelse indeni.

Noget vil fejle, og det interessante spørgsmål er ikke, hvilket svar der vælges. Det er, hvad der forhindrer gendannelsen i at blive arbejdsbyrden. Hver del af den er afgrænset, før problemerne starter: hvor mange forsøg, hvor lang hver ventetid er, hvor meget af tillægget en redning må bruge, og hvor meget af ejendommen én dårlig afhængighed tager med sig. Intet her ender, fordi en løkke besluttede, at den havde prøvet hårdt nok. Runtime registrerer forsøgsnummeret, beregnet ventetid, kredsløbstilstand, erstatning og tilstand, der føres over. Det giver en hændelsesgennemgang en afgrænset sti at inspicere: et forsøg kan afspilles, en lukket rute kan forklares, og en terminal fejl kan skelnes fra en redning, der blev fuldført.

Politik beslutter, hvad der må ske. Noget skal beslutte, hvad der sker, når det ikke vil.