Tinyfish und Karpathys LLM Wiki: Scraping und Wissensbasen für Agents

Produktive Agents brauchen zwei Arten von Wissen: aktuelle Fakten aus dem Web und stabile, vernetzte Interna. Am einen Ende steht Tinyfish als Infrastruktur für Search, Fetch, Browser und Web-Agents. Am anderen Andrej Karpathys LLM Wiki (Gist): ein Muster für persistente Wissensbasen, die der Agent selbst pflegt. Wer beides verwechselt, füllt entweder den Kontext mit Scraping-Müll oder arbeitet mit veralteten internen Notizen.

Tinyfish: AI Scraping und Web-Agents

Klassisches Scraping scheitert an JavaScript-Rendering, Login-Wänden, Bot-Schutz und Layout-Änderungen. Tinyfish bündelt vier APIs unter einem Schlüssel: Search liefert strukturierte Ergebnisse aus dem Live-Web (laut Homepage ohne Cache, mit echtem Browser-Rendering). Fetch wandelt eine URL in sauberes Markdown, JSON oder HTML um, token-effizient für Modelle und Pipelines. Browser hält Sessions, umgeht Anti-Bot-Mechanismen und erreicht authentifizierte Portale. Web Agent navigiert Formulare, füllt Felder aus und extrahiert strukturierte Daten, laut Produktseite mit hoher Genauigkeit auf öffentlichen Benchmarks wie Mind2Web.

Für Teams, die Agents mit frischen Markt-, Preis- oder Compliance-Daten speisen, ist der Reiz klar: weniger fragile CSS-Selektoren, mehr semantische Ziele („Hole die aktuelle GL-Prämie von Anbieter X“). Tinyfish wirbt zudem mit MCP-Anbindung für Claude Code, Cursor und andere MCP-Clients, plus direkter REST-API für eigene Stacks. Ein Credit-Pool und eine Routing-Schicht sollen entscheiden, ob Search, Fetch, Browser oder Agent für eine Aufgabe reichen.

Das ersetzt keine Governance. Jede Pipeline braucht Allowlists, Rate Limits, Logging und menschliche Freigaben, bevor extrahierte Daten in Produktionssysteme fließen. Mehr zu Autonomiestufen und Guardrails im Unternehmen: KI-gestütztes Coding mit Ownership.

Karpathys LLM Wiki: Wissensarchitektur

Karpathy beschreibt im Gist ein Muster, das bewusst nicht klassisches RAG im Upload-Stil ist. Bei Standard-RAG lädt man Dateien hoch, chunkt sie und lässt das Modell bei jeder Frage erneut fragmentieren. Das Wissen akkumuliert nicht: jede subtile Synthesefrage startet bei null.

Das LLM Wiki arbeitet anders. Der Agent baut und pflegt ein persistentes Wiki aus verlinkten Markdown-Dateien. Neue Quellen werden nicht nur indexiert, sondern integriert: Entity-Seiten aktualisieren, Widersprüche markieren, Querverweise pflegen. Drei Schichten strukturieren das System:

• Raw Sources: unveränderliche Originaldokumente (Papers, Artikel, Transkripte).
• Wiki: vom LLM geschriebene Summaries, Konzept- und Entity-Seiten, Synthesen.
• Schema: Konventionen in AGENTS.md oder vergleichbaren Dateien, damit Ingest, Query und Lint konsistent laufen.

Drei Operationen halten das Wiki gesund: Ingest (neue Quelle verarbeiten und Querverweise aktualisieren), Query (Antworten mit Zitaten, gute Antworten zurück ins Wiki filen), Lint (Widersprüche, verwaiste Seiten, veraltete Claims finden). Karpathy empfiehlt praktisch Obsidian als Lesefläche: Graph View zeigt Hubs und Lücken, das Wiki ist ein Git-Repo aus Markdown.

Für Unternehmen ist das weniger Copy-Paste-Infrastruktur als Vorbild: interne Runbooks, ADRs, Postmortems und Kunden-Insights als verlinktes Wiki, das Agents per Suche oder MCP lesen. Das ersetzt kein Context Engineering, ergänzt es aber um eine Schicht, die mit jeder Quelle reicher wird statt nur größer.

Obsidian, RAG und Agent-Kontext

Obsidian allein ist kein Agent-Stack. Sinnvoll wird die Kombination: Raw Collection im Repo, Wiki vom Agent gepflegt, index.md als leichtgewichtiger Katalog (Karpathy berichtet von guter Skalierung bis zu hunderten Quellen ohne Embedding-RAG). Ab größerer Wiki-Größe lohnt lokale Hybrid-Suche (BM25 plus Vektoren) oder ein dedizierter MCP-Server.

RAG auf Vektordatenbank bleibt sinnvoll für statische Handbücher und PDF-Archive. Das LLM Wiki adressiert kompilierendes Wissen: Synthesen, die bereits stehen, statt bei jeder Anfrage neu zusammengesetzt zu werden. Episodisches Session-Wissen gehört wiederum in Memory-Layer wie Mem0; objektive Code-Fakten in Codebase Intelligence mit Sibyl, Fallow und Spectron. Die Architektur trennt: externes Web (Tinyfish), internes Wiki (Karpathy-Muster), episodisches Memory (Mem0), Code-Graph (Sibyl).

Rechtliche Grenzen beim Scraping

AI-native Scraping macht technische Hürden kleiner, rechtliche nicht. Vor jedem produktiven Einsatz prüfen:

• Robots.txt und Nutzungsbedingungen der Zielseiten; automatisierte Extraktion kann vertraglich untersagt sein.
• DSGVO: Personenbezogene Daten aus dem Web in Agent-Kontext oder Vektorspeicher fallen unter Löschpflichten und Zweckbindung.
• Urheberrecht und Datenbankrecht: Volltext-Spiegelung großer Kataloge ist riskanter als strukturierte, minimale Faktenextraktion mit Quellenangabe.
• Zweckbindung: Monitoring und Due Diligence brauchen dokumentierte Rechtsgrundlagen; der Agent entscheidet das nicht selbst.

Legale Allowlists, Retention und Audit-Logs gehören in die Pipeline, nicht in den Prompt. Wer Bot-Schutz umgeht, trägt zusätzliche Verantwortung für Fair Use und Vertragscompliance.

Alternativen: Firecrawl und Playwright

Tinyfish ist nicht die einzige Option. Die Wahl hängt von Budget, Betriebsmodell und Integrations-Tiefe ab:

• Playwright oder Puppeteer plus eigene Parser: maximale Kontrolle, höherer Wartungsaufwand bei Layout-Änderungen. Sinnvoll, wenn wenige, stabile Zielseiten und eigenes DevOps vorhanden sind.
• Firecrawl: API-orientiertes Crawling und Markdown-Extraktion, beliebt für RAG-Pipelines und schnelle Prototypen. Weniger Fokus auf komplexe Multi-Step-Formulare als ein dedizierter Web Agent.
• Search APIs: wenn ein Index reicht und Millisekunden-Frische nicht kritisch ist.
• Tinyfish: wenn Search, Fetch, Browser und Agent unter einem Vertrag und mit MCP-Anbindung gebündelt werden sollen, besonders bei authentifizierten oder bot-geschützten Quellen.

Oft ist ein Hybrid sinnvoll: Firecrawl oder Fetch für öffentliche Dokumentation, Playwright für eine interne Testumgebung, Tinyfish für dynamische Markt- oder Portal-Daten mit hohem Wartungsdruck.

Fazit: zwei Pole bewusst verbinden

Tinyfish liefert externe, zeitkritische Fakten aus dem Live-Web. Karpathys LLM Wiki liefert ein Reifegradmodell für internes, kumulatives Wissen in Obsidian und Markdown. RAG, Mem0 und Code-Intelligence decken jeweils andere Schichten ab. Ohne Qualitäts-Gates und klare Datenhoheit landet Scraping-Rauschen im Agent-Kontext, während ein ungepflegtes Wiki zur zweiten Wahrheit wird.

Wer Agents produktiv einsetzen will, plant drei Pipelines: legale Web-Extraktion, kuratiertes Wiki mit Ingest- und Lint-Routinen, episodisches Memory mit Löschkonzept. Dann werden frische Web-Daten und strukturiertes Wissen echte Verstärker statt neue Single Points of Failure.