Context Engineering beginnt mit Retrieval

Die wichtigsten Punkte

• Agents arbeiten mit einem begrenzten Kontextfenster, und der Informationsabruf scheitert auf drei Arten: ineffiziente Suche, zu viel Kontext auf einmal und irrelevanter oder veralteter Kontext.
• Das Deep-Agents-Harness hält Suchen ab Werk klein. Die integrierten Filesystem-Tools suchen, bevor sie lesen: glob findet Dateinamen, grep findet passende Zeilen, und read_file liest immer nur eine Seite. Überdimensionierte Tool-Ergebnisse werden ausgelagert: das vollständige Ergebnis wird in Dateien gespeichert, aber der Agent erhält nur den Pfad und eine Vorschau.
• Verwenden Sie für eigene Suchtools (wie RAG) das Muster „retrieve, offload, delegate“: Ergebnisse in Dateien speichern, die Pfade zurückgeben und Subagents die Dateien lesen lassen. Der Haupt-Agent sieht nur, was relevant ist.

Stellen Sie sich vor, Sie legen eine offene Buchprüfung ab: Sie haben technisch gesehen alle Antworten, aber irgendwie macht genau das die richtige noch schwerer zu finden.

• Wo fangen Sie überhaupt an zu suchen?
• Woher wissen Sie, dass Ihre Quellen korrekt sind?
• Wie optimieren Sie Ihre Zeit, damit Sie nicht Ihre gesamte Energie auf redundante Suchen verschwenden?

Die richtigen Informationen effizient zu finden, ist gar nicht so einfach.

Gibt man einem Agenten eine Frage, befindet er sich in einer ähnlichen Lage: Er hat ein begrenztes Kontextfenster und muss daher wie wir Menschen Informationen abrufen um bestimmte Aufgaben zu erledigen (statt alles auswendig zu kennen). Bei der Suche haben Agenten mit folgenden Problemen zu kämpfen:

• Ineffiziente Suche: jede Suche kostet Tokens und Zeit. Ein Agent, der ungeschickt sucht (z. B. jede Datei öffnet, nur um zu sehen, was drinsteht, oder dieselbe Abfrage immer wieder umformuliert), kann sein Kontextfenster mit Suchergebnissen füllen, bevor er etwas Nützliches findet.
• Zu viel Kontext auf einmal: eine einzige Suche, die einen vollständigen Datenexport oder ein Dutzend Dokumente ausgießt, füllt das Kontextfenster mit einem Schlag und lässt keinen Raum mehr für die eigentliche Arbeit.
• Irrelevanter oder veralteter Kontext: veraltete oder themenfremde Informationen können für ein Modell genauso überzeugend wirken wie die richtige Antwort. Sobald sie im Kontextfenster stehen, baut der Agent möglicherweise darauf auf (und der Fehler pflanzt sich in jeden folgenden Schritt fort).

Zum Glück stehen einem Agenten mehrere Techniken zur Verfügung, mit denen er die korrekten Informationen abrufen kann. Es ist die Aufgabe eines Agent Harness diese Techniken strategisch einzusetzen, um dem Modell den richtigen Kontext zur richtigen Zeit für die jeweilige Aufgabe zu liefern.

Dieser Blog behandelt die Herausforderungen beim Agent-Retrieval (das Finden und Einholen genau der Informationen, die für die jeweilige Aufgabe nötig sind), die Techniken, die uns zu ihrer Bekämpfung zur Verfügung stehen, und wie man diese beim Entwurf eines Agent Harness im Blick behält (am Beispiel des Deep-Agents-Harness von LangChain ).

Weitere Informationen zum Verwalten des Kontexts, sobald er sich im Kontextfenster befindet, finden Sie in diesem Blogbeitrag zu Context Engineering.

Unser Beispiel: ein Competitive-Analysis-Agent

Sehen wir uns an, wie dies in einem realen Anwendungsfall angewendet werden kann: einem Competitive-Analysis-Agent. Jeden Montag recherchiert ein Agent hunderte Wettbewerber und verfasst einen Bericht nach der Vorlage des Teams. Er muss:

• die Notizen der letzten Woche zu Unternehmen A finden
• eine bestimmte Umsatzzahl in einem riesigen Marktdatenexport nachschlagen
• ein Newsarchiv nach allem Neuen durchsuchen

Jedes davon ist eine andere Art von Retrieval und stößt daher auf unterschiedliche Probleme. Wir haben unseren Agenten mit dem Deep Agents harness gebaut, sodass es einige Techniken gibt, die wir sofort anwenden können, um diese Probleme zu minimieren.

1. Ineffiziente Suche

Unser Agent muss für jeden Wettbewerber drei Dinge finden. Wenn jeder Vorgang ein Dutzend Versuche benötigt (Dateien öffnen, nur um zu sehen, was darin steht, oder eine Suche umformulieren, weil die Quelle andere Wörter verwendet), füllt sich sein Kontextfenster mit fehlgeschlagenen Suchen, bevor er auch nur ein Wort des Berichts schreibt.

Deshalb ist die beste Suche die, die der Agent nicht wiederholen muss – und das bedeutet, das richtige Werkzeug für jede Aufgabe zu verwenden.

Beginnen Sie mit den integrierten Dateisystem-Tools

Eine der häufigsten Möglichkeiten für einen Agenten, Informationen zu durchsuchen, ist ein Dateisystem. Wenn unser Agent jedoch jede Datei öffnet, um zu sehen, was darin steht, sucht er sehr ineffizient: Jede gelesene Datei landet in seinem Kontextfenster, sodass es allein durch das Nachsehen voll laufen kann.

Ein besserer Ansatz ist, zunächst Namen und Schlüsselwörter zu prüfen (so wie man bei einer offenen Buchprüfung den Index eines Buches überfliegt, statt jede Seite zu lesen). Zwei gängige Dateisystem-Tools tun genau das:

• glob findet Dateien anhand eines Namensmusters. Zum Beispiel findet es **/company-a*.md die Notizen der letzten Woche zu Unternehmen A.
• grep durchsucht Dateien, ohne sie in das Kontextfenster zu laden. Es findet wörtlichen Text und kann die übereinstimmenden Dateien, die übereinstimmenden Zeilen oder Zählungen zurückgeben.

Jeder Deep-Agent verfügt über diese integrierten Tools, zusammen mit ls, read_file, write_file und edit_file„. Dieselben Tools funktionieren unabhängig davon, wo sich die Dateien befinden (Agent-Zustand, lokale Festplatte, ein persistenter Speicher oder eine Sandbox), da sie alle über den" Backend.

Fügen Sie ein Retrieval-Tool hinzu, wenn Schlüsselwörter nicht ausreichen

Grep ist großartig, wenn Sie wissen, nach welchen Wörtern Sie suchen sollen, aber es findet nur die exakte Textangabe, die Sie ihm geben. Das ist ein Problem für die dritte Aufgabe in unserem Beispiel: das Durchsuchen eines Nachrichtenarchivs nach allem Neuen. Wenn unser Agent nach "Company A funding" grept, verpasst er einen Artikel mit dem Titel "Company A closes $50M Series B", obwohl genau das gesucht ist.

Um nach Bedeutung statt nach exakten Wörtern zu suchen (semantische Suche), fügen Sie ein Retrieval-Tool hinter dem ein Vektorspeichersteht, hinzu. Ein Retrieval-Tool ist ein beliebiges Tool, das der Agent aufrufen kann, um Informationen abzurufen: Es nimmt eine Abfrage entgegen, schlägt sie in einer Datenquelle nach und gibt zurück, was es findet (die nächstliegenden Treffer).

Wie ein Retrieval-Tool abgleicht, hängt von der Datenquelle dahinter ab. Mit einem Vektorspeicher als Grundlage gleicht es nach Bedeutung ab, aber ein Retrieval-Tool kann auch auf anderen Datenquellen aufbauen:

• Eine SQL-Datenbank für strukturierte Abfragen (z. B. Verkaufszahlen oder Kundendatensätze)
• Eine Such-API (für frische Informationen aus dem Web)
• Ein MCP-Server (für Tools, die jemand anderes bereits gebaut hat, z. B. eine Dokumentationssuche)

Für einen tieferen Einblick, wie semantische Suche funktioniert, siehe LangChains Anleitung.

Dem Agenten die Entscheidung überlassen, wann gesucht wird

Viele Retrieval-Setups suchen einmalig am Anfang und antworten dann. Das funktioniert für einen FAQ-Bot (2-Schritte-RAG), aber nicht für unseren Agenten. Nehmen wir an, der Agent findet mitten in der Recherche zu Company C einen Artikel über eine Produktvorstellung, von der er nichts wusste, und benötigt nun die Preisgestaltung dieses Produkts (nach der er zu Beginn nicht hätte suchen können). Mit nur einer Suche geht der Bericht ohne diese Information heraus.

Recherche-Agenten benötigen agentisches Retrieval (statt 2-Schritte-RAG): Der Agent entscheidet, wann er sucht, wonach er sucht und ob er mehr benötigt. Mit Deep Agents funktioniert dies standardmäßig bereits so: Der Agent läuft in einer Schleife und kann jedes Tool so oft aufrufen, wie er benötigt.

Verpacken Sie Ihr Such-Know-how als Skill

Damit der Agent gut suchen kann, können Sie Ihr Such-Know-how als Skillverpacken: eine Reihe von Anweisungen für eine bestimmte Aufgabe (z. B. welcher Index zu verwenden ist, wie Suchanfragen formuliert und wie Zitate formatiert werden).

Der Agent sieht nur den Namen jedes Skills und eine kurze Beschreibung, bis eine Aufgabe ihn erfordert; dann lädt er die vollständigen Anweisungen, sodass spezialisiertes Know-how bei Bedarf zur Verfügung steht, ohne den Rest der Zeit Kontext zu belegen (eine Technik namens progressive disclosure). Hier ist eine Videoerklärung.

2. Zu viel Kontext auf einmal

Selbst bei Optimierung des Suchprozesses kann jedoch selbst die richtige Suche zu viel zurückgeben. Unser Agent benötigt nur eine Zahl aus dem Marktdatenexport (den Quartalsumsatz von Company B), aber das Laden aller 40,000 Zeilen, um sie zu finden, würde sein Kontextfenster füllen. Unser Retrieval-Tool hat dasselbe Problem: Wenn es jede Nachrichtenmeldung direkt an das Modell zurückgibt, summieren sich vier Ergebnisse pro Suche über fünf Unternehmen schnell.

Große Dateien seitenweise lesen

Die Dateisystem-Tools sind so gebaut, dass sie so wenig wie möglich zurückgeben. read_file liest eine Datei seitenweise (standardmäßig 100 Zeilen), und der Agent kann einen Offset (die Startzeile) und ein Limit (wie viele Zeilen gelesen werden) setzen, um zu dem benötigten Teil zu springen. Um also den Umsatz von Company B zu finden, grept der Agent danach und liest dann nur die wenigen Zeilen um den Treffer.

Das Harness überlastete Ergebnisse auslagern lassen

Manchmal gibt ein Tool trotzdem mehr zurück als erwartet. Wenn ein Tool-Ergebnis zu groß ist (über etwa 20,000 Tokens), speichert das Harness es in einer Datei unter /large_tool_results/ und gibt dem Agenten den Pfad plus eine kurze Vorschau (die ersten und letzten Zeilen). Der Agent kann dann nur die benötigten Teile mit read_fileOffset und Limit nachlesen.

Ihr Retrieval-Tool Dateipfade zurückgeben lassen

Sie können dieselbe Idee auf Ihr eigenes Retrieval-Tool anwenden, statt auf das Größenlimit zu warten: Lassen Sie es jedes Ergebnis in eine Datei schreiben und nur die Pfade zurückgeben. Dies ist der erste Teil eines Musters namens „retrieve, offload, delegate“ (LangChain’s RAG guide führt es vollständig durch).

Hier ist ein vereinfachtes Retrieval-Werkzeug. Es führt die Suche aus, speichert jedes Ergebnis als Datei im Backenddes Agenten und gibt nur die Liste der Dateipfade zurück:

backend = StateBackend()

@tool
def search_news(query: str) -> str:
    """Search the news archive and save each result to a file."""
    docs = vector_store.similarity_search(query, k=4)
    files = [(f"/retrieved/result_{i}.md", doc.page_content.encode()) for i, doc in enumerate(docs)]
    backend.upload_files(files)
    return "Saved results to: " + ", ".join(path for path, _ in files)

Jetzt sieht der Hauptagent vier kurze Pfade statt vier vollständiger Artikel.

3. Irrelevanter oder veralteter Kontext

Kleine Ergebnisse helfen nicht, wenn es die falschen Ergebnisse sind. Jede dieser vier Dateien könnte von einem anderen Unternehmen mit ähnlichem Namen handeln oder eine Geschichte von vor zwei Jahren sein. Themenferner oder veralteter Text wirkt für ein Modell genauso überzeugend wie die richtige Antwort, daher besteht das Ziel darin, ihn vollständig aus dem Kontext des Hauptagenten fernzuhalten.

Subagenten die Ergebnisse filtern lassen

Allerdings muss der Hauptagent trotzdem diese Dateien lesen, um herauszufinden, welche davon relevant sind (und jeder off-topic Artikel, den er öffnet, landet in seinem Kontext). Genau hier kommt der „Delegate“-Teil des „Retrieve, Offload, Delegate“-Musters ins Spiel: ein Subagent liest jede abgerufene Datei und gibt nur die wichtigsten Fakten zurück.

1. Den Subagenten definieren: Die Beschreibung sagt dem Hauptagenten, wann er ihn verwenden soll (eine Datei pro Aufruf), und der System-Prompt sagt dem Subagenten, was er mit dieser Datei tun soll.

chunk_analyst = {
		"name": "chunk-analyst",
		"description": "Analyze one retrieved file. Pass the question and a single path under /retrieved/.",
		"system_prompt": "Use read_file to read the assigned file. Return the key facts and the source URL.",
}

1. Dem Hauptagenten das Retrieval-Werkzeug und den Subagenten geben. Das gleiche Backend übergeben, das in search_newsverwendet wurde, damit der Subagent die Dateien lesen kann, die das Werkzeug gespeichert hat.

agent = create_deep_agent(
		model=model,
		tools=[search_news],
		backend=backend,  # same instance, so read_file can see /retrieved/
		subagents=[chunk_analyst],
)

Jetzt läuft der Ablauf so:

1. Suchen: Der Hauptagent ruft search_news auf und erhält vier Pfade zurück.
2. Delegieren: Er sendet jeden Pfad an einen Chunk-Analyst-Subagenten, und diese können parallel laufen.
3. Synthetisieren: Jeder Analyst liefert eine kurze Zusammenfassung mit seiner Quelle zurück. Der Hauptagent kombiniert sie und sucht erneut, falls etwas fehlt.

Die Rohergebnisse gehen in Dateien, das fehleranfällige Lesen passiert in Subagenten mit ihren eigenen Kontextfenstern, und der Hauptagent sieht immer nur die Schlussfolgerungen. Alles Off-topic bleibt im Kontext des Subagenten, und das Kontextfenster des Hauptagenten bleibt übersichtlich!

Aus aktuellen Quellen schöpfen

Filterung hält off-topic Ergebnisse zwar fern, kann aber nichts an veralteten Ergebnissen ändern. Unser Wettbewerbsanalyse-Agent läuft jeden Montag, also erfasst der Index vom letzten Monat die Nachrichten dieser Woche nicht.

Eine Lösung: Eine Search-API oder ein MCP-Server könnte dem Agenten aktuelle Informationen liefern (statt dessen, was vor Monaten indexiert wurde). Wenn Ihre Daten Datumsangaben enthalten, würde die Filterung nach Datum im Retrieval-Werkzeug auch alte Ergebnisse ausschließen.

Vorsicht bei abgerufenem Text

Auf der anderen Seite können relevante aktuelle Ergebnisse Probleme verursachen! Da abgerufener Text Daten und keine Anweisungen ist, könnte alles, was Sie abrufen, eine Prompt-Injection (und keine Prompt- oder Trennzeichen-Strategie verhindert dies vollständig). Stellen Sie sicher, dass Sie die Ausgaben validieren: Prüfen Sie, ob Antworten die erwarteten Quellen zitieren und ob Aussagen mit diesen übereinstimmen.

Abrufstrategien, die man im Kopf behalten sollte

Darauf sollten Sie achten (unabhängig davon, auf welchem Harness Sie aufbauen):

• Verwenden Sie das effizienteste Tool, das funktioniert. Wenn Sie die Wörter kennen, schlägt grep eine Embedding-Suche. Sparen Sie semantische Suche für die Fälle auf, in denen Sie sie wirklich brauchen.
• Seitenweise lesen statt vollständig laden. Lesen Sie große Dateien in Stücken statt auf einmal.
• Zeiger statt Nutzdaten zurückgeben. Schreiben Sie abgerufene Inhalte in Dateien und übergeben Sie dem Agenten die Pfade.
• Das Lesen delegieren. Lassen Sie Subagenten lesen und zusammenfassen, damit der Hauptagent nur die Schlussfolgerungen sieht.
• Erdung überprüfen. Prüfen Sie Antworten anhand des Abrufenen, und behandeln Sie abgerufenen Text als nicht vertrauenswürdig.

Ausprobieren

uv add deepagents

Möchten Sie von einem Live-Dozenten mehr erfahren? Ich werde dies am 9. November behandeln: Registrieren Sie sich HIER!

‍

Retrieval ist nur die halbe Geschichte: wie Informationen ihren Weg zum Agenten finden. Wie verwalten wir das Kontextfenster des Agenten, wenn er im Laufe der Zeit Informationen ansammelt?

Um mehr zu erfahren, schauen Sie sich Folgendes an:

• Blog über Context Engineering mit Deep Agents
• Deep Agents Kurs auf LangChain Academy (kostenlos, online und im eigenen Tempo).