Open-Source-KI-Agenten: welchen du als Basis wählst
Die Wahl eines Open-Source-Agenten läuft auf vier Prüfungen hinaus: eine Lizenz, die dein Geschäftsmodell erlaubt, eine Architektur, die du wirklich lesen kannst, aktuelle Wartung durch mehr als eine Person und eine Werkzeugschnittstelle, die du ohne Fork erweiterst. Sterne beantworten davon nichts.
Was ein Agenten-Projekt dir tatsächlich abnimmt
Ein Agenten-Framework bündelt vier Dinge: eine Schleife, die entscheidet, was als Nächstes passiert, eine Möglichkeit, dem Modell Werkzeuge bereitzustellen, eine Form von Gedächtnis oder Zustand und Fehlerbehandlung für den Fall, dass das Modell Unsinn zurückgibt. Die Schleife ist der einfache Teil — deshalb gibt es so viele Frameworks. In der Werkzeugschnittstelle und der Fehlerbehandlung stecken die Monate Arbeit.
Prüfe genau diese beiden. Wenn das Erweitern der Werkzeuge bedeutet, im Quelltext des Frameworks zu editieren, hast du keinen Baustein übernommen, sondern einen Fork.
Die vier Prüfungen, auf die es ankommt
| Prüfung | Worauf achten | Warnsignal |
|---|---|---|
| Lizenz | MIT, Apache-2.0 oder BSD, wenn du verkaufen willst | AGPL oder eine eigene „source-available“-Lizenz |
| Lesbare Architektur | Du verfolgst einen Ablauf in etwa einer Stunde von Anfang bis Ende | Abstraktionsschichten ohne ein Beispiel, das sie nutzt |
| Wartung | Commits der letzten 90 Tage von mehr als einer Person | Eine heldenhafte Person, Issues seit Monaten unbeantwortet |
| Erweiterbarkeit | Werkzeuge lassen sich von außen registrieren | Ein neues Werkzeug heißt: Framework-Dateien ändern |
Warum Sternzahlen in die Irre führen
Sterne messen den Moment, in dem ein Projekt entdeckt wurde, nicht ob es heute ein tragfähiges Fundament ist. Ein Repository, das vor anderthalb Jahren trendete, kann seitdem verwaist sein; ein Projekt mit 400 Sternen und drei aktiven Maintainern ist meist die bessere Wahl als eines mit 40.000 und keinem.
Sterne unterscheiden außerdem nicht zwischen Demo und Produkt. Viele der meistgesternten Agenten-Repositories entstanden, um eine Idee zu illustrieren — und ihre Autorinnen und Autoren schreiben das in der README, wenn man über das animierte GIF hinausliest.
Projekt und Vorhaben zusammenbringen
- Internes Werkzeug: Lesbarkeit und Selbst-Hosting vor Funktionsumfang. Du wirst es abends um sechs debuggen.
- Produkt: erst die Lizenz, dann die Erweiterbarkeit. Ein Lizenzproblem nach dem Launch ist teurer als alles andere auf dieser Liste.
- Prototyp zur Nachfrageprüfung: nimm, was am schnellsten zur Demo führt, und rechne damit, es zu ersetzen.
- Aufsatz auf bestehendes SaaS: ein Projekt mit echter Protokollebene wie MCP schlägt eines mit fest verdrahteten Integrationen.
Die Suche abkürzen
Diese Prüfungen sauber durchzuführen kostet etwa eine Stunde pro Kandidat — weshalb die meisten sie überspringen und es später bereuen. Der RepoLoot-Katalog nimmt den strukturellen Teil vorweg: Funktion, gelöstes Problem, Baumöglichkeiten, Zielgruppe und Umsetzungsaufwand, wobei die Identität des Repositories erst sichtbar wird, wenn du dich entschieden hast.
Häufige Fragen
- Wie wähle ich ein Open-Source-Framework für KI-Agenten?
- Prüfe vier Dinge: eine Lizenz, die zu deinen kommerziellen Plänen passt, eine Architektur, die du in etwa einer Stunde durchgängig nachvollziehst, Wartungsaktivität der letzten 90 Tage von mehr als einer Person, und die Möglichkeit, neue Werkzeuge von außen zu registrieren, ohne das Framework zu forken.
- Sind GitHub-Sterne ein gutes Auswahlkriterium?
- Nein. Sterne halten fest, wann ein Projekt entdeckt wurde, nicht ob es heute gepflegt und geeignet ist. Ein Projekt mit 400 Sternen und drei aktiven Maintainern ist meist das bessere Fundament als eines mit 40.000 und keinem.
- Welche Lizenz brauche ich, wenn ich mein Produkt verkaufen will?
- MIT, Apache-2.0 oder BSD. AGPL und eigene „source-available“-Lizenzen sind eine Entscheidung, die vor dem Bauen mit juristischer Beratung fällt, nicht danach.