Agentic AI für Netzwerke: das Werkzeug wählen

Das hier ist eine Notiz zu agentic AI für Netzwerke. Ich habe diese Woche einem Agenten bei der Arbeit zugesehen. Die eigentliche Änderung war klein. Was davor passierte, war lang: Dateien auf, Beschreibungen lesen, noch einmal nachsehen, ob das Werkzeug überhaupt da ist. Der Agent hat die Zeit mit Suchen verbracht.

Was ich lösen will

Die Aufgabe ist gewöhnliche Netzarbeit, ausgeführt von einem Agenten. Einen Dienst auf zwei Routern anlegen. Zurücklesen. Wieder entfernen. Prüfen, dass er weg ist.

Der Agent schreibt dabei über einen Controller. Im Labor ist das Cisco Network Services Orchestrator. Der Controller hat die Router schon im Bestand. Der Agent erreicht ihn über Werkzeuge im Model Context Protocol: Wer bin ich, ist der Dienst da, lege ihn an, lösche ihn, zeig das Ergebnis auf dem Gerät.

Dieselbe Form passt auf einen anderen Internet-Protokoll-Controller. Dem Agenten soll egal sein, welches Produkt darunter liegt, solange jedes Werkzeug eine klare Sache tut und das Ergebnis prüfbar ist.

Was ich in den Griff bekommen will, ist der Abstand zwischen diesem klaren Werkzeug und einem Agenten, der es erst suchen muss. Die Netzänderung ist klein. Der Katalog der Werkzeuge davor ist groß. Fängt jede Anfrage beim Katalog an, geht das Budget in die Suche.

Wenn die Werkzeugliste zur Rechnung wird

Eine Handvoll Werkzeuge liest du und wählst. Bei ein paar Dutzend kommt das Modell noch mit, mit dem einen oder anderen Fehlversuch. Wächst die Fläche im Model Context Protocol zu einem massiven Katalog, ist die Auswahl selbst die Arbeit.

Welches Werkzeug legt einen Dienst an. Welches liest ihn nur. Welches gehört zu einer Routing-Frage, welches zu einer Prüfung, ob der Dienst noch da ist, welches zu einer Störung, die mit der Änderung nichts zu tun hat. Anwendungsfälle teilen sich nicht ein Werkzeug. Anlegen, Entfernen und Prüfen sind verschiedene Aufrufe.

Schleppt jeder Schritt den ganzen Katalog mit, bezahlst du die Auswahl, bevor sich am Router etwas ändert. Ein falsches Werkzeug, ein zweiter Versuch, ein längerer Prompt. Die Kosten folgen dann der Größe der Liste, nicht der Größe der Änderung. Bei massivem Umfang ist die Werkzeugwahl der Kostenfaktor, und die Netzarbeit kommt danach.

Der Katalog ist nicht die Arbeit

Ein Werkzeugkatalog ist nützlich, wenn du etwas Neues baust. Er ist eine schlechte Startbedingung, wenn die Aufgabe einer ähnelt, die schon gelaufen ist. Der Agent liest dann Namen, rät Argumente, korrigiert sich, und nennt das Fortschritt. Der größte Teil der Zeit steckt in der Suche. Der kleine Rest ist die Handlung.

Eine Person, die denselben Fehler schon einmal behoben hat, fängt mit dem letzten Mal an, an dem es funktioniert hat, und prüft danach, ob die Welt noch dieselbe ist.

Was ich unter Innovation verstehe

Die nächste ähnliche Aufgabe sollte dort beginnen, wo die letzte aufgehört hat: bei einem Weg, der schon ein Ergebnis geliefert hat. Das Modell darf und soll prüfen, ob Gerät, Schnittstelle und Katalog noch passen. Es soll nicht dafür bezahlt werden, das Werkzeug neu zu entdecken.

Ein gespeicherter Weg ist keine Erlaubnis, ihn blind zu wiederholen. Dienstag kann stimmen und Freitag falsch sein, weil sich eine Schnittstelle geändert hat oder das Werkzeug gar nicht mehr angeboten wird. Die Prüfung bleibt. Die Suche muss nicht bleiben.

Was die Uhr danach gesagt hat

Dieselbe Änderung, zweimal. Einmal anlegen, einmal wieder entfernen.

Beim ersten Mal hat ein Agent beim Katalog angefangen.

• Anlegen: 7 Minuten 6 Sekunden, 58 Werkzeugaufrufe.
• Entfernen: 5 Minuten 22 Sekunden, 42 Werkzeugaufrufe.

Das Sprachmodell war bei jedem dieser Schritte dabei. Eine Token-Rechnung für diesen Lauf liegt mir nicht vor. Die erfinde ich nicht.

Beim zweiten Mal lag der Weg schon fest.

• Anlegen: 30 Sekunden, 7 Aufrufe.
• Entfernen: 26 Sekunden, 7 Aufrufe.

Dieser Lauf hat kein Sprachmodell aufgerufen. Die Modellkosten dafür waren null.

Auf der Uhr ist das etwa vierzehnmal und etwa zwölfmal. Eine Größenordnung. Mehrere Größenordnungen wären das Hundertfache oder das Tausendfache, und das habe ich nicht gemessen. Was ich gemessen habe, reicht: die Handlung war vorher schon kurz, und die Suche davor ist fast verschwunden. Dazu kommt eine Modellrechnung von null auf dem zweiten Weg.

Woran du es erkennst

Zähl bei einem langsamen Lauf, wie viele Aufrufe Suche sind und wie viele die Handlung. Wenn die Handlung kurz ist und die Suche lang, sitzt der Hebel bei der Erfahrung, nicht bei einem größeren Modell.

Dann lohnt es sich, die nächste Aufgabe nicht wieder bei null zu starten.