Was wir bauen
Die Referenzimplementierung ist ein kleines Python-Projekt mit einigen klar getrennten Teilen:| Teil | Was es tut |
|---|---|
| CLI | Nimmt Research-Thema, Modell, Provider, Tiefen-Settings, Output-Pfad und Artefakt-Verzeichnis entgegen |
| Venice-Client | Ruft Chat-Completions, Streaming-Chat-Completions und POST /augment/scrape auf |
| Such-Layer | Sucht per Default auf DuckDuckGo, optional mit arXiv-Paper-Discovery |
| Datenmodelle | Verfolgt Quell-URLs, kanonische URLs, Chunks, Belege, Notizen, Fehler und Reports |
| Research-Agent | Plant Suchen, liest Quellen, extrahiert Belege, analysiert Lücken, erzeugt Folgequeries und schreibt den finalen Report |
| Artefakt-Writer | Speichert auditierbare JSONL-Records für Queries, Research-Gaps, Ergebnisse, Fetches, Chunks, Source-Notes, Report-Drafts, Fehler und Reports |
- Venice bitten, vielfältige Suchanfragen zum Thema zu generieren.
- Im Web mit einem oder mehreren Providern suchen.
- URLs vor dem Lesen deduplizieren.
- Mit Venices Scrape-Endpoint jede öffentliche Seite in Markdown verwandeln.
- Lange Seiten in Chunks splitten.
- Venice bitten, aus jedem Chunk Belege zu extrahieren.
- Venice bitten, aus den Chunk-Belegen Source-Notes zu machen.
- Research-Gaps und Source-Balance-Probleme identifizieren, bevor Folgequeries erzeugt werden.
- Venice bitten, den finalen Report mit Fußnoten-Zitaten zu synthetisieren.
Projekt einrichten
Das Referenzprojekt nutzt Python 3.13 unduv, derselbe Code funktioniert aber auch mit einer klassischen Virtual Environment.
Neues Projekt anlegen:
pip nutzt, legt eine Virtual Environment an und installiert dieselben Pakete:
.env-Datei für die lokale Entwicklung an:
VENICE_MODEL, damit du das Modell ohne Code-Änderungen wechseln kannst. Die Referenz nimmt aktuell standardmäßig openai-gpt-55, du kannst es aber gegen ein anderes für dein Venice-Konto verfügbares Chat-Modell tauschen.
Datenmodelle erstellen
Bevor wir die Agent-Logik schreiben, definieren wir die Objekte, die durch die Pipeline laufen. Diese Modelle machen den Rest des Codes leichter nachvollziehbar, weil jede Quelle Provenienz mit sich trägt: woher sie stammt, welche Query sie gefunden hat, wann sie abgerufen wurde und wie sie gechunkt wurde. Erstelleresearch_agent/models.py:
canonical_url, content_hash und chunks.
Mit canonical_url vermeidet der Agent, dieselbe Quelle mehrfach zu lesen, wenn sich Suchergebnisse nur in Tracking-Parametern oder Fragments unterscheiden. content_hash hilft, Duplikate auch dann zu erkennen, wenn sie unter anderen URLs liegen. chunks erlaubt es, lange Seiten in kleineren Stücken zusammenzufassen, statt nützliche Belege an Kontextlimits zu verlieren.
Ergänze die Helferfunktionen unter den Dataclasses:
Den Venice-Client bauen
Als Nächstes erstellen wir einen kleinen Venice-Client. Du könntest das OpenAI-Python-SDK für Chat-Completions verwenden, weil Venice OpenAI-kompatibel ist – die Referenz nutzt aber direkthttpx, damit derselbe Client auch Venices POST /augment/scrape-Endpoint aufrufen kann.
Erstelle research_agent/venice.py:
from_env()-Helper hält Secrets aus deinem Quellcode raus. Außerdem ist die lokale Entwicklung angenehmer, weil python-dotenv VENICE_API_KEY und VENICE_MODEL aus .env laden kann.
Jetzt Chat-Completions ergänzen:
_post_chat_stream()-Helper, der Server-Sent Events aus Streaming-Chat-Completions liest. Du kannst zunächst ohne Streaming starten und es ergänzen, sobald der restliche Research-Flow läuft.
Such-Provider hinzufügen
Der Such-Layer hat zwei Aufgaben: Quell-URLs finden und diese URLs durch den Venice-Scraper holen. Die Referenzimplementierung nutzt DuckDuckGos HTML-Endpoint für allgemeine Websuche und arXivs Atom-API für Papers. Erstelleresearch_agent/web.py:
WebSearch-Klasse koordiniert Provider und holt Seiten:
Lokale Artefakte schreiben
Für Research-Workflows zählt Auditierbarkeit. Wenn der finale Report etwas Überraschendes sagt, willst du nachvollziehen können, welche Quelle dazu geführt hat. Erstelleresearch_agent/artifacts.py:
Den Research-Agenten bauen
Da wir Venice, Suche, Modelle und Artefakte haben, können wir den eigentlichen Agenten bauen. Erstelleresearch_agent/agent.py:
models.py, falls sie noch nicht da sind:
ResearchAgent:
run()-Methode koordiniert die Research-Passes:
seen_*-Sets verhindern, dass der Agent Zeit mit Duplikatquellen verschwendet. URL-Dedupe fängt wiederholte Links. Content-Hash-Dedupe fängt Spiegelseiten, syndizierte Posts und Seiten, die auf denselben Endinhalt umleiten.
Initiale und Folge-Suchen planen
Der erste Modell-Aufruf macht aus dem Thema Suchanfragen:_gap_follow_up_queries(), das Venice bittet, sowohl Gap-Records als auch Queries zurückzugeben:
--artifacts werden diese Records nach research_gaps.jsonl geschrieben. Das gibt dir eine nützliche Audit-Spur, warum der Agent in einem zweiten Pass nach einer bestimmten Query gesucht hat.
Der Parser sollte tolerant sein. Liefert das Modell fehlerhaftes JSON, fällt der Agent auf das Originalthema zurück:
Quellen lesen und zusammenfassen
Jetzt sammeln wir Source-Notes. Der Agent sucht pro Query, holt jedes Ergebnis durch Venice Scrape, chunkt das Markdown und fasst die nützlichen Belege zusammen.Den finalen Report schreiben
Sobald der Agent Source-Notes hat, kann er den Report schreiben. Starten wir mit einem einfachen Single-Pass-Report-Writer:Das CLI ergänzen
Jetzt brauchen wir einen Command-Line-Einstieg. Erstellemain.py:
| Option | Was sie steuert |
|---|---|
--iterations | Anzahl der Research-Passes |
--queries | Pro Pass generierte Suchanfragen |
--results | Pro Query und Provider gelesene Ergebnisse |
--providers | Suchprovider, z. B. duckduckgo oder duckduckgo,arxiv |
--max-sources | Maximale Anzahl nutzbarer Quellen |
--chunk-chars | Ungefähre Chunk-Größe vor der Belegextraktion |
--max-chunks-per-source | Anzahl der pro Quelle zusammengefassten Chunks |
--report-style | Tiefe des finalen Reports: brief, standard oder deep |
--artifacts | Verzeichnis für JSONL-Audit-Records |
--output | Pfad für den finalen Markdown-Report |
Den Agenten ausführen
Schneller Research-Pass:brief für ein knappes, quellenbasiertes Briefing, standard für eine umfangreichere Übersicht und deep für den gestaffelten Outline-/Section-/Editor-Workflow.
Auditierbare Artefakte speichern:
source_notes.jsonl die zusammengefassten Quellbelege, research_gaps.jsonl zeigt, warum Folgequeries entstanden sind, und errors.jsonl zeigt Seiten, die beim Suchen, Scrapen oder Zusammenfassen scheiterten.
Privacy- und Reliability-Hinweise
Ein Research-Agent berührt mehrere Systeme – es lohnt sich, präzise zu sein, was wohin geht:| Schicht | Wer sieht die Daten |
|---|---|
| Lokales CLI | Thema, Konfiguration, Source-Notes, Artefakte und finale Reports bleiben auf deinem Rechner |
| Suchprovider | Suchanfragen gehen an den gewählten Provider, z. B. DuckDuckGo oder arXiv |
| Venice Scrape | Öffentliche Quell-URLs werden an Venices Scrape-Endpoint geschickt |
| Venice Chat Completions | Prompts, Quell-Chunks, Source-Notes und Report-Anweisungen werden an Venice gesendet |
| Output-Dateien | Markdown-Reports und JSONL-Artefakte werden lokal geschrieben |
POST /augment/search-Endpoint nutzt statt direkt DuckDuckGo. Die Referenz nutzt schlanke öffentliche Provider, damit die Demo leicht lauffähig und verständlich bleibt.
Für Reliability die Defaults konservativ halten:
- Retries für Venice-Aufrufe und Web-Requests nutzen.
- Ein kleines
--request-delayergänzen, wenn du viele Seiten vom selben Host liest. --max-sourcesdeckeln, damit breite Themen nicht endlos laufen.--artifactsfür wichtige Reports speichern, um die finale Ausgabe auditieren zu können.- Den Report als Briefing behandeln, nicht als Wahrheit. Bei wichtigen Aussagen den Zitaten zur Originalquelle folgen.
Die Teile testen
Du brauchst keine echten Web-Requests oder Venice-Aufrufe, um den Großteil des Systems zu testen. Die Referenz nutzt Fake-Venice- und Fake-Web-Klassen, um Research-Loop, Dedupe-Verhalten, Artefakte und Report-Prompts zu testen. Ein guter erster Test ist die URL-Kanonisierung:Benchmarking
Viele KI-Provider haben mittlerweile eigene Deep-Research-Workflows, deshalb enthält die Referenz einen einfachen Benchmark gegen Perplexitys Deep Research. Beide Agenten wurden gebeten, einen Report über die Architektur von KI-Agent-Frameworks zu schreiben, und die erzeugten Reports liegen im GitHub-Repo. Das ist kein formaler Benchmark, sondern ein praktischer Weg, Report-Struktur, Quellabdeckung, Zitationsqualität und etwaige Fokussierung auf einen Source-Cluster zu inspizieren. Genau deshalb verfolgt die aktualisierte Implementierungresearch_gaps.jsonl und die Source-Balance vor Folgesuchen.
Dieses Beispiel erweitern
Sobald der Baseline-Agent läuft, gibt es praktische Verbesserungen:- Einen Venice-Suchprovider mit
POST /augment/searchergänzen. - Reports und Artefakte in einer kleinen SQLite-DB statt in JSONL-Dateien ablegen.
- Allow- oder Blocklisten für vertrauenswürdige Research-Domains.
- PDF-Support, indem Venice Scrape mit Document-Parsing für Quellen ohne sauberes HTML kombiniert wird.
- Ein Evaluations-Set aus Themen und erwarteten Quelltypen, um Research-Qualität nach Prompt-Änderungen zu vergleichen.
- Einen Review-Schritt, der Venice bittet, unsupportete Claims im finalen Report zu finden, bevor er gespeichert wird.