Feynman im Test: Ist der Open-Source AI Research Agent bereit für Teams?

Feynman ist einer der vollständigsten Open-Source-Versuche, Deep Research in einen auditierbaren Terminal-Workflow zu verwandeln. Du gibst ein Thema ein. Das System kann Papers, Webseiten und Repositories durchsuchen, Aufgaben an vier spezialisierte Agents verteilen, einen belegten Brief schreiben, Zitate prüfen, ein Paper mit seinem Code vergleichen, eine Replikation planen und ein Thema laufend beobachten.

Unser Urteil nach Prüfung des öffentlichen Codes und der Dokumentation am 3. September 2026: Feynman ist ein starker Pilotkandidat für technische Rechercheteams. „Vollständig lokal“ beschreibt aber eine mögliche Konfiguration, nicht jeden normalen Workflow. Modellaufrufe, Suchanbieter und Cloud GPUs können weiterhin Daten aus dem eigenen System bewegen und Nutzungskosten erzeugen. Citation Checks reduzieren ein gefährliches Fehlermuster, ersetzen aber keine Fachperson, die bewertet, ob eine Quelle wirklich ausreicht.

Diese Seite besitzt die produktspezifische Suche nach „Feynman Review“ und „Open-Source AI Research Agent“. Unser LangChain Deep Agents Test behandelt ein allgemeines Agent Harness, Agent Reach den günstigen Quellenzugang und LLM-as-a-Verifier die feingranulare Bewertung von Agent-Trajektorien. Diese Aufteilung verhindert, dass ein Brand Review mit breiteren Architekturfragen konkurriert.

Was ist Feynman?

Feynman ist eine MIT-lizenzierte Research-first CLI auf Basis der Pi Agent Runtime und alphaXiv. Das offizielle README dokumentiert Workflows für Deep Research, Literaturrecherche, Paper Ranking, Drafting, Peer-Review, Code Audit, Replikation, ML Recipes und wiederkehrende Watches. Outputs landen in lokalen Projektordnern. Quellenintensive Workflows erzeugen zusätzliche Provenance-Artefakte.

Die Zahl der Agents ist weniger wichtig als der Ablauf. Feynman speichert Pläne, Zwischenrecherche, Drafts, Verifikationsnotizen und finale Outputs als Dateien. Das schafft reviewbare Übergabepunkte und einen Recovery-Pfad bei langen, fehlgeschlagenen Runs. Sensible Rechercheunterlagen brauchen deshalb dieselben Zugriffs-, Retention- und Backup-Regeln wie andere Arbeitsdaten.

Wie funktioniert Feynman Deep Research?

Das Projekt startet nicht sofort einen Schwarm. Der Deep-Research-Workflow schreibt zuerst einen Plan und wartet auf Freigabe. Enge Erklärfragen bleiben beim Lead Agent. Breite Surveys können parallele Recherche delegieren. Danach extrahiert das System Erkenntnisse, trennt Konsens von Widerspruch und prüft am Ende Claims gegen ihre Quellen.

1. Frage planen. Subfragen, Quellenstrategie, Task Ledger und Verification Log werden vor dem Modellbudget sichtbar.
2. Skalierung wählen. Eine enge Frage bleibt beim Lead, ein breiter Evidenzraum kann parallelisiert werden.
3. Extrahieren statt nur zusammenfassen. Methoden, Ergebnisse, Grenzen und Fundstellen werden aus den stärksten Quellen gezogen.
4. Konflikte synthetisieren. Konsens, Widerspruch und offene Fragen bleiben getrennt.
5. Vor Lieferung verifizieren. Quellen werden erneut geöffnet und nicht belegte Aussagen markiert oder entfernt.

Das Plan Gate ist gutes Produktdesign. Scope und Quellenstandard sind sichtbar, bevor der teure Teil beginnt. Die Qualität hängt trotzdem von Prompt, Modell, Retrieval Coverage und dem Menschen ab, der den Plan freigibt.

Was kann Feynman außer Literaturrecherche?

Läuft Feynman wirklich vollständig lokal?

Lokale Modellinferenz ist möglich. Ein normaler Rechercheworkflow greift trotzdem auf externe Quellen zu. Die Dokumentation des Standalone Installers beschreibt ein vorkompiliertes Bundle mit gepinnter Node.js Runtime und SHA-256-Prüfung vor dem Austausch. Alternativ gibt es eine npm-Installation mit kompatibler Node-Version. Supply-Chain-sensitive Teams sollten das Skript lesen, eine konkrete Release-Version pinnen und die publizierte Prüfsumme kontrollieren.

Der Setup Guide unterstützt gehostete Provider, Amazon Bedrock, LM Studio, LiteLLM, Ollama und vLLM. Ein lokales Modell kann Prompts und Inference in der eigenen Infrastruktur halten. Paper Search, Web Retrieval, alphaXiv, optionale Parser und Cloud Compute bleiben Netzwerkgrenzen, solange du sie nicht gezielt ersetzt oder abschaltest.

• Wohin geht der Research Prompt?
• Welcher Provider erhält URLs, Dokumente, Repository-Inhalte oder Suchanfragen?
• Welche Seiten werden wie lange in welchem Cache gespeichert?
• Wo liegen Credentials und OAuth Tokens?
• Verlässt Telemetrie das Gerät, und erlaubt die Policy ihre Metadaten?

„Läuft im Terminal“ ist eine Aussage über das Interface. „Alle Daten bleiben lokal“ ist eine Aussage über Architektur. Verifiziere die zweite mit der exakten Provider- und Suchkonfiguration.

Verhindert Feynman halluzinierte Zitate?

Nein. Es schafft aber eine deutlich bessere Fehlergrenze als Text, der nur wie eine Quellenarbeit aussieht. Der Verifier soll jede URL abrufen, die tragende Passage finden, die Aussage als belegt, überzogen, widersprochen oder unbelegt klassifizieren und nicht belegbare Claims entfernen.

Drei Grenzen bleiben: Eine erreichbare URL kann schlechte Evidenz enthalten. Eine Quelle kann den Wortlaut tragen, während das Modell einen methodischen Fehler übersieht. Die Suche kann genau das Paper verpassen, das die Schlussfolgerung kippt. Behandle den finalen Brief als auditierbaren Draft, nicht als autonome Freigabe. Unsere Checkliste für AI Agent Evals und Sandboxes ergänzt deterministische Checks, adversariale Fälle und Human Approval.

Kann Feynman Papers auditieren und replizieren?

Der Code-Audit-Workflow extrahiert konkrete Claims aus dem Paper und sucht im zugehörigen öffentlichen Repository nach Konfiguration, Training und Evaluation. Er dokumentiert Mismatches, fehlende Implementierungen und Reproduzierbarkeitsrisiken mit Dateipfaden. Privater Trainingscode, fehlende Daten und undokumentierte Operator-Schritte bleiben außer Reichweite.

Der Replikationsworkflow erstellt Anforderungen, Experiment Recipe, fehlende Details, Risiken und Erfolgskriterien. Ausgeführt wird erst nach der Wahl von lokal, isoliert, Docker, Modal, RunPod oder plan-only. Dieses Approval Gate ist wichtig, weil eine Replikation fremden Code laden, lizenzierte Daten verarbeiten und echtes GPU-Budget verbrauchen kann.

Verwende „repliziert“ nur, wenn die geplanten Checks gegen gespeicherte Skripte und Raw Outputs bestanden haben. Ein plausibler Plan ist keine Reproduktion.

Laufen Research Watches automatisch?

Nur wenn Scheduling wirklich verfügbar ist. Die Watch-Dokumentation sagt klar: Feynman erstellt immer Baseline und Follow-up-Plan, terminiert die Wiederholung aber nur mit sichtbarem Scheduler Tool. Fehlt es, wird die Lücke dokumentiert und ein Refresh Prompt ausgegeben.

Was kostet Feynman?

Die Software ist MIT-lizenziert, also ohne Lizenzgebühr. Die Gesamtkosten eines akzeptierten Research Outputs enthalten mindestens fünf weitere Blöcke:

• Modellinferenz: Lead, parallele Recherche, Review, Writing und Verifikation verbrauchen Tokens oder lokalen Compute.
• Suche und Extraktion: Gehostete Suche, Parser und Grounding können pro Request abrechnen.
• Experiment Compute: Lokale GPU-Zeit, Cloud-GPU-Minuten, Storage und Transfer können dominieren.
• Menschliches Review: Fachpersonen müssen unsichere Evidenz und riskante Empfehlungen auflösen.
• Betrieb: Versionen, Credentials, Retention, Monitoring, Provider-Wechsel und Fehler brauchen Ownership.

Miss Kosten pro akzeptiertem Brief oder verifiziertem Experiment, nicht pro Modellaufruf. Ein billiger Report, den zwei Senior-Stunden reparieren, ist teuer.

Für wen lohnt sich Feynman?

Ein zweiwöchiger Feynman Pilot mit klarer Kaufentscheidung

1. Wähle eine wiederholbare Research Question. Nutze ein Thema mit vertrauenswürdigem Human Brief und bekannten Pflichtquellen.
2. Friere die Acceptance Rubric ein. Miss Recall wichtiger Quellen, irrelevante Treffer, Claim Support, Reviewer-Korrekturen und Freigabezeit.
3. Pinne Release und Modell. Dokumentiere Version, Modell, Suchroute, Prompts und Retrieval-Datum.
4. Starte ohne Experiment Execution. Prüfe Recherche und Zitate, bevor du Code- oder GPU-Zugriff erlaubst.
5. Teste ein adversariales Thema. Nutze widersprüchliche Papers, einen Dead Link, unvollständigen Code und einen attraktiven unbelegten Claim.
6. Prüfe den Datenfluss. Mappe Provider, Credentials, Caches, Retention und Requests.
7. Teste einen Paper Audit. Ein Engineer kontrolliert Stichproben der Matches und Mismatches direkt im Repository.
8. Teste einen begrenzten Replication Plan. Eine Fachperson prüft Annahmen vor jedem Compute Spend.
9. Zähle Gesamtkosten. Tokens, Suche, GPUs, fehlgeschlagene Runs und Review-Minuten gehören hinein.
10. Setze das Scale Gate vorher. Erweitere nur, wenn Zeit oder Evidenzabdeckung besser werden, ohne Citation Support und Kontrolle zu senken.

Research Boundary

Status am 3. September 2026 gegen das öffentliche Repository, die Lizenz und die offizielle Workflow-Dokumentation geprüft. Dies ist ein unabhängiger Architektur- und Buyer Review, kein gesponserter Beitrag, Security Audit oder kontrollierter Benchmark. Wir haben Feynman nicht installiert, keine privaten Dokumente übertragen, keine Paid Provider verbunden und keine GPU-Replikation ausgeführt. Das Projekt bewegt sich schnell. Pinne deshalb ein Release und prüfe die aktuelle Dokumentation vor der Einführung erneut.