Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Auf der vorherigen Seite wurde gezeigt, wie Middleware die Ausführungspipeline des Agents mit querschnittlichen Anliegen – Protokollierung, Leitplanken, Fehlerbehandlung – umschließt, ohne die Kernlogik des Agents zu berühren. Middleware befasst sich damit, wie der Agent läuft, aber nicht was der Agent weiß. Bisher stammt das Wissen des Agenten aus zwei Quellen: aus seinen Trainingsdaten und aus dem, was der Benutzer in der aktuellen Gesprächsrunde sagt.
Das ist ein Problem. Ein nützlicher Agent benötigt mehr als das. Es muss sich erinnern, was der Benutzer vor drei Runden gesagt hat, die Vorlieben des Benutzers kennen oder relevante Fakten aus einer Wissensbasis abrufen – alles , bevor er mit dem Generieren einer Antwort beginnt. Tools können Informationen abrufen, aber sie sind reaktiv: Das Modell muss entscheiden, sie aufzurufen. Wenn das Modell nicht erkennt, dass es Kontext benötigt, wird es nicht danach gefragt.
Kontextanbieter lösen dies. Sie sind Komponenten, die vor und nach jedem Agentaufruf ausgeführt werden, um proaktiv relevante Informationen in das Kontextfenster einzufügen und optional den Zustand aus der Antwort zu extrahieren, um ihn für die zukünftige Verwendung zu speichern. Sie geben Ihrem Agent Arbeitsspeicher, Personalisierung und Zugriff auf externes Wissen – ohne die Anweisungen oder den Code des Agents zu ändern.
Wann Sie dies verwenden sollten
Fügen Sie Ihrem Agent Kontextanbieter hinzu, wenn:
- Der Agent benötigt Konversationsverlauf – er sollte sich merken, was in früheren Dialogen gesagt wurde, nicht nur die aktuelle Nachricht.
- Sie möchten benutzerspezifische Daten – Profile, Einstellungen, Kontodetails oder Sitzungsstatus – einfügen, damit der Agent seine Antworten personalisieren kann.
- Sie benötigen Retrieval-Augmented Generation (RAG) – das automatische Abrufen relevanter Dokumente oder Fakten aus einer Wissensbasis vor jeder Antwort.
- Der Agent erfordert dynamische Anweisungen – Kontext, der sich zwischen Aufrufen basierend auf der Tageszeit, dem Standort des Benutzers oder anderen Laufzeitbedingungen ändert.
- Sie möchten die Datenbeschaffung von der Agentlogik entkoppeln – der Agent muss nicht wissen , woher der Kontext kommt, nur dass er verfügbar ist.
Warum nicht nur Tools verwenden?
Tools und Kontextanbieter bieten sowohl Agents Zugriff auf externe Informationen, aber sie funktionieren grundsätzlich auf unterschiedliche Weise:
| Aspect | Tools | Kontextanbieter |
|---|---|---|
| Auslöser | Reaktiv – das Modell entscheidet, wann ein Tool aufgerufen werden soll | Proaktiv – wird automatisch vor jedem Aufruf ausgeführt |
| Control | Modellgesteuert: Das Modell wählt das Tool, wann und mit welchen Argumenten | Entwicklergesteuert: Sie entscheiden, welcher Kontext immer verfügbar ist |
| Sichtbarkeit | Das Modell muss wissen, dass ein Tool vorhanden ist und beurteilt, dass es relevant ist. | Kontext wird transparent eingefügt – das Modell sieht ihn als Teil der Eingabeaufforderung. |
| Anwendungsfall | On-Demand-Aktionen und -Nachschlagevorgänge: "Web durchsuchen", "Datenbank abfragen" | Immer vorhandener Kontext: Unterhaltungsverlauf, Benutzerprofile, vorab geladenes Wissen |
| Tokenkosten | Token, die nur ausgegeben werden, wenn das Tool aufgerufen wird | Tokens, die bei jedem Aufruf verbraucht werden (der Kontext befindet sich immer im Prompt) |
Keines ist streng besser. Viele Agents verwenden beide: Kontextanbieter für Informationen, die immer vorhanden sein sollten (Verlauf, Benutzerprofil, Kernwissen) und Tools für Informationen, die der Agent bei Bedarf abrufen soll (Livesuchergebnisse, Datenbankabfragen, API-Aufrufe).
Tip
Eine gute Faustregel: Wenn der Agent bei jeder Ausführung diese Informationen enthalten soll, verwenden Sie einen Kontextanbieter. Wenn der Agent es nur dann abrufen soll, wenn es relevant ist, verwenden Sie ein Tool.
Funktionsweise von Kontextanbietern
Kontextanbieter nehmen an einem zweistufigen Lebenszyklus um jeden Agentaufruf teil:
┌──────────────────────────────────────────────────────────────┐
│ Caller: agent.run("What's the return policy?") │
└──────────────┬───────────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────┐
│ BEFORE RUN — each context provider injects context │
│ │
│ • History provider loads past conversation messages │
│ • Memory provider retrieves relevant facts/preferences │
│ • RAG provider searches knowledge base and adds results │
│ • Custom provider injects user profile, time, location │
└──────────────┬───────────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────┐
│ Agent core — model sees original input + all injected │
│ context and generates a response │
└──────────────┬───────────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────┐
│ AFTER RUN — each context provider processes the response │
│ │
│ • History provider saves the new messages │
│ • Memory provider extracts facts to remember for later │
│ • Custom provider updates session state │
└──────────────────────────────────────────────────────────────┘
Wichtige Punkte:
- Kontextanbieter werden automatisch ausgeführt. Sie registrieren sie einmal beim Erstellen des Agents. Danach nehmen sie an jedem Aufruf ohne zusätzlichen Code teil.
- Mehrere Anbieter verfassen etwas gemeinsam. Sie können mehrere Kontextanbieter registrieren – einen Verlaufsanbieter, einen RAG-Anbieter und einen benutzerdefinierten Anbieter – und alle tragen zum gleichen Kontextfenster bei. Ihre Beiträge werden in Registrierungsreihenfolge zusammengefasst.
- Anbieter haben zwei Hooks. Der Vor-Hook fügt kontext (Nachrichten, Anweisungen, Tools) in die Eingabeaufforderung ein. Der After-Hook verarbeitet die Antwort – Speichern von Nachrichten, Extrahieren von Erinnerungen oder Aktualisieren des Zustands.
- Die Anbieter sind sitzungsabhängig. Kontextanbieter erhalten die aktuelle Sitzung, sodass sie Daten laden und speichern können, die auf eine bestimmte Unterhaltung festgelegt sind. Informationen zur Funktionsweise der Sitzungsverwaltung finden Sie unter "Sitzungen ".
Tip
Eine detaillierte Ansicht der Position, an der sich Kontextanbieter in der vollständigen Agent-Ausführungspipeline befinden – neben Middleware und dem Chatclient – finden Sie in der Agentpipelinearchitektur.
Verwalten des Kontextfensters
Jeder Kontext, den Sie injizieren, verwendet Token aus dem Kontextfenster des Modells. Die Geschichte wächst mit jeder Drehung. RAG-Ergebnisse fügen Dokumentblöcke hinzu. Benutzerprofile fügen Metadaten hinzu. Wenn die Gesamtmenge den Grenzwert des Modells überschreitet, werden die ältesten oder am wenigsten relevanten Informationen abgeschnitten, wobei möglicherweise wichtiger Kontext verloren geht.
Die Verwaltung von Kontextfenstern ist bei der Verwendung von Kontextanbietern von entscheidender Bedeutung: Komprimierungsstrategien fassen den älteren Verlauf zusammen oder kürzen sie, um innerhalb von Tokengrenzen zu bleiben, während wichtige Informationen beibehalten werden. Siehe Komprimierung.
Tip
Praktische Erfahrungen mit Speicher- und Kontextanbietern finden Sie in Schritt 4: Arbeitsspeicher im Lernprogramm "Erste Schritte".
Important
Es wird nicht empfohlen, ein sehr langes Kontextfenster beizubehalten, da die Leistung des Modells beeinträchtigt werden kann, wenn das Kontextfenster wächst. Wenn der Agent Leistungsverlust erfährt, sollten Sie erwägen, Kompaktierungsstrategien zu verwenden, um die Kontextgröße zu verringern.
Überlegungen
| Consideration | Details |
|---|---|
| Tokenbudget | Jeder eingefügte Kontext verwendet Token. Überwachen Sie die Gesamtkontextgröße sorgfältig – insbesondere bei der Kombination mehrerer Anbieter. Wenn der Kontext unbegrenzt wird, werden wichtige Informationen unbemerkt abgeschnitten. |
| Abruflatenz | Kontextanbieter, die externe Dienste (Datenbanken, Suchindizes, APIs) abfragen, fügen jedem Aufruf Latenz hinzu. Verwenden Sie Zwischenspeicherung, Verbindungspooling und asynchrone Vorgänge, um den Abruf schnell zu halten. |
| Relevance | Das Injizieren irrelevanter Kontext verschwendet nicht nur Token – es kann die Reaktionen des Modells aktiv beeinträchtigen, indem das Signal verdünnt wird. Stellen Sie sicher, dass Ihre Anbieter fokussierte, relevante Informationen einfügen. |
| Veralterung | Zwischengespeicherter oder vorinstallierter Kontext kann veraltet werden. Planen Sie Anbieter so, dass sie Daten in den geeigneten Intervallen aktualisieren, und überlegen Sie, ob leicht veraltete Kontexte für Ihren Anwendungsfall akzeptabel sind. |
| Kompositierbarkeit | Wenn mehrere Anbieter zu demselben Kontextfenster beitragen, können ihre Beiträge auf unerwartete Weise interagieren. Testen Sie Anbieter, nicht nur einzeln, um sicherzustellen, dass der kombinierte Kontext sinnvoll ist. |
Nächste Schritte
Da Ihr Agent nun Über Tools, Fähigkeiten, Middleware und Kontextanbieter verfügt, ist der nächste Schritt Agents als Tools – das Verfassen von Agents durch die Verwendung eines Agents als Tool für einen anderen, wodurch Spezialisierung und Delegierung ermöglicht werden.
Gehen Sie tiefer:
- Referenz zu Kontextanbietern – integrierte und benutzerdefinierte Anbietermuster
- Übersicht über Unterhaltungen und Speicher – Sitzungen, Verlauf und Speicher
- RAG – Retrieval Augmented Generation-Muster
- Komprimierung – Verwalten der Größe des Kontextfensters
- Speicher – Beibehalten von Unterhaltungsdaten
- Agentpipelinearchitektur – Wie Kontextanbieter in die Ausführungspipeline passen
- Schritt 4: Arbeitsspeicher – praktisches Lernprogramm