💬 NLP

Skill-as-Pseudocode: Refactoring Skill Libraries to Pseudocode for LLM Agents

Das Papier schlägt Skill-as-Pseudocode (SaP) vor, eine automatische Methode, die freie Markdown-Skill-Bibliotheken in typisierten Pseudocode mit deterministischer Verifikation umwandelt und dadurch LLM-Agenten ermöglicht, auf dem ALFWorld-Benchmark deutlich höhere Erfolgsraten und einen reduzierten Token-Verbrauch zu erzielen, indem sie klare typisierte Signaturen und konkrete Aufrufvorlagen bereitstellt.

Ursprüngliche Autoren: Xinze Li, Yuhang Zang, Yixin Cao, Aixin Sun

Veröffentlicht 2026-05-28

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Xinze Li, Yuhang Zang, Yixin Cao, Aixin Sun

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie unterrichten einen sehr intelligenten, aber wörtlich denkenden Roboter bei der Erledigung von Hausarbeiten, wie zum Beispiel das Reinigen eines Hauses oder das Aufräumen einer Küche. Sie geben dem Roboter ein riesiges, unordentliches Handbuch mit Anweisungen in normalem Englisch (Markdown).

Das Problem: Die „verwirrende Schleife"
Jedes Mal, wenn der Roboter etwas tun muss, muss er lange Textabsätze durchlesen, um zwei Dinge herauszufinden:

Was die Aufgabe ist (z. B. „den Becher bewegen").
Genau wie er es dem Computersystem des Hauses sagen muss (z. B. akzeptiert das System nur den Befehl move mug to shelf, nicht put mug on shelf).

Da die Anweisungen in Absätzen versteckt sind, rät der Roboter oft falsch. Er versucht, den Becher „zu legen", das Haus sagt „Nichts passiert", und der Roboter wird verwirrt. Dann geht er zurück, um das Handbuch erneut zu lesen, rät wieder falsch und steckt in einer Schleife des Scheiterns fest. Das kostet Zeit und lässt dem Roboter die Energie ausgehen (oder „Tokens", in KI-Terminologie).

Die Lösung: „Skill-as-Pseudocode" (SaP)
Die Autoren dieses Papiers haben ein System namens Skill-as-Pseudocode (SaP) entwickelt. Stellen Sie sich dies als einen „Übersetzer" vor, der das unordentliche menschliche Handbuch nimmt und es in eine saubere, strukturierte Spickzettel für den Roboter umschreibt.

So funktioniert der Übersetzer, anhand einer einfachen Analogie:

1. Der Detektiv (Muster finden)

Stellen Sie sich einen Bibliothekar vor, der durch hunderte verschiedener Anweisungsmanuals schaut. Er bemerkt, dass viele Manuals dasselbe auf unterschiedliche Weise sagen.

Manual A sagt: „Gehen Sie in die Küche, nehmen Sie das Salz und legen Sie es in den Schrank."
Manual B sagt: „Finden Sie das Salz auf der Arbeitsplatte und bewegen Sie es in den Schrank."

Der Bibliothekar erkennt, dass dies eigentlich dieselbe zugrunde liegende Aktion ist. Er gruppiert diese ähnlichen Anweisungen zu einem „Cluster" zusammen.

2. Der Architekt (Entwurf des Bauplans)

Für jede Gruppe ähnlicher Anweisungen lässt das System eine KI einen Typisierten Vertrag entwerfen.

Statt eines Absatzes sieht dieser Vertrag wie eine Computerfunktion aus: move_object(from: "counter", to: "cabinet").
Er listet klar auf: Welche Eingaben werden benötigt? Was passiert danach? Was sind die Regeln?

3. Der Sicherheitsinspektor (Die vier Prüfungen)

Bevor das System den Roboter diesen neuen Bauplan nutzen lässt, führt ein strenger Sicherheitsinspektor vier spezifische Prüfungen durch, um sicherzustellen, dass die Übersetzung perfekt ist:

Abdeckung: Haben wir wichtige Details aus dem Originaltext übersehen?
Bindung: Wissen wir genau, woher wir das „Salz" oder den „Becher" aus dem ursprünglichen Satz beziehen?
Ersatz: Wenn wir den alten Absatz durch diesen neuen Bauplan ersetzen, ergibt der Rest des Manuals immer noch Sinn?
Risiko: Sagt diese neue Anweisung dem Roboter versehentlich, etwas Gefährliches zu tun (wie eine Datei zu löschen oder ein Fenster zu zerbrechen)?

Wenn der Bauplan alle vier Prüfungen besteht, wird er genehmigt. Wenn er auch nur eine nicht besteht, wird er verworfen, um zu verhindern, dass der Roboter verwirrt wird.

4. Die Lieferung (Das „Paket")

Wenn der Roboter eine Aufgabe erledigen muss, erhält er nicht das alte, unordentliche Handbuch. Stattdessen erhält er ein Paket, das drei Teile hat, in der perfekten Reihenfolge präsentiert:

Die „How-To"-Vorlage: Die genauen Wörter, die der Roboter an den Hauscomputer tippen muss (z. B. move {object} to {target}).
Die „Was"-Signatur: Eine klare Zusammenfassung dessen, was die Fähigkeit bewirkt.
Der Kontext: Der Rest der Anweisungen, nun bereinigt, damit sie der neuen Vorlage nicht widersprechen.

Die Ergebnisse

Die Forscher testeten dies an einem Spiel namens ALFWorld, bei dem ein KI-Agent Haushaltsrätsel lösen muss.

Alter Weg (Graph-of-Skills): Der Roboter las das unordentliche Handbuch, riet falsch, steckte in Schleifen fest und scheiterte häufig.
Neuer Weg (SaP): Der Roboter erhielt den sauberen „Spickzettel". Er wusste sofort genau, was zu tun war und wie er es sagen musste.

Das Ergebnis:

Der Roboter löste 82 von 134 Spielen mit der neuen Methode, verglichen mit nur 47 mit der alten Methode.
Er verwendete zudem 22 % weniger Speicher und tätigte 14 % weniger Aufrufe an das KI-Gehirn, da er nicht immer wieder das Handbuch neu lesen musste, wenn er stecken blieb.

Kurz gesagt:
Das Papier zeigt, dass KI-Agenten aufhören, verwirrt zu werden und Fehler zu machen, und die Arbeit viel schneller erledigen, wenn man ihnen nicht lange, unordentliche Absätze gibt, sondern stattdessen strukturierte, verifizierte „code-ähnliche" Anweisungen. Das System wirkt wie ein rigoroser Redakteur, der menschliche Prosa in roboterfertige Baupläne verwandelt.

Technische Zusammenfassung: Skill-as-Pseudocode (SaP)

Problemstellung

Moderne LLM-basierte Agenten verlassen sich auf Skill-Bibliotheken – Sammlungen prozeduraler Dokumente (typischerweise Markdown), die Agenten während der Aufgabenausführung abrufen und befolgen. Diese Bibliotheken werden jedoch derzeit als freiformulierter Prosa verfasst. Diese Darstellung erzeugt einen signifikanten Engpass: Der Agent muss bei jedem Abruf sowohl das Eingabeschema (was der Skill tut) als auch die konkrete Aufrufsyntax (wie er aufgerufen wird) neu ableiten.

Die Autoren stellen fest, dass dieses proslastige Format eine „verwirrt → erneut abrufen → immer noch verwirrt"-Schleife induziert. Wenn ein Agent eine teilweise korrekte Aktion basierend auf einer Prosa-Beschreibung ausführt, liefert die Umgebung häufig nichtssagendes Feedback (z. B. „Nichts passiert"). Der Agent ruft dann dieselbe Prosa erneut ab, scheitert daran, das fehlende Detail zu extrahieren, und wiederholt den Zyklus. Diese Schleife führt sowohl zu Aufgabenfehlern als auch zu erhöhten LLM-Aufrufkosten. Zwar existieren typisierte Kataloge wie OpenAPI, doch sie stellen nicht die Standard-Bereitstellungsoberfläche für Agent-Skills dar, die weiterhin in Markdown vorliegen.

Methodik: Skill-as-Pseudocode (SaP)

Die Autoren schlagen Skill-as-Pseudocode (SaP) vor, eine automatische Pipeline, die Markdown-Skill-Bibliotheken in typisierten Pseudocode mit deterministischer Qualitätskontrolle umwandelt. Die Kernidee besteht darin, dass zwei spezifische Signale die Abruf-Aktions-Schleife unterbrechen:

Ein typisierter Vertrag: Eine strukturierte Signatur, die den Auslöser, die Ein-/Ausgabeschemata sowie die Vor- und Nachbedingungen offenlegt.
Konkrete Aktionsvorlagen: Die genauen Token-Sequenzen, die die Umgebung akzeptiert (z. B. move {obj} to {target}), im Gegensatz zum abstrakten Vertrag.

Die Pipeline

Die SaP-Pipeline verarbeitet eine Bibliothek übergeordneter Skills (Markdown-Dokumente) durch fünf Stufen sowie zwei LLM-bewusste Nach-Verifizierungsdurchläufe:

Parser: Unterteilt Markdown-Dokumente in prozedurale Einheiten (Abschnitte unter Überschriften).
Kandidaten-Vorschlag: Gruppiert Einheiten aus einem oder mehreren übergeordneten Dokumenten zu Kandidaten-Clustern basierend auf gemeinsamen Verben, Objekten und Code-Verknüpfungen unter Verwendung von Embedding-basiertem Clustering.
Vertrags-Extraktor (LLM): Für jedes Cluster erstellt ein einzelner LLM-Aufruf einen strengen JSON-typisierten Vertrag ( $\kappa$ ).
Verifizierer (Deterministisch): Ein vierstufiger deterministischer Verifizierer bewertet den Entwurfsvertrag. Ein Vertrag wird nur befördert, wenn er folgende Kriterien erfüllt:
- Abdeckung: Die Auslöser- und E/A-Strings des Vertrags müssen im Text der übergeordneten Einheit vorhanden sein.
- Bindung: Jeder erforderliche Eingabewert im Vertrag muss einem entsprechenden Span im übergeordneten Text entsprechen.
- Ersetzung: Die übergeordnete Einheit muss syntaktisch durch einen invoke(κ, args)-Platzhalter ersetzbar sein, ohne den Kontrollfluss zu unterbrechen.
- Risiko: Der Vertrag darf keine unsicheren Nebeneffekte enthalten (z. B. rm -rf, nicht deklarierte Netzwerk-Egress).
Refaktorierung: Validierte Verträge werden in die übergeordneten Skills inline eingefügt.
- Bindungsextraktion (BE): Ein LLM-Durchlauf, der überprüft, ob eine bestimmte Einheit ein echtes Beispiel des Vertrags ist, und die spezifischen Argumentbindungen extrahiert. Falsche Treffer werden verworfen.
- Umschreibungs-Bereinigung (RC): Ein LLM-Durchlauf, der verbleibende Prosa-Konflikte erkennt und umschreibt (z. B. ein Beispielblock, der ein Verb wie put verwendet, während die Umgebung move erfordert), um mit dem verifizierten Vertrag übereinzustimmen.

Substitution zur Laufzeit des Abrufs

Zum Inferenzzeitpunkt ruft der Agent ein ersetztes Skill-Bündel ab, nicht rohe Prosa. Für einen abgerufenen übergeordneten Skill ersetzt das System den ursprünglichen Inhalt durch:

Aktionsvorlagen: Konkrete, ausführbare Befehlssequenzen mit extrahierten Bindungen (werden zuerst platziert).
Umschriebenes Skelett: Die übergeordnete Struktur mit invoke(κ, args)-Platzhaltern.
Inline-Vertrag: Die typisierte Signatur und das Schema für den aufgerufenen untergeordneten Skill.

Entscheidend ist, dass das System einen ausschließlich hierarchischen Abrufpool verwendet. Beförderte untergeordnete Verträge werden intern gespeichert und sind nur über den invoke-Platzhalter des übergeordneten Elements zugänglich. Das Bloßstellen von untergeordneten Elementen als eigenständige Top-Level-Ergebnisse wird vermieden, da dies dem Agenten den notwendigen Kontext (die Aktionsvorlagen des übergeordneten Elements) entziehen würde.

Hauptbeiträge

Neudefinition der Skill-Verbesserung: Das Papier definiert die Optimierung von Skill-Bibliotheken neu als ein Prosa-zu-typisiertem-Pseudocode-Konvertierungsproblem mit deterministischer Qualitätskontrolle, das bestehende Arbeiten zur typisierten Weiterleitung ergänzt, die davon ausgehen, dass Verträge bereits existieren.
Die SaP-Pipeline: Eine neuartige Architektur mit einem vierstufigen deterministischen Verifizierer und zwei LLM-bewussten Nach-Verifizierungsdurchläufen (BE und RC), die jeweils durch deterministische Nachprüfungen geschützt sind, um Sicherheit und Konsistenz zu gewährleisten.
Hierarchische Abrufschnittstelle: Ein Abrufmechanismus, der pro Aufruf ein strukturiertes Bündel (typisierter Vertrag + konkrete Vorlage) liefert und das „Was" (Vertrag) vom „Wie" (Vorlage) trennt.
Empirische Validierung: Nachweis, dass SaP im Vergleich zur Graph-of-Skills (GoS)-Basislinie gleichzeitig die Erfolgsquote von Aufgaben verbessert und Token-/LLM-Aufrufkosten senkt.

Ergebnisse

Experimente wurden auf dem ALFWorld-Unseen-Split (134 Spiele) mit gpt-4o-mini und einer Teilmenge von SkillsBench (10 Aufgaben) mit gpt-5-codex durchgeführt.

ALFWorld-Leistung: Über drei Seeds (402 gepaarte Spiele) gewann SaP 82/402 Spiele im Vergleich zu 47/402 für die GoS-Basislinie. Dies entspricht einer relativen Reward-Steigerung von 74% (McNemar $p = 8.2 \times 10^{-5}$ ).
Effizienzgewinne: SaP erzielte diese Gewinne bei gleichzeitiger Reduzierung der Eingabetokens um 22,8%, der Ausgabetokens um 17,3% und der LLM-Aufrufe um 14,5% pro Spiel.
Mechanismusanalyse: Die Verbesserung wird auf das Durchbrechen der „Abruf-Aktions-Schleife" zurückgeführt. SaP-Agenten verursachten signifikant weniger „Nichts passiert"-Fehler und erneut Abrufanfragen. Die Korrektheit der Aktionen nach dem Abruf verbesserte sich von 20,5% (GoS) auf 29,3% (SaP).
Ablationsstudie: Das Entfernen der hierarchischen Trennung (Bloßstellen von untergeordneten Elementen als eigenständige Ergebnisse) führte zu einem Reward-Rückgang von 27%, was die Notwendigkeit der übergeordneten-untergeordneten Bündelstruktur bestätigt. Die BE- und RC-Durchläufe erwiesen sich als Reparatur unterschiedlicher Fehlermodi (falsche Cluster-Mitgliedschaft bzw. Syntaxkonflikte).

Bedeutung und Behauptungen

Das Papier behauptet, dass die Prosa-Darstellung selbst, und nicht ein Mangel an Faktorisierung, der dominante Engpass für LLM-Agenten ist, die Skill-Bibliotheken konsumieren. Durch die Automatisierung der Umwandlung von Prosa in typisierten Pseudocode mit deterministischer Verifizierung bietet SaP Agenten ein „Was" (Vertrag) und ein „Wie" (Vorlage) in einer einzigen Antwort.

Die Autoren positionieren SaP als eine produktseitige Lösung für das Problem der typisierten Weiterleitung. Während bestehende Arbeiten davon ausgehen, dass Verträge handschriftlich verfasst sind, gewinnt SaP sie aus Prosa zurück. Die Methodik wird als disziplinierter Ansatz präsentiert, bei dem jeder LLM-Extrakt eine Hypothese ist, die durch deterministische Regeln überprüft wird, anstatt ein Black-Box-Ausgang zu sein.

Das Papier vermerkt bescheiden, dass die Pipeline zwar architektonisch für typisierte APIs (OpenAPI) unterstützt wird, die aktuelle empirische Evaluation jedoch auf Markdown-Bibliotheken beschränkt ist. Darüber hinaus ist der Ersetzungsmechanismus statisch (syntaktisch) und nicht dynamisch (Laufzeit-Erweiterung) und verlässt sich darauf, dass die Abrufschnittstelle untergeordnete Verträge bei Bedarf bereitstellt. Die Ergebnisse deuten darauf hin, dass für statische Skill-Bibliotheken die Kosten der Prosa-zu-Struktur-Konvertierung zum Indexierungszeitpunkt und nicht bei jedem Abruf getragen werden können, was die Effizienz und Zuverlässigkeit von Agenten erheblich verbessert.