Ügynök-futtatókörnyezet összehangolt munkához | Dweve Nexus

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Kódolási ügynök és operátori segítség. A bemutató mérőszámok illusztratívak.

Terminál, keresés, lint, teszt, git és egyebek.

Megjegyzi a kódbázis és a csapat kontextusát.

Speciális ügynökök együttműködnek a különböző területeken.

A szabályzatok, ellenőrzések és tesztek mindig futnak.

Diffek áttekintése, változtatások kérése, végső jóváhagyás.

Bármely munkamenet bitre pontosan visszajátszható, ha valamit ellenőrizni kell.

retry.ts olvasása, időtúllépési hiba nyomon követése

Guard kivonása + újrapróbálkozások korlátozása

Autonóm ügynökök, amelyek kódot írnak és nyomot hagynak

hálózati időtúllépések, 5xx válaszok és idempotens-biztos feltételek kezelésére. Tiszta segédfüggvény, teljesen egységtesztelve.

Bemenet, szabályzat, érvelés egy artefaktumon

Megáll, mielőtt bármi visszafordíthatatlan történne

egy feladat köré szerveződik, és megmutatja, mit csinál

szándék, hatókör, tartalom, etika, anomália, futásidő

cél obj-281 · csapat 5 szakértő · ciklus 1/1

A futásidő végrehajtható szervezeteknek · egy cél, egy megalakított csapat, egy nyomvonal

döntés futtatása · fizetés visszatartása a v-281 szállítónál

művelet · jóváhagyási kapu · #4f9e2c döntés

aláírás · M. Bos, ops-3 · 2026-04-12 09:14 CET

fiók · megkötési nyomvonal lezárva, végponttól végpontig visszajátszható

Működő, epizodikus, szemantikus, procedurális, tudásbázis

Hozzon a Nexusnak egy célt, amely jelenleg embereket, rendszereket, szabályokat és jóváhagyásokat keresztez. Nézze meg, hogyan bomlik le a munka, hogyan alakul ki a szervezet, hogyan rendelődik hozzá a hatáskör, hogyan korlátozódik a hiba, és hogyan tér vissza minden hozzájárulás egy elszámoltatható kimenethez.

Csővezeték, fan-out, delegálás, blackboard, vita

Dweve Nexus, a végrehajtható szervezetek futtatókörnyezete

A Nexus egy Python többágenses futtatókörnyezet olyan munkához, amely több struktúrát igényel, mint egy promptciklus. Megvalósítása külön komponensekre bontja az ágenseket, a feladatéletciklust, a munkafolyamatokat, a memóriát és a képességalapú útválasztást. Python-builder, DweveScript és CLI határozza meg és futtatja ezt a munkát.

Python futtatókörnyezet, külön komponensek

Képességegyeztetés, explicit követelmények

Használja a Python-buildereket, a DweveScriptet vagy a CLI-t az ágensek, feladatok és munkafolyamatok meghatározásához az összehangolandó munkához.

Összetevők az összehangolt ügynökmunkához

Munkamemória, epizodikus, szemantikus, procedurális és tudás

Deduktívtól a hibridig, a feladathoz igazítva

Dweve Nexus, minden feladat megkapja a saját csapatát

A legtöbb AI-eszköz minden munkát ugyanannak az asszisztensnek ad. A Nexus másképp működik. A Fabric mögött csapatot szervez a kérésed köré, minden részt a hozzá illő szakembernek küld, és egyetlen eredményt ad vissza abban a beszélgetésben, amelyet már megnyitottál. Egyszer kérdezel. A Nexus mindent megszervez mögötte.

Kérdezz egyszer. Hagyd, hogy a Nexus csapatot formáljon, ossza szét a munkát, hozza össze a darabokat, és adjon vissza egy eredményt. A szervezet érted dolgozik. A hatalom nálad marad.

A gépelt átadások koherenssé teszik a futásidőt. Aki aláírja a munkát, az valami mást olvas.

A jelenlegi implementáció Python-builderokat biztosít az ügynökökhöz és egy DweveScript-fordítót a deklaratív ügynök- és munkafolyamat-definíciókhoz. A CLI elemzi, fordítja és futtatja a DweveScript-fájlokat. Ezek komplementer felületek ugyanahhoz a Python-implementációhoz, nem pedig egyenértékű Rust-, TypeScript- vagy Go-kliens ígéretei. Az egyikben írt definíció ugyanaz a definíció, ha a másikból olvassák, így a csapat mozoghat a deklaratív fájl és a builder között anélkül, hogy két leírást tartana fenn ugyanarról a szervezetről.

A pont-pont üzenetek mellett egy gépelt eseménysín fut, amelyen egy ügynökcsoport valójában összehangolódik: feladatkérések és eredmények, elfogadás és elutasítás, igénylések és felszabadítások, valamint életciklus- és állapotesemények, a feliratkozók szűrhetik, továbbíthatják, eldobhatják és átalakíthatják, amit kapnak. Kétféle állapotot szándékosan az egyes üzeneteken kívül tartanak. A blackboard egy deklarált struktúra, amelyet az ügynökök olvasnak és írnak, így egy hozzájárulás olvasható más számára is, nem csak annak, aki írta.

Események és a megosztásra szánt állapot

A Nexusban egy átadás egy érték, amelynek alakja van, nem pedig egy bekezdés, amelyet az egyik ügynök remél, hogy a másik értelmez. A protokollréteg A2A-kompatibilis típusokat hordoz üzenetekhez, feladatokhoz, artefaktumokhoz, képességekhez, készségekhez, szerepekhez és állapotokhoz, és a JSON csak egy módja annak, hogy ezeket a vezetékre tegyük, nem maga a típustendszer. Az eszközök és a külső rendszerek szerződés alapján érkeznek, és a Model Context Protocol támogatott az egyik ilyen határfelületként, ahol az ügyfél igényli. A fogadó komponens ellenőrizheti az alakot, mielőtt cselekszik, és a nyomkövetés ellenőrizhetővé teszi az átadást. A JSON szállítási választás; nem helyettesíti a szerződést.

A visszajátszás megválaszolja, mi történt. Amit a részek átadnak egymásnak, az ugyanolyan szigorúan típusos.

A Nexus külön komponensekkel rendelkezik az útválasztáshoz, a munkafolyamat-végrehajtáshoz, a kommunikációhoz, az érveléshez, a memóriához, a biztonsághoz és a helyreállításhoz. Ez a szétválasztás lehetővé teszi, hogy a megfelelő komponenst vizsgáljuk meg, ha a munka váratlanul viselkedik, nem pedig minden hibát prompt-problémaként kezelünk. Minden komponens rögzíti, hogy mit döntött abban a pillanatban, amikor döntött, így egy incidens után a kérdés az, hogy melyik komponens változott, nem pedig az, hogy melyik mondat volt rosszul megfogalmazva. Ezt a rekordot olvassa vissza a visszajátszás.

A rögzített visszajátszás újra felhasználja minden külső hívás rögzített kimenetét, és rekonstruálja az eredeti futást, ami a futásidő saját döntéseit teszteli úgy, hogy a külvilágot mozdulatlanul tartja. Az élő visszajátszás újra meghívja a függőségeket, és összehasonlít, ez az a teszt, amely elbukhat, és ezért érdemes futtatni. A rögzített visszajátszás arra válaszol, hogy a futásidő ugyanazokat a döntéseket hozta-e, miközben a külvilág mozdulatlan volt. Az élő visszajátszás arra válaszol, hogy a mai függőségek még mindig ugyanazt az eredményt adják-e. Az összehasonlítás tehát a környezet tesztje, nem a történelem második másolata.

Mindez élőben megfigyelhető. Amit a futásidő eldönt magának, az a futás előtt eldől.

A strukturált események entitásonként kerülnek kibocsátásra, és a telepítés dönti el, melyik tároló fogadja őket: korlátos memória egy fejlesztési környezetben, perzisztens tároló élesben, és append-only vagy hamisításbiztos tároló, ahol a rekordnak meg kell állnia a helyét az épületen kívüli személy előtt. Mindegyiket annak nevezik, ami. A futásidő nem nevezi a közönséges változtatható naplókat megváltoztathatatlannak, ez a különbség az elfogadott bizonyíték és a tesztelendő állítás között. Az események megtartják entitásukat és tárolási pozíciójukat.

A különböző entitástípusok más-más kérdéseket fogadnak el, és éppen ez az aszimmetria a hasznos. Egy ágensről megkérdezni, hogy mennyire egészséges, értelmes, de ugyanezt egy művelettől kérdezni nem az, mert egy művelet vagy blokkolva van, vagy nincs, és az egészsége csak annak az egészsége, aki benne van. Egy munkaegységnek van határideje és újrapróbálkozások száma, egy csoportnak pedig egyik sincs: amije van, az a tagság és a nyilvántartás arról, hogy min dolgozott. Mivel ezek a halmazok páronként sem egyeznek, egyetlen lapos soráram mind a négyre rosszul válaszol.

Egy éles kérdés ritkán az, amit egy napló mondott. Hanem az, hogy melyik munkaegység mulasztotta el a határidejét, melyik ágens egészségtelen, a művelet melyik része blokkolt és mi miatt. A Nexus ugyanazokon a dolgokon jelent állapotot, amelyeken végrehajt, így a kérdés ahhoz kerül, aki a válasz birtokában van, nem pedig olyan sorokból áll össze, amelyek épp említik. Ez a kérdést megválaszolhatóvá teszi anélkül, hogy újra kellene játszani egy beszélgetést. Az állapot azé az entitásé, amelyik a munkát birtokolja, így egy elmulasztott határidő, egészségtelen ágens vagy blokkolt művelet a rekordjából és aktuális állapotából vizsgálható.

A helyreállításról szólnak neked. Másképp nézni, ahogy fut, más igény.

Két következmény, amit egy mérnök használhat. Mivel a várakozás determinisztikus fixpont, amit a próbálkozás számából számítanak, nem pedig véletlen forrásból húznak, a sikertelen futás ütemezése része annak, ami újrajátszható, így egy vitának arról, hogy mennyi ideig tartott tegnap, van válasza, nem pedig elmélete. És mivel az áramkör az ágenshez tartozik, nem pedig a munka fajtájához, egy meghibásodó függőség leállítja az útválasztást egy helyre, miközben ugyanaz a munka máshol útválasztható marad. Minden helyettesítés le van írva, ahogy történik: az átirányítás megnevezi a helyettesítő ágenst és az állapotot, ami vele utazott, így egy megmentett futás utólag egyetlen munkadarabként olvasható, benne egy helyreállítással.

Valami el fog bukni, és az érdekes kérdés nem az, hogy melyik választást választják. Hanem az, hogy mi akadályozza meg, hogy a helyreállítás maga legyen a terhelés. Minden része korlátozva van, mielőtt a baj elkezdődik: hány próbálkozás, mennyi ideig tart minden várakozás, mennyit költhet a mentés az engedményből, és mennyit visz magával az ingatlanból egy rossz függőség. Itt semmi nem ér véget azért, mert egy ciklus úgy döntött, hogy elég keményen próbálkozott. A futásidejű környezet rögzíti a próbálkozás számát, a számított várakozást, az áramkör állapotát, a helyettesítést és az átvitt állapotot. Ez egy incidens-áttekintésnek korlátozott utat ad a vizsgálatra: egy újrapróbálkozás újrajátszható, egy lezárt útvonal megmagyarázható, és egy végleges hiba megkülönböztethető egy befejezett mentéstől.