Tool Router: Warum er für meine lokalen Agenten unverzichtbar ist

Ein lokales Modell kann eine Aufgabe lösen und trotzdem schon vor dem ersten Arbeitsschritt unnötig viel Kontext verbrauchen. Bei mir war ein wesentlicher Grund der Werkzeugkatalog: ausführliche Beschreibungen und Parameterschemas für Aktionen, die in der jeweiligen Sitzung größtenteils gar nicht gebraucht wurden.

Beim Bau von NexClaw wurde dieses Problem sichtbar. Daraus entstand mein NEX Tool Router. Für meine Agenten mit vielen Integrationen ist er inzwischen ein wichtiger Teil des Aufbaus.

Das eigentliche Problem: alles wissen, bevor etwas passiert

Eine Werkzeugbeschreibung ist notwendig. Das Modell muss wissen, welche Aktion es aufrufen kann und welche Parameter sie braucht. Wenn aber der vollständige Katalog im Modellkontext landet, zahlt jede Anfrage auch für unbenutzte Möglichkeiten.

Dabei sind zwei Dinge zu unterscheiden: MCP kann Werkzeuge auflisten; wie viel davon tatsächlich an das Modell weitergereicht wird, entscheidet der Client beziehungsweise Harness. Ein großer Startkontext ist keine unvermeidliche Vorschrift des Protokolls.

Auch lokale Modelle haben nicht grundsätzlich kleine Kontextfenster. Mein Qwen-Dienst ist beispielsweise auf 262.144 Tokens eingestellt. Trotzdem kostet lange Eingabe Verarbeitung, und der Kontext konkurriert mit Aufgabe, Dokumenten und Verlauf. Ein großes Fenster macht irrelevante Schemas nicht nützlich.

Mein Prinzip: suchen, beschreiben, ausführen

Der Router stellt drei zentrale Aktionen bereit:

Der aktuelle Router-Modus enthält außerdem nex_memory für das Gedächtnis. Die oft zitierte Beschreibung „nur drei Tools“ beschreibt daher den Kern des Routing-Konzepts, nicht mehr die vollständige heutige Liste.

Ein Beispiel: Der Agent soll eine Mail archivieren. Er sucht zuerst nach dieser Aufgabe, bekommt passende Treffer mit Kurzbeschreibung und Parameternamen und lädt bei Bedarf das genaue Schema nach. Anschließend führt er die konkrete Aktion aus. Er muss dafür keine Beschreibungen zur Website-Pflege oder Bildgenerierung mitlesen.

Wie ich es programmiert habe

Der Router sitzt im vorhandenen MCP-Server. Die Werkzeugdefinitionen kommen aus dem Integrationskatalog. Daraus wird zunächst die Menge gebildet, die der jeweilige Zugriffsumfang erlaubt.

Die Suche nutzt mit vorhandener Agenten-ID bevorzugt die semantische Suche von NexClaw. Sie kombiniert Embeddings und BM25. Die gelieferten Namen werden anschließend mit dem lokal erlaubten Katalog abgeglichen. Ein Suchtreffer außerhalb dieses Katalogs wird dadurch nicht als ausführbares Werkzeug angeboten.

Wenn die semantische Suche nicht verfügbar ist, gibt es einen lokalen Stichwort-Fallback. Er berücksichtigt Werkzeugnamen, Beschreibungen, Integration und kuratierte Suchbegriffe. Eine kleine deutsch-englische Aliasliste hilft beispielsweise bei „mail“, „emails“ und „nachrichten“. Wortgrenzen verhindern, dass eine zufällige Teilzeichenfolge bereits als sinnvoller Treffer zählt.

Das ist aus konkreten Fehlern entstanden. Im Code ist etwa dokumentiert, dass die frühere Stichwortsuche das Werkzeug zum Verschieben einer Mail bei der Formulierung „archivieren“ nicht gut fand. Ein anderer Fall betraf „überfällige Aufgaben“: zu breite Aliase ließen allgemeine Schreibwerkzeuge vor dem passenden Lesewerkzeug erscheinen. Solche Fälle erklären die Suchlogik besser als das Versprechen einer magischen Tool-Erkennung.

Sichtbarkeit ersetzt keine Berechtigung

Die Suchantwort bleibt kompakt: Name, verkürzte Beschreibung, Pflichtparameter und ausgewählte optionale Parameter. Das volle Schema folgt erst über die Beschreibungsfunktion.

Vor der Ausführung muss das Werkzeug im erlaubten Katalog vorhanden sein. Danach geht der Aufruf an die bestehende Ausführungsschicht. Der Router eröffnet keinen zweiten, privilegierten Weg zu Integrationen. Umgekehrt ist ein passender Suchtreffer noch keine fachliche Freigabe für eine Aktion.

Ein Fallback verdient dabei besondere Aufmerksamkeit: Der aktuelle lokale Stichwortpfad übernimmt nicht jede Filterwirkung des semantischen Pfads identisch. Deshalb darf beispielsweise die gewünschte Nebenwirkung „nur lesen“ nicht ausschließlich durch die Suchreihenfolge abgesichert werden. Berechtigungen und Ausführungsregeln bleiben eigenständige Aufgaben.

Was die alten Messungen zeigen – und was nicht

In meinen Entwicklungsnotizen vom 8. September stehen zwei getrennte Vergleiche: rund 28.000 Tokens Werkzeugdefinitionen gegenüber rund 400 Tokens Router-Einstieg sowie 21.700 gegenüber 1.350 Tokens Startkontext einer betrachteten Sitzung.

Das sind historische Beobachtungen verschiedener Messgrößen. Sie dürfen weder zusammengerechnet noch als aktuelle Garantie für jeden Agenten verstanden werden. Der heutige Router hat sich weiterentwickelt. Für einen neuen Leistungsvergleich gehören derselbe Agent, derselbe Katalog, derselbe Tokenizer und vergleichbare Aufgaben zusammen.

Die hilfreiche Aussage bleibt: Ein wesentlicher Teil des Kontexts lässt sich erst dann laden, wenn er gebraucht wird.

Vorteile und Preis der zusätzlichen Schicht

Der Vorteil ist ein übersichtlicherer Einstieg. Der Katalog kann wachsen, ohne dass jede Sitzung sofort alle vollständigen Definitionen erhält. Beschreibungen bleiben zentral pflegbar, und unterschiedliche Harnesses können denselben Werkzeugzugang nutzen.

Dafür entstehen zusätzliche Schritte. Suche und gegebenenfalls Schemaabruf kosten Zeit. Eine schwache Suche kann das passende Werkzeug übersehen; eine zu allgemeine Anfrage kann viele wenig hilfreiche Treffer liefern. Ein Ausfall der Suchschicht benötigt einen erkennbaren Fallback. Und ein Modell muss lernen, gefundene Namen und echte Parameter zu verwenden, statt sie zu erraten.

Bei fünf kleinen, ständig benötigten Werkzeugen würde ich den direkten Katalog durchaus bevorzugen. In meinem wachsenden NEX-Aufbau überwiegt der Nutzen des Routers.

Was ich anderen daraus mitgeben würde

Zuerst den tatsächlich ans Modell gesendeten Kontext ansehen. Dann an echten Aufgaben prüfen, welche Werkzeuge gefunden, verstanden und erfolgreich ausgeführt werden. Nur Tokens zu sparen genügt nicht, wenn die Trefferqualität dabei sinkt.

Der übertragbare Gedanke ist einfach: Werkzeuge können verfügbar sein, ohne permanent vollständig im Kontext zu stehen. Diese Trennung ist für meine lokalen Agenten so wertvoll geworden, dass ich sie beim Ausbau des Systems nicht mehr missen möchte.