Das Shell-Tool ist kein Allheilmittel für Kontext-Engineering

Die wichtigsten Werkzeuge eines Agenten sind die Suchwerkzeuge, mit denen er seinen eigenen Kontext aufbauen kann. Die jüngsten Beiträge von LlamaIndex und LangChain haben eine Diskussion ausgelöst: Sind ein Shell-Tool und ein Dateisystem alles, was ein Agent für Kontext-Engineering braucht? Leider driftete die Diskussion schnell in die falsche Richtung ab: Dateisystem versus Datenbank.

Dieser Beitrag konzentriert sich erneut auf die Frage:Welche Suchoberflächen braucht ein Agent, um seinen eigenen Kontext zu erstellen? Zunächst werden die Vor- und Nachteile von Shell-Tools und dedizierten Datenbanktools erläutert. Von dort aus ergibt sich ein praktisches Framework, um die richtigen Schnittstellen für die Bedürfnisse Ihres Agenten zu finden.

Was bedeutet „Kontextaufbau“ eigentlich für einen Agenten?

In frühen Retrieval-Augmented Generation (RAG)-Pipelines erzeugte der Entwickler eine feste Retrieval-Pipeline, und das große Sprachmodell (LLM) war passiver Empfänger des Kontexts. Das war eine grundlegende Einschränkung: Der Kontext wurde bei jeder Abfrage abgerufen, egal ob er benötigt wurde oder nicht, ohne zu prüfen, ob er tatsächlich half.

Mit der Umstellung auf agentenbasiertes RAG haben die Agenten nun Zugriff auf eine Reihe von Suchwerkzeugen, um ihren eigenen Kontext zu erstellen. Beispielsweise ermöglichen sowohl Claude Code [1] als auch Cursor [2] dem Agenten, zwischen verschiedenen Suchwerkzeugen zu wählen und diese sogar für verkettete Abfragen zu kombinieren, je nachdem, was die Aufgabe tatsächlich erfordert.

Welche Suchoberflächen gibt es für das Kontext-Engineering?

Kontext kann sich an verschiedenen Orten befinden, etwa im Web, in einem lokalen Dateisystem oder in einer Datenbank. Ein Agent kann mit jeder dieser kontextlosen Datenquellen über verschiedene Werkzeuge interagieren:

• Shell-Tools können Shell-Befehle ausführen und haben Zugriff auf das lokale Dateisystem. Beispiele für integrierte Shell-Tools sind das Bash-Tool von Claude API, das Exec-Tool von OpenClaw und das Shell-Tool von LangChain.
• Spezielle Datenbanktools wie zum Beispiel Tools eines Model Context Protocol (MCP)-Servers (z. B. der Elastic Agent Builder MCP-Server) oder benutzerdefinierte Tools (z. B. run_esql(query) oder db_list_index()) können Datenbanken abfragen.
• Dedizierte Dateisuchwerkzeuge können lokale (oder hochgeladene) Dateien suchen und lesen (ohne vollständigen Zugriff auf die Shell). Beispiele für integrierte Dateisuchwerkzeuge sind das Dateisuchwerkzeug der Gemini API oder das Dateisuchwerkzeug von OpenAI.
• Web-Suchwerkzeuge können Informationen aus dem Web abrufen.
• Gedächtniswerkzeuge speichern und rufen aus dem Langzeitgedächtnis ab (unabhängig davon, wie es gespeichert ist).

Wie Sie sehen, ist das Shell-Tool vielseitig und kann verwendet werden, um Kontext aus verschiedenen Datenquellen abzurufen, darunter:

• Dateisystem: Der Agent erkundet die Verzeichnisstruktur (ls, find), sucht nach relevanten Inhalten (grep, cat) und wiederholt dies, bis er genügend Kontext aufgebaut hat.
• Datenbank: Der Agent kann Befehlszeilen-Schnittstellen (CLI)-Tools für Datenbanken verwenden (z. B. elasticsearch-sql-cli), HTTP-APIs über curl aufrufen oder Skripte ausführen, was insbesondere in Kombination mit Elastic Agent Skills nützlich ist. Dabei handelt es sich um wiederverwendbare, dokumentierte Beispiele, die in den Kontext des Agenten eingefügt werden, um die korrekte Tool-Nutzung anzuleiten (z. B. Elastic Agent Skills für Elasticsearch).
• Web: Der Agent kann Websuchen per curl-Befehl über die API eines Suchanbieters ausführen.

Das Shell-Tool bietet jedoch direkten Systemzugriff und erfordert daher Sicherheitsmaßnahmen, zum Beispiel die Ausführung in einer isolierten Sandbox-Umgebung und das Protokollieren aller ausgeführten Befehle.

Wann sollten welche Suchoberflächen verwendet werden?

Die richtige Suchschnittstelle hängt von Ihren Daten, Ihren Abfragemustern und Ihrem Anwendungsfall ab. Dieser Abschnitt dient als praktischer Ausgangspunkt.

Dateisysteme machen Datenbanken nicht überflüssig

Bei der Diskussion um Dateisysteme versus Datenbanken geht es nicht um die Speicherschicht. LangChain erklärt zum Beispiel, dass sein Speichersystem Daten nicht wirklich in einem echten Dateisystem speichert. Stattdessen speichert es sie in einer Datenbank und stellt sie dem Agenten als eine Reihe von Dateien dar [3].

Dateisysteme eignen sich hervorragend für dateiabhängige Anwendungsfälle, wie z. B. Codierungsagenten. Sie eignen sich auch gut als temporärer Notizblock oder Arbeitsspeicher und für Einzelnutzer- oder Einzelagenten-Szenarien, bei denen die Gleichzeitigkeit keine Rolle spielt. In diesen Fällen bietet Ihnen ein physisches Dateisystem oder die Darstellung der Daten als Dateisystem Flexibilität, bevor Sie sich auf eine speziell entwickelte Schnittstelle festlegen.

Aber Dateisystemspeicher haben echte Nachteile, wie etwa schwache Parallelität, manuelle Schema-Durchsetzung und atomare Transaktionen. Diese treten noch deutlicher zutage, wenn Ihre Anwendung skaliert werden muss oder auf ein Multi-Agenten-Szenario umgestellt werden soll. Wer diese Nachteile ignoriert, sieht sich zu einer mühsamen Neuerstellung schlechterer Datenbanken gezwungen, ohne die jahrzehntelange technische Erfahrung hinter Transaktionssicherheit oder Zugriffskontrolle nutzen zu können, die Produktionsdatenbanken bereits bieten. Außerdem wählt man in den meisten Unternehmenskontexten nicht, ob eine Datenbank verwenden werden soll, da sie bereits vorhanden ist und geschäftskritische Daten speichert.

Shell-Tool + Dateisystem

Ein Shell-Tool ist der natürliche Ausgangspunkt für die Dateisystemsuche. Derzeit treiben Codierungsagenten den Fortschritt auf diesem Feld maßgeblich voran. Da sie mit Code in lokalen Dateien arbeiten, sind es von Natur aus dateiintensive Anwendungsfälle. Deshalb werden LLMs in der Post-Training-Phase für Codierungsaufgaben feinjustiert. Viele LLMs beherrschen daher nicht nur das Schreiben von Code, sondern auch die Verwendung von Shell-Befehlen und die Navigation in Dateisystemen.

Die Verwendung eines Shell-Tools mit integrierten CLIs wie ls und grep zum Suchen von Dateien ist effektiv. Mit grep ist eine Abfrage wie „Finde alle Dateien, die matplotlibimportieren“ schnell, präzise und kostengünstig. Wenn der Agent jedoch konzeptionelle Anfragen bearbeiten muss, wie zum Beispiel „Wie geht unsere App mit fehlgeschlagener Authentifizierung um?“, kann die Mustererkennung mit grep schnell an ihre Grenzen stoßen. Um diese Lücke zu schließen, sind mehrere Alternativen entstanden, die semantische Suchfunktionen in die Befehlszeile einfügen, darunter jina-grep.

Grep und viele seiner semantischen Suchalternativen laufen jedoch in O(n) über dem Korpus. Für Anwendungsfälle in Codebasen mag das in Ordnung sein. Wenn Ihre Datenmenge jedoch zunimmt, wird sich Latenz bemerkbar machen. In diesem Fall ist ein indizierter Datenspeicher erforderlich, um die Leistung aufrechtzuerhalten.

Shell-Tool + Datenbank

Eine weitere Möglichkeit, zusätzliche Suchfunktionen wie semantische oder hybride Suche für Ihre Daten zu erstellen, besteht darin, diese in einer Datenbank zu speichern, wie es beispielsweise Cursor tut. Und wenn Daten komplexe relationale Verknüpfungen oder Aggregationen erfordern, benötigen Sie eine Datenbankschnittstelle.

Falls die Daten nicht im Dateisystem, sondern in einer Datenbank gespeichert sind, kann ein Shell-Tool für bestimmte Anwendungsfälle als leichtgewichtige Datenbankschnittstelle dienen. Sind Ihre Abfragen einfach genug für eine CLI oder einen curl-Aufruf, führt ein spezielles Datenbanktool eventuell zu unnötiger Komplexität.

Dieser Ansatz eignet sich auch für frühe Explorationsphasen, in denen Sie noch nicht wissen, welche Abfragemuster Ihr Agent tatsächlich entwickeln wird. In diesem Fall können Agent Skills dem Agenten genügend Struktur geben, um korrekte Abfragen durchzuführen, ohne dass ein speziell dafür entwickeltes Tool erforderlich ist. Wenn der Agent jedoch viele Iterationen benötigt, um die richtige Methode zum Abfragen der Datenbank für wiederkehrende Aufgaben herauszufinden, rechtfertigt der Token-Overhead der Verwendung eines Shell-Tools als Schnittstelle den Einfachheitsvorteil, ein zusätzliches Tool zu vermeiden, nicht mehr.

Dedizierte Datenbank-Tools

Insbesondere bei strukturierten oder analytischen wiederkehrenden Abfragemustern sind spezielle Datenbankwerkzeuge notwendig. In einem Blogbeitrag von Vercel und Braintrust wurden Agenten mit verschiedenen Suchwerkzeugen für reale Rechercheaufgaben in semistrukturierten Daten verglichen, wie z. B. Kundensupport-Tickets und Transkripte von Verkaufsgesprächen (z. B. „Wie viele offene Tickets erwähnen ‚Sicherheit‘?“ oder „Finden Sie Tickets, bei denen jemand einen Fehler gemeldet hat und später jemand einen PR eingereicht hat, der behauptet, ihn zu beheben?“). [4].

Agenten mit dedizierten Datenbank-Tools verbrauchten weniger Token, waren schneller und machten weniger Fehler als Agenten, die nur ein Shell-Tool und ein Dateisystem verwendeten. Wir ziehen daraus den Schluss, dass direkte Datenbank-Tools die richtige Wahl sind, wenn die Abfrage analytische Schlussfolgerungen über teilweise strukturierte Daten erfordert.

Kombination von Suchschnittstellen

Keine einzelne Suchschnittstelle kann jede Suchanfrage optimal verarbeiten. Cursor kombiniert beispielsweise Shell-Tools (für Suchen mit grep) und semantische Suchwerkzeuge und ermöglicht es dem Agenten, mit dem Prompt des Nutzers das richtige Werkzeug auszuwählen. Sie berichten, dass der Agent für das Auffinden bestimmter Symbole oder Zeichenfolgen grep, für konzeptuelle oder Verhaltensfragen die semantische Suche und beides für explorative Aufgaben auswählt.

Das Vercel-Experiment kommt zum selben Ergebnis: Sein Hybrid-Agent mit Zugriff sowohl auf ein Shell-Tool als auch auf ein dediziertes Datenbank-Tool erzielte die beste Leistung aller getesteten Agenten, indem er zuerst die dedizierten Datenbank-Tools nutzte und anschließend die Ergebnisse durch das Durchsuchen des Dateisystems mit grep überprüfte. Jedoch verwendet dieser Ansatz mehr Token und Zeit für Überlegungen zur Werkzeugwahl und Verifizierung.

Das Muster ist in beiden Beispielen dasselbe: Komposition ist jeder einzelnen Schnittstelle überlegen, aber Komposition hat auch den Nachteil zusätzlicher Kosten und Latenz.

Praktische Empfehlungen zur Auswahl des richtigen Werkzeugsatzes

Die richtigen Suchschnittstellen sind klein, zielgerichtet und speziell auf die tatsächlichen Suchmuster Ihres Agenten zugeschnitten. Derzeit gilt es als Best Practice, statt eines Agenten mit Hunderten von MCP-Tools einen Agenten mit so wenigen Tools wie möglich zu haben. Das liegt daran, dass die sofortige Offenlegung aller möglichen Tools ein Nachteil ist, weil sie das Kontextfenster aufbläht und den Agenten darüber verwirrt, welches Tool er tatsächlich verwenden soll. Claude Code verfügt beispielsweise Berichten zufolge nur über etwa 20 Tools.

Die Idee der progressiven Offenlegung besteht hingegen darin, mit einem minimalen Satz an Tools zu beginnen und es dem Agenten zu ermöglichen, zusätzliche Fähigkeiten nur bei Bedarf abzufragen. Forschungen von Anthropic [5] und Cursor [6] haben gezeigt, dass dieser Ansatz eine Token-Ersparnis von 47%–85% bringt. Claude Code implementiert dies zum Beispiel direkt und ermöglicht es dem Agenten, schrittweise herauszufinden, wie eine API oder eine Datenbank abgefragt werden kann, ohne dass dieses Wissen bei jedem LLM-Aufruf Kontext verbraucht.

Sobald Sie mit den Abfragemustern des Agenten vertraut sind, können Sie die Suchwerkzeuge, auf die der Agent standardmäßig Zugriff hat, erneut aufrufen. Eine hilfreiche Herangehensweise an diesen Zielkonflikt ist das Prinzip „Low Floor, High Ceiling“ zur Auswahl der passenden Werkzeuge. High-Ceiling-Tools schränken das Potenzial des Agenten nicht ein. Ein vielseitiges Shell-Tool ermöglicht es dem Agenten beispielsweise, vollständige, auch mehrdeutige Datenbankabfragen zu schreiben, aber auf Kosten des Argumentationsaufwands, höherer Latenz und geringerer Zuverlässigkeit.

Bei Low-Floor-Tools ist es genau umgekehrt. Dabei handelt es sich um spezialisierte Tools, die bestimmte Abfragen kapseln und dem Agenten mit minimalem zusätzlichem Überlegungsaufwand sofort zur Verfügung stellen – bei geringeren Kosten und höherer Zuverlässigkeit. Sie erfordern jedoch eine Vorentwicklung, können nicht jede mögliche Anfrage abdecken und erschweren es dem Agenten, das richtige Werkzeug auszuwählen.

Betrachten Sie jedes Tool als Teil eines Spektrums: Low-Floor-Tools sind für den Agenten leicht korrekt zu verwenden, haben aber einen begrenzten Anwendungsbereich. High-Ceiling-Tools sind vielseitig, erfordern aber mehr Überlegung, um sie richtig einzusetzen.

Die meisten Agenten benötigen eine Mischung aus verschiedenen Suchwerkzeugen. Jedes Werkzeug muss sich jedoch als nützlich erweisen. Wir empfehlen, mit einem universellen Such-Tool zu beginnen (zum Beispiel einem search_database() -Tool oder einem Shell-Tool). Nutzen Sie dann die Befehlsprotokolle, die Sie aus Sicherheitsgründen bereits führen, erneut, um nachzuverfolgen, was Ihr Agent tatsächlich tut, einschließlich der Toolaufrufe, Wiederholungen und der Anzahl der Aufrufe pro Nutzerabfrage. Und wenn Sie feststellen, dass sich ein Abfragemuster wiederholt oder fehlschlägt, dann sollten Sie für diese Aufgabe ein spezielles Werkzeug erstellen.

Zusammenfassung

Die Debatte „Dateisystem versus Datenbank“ lenkt von der eigentlichen Frage ab, die sich Entwickler stellen müssen: Welche Suchoberflächen braucht ein Agent, um seinen eigenen Kontext zu erstellen? Die Antwort ist sehr wahrscheinlich: keine einzige.

Ein Shell-Tool ist ein vielseitiges Tool für die Interaktion mit unterschiedlichen kontextfremden Quellen und damit ein guter Ausgangspunkt. Für Anwendungsfälle mit strukturierten analytischen Abfragen ist es jedoch weniger effizient und präzise als dedizierte Datenbank-Tools.

Ziel ist es, die minimale Menge an Suchwerkzeugen zu finden, die die tatsächlichen Abfragemuster Ihres Agenten gut verarbeitet. Beginnen Sie mit einem Shell-Tool und protokollieren Sie, was Ihr Agent tatsächlich tut. Wenn Sie feststellen, dass sich ein Abfragemuster wiederholt und fehlschlägt, ist es Zeit, spezialisierte Werkzeuge zu entwickeln.

Referenzen

1. Thariq (Anthropic). Lessons from Building Claude Code: Seeing like an Agent (2026).

2. Cursor: Dokumentation. Semantic & agentic search (2026).

3. Harrison Chase (LangChain). How we built Agent Builder’s memory system (2026).

4. Ankur Goyal (Braintrust) und Andrew Qu (Vercel). Testing if "bash is all you need" (2026).

5. Anthropic. Introducing advanced tool use on the Claude Developer Platform (2025).

6. Cursor. Dynamische Kontexterkennung (2026).