Agentenlaufzeit für koordiniertes Arbeiten | Dweve Nexus

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Coding-Agent und Operator-Unterstützung. Demokennzahlen sind illustrativ.

Terminal, Suche, Lint, Test, Git und mehr.

Merkt sich Ihre Codebasis und den Teamkontext.

Spezialisierte Agenten arbeiten fachübergreifend zusammen.

Jeder Schritt wird mit Zeitstempeln aufgezeichnet.

Richtlinien, Prüfungen und Tests laufen immer.

Diffs prüfen, Änderungen anfordern, endgültige Freigabe.

Jede Sitzung bitgenau wiedergeben, wenn etwas überprüft werden muss.

retry.ts lesen, Timeout-Fehler aufgespürt

Guard extrahieren + Wiederholungen begrenzen

Autonome Agenten, die Code schreiben und Belege aufbewahren

zur Behandlung von Netzwerk-Timeouts, 5xx-Antworten und idempotent-sicheren Bedingungen. Reine Hilfsfunktion, vollständig unit-getestet.

Eingabe, Richtlinie, Begründung auf einem Artefakt

verwaltetes Mesh, vor Ort, luftdicht abgeschottet

um eine Aufgabe herum geformt, und es zeigt seine Arbeit

Den besten nächsten Schritt ausgearbeitet

Geprüft, was Sie zuvor entschieden haben

Absicht, Umfang, Inhalt, Ethik, Anomalie, Laufzeit

Ziel obj-281 · Team 5 Spezialisten · Zyklus 1/1

Die Laufzeit für ausführbare Organisationen · ein Ziel, ein geformtes Team, eine Spur

Entscheidung ausführen · Zahlung an Anbieter v-281 zurückhalten

Aktion · Genehmigungsstufe · Entscheidung #4f9e2c

für Betrieb in Warteschlange, wartet auf Genehmiger

Signatur · M. Bos, ops-3 · 2026-04-12 09:14 MEZ

Konto · Einschränkungsspur versiegelt, Ende-zu-Ende wiederholbar

Arbeits-, episodisch, semantisch, prozedural, Wissensbasis

Eine rechenschaftspflichtige Organisation entsteht

ein Ziel, ein rechenschaftspflichtiger Betrieb

Bringen Sie Nexus ein Ziel, das derzeit Menschen, Systeme, Regeln und Genehmigungen umfasst. Sehen Sie, wie die Arbeit zerlegt wird, wie die Organisation entsteht, wie Befugnisse zugewiesen werden, wie Fehler eingedämmt werden und wie jeder Beitrag zu einem rechenschaftspflichtigen Ergebnis zurückkehrt.

Pipeline, Fan-out, Delegation, Blackboard, Debatte

Dweve Nexus, die Laufzeit für ausführbare Organisationen

Nexus ist eine Python-Multi-Agenten-Laufzeit für Arbeit, die mehr Struktur als eine Prompt-Schleife benötigt. Seine Implementierung trennt Agenten, Aufgabenlebenszyklus, Workflows, Speicher und fähigkeitsbasierte Weiterleitung in separate Komponenten. Python-Builder, DweveScript und eine CLI definieren und führen diese Arbeit aus.

Fähigkeitsabgleich, explizite Anforderungen

Verwenden Sie die Python-Builder, DweveScript oder CLI, um Agenten, Aufgaben und Workflows für die Arbeit zu definieren, die Sie koordinieren müssen.

Komponenten für koordinierte Agentenarbeit

Arbeits-, episodisches, semantisches, prozedurales und Wissensgedächtnis

Deduktiv bis hybrid, je nach Aufgabe ausgewählt

Dweve Nexus, jede Aufgabe bekommt ihr eigenes Team

Die meisten KI-Tools geben jede Aufgabe demselben Assistenten. Nexus funktioniert anders. Hinter Fabric bildet es ein Team um das, was du gefragt hast, schickt jeden Teil an den Spezialisten, der dazu passt, und liefert ein Ergebnis durch das Gespräch, das du bereits geöffnet hast. Du fragst einmal. Nexus organisiert alles dahinter.

Frag einmal. Lass Nexus das Team bilden, die Arbeit aufteilen, die Teile zusammenführen und ein Ergebnis liefern. Die Organisation arbeitet für dich. Die Autorität bleibt bei dir.

Typisierte Übergaben halten die Laufzeit kohärent. Wer die Arbeit übernimmt, liest etwas anderes.

Die aktuelle Implementierung bietet Python-Builder für Agenten und einen DweveScript-Compiler für deklarative Agenten- und Workflow-Definitionen. Seine CLI parst, kompiliert und führt DweveScript-Dateien aus. Das sind komplementäre Schnittstellen zur selben Python-Implementierung, keine Behauptungen über gleichwertige Rust-, TypeScript- oder Go-Clients. Eine Definition, die in einer davon geschrieben wurde, ist dieselbe Definition, wenn sie aus der anderen gelesen wird, sodass ein Team zwischen der deklarativen Datei und dem Builder wechseln kann, ohne zwei Beschreibungen derselben Organisation zu pflegen.

Neben Punkt-zu-Punkt-Nachrichten läuft ein typisierter Event-Bus, auf den sich eine Gruppe von Agenten tatsächlich koordiniert: Aufgabenanfragen und -ergebnisse, Annahme und Ablehnung, Ansprüche und Freigaben sowie Lebenszyklus- und Gesundheitsereignisse, wobei Abonnenten filtern, weiterleiten, verwerfen und transformieren können, was sie empfangen. Zwei Arten von Zustand werden bewusst außerhalb einzelner Nachrichten gehalten. Ein Blackboard ist eine deklarierte Struktur, die Agenten lesen und schreiben, sodass ein Beitrag für etwas anderes lesbar ist als nur für den, der ihn geschrieben hat.

Ereignisse und der Zustand, der geteilt werden soll

Eine Übergabe in Nexus ist ein Wert mit einer Form, kein Absatz, von dem ein Agent hofft, dass ein anderer ihn parst. Die Protokollschicht trägt A2A-kompatible Typen für Nachrichten, Aufgaben, Artefakte, Fähigkeiten, Fertigkeiten, Rollen und Status, und JSON ist eine Möglichkeit, diese auf die Leitung zu bringen, nicht das Typsystem selbst. Tools und externe Systeme kommen per Vertrag, und Model Context Protocol wird als eine dieser Grenzen unterstützt, wo ein Kunde es wünscht. Eine empfangende Komponente kann diese Form validieren, bevor sie handelt, und die Spur hält die Übergabe prüfbar. JSON ist eine Transportwahl; es ersetzt nicht den Vertrag.

Replay beantwortet, was passiert ist. Was die Teile einander übergeben, ist ebenso streng typisiert.

Nexus hat separate Komponenten für Routing, Workflow-Ausführung, Kommunikation, Denken, Gedächtnis, Sicherheit und Wiederherstellung. Diese Trennung ermöglicht es, die relevante Komponente zu untersuchen, wenn sich Arbeit unerwartet verhält, statt jeden Fehler als Prompt-Problem zu behandeln. Jede Komponente zeichnet auf, was sie in dem Moment entschieden hat, in dem sie es entschieden hat, sodass die Frage nach einem Vorfall ist, welche Komponente sich geändert hat, nicht welcher Satz schlecht formuliert war. Diese Aufzeichnung ist es, die ein Replay zurückliest.

Erfasstes Replay verwendet die aufgezeichneten Ausgaben jedes externen Aufrufs erneut und rekonstruiert den ursprünglichen Lauf, was die eigenen Entscheidungen der Laufzeit testet, während die Außenwelt stillgehalten wird. Live-Replay ruft die Abhängigkeiten erneut auf und vergleicht, was der Test ist, der fehlschlagen kann und daher derjenige, der sich lohnt. Erfasstes Replay beantwortet, ob die Laufzeit dieselben Entscheidungen getroffen hat, während die Außenwelt stillgehalten wurde. Live-Replay beantwortet, ob die heutigen Abhängigkeiten noch dasselbe Ergebnis liefern. Der Vergleich ist daher ein Test der Umgebung, keine zweite Kopie der Geschichte.

Zwei Möglichkeiten, es erneut auszuführen

All das kann live beobachtet werden. Was die Laufzeit selbst entscheidet, ist festgelegt, bevor sie läuft.

Strukturierte Ereignisse werden pro Entität ausgegeben, und die Bereitstellung entscheidet, welcher Speicher sie empfängt: begrenzter Speicher in einer Entwicklungsumgebung, persistenter Speicher in der Produktion und Append-Only- oder manipulationssichere Speicherung, wo die Aufzeichnung vor jemandem außerhalb des Gebäudes bestehen muss. Jede davon wird beim Namen genannt. Die Laufzeit nennt gewöhnliche veränderliche Logs nicht unveränderlich, was den Unterschied zwischen Beweisen, die jemand akzeptiert, und einer Behauptung, die sie testen, ausmacht. Ereignisse behalten ihre Entität und Speicherhaltung.

Die Arten von Entitäten stellen unterschiedliche Fragen, und genau diese Asymmetrie ist das Nützliche. Einen Agenten zu fragen, wie gesund er ist, ergibt Sinn, dieselbe Frage an eine Operation zu stellen jedoch nicht, denn eine Operation ist entweder blockiert oder nicht, und ihre Gesundheit ist nur die Gesundheit dessen, der sich in ihr befindet. Eine Arbeitseinheit hat eine Frist und eine Anzahl von Wiederholungen, eine Gruppe hat beides nicht: Was eine Gruppe hat, ist eine Mitgliedschaft und eine Aufzeichnung dessen, woran sie gearbeitet hat. Da keine zwei dieser Mengen übereinstimmen, beantwortet ein einziger flacher Strom von Zeilen alle vier schlecht.

Eine Produktionsfrage ist selten, was ein Log gesagt hat. Es geht darum, welche Arbeitseinheit ihre Frist verpasst hat, welcher Agent ungesund ist, welcher Teil der Operation blockiert ist und worauf. Nexus meldet Zustände zu denselben Dingen, die es ausführt, sodass die Frage an denjenigen geht, der die Antwort besitzt, anstatt aus Zeilen zusammengesetzt zu werden, die sie zufällig erwähnen. Das macht die Frage adressierbar, ohne ein Gespräch abzuspielen. Der Zustand gehört der Entität, die die Arbeit besitzt, sodass eine verpasste Frist, ein ungesunder Agent oder eine blockierte Operation anhand ihrer Aufzeichnung und ihres aktuellen Zustands untersucht werden kann.

Über die Wiederherstellung wirst du informiert. Sie beim Laufen zu beobachten, ist eine andere Anforderung.

Zwei Konsequenzen, die ein Ingenieur nutzen kann. Da die Wartezeit ein deterministischer Fixpunkt ist, der aus der Versuchsnummer berechnet wird, und nicht aus einer Zufallsquelle stammt, ist der Zeitplan eines fehlgeschlagenen Laufs Teil dessen, was abgespielt wird, sodass eine Diskussion darüber, wie lange gestern gedauert hat, eine Antwort statt einer Theorie hat. Und da der Schutzschalter zum Agenten gehört und nicht zur Art der Arbeit, stoppt eine fehlgeschlagene Abhängigkeit das Routing an einer Stelle, während dieselbe Arbeit überall sonst routbar bleibt. Jede Ersetzung wird festgehalten, sobald sie geschieht: Die Umleitung benennt den Ersatzagenten und den Zustand, der mit ihm reiste, sodass ein geretteter Lauf danach als ein Stück Arbeit mit einer Wiederherstellung darin gelesen wird.