LangAlpha: ein Agenten-Harness für Aktienrecherche mit persistentem Workspace
Claude Code for Financial Market
Auf einen Blick
- Was ist das?
- LangAlpha verbindet einen Claude-Code-ähnlichen Agenten mit Finanzdaten, Sandbox-Workspaces und einem Web-Arbeitsplatz. Der Ansatz löst ein echtes Problem, die Dokumentation lässt aber zentrale Betriebsfragen offen.
- Für wen ist es gedacht?
- Wer Research über Wochen statt in einzelnen Prompts betreibt und bereit ist, FastAPI, PostgreSQL und Redis selbst zu betreiben, findet in LangAlpha einen passenden Rahmen. Für einmalige Datenabfragen ist das Projekt überdimensioniert, ebenso ohne eigene Datenprovider-Verträge.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Das Problem: Investitionsrecherche ist kein einmaliger Prompt
Das README formuliert die Ausgangslage selbst: bestehende KI-Finanzwerkzeuge behandelten Investieren als Einmalvorgang, Frage stellen, Antwort erhalten, weitergehen. Der Einwand im Repository lautet, echte Investitionsarbeit sei iterativ, eine These entstehe, täglich kommen neue Daten, die Überzeugung werde angepasst. Genau diese Lücke soll LangAlpha füllen.
Die Zielgruppe ist damit enger, als der Beiname vibe investing agent harness vermuten lässt. Angesprochen sind Menschen, die über Wochen an einer These arbeiten, etwa an einer Sektorrotation oder einer Analyse der Nachfrage nach Rechenzentren. Das README nennt als Beispiel-Workspaces Q2 rebalance, data center demand deep dive und energy sector rotation. Wer nur schnell einen Kurs abfragen will, braucht dieses Projekt nicht.
Die Inspiration ist ausdrücklich aus der Softwareentwicklung entlehnt. Code-Agenten wie Claude Code hätten davon profitiert, dass eine Codebasis bestehen bleibt und jeder Commit auf früherem Stand aufbaut. LangAlpha überträgt dieses Muster auf Research: nicht die Antwort ist das Produkt, sondern der Workspace, der sich über Sitzungen hinweg anreichert.
Persistenz als Kernmechanik: Workspace, Sandbox, agent.md
Jeder Workspace wird laut README auf eine eigene Sandbox abgebildet, mit strukturierten Verzeichnissen und einer Notizdatei agent.md, die Recherche über Sitzungen und Threads hinweg fortschreibt. Das ist der eigentliche Mechanismus, nicht das Modell. Ein Agent, der seine eigenen Notizen beim nächsten Start wieder liest, verhält sich anders als einer, der bei null beginnt.
Daneben stehen zwei getrennte Speicher. Ein Langzeitgedächtnis unter .agents/user/memory/ und .agents/workspace/memory/ hält dauerhafte Nutzerpräferenzen und Wissen über Sandboxes hinweg. Ein benutzerverwalteter Memo-Speicher unter .agents/user/memo/ nimmt PDFs und Markdown-Notizen auf, die der Agent bei Bedarf liest. Die Trennung ist sinnvoll: Präferenzen ändern sich selten, Memos sind Material, das der Nutzer kontrolliert.
Die Architekturskizze im README zeigt zwei PostgreSQL-Pools. Einer trägt App-Daten wie Nutzer, Workspaces, Threads, Turns, BYOK Keys und Automations, der andere den LangGraph Checkpointer für Agent State und Checkpoints. Getrennte Pools für Anwendungszustand und Agentenzustand sind eine bewusste Entscheidung: Checkpoints wachsen schnell und haben ein anderes Lastprofil als Nutzerdaten.
Programmatic Tool Calling: Python statt Rohdaten im Kontextfenster
Der interessanteste technische Punkt ist Programmatic Tool Calling. Statt Rohdaten aus MCP-Servern in das Kontextfenster des Modells zu schütten, schreibt der Agent Python und führt es aus. Das README begründet das mit mehrstufiger Analyse bei deutlich geringerem Token-Verbrauch. Für Finanzdaten ist das naheliegend: eine Zeitreihe mit mehreren tausend Kursen gehört nicht in einen Prompt.
Dazu kommt Progressive Tool Discovery. MCP-Werkzeuge werden zunächst nur als Zusammenfassung in den Kontext geladen, die vollständige Dokumentation landet im Workspace. Der Agent entdeckt Werkzeuge also bei Bedarf. Zusätzlich lassen sich JSON-Tools an Skills binden, die dem Agenten erst nach Aktivierung des Skills sichtbar werden. Das ist eine Kontextbudget-Entscheidung, und sie ist nachvollziehbar, weil ein Finanz-Agent sonst an der schieren Zahl verfügbarer Werkzeugbeschreibungen erstickt.
Die Datenebene ist mehrstufig aufgebaut: native Werkzeuge für schnelle Abfragen, MCP-Server für Massendaten, Charting und mehrjährige Analysen in Sandboxes. Welche Provider konkret angebunden sind, geht aus dem vorliegenden Material nicht hervor. Wer die Beschaffung plant, muss das im Repository oder in der API-Dokumentation unter docs/api/README.md nachschlagen.
Oberfläche, Kanäle und der Sekretär als zweiter Agent
Der Web-Arbeitsplatz bietet laut README Inline-Charts, einen Dateibetrachter für mehrere Formate, TradingView-Charting, Echtzeit-Marktdaten über WebSocket, vom Agenten gezeichnete Chart-Annotationen, ein Quellenpanel pro Turn, teilbare Konversationen und eine Subagenten-Überwachung. Das Quellenpanel ist der Teil, der in der Praxis am meisten zählt. Ein Agent, der eine Zahl ohne Herkunft liefert, ist für Research unbrauchbar.
Subagenten laufen parallel mit isolierten Kontextfenstern, vorbestimmten Werkzeugen und Skills, Zwischensteuerung während der Ausführung und Wiederaufnahme aus Checkpoints. Live Steering erlaubt Folgenachrichten, während der Agent arbeitet. Das ist mehr als Beiwerk: Bei einer Marktanalyse, die Minuten läuft, ist Nachsteuern ohne Abbruch der Unterschied zwischen brauchbar und verschwendet.
Ein zweiter, schneller Agent fungiert als Sekretär. Er legt Workspaces an, stößt tiefe PTC-Analysen im Hintergrund an, überwacht laufende Aufgaben und holt Ergebnisse zurück, alles über Konversationsbefehle mit menschlicher Freigabe. Diese Aufteilung in einen schnellen Koordinator und langsame Analyse-Agenten ist ein bekanntes Muster. Die Freigabeschwelle ist hier wichtig, weil der Sekretär Workspaces und Hintergrundaufgaben anlegt, also Ressourcen verbraucht.
Installation und Betrieb: was das Material tatsächlich hergibt
Das README verlangt Python 3.13 oder neuer. Der Abschnitt Getting Started ist im vorliegenden Text jedoch abgeschnitten, konkrete Installationsbefehle fehlen darin. Verlässlich belegbar sind nur die Repository-Struktur und die Release-Artefakte.
Die Struktur ist explizit: src/ptc_agent/ für den Agentenkern, src/server/ für das Backend, web/ für die Weboberfläche, libs/ptc-cli/ für das TUI und plugins/ für Erweiterungen. Wer aus dem Quellcode startet, muss also mindestens einen Python-Dienst und einen Node-Build für web/ betreiben. Dazu kommen PostgreSQL und Redis, die beide in der Architekturskizze als eigene Komponenten erscheinen.
Redis trägt zwei Aufgaben: einen SSE-Ereignispuffer mit 150K Ereignissen für Reconnect-Replay und einen API-Cache für Marktdaten im SWR-Muster. Der Puffer ist die Voraussetzung dafür, dass ein Browser-Tab neu laden kann, ohne den laufenden Agentenstrom zu verlieren. 150K Ereignisse sind eine Obergrenze, die bei langen Läufen relevant wird. Wer diese Zahl im Betrieb nicht beobachtet, verliert bei sehr langen Sitzungen ältere Ereignisse.
Für Nutzer ohne eigenen Server existiert ein Desktop-Artefakt. Die Releases enthalten desktop-v0.2.3 und desktop-oss-v0.2.3, wobei letzteres im Release-Titel als self-hosted gekennzeichnet ist. Die Existenz zweier Desktop-Varianten deutet auf unterschiedliche Betriebsmodelle hin. Welche davon welche Backend-Abhängigkeiten mitbringt, lässt sich aus dem vorliegenden Material nicht ableiten.
Grenzen: Betreiberlast, Provider-Abhängigkeit und ein stiller Fehlerpfad
LangAlpha ist kein Werkzeug, das man nebenbei startet. FastAPI-Backend, zwei PostgreSQL-Pools, Redis mit Ereignispuffer und Cache, ein React-Frontend und Sandboxes für die Ausführung erzeugter Skripte ergeben eine Betriebsfläche, die kleiner ist als bei einer Handelsplattform, aber größer als bei einem CLI-Werkzeug. Wer nur gelegentlich recherchiert, zahlt diesen Preis ohne Gegenwert.
Die zweite Grenze ist die Datenbeschaffung. Das README spricht von einer mehrstufigen Provider-Hierarchie, nennt aber keine Anbieter. Ohne eigene Verträge oder Schlüssel ist unklar, welche Daten der Agent tatsächlich sieht. Es gibt BYOK Keys in der Datenbank, das Modell ist also auf eigene Schlüssel ausgelegt. Für die Datenebene ist das nicht belegt.
Drittens die Modellschicht. Sie ist als provider-agnostisch beschrieben, mit automatischem Failover bei Fehlern. Failover löst Verfügbarkeit, nicht Qualität. Ein Ausweichmodell kann eine Finanzanalyse anders strukturieren, andere Werkzeugaufrufe wählen und andere Zahlen ziehen. Wer auf Reproduzierbarkeit angewiesen ist, sollte prüfen, ob sich ein Modell festnageln lässt, statt sich auf das Failover zu verlassen.
Viertens die Sicherheitsversprechen. Das README nennt Verschlüsselung im Ruhezustand über pgcrypto, automatische Erkennung und Redaktion von Zugangsdaten, Sandbox-Ausführung und geheime Speicherung pro Workspace. Das sind Zusagen über einen Bereich, in dem Fehler teuer sind. Sie sind im vorliegenden Material nicht durch Tests oder Dokumentation belegt. Wer LangAlpha mit echten Kontodaten oder nicht öffentlichen Research-Notizen betreibt, sollte diese Punkte selbst im Code unter src/server/ nachvollziehen.
Alternative: ein Skript- und Notebook-Ansatz mit LangChain
Die naheliegende Alternative ist kein Konkurrenzprodukt, sondern der Verzicht auf das Harness. Wer bereits mit LangChain oder LangGraph arbeitet, kann einen Agenten mit denselben Bausteinen selbst verdrahten und die Ergebnisse in Jupyter-Notebooks oder Skripten ablegen. Die Unterschiede sind konkret.
Bei einem eigenen Skriptaufbau bestimmt der Entwickler, was im Kontext landet. LangAlpha nimmt ihm das ab, mit Progressive Tool Discovery und PTC, verlangt dafür aber Vertrauen in diese Mechanismen. Bei einem Notebook ist Persistenz eine Datei im Git-Repository, nicht ein Workspace mit Sandbox, agent.md und getrennten Gedächtnisspeichern. Das ist billiger zu betreiben und leichter zu prüfen, verliert aber die Subagenten-Parallelität und die Wiederaufnahme aus Checkpoints.
Der zweite Unterschied ist die Oberfläche. Ein Notebook zeigt Code und Ausgabe. LangAlpha zeigt Charts, Quellenpanel und Subagenten-Fortschritt in einer Weboberfläche. Wer Ergebnisse mit anderen teilen will, gewinnt dadurch. Wer nur für sich rechnet, zahlt für eine Frontend-Codebasis, die er nicht braucht.
Der dritte Unterschied ist die Kanalanbindung. Slack, Discord, Feishu, Telegram und E-Mail-Zustellung für geplante Ergebnisse sind im eigenen Skriptaufbau zusätzliche Integrationen. LangAlpha bringt sie mit, bindet dafür aber an seine Serverarchitektur.
Wartung, Lizenz und was vor der Adoption zu prüfen ist
Das Projekt ist aktiv. Der letzte Push liegt laut Repository-Metadaten auf dem 8. September 2026, die Releases v2026.09.07 und desktop-oss-v0.2.3 stammen vom 7. September 2026. Die Versionsnummer v2026.09.07 folgt einem Datumsschema, das auf häufige Releases hindeutet. Für Betreiber bedeutet das: Upgrade-Pfade müssen funktionieren, sonst wird jede Aktualisierung zum Projekt.
Die Lizenz ist Apache-2.0. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber die Beibehaltung von Copyright- und Lizenzhinweisen sowie eine Änderungsangabe bei modifizierten Dateien. Relevant ist der Patentgrant, der bei rein permissiven Lizenzen fehlt. Für eine Firma, die LangAlpha intern für Research einsetzt, ist das unproblematisch. Wer den Code in ein eigenes Produkt einbettet, muss die Hinweise mitführen. Das ist keine Rechtsberatung, sondern nur der Hinweis, dass die Bedingungen an dieser Stelle konkreter sind als bei MIT.
Offen bleibt die Frage des Betriebsaufwands über Zeit. Zwei PostgreSQL-Pools, ein Redis-Puffer und ein React-Frontend bedeuten, dass ein Upgrade mehrere Komponenten gleichzeitig betreffen kann. Ob es Migrationsskripte zwischen den Releases gibt, geht aus dem vorliegenden Material nicht hervor. Wer den Desktop-OSS-Build nutzt, sollte vor einem Wechsel auf die Servervariante klären, ob die Workspace-Daten überhaupt übertragbar sind.
Der ehrlichste nächste Schritt ist kein Testlauf, sondern eine Inventur: Welche MCP-Server liefert das Repository ohne eigenen Schlüssel mit, welche Skills sind vorgebaut, und welche Verzeichnisse unter .agents/ überleben einen Neustart der Sandbox. Diese drei Antworten entscheiden, ob LangAlpha für den eigenen Rechercheablauf trägt.
Redaktionelles Fazit
Wer Research über Wochen statt in einzelnen Prompts betreibt und bereit ist, FastAPI, PostgreSQL und Redis selbst zu betreiben, findet in LangAlpha einen passenden Rahmen. Für einmalige Datenabfragen ist das Projekt überdimensioniert, ebenso ohne eigene Datenprovider-Verträge. Vor dem Adoptionstest sollten Sie klären, welche MCP-Server ohne eigenen API-Key nutzbar sind, ob der Lizenztext die im README beschriebene Verschlüsselung und Credential-Redaction abdeckt, und wie ein Upgrade von desktop-oss-v0.2.3 auf v2026.09.07 migriert.
Community-Notizen