Wie KI-Agenten Skills tatsächlich implementieren: Vollständiger plattformübergreifender Vergleich

Einleitung

Jedes KI-Agenten-Framework steht vor der gleichen grundlegenden Frage: Wie macht man ein LLM in einem bestimmten Bereich gut? Das Modell selbst verfügt über breites Allgemeinwissen, aber wenn es ein Code-Review durchführen, Infrastruktur bereitstellen oder Minecraft navigieren soll, benötigt es spezialisierte Anweisungen, Tool-Zugang und Domänenkontext.

Das ist das Skill-Injektionsproblem. Und jedes große Framework löst es anders.

Manche Plattformen laden alles von Anfang an in den System-Prompt. Andere nutzen Lazy Loading und enthüllen Fähigkeiten erst, wenn der Agent sie benötigt. Einige wenige verwenden Vektordatenbanken, um relevante Skills basierend auf semantischer Ähnlichkeit abzurufen. Die Unterschiede sind nicht akademisch – sie wirken sich direkt auf Token-Kosten, Agenten-Zuverlässigkeit und die Anzahl der Skills aus, die ein Agent realistisch handhaben kann.

Wir haben 11 große KI-Agenten-Plattformen analysiert, um genau zu verstehen, wo Skills im Prompt landen, wann sie geladen werden, was sie an Tokens kosten und wie sie überleben, wenn das Kontextfenster voll wird. Dies ist kein oberflächlicher Feature-Vergleich. Wir haben Quellcode, Dokumentation und Architekturdiagramme untersucht, um die genauen Injektionsmechanismen jeder Plattform zu kartieren.

Master-Vergleichstabelle

Hier ist der vollständige Überblick, bevor wir in die Details eintauchen.

Injektionsmechaniken: Wo, Wann und Wie

Persistenz, Token-Kosten und Always-On-Verhalten

Bereit, Ihr Geschäft zu erweitern?

Starten Sie heute Ihre kostenlose Testversion und sehen Sie innerhalb weniger Tage Ergebnisse.

Demo anfragen Anmelden

Was “Skill-Injektion” tatsächlich bedeutet

Bevor wir in den Vergleich eintauchen, definieren wir den Problemraum. Das Kontextfenster eines KI-Agenten – der gesamte Text, den das LLM bei jedem Aufruf sieht – hat eine feste Größe. Jeder Token an Anweisungen, Konversationsverlauf, Tool-Definitionen und abgerufenen Daten konkurriert um Platz in diesem Fenster.

Ein “Skill” im Agenten-Kontext ist jedes strukturierte Paket von Fachwissen, das das Verhalten des Agenten verändert. Dies kann sein:

• Anweisungen, die dem Agenten sagen, wie er eine bestimmte Domäne angehen soll (Code-Review-Richtlinien, Deployment-Checklisten)
• Tool-Definitionen, die dem Agenten aufrufbare Funktionen geben (API-Integrationen, Dateioperationen)
• Few-Shot-Beispiele, die dem Agenten zeigen, wie gute Ausgaben aussehen
• Abgerufenes Wissen aus Vektordatenbanken oder externen Dokumenten

Der Injektionsmechanismus – wo und wann dieser Inhalt in den Kontext gelangt – bestimmt drei kritische Eigenschaften:

1. Token-Effizienz: Wie viele Tokens verbraucht der Skill, und werden diese Kosten auch dann fällig, wenn der Skill nicht benötigt wird?
2. Zuverlässigkeit: Wird der Agent den Skill konsistent nutzen, wenn er relevant ist, oder könnte er den Hinweis verpassen?
3. Skalierbarkeit: Auf wie viele Skills kann der Agent zugreifen, bevor Kontextaufblähung die Leistung verschlechtert?

Jedes Framework trifft unterschiedliche Kompromisse über diese drei Dimensionen hinweg. Schauen wir uns jedes einzelne an.

Das Injektionsspektrum: Von Always-On bis On-Demand

Über alle 11 Plattformen hinweg fallen die Ansätze zur Skill-Injektion auf ein Spektrum von “alles vorab geladen” bis “nichts geladen, bis es explizit benötigt wird.”

Am einen Ende injizieren Plattformen wie CrewAI, SuperAGI und CAMEL-AI den vollständigen Inhalt jedes aktivierten Skills in jeden LLM-Aufruf. Der Agent hat immer seine vollständige Expertise verfügbar. Einfach, zuverlässig, aber teuer in Tokens.

Am anderen Ende verwenden Claude Code, LangChain Deep Agents und OpenAIs Responses API Progressive Disclosure – der Agent sieht beim Start nur Skill-Namen und kurze Beschreibungen, und der vollständige Inhalt wird bei Bedarf geladen. Effizient, skalierbar, aber der Agent muss erkennen, wann er einen Skill benötigt.

In der Mitte nutzen AutoGen Teachability und Voyager semantisches Retrieval, um nur die relevantesten Skills pro Runde zu injizieren, was ein dynamisches, kontextsensitives Injektionsmuster erzeugt.

Und dann gibt es einzigartige Ansätze: DSPy kompiliert optimierte Few-Shot-Beispiele offline und baut sie dauerhaft in Modul-Prompts ein. MetaGPT codiert Skills als Action-Templates, die nur aktiviert werden, wenn eine bestimmte Rolle zu einer bestimmten Action übergeht.

Schauen wir uns jede Plattform im Detail an.

Abonnieren Sie unseren Newsletter

Erhalten Sie die neuesten Tipps, Trends und Angebote kostenlos.

E-Mail-Adresse

Abonnieren

Claude Code: Dreischichtiges Progressive Disclosure

Claude Code implementiert eine der ausgereiftesten Skill-Injektionsarchitekturen mit einem dreischichtigen Progressive-Disclosure-System, das Bewusstsein mit Token-Effizienz in Einklang bringt.

Schicht 1: Immer im Kontext

Beim Sitzungsstart wird der Name und die Beschreibung jedes verfügbaren Skills in eine system-reminder-Nachricht injiziert – ein Metadatenblock, den das Modell immer sieht. Dies kostet ungefähr 250 Zeichen pro Skill und verbraucht etwa 1% des Kontextfenster-Budgets für alle Skill-Beschreibungen zusammen (circa 8K Zeichen als Fallback-Budget, überschreibbar über die Umgebungsvariable SLASH_COMMAND_TOOL_CHAR_BUDGET).

Ebenso erscheinen verzögerte Tools – Tools, deren vollständige JSON-Schemas noch nicht geladen wurden – als reine Namensliste in System-Reminder-Blöcken. Ab Claude Code v2.1.69 werden sogar eingebaute System-Tools wie Bash, Read, Edit, Write, Glob und Grep hinter ToolSearch verzögert, was den System-Tool-Kontext von ungefähr 14-16K Tokens auf etwa 968 Tokens reduziert.

Der Agent sieht genug, um zu wissen, was verfügbar ist, ohne die Token-Kosten vollständiger Definitionen zu zahlen.

Schicht 2: Bei Aktivierung

Wenn ein Benutzer einen Slash-Befehl eingibt (z.B. /commit) oder das Modell einen Skill basierend auf seiner Beschreibung automatisch zuordnet, wird der vollständige SKILL.md-Body als Konversationsnachricht über das Skill-Tool geladen. Dieser Body enthält die vollständigen Anweisungen – manchmal Tausende von Tokens an detaillierter Anleitung.

Wichtiges Detail: Shell-Vorverarbeitung läuft zuerst (alle !command-Direktiven in der Skill-Datei werden ausgeführt und ihre Ausgabe ersetzt die Direktive), und einmal geladen, bleibt der Skill-Body für den Rest der Sitzung in der Konversation.

Schicht 3: Bei Bedarf

Zusätzliche Ressourcen – Referenzdokumente, Skripte, Asset-Dateien – werden nur gelesen, wenn das Modell sich explizit entscheidet, das Read-Tool zu verwenden, um auf sie zuzugreifen. Diese werden nie automatisch geladen.

Verhalten bei Kontextkomprimierung

Wenn die Konversation sich dem Kontextlimit nähert und die Komprimierung ausgelöst wird, hängt Claude Code die zuletzt aufgerufenen Skills mit einem Budget von 5K Tokens pro Skill und einem kombinierten Maximum von 25K wieder an. Zuletzt aufgerufene Skills haben Priorität. Ältere Skills können vollständig entfernt werden.

Diese dreischichtige Architektur bedeutet, dass ein Agent mit über 20 verfügbaren Skills minimale Vorabkosten zahlt, aber innerhalb einer einzigen Runde auf vollständiges Fachwissen zu jedem von ihnen zugreifen kann.

CrewAI: Vollständige Injektion in jeden Task-Prompt

CrewAI verfolgt den gegenteiligen Ansatz von Progressive Disclosure. Wenn ein Skill für einen Agenten aktiviert ist, wird sein vollständiger Inhalt in jeden Task-Prompt injiziert, den der Agent ausführt.

Wie es funktioniert

Skills in CrewAI sind eigenständige Verzeichnisse, jedes mit einer SKILL.md-Datei, die YAML-Frontmatter (Name, Beschreibung, Lizenz, Kompatibilität, erlaubte Tools) und einen Markdown-Body enthält. Das Skill-System unterscheidet zwischen Skills und Tools: Skills injizieren Anweisungen und Kontext, die beeinflussen, wie der Agent denkt, während Tools aufrufbare Funktionen für Aktionen bereitstellen.

Während der Agenten-Initialisierung ruft Agent.set_skills() die Funktion discover_skills() auf, um Skill-Verzeichnisse auf Metadatenebene zu scannen, und dann activate_skill(), um vollständige Skill-Bodies zu lesen. Zum Zeitpunkt der Task-Ausführung ruft _finalize_task_prompt() die Funktion format_skill_context() für jeden aktivierten Skill auf und hängt allen formatierten Skill-Inhalt an den Task-Prompt an.

Das LLM empfängt: [System-Nachricht] + [Task-Prompt + ALLE Skill-Bodies]

Token-Auswirkungen

CrewAI setzt eine Soft-Warnung bei 50.000 Zeichen pro Skill, aber kein hartes Limit. Die Dokumentation empfiehlt, Skills fokussiert und prägnant zu halten, da große Prompt-Injektionen die Aufmerksamkeit des Modells verwässern – eine echte Sorge angesichts der Forschung zu Context Rot.

Der Kompromiss ist einfach: Der Agent hat immer sein vollständiges Fachwissen verfügbar (hohe Zuverlässigkeit), aber die Token-Kosten skalieren linear mit der Anzahl der Skills pro Task (niedrige Effizienz). Für Agenten mit 1-2 fokussierten Skills funktioniert dies gut. Für Agenten, die breite Fähigkeitensets benötigen, wird es schnell teuer.

Keine taskübergreifende Persistenz

Jeder Task erhält eine frische Injektion. Es gibt keine Ansammlung von Skill-Inhalt über Tasks hinweg – was tatsächlich ein Feature ist, kein Bug. Es bedeutet, dass jeder Task mit einem sauberen Kontext beginnt und die Veralterungsprobleme vermeidet, die sitzungsbasierte Persistenz erzeugen kann.

LangChain Deep Agents: Agentengesteuertes Laden über SkillsMiddleware

LangChain Deep Agents implementiert ein ausgeklügeltes Middleware-basiertes Skill-System, bei dem der Agent selbst entscheidet, wann er vollständigen Skill-Inhalt lädt – ein echtes Progressive-Disclosure-Modell, bei dem der Agent die Aktivierung steuert.

Die drei Stufen

Stufe 1 (Index): SkillsMiddleware parst alle SKILL.md-Frontmatter beim Start und injiziert einen leichtgewichtigen Index in den System-Prompt. Dieser Index enthält nur Namen und Beschreibungen und kostet ungefähr 278 Tokens pro Skill gegenüber 3.302 Tokens für den vollständigen Inhalt.

Stufe 2 (Vollständiger Inhalt): Wenn der Agent bestimmt, dass ein Skill relevant ist, ruft er read_file() für den SKILL.md-Pfad des Skills auf. Dies ist ein regulärer Tool-Aufruf – das Framework injiziert den Body nicht; der Agent trifft eine bewusste Entscheidung, ihn zu laden. Der vollständige Inhalt gelangt als Tool-Ergebnis in den Konversationsverlauf.

Stufe 3 (Deep Dive): Begleitmaterialien, Referenzdokumente und Skripte werden nur gelesen, wenn der Agent sie explizit liest.

Token-Effizienz in der Praxis

Mit 12 Skills reduziert Progressive Disclosure den Kontext von ungefähr 30.000 Tokens (alle geladen) auf etwa 600 Tokens (nur Index), die auf 2.000-5.000 erweitert werden, wenn relevante Skills für eine bestimmte Aufgabe geladen werden. Das ist eine potenzielle Reduktion von 83-98% beim skill-bezogenen Token-Verbrauch.

Mehrere Skill-Quellen können geschichtet werden, und bei Namenskollisionen gewinnt die letzte Quelle. Dateien über 10 MB werden automatisch übersprungen.

Der Hauptunterschied zu Claude Code

Während Claude Code ein dediziertes Skill-Tool zur Auslösung des Ladens verwendet, nutzt Deep Agents das bestehende read_file-Tool des Agenten. Das bedeutet, der Lademechanismus ist transparent – der Agent liest Skill-Dateien genauso wie jede andere Datei. Der Nachteil ist, dass es kein spezielles Komprimierungsverhalten gibt: Skill-Inhalte, die in den Konversationsverlauf gelangen, unterliegen dem Standard-LangChain-Message-Trimming ohne Prioritätsbehandlung.

OpenAI Responses API und Agents SDK: Plattformverwaltetes verzögertes Laden

OpenAI implementiert Skill-Injektion durch zwei unterschiedliche, aber philosophisch übereinstimmende Mechanismen: den tool_search-Tool-Typ der Responses API und das ToolSearchTool des Agents SDK.

Responses API: tool_search

Der tool_search-Tool-Typ (verfügbar ab GPT-5.4+) ermöglicht Entwicklern, große Tool-Oberflächen bis zur Laufzeit zu verzögern. Drei Verzögerungsstrategien sind verfügbar:

• Individuelle Funktionsverzögerung: @function_tool(defer_loading=True) – das Modell sieht den Funktionsnamen und die Beschreibung, aber das Parameterschema wird verzögert. Spart Tokens auf Parameterebene.
• Namespace-Verzögerung: tool_namespace(name=..., description=..., tools=[...]) – gruppiert Funktionen unter einem einzelnen Namespace. Das Modell sieht nur den Namespace-Namen und die Beschreibung und spart deutlich mehr Tokens.
• MCP-Server-Verzögerung: HostedMCPTool(tool_config={..., "defer_loading": True}) – verzögert ganze MCP-Server-Tool-Oberflächen.

Wenn das Modell feststellt, dass es ein bestimmtes Tool benötigt, gibt es einen tool_search-Aufruf aus. Die API gibt 3-5 relevante Tool-Definitionen zurück, die am Ende des Kontextfensters injiziert werden, um das Prompt-Caching zu erhalten.

Agents SDK: ToolSearchTool

Das Agents SDK bietet ein programmatisches Äquivalent. Tool-Namespaces werden registriert, aber nicht geladen:

crm_tools = tool_namespace(
    name="crm",
    description="CRM management tools",
    tools=[...]
)
agent = Agent(tools=[*crm_tools, ToolSearchTool()])

Zur Laufzeit sieht der Agent nur Namespace-Namen. Er ruft ToolSearchTool("crm") auf, um die vollständigen Schemas zu entdecken und zu laden, und kann dann einzelne Tools innerhalb dieses Namespace aufrufen.

Keine anforderungsübergreifende Persistenz

Jede API-Anfrage ist unabhängig. Entdeckte Tools persistieren nicht über Aufrufe hinweg. Dies ist der zustandsloseste Ansatz in unserem Vergleich – sauber, vorhersagbar, erfordert aber eine Wiederentdeckung bei jeder Anfrage, wenn sich Tools ändern.

AutoGen Teachability: Semantisches Retrieval pro Runde

AutoGens Teachability-Fähigkeit verfolgt einen grundlegend anderen Ansatz als jedes andere Framework in diesem Vergleich. Statt statischen Skill-Inhalt zu injizieren, ruft sie dynamisch relevante “Memos” aus einer ChromaDB-Vektordatenbank bei jeder einzelnen Runde ab.

Die Retrieval-Schleife pro Runde

Teachability registriert einen Hook auf process_last_received_message, der jede eingehende Benutzernachricht abfängt, bevor der Agent sie verarbeitet:

1. Ein TextAnalyzerAgent extrahiert Schlüsselkonzepte aus der eingehenden Nachricht
2. Diese Konzepte werden verwendet, um ChromaDB abzufragen (standardmäßig mit Sentence Transformer Embeddings)
3. Die Top-K relevantesten Memos werden abgerufen (konfigurierbar über max_num_retrievals, Standard 10)
4. Abgerufene Memos werden an den Nachrichtentext angehängt, bevor der Agent ihn sieht

Wichtig: Die modifizierte Nachricht wird nicht in den gespeicherten Konversationsverlauf übernommen – nur die Originalnachricht wird gespeichert. Dies verhindert, dass sich Memo-Inhalte über Runden hinweg aufstauen.

Lernschleife

Nachdem das LLM geantwortet hat, analysiert ein zweiter Hook die Antwort auf neue Erkenntnisse:

1. TextAnalyzerAgent identifiziert neues Wissen in der Antwort
2. Neue Memos werden als Schlüssel-Wert-Paare extrahiert (Eingabetext -> Ausgabetext)
3. Diese Memos werden in ChromaDB gespeichert und stehen für zukünftige Runden und Sitzungen zur Verfügung

Dies erzeugt eine echte Lernschleife, in der der Agent im Laufe der Zeit Fachwissen ansammelt.

Sitzungsübergreifende Persistenz

AutoGen Teachability ist eine von nur drei Plattformen in unserem Vergleich (neben Voyager und DSPy), die Skills sitzungsübergreifend persistiert. Die ChromaDB-Datenbank liegt auf der Festplatte, was bedeutet, dass ein Agent am Montag aus Interaktionen lernen und dieses Wissen am Freitag anwenden kann.

Der recall_threshold-Parameter (Standard 1,5) steuert, wie ähnlich eine Nachricht einem gespeicherten Memo sein muss, damit es abgerufen wird, und reset_db kann den gesamten Speicher bei Bedarf löschen.

Token-Effizienz

Da nur relevante Memos pro Runde injiziert werden (typischerweise 3-5), sind die Token-Kosten natürlich begrenzt, unabhängig davon, wie groß die Memo-Datenbank wird. Ein Agent mit 10.000 gespeicherten Memos zahlt immer noch nur für die Handvoll, die für die aktuelle Runde am relevantesten sind.

Semantic Kernel: Plugin-Schemas als immer vorhandene Tool-Definitionen

Microsofts Semantic Kernel verfolgt einen unkomplizierten Ansatz: Plugins sind Sammlungen von KernelFunction-Objekten, die beim Kernel registriert werden, und deren Schemas werden dem LLM als Function-Calling-Tool-Definitionen zur Verfügung gestellt.

Zwei Injektionspfade

Function Calling: Wenn ToolCallBehavior.AutoInvokeKernelFunctions gesetzt ist, werden alle registrierten Funktionen dem LLM bei jeder API-Anfrage als verfügbare Tools gesendet. Das LLM entscheidet, welche es aufruft; Semantic Kernel übernimmt den Aufruf und die Ergebnisweiterleitung.

Prompt-Templates: Die Template-Syntax von Semantic Kernel ({{plugin.function}}, Handlebars oder Liquid) ermöglicht es, Funktionen inline während des Prompt-Renderings aufzurufen. Ergebnisse werden direkt in den Prompt-Text eingebettet, bevor er das LLM erreicht – eine Form der Eager Evaluation im Gegensatz zum Lazy Tool Calling.

Kein Progressive Disclosure

Das Schema jedes registrierten Plugins ist in jedem API-Aufruf enthalten. Es gibt kein eingebautes verzögertes Laden, keine Namespace-Gruppierung und keine bedarfsgesteuerte Aktivierung. Die Dokumentation empfiehlt ausdrücklich, nur die für ein bestimmtes Szenario benötigten Plugins zu importieren, um den Token-Verbrauch und Fehlaufrufe zu reduzieren.

Dies macht Semantic Kernel zu einer der vorhersagbarsten Plattformen – man weiß immer genau, worauf der Agent Zugriff hat – begrenzt aber die Skalierbarkeit. Ein Agent mit 50 registrierten Funktionen zahlt die vollen Schema-Kosten bei jedem einzelnen Aufruf.

Persistenz

Die Plugin-Registrierung ist pro Kernel-Instanz und im Arbeitsspeicher. Es gibt keinen eingebauten Mechanismus für sitzungsübergreifende Skill-Persistenz.

MetaGPT: Action-Templates innerhalb rollenbasierter SOPs

MetaGPT codiert Skills nicht als eigenständige Pakete, sondern als Action-Templates, die in Standard Operating Procedures (SOPs) eingebettet sind, die das Rollenverhalten steuern.

Rollen- und Action-Architektur

Jede Role in MetaGPT hat ein Persona-Präfix, das in Prompts injiziert wird, und einen Satz von Action-Klassen. Jede Action enthält einen LLM-Proxy, der über aask() aufgerufen wird, das natürlichsprachliche Prompt-Templates verwendet, um den LLM-Aufruf zu strukturieren.

Wenn Role._act() feuert, unterstützt es drei React-Modi:

• "react": Das LLM wählt dynamisch Actions in Think-Act-Schleifen
• "by_order": Actions werden sequentiell in einer vorbestimmten Reihenfolge ausgeführt
• "plan_and_act": Der Agent plant zuerst und führt dann Actions gemäß dem Plan aus

Schmales Injektionsfenster

Nur das Prompt-Template der aktuellen Action ist zu einem bestimmten Zeitpunkt aktiv. Der Agent sieht keine Templates für andere Actions – er sieht nur sein Rollen-Präfix plus den Kontext der spezifischen Action. Dies ist das schmalste Injektionsfenster aller von uns untersuchten Frameworks.

Kontext-Parsing-Funktionen innerhalb von Action-Klassen extrahieren relevante Informationen aus Eingaben, sodass jede Action eine kuratierte Teilmenge des verfügbaren Kontexts erhält, anstatt den vollständigen Konversationsverlauf.

Single-Turn-Persistenz

Das Template wird für jede Action-Ausführung frisch gerendert. Es gibt keine Ansammlung oder sitzungsübergreifende Persistenz. Dies hält jede Action fokussiert, bedeutet aber, dass der Agent innerhalb eines einzelnen Workflows nicht auf zuvor geladenem Skill-Inhalt aufbauen kann.

Voyager: Embedding-basiertes Skill-Retrieval für lebenslanges Lernen

Voyager, der Minecraft-Erkundungsagent von NVIDIA und Caltech, implementiert eine der elegantesten Skill-Injektionsarchitekturen: eine wachsende Bibliothek verifizierter Programme, die nach Embedding-Ähnlichkeit abgerufen werden.

Die Skill-Bibliothek

Wenn Voyager Code schreibt, der die Selbstverifikation besteht (das generierte Mineflayer-JavaScript tatsächlich im Spiel funktioniert), werden der Code und sein Dokumentationsstring in einer Vektordatenbank gespeichert. Das Docstring-Embedding wird zum Retrieval-Schlüssel.

Abruf pro Aufgabe

Bei jeder neuen Aufgabe, die vom automatischen Curriculum vorgeschlagen wird:

1. Die Aufgabenbeschreibung und das Umgebungsfeedback werden eingebettet
2. Kosinus-Ähnlichkeitssuche über alle gespeicherten Skill-Embeddings
3. Die Top-5 relevantesten Skills werden abgerufen
4. Der abgerufene Skill-Code wird als Few-Shot-Beispiele in den Prompt des Action-Agenten eingefügt

Der Prompt sieht so aus:

You are a Minecraft bot. Here are some relevant skills you've learned:

// Skill: mineWoodLog
async function mineWoodLog(bot) { ... }

// Skill: craftPlanks
async function craftPlanks(bot) { ... }

Now write code to: build a wooden pickaxe

Der generierte Code kann abgerufene Skills namentlich aufrufen, was kompositionellen Skill-Aufbau ermöglicht – komplexe Verhaltensweisen, die aus einfacheren, verifizierten Primitiven zusammengesetzt werden.

Lebenslange Persistenz

Die Skill-Bibliothek ist der Kern-Mechanismus für “lebenslanges Lernen”. Sie wächst über die gesamte Lebensdauer des Agenten, und neue Skills bauen auf alten auf. Anders als bei den meisten Frameworks, wo Skills von Menschen erstellt werden, werden Voyagers Skills vom Agenten selbst generiert, verifiziert und gespeichert.

Die Token-Kosten sind natürlich begrenzt: Unabhängig davon, ob die Bibliothek 50 oder 5.000 Skills enthält, zahlt jede Aufgabe nur für die 5 relevantesten Abrufe.

DSPy: Kompilierte Few-Shot-Beispiele als eingefrorene Skills

DSPy verfolgt einen radikal anderen Ansatz als jedes andere Framework. Statt Skills zur Laufzeit zu injizieren, kompiliert DSPy optimale Few-Shot-Demonstrationen offline und baut sie dauerhaft in Modul-Prompts ein.

Der Kompilierungsprozess

Zwei Haupt-Optimizer übernehmen die Kompilierung:

BootstrapFewShot: Verwendet ein Teacher-Modul, um Traces durch das Programm zu generieren. Traces, die eine benutzerdefinierte Metrik bestehen, werden als Demonstrationen beibehalten. Jedes dspy.Predict-Modul innerhalb des Programms erhält seinen eigenen kuratierten Satz von Demonstrationen.

MIPROv2 (Multi-prompt Instruction Proposal Optimizer v2): Ein dreiphasiger Prozess:

1. Bootstrap: Generierung von Kandidaten-Demonstrationssätzen
2. Propose: Generierung von Kandidaten-Instruktionstexten, die sowohl die Datenverteilung als auch die Demonstrationen berücksichtigen
3. Search: Bayessche Optimierung über den kombinierten Raum von Instruktionen x Demonstrationen über alle Module

Parameter wie max_bootstrapped_demos (generierte Beispiele) und max_labeled_demos (aus Trainingsdaten) steuern, wie viele Beispiele im Prompt jedes Moduls landen.

Nach der Kompilierung fixiert

Einmal kompiliert, werden Demonstrationen im demos-Attribut jedes Predict-Moduls gespeichert und bei jedem LLM-Aufruf in den Prompt formatiert. Sie ändern sich zur Laufzeit nicht – der “Skill” ist eingefroren.

Das bedeutet, DSPy-Skills sind die vorhersagbarsten in unserem Vergleich: Token-Kosten sind nach der Kompilierung bekannt, es gibt keine Varianz zwischen Runden, und der Agent sieht immer die gleichen Demonstrationen. Der Nachteil ist Unflexibilität – um Skills zu ändern, muss man neu kompilieren.

Persistenz

Kompilierte Programme werden als JSON serialisiert, einschließlich aller Demonstrationen. Sie sind vollständig persistent und sitzungsübergreifend ladbar, was DSPy zu einem der langlebigsten Skill-Speichermechanismen macht.

SuperAGI: Toolkit-basierte Vorab-Registrierung

SuperAGI verwendet ein traditionelles Toolkit-Muster, bei dem alle Tools bei der Agenten-Initialisierung registriert werden.

Jedes Toolkit erweitert BaseToolkit mit:

• name- und description-Attributen
• get_tools()-Methode, die eine Liste von BaseTool-Instanzen zurückgibt
• get_env_keys() für erforderliche Umgebungsvariablen

Toolkits werden über SuperAGIs Tool-Manager aus GitHub-Repositories installiert. Bei der Agenten-Initialisierung gibt BaseToolkit.get_tools() alle Tools zurück, und deren vollständige Schemas werden dem LLM als Function-Calling-Definitionen zur Verfügung gestellt.

Es gibt kein verzögertes Laden, kein Progressive Disclosure und keine Filterung pro Runde. Das Schema jedes registrierten Tools ist in jedem Aufruf vorhanden. Dies ist das einfachste Injektionsmodell und funktioniert gut für Agenten mit fokussierten, kleinen Tool-Sets, skaliert aber nicht für Agenten, die Dutzende von Fähigkeiten benötigen.

CAMEL-AI: ChatAgent Tool-Registrierung

CAMEL-AI folgt einem ähnlichen Vorab-Registrierungsmuster. Tools aus verschiedenen Toolkits (z.B. MathToolkit, SearchToolkit) werden als Liste an ChatAgent(tools=[...]) bei der Initialisierung übergeben.

Das Framework betont, dass benutzerdefinierte Funktionen klare Argumentnamen und umfassende Docstrings benötigen, damit das Modell die Verwendung verstehen kann – das Tool-Schema ist der einzige “Skill”-Inhalt, den das Modell sieht. Es gibt keinen separaten Mechanismus zur Instruktionsinjektion.

Neuere Ergänzungen umfassen MCP-Unterstützung (Model Context Protocol) über MCPToolkit, die es ChatAgent ermöglicht, sich mit MCP-Servern zu verbinden und externe Tools zu registrieren. Dies erweitert die verfügbare Tool-Oberfläche, ändert aber nicht das Injektionsmodell – alle entdeckten MCP-Tools werden weiterhin vorab registriert.

Plattformübergreifender Vergleich

Wann Skills injiziert werden

Persistenzmodelle

Überleben bei Kontextkomprimierung

Das Progressive-Disclosure-Muster

Der bedeutendste architektonische Trend über diese Plattformen hinweg ist die Übernahme von Progressive Disclosure – ein Konzept aus dem UI-Design, bei dem Informationen schrittweise nach Bedarf enthüllt werden.

Warum Progressive Disclosure wichtig ist

Ein naiver Ansatz zur Skill-Injektion – alles vorab laden – erzeugt zwei Probleme:

1. Token-Verschwendung: Die meisten Skills sind für die meisten Runden nicht relevant. 20 vollständige Skill-Bodies zu laden, wenn nur 1-2 pro Runde benötigt werden, verschwendet über 90% der skill-bezogenen Tokens.
2. Aufmerksamkeitsverwässerung: Forschung zu Context Rot zeigt, dass LLMs schlechter abschneiden, wenn ihr Kontext große Mengen irrelevanter Informationen enthält. Mehr Skills im Kontext können die Qualität der Skill-Anwendung tatsächlich verringern.

Progressive Disclosure löst beide Probleme, indem ein leichtgewichtiger Index verfügbarer Skills beibehalten wird, während vollständiger Inhalt nur bei Bedarf geladen wird.

Implementierungsvarianten

Claude Code verwendet ein dediziertes System: Skill-Metadaten in System-Reminder-Nachrichten, ein Skill-Tool für die Aktivierung und ToolSearch für verzögerte Tool-Schemas. Das Framework verwaltet die Injektion automatisch mit prioritätsbasierter Komprimierung.

LangChain Deep Agents nutzt die bestehende Dateilese-Fähigkeit des Agenten: SkillsMiddleware injiziert den Index, und der Agent lädt vollständigen Inhalt über read_file(). Dies ist transparenter, bietet aber weniger Optimierung auf Framework-Ebene.

OpenAI Responses API verwendet Namespace-basierte Gruppierung mit plattformverwalteter Suche: Tool-Namespaces bieten allgemeine Beschreibungen, und tool_search gibt relevante Schemas zurück. Die Plattform übernimmt die Suchlogik vollständig.

Token-Einsparungen in der Praxis

Die Zahlen sind überzeugend. Mit 12 Skills:

• Always-On-Injektion (CrewAI/SuperAGI-Stil): ~30.000 Tokens
• Progressive Disclosure nur Index: ~600 Tokens
• Index + 2 aktivierte Skills: ~2.000-5.000 Tokens

Das ist eine Reduktion von 83-98% beim skill-bezogenen Token-Verbrauch pro Runde. Über eine lange Sitzung mit Hunderten von Runden summieren sich die Einsparungen dramatisch.

Architekturmuster und Kompromisse

Über alle 11 Plattformen hinweg ergeben sich vier unterschiedliche Architekturmuster:

Muster 1: Always-On-Injektion

Verwendet von: CrewAI, SuperAGI, CAMEL-AI, Semantic Kernel

Wie es funktioniert: Vollständiger Skill-Inhalt oder Tool-Schemas sind in jedem LLM-Aufruf vorhanden.

Vorteile:

• Maximale Zuverlässigkeit – der Agent hat immer sein vollständiges Fachwissen verfügbar
• Einfachste Implementierung – keine Aktivierungslogik erforderlich
• Vorhersagbare Token-Kosten – jede Runde gleich

Nachteile:

• Token-Kosten skalieren linear mit der Anzahl der Skills
• Aufmerksamkeitsverwässerung bei vielen Skills
• Skaliert nicht über ~5-10 Skills pro Agent hinaus

Am besten geeignet für: Fokussierte Agenten mit 1-3 Kern-Skills, die immer relevant sind.

Muster 2: Progressive Disclosure

Verwendet von: Claude Code, LangChain Deep Agents, OpenAI Responses API/Agents SDK

Wie es funktioniert: Leichtgewichtige Metadaten immer vorhanden; vollständiger Inhalt wird bei Bedarf geladen.

Vorteile:

• Skaliert auf Dutzende oder Hunderte verfügbare Skills
• Minimale Token-Kosten, wenn Skills nicht benötigt werden
• Erhält den Prompt-Cache, wenn vollständige Schemas am Ende angehängt werden

Nachteile:

• Agent könnte den Hinweis verpassen, einen relevanten Skill zu aktivieren
• Zusätzliche Latenz durch den Aktivierungsschritt
• Komplexere Framework-Implementierung

Am besten geeignet für: Allzweck-Agenten, die Zugang zu vielen Fähigkeiten benötigen, aber nur wenige pro Aufgabe nutzen.

Muster 3: Semantisches Retrieval

Verwendet von: AutoGen Teachability, Voyager

Wie es funktioniert: Vektordatenbank-Abfragen liefern relevante Skills/Wissen basierend auf semantischer Ähnlichkeit zum aktuellen Kontext.

Vorteile:

• Natürlich begrenzte Token-Kosten unabhängig von der Bibliotheksgröße
• Inhaltsrelevanz verbessert sich im Laufe der Zeit, wenn die Bibliothek wächst
• Sitzungsübergreifendes Lernen und Akkumulation
• Keine explizite Aktivierung erforderlich – Relevanz wird automatisch berechnet

Nachteile:

• Retrieval-Qualität hängt von der Qualität des Embedding-Modells ab
• Risiko, veraltete oder subtil falsche Informationen abzurufen
• Erfordert Vektordatenbank-Infrastruktur
• Weniger vorhersagbar – verschiedene Runden laden unterschiedliche Inhalte

Am besten geeignet für: Agenten, die aus Erfahrung lernen und im Laufe der Zeit Domänenwissen ansammeln müssen.

Muster 4: Kompilierte/statische Injektion

Verwendet von: DSPy, MetaGPT

Wie es funktioniert: Skills werden in festen Prompt-Inhalt kompiliert (DSPy) oder über starre Action-Templates aktiviert (MetaGPT).

Vorteile:

• Vorhersagbarstes Verhalten – jedes Mal der gleiche Inhalt
• Optimierung kann offline durchgeführt werden (DSPys Kompilierung)
• Kein Laufzeit-Overhead für Skill-Auswahl
• Nachweislich effektiv für klar definierte, wiederholbare Aufgaben

Nachteile:

• Unflexibel – Skill-Änderungen erfordern Neukompilierung (DSPy) oder Code-Änderungen (MetaGPT)
• Kann sich nicht an neuartige Situationen außerhalb der kompilierten Beispiele anpassen
• DSPys Kompilierungsprozess selbst erfordert viele LLM-Aufrufe

Am besten geeignet für: Produktionspipelines mit klar definierten Aufgaben, bei denen Zuverlässigkeit wichtiger ist als Flexibilität.

Praktische Auswirkungen für Agenten-Entwickler

Die Wahl des richtigen Musters

Die richtige Skill-Injektionsarchitektur hängt vom Profil Ihres Agenten ab:

Wenn Ihr Agent eine enge, klar definierte Rolle hat (z.B. ein Code-Review-Bot, ein Kundensupport-Agent für ein Produkt), ist die Always-On-Injektion (CrewAI/SuperAGI-Muster) am einfachsten und zuverlässigsten. Die Token-Kosten von 2-3 immer vorhandenen Skills sind überschaubar, und Sie vermeiden die Komplexität der Aktivierungslogik.

Wenn Ihr Agent breite Fähigkeiten benötigt, aber nur wenige pro Interaktion nutzt (z.B. ein Entwicklerassistent, ein Allzweck-Automatisierungsagent), ist Progressive Disclosure (Claude Code/Deep Agents-Muster) der klare Gewinner. Die Token-Einsparungen von 83-98% im großen Maßstab sind zu signifikant, um sie zu ignorieren.

Wenn Ihr Agent aus Interaktionen lernen und sich verbessern muss (z.B. ein persönlicher Assistent, ein Domänenexperte, der Wissen ansammelt), bietet semantisches Retrieval (AutoGen Teachability-Muster) die Lernschleife, die anderen Mustern fehlt. Stellen Sie nur sicher, dass Sie Qualitätskontrollen für das haben, was in die Wissensbasis gelangt.

Wenn Ihr Agent klar definierte Pipelines ausführt (z.B. Datenverarbeitung, Berichterstellung, standardisierte Workflows), bietet kompilierte Injektion (DSPy-Muster) das vorhersagbarste, optimierteste Verhalten.

Der hybride Ansatz

Für produktive Agenten-Teams, bei denen Agenten sofort einsatzbereit sein müssen, empfehlen wir einen hybriden Ansatz:

Kern-Skills (1-2 pro Agent, die ihr primäres Domänenwissen definieren): immer in den System-Prompt injiziert, im CrewAI-Stil. Dies sind unverzichtbare Fähigkeiten, die der Agent bei jeder Runde benötigt.

Erweiterte Skills (zusätzliche Fähigkeiten, die der Agent möglicherweise benötigt): nur Metadaten im System-Prompt, geladen über einen Such-/Lademechanismus bei Bedarf, im Deep Agents-Stil. Diese erweitern den Fähigkeitenumfang des Agenten, ohne Token-Kosten zu verursachen, wenn sie nicht relevant sind.

Gelerntes Wissen (angesammeltes Domänenwissen): in einer Vektordatenbank gespeichert und semantisch pro Runde abgerufen, im AutoGen-Stil. Dies ermöglicht dem Agenten, sich im Laufe der Zeit zu verbessern, ohne manuelle Skill-Erstellung.

Diese geschichtete Architektur passt natürlich dazu, wie ein System-Prompt aufgebaut wird: Datum -> Persona -> Systemanweisungen -> Kern-Skills -> Skill-Index -> Rollen-/Team-Kontext. Die Kern-Skills und der Index verursachen vorhersagbare, überschaubare Token-Kosten, während die vollständigen Skill-Bodies nur bei Bedarf erscheinen.

Best Practices für Token-Budgets über Frameworks hinweg

Unabhängig davon, welches Injektionsmuster Sie verwenden, gelten diese Token-Management-Strategien universell:

Cache-freundliche Reihenfolge

Stapeln Sie unveränderlichen Kontext (Systemanweisungen, Tool-Schemas) am Anfang des Prompts. Bei Anbietern, die Prompt-Caching unterstützen, kosten gecachte Tokens 75% weniger. Claude Code und OpenAI injizieren beide entdeckte Tool-Schemas am Ende des Kontexts, speziell um Cache-Treffer auf dem statischen Präfix zu erhalten.

Auslagerung

Fassen Sie Tool-Antworten zusammen, anstatt vollständige Ergebnisse im Kontext zu behalten. Speichern Sie die vollständigen Daten in externen Referenzen, die der Agent bei Bedarf lesen kann. Dies ist besonders wichtig für Agenten, die viele Tool-Aufrufe pro Sitzung machen.

Reduktion

Komprimieren Sie den Konversationsverlauf durch Zusammenfassung. Extrahieren Sie Schlüsselfakten aus langen Austauschen in verdichtete Darstellungen. Jedes Framework mit sitzungsbasierter Persistenz profitiert von aggressivem Verlaufsmanagement.

Retrieval statt Vorladen

Rufen Sie relevante Informationen dynamisch zur Laufzeit ab, anstatt alles vorab zu laden. Dies gilt für Skills, Wissensbasen und sogar den Konversationsverlauf. Studien zeigen, dass dies die Prompt-Größen um bis zu 70% reduzieren kann.

Isolation

Verwenden Sie Sub-Agenten für spezifische Aufgaben, damit der Kontext jedes Agenten fokussiert bleibt. Anstatt einem Agenten 20 Skills zu geben, erstellen Sie ein Team von 5 Agenten mit jeweils 4 Skills. Jeder Agent behält ein schlankes Kontextfenster, und das Team deckt gemeinsam den gesamten Fähigkeitenumfang ab.

Fazit

Die Art und Weise, wie KI-Agenten-Frameworks Skills in den Kontext injizieren, ist eine der folgenreichsten architektonischen Entscheidungen im Agenten-Design – wird aber selten auf diesem Detaillierungsgrad diskutiert.

Das Feld konvergiert eindeutig auf Progressive Disclosure als bevorzugtes Muster für Allzweck-Agenten, wobei Claude Code, LangChain Deep Agents und OpenAI alle unabhängig voneinander zu ähnlichen dreistufigen Architekturen gelangt sind. Gleichzeitig bedienen spezialisierte Muster wie semantisches Retrieval (AutoGen, Voyager) und kompilierte Injektion (DSPy) wichtige Nischen, die Progressive Disclosure allein nicht abdeckt.

Für Praktiker, die heute Agentensysteme bauen, ist die zentrale Erkenntnis, dass Skill-Injektion kein Einheitsansatz ist. Der richtige Ansatz hängt von der Rolle Ihres Agenten ab, der Anzahl der benötigten Skills, ob er im Laufe der Zeit lernen muss, und Ihrer Toleranz für Kompromisse zwischen Token-Kosten und Zuverlässigkeit.

Die robustesten Produktionssysteme werden wahrscheinlich mehrere Muster kombinieren – Always-On für Kernfähigkeiten, Progressive Disclosure für erweiterte Skills und semantisches Retrieval für angesammeltes Wissen – und so Agenten schaffen, die sowohl effizient als auch fachkundig sind.