Skills als Werkzeugzugang: KI-Agentenkontext skalieren

Eine technische Fallstudie zu NanthAI:Edge.

Die meisten KI-Agenten skalieren auf die falsche Weise: Jede neue Fähigkeit bringt mehr Prompt-Text, mehr Werkzeugschemas und mehr Möglichkeiten für Fehlentscheidungen des Modells mit sich. Bei NanthAI:Edge ist das nicht nur Theorie. Der derzeit sichtbare Skill-Katalog umfasst als Metadaten etwa 5.100 Token, gegenüber etwa 67.000 Token für die vollständigen sichtbaren Skill-Inhalte. Das Basisregister stellt 4 Werkzeuge bereit, das vollständig erweiterte Register dagegen 115. Das beweist keinen besseren Aufgabenerfolg, wohl aber einen erheblich kleineren Kontextumfang.

Zusammenfassung

Agenten auf Basis großer Sprachmodelle (LLMs), die Werkzeuge nutzen, stehen in einem strukturellen Spannungsverhältnis zwischen einem breiten Fähigkeitsspektrum und sparsamem Kontext. Jede zusätzliche Arbeitsablaufanweisung und jedes zusätzliche Werkzeugschema im Modellkontext verbraucht Token, erhöht Latenz und Kosten und kann die Werkzeugauswahl unzuverlässiger machen. Dieser Artikel entwickelt das Entwurfsmuster des schrittweisen, durch Skills gesteuerten Werkzeugzugangs. Ein kompakter, cache-stabiler Skill-Katalog vermittelt dabei sowohl das Laden von Anweisungen bei Bedarf als auch die schrittweise Erweiterung des ausführbaren Werkzeugregisters.

Ein Skill wird als modulares, auffindbares Anweisungspaket mit Metadaten, vollständigen Verhaltensanleitungen und deklarierten Anforderungen an Werkzeugprofile behandelt. Statt alle Skills und Werkzeuge in jede Anfrage einzufügen, stellt das System zunächst schlanke Skill-Metadaten bereit. Passt eine Aufgabe zu einem Skill, ruft das Modell load_skill auf. Geladene Skills fügen dann detaillierte Anweisungen ein und aktivieren die passenden Werkzeugprofile.

Der Artikel ordnet dieses Muster in die Literatur zu überladenen Prompts, zur Skalierbarkeit von Funktionsaufrufen, abrufbasierter Werkzeugauswahl, Prompt-Caching, schrittweiser Offenlegung und modularer Agentenarchitektur ein. Anschließend analysiert er NanthAI:Edge als konkrete Fallstudie anhand von Implementierungsdetails, die der Systemautor bereitgestellt hat. NanthAI:Edge organisiert Fähigkeiten in drei Ebenen: Kontotarif, Skills und ausführbare Werkzeuge. Der Artikel erläutert erwartete Vorteile, zentrale Risiken und die Abwägungen bei der Umsetzung dieser Architektur.

Zusammengefasster Ablauf des durch Skills gesteuerten Werkzeugregisters

1. Einleitung

Moderne agentische LLM-Systeme setzen für jede Anfrage typischerweise drei Kontextarten zusammen: Systemanweisungen, Werkzeugschemas und Unterhaltungszustand. Mit zunehmenden Fähigkeiten wächst meist jede Ebene. Neue Arbeitsabläufe bringen neue Prompt-Anweisungen. Neue Integrationen bringen neue Werkzeugschemas. Neue Nutzerpräferenzen und Erinnerungen bringen weiteren Kontext. Das System wird leistungsfähiger, aber auch zunehmend schwerfällig.

Daraus ergeben sich zwei verwandte Probleme:

1. Prompt-Überladung entsteht, wenn sich im System-Prompt umfangreiche Verhaltensanweisungen, Richtlinien, Arbeitsablaufanleitungen, Beispiele, Erinnerungen und Kontextregeln ansammeln.
2. Überladung des Werkzeugregisters entsteht, wenn dem Modell viele ausführbare Werkzeuge bereitgestellt werden, unabhängig davon, ob sie für die aktuelle Aufgabe relevant sind.

Beides ist teuer. Es verbraucht Eingabetoken, erhöht Latenz und Anbieterkosten und erschwert das Prompt-Caching. Noch wichtiger ist, dass die Entscheidungsqualität leiden kann. Ein Modell, das unter Dutzenden oder Hunderten Werkzeugen wählen soll, muss mehr Kandidaten vergleichen, mehr Beschreibungen berücksichtigen und mehr semantische Überschneidungen auflösen.

Neuere Arbeiten zur abrufgestützten Werkzeugauswahl stützen diese Sorge. Die RAG-MCP-Studie von Gan und Sun berichtet, dass das Abrufen relevanter Werkzeugschemas statt der Übergabe aller Schemas die Auswahlgenauigkeit in einer MCPBench-WebSearch-Konfiguration von 13,62 % auf 43,13 % verbesserte und die Prompt-Token ungefähr halbierte. Diese Zahlen gelten für den jeweiligen Benchmark und sollten nicht unbesehen verallgemeinert werden. Sie verdeutlichen aber den zentralen Druck: Alle Werkzeuge gleichrangig bereitzustellen ist oft eine schlechte Informationsarchitektur.

Dieser Artikel untersucht eine strukturierte Alternative: schrittweisen, durch Skills gesteuerten Werkzeugzugang.

Das Muster ist einfach:

1. Einen kompakten Katalog verfügbarer Skills bereitstellen.
2. Das Modell über load_skill einen passenden Skill laden lassen.
3. Vollständige Skill-Anweisungen erst nach der Aktivierung einfügen.
4. Das aktive Werkzeugregister nur durch Profile erweitern, die geladene Skills benötigen.

Der Entwurf überträgt die schrittweise Offenlegung aus der UX und das Verbergen von Implementierungsdetails aus der Softwarearchitektur auf die Ökonomie von LLM-Kontextfenstern. Die Details werden nicht vor einem menschlichen Nutzer verborgen, sondern vor dem Modell, bis die Aufgabe ihre Bereitstellung rechtfertigt.

Wir analysieren dieses Muster anhand von NanthAI:Edge, einer kommerziellen Agenten-Runtime, deren Architektur abgestufte Kontofähigkeiten, Skill-Erkundung, Skill-Laden und profilgesteuerte Werkzeugerweiterung umsetzt. NanthAI-spezifische Angaben in diesem Artikel sind vom Systemautor bereitgestellte Implementierungsdetails der Fallstudie.

Der Artikel liefert:

1. Einen konzeptionellen Rahmen für Skills als schrittweisen Zugang zu Anweisungen und Werkzeugen.
2. Eine Fallstudienanalyse der dreistufigen Architektur von NanthAI:Edge.
3. Eine Erörterung von Cache-Stabilität, Routing-Absicht und profilbasierter Registererweiterung.
4. Einen Risikokatalog mit Schwerpunkt auf falscher Skill-Auswahl und unterbliebenem Skill-Laden.

2. Hintergrund: Überladene Prompts, Werkzeugschemas und agentische Werkzeugnutzung

2.1 Funktionsaufrufe und Werkzeugbereitstellung

APIs für Funktionsaufrufe verlangen, dass Werkzeuge dem Modell durch Namen, natürlichsprachliche Beschreibungen und strukturierte Parameterschemas beschrieben werden. Das Modell entscheidet, ob und welches Werkzeug es aufruft und welche Argumente es übergibt. Benchmarks wie das Berkeley Function Calling Leaderboard bewerten diese Fähigkeit in Szenarien mit einer oder mehreren Runden, parallelen Aufrufen und relevanzabhängiger Auswahl.

Werkzeugnutzung ist keine einzelne Fähigkeit. Sie gliedert sich in mehrere:

• Werkzeugauswahl: die richtige Funktion wählen.
• Argumenterstellung: gültige und semantisch korrekte Parameter erzeugen.
• Aufrufreihenfolge: Werkzeuge in der richtigen Reihenfolge aufrufen.
• Ergebnisinterpretation: Werkzeugausgaben korrekt verwenden.
• Aufgabenerfüllung: die tatsächliche Absicht des Nutzers erfüllen.

Ein System kann das richtige Werkzeug wählen und dennoch bei den Argumenten scheitern. Es kann ein plausibles Werkzeug aufrufen und trotzdem die Aufgabe verfehlen. Es kann einmal erfolgreich sein und sich über mehrere Runden verschlechtern. Deshalb reicht die Bewertung der Endantwort allein zur Evaluation agentischer Systeme nicht aus.

2.2 Prompt-Überladung

Überladene Prompts werden oft als Kostenproblem betrachtet. Das tieferliegende Problem ist jedoch der Fokus. Lange Prompts können relevante und irrelevante Informationen, veraltete Anweisungen, doppelte Richtlinien und viele Werkzeugdefinitionen enthalten. Größere Kontextfenster bieten dafür Platz. Dass Informationen hineinpassen, bedeutet aber nicht, dass sie zuverlässig genutzt werden.

Forschung zu langen Kontexten wie „Lost in the Middle“ zeigt, dass Modelle Informationen je nach ihrer Position im Kontext weniger zuverlässig nutzen können. Weitere Studien zu langen Kontexten und Werkzeugaufrufen legen nahe, dass Kontextlänge, Werkzeugzahl und die Ansammlung über mehrere Runden störanfällig zusammenwirken können. Genaue Schwellenwerte variieren je nach Modell und Aufgabe. Deshalb vermeidet dieser Artikel Aussagen wie „Modelle scheitern ab N Werkzeugen“. Die belastbare Aussage ist enger: Unnötige Anweisungen und irrelevante Schemas vergrößern den Entscheidungsraum des Modells und können die Bedingungen für das Routing verschlechtern.

2.3 Überladung des Werkzeugregisters

Ein überladenes Werkzeugregister ist die werkzeugspezifische Form eines überladenen Prompts. Ein großes, flaches Register lässt bei jeder Aufgabe alle verfügbaren Werkzeuge um Aufmerksamkeit konkurrieren. Besonders problematisch ist das bei semantischen Überschneidungen: mehrere Such-, Dokument-, Kalender- oder Arbeitsbereichswerkzeuge oder mehrere integrationsspezifische Varianten.

Arbeiten zur abrufbasierten Werkzeugauswahl setzen direkt an diesem Problem an. RAG-MCP ruft vor dem Prompting relevante Schemas ab, statt alle Werkzeuge bereitzustellen. Tool Attention und Ansätze zum dynamischen Laden von Schemas plädieren ebenfalls für eine kleinere aktive Kandidatenmenge. Diese Ansätze beweisen nicht, dass Skill-Steuerung funktioniert. Sie stützen aber den allgemeineren Gedanken, dass das Modell nicht immer jede ausführbare Fähigkeit sehen sollte.

2.4 Qualität der Werkzeugbeschreibungen

Weniger Werkzeuge bereitzustellen reicht nicht aus. Die weiterhin sichtbaren Werkzeuge und Skills müssen klar beschrieben sein. ToolACE berichtet über Verbesserungen durch geprüfte, hochwertige Daten für Funktionsaufrufe und zeigt damit, dass Schema- und Beschreibungsqualität die Genauigkeit der Werkzeugnutzung beeinflussen. Studien zu API-Dokumentation legen ebenfalls nahe, dass unklare Parameterbeschreibungen und komplexe Schnittstellen mehr Fehler verursachen.

Daraus ergibt sich das zentrale Spannungsverhältnis im Entwurf:

• Detaillierte Anweisungen und Schemas verbessern die Ausführung.
• Alle detaillierten Anweisungen und Schemas global bereitzustellen führt zur Überladung.

Die schrittweise Skill-Steuerung begegnet diesem Spannungsverhältnis, indem sie Erkundungsmetadaten von Ausführungsdetails trennt.

2.5 Prompt-Caching

Prompt-Caching kann Latenz und Kosten senken, wenn stabile Präfixe wiederverwendet werden. Caching profitiert jedoch von einer stabilen Prompt-Struktur. Werden Werkzeuglisten oder Systemanweisungen unvorhersehbar umgeschrieben, kann die Cache-Wiederverwendung leiden.

Daraus ergibt sich ein zweites Spannungsverhältnis:

• Dynamisches Laden reduziert irrelevanten Kontext.
• Dynamisches Einfügen kann die Cache-Stabilität beeinträchtigen.

Eine tragfähige Architektur zur Skill-Steuerung muss deshalb regeln, wo und wie geladene Anweisungen erscheinen. NanthAI:Edge behält, wie später beschrieben, einen stabilen Basis-Prompt und Katalog bei und hängt anschließend normalisierte Blöcke geladener Skills an vorhersehbaren Positionen an.

3. Skills als modulare Anweisungspakete

Ein Skill ist ein benanntes, auffindbares Fähigkeitspaket. Er ist weder bloß ein Werkzeug noch bloß ein Prompt-Schnipsel. Er liegt zwischen Nutzerabsicht und ausführbaren Funktionen.

Ein Skill enthält typischerweise:

• slug
• name
• summary
• runtimeMode
• vollständige Arbeitsablaufanweisungen
• erforderliche Werkzeug-IDs
• erforderliche Werkzeugprofile
• erforderliche Integrationen
• erforderliche Kontofähigkeiten
• Richtlinienvorgaben
• Versionsmetadaten

Ein Werkzeug ist eine ausführbare Operation. Ein Skill ist eine Fähigkeit auf Arbeitsablaufebene, die kein, ein oder viele Werkzeuge verwenden kann.

Ein Dokumenterzeugungswerkzeug kann beispielsweise eine .docx-Datei erstellen. Ein Skill zum „Schreiben wissenschaftlicher Arbeiten“ kann Regeln für den Quellenumgang, Zitierdisziplin, Struktur, Syntheseanforderungen und Erwartungen an die Dokumenterzeugung definieren und Dokument-, Such- und Analysewerkzeuge aktivieren.

Die schrittweise Skill-Steuerung arbeitet über drei Offenlegungsebenen:

Diese Struktur macht Skills zu Grundbausteinen der Kontextverwaltung. Sie sind zugleich:

• Einheiten von Fähigkeiten;
• Einheiten des Anweisungsumfangs;
• Einheiten der Werkzeugregistererweiterung;
• Einheiten der Steuerung und Beobachtbarkeit.

4. Fallstudie NanthAI:Edge

Dieser Abschnitt fasst vom Systemautor bereitgestellte Implementierungsdetails der Fallstudie zusammen. Er sollte als Architekturdokumentation gelesen werden, nicht als unabhängig geprüfter Beleg.

4.1 Dreistufiges Fähigkeitsmodell

NanthAI:Edge organisiert Fähigkeiten in drei Ebenen:

1. Kontofähigkeiten und Tarif
2. Skills
3. Ausführbare Werkzeuge

Die Kontoebene bestimmt, worauf der Nutzer zugreifen darf. Nutzer des kostenlosen Tarifs erhalten einfachen Chat ohne vom Modell aufrufbares Werkzeugregister. Pro-Nutzer erhalten bei werkzeugfähigen Modellen ein kleines Basisregister.

Die Skill-Ebene enthält modulare Anweisungspakete mit Metadaten und Aktivierungsregeln.

Die Ebene ausführbarer Werkzeuge enthält die eigentlichen Werkzeugschemas und Implementierungen. Umfangreiche Werkzeugfamilien werden jedoch nicht standardmäßig bereitgestellt. Sie werden durch in Skills deklarierte Profile freigeschaltet.

4.2 Basisregister

Das Basisregister enthält schlanke Allzweckwerkzeuge wie:

• load_skill
• list_skills
• search_chats
• fetch_image

Das entscheidende Werkzeug ist load_skill. Es macht Routing zu einer eigenständigen Modellaktion. Das Modell braucht nicht alle Anweisungen im Voraus, sondern genug Metadaten, um zu entscheiden, wann weiterführende Anweisungen nötig sind.

4.3 Skill-Metadaten

NanthAI-Skills enthalten strukturierte Metadaten:

• slug
• name
• summary
• runtimeMode
• requiredToolIds
• requiredToolProfiles
• requiredIntegrationIds
• requiredCapabilities

Diese Metadaten unterstützen sowohl die Erkundung durch das Modell als auch die Durchsetzung von Laufzeitrichtlinien. Ein Skill, der Slack benötigt, kann beispielsweise ausgeblendet werden, wenn der Nutzer Slack nicht verbunden hat. Ein Skill, der eine Pro-Fähigkeit benötigt, kann für Nutzer des kostenlosen Tarifs entfallen.

4.4 Katalog verfügbarer Skills

Als verfügbar ermittelte Skills werden als <available_skills>-XML-Block im System-Prompt dargestellt. Dieser Katalog enthält kompakte Metadaten, keine vollständigen Anweisungen.

Ein vereinfachtes Beispiel:

<available_skills>
<skill slug="analytics_report">
<name>Analysebericht</name>
<summary>Verwenden, wenn der Nutzer Datenanalyse, Diagramme oder strukturierte Analyseergebnisse benötigt.</summary>
</skill>
<skill slug="document_drafting">
<name>Dokumententwurf</name>
<summary>Verwenden, wenn der Nutzer ein strukturiertes Dokument, einen Vorschlag, ein Memo oder eine erzeugte Datei benötigt.</summary>
</skill>
</available_skills>

Der Katalog ist eine Routing-Schnittstelle. Er zeigt dem Modell die vorhandenen Fähigkeiten, ohne es zur vollständigen Verarbeitung jedes Arbeitsablaufs zu zwingen.

4.5 Skill-Zustände

NanthAI bestimmt Skills über vier Geltungsbereiche:

• Kontoeinstellungen;
• Persona;
• Chat;
• Überschreibungen auf Rundenebene.

Jedem Skill kann einer von drei Zuständen zugewiesen werden:

• always: vollständige Anweisungen werden in jede Runde eingefügt;
• available: im Katalog aufgeführt und bei Bedarf ladbar;
• never: vollständig ausgeschlossen.

Das ermöglicht feingranulare Richtlinien. Allgemeingültige Regeln können immer aktiv sein. Spezialisierte Arbeitsabläufe können verfügbar sein. Unzulässige oder irrelevante Fähigkeiten können verborgen werden.

4.6 load_skill

Wenn das Modell erkennt, dass eine Aufgabe zu einem Skill passt, ruft es load_skill mit dem Skill-Slug auf. Die Runtime gibt vollständige Anweisungen und Routing-Metadaten zurück.

Statt sich auf rohe Werkzeugergebnis-Transkripte zu verlassen, normalisiert NanthAI geladene Anweisungen in einer eigenen Systemnachricht für geladene Skills. Das macht den aktiven Anweisungszustand ausdrücklich sichtbar und vermeidet die Ansammlung eines unübersichtlichen Werkzeugaufrufverlaufs.

4.7 Schrittweise Werkzeugprofile

Skills deklarieren requiredToolProfiles. Das Laden eines Skills kann ein oder mehrere Werkzeugprofile aktivieren. Zu den vom Autor angegebenen Profilen gehören:

• docs
• analytics
• workspace
• persistentRuntime
• subagents
• google
• microsoft
• notion
• appleCalendar
• cloze CRM
• slack
• scheduledJobs
• skillsManagement
• personas

Beispiele:

• docs schaltet Werkzeuge zur Erzeugung und Bearbeitung von Dokumenten und Dateien frei.
• analytics schaltet Python- und Datenwerkzeuge frei.
• workspace schaltet Datei- und Ausführungswerkzeuge für den Arbeitsbereich frei.
• Integrationsprofile schalten app-spezifische Werkzeuge nur bei bestehender Verbindung frei.
• subagents schaltet das Starten von Subagenten nur frei, wenn es erlaubt ist.

Das Register erweitert sich somit entsprechend den aktivierten Skills und nicht entsprechend dem gesamten Fähigkeitsspektrum der Plattform.

4.8 Laufzeitleitplanke

NanthAI enthält eine Laufzeitleitplanke, die das Modell anweist, keine nicht verfügbaren Werkzeuge zu erfinden: kein lokaler Dateisystemzugriff, keine Shell, keine Browserautomatisierung, keine nicht konfigurierten MCP-Server und keine direkten Netzwerkabrufe außerhalb ausdrücklich bereitgestellter NanthAI-Werkzeuge.

Diese Leitplanke auf Prompt-Ebene ist für sich genommen keine Sicherheitsgrenze. Die tatsächliche Sicherheitsgrenze muss durch Laufzeitautorisierung und Werkzeug-Freigabelisten durchgesetzt werden. Die Leitplanke stärkt aber das Verständnis des Modells für den aktiven Fähigkeitsumfang.

5. Architekturanalyse

5.1 Token-Kostenmodell

Bei einem monolithischen Entwurf entsprechen die Prompt-Kosten pro Runde ungefähr:

base_prompt + all_skill_instructions + all_tool_schemas + conversation_state

Bei schrittweiser Skill-Steuerung entsprechen die Kosten ungefähr:

base_prompt + skill_catalog_metadata + loaded_skill_instructions + active_profile_tool_schemas + conversation_state

Entscheidend ist, was mit dem gesamten Fähigkeitsspektrum der Plattform skaliert. Beim monolithischen Entwurf steigen die hohen Anweisungs- und Schemakosten mit allen verfügbaren Fähigkeiten. Beim schrittweisen Entwurf steigen die hohen Kosten mit den aktivierten Fähigkeiten. Der Katalog wächst weiterhin, aber nur als kompakte Metadaten.

Das ist der wirtschaftliche Kern der Architektur.

5.2 Der Katalog als cache-stabile Routing-Schnittstelle

Der available_skills-Block soll über Runden hinweg stabil bleiben, solange sich Nutzerfähigkeiten, Persona, Chat-Einstellungen oder Rundenüberschreibungen nicht ändern. Stabilität ist wichtig, weil Prompt-Caching von wiederverwendbaren Präfixen abhängt. Ein kompakter, stabiler Katalog kann cache-freundlich bleiben, während vollständige Skill-Inhalte erst später geladen werden.

5.3 Block geladener Skills

Das Normalisieren geladener Skill-Anweisungen in einer eigenen Systemnachricht hat zwei Vorteile:

1. Erstens hält es den Anweisungszustand übersichtlich. Das Modell sieht die Anleitung geladener Skills als aktiven Systemkontext statt als historisches Werkzeugergebnis.
2. Zweitens hilft es, die Prompt-Cache-Struktur zu erhalten. Werden geladene Skills hinter dem stabilen Basis-Prompt und Kataloginhalt angehängt, erweitern neue Aktivierungen den Kontext, ohne das stabile Präfix umzuschreiben.

Das ist eine der wichtigsten architektonischen Erkenntnisse im NanthAI-Entwurf: Dynamische Fähigkeitserweiterung und Prompt-Caching sind nicht von sich aus vereinbar. Die Nachrichtenstruktur muss sie deshalb ausdrücklich miteinander in Einklang bringen.

5.4 Profilbasierte Registererweiterung

Werkzeugprofile schaffen eine Zwischenschicht zwischen Skills und Werkzeugen. Das ist besser, als jedem Skill direkt eine lange Liste einzelner Werkzeugschemas zuzuordnen.

Diese Zwischenschicht hat mehrere Vorteile:

• Mehrere Skills können ein Profil teilen;
• Profile lassen sich als Fähigkeitspakete testen;
• Die Verfügbarkeit von Integrationen kann einmal pro Profil geprüft werden;
• Zusammengehörige Werkzeuge können gemeinsam bereitgestellt werden;
• Richtlinien können auf Profilebene angewendet werden;
• Das aktive Register bleibt erklärbar.

Viele Skills können beispielsweise Dokumenterzeugung benötigen. Statt Dokumentwerkzeuglisten in mehreren Skills zu duplizieren, können sie das Profil docs aktivieren.

5.5 Routing-Absicht

In einem flachen Register ist die Absicht implizit. Ruft das Modell ein Werkzeug auf, müssen Entwickler den Grund erschließen. In einem durch Skills gesteuerten System wird die Routing-Absicht ausdrücklich sichtbar:

Nutzeraufgabe → geladener Skill → aktiviertes Profil → ausgewähltes Werkzeug

Das verbessert die Beobachtbarkeit. Fehler lassen sich nach Ebenen aufschlüsseln:

• War der richtige Skill sichtbar?
• Wurde er geladen?
• Hat er das richtige Profil aktiviert?
• Wurde das richtige Werkzeug ausgewählt?
• Waren die Argumente korrekt?
• Hat die Endantwort die Aufgabe erfüllt?

Gegenüber monolithischem Prompting ist das ein erheblicher Vorteil bei der Evaluation.

6. Zentrales Gegenargument: Metadaten-Routing kann scheitern

Der stärkste Einwand gegen die schrittweise Skill-Steuerung lautet, dass das Verbergen vollständiger Anweisungen das Routing beeinträchtigen kann.

Ein Modell kann ähnliche Skills möglicherweise nicht allein anhand ihrer Metadaten unterscheiden. Sind die Katalogzusammenfassungen zu kurz, vage oder überlappend, kann das Modell:

• den falschen Skill laden;
• gar keinen Skill laden;
• zu viele Skills laden;
• das falsche Werkzeugprofil aktivieren;
• eine plausible, aber unzureichend spezifizierte Antwort erzeugen.

Das ist kein nebensächlicher Sonderfall, sondern die zentrale Abwägung. Die schrittweise Steuerung tauscht ein Problem, die globale Überladung, gegen ein anderes ein: Vollständigkeit und Präzision des Routings.

Die Architektur ist am stärksten, wenn:

• der Skill-Katalog eine überschaubare Größe hat;
• Skill-Zusammenfassungen klar unterscheidbar sind;
• Skills sich nicht stark überschneiden;
• Rückfragen als Ausweichmöglichkeit erlaubt sind;
• Routing-Entscheidungen protokolliert und ausgewertet werden;
• semantischer Abruf den Katalogabgleich unterstützen kann.

Sie ist am schwächsten, wenn:

• Tausende ähnlicher Skills vorhanden sind;
• Zusammenfassungen allgemein gehalten sind;
• Aufgaben feine Unterscheidungen erfordern;
• das Modell davon abgehalten wird, klärende Fragen zu stellen;
• ein übersehener Skill unbemerkt zu einer schlechten, aber plausiblen Ausgabe führt.

Eine robuste Implementierung sollte daher Modellurteile mit deterministischen Prüfungen, Abruf, Versionierung und Evaluation verbinden.

7. Risiken und Fehlermodi

R1: Falsche Skill-Auswahl

Das Modell lädt einen beinahe passenden Skill. Dadurch können falsche Anweisungen eingefügt und irrelevante Werkzeuge aktiviert werden.

Gegenmaßnahmen: klar unterscheidbare Zusammenfassungen, Beispiele, Hinweise zur Nichtverwendung, Offline-Routing-Tests, Konfidenzschwellen.

R2: Unterbliebenes Skill-Laden

Das Modell arbeitet weiter, ohne einen Skill zu laden. Das ist gefährlich, weil die Ausgabe akzeptabel aussehen kann, obwohl sie Anforderungen des Arbeitsablaufs verletzt.

Gegenmaßnahmen: deutlichere Ladeanweisungen, Erkennung übersehener Skills, nachträgliche Klassifikatoren, Rückfrageverhalten.

R3: Veraltete Anweisungen

Geladene Skill-Anweisungen können nach einer Skill-Aktualisierung bestehen bleiben.

Gegenmaßnahmen: Skill-Versions-IDs, Cache-Invalidierung, Regeln zum erneuten Laden, Kompatibilitätstests.

R4: Verborgene Kopplung

Skills und Profile können auseinanderlaufen. Ein Skill kann Werkzeuge voraussetzen, die in seinem Profil tatsächlich nicht verfügbar sind.

Gegenmaßnahmen: requiredToolProfiles, requiredToolIds, Profiltests, Abhängigkeits-Linting.

R5: Zusätzliche Latenz

load_skill fügt vor Arbeitsbeginn eine Werkzeugaufrufrunde hinzu.

Gegenmaßnahmen: häufige Arbeitsabläufe als always beibehalten, vorausschauend vorladen oder ein hybrides Basisregister verwenden.

R6: Cache-Invalidierung

Zu früh eingefügte dynamische Inhalte können die Cache-Wiederverwendung beeinträchtigen.

Gegenmaßnahmen: konsequent stabiles Präfix, nur durch Anhängen erweiterter Block geladener Skills, Cache-Tests.

R7: Prompt-Injection

Von Nutzern verfasste Skills können unsichere Anweisungen enthalten.

Gegenmaßnahmen: Skill-Prüfung, Richtlinien-Linting, Sandboxing, Berechtigungsbereiche, Durchsetzung zur Laufzeit.

R8: Übermäßiges Vertrauen in Modellurteile

Bei Mehrdeutigkeit kann das Modell schlecht routen.

Gegenmaßnahmen: abrufgestütztes Routing, deterministische Richtlinienprüfungen, Rückfragen an Nutzer, Telemetrie.

8. Diskussion

Die schrittweise Skill-Steuerung versteht Werkzeugregistrierung als Fähigkeitsarchitektur. Statt einer flachen Werkzeugliste erhält die Agenten-Runtime mehrere Ebenen:

Kontorichtlinie → Skill-Katalog → Skill-Laden → Profilaktivierung → Werkzeugausführung

Daraus ergeben sich mehrere Folgen:

1. Skills werden zur primären Steuerungseinheit. Tarifzugang, Integrationszustand, Werkzeugprofile und Laufzeitmodi lassen sich durch Skill-Metadaten ausdrücken.
2. Routing wird untersuchbar. load_skill-Ereignisse lassen sich protokollieren, messen und auswerten.
3. Marktplätze werden leichter handhabbar. Von Nutzern verfasste Skills können ihre Anforderungen deklarieren und mit begrenztem Fähigkeitsumfang zugelassen werden.
4. Hybride Entwürfe sind wahrscheinlich am besten. Kleine allgemeine Werkzeuge sollten im Basisregister bleiben. Spezialisierte, risikoreiche, teure oder selten genutzte Werkzeuge sollten gezielt freigeschaltet werden. always-Skills sollten selten sein. available sollte für spezialisierte Arbeitsabläufe der Standard sein. never sollte unzulässige Fähigkeiten unterdrücken.
5. Die Qualität des Skill-Katalogs wird zu einem Teil des Produkts. Katalogzusammenfassungen sind keine internen Etiketten, sondern Routing-Schnittstellen für das Modell. Sie erfordern dieselbe Sorgfalt wie API-Dokumentation.

Diese Richtung verfolgen wir in NanthAI:Edge: Fähigkeiten sollen auffindbar sein, ohne dauerhaft eingefügt zu werden. Leistungsfähige Werkzeuge sollen nur erscheinen, wenn der aktive Arbeitsablauf sie rechtfertigt.

9. Statische Architekturmessungen

Die vollständige Verhaltensvalidierung erfordert zwar eine Benchmark-Suite, einige Aussagen lassen sich aber direkt anhand der aktuellen NanthAI:Edge-Implementierung prüfen. Insbesondere erlaubt die Codebasis, den vom Skill-Katalog und dem schrittweise erweiterten Werkzeugregister bereitgestellten Kontextumfang zu messen.

Diese Messungen quantifizieren die Seite des Arguments, die den sparsamen Umgang mit Kontext betrifft: Wie viel Prompt- und Werkzeugschemamaterial wird vermieden, wenn kompakte Skill-Metadaten und ein kleines Basisregister bereitgestellt werden, statt sämtliche Skill-Inhalte und Werkzeugschemas von Anfang an einzufügen?

9.1 Verdichtung des Skill-Katalogs

Der aktuelle Systemkatalog von NanthAI:Edge enthält 55 sichtbare und 11 verborgene oder nicht sichtbare Skills. Sichtbare Skills werden im available_skills-Katalog für das Modell als schlanke Metadaten dargestellt: Skill-Name, Zusammenfassung und Hinweise auf Anforderungen. Ihre vollständigen Anweisungsinhalte bleiben zurückgehalten, bis ein Skill ausdrücklich geladen wird.

Gemessen am aktuellen sichtbaren Katalog:

Das bedeutet, dass der standardmäßig zur Skill-Erkundung bereitgestellte Umfang ungefähr ein Dreizehntel des vollständigen sichtbaren Skill-Anweisungssatzes beträgt. Das Modell sieht weiterhin, dass die Fähigkeiten existieren, verursacht aber erst dann die vollen Anweisungskosten, wenn eine Aufgabe sie tatsächlich benötigt.

Das stützt die erste Aussage der Architektur zum sparsamen Umgang mit Kontext: Die Skill-Erkundung kann breit bleiben, während Anweisungen gezielt aktiviert werden.

9.2 Verdichtung des Werkzeugregisters

Beim Werkzeugregister ist der Effekt noch deutlicher. Im aktuellen schrittweise erweiterten Register stellt der Basiswerkzeugsatz nur vier Allzweckwerkzeuge bereit:

• load_skill
• list_skills
• search_chats
• fetch_image

Sind alle Werkzeugprofile erweitert, enthält das Register 115 Werkzeuge. Der Unterschied bei den Schema-Token ist erheblich:

Das stützt die zweite Aussage zum sparsamen Umgang mit Kontext: Der standardmäßige ausführbare Aktionsraum des Modells ist wesentlich kleiner als der gesamte Fähigkeitsumfang der Plattform.

Bei einem monolithischen Entwurf würde das Modell in jeder werkzeugfähigen Runde das vollständige Register sehen. Bei schrittweiser Registererweiterung sieht es nur die Basiswerkzeuge, bis ein geladener Skill ein oder mehrere Profile aktiviert.

9.3 Kostenbeispiele aktiver Profile

Unterschiedliche Arbeitsabläufe aktivieren unterschiedliche Werkzeugprofile. Die Einsparungen hängen deshalb von der Aufgabe ab. Ein eng umrissener Analyseablauf stellt wesentlich weniger Werkzeuge bereit als ein Dokumenterzeugungsablauf. Beide stellen deutlich weniger bereit als ein vollständig erweitertes Register.

Diese Beispiele verdeutlichen, warum die profilbasierte Zwischenschicht wichtig ist. Eine Datenanalyse benötigt keine Werkzeuge für Kalender, Slack, Dokumentbearbeitung, geplante Aufgaben oder Persona-Verwaltung. Eine Slack-Aufgabe braucht keine Python-Ausführung oder Dokumenterzeugungswerkzeuge. Eine Dokumentaufgabe benötigt möglicherweise das relativ umfangreiche Profil docs, vermeidet aber weiterhin die meisten Integrations- und Laufzeitwerkzeuge, sofern sie nicht ausdrücklich erforderlich sind.

Das System verlagert die Werkzeugschemakosten somit von „alles, was dem Nutzer zur Verfügung steht“ zu „alles, was der derzeit aktivierte Arbeitsablauf rechtfertigt“.

9.4 Einordnung

Diese Messungen bestätigen die Annahme der Kontextreduktion der Architektur, nicht ihr vollständiges Verhaltensversprechen.

Sie zeigen, dass der schrittweise Entwurf von NanthAI:Edge Folgendes deutlich reduziert:

• standardmäßig bereitgestellte Skill-Anweisungen;
• standardmäßig bereitgestellte Werkzeugschemas;
• Größe des Aktionsraums für das Modell;
• Prompt-Material, das für Caching stabil bleiben muss;
• irrelevante Werkzeugkandidaten vor aufgabenspezifischer Aktivierung.

Die Messungen beweisen jedoch nicht, dass das Modell besser routet, Werkzeuge genauer auswählt oder Aufgaben erfolgreicher erledigt. Diese Aussagen erfordern eine Verhaltensevaluation.

Die statischen Messungen beantworten eine Frage:

Reduziert die schrittweise Skill-Steuerung in dieser Implementierung tatsächlich den bereitgestellten Kontext- und Schemaumfang?

Die Antwort lautet ja. In der aktuellen Implementierung ist die Reduktion groß: ungefähr 92,5 % bei Skill-Anweisungen und 97,7 % beim Basiswerkzeugregister gegenüber der vollständigen Bereitstellung.

10. Fazit

Agentische KI-Systeme stehen vor einem wachsenden Problem der Informationsarchitektur. Mit zunehmenden Werkzeugen, Integrationen, Arbeitsabläufen und Richtlinien werden monolithische Prompt- und Werkzeugregisterentwürfe immer teurer und schwerer zu bewerten. Große Kontextfenster helfen bei der Kapazität, lösen aber nicht die Probleme von Relevanz, Routing, Cache-Stabilität oder Steuerung.

Schrittweiser, durch Skills gesteuerter Werkzeugzugang bietet eine systematische Alternative. Ein kompakter Skill-Katalog ermöglicht Auffindbarkeit. load_skill sorgt für ausdrückliche Aktivierung. Geladene Skill-Anweisungen geben aufgabenspezifische Anleitung. Werkzeugprofile ermöglichen eine begrenzte Registererweiterung. Laufzeitautorisierung und Leitplanken erhalten die Fähigkeitsgrenzen.

Die Fallstudie NanthAI:Edge zeigt, wie sich dieses Muster mit Kontotarifen, geschichteten Skill-Zuständen, Katalogen verfügbarer Skills, normalisierten Nachrichten geladener Skills, profilgesteuerten Registern und Laufzeitleitplanken umsetzen lässt. Die Architektur ist vielversprechend, weil sie die Kontextkosten an aktivierten Fähigkeiten statt am gesamten Fähigkeitsspektrum der Plattform ausrichtet.

Die zentrale offene Frage ist empirisch: Überwiegen die Routing-Kosten der metadatenbasierten Skill-Auswahl die Vorteile einer geringeren Prompt- und Registerüberladung? Die Antwort hängt von Kataloggröße, Skill-Überschneidungen, Modellfamilie, Aufgabenverteilung und Implementierungsqualität ab.

Agentenplattformen sollten Fähigkeiten schrittweise bereitstellen, Routing beobachtbar machen und Werkzeuge nur aktivieren, wenn die Aufgabe sie rechtfertigt.

Literatur

• Gan, T., & Sun, Q. (2025). RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation. arXiv. https://arxiv.org/abs/2505.03275

• Liu et al. (2025). Lost in the Middle: How Language Models Use Long Contexts. https://arxiv.org/abs/2307.03172

• Gim, I., Chen, G., Lee, S.-s., Sarda, N., Khandelwal, A., & Zhong, L. (2024). Prompt Cache: Modular Attention Reuse for Low-Latency Inference. Proceedings of MLSys 2024. https://proceedings.mlsys.org/paper_files/paper/2024/file/a66caa1703fe34705a4368c3014c1966-Paper-Conference.pdf

• Liu, W., et al. (2024). ToolACE: Winning the Points of LLM Function Calling. arXiv. https://arxiv.org/html/2409.00920v2

• Yang, S., et al. (2023). Improving Planning with LLMs: A Modular Approach. arXiv. https://arxiv.org/html/2310.00194v4

• Wang, et al. (2025). Evaluating Position Bias in Large Language Model Recommendations. arXiv. https://arxiv.org/html/2508.02020v1

• Berkeley Function Calling Leaderboard. https://gorilla.cs.berkeley.edu/leaderboard.html

• Nielsen, J. (2006). Progressive Disclosure. Nielsen Norman Group. https://www.nngroup.com/articles/progressive-disclosure/

• Fowler, M. Function calling using LLMs. https://martinfowler.com/articles/function-call-LLM.html

• AWS. AI agents in enterprises: Best practices with Amazon Bedrock AgentCore. https://aws.amazon.com/blogs/machine-learning/ai-agents-in-enterprises-best-practices-with-amazon-bedrock-agentcore/

• NanthAI:Edge-Architekturbeschreibung. Vom Autor bereitgestelltes Fallstudienmaterial; nicht unabhängig geprüft.

Auch veröffentlicht auf LinkedIn.