VCPToolBox: ein Agentenrahmen, der das Modell zum Bewohner einer eigenen Zeitlinie machen will

Das Problem, das VCPToolBox anders löst als eine Tool-Calling-Schicht

Die README formuliert den Ausgangspunkt als Satz: In gängigen Agentenrahmen sei das Modell ein Aufgerufener, das nach der Antwort wieder in einen Zustand ohne Kontext zurückfalle. VCPToolBox setzt dagegen an einer konkreten technischen Lücke an: Die Entscheidung, welches Wissen in den Prompt gehört, wird aus dem Modell herausgenommen und in eine Schicht vor dem Modell verlagert. Das Projekt nennt das Gravitation statt Query. Gemeint ist damit, dass ein System außerhalb des Modells fortlaufend berechnet, welche Erinnerungen, Umgebungsdaten und Werkzeugrechte in den aktuellen Turn gehören. Die Zielgruppe sind entsprechend nicht Teams, die eine einzelne Funktion an ein LLM hängen wollen, sondern Betreiber, die einen dauerhaft laufenden Agenten mit eigenem Gedächtnis, mehreren Frontends und verteilten Knoten aufsetzen. Die README adressiert diese Gruppe direkt und warnt zugleich: Der Agent habe Rechte auf Ebene eines verteilten Systems, und nicht offizielle API-Zugänge könnten Daten, Gedächtnisinhalte und Schlüssel offenlegen. Das ist eine ungewöhnlich deutliche Selbstbeschränkung für ein Projekt dieser Art, und sie ist ernst zu nehmen, weil die Schicht zwischen Modell und Anwendung naturgemäß alle Nachrichten sieht.

Wie die Schicht zwischen API und Frontend arbeitet

VCPToolBox sitzt laut Beschreibung zwischen Modell-API und Frontend-Anwendung. Die README beschreibt den Datenfluss als Kette: Aus dem gesamten Kontext wird zunächst ein Rauschanteil entfernt, das Ergebnis wird als Quellfeld behandelt und über eine Gedächtnistopologie weitergegeben. Aus dieser Weitergabe entsteht pro Anfrage ein gerichtetes Flussnetz, aus demselben Übertragungsoperator ein kontinuierliches semantisches Feld, aus dem Kandidatenerinnerungen als geordnete Kurven gelesen werden. Ein als Omega bezeichnetes Funktional misst, ob das Netz überhaupt zustande kommt, und steuert, in welcher Reihenfolge strukturelle Belege sortiert werden. Diese Rechnung liegt in einem Rust-Kern und wird als einzelne asynchrone N-API-Aufgabe übergeben, parallelisiert mit Rayon auf Kandidatenebene, damit die Schleife über Kandidaten nicht zwischen JavaScript und Rust pendelt. Für die Praxis relevanter ist der Teil davor: Werkzeugaufrufe laufen nicht über natives Function Calling, sondern über ein Textmarker-Protokoll. Jedes Modell, das Text ausgeben kann, kann daran teilnehmen. Die README nennt sechs Plugin-Protokolle (synchron, asynchron, statisch, Dienst, Nachrichten-Vorverarbeitung, hybrid), alle verteilbar. Rückgaben von Werkzeugen werden als natürliche Sprache zurückgegeben, nicht als JSON zum Parsen. Das ist eine bewusste Entscheidung gegen strikte Schemata und für Fehlertoleranz, und sie kostet Struktur an der Stelle, an der strenge Typprüfung möglich wäre.

Vom Repository zum laufenden System

Die Releases des Projekts sind nach dem Installationsskript benannt: v1.4.0 trägt den Zusatz 一键安装脚本1.2, die vorherigen Einträge 1.1 und 1.0. Der vorgesehene Weg ist also ein Ein-Klick-Installer, nicht eine manuelle Abfolge von npm-Befehlen. Konkrete Kommandos, Umgebungsvariablen oder Konfigurationsdateien nennt die README nicht; sie verweist für Details auf die Whitepaper-Dateien docs/vcp白皮书V3.md, docs/RIVERMEMO_TOPOLOGY_V3.md und die technische Lite-Übersicht unter docs/TECHNICAL_. Wer den Aufbau nachvollziehen will, muss diese Dokumente lesen, bevor er den Installer startet. Ein Punkt ist aus der README belegbar und für die Konfiguration zentral: Nahezu alles wird über Platzhalter im System-Prompt gesteuert, über eine als Agent-TVS bezeichnete Template-Pipeline, die auch externe Dateien rekursiv auflösen kann. Ein Fähigkeitsschalter ist damit kein Codeänderung, sondern ein Platzhalter. Das erklärt, warum das Projekt von Frontends weitgehend unabhängig sein will, verlagert aber auch Konfigurationslogik in Prompt-Text, der schwerer zu testen ist als eine Konfigurationsdatei. Für den Betrieb kommen laut README eine Vue-Verwaltungsoberfläche, der Desktop-Client VCPChat und eine mobile Variante hinzu.

Die Gedächtnisschicht als eigener Rechenweg

Der inhaltlich interessanteste Teil ist RiverMemo. Die README begründet es mit einem Einwand gegen Vektorähnlichkeit: Ein Wort trage bei verschiedenen Personen unterschiedliche Erfahrung, und der nächste Nachbar im öffentlichen Vektorraum sei nicht automatisch der nächste Nachbar in der Kognition eines Menschen. Deshalb soll das System aus den gemeinsam angesammelten Erinnerungen eines Nutzers und eines Agenten eine eigene semantische Landkarte aufbauen, in der private Erfahrung, Emotion und Kausalität die Koordinaten mitverschieben. Das Bild, das die README wählt, ist eine Flusslandschaft: Jeder Tag ist ein Strom von links nach rechts, dasselbe Tag in verschiedenen Erinnerungen bildet Zuflüsse und Zusammenflüsse, Strömungen haben Energie und Richtung, und ein glockenförmiger Dämpfer verhindert, dass synonyme Echos das Gewässer trüben. Zwei Verfahren bekommen eigene Namen: ein Wurmloch-Algorithmus für plötzliche starke Verknüpfungen und ein Langfliegeknoten-Algorithmus für vom Agenten selbst gebaute Kanäle zwischen weit entfernten Bereichen. Eine Residuenpyramide liefere die globale Geländekarte, eine SVD-Analyse entscheide, wie stark eine bereichsübergreifende Assoziation gedämpft wird. Das ist ein ungewöhnlich elaboriertes Modell, und die README räumt selbst ein, dass die schweren Teile offline gerechnet werden können, während die Online-Suche möglichst als Tabellenzugriff nach Vorberechnung läuft. Genau dort liegt die offene Frage: Die README beschreibt das Ergebnis als intuitiv, liefert aber keine Angaben dazu, wie sich die Qualität der Assoziationen messen lässt.

Was der Rahmen nicht leistet und wann er das falsche Werkzeug ist

Zwei Dinge sind aus dem Material klar ableitbar. Erstens ist die Einstiegshürde hoch. Ein System, das zwischen Modell und Frontend sitzt, alle Nachrichten sieht und Werkzeuge über Textmarker ausführt, verlangt vom Betreiber ein Verständnis für Prompt-Platzhalter, Plugin-Protokolle und verteilte Knoten. Die README sagt das selbst: Nicht professionelle Nutzer sollten die Bereitstellung sorgfältig abwägen. Zweitens ist die Dokumentation in der Hauptdatei überwiegend Essay. Sie erklärt, warum das Projekt so gedacht ist, und verweist für alles Operative auf Nebendokumente. Wer eine Referenz mit Signaturliste, Fehlercodekatalog und Migrationshinweisen sucht, findet sie hier nicht auf der ersten Seite. Ein dritter Punkt betrifft die Textmarker-Protokolle: Sie machen Werkzeugaufrufe modellunabhängig und fehlertolerant, aber sie sind kein Ersatz für ein Schema. Ein Modell, das das Markerformat verletzt, erzeugt einen Fehler, der auf der Ebene der Texterkennung behandelt werden muss, nicht auf der Ebene einer Typvalidierung. Für Anwendungen, in denen ein falsch aufgerufenes Werkzeug Schaden anrichtet, ist das eine relevante Einschränkung. Und wer nur einen Chatbot mit ein paar Tools braucht, bezahlt hier für Gedächtnistopologie, Verteilungslogik und Frontend-Stack, ohne einen der Teile zu benötigen.

Der Unterschied zu einem klassischen RAG-Stack

Der naheliegende Vergleich ist ein üblicher RAG-Aufbau: Dokumente werden in Chunks zerlegt, eingebettet, in einer Vektordatenbank abgelegt, und zur Laufzeit holt eine Ähnlichkeitssuche die nächsten Nachbarn, die in den Prompt wandern. VCPToolBox enthält zwar ebenfalls eine Vektordatenbank als Baustein, geht aber an zwei Stellen anders vor. Erstens wird nicht allein nach Ähnlichkeit geordnet: Die README beschreibt eine Sortierschicht, in der Rauschentfernung, Weitergabe über die Topologie, Feldbildung und ein Strukturmaß zusammenwirken, und sie nennt ausdrücklich, dass die Reihenfolge der Belege von diesem Maß abhängt. Zweitens wird nicht nur auf Anfrage geholt. Umgebungsdaten wie Zeit, Wetter, Kalender und Gerätezustand sollen unabhängig von einer ausdrücklichen Abfrage in den Kontext gelangen. Ein RAG-Stack beantwortet die Frage, welche Textstellen zu einer Anfrage passen. VCPToolBox beantwortet zusätzlich die Frage, was der Agent in diesem Moment ohnehin wissen sollte. Der Preis dafür ist, dass die Auswahl nicht mehr allein aus der Anfrage ableitbar ist und damit schwerer zu reproduzieren wird. Wer nachvollziehbare, auf eine Anfrage zurückführbare Treffer braucht, hat mit einem schlichten Retriever einen kürzeren Weg zur Antwort.

Wartung, Aktualisierung und die Lizenzfrage

Die Release-Historie zeigt einen langsamen Takt: v1.4.0 im August 2026, davor ein Eintrag im April 2026, davor im März 2026, jeweils mit dem Installationsskript als eigentlichem Inhalt. Der letzte Push liegt laut Repository-Angaben bei September 2026, das Projekt ist nicht archiviert. Aktualisierungen laufen damit über das Ein-Klick-Skript, und die Versionsnummer des Skripts (1.2 in v1.4.0) ist von der des Systems zu unterscheiden. Weil die README die automatische Sicherung, Selbstreparatur der Datenbank und atomare differentielle Synchronisation als vorhandene Mechanismen nennt, ist der Upgrade-Pfad offenbar bedacht, doch ohne veröffentlichte Migrationshinweise bleibt unklar, was ein Sprung zwischen Hauptversionen an bestehenden Gedächtnisdaten ändert. Das ist die Stelle, an der Betreiber vor einem Upgrade ein eigenes Backup fahren sollten, statt sich auf die Beschreibung zu verlassen. Zur Lizenz: Das Repository trägt die Kennung NOASSERTION, und die README nennt keine Bedingungen, keine Einschränkungen und keine Pflichten. Damit ist rechtlich nicht feststellbar, unter welchen Voraussetzungen der Code eingesetzt oder weitergegeben werden darf. Das ist keine Kleinigkeit bei einer Schicht, die Zugangsdaten und Gesprächsinhalte verarbeitet, und es ist vor jeder kommerziellen Nutzung zu klären. Eine rechtliche Bewertung kann hier nicht erfolgen, der offene Punkt lässt sich aber benennen.

Redaktionelles Fazit

Wer wissen will, wie sich persistente Agenten-Kontexte jenseits von Chat-Verläufen bauen lassen, findet in VCPToolBox ein ungewöhnlich ausgearbeitetes Beispiel, und wer eine reine Function-Calling-Schicht sucht, ist hier falsch. Vor jedem Einsatz ist die Lizenz zu klären, denn das Repository trägt NOASSERTION und die README nennt keine Bedingungen. Danach bleibt als erster konkreter Schritt, den Inhalt von docs/vcp白皮书V3.md und docs/RIVERMEMO_TOPOLOGY_V3.md gegen den eigenen Betriebsfall zu prüfen, bevor der Installer aus dem Release v1.4.0 auf einer Maschine mit echten Zugangsdaten läuft.

Offizielle Quellen

1. Issues
2. lioensky/VCPToolBox on GitHub
3. Project website
4. README
5. Releases