Agentensuche ist ein Problem der Ausführungsumgebung

Ein arXiv-Paper vom 14. Mai hat grep und Vektorsuche in Chronos, Claude Code, Codex und Gemini CLI anhand von 116 LongMemEval-Fragen getestet. Im ersten Experiment des Papers schlug inline geliefertes grep bei jedem Agentenrahmen-/Modell-Paar die inline gelieferte Vektorsuche. Die größere Erkenntnis war allerdings ungewöhnlicher: Die Ausführungsumgebung veränderte das Ergebnis fast so stark wie das Suchverfahren selbst.¹

Die Suchqualität von Agenten steckt nicht allein in „grep gegen Vektorsuche“. Sie entsteht in der gesamten Ausführungsumgebung: Prompt, Tool-Oberfläche, Shell-Ergonomie, Ergebnisformatierung, Kontextdruck, Lieferpfad, Wiederholungsverhalten und die Fähigkeit des Modells, die Tool-Schleife zu schließen.

Kurzfassung

Sen, Kasturi, Lumer, Gulati und Subbiah verglichen lexikalische Suche und Vektorsuche in einem eigenen Agentenrahmen namens Chronos sowie in drei anbietereigenen CLI-Agentenrahmen: Claude Code, Codex und Gemini CLI.¹ Die Studie nutzte eine Teilmenge von LongMemEval-S mit 116 Fragen und testete sowohl inline gelieferte Tool-Ergebnisse als auch dateibasierte Tool-Ergebnisse.¹ Inline-grep übertraf in Experiment 1 bei jedem Agentenrahmen-/Modell-Paar die inline gelieferte Vektorsuche, darunter Codex CLI mit GPT-5.4: 93,1 % für inline-grep gegenüber 75,9 % für inline-Vektor.¹ Das Paper belegt nicht, dass grep der Vektorsuche grundsätzlich überlegen ist. Die Autoren begrenzen diese Schlussfolgerung ausdrücklich auf ihr Long-Memory-Setting für dialogbasierte QA, in dem Antworten häufig von wortgenauen Textstellen abhängen.¹ Für Entwickler von Agenten ist die nützlichere Folgerung präziser: Suchverfahren, Agentenausführung und Ergebnislieferung bilden ein gemeinsames System. Testen Sie sie gemeinsam.

Zentrale Erkenntnisse

• Für Entwickler von Agenten: Behandeln Sie grep weiterhin als ernsthafte Ausgangsbasis. Die Ergebnisse des Papers lassen „standardmäßig Vektor“ bei Long-Memory-QA über Chatverläufe nachlässig erscheinen, vor allem wenn wörtliche Namen, Daten und Benutzerfakten entscheidend sind.¹
• Für Codex- und Claude Code-Benutzer: Betrachten Sie eine CLI eines Anbieters nicht als neutrale Hülle um ein Suchprimitiv. Das Paper berichtet erhebliche Verschiebungen auf Ebene des Agentenrahmens, obwohl dieselben zugrunde liegenden Gesprächsdaten verwendet wurden.¹
• Für RAG-Teams: Berichten Sie den Lieferpfad, nicht nur das Suchverfahren. Inline-Ergebnisse und dateibasierte Ergebnisse führten zu unterschiedlichem Verhalten, weil die Dateilieferung eine weitere Tool-Nutzungsaufgabe hinzufügt.¹
• Für Migrationsarbeit: Bewahren Sie die Laufzeitverhalten, die Suche zuverlässig machen. Eine Migration von Claude Code zu Codex sollte Suche, Transkriptform und Prüfschleifen testen, bevor sie Gleichwertigkeit behauptet.
• Für zitationslastige Systeme: Abschließende Quellenangaben erzählen nicht die ganze Beweisgeschichte. Ein separates Paper zu Agentic GraphRAG argumentiert, dass Herkunftsnachweise auch von besuchtem, aber nicht zitiertem Graph-Kontext abhängen können, nicht nur von zitierten Knoten.⁴

Was hat das grep-Paper tatsächlich getestet?

Das Paper stellt eine praktische Frage: Wenn ein LLM-Agent Fragen über lange Gesprächsverläufe beantworten muss, wie stark hängt die Suche vom Suchverfahren ab, und wie stark vom Agentensystem, das darum herum gebaut ist?¹

Die Autoren verglichen zwei Suchfamilien:

Diese Suchverfahren testeten sie über zwei Klassen von Ausführungsumgebungen hinweg:

Außerdem variierten sie, wie die Ergebnisse das Modell erreichten. Inline-Lieferung fügt Suchtreffer direkt in das Gespräch ein. Programmatische Lieferung schreibt Ergebnisse in Dateien; anschließend muss das Modell sie finden, öffnen und einarbeiten.¹ Das klingt nach einem Implementierungsdetail. Die Daten zeigen: Es ist Teil der Aufgabe.

Warum hat grep hier gewonnen?

Die gemessene Aufgabe begünstigt wörtliches Wiederfinden. LongMemEval stellt Fragen zu langen Gesprächen über mehrere Sitzungen hinweg. Viele Antworten hängen von Namen, Zeitangaben, persönlichen Fakten oder exakten früheren Aussagen ab. In diesem Setting kann ein lexikalisches Tool mit hoher Präzision ein semantisches Suchverfahren schlagen, weil die Antwort oft hinter einer charakteristischen Zeichenkette liegt.¹

Tabelle 1 des Papers zeigt das Muster deutlich:

Diese Tabelle sagt nicht: „Löschen Sie Ihre Vektordatenbank.“ Das Paper selbst warnt vor dieser Lesart. Die Autoren betonen, dass ihre Schlussfolgerung an dialogbasierte Long-Memory-QA gebunden ist und dass dichtes oder hybrides Retrieval sich bei wissenschaftlicher Synthese, visuellen Dokumenten oder Codesemantik anders verhalten kann.¹

Die bessere Lesart: Exakte Suche verdient in jeder ernsthaften Agentenausführung einen Platz erster Klasse. Wenn Ihr Agent das Dateisystem durchsuchen, Logs lesen, frühere Transkripte prüfen oder einen wörtlichen Benutzerfakt wiederfinden kann, ist lexikalische Suche möglicherweise das günstigste Tool mit hohem Signalwert.

Die Ausführungsumgebung veränderte das Ergebnis

Die nützlichste Zeile im Paper lautet nicht „grep hat gewonnen“. Nützlicher ist die Beobachtung, dass ein anderer Agentenrahmen die Obergrenze ungefähr in derselben Größenordnung verschieben kann wie ein anderes Suchverfahren.¹

Ein Beispiel: Claude Opus 4.6 erreichte mit inline-grep unter Chronos 93,1 %, unter Claude Code aber 76,7 %.¹ Dieselbe Modellfamilie, dieselbe Benchmark-Teilmenge, andere Ausführungsumgebung. Ein weiteres Beispiel: Codex CLI mit GPT-5.4 erreichte mit inline-grep 93,1 %, fiel aber auf 55,2 %, sobald grep-Ergebnisse über den programmatischen dateibasierten Lieferpfad liefen; programmatische Vektorsuche landete bei 67,2 %.¹

Das ist kein reines Suchergebnis. Es ist ein Ergebnis der Ausführungsumgebung.

Das Modell musste mehr tun, als Belege zu finden. Es musste den Tool-Vertrag verstehen, Suchbegriffe wählen, stdout interpretieren, über Wiederholungen entscheiden, Dateien lesen, wenn Ergebnisse nicht inline vorlagen, und Belege in eine Antwort integrieren. Jeder dieser Schritte gehört zur Agentenausführung. Wird auch nur einer davon brüchig, kann ein starkes Suchverfahren trotzdem eine schwache Antwort erzeugen.

Warum dateibasierte Lieferung ein Test der Tool-Nutzung ist

Dateibasierte Lieferung hat einen offensichtlichen Reiz. Sie kann Kontextdruck senken, weil große Suchergebnisse außerhalb des unmittelbaren Transkripts bleiben, bis das Modell sie lesen möchte. Das sollte helfen, wenn inline gelieferte Vektortreffer das Kontextfenster überfüllen.

Das Paper zeigt den Zielkonflikt. Programmatische Vektorsuche schlug programmatisches grep in mehreren Zeilen, was das Kontextdruck-Argument stützt.¹ Die Codex/GPT-5.4-Zeile zeigt jedoch die andere Seite: Dateilieferung kann günstige Suche in einen mehrstufigen Arbeitsablauf verwandeln. Der Agent muss das Artefakt finden, öffnen, nützliche Textstellen extrahieren und erneut versuchen, wenn der erste Lesevorgang nicht gereicht hat.¹

Programmatische Lieferung tauscht also Kontextbandbreite gegen Kompetenz in der Tool-Schleife. Dieser Tausch lohnt sich nur, wenn die Ausführungsumgebung die Schleife zuverlässig schließt.

Für echte Arbeit ist das entscheidend. Ein lokaler Agent scheitert bei der Suche nicht nur, weil der Index falsch war. Er scheitert, weil stdout ungünstig gestückelt wurde, weil der Pfad zur Ergebnisdatei leicht zu übersehen war, weil ein Befehl zu viel Rauschen zurückgab, weil der Prompt die Aufgabe schlecht rahmte oder weil das Modell einen Lesevorgang zu früh abbrach.

Was das für die Codex-Migration bedeutet

Meine eigene Migration von Claude Code zu Codex konzentriert sich darauf, Betriebsverträge zu übertragen, statt einen Dateibaum zu kopieren. Dieses Paper bestätigt diese Entscheidung.

Wenn Suchqualität von der Ausführungsumgebung abhängt, hängt Migrationsqualität von mehr ab als von der Frage: „Hat Codex ein Such-Tool?“ Eine Migration muss die Verhaltensweisen bewahren, die Suche nützlich machen:

• Der Agent weiß, wann er exakte Suche vor semantischer Suche einsetzen sollte;
• Befehlsausgaben bleiben klein genug, um gelesen zu werden;
• Belegpfade bleiben bis in die finale Antwort erhalten;
• dateibasierte Artefakte sind leicht zu finden und zu prüfen;
• erfolglose Suchen führen zu besseren Abfragen statt zu voreiligen Antworten;
• öffentliches Schreiben nutzt Quellenprüfung, nicht plausibel wirkende Suche.

Diese Liste ist bewusst öffentlich und allgemein gehalten. Sie legt keine privaten Hooks, privaten Prompts oder lokalen Arbeitsablaufinterna offen. Entscheidend ist der Betriebsvertrag: Der Agent soll belegen, was er gefunden hat, statt lediglich selbstsicher über die durchgeführte Suche zu klingen.

Das Paper erklärt auch, warum sich eine Migration schlechter anfühlen kann, selbst wenn jede offensichtliche Funktion vorhanden ist. Claude Code und Codex können beide Shell-Tools bereitstellen. Beide können Dateien lesen. Beide können suchen. Wenn sich jedoch Transkriptformatierung, Umgang mit Dateiergebnissen, Abbruchverhalten oder Wiederholungsmuster unterscheiden, kann dasselbe Suchprimitiv zu anderer Arbeit führen.

Die drei anderen Signale zeigen in dieselbe Richtung

Drei weitere Papers vom 14. Mai aus demselben Scan deuten auf dasselbe größere Muster: Agentenqualität verlagert sich aus isolierten Modellaufrufen in die Architektur der Ausführungsumgebung.

APWA behandelt hochgradig parallele Agentenarbeit als verteiltes Ausführungsproblem. Die Autoren zerlegen Arbeitsabläufe in nicht interferierende Teilprobleme, die unabhängige Ressourcen ohne Querverständigung verarbeiten können, und evaluieren die Skalierung auf größeren Aufgaben, bei denen frühere Systeme scheitern.² Das ist eine Aussage über die Ausführungsumgebung, kein Prompt-Trick.

MeMo behandelt Gedächtnis als separate Modellkomponente. Es hält das ausführende LLM konstant, kodiert neues Wissen in ein dediziertes Gedächtnismodell und berichtet Widerstand gegen Retrieval-Rauschen sowie Plug-and-play-Kompatibilität mit offenen und geschlossenen LLMs.³ Das ist eine Aussage über Gedächtnisarchitektur, keine Aussage über längeren Kontext.

Das Provenienz-Paper zu Agentic GraphRAG argumentiert, dass finale Quellenangaben notwendig, aber unzureichend sein können. Genaue Antworten können von nicht zitiertem Traversierungskontext, Graph-Struktur und besuchten, aber nicht zitierten Entitäten abhängen.⁴ Das ist eine Aussage über Herkunftsnachweise, keine über Zitationsformat.

Neben das grep-Paper gestellt, ergibt sich ein Muster:

Das gemeinsame Thema: Die Hülle ist das Produkt. Die Ausführungsumgebung entscheidet, ob die Fähigkeit des Modells zu nützlicher Arbeit wird.

Was ich an einem Agenten-Stack ändern würde

Beginnen Sie mit einer langweiligen Ausgangsbasis. Geben Sie dem Agenten exakte Suche über die Dateien, Logs, Transkripte oder Notizen, die zählen. Messen Sie das, bevor Sie semantische Suche hinzufügen.

Testen Sie dann vier Kombinationen, nicht zwei:

Zeichnen Sie für jeden Lauf das Tool-Transkript auf. Die finale Antwort reicht nicht. Sie müssen wissen, ob der Agent die richtigen Begriffe gesucht, die richtige Datei geöffnet, die richtige Textstelle bemerkt, nach einem Fehltreffer erneut versucht und die Belege zitiert hat, die die Antwort tatsächlich stützen.

Fügen Sie Vektorsuche hinzu, wenn die Domäne das Wiederfinden von Paraphrasen, konzeptuelle Synthese oder nicht wörtliche Belege braucht. Behalten Sie exakte Suche bei, wenn die Domäne Namen, IDs, Dateinamen, Daten, Logzeilen, Befehlsausgaben, Benutzerpräferenzen oder frühere Anweisungen enthält. Nutzen Sie hybrides Routing, wenn die Aufgabe beides mischt.

Für öffentliches Schreiben sollte der Suchpfad strenger sein. Ein zitierter Artikel sollte Quell-URLs, Übereinstimmung zwischen Aussage und Quelle sowie eine Aufzeichnung dessen enthalten, was unverifiziert bleibt. Wenn das System einen Graph, eine Gedächtnisschicht oder einen Zwischenpfad in der Suche genutzt hat, sollten finale Quellenangaben nicht die einzige Spur sein. Das Provenienz-Paper macht diesen Punkt für Agentic GraphRAG, aber die Produktlektion gilt breiter: Belege sollten den Weg erklären, nicht nur das Ziel.⁴

Die bessere Benchmark-Frage

Die schwache Benchmark-Frage lautet:

Welches Suchverfahren ist besser?

Die stärkere Frage lautet:

Welche Suchweise erzeugt unter dieser Ausführungsumgebung, mit diesem Modell, diesem Korpus, diesem Lieferpfad und dieser Wiederholungsregel verifizierte Antworten?

Diese Frage lässt sich langsamer beantworten. Sie liefert aber auch etwas, das Sie nutzen können.

Agentenarbeit verführt immer wieder zu Komponentenbehauptungen: besseres Modell, besseres Suchverfahren, besserer Prompt, besseres Gedächtnis, bessere Parallelisierung. Die betriebliche Realität drängt in die andere Richtung. Die Komponente zählt erst, wenn die Ausführungsumgebung daraus einen verlässlichen Weg von Aufgabe zu Beleg zu Handlung macht.

Das ist der Teil, den zu migrieren sich lohnt.

FAQ

Belegt dieses Paper, dass grep besser ist als Vektorsuche?

Nein. Die Autoren begrenzen das Ergebnis ausdrücklich auf das untersuchte Long-Memory-Setting für dialogbasierte QA. Sie schreiben, dass dichtes Retrieval und hybrides Routing sich in Domänen anders verhalten können, in denen Belege selten wörtlich sind, darunter wissenschaftliche Synthese, stark visuelle Dokumente und Codesemantik.¹

Warum hat grep im Experiment so gut abgeschnitten?

LongMemEval-Fragen hängen häufig von wörtlichen Textstellen aus früheren Gesprächen ab: Namen, Daten, persönliche Fakten und exakte Aussagen. Grep belohnt hochpräzise Muster, wenn der Agent einen charakteristischen Begriff erraten kann.¹

Warum war der Agentenrahmen wichtig?

Die Ausführungsumgebung steuert Prompt-Form, Tool-Beschreibungen, Transkriptformatierung, Shell-Verhalten, Kontextaufbau, Ergebnislieferung und Abbruchkriterien. Das Paper berichtet große Genauigkeitsverschiebungen zwischen Chronos, Claude Code, Codex CLI und Gemini CLI, obwohl die zugrunde liegenden Gesprächsdaten gleich blieben.¹

Was sollten Codex-Benutzer daraus machen?

Behalten Sie exakte Suche als Ausgangsbasis bei, prüfen Sie Tool-Transkripte und testen Sie inline gegenüber dateibasierter Lieferung, bevor Sie annehmen, ein Suchverfahren sei besser. Die Codex-Zeile des Papers ist nützlich, bleibt aber ein einzelnes Benchmark-Setting, ein einzelner Korpustyp und ein unvollständiges anbieterseitiges Gesamtbild für Skalierungszeilen.¹

Wie hängt das mit RAG-Zitationen zusammen?

Das Provenienz-Paper zu Agentic GraphRAG argumentiert, dass finale Quellenangaben eine Antwort stützen können und dennoch Suchkontext auslassen, der die Antwort beeinflusst hat. Für Agentensysteme sollte Zitationsqualität Provenienz über den Weg einschließen, nicht nur die finale Liste zitierter Quellen.⁴

Was sollte eine Migration von Claude Code zu Codex bewahren?

Bewahren Sie das Betriebsverhalten: wann der Agent sucht, wie er Ausgabe begrenzt, wie er Belege öffnet, wie er erneut versucht, wie er Quellpfade festhält und wie er unbelegte Behauptungen verweigert. Setzen Sie Gleichwertigkeit nicht voraus, nur weil beide Umgebungen eine Shell und einen Suchbefehl bereitstellen.

Referenzen