Fähigkeits-Routing für KI-Agenten: AutoAttach, Suggest und Fallback

Von einer Android-Anfrage zu Fähigkeitskandidaten

Stell dir eine konkrete Anfrage vor: „Fass diese Benachrichtigung zusammen und erinnere mich heute Abend daran, zurückzurufen.“ Ein Android-Agent sollte daraus nicht sofort eine Aktion auslösen. Beim Fähigkeits-Routing für KI-Agenten entsteht zuerst eine Kandidatenliste: Benachrichtigung lesen, aktuellen Bildschirm als Kontext einbeziehen, Kontakt oder Nummer erkennen, Erinnerung vorbereiten, eventuell Rückrufroute vorschlagen und vor einer wirklichen Wirkung die passende Freigabe einholen.

Dieser Schritt ist nötig, weil ein Agent nicht jede Fähigkeit in jeden Kontext laden kann. Zu viele Tools, Skills, Workflows und Plugins würden den Prompt aufblähen, Latenz erhöhen und falsche Treffer wahrscheinlicher machen. Ein guter Router nutzt deshalb die Aufgabe, den aktuellen App-Zustand, verfügbare Berechtigungen, frühere Aktivierungen und Kontext-Metadaten, um wenige passende Kandidaten zu priorisieren.

Wichtig ist die Grenze: Semantische Ähnlichkeit beweist keine Autorisierung. Wenn ein Skill „Rückruf vorbereiten“ passend klingt, heißt das noch nicht, dass er aktiv, vertrauenswürdig, berechtigt oder für genau diesen Kontakt freigegeben ist. Routing beantwortet zuerst die Frage „Welche Fähigkeit könnte helfen?“ Die spätere Ausführung beantwortet „Darf und soll diese konkrete Android-Aktion jetzt sichtbar passieren?“

Für die allgemeinen Ebenen von Tools, Skills, Workflows und Plugins haben wir einen eigenen Leitfaden. Wenn du die Begriffe zuerst sortieren möchtest, führt FoneClaw Tools, Plugins, Skills und Workflows: die Ebenen richtig wählen in die Grundstruktur ein. Diese Seite bleibt enger: Sie folgt einer Anfrage durch Auswahl, Aktivierung, Freigabe und Wiederherstellung.

AutoAttach, Suggest oder Fallback richtig wählen

Nach der Kandidatenermittlung muss der Agent entscheiden, wie stark er eingreift. Bei FoneClaw denken wir in drei Routen: AutoAttach, Suggest und Fallback. Diese Begriffe beschreiben keine Ausführung, sondern den Umgang mit Kontext und Kandidaten. Genau diese Trennung schützt den Nutzer vor zwei Fehlern: zu wenig Hilfe bei klaren Aufgaben und zu viel Automatik bei unsicheren Aufgaben.

AutoAttach passt, wenn der Bezug eindeutig und risikoarm ist. Bei einer sichtbaren Benachrichtigung kann der Agent relevante lokale Kontext-Metadaten an die Anfrage hängen: App-Quelle, sichtbarer Text, Zeitpunkt oder eine bereits bekannte Aufgabenart. AutoAttach bedeutet nicht, dass ein Tool ausgeführt wird. Es bedeutet: Der Agent erhält passenderen Kontext, damit er nicht raten muss.

Suggest ist die richtige Route, wenn mehrere sinnvolle Kandidaten existieren oder wenn der nächste Schritt für den Nutzer erkennbar gewählt werden sollte. Bei „erinnere mich daran“ kann FoneClaw zum Beispiel eine Erinnerung, eine Aufgabe oder einen Kalendertermin als Möglichkeit zeigen. Suggest gibt dem Nutzer eine sichtbare Wahl, bevor eine Fähigkeit aktiviert oder eine Aktion vorbereitet wird.

Fallback greift, wenn kein Kandidat zuverlässig genug ist, eine Abhängigkeit fehlt, eine Berechtigung blockiert, ein Plugin nicht aktiv ist oder die Anfrage mehrdeutig bleibt. Fallback ist keine Hintertür um Regeln herum. Er ist der sichere Weiterweg: nachfragen, eine manuelle Option zeigen, zu einer vorhandenen Standardfähigkeit wechseln oder erklären, welche Voraussetzung fehlt.

Diese Matrix ist in der Praxis wichtiger als ein einzelner Confidence-Wert. Ein hoher Wert kann bei einem falschen Ziel gefährlich sein; ein niedriger Wert kann bei einer harmlosen Zusammenfassung trotzdem nützlich sein, wenn der Agent nur eine Rückfrage stellt. Gute Router bewerten daher Aufgabe, Risiko, Kontext und Nutzerwirkung gemeinsam.

Discovery, Attachment, Aktivierung, Freigabe und Ausführung trennen

Der häufigste Denkfehler beim Android-Agent Tool-Routing ist die Vermischung von Zuständen. Ein Agent kann eine Ressource entdecken, ohne sie zu installieren. Er kann Metadaten anhängen, ohne eine Fähigkeit zu aktivieren. Er kann eine Fähigkeit aktivieren, ohne jede spätere Aktion automatisch freizugeben. Und er kann eine Aktion vorbereiten, ohne sie bereits endgültig auszuführen.

Die Zustandsmaschine beginnt mit Discovery. Der Agent findet eine eingebaute Fähigkeit, einen Skill, Workflow oder Plugin-Kandidaten. Der GitHub-Hinweis zu Agent Finder zeigt branchenweit ein ähnliches Muster: relevante Ressourcen können bei Bedarf gerankt werden, ohne dass sie still installiert werden. Für FoneClaw ist das eine nützliche Analogie, keine Produktintegration.

Danach folgt Attachment. Hier wird Kontext oder Fähigkeitsmetadatum in den aktuellen Agentenablauf aufgenommen. Ein Beispiel ist der sichtbare Bildschirm, eine passende Tool-Beschreibung oder der Hinweis, dass ein bestimmter Skill existiert. Attachment schafft Orientierung, aber noch keine Ausführung.

Aktivierung ist ein eigener Schritt. Ein Plugin oder Skill kann sichtbar geprüft, aktiviert oder als Entwurf vorbereitet werden. Die Google-Developer-Ankündigung zu Agent Plugins beschreibt Plugins als offene, herstellerneutrale Verpackung für Agent Skills und MCP-Server mit gemeinsamen Metadaten. Verpackung erleichtert Auffindbarkeit und Struktur, ersetzt aber nicht Vertrauen, Aktivierung oder Ausführungskontrolle.

Erst danach kommen Freigabe und Ausführung. Eine aktivierte Fähigkeit darf nicht automatisch jede spätere Android-Aktion durchführen. Senden, Löschen, Kaufen, Anrufen, Teilen oder Kontoänderungen brauchen sichtbare Prüfung. Nach der Ausführung folgt die Ergebnisprüfung: Ist der Entwurf sichtbar? Wurde die Systemeinstellung geändert? Fehlt eine Berechtigung? Der letzte Zustand ist Wiederherstellung, nicht blinder Retry.

Manifeste, Abhängigkeiten, Kontext und Sicherheitssignale nutzen

Verlässliches Plugin- und Skill-Routing braucht bessere Eingaben als nur Namen und Schlagwörter. Ein Manifest hilft, Identität, Fähigkeiten, erwartete Eingaben, Ausgaben, Abhängigkeiten und mögliche Kontextarten zu beschreiben. Es beantwortet aber nur einen Teil der Frage. Metadaten machen eine Fähigkeit auffindbar; sie machen sie nicht automatisch vertrauenswürdig.

Abhängigkeiten sind der nächste Prüfpunkt. Ein Plugin kann einen MCP-Server, eine Berechtigung, eine lokale App, eine Netzwerkverbindung oder ein Konto brauchen. Diese Voraussetzungen müssen vor Aktivierung und spätestens vor Ausführung geprüft werden. Wenn eine Abhängigkeit fehlt, ist Suggest oder Fallback besser als eine scheinbar passende Route, die später unklar scheitert.

Kontext-Metadaten geben dem Router die Richtung. Ist der Nutzer in einer Mail-App, auf einer Karte, in einer Chat-Konversation oder in den Android-Einstellungen? Geht es um sichtbaren Text, ein Bild, eine Telefonnummer, einen Termin oder eine App-Aktion? Je genauer diese Metadaten sind, desto kleiner wird die Kandidatenliste. Gleichzeitig begrenzen sie den Kontext: Nicht jede Aufgabe braucht Kontakte, Standort oder Benachrichtigungen.

Confidence ist ein Signal, kein Urteil. Ein Router sollte nicht nur „höchster Score gewinnt“ verwenden. Er sollte falsche Positive, fehlende Abhängigkeiten, sensible Wirkung und Mehrdeutigkeit mitbewerten. In FoneClaw verwenden wir deshalb stabile Fähigkeitszustände und überprüfbare Snapshots: Wenn eine Aktualisierung einer Fähigkeit fehlschlägt, bleibt der letzte akzeptierte Zustand erhalten, statt einen halb aktiven Zustand entstehen zu lassen.

Für tiefere Fragen rund um Ressourcensuche, Registries und Vertrauen ist Agentic Resource Discovery: Ressourcensuche, ai-catalog.json und Vertrauen für Phone Agents die passendere Vertiefung. Hier geht es um die Entscheidung im laufenden Android-Ablauf.

Fehlende, veraltete, abgelehnte oder mehrdeutige Fähigkeiten abfangen

Ein guter Fähigkeitsrouter plant Fehlerfälle ausdrücklich ein. Der einfachste Fall ist eine fehlende Fähigkeit: Der Nutzer fragt nach einer Aktion, die nicht durch ein eingebautes Tool, einen aktiven Skill, einen Workflow oder ein geprüftes Plugin abgedeckt ist. Dann sollte der Agent nicht so tun, als könne er handeln. Er kann eine Alternative anbieten, eine manuelle Anleitung geben oder eine passende Ressource zur Prüfung vorschlagen.

Veraltete Abhängigkeiten sind schwieriger. Ein Plugin kann vorhanden sein, aber eine benötigte Berechtigung, App-Version, Serververbindung oder lokale Einstellung fehlt. Hier hilft kein reiner Modell-Retry. Der Router muss den Zustand erkennen und in Wiederherstellung wechseln: Berechtigung öffnen, Aktivierung prüfen, Konto anmelden lassen oder auf eine unterstützte Standardroute zurückfallen.

Abgelehnte Berechtigungen sind ein eigener Zustand. Wenn der Nutzer Kontakte, Benachrichtigungen, Kalender oder Standort nicht freigibt, bleibt die Entscheidung bestehen. FoneClaw führt dann nicht dieselbe Anfrage immer wieder aus. Der Agent erklärt, welche Fähigkeit eingeschränkt ist, und bietet eine Route an, die mit dem aktuellen Berechtigungsstand funktioniert.

Mehrdeutigkeit ist der häufigste Alltagsfall. „Schick Alex die Adresse“ kann mehrere Alex-Kontakte, mehrere Adressen oder mehrere Apps meinen. Ein sicherer Router stellt eine Rückfrage oder zeigt eine sichtbare Auswahl. Für Skills mit höheren Risiken lohnt sich zusätzlich ein Blick auf Sicherheit von KI-Agent-Skills: Warum Phone Agents Laufzeitprüfungen brauchen, weil Skill-Fähigkeit und Android-Berechtigung getrennt geprüft werden sollten.

Kontrolliertes Fähigkeits-Routing in FoneClaw anwenden

In FoneClaw beginnt Routing mit der aktuellen Anfrage und dem Kontext, den der Nutzer bewusst einbringt. Das kann eine Chat-Anfrage, eine sichtbare App-Situation, ein aktueller Bildschirm, eine Benachrichtigung oder ein vorheriger Aufgabenverlauf sein. Aus diesem Kontext erzeugt der Agent Kandidaten: eingebaute Tools, vorhandene Workflows, verfügbare Skills oder geprüfte Plugin-Wege.

Der aktuelle FoneClaw-Umfang umfasst 100+ built-in tools und kontrollierte Erweiterungspfade. Die FoneClaw-Funktionsseite beschreibt diese Fähigkeiten auf Produktebene. Für Routing heißt das: Der Agent muss nicht bei jeder Anfrage das gesamte Universum möglicher Funktionen laden. Er kann lokale Hinweise nutzen, Kandidaten sortieren und nur relevante Fähigkeitsdaten in den Ablauf bringen.

AutoAttach, Suggest und Fallback setzen genau hier an. AutoAttach ergänzt passende lokale Metadaten, wenn die Verbindung zur Aufgabe klar ist. Suggest zeigt dem Nutzer eine nachvollziehbare Option, wenn mehrere Wege plausibel sind. Fallback hält den Ablauf nutzbar, wenn kein Weg sicher genug ist, eine Abhängigkeit fehlt oder eine Berechtigung blockiert. Keiner dieser Schritte umgeht Freigaben.

Bei Plugins und Skills bleibt der Lebenszyklus sichtbar. Plugin-Aktivierung wird geprüft, statt still zu passieren. Skill-Lernen arbeitet mit Vorschau und Bestätigung, bevor ein deaktivierter Entwurf gespeichert wird. Das ist Absicht: Wir bauen FoneClaw so, dass eine entdeckte Fähigkeit nicht mit einer ausgeführten Android-Aktion verwechselt wird. Der Nutzer soll sehen, was vorgeschlagen, aktiviert, vorbereitet und schließlich ausgeführt wird.

Ein Beispiel macht den Ablauf greifbar. Du bittest FoneClaw: „Erstelle aus diesem Chat eine Aufgabe für morgen.“ Der Router erkennt Bildschirmkontext, Aufgabenabsicht und mögliche Kandidaten. AutoAttach kann den sichtbaren Chatkontext ergänzen. Suggest kann zwischen Aufgabe, Erinnerung oder Kalendertermin unterscheiden. Nach deiner Auswahl bereitet FoneClaw den unterstützten Android-Schritt vor. Vor sensiblen Wirkungen bleibt die Freigabe sichtbar, und bei fehlender Kalender- oder Benachrichtigungsberechtigung führt FoneClaw in Wiederherstellung.

Diese Freigabe- und Confidence-Gestaltung ist ein eigenes Thema. Wenn du tiefer in sichtbare Vorschläge, Begründungen und Freigabegrenzen einsteigen möchtest, ergänzt KI-Agent Freigabe-UX auf dem Smartphone: Vorschläge, Freigaben und Wiederherstellung diesen Routing-Leitfaden.

Sieben Tests für einen verlässlichen Fähigkeitsrouter

Ein Fähigkeitsrouter sollte nicht nur an erfolgreichen Treffern gemessen werden. Gerade falsche Treffer und No-Match-Fälle zeigen, ob die Architektur alltagstauglich ist. Diese sieben Prüfungen helfen beim Design und bei der Bewertung.

• Kandidatenqualität: Erzeugt der Router wenige, passende Kandidaten statt einer langen unsortierten Liste?
• False Positive: Was passiert, wenn ein Skill ähnlich klingt, aber für die Aufgabe nicht geeignet ist?
• No-Match: Kann der Agent hilfreich weiterarbeiten, wenn keine passende Fähigkeit existiert?
• Abhängigkeiten: Werden fehlende Apps, Konten, Berechtigungen oder Serverzustände vor Aktivierung und Ausführung erkannt?
• Attachment-Grenze: Bleibt AutoAttach auf Kontext und Metadaten beschränkt, ohne Tools auszuführen?
• Freigabegrenze: Halten sensible Android-Wirkungen sichtbar an, auch wenn Routing und Aktivierung erfolgreich waren?
• Wiederherstellung: Gibt es einen klaren nächsten Schritt bei Abbruch, Ablehnung, veraltetem Snapshot oder mehrdeutigem Ziel?

Der beste Test ist eine reversible Android-Anfrage mit zwei Varianten: einmal mit klarem Treffer und einmal mit absichtlich fehlender Fähigkeit. Ein Router ist erst dann gut, wenn beide Fälle verständlich enden. Genau dort liegt der Wert von kontrolliertem Fähigkeits-Routing: Der Agent findet Hilfe, ohne Auswahl, Aktivierung, Freigabe und Ausführung miteinander zu verwechseln.