Ein KI-Suchagent kann in einer Demo funktionieren, aber unter Produktionslasten scheitern, wenn die Suche unvollständige Evidenz liefert, Wiederholungsversuche erfolglose Aktionen wiederholen oder die Ausführung Zeit- und Kostenlimits überschreitet. TinyFish, das Web-Infrastruktur für KI-Agenten bereitstellt, hat zwei technische Leitfäden zu diesen Herausforderungen veröffentlicht. Der erste definiert eine Agentic-Search-Architektur für den Produktiveinsatz, während der zweite Erfahrungen aus dem Aufbau eines Deep-Research-Systemsteilt. Gemeinsam untersuchen sie, wie ein autonomer Suchagent die Suche planen, Evidenz bewerten, Fehler behandeln und die Grenze zwischen modellbasiertem Denken und deterministischer Ausführung verwalten kann.
TL;DR
TinyFish hat seine Agentic-Search-Architektur und zentrale Erkenntnisse aus dem Aufbau von Deep-Research-Systemen vorgestellt. Das System basiert auf vier Web-Primitiven (TinySearch, TinyFetch, TinyBrowser und TinyAgent) und arbeitet über eine siebenphasige Kontrollschleife um das Basismodell. Auf OpenBenchmarks erreichte TinyFish eine Abschlussrate von 79.0% bei Coding-Aufgaben und lieferte dabei die niedrigsten medianen Aufgabenkosten ($0.050) sowie den geringsten Token-Fußabdruck – ein Beleg für die Bedeutung strikter Kontrollschleifen, fehlerspezifischer Wiederholungsversuche und einheitlichen Reasonings gegenüber eigenständigen Plannern.
Was ist eine Agentic-Search-Architektur?
Eine Agentic-Search-Architektur ermöglicht es einem KI-Agenten, die Suche zu planen, auf Quellen zuzugreifen, Evidenz zu bewerten und seinen Ansatz anzupassen, wenn neue Informationen verfügbar werden. Das Modell stellt das Reasoning bereit, während die umgebende Anwendung Zustand, Tool-Ausführung, Evidenzverarbeitung, Laufzeitrichtlinien und Ausgabevalidierung verwaltet. Zusammen ermöglichen diese Komponenten einem Agenten den Umgang mit unvollständigen Ergebnissen, behebbaren Fehlern und sich ändernden Informationsanforderungen.
TinyFish's Architektur bezieht grundlegende Konzepte aus einem Architektur-Preprint vom Februar 2026, der durch typisierte Tool-Schnittstellen Reasoning von der Ausführung entkoppelt. Das Papier etabliert wesentliche System-Schutzvorkehrungen, darunter detailliertes Tracing neben strikten Limits für Tokens, Ausführungszeit, Gesamtkosten und Tool-Aufrufe.
Wie funktioniert ein Suchlauf im Produktiveinsatz?
TinyFish teilt einen Lauf in 7 Phasen:
- Aufgabe definieren: Das Ziel in einen „Evidenzvertrag“ umwandeln: erforderliche Felder, Quellen, Aktualität und Abschlussregeln.
- Suche planen: Unabhängige Anforderungen von abhängigen trennen. Abhängige Abfragen warten auf frühere Antworten.
- Erste Route wählen: Wählen Sie ein Werkzeug anhand dessen, was das System über die Evidenz weiß.
- Entdecken, auswählen, abrufen: Behandeln Sie Suchergebnisse als Kandidaten, bis der Seiteninhalt eintrifft.
- Bewerten: Kennzeichnen Sie Evidenz als ausreichend, unvollständig, widersprüchlich, unzugänglich oder Budget erschöpft.
- Reagieren oder eskalieren: Überarbeiten Sie die Abfrage, wiederholen Sie den Versuch, wechseln Sie die Quellen oder ändern Sie die Zugriffsmethode.
- Stoppen und validieren: Liefern Sie abgeschlossen, unvollständig, fehlgeschlagen, abgebrochen oder menschliche Prüfung erforderlich zurück.
Phase 2 adressiert ein bekanntes Versagen. ChainRAG (ACL 2025) nennt es das Problem des „lost-in-retrieval“, bei dem wichtige Entitäten während der Multi-Hop-Fragendekomposition verschwinden. Phase 6 stützt sich auf Search-R1, das zeigt, wie Modelle lernen können, während des Reasonings zusätzliche Suchanfragen zu generieren, wenn eine frühere Retrieval-Phase unzureichend ist. Über 7 QA-Datensätze hinweg schlug sein gelerntes Multi-Turn-Search die RAG-Baselines um 41% (Qwen2.5-7B) und 20% (Qwen2.5-3B).
Wie sollte ein Such-Agent Werkzeuge routen?
Das Routing sollte der Informationslücke folgen, nicht einer festen Leiter.
| Ausgangszustand | Primitiv | Was die App weiterhin besitzt |
| Quellort unbekannt | Suche | Abfrageplanung, Quellenrichtlinie, Stopping |
| URL bekannt und lesbar | Fetch | Vollständigkeitsprüfungen, Claim-Validierung |
| App muss Seitenaktionen steuern | Browser | Jede Aktion, jeder Retry und jeder Checkpoint |
| Entscheidungen über mehrere Seiten hinweg | Web Agent | Geschäftsregeln, Budgets, Validierung |
Eskalation ist nicht immer die Lösung. Schwache Ergebnisse brauchen eine bessere Anfrage. Widersprüchliche Quellen brauchen stärkere Belege. Ein schwereres Tool behebt beides nicht.
Retries sollten auf der Art des Fehlers basieren und innerhalb definierter Grenzen bleiben. Transiente Fehler können eine Wiederholung einer Anfrage rechtfertigen, während unvollständige oder widersprüchliche Belege einen anderen Ansatz erfordern. Browser-Retries müssen außerdem bereits abgeschlossene Aktionen berücksichtigen, um unbeabsichtigte Folgen zu vermeiden, etwa das doppelte Absenden desselben Formulars.
better',{'font-size':13,'font-weight':700,fill:G,'text-anchor':'start'}); D.sf.forEach(function(d){var tf=d[0]==='TinyFish',g=el('g',{},s4); var ring=el('circle',{r:tf?17:0,fill:'none',stroke:G,'stroke-opacity':.4,'stroke-width':2},g); var c=el('circle',{r:tf?10:8,fill:tf?G:'#6a6a6a',stroke:'#111','stroke-width':2},g); var t=tx(g,0,0,'',{'font-size':13,'font-weight':700,fill:tf?G:TX,'text-anchor':'start'}); pts[d[0]]={g:g,c:c,t:t,ring:ring,x:sx(d[1]),y:sy(d[2])}}); pts['Exa fast']=pts['Exa deep'];boost(s4,1.2)} var anim4=null,OFF={sf:{'TinyFish':[-16,-20,'end'],'Exa deep':[-14,-18,'end'],'Perplexity':[14,-12,'start'],'Firecrawl':[14,16,'start']}, so:{'TinyFish':[16,0,'start'],'Exa fast':[-14,0,'end'],'Perplexity':[14,0,'start'],'Firecrawl':[14,0,'start']}}; function drawScatter(fromZero){var data=D[cur],start={},t0=null; data.forEach(function(d){var p=pts[d[0]];start[d[0]]=fromZero?{x:sx(0),y:Y0}:{x:p.x,y:p.y};p.tx=sx(d[1]);p.ty=sy(d[2]); p.t.textContent=d[0]+' '+d[2].toFixed(1)+'% · $'+d[1].toFixed(3)}); anim4=function(ts){if(!t0)t0=ts;var f=Math.min(1,(ts-t0)/900),e=1-Math.pow(1-f,3); data.forEach(function(d){var p=pts[d[0]],s=start[d[0]];p.x=s.x+(p.tx-s.x)*e;p.y=s.y+(p.ty-s.y)*e;p.g.setAttribute('transform','translate('+p.x+','+p.y+')'); var o=OFF[cur][d[0]];p.t.setAttribute('x',o[0]);p.t.setAttribute('y',o[1]);p.t.setAttribute('text-anchor',o[2])}); if(f>=1)anim4=null}} build4();chips('c4','b',function(b){cur=b;drawScatter(false)});drawScatter(true); function loop(ts){if(active==='p1'&&run1)run1.tick(ts);if(active==='p3')tick3(ts);if(anim4)anim4(ts); if(pts.TinyFish)pts.TinyFish.ring.setAttribute('r',15+3*Math.sin(ts/220));requestAnimationFrame(loop)} requestAnimationFrame(loop); window.addEventListener('load',post);window.addEventListener('resize',post);setTimeout(post,300); })(); </script> </body></html> ">Was hat TinyFish beim Aufbau von Deep Research gelernt?
Der Deep-Research-Agent sucht, durchsucht das Web und erstellt umfassende, mit Quellen belegte Berichte. Die meisten technischen Herausforderungen drehten sich um Kontextmanagement, Systemorchestrierung und Produktdesign.
Lektion #1: Entfernung des separaten Planers
Anfängliche Iterationen verwendeten einen eigenständigen Planner, der jedes Mal neu aufgerufen wurde. Nur strukturierter Zustand wurde an ihn übergeben. Bei Folgenachfragen wie „focus only on pricing risks in Southeast Asia“ driftete der Agent zurück zu breiter Marktforschung. TinyFish verlagerte die Planung anschließend in die eigene vereinheitlichte Reasoning-Schleife des Orchestrators.
Lektion #2: Entfernung von Subagents:
TinyFish wies anfangs jeder Suchanfrage einen separaten Subagent zu, was den Kontextwechsel-Overhead, die Latenz und die Kosten erhöhte. Das Team ersetzte diese Subagents später durch Tool-Aufrufe für wiederholbare Aufgaben wie das Ranking von Suchergebnissen, die Klassifizierung von Quellen und die Extraktion von Belegen. Dies reduzierte die Informationen, die an den Orchestrator zurückgegeben wurden, sodass er sich auf die Forschungsplanung und die Entscheidung konzentrieren konnte, was als Nächstes untersucht wird.
Lektion #3: Abstimmung auf Forscher:
TinyFish hatte sein Forschungssystem zunächst auf Quellenabdeckung optimiert, doch die Nutzer legten größeren Wert auf die Qualität und Relevanz der unterstützenden Belege. Das Team passte das Quellenranking an das Forschungsziel an und fügte Kontrollen zum Priorisieren, Ausschließen oder Einschränken von Domains hinzu. Außerdem entwickelte es einen internen Evaluation-Harness mit einem LLM Judge, um Berichte hinsichtlich Relevanz, Belegstärke, Zitationsvertrauen und Quellenvielfalt zu bewerten.
Wie summieren sich Kosten und Latenz?
TinyFish budgetiert die gesamte Aufgabe, nicht einzelne Aufrufe:
- Aufgabenlatenz = Planung + Suche + Retrieval + Auswertung + Retries + interaktive Schritte + Warteschlangen.
- Aufgabenkosten = Tokens + Tool-Aufrufe + Seiten- oder Browsernutzung + Retries + Infrastruktur.
SearchAgent-X (ICLR 2026) zeigt, warum. Exaktes Retrieval erzeugte Overhead, und grobes Retrieval erzwang zusätzliches Reasoning. Seine Fixes erreichten bis zu 3,4-fachen Durchsatz und 5x niedrigere Latenz im Vergleich zu getesteten Baselines.
Wie schlägt sich TinyFish bei Suche und Fetch?
OpenBenchmarks fixiert das Modell (gpt-5.6-sol), 100 Aufgaben und Budgets und variiert nur den Anbieter. Die Scores sind Mittelwerte aus 3 Läufen.
| Metrik | TinyFish | Exa deep | Perplexity | Firecrawl |
| Suche + Abruf abgeschlossen | 79.0% ± 2.0 | 83.0% ± 1.0 | 77.7% ± 1.5 | 76.0% ± 1.0 |
| Median-Aufgabenzeit | 24s | 37s | 22s | 34s |
| Mediankosten pro Aufgabe | $0.050 | $0.127 | $0.083 | $0.082 |
| Median-Tokens pro Aufgabe | 12,844 | 23,660 | 20,062 | 17,379 |
| Nur-Suche-Abschluss | 59.3% | 66.3% (Exa fast) | 77.3% | 70.3% |
| Listenpreis der Suche | $0 | $0.012 | $0.005 | $0.005 |
Quelle: OpenBenchmarks-Board, aktualisiert am 26. September 2026. Die Aufgaben decken ausschließlich Unternehmensdokumentation ab.
OpenBenchmarks berichtet auch separat über Nur-Suche-Ergebnisse. In dieser Konfiguration erreichte TinyFish 59.3% Aufgabenabschluss, verglichen mit 77.3% für Perplexity, 70.3% für Firecrawl und 66.3% für Exa Fast. Diese Ergebnisse sollten nicht direkt mit den Such-und-Abruf-Werten verglichen werden, da die verfügbaren Retrieval-Fähigkeiten unterschiedlich sind.
Wichtigste Erkenntnisse
- Kontrolliere die gesamte Trajektorie, nicht 1 Suchaufruf.
- Route nach Informationslücke; eskaliere nur, wenn der Zugriff fehlschlägt.
- Halte Planung und Ausführung in 1 Reasoning-Schleife.
- Verlagere deterministische Schritte in Tool-Aufrufe, nicht in Subagenten.
- Ordne Quellen nach dem Rechercheziel, nicht nach einem einzigen Qualitätswert.
Lies den Architecture Guide, die Deep-Research-Lessons und die TinyFish-Dokumentation.
Dank an das Tinyfish-Team für das Thought Leadership / die Ressourcen zu diesem Artikel. Dieser Artikel wird von TinyFish gesponsert.
Der Beitrag TinyFish erläutert die Agentische Sucharchitektur für KI-Agenten im Produktiveinsatz erschien zuerst auf MarkTechPost.