Runtime d'agents pour le travail coordonné | Dweve Nexus

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Assistance pour agent de codage et opérateur. Les métriques de démonstration sont illustratives.

Terminal, recherche, lint, test, git, et plus.

Se souvient de votre codebase et du contexte de l'équipe.

Des agents spécialisés collaborent sur différents aspects.

Chaque étape est enregistrée avec horodatage.

Les politiques, vérifications et tests s'exécutent toujours.

Examinez les diffs, demandez des modifications, approbation finale.

Rejouez toute session bit pour bit quand une révision est nécessaire.

Lire retry.ts, bug de délai d'attente tracé

Extraire garde + limiter les nouvelles tentatives

Agents autonomes qui écrivent du code et gardent des reçus

pour gérer les délais d'attente réseau, les réponses 5xx et les conditions idempotentes sûres. Helper pur, entièrement testé unitairement.

Groupes d'algorithmes par type de données

Entrée, politique, raisonnement sur un seul artefact

formé autour d'une tâche, et il montre son travail

A vérifié ce que vous aviez décidé avant

intention, portée, contenu, éthique, anomalie, exécution

objectif obj-281 · équipe de 5 spécialistes · cycle 1/1

L'exécution pour les organisations exécutables · un objectif, une équipe formée, une trace

exécuter la décision · retenir le paiement au fournisseur v-281

agir · étape d'approbation · décision #4f9e2c

en file d'attente pour les opérations, en attente d'approbation

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

compte · trace de contrainte scellée, rejouable de bout en bout

Base de connaissances : opérationnelle, épisodique, sémantique, procédurale

Apportez à Nexus un objectif qui traverse actuellement les personnes, les systèmes, les règles et les approbations. Voyez comment le travail est décomposé, comment l’organisation se forme, comment l’autorité est attribuée, comment les échecs sont contenus, et comment chaque contribution revient à un résultat responsable.

Chaque contribution revient à l’objectif

Pipeline, fan-out, délégation, blackboard, débat

Dweve Nexus, l’exécution des organisations exécutables

Nexus est un runtime multi-agents en Python pour un travail qui nécessite plus de structure qu’une simple boucle de prompt. Son implémentation sépare les agents, le cycle de vie des tâches, les workflows, la mémoire et le routage basé sur les capacités en composants distincts. Les builders Python, DweveScript et une CLI définissent et exécutent ce travail.

Correspondance des capacités, exigences explicites

Utilisez les builders Python, DweveScript ou la CLI pour définir les agents, les tâches et les workflows pour le travail que vous devez coordonner.

Composants pour le travail coordonné des agents

Générateurs Python, DweveScript et la CLI

De travail, épisodique, sémantique, procédurale et connaissances

Du déductif à l'hybride, sélectionnés selon la tâche

Dweve Nexus, chaque tâche a sa propre équipe

La plupart des outils d'IA confient chaque travail au même assistant. Nexus fonctionne différemment. Derrière Fabric, il forme une équipe autour de votre demande, envoie chaque partie au spécialiste qui lui convient, et renvoie un résultat unique dans la conversation que vous avez déjà ouverte. Vous demandez une fois. Nexus organise tout derrière.

Demandez une fois. Laissez Nexus former l'équipe, diviser le travail, rassembler les pièces et renvoyer un résultat unique. L'organisation travaille pour vous. L'autorité reste avec vous.

Les transferts typés maintiennent la cohérence de l'exécution. Celui qui signe pour le travail lit autre chose.

L'implémentation actuelle fournit des générateurs Python pour les agents et un compilateur DweveScript pour les définitions déclaratives d'agents et de flux de travail. Sa CLI analyse, compile et exécute les fichiers DweveScript. Ce sont des interfaces complémentaires à la même implémentation Python, plutôt que des revendications de clients équivalents en Rust, TypeScript ou Go. Une définition écrite dans l'un est la même définition lorsqu'elle est lue depuis l'autre, de sorte qu'une équipe peut passer du fichier déclaratif au générateur sans maintenir deux descriptions de la même organisation.

En plus des messages point à point, un bus d'événements typé est exécuté, ce sur quoi un groupe d'agents se coordonne réellement : demandes et résultats de tâches, acceptation et rejet, revendications et libérations, et événements de cycle de vie et de santé, avec des abonnés capables de filtrer, transférer, supprimer et transformer ce qu'ils reçoivent. Deux types d'état sont délibérément maintenus en dehors des messages individuels. Un tableau noir est une structure déclarée que les agents lisent et écrivent, de sorte qu'une contribution est lisible par quelqu'un d'autre que celui qui l'a écrite.

Événements, et l'état destiné à être partagé

Un transfert dans Nexus est une valeur avec une forme plutôt qu'un paragraphe qu'un agent espère que l'autre analysera. La couche de protocole transporte des types compatibles A2A pour les messages, les tâches, les artefacts, les capacités, les compétences, les rôles et les statuts, et JSON est une façon de les mettre sur le fil plutôt que le système de types lui-même. Les outils et les systèmes externes arrivent par contrat, et le protocole Model Context Protocol est pris en charge comme l'une de ces frontières où un client le souhaite. Un composant récepteur peut valider cette forme avant d'agir, et la trace rend le transfert inspectable. JSON est un choix de transport ; il ne remplace pas le contrat.

La relecture répond à ce qui s'est passé. Ce que les parties se transmettent est typé aussi étroitement.

Nexus a des composants séparés pour le routage, l'exécution des flux de travail, la communication, le raisonnement, la mémoire, la sécurité et la récupération. Cette séparation permet d'inspecter le composant pertinent lorsque le travail se comporte de manière inattendue, plutôt que de traiter chaque échec comme un problème de prompt. Chaque composant enregistre ce qu'il a décidé au moment où il l'a décidé, de sorte que la question après un incident est de savoir quel composant a changé plutôt que quelle phrase a été mal formulée. C'est cet enregistrement que la relecture lit en arrière.

La relecture capturée réutilise les sorties enregistrées de chaque appel externe et reconstruit l'exécution d'origine, ce qui teste les propres décisions de l'exécution avec le monde extérieur maintenu immobile. La relecture en direct appelle à nouveau les dépendances et compare, ce qui est le test qui peut échouer et donc celui qui vaut la peine d'être exécuté. La relecture capturée répond si l'exécution a pris les mêmes décisions avec le monde extérieur maintenu immobile. La relecture en direct répond si les dépendances d'aujourd'hui produisent toujours le même résultat. La comparaison est donc un test de l'environnement, pas une seconde copie de l'historique.

Tout cela peut être regardé en direct. Ce que l'exécution décide pour elle-même est réglé avant qu'elle ne s'exécute.

Des événements structurés sont émis par entité, et le déploiement décide quel magasin les reçoit : mémoire limitée sur un environnement de développement, magasin persistant en production, et stockage en ajout seul ou inviolable lorsque l'enregistrement doit tenir face à quelqu'un en dehors du bâtiment. Chacun de ces éléments est appelé ce qu'il est. L'exécution n'appelle pas les journaux mutables ordinaires immuables, ce qui est la différence entre une preuve que quelqu'un accepte et une affirmation qu'il teste. Les événements conservent leur entité et leur posture de stockage.

Les types d'entités posent des questions différentes, et l'asymétrie est la partie utile. Demander à un agent s'il est en bonne santé a du sens, et demander la même chose à une opération n'en a pas, car une opération est soit bloquée, soit elle ne l'est pas, et sa santé n'est que celle de qui se trouve à l'intérieur. Une unité de travail a une échéance et un nombre de tentatives, et un groupe n'a ni l'un ni l'autre : ce qu'a un groupe, c'est une appartenance et un enregistrement de ce sur quoi il a travaillé. Comme aucune de ces deux séries ne correspond, un seul flux de lignes répond mal aux quatre questions.

Une question de production est rarement ce qu'un journal a dit. C'est quelle unité de travail a manqué son échéance, quel agent est en mauvaise santé, quelle partie de l'opération est bloquée et sur quoi. Nexus rapporte l'état sur les mêmes choses qu'il exécute, donc la question va à ce qui possède la réponse au lieu d'être assemblée à partir de lignes qui la mentionnent par hasard. Cela rend la question adressable sans rejouer une conversation. L'état appartient à l'entité qui possède le travail, donc une échéance manquée, un agent en mauvaise santé ou une opération bloquée peuvent être examinés à partir de son enregistrement et de sa condition actuelle.

La récupération est quelque chose dont on vous informe. La regarder pendant qu'elle s'exécute est une demande différente.

Deux conséquences qu'un ingénieur peut utiliser. Parce que l'attente est un point fixe déterministe calculé à partir du numéro de tentative plutôt qu'un tirage d'une source aléatoire, le calendrier d'une exécution échouée fait partie de ce qui se rejoue, donc une discussion sur la durée d'hier a une réponse plutôt qu'une théorie. Et parce que le circuit appartient à l'agent plutôt qu'au type de travail, une dépendance défaillante cesse d'acheminer vers un endroit tandis que le même travail reste acheminable partout ailleurs. Chaque substitution est écrite au fur et à mesure : le réacheminement nomme l'agent de remplacement et l'état qui l'accompagnait, donc une exécution secourue se lit ensuite comme une seule pièce de travail avec une récupération à l'intérieur.