Runtime de agenți pentru lucru coordonat | Dweve Nexus

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Agent de codare și asistență pentru operatori. Metricile demonstrative sunt ilustrative.

Terminal, căutare, lint, test, git și altele.

Își amintește contextul bazei de cod și al echipei.

Agenți specializați colaborează pe diferite domenii.

Fiecare pas este înregistrat cu marcaje temporale.

Politicile, verificările și testele rulează întotdeauna.

Revizuiește diffs, solicită modificări, aprobă final.

Redă orice sesiune bit cu bit când ceva necesită revizuire.

Citește retry.ts, a depistat bug-ul de timeout

Agenți autonomi care scriu cod și păstrează dovezi

pentru a gestiona timeout-uri de rețea, răspunsuri 5xx și condiții sigure pentru idempotență. Helper pur, complet testat unitar.

Intrare, politică, raționament pe un singur artefact

format în jurul unei sarcini și își arată munca

intenție, scop, conținut, etică, anomalie, runtime

obiectiv obj-281 · echipă de 5 specialiști · ciclu 1/1

Runtime pentru organizații executabile · un obiectiv, o echipă formată, o urmă

decizie de rulare · reține plata către furnizorul v-281

acțiune · poartă de aprobare · decizia #4f9e2c

în coadă pentru operațiuni, în așteptarea aprobatorului

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

cont · constrângere de urmă sigilată, redifuzabilă de la cap la coadă

De lucru, episodic, semantic, procedural, bază de cunoștințe

unui singur obiectiv, o singură operațiune responsabilă

Adu Nexus un obiectiv care traversează în prezent oameni, sisteme, reguli și aprobări. Vezi cum este descompusă munca, cum se formează organizația, cum este atribuită autoritatea, cum este limitat eșecul și cum fiecare contribuție revine la un singur rezultat responsabil.

Pipeline, fan-out, delegare, blackboard, dezbatere

Dweve Nexus, runtime-ul pentru Organizații Executabile

Nexus este un runtime multi-agent în Python pentru munca ce necesită mai multă structură decât o buclă de prompt. Implementarea sa separă agenții, ciclul de viață al sarcinilor, fluxurile de lucru, memoria și rutarea bazată pe capabilități în componente distincte. Constructorii Python, DweveScript și o CLI definesc și rulează acea muncă.

Potrivirea capabilităților, cerințe explicite

Folosește constructorii Python, DweveScript sau CLI pentru a defini agenți, sarcini și fluxuri de lucru pentru munca pe care trebuie să o coordonezi.

Componente pentru munca coordonată a agenților

De lucru, episodică, semantică, procedurală și de cunoștințe

De la deductiv la hibrid, selectate pentru sarcină

Dweve Nexus, fiecare sarcină își are propria echipă

Cele mai multe instrumente AI dau aceeași sarcină aceluiași asistent. Nexus funcționează diferit. În spatele Fabric, formează o echipă în jurul a ceea ce ai cerut, trimite fiecare parte specialistului potrivit și returnează un singur rezultat prin conversația pe care ai deschis-o deja. Întrebi o dată. Nexus organizează totul în spate.

Întreabă o dată. Lasă Nexus să formeze echipa, să împartă munca, să aducă piesele împreună și să returneze un singur rezultat. Organizația lucrează pentru tine. Autoritatea rămâne la tine.

Predările tipizate mențin runtime-ul coerent. Oricine semnează pentru lucrare citește altceva.

Implementarea actuală oferă constructori Python pentru agenți și un compilator DweveScript pentru definiții declarative de agenți și fluxuri de lucru. CLI-ul său parsează, compilează și rulează fișiere DweveScript. Acestea sunt interfețe complementare către aceeași implementare Python, nu pretenții de clienți echivalenți în Rust, TypeScript sau Go. O definiție scrisă într-una dintre ele este aceeași definiție când este citită din cealaltă, astfel încât o echipă poate trece între fișierul declarativ și constructor fără să mențină două descrieri ale aceleiași organizații.

Pe lângă mesajele punct la punct, rulează un bus de evenimente tipizat, pe care un grup de agenți îl coordonează efectiv: cereri și rezultate de sarcini, acceptare și respingere, revendicări și eliberări, și evenimente de ciclu de viață și sănătate, cu abonați capabili să filtreze, să redirecționeze, să renunțe și să transforme ceea ce primesc. Două tipuri de stare sunt ținute în mod deliberat în afara mesajelor individuale. O blackboard este o structură declarată pe care agenții o citesc și o scriu, astfel încât o contribuție este lizibilă pentru altcineva decât cel care a scris-o.

Evenimente și starea care trebuie partajată

O predare în Nexus este o valoare cu o formă, nu un paragraf pe care un agent speră că altul îl parsează. Stratul de protocol transportă tipuri compatibile A2A pentru mesaje, sarcini, artefacte, capabilități, abilități, roluri și statusuri, iar JSON este o modalitate de a le pune pe fir, nu sistemul de tipuri în sine. Instrumentele și sistemele externe vin prin contract, iar Model Context Protocol este suportat ca una dintre acele granițe unde clientul o dorește. O componentă receptoare poate valida acea formă înainte de a acționa, iar urma menține predarea inspectabilă. JSON este o alegere de transport; nu înlocuiește contractul.

Replay răspunde la ce s-a întâmplat. Ce își predau părțile este tipizat la fel de strict.

Nexus are componente separate pentru rutare, execuția fluxurilor de lucru, comunicare, raționament, memorie, siguranță și recuperare. Această separare face posibilă inspectarea componentei relevante când munca se comportă neașteptat, mai degrabă decât tratarea fiecărui eșec ca o problemă de prompt. Fiecare componentă înregistrează ce a decis în momentul în care a decis, astfel încât întrebarea după un incident este care componentă s-a schimbat, nu care propoziție a fost formulată greșit. Acea înregistrare este ceea ce replay-ul citește înapoi.

Replay-ul capturat reutilizează ieșirile înregistrate ale fiecărui apel extern și reconstruiește rularea originală, ceea ce testează deciziile proprii ale runtime-ului cu lumea exterioară ținută nemișcată. Replay-ul live apelează din nou dependențele și compară, ceea ce este testul care poate eșua și, prin urmare, cel care merită rulat. Replay-ul capturat răspunde dacă runtime-ul a luat aceleași decizii cu lumea exterioară ținută nemișcată. Replay-ul live răspunde dacă dependențele de astăzi produc încă același rezultat. Comparația este, prin urmare, un test al mediului, nu o a doua copie a istoriei.

Toate acestea pot fi urmărite live. Ceea ce runtime-ul decide pentru sine este stabilit înainte de a rula.

Evenimentele structurate sunt emise per entitate, iar implementarea decide ce stocare le primește: memorie limitată pe un mediu de dezvoltare, stocare persistentă în producție și stocare append only sau tamper evident unde înregistrarea trebuie să reziste cuiva din afara clădirii. Fiecare dintre acestea este numită ceea ce este. Runtime-ul nu numește jurnalele obișnuite mutabile imutabile, ceea ce este diferența dintre o dovadă pe care cineva o acceptă și o afirmație pe care o testează. Evenimentele își păstrează entitatea și postura de stocare.

Tipurile de entitate primesc întrebări diferite, iar asimetria este partea utilă. Să întrebi un agent cât de sănătos este are sens, dar să pui aceeași întrebare unei operațiuni nu are, pentru că o operațiune fie este blocată, fie nu, iar sănătatea ei este doar sănătatea celui care se află în interiorul ei. O unitate de lucru are un termen limită și un număr de reîncercări, iar un grup nu are niciuna: ceea ce are un grup este o listă de membri și o evidență a lucrurilor la care a lucrat. Deoarece niciunul dintre aceste seturi nu se potrivește, un singur flux plat de linii răspunde prost la toate cele patru.

O întrebare de producție rareori este despre ce a spus un jurnal. Este despre care unitate de lucru a ratat termenul limită, care agent este nesănătos, care parte a operațiunii este blocată și pe ce. Nexus raportează starea acelorași lucruri pe care le execută, astfel încât întrebarea ajunge la cel care deține răspunsul, în loc să fie asamblată din linii care se întâmplă să o menționeze. Asta face întrebarea adresabilă fără a rejuca o conversație. Starea aparține entității care deține lucrarea, astfel încât un termen limită ratat, un agent nesănătos sau o operațiune blocată pot fi investigate din evidența și starea sa curentă.

Recuperarea este ceva despre care ești informat. Să o urmărești în timp ce rulează este o cerință diferită.

Două consecințe pe care un inginer le poate folosi. Deoarece așteptarea este un punct fix determinist calculat din numărul de încercări, nu o extragere dintr-o sursă aleatorie, programul unei rulări eșuate face parte din ceea ce se reia, astfel încât o discuție despre cât a durat ieri are un răspuns, nu o teorie. Și pentru că circuitul aparține agentului, nu tipului de lucrare, o dependență eșuată oprește rutarea către un singur loc, în timp ce aceeași lucrare rămâne rutabilă oriunde altundeva. Fiecare substituție este înregistrată pe măsură ce se întâmplă: rerutarea numește agentul de înlocuire și starea care a călătorit cu el, astfel încât o rulare salvată se citește ulterior ca o singură piesă de lucru cu o recuperare în interiorul ei.

Ceva va eșua, iar întrebarea interesantă nu este care răspuns este ales. Este ce oprește recuperarea să devină volumul de muncă. Fiecare parte a ei este limitată înainte să înceapă problemele: câte încercări, cât durează fiecare așteptare, cât din alocație poate cheltui o salvare și cât din patrimoniu ia cu ea o dependență proastă. Nimic aici nu se termină pentru că o buclă a decis că a încercat suficient. Runtime-ul înregistrează numărul de încercări, așteptarea calculată, starea circuitului, înlocuirea și starea transportată. Asta oferă unei analize de incident un traseu limitat de inspectat: o reîncercare poate fi reluată, o rută închisă poate fi explicată, iar o eșuare terminală poate fi distinsă de o salvare care s-a terminat.