Runtime di agenti per il lavoro coordinato | Dweve Nexus

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Assistenza per agenti di codifica e operatori. Le metriche demo sono illustrative.

Terminale, ricerca, lint, test, git e altro.

Ricorda il tuo codebase e il contesto del team.

Agenti specializzati collaborano su diversi ambiti.

Ogni passaggio è registrato con timestamp.

Politiche, controlli e test vengono sempre eseguiti.

Rivedi le diff, richiedi modifiche, approvazione finale.

Riproduci qualsiasi sessione bit per bit quando qualcosa richiede revisione.

Leggi retry.ts, individuato bug di timeout

Agenti autonomi che scrivono codice e tengono traccia

per gestire timeout di rete, risposte 5xx e condizioni idempotent-safe. Helper puro, completamente testato.

Input, policy, ragionamento su un unico artefatto

Si ferma prima di qualsiasi cosa irreversibile

formato attorno a un unico compito, e mostra il proprio lavoro

Ha individuato il passo successivo migliore

Ha verificato le tue decisioni precedenti

episodico + semantico · 4 corrispondenze

intento, ambito, contenuto, etica, anomalia, runtime

obiettivo obj-281 · team di 5 specialisti · ciclo 1/1

Il runtime per organizzazioni eseguibili · un obiettivo, un team formato, una traccia

esegui decisione · mantieni pagamento al fornitore v-281

azione · gate di approvazione · decisione #4f9e2c

in coda per le operazioni, in attesa di approvazione

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

account · traccia dei vincoli sigillata, riproducibile dall'inizio alla fine

Knowledge base di lavoro, episodica, semantica, procedurale

a un obiettivo, un'operazione responsabile

rimane nei limiti della propria autorità

Porta a Nexus un obiettivo che oggi attraversa persone, sistemi, regole e approvazioni. Osserva come il lavoro viene scomposto, come si forma l'organizzazione, come viene assegnata l'autorità, come vengono contenuti i fallimenti e come ogni contributo confluisce in un unico risultato responsabile.

Ogni contributo confluisce nell'obiettivo

Pipeline, fan-out, delega, blackboard, dibattito

Dweve Nexus, il runtime per Organizzazioni Eseguibili

Nexus è un runtime multi-agente in Python per lavori che richiedono più struttura di un semplice ciclo di prompt. La sua implementazione separa agenti, ciclo di vita delle attività, flussi di lavoro, memoria e routing basato sulle capacità in componenti distinti. I builder Python, DweveScript e una CLI definiscono ed eseguono quel lavoro.

Corrispondenza delle capacità, requisiti espliciti

Usa i builder Python, DweveScript o la CLI per definire agenti, attività e flussi di lavoro per il lavoro che devi coordinare.

Componenti per il lavoro coordinato degli agenti

Working, episodica, semantica, procedurale e conoscitiva

Dalla deduttiva all'ibrida, selezionata per il compito

Dweve Nexus, ogni attività ha il suo team

La maggior parte degli strumenti AI affida ogni lavoro allo stesso assistente. Nexus funziona diversamente. Dietro Fabric forma un team attorno a ciò che hai chiesto, invia ogni parte allo specialista adatto e restituisce un unico risultato attraverso la conversazione che hai già aperto. Chiedi una volta. Nexus organizza tutto dietro le quinte.

Chiedi una volta. Lascia che Nexus formi il team, divida il lavoro, riunisca i pezzi e restituisca un unico risultato. L'organizzazione lavora per te. L'autorità resta a te.

I passaggi di consegne tipizzati mantengono coerente il runtime. Chi firma per il lavoro legge qualcos'altro.

L'implementazione attuale fornisce builder Python per gli agenti e un compilatore DweveScript per definizioni dichiarative di agenti e flussi di lavoro. La sua CLI analizza, compila ed esegue file DweveScript. Queste sono interfacce complementari alla stessa implementazione Python, non affermazioni di client Rust, TypeScript o Go equivalenti. Una definizione scritta in una di esse è la stessa definizione quando letta dall'altra, quindi un team può passare dal file dichiarativo al builder senza mantenere due descrizioni della stessa organizzazione.

Accanto ai messaggi punto a punto viene eseguito un event bus tipizzato, su cui un gruppo di agenti si coordina effettivamente: richieste e risultati di attività, accettazioni e rifiuti, rivendicazioni e rilasci, ed eventi di ciclo di vita e salute, con gli abbonati in grado di filtrare, inoltrare, eliminare e trasformare ciò che ricevono. Due tipi di stato sono deliberatamente tenuti fuori dai singoli messaggi. Una blackboard è una struttura dichiarata che gli agenti leggono e scrivono, così un contributo è leggibile da qualcuno diverso da chi lo ha scritto.

Un passaggio di consegne in Nexus è un valore con una forma, non un paragrafo che un agente spera che un altro analizzi. Il livello di protocollo trasporta tipi compatibili A2A per messaggi, attività, artefatti, capacità, competenze, ruoli e stati, e JSON è un modo per metterli su un cavo, non il sistema di tipi stesso. Strumenti e sistemi esterni arrivano tramite contratto, e Model Context Protocol è supportato come uno di quei confini dove il cliente lo desidera. Un componente ricevente può validare quella forma prima di agire, e la traccia mantiene il passaggio ispezionabile. JSON è una scelta di trasporto; non sostituisce il contratto.

Replay risponde a cosa è successo. Ciò che le parti si scambiano è tipizzato altrettanto strettamente.

Nexus ha componenti separati per routing, esecuzione dei flussi di lavoro, comunicazione, ragionamento, memoria, sicurezza e recupero. Questa separazione rende possibile ispezionare il componente rilevante quando il lavoro si comporta in modo inaspettato, invece di trattare ogni errore come un problema di prompt. Ogni componente registra ciò che ha deciso nel momento in cui lo ha deciso, così la domanda dopo un incidente è quale componente è cambiato, non quale frase è stata formulata male. Quel record è ciò che un replay rilegge.

Il replay catturato riutilizza gli output registrati di ogni chiamata esterna e ricostruisce l'esecuzione originale, testando le decisioni del runtime con il mondo esterno fermo. Il replay live chiama di nuovo le dipendenze e confronta, che è il test che può fallire e quindi quello che vale la pena eseguire. Il replay catturato risponde se il runtime ha preso le stesse decisioni con il mondo esterno fermo. Il replay live risponde se le dipendenze di oggi producono ancora lo stesso risultato. Il confronto è quindi un test dell'ambiente, non una seconda copia della storia.

Tutto questo può essere osservato dal vivo. Ciò che il runtime decide per sé è stabilito prima che venga eseguito.

Gli eventi strutturati vengono emessi per entità, e la distribuzione decide quale archivio li riceve: memoria limitata su un ambiente di sviluppo, un archivio persistente in produzione e archiviazione append only o a prova di manomissione dove il record deve reggere di fronte a qualcuno esterno all'organizzazione. Ognuno di questi è chiamato con il suo nome. Il runtime non chiama immutabili i normali log mutabili, che è la differenza tra una prova che qualcuno accetta e un'affermazione che testa. Gli eventi mantengono la loro entità e postura di archiviazione.

I diversi tipi di entità accettano domande diverse, e l'asimmetria è la parte utile. Chiedere a un agente quanto sia sano ha senso, mentre fare la stessa domanda a un'operazione non lo ha, perché un'operazione o è bloccata o non lo è, e la sua salute è solo la salute di chi vi è dentro. Un'unità di lavoro ha una scadenza e un conteggio di tentativi, mentre un gruppo non ha né l'uno né l'altro: ciò che un gruppo ha è un'iscrizione e una registrazione di ciò su cui ha lavorato. Poiché nessuno di questi insiemi coincide, un unico flusso piatto di righe risponde male a tutte e quattro le domande.

Una domanda di produzione raramente riguarda ciò che un log ha detto. Riguarda quale unità di lavoro ha mancato la scadenza, quale agente non è sano, quale parte dell'operazione è bloccata e su cosa. Nexus riporta lo stato sulle stesse cose su cui opera, quindi la domanda va a chi possiede la risposta invece di essere assemblata da righe che casualmente la menzionano. Questo rende la domanda indirizzabile senza riprodurre una conversazione. Lo stato appartiene all'entità che possiede il lavoro, quindi una scadenza mancata, un agente non sano o un'operazione bloccata possono essere indagati dal suo record e dalla sua condizione attuale.

Il recupero è qualcosa di cui vieni informato. Guardarlo mentre è in esecuzione è una richiesta diversa.

Due conseguenze che un ingegnere può usare. Poiché l'attesa è un punto fisso deterministico calcolato dal numero di tentativi piuttosto che un'estrazione da una fonte casuale, la pianificazione di un'esecuzione fallita fa parte di ciò che viene riprodotto, quindi una discussione su quanto sia durato ieri ha una risposta piuttosto che una teoria. E poiché il circuito appartiene all'agente piuttosto che al tipo di lavoro, una dipendenza fallita ferma il routing verso un luogo mentre lo stesso lavoro rimane instradabile ovunque altro. Ogni sostituzione viene registrata mentre accade: il reindirizzamento nomina l'agente sostitutivo e lo stato che viaggiava con esso, quindi un'esecuzione salvata si legge in seguito come un unico pezzo di lavoro con un recupero al suo interno.