BeeAI Framework: Python und TypeScript für Multi-Agent-Systeme

Zwei Bibliotheken, ein Repository, zwei Versionsstände

Das Repository enthält zwei unabhängig veröffentlichte Bibliotheken. Die Release-Liste nennt python_v0.1.83 vom 19. August 2026 und typescript_v0.1.30 vom 24. Juli 2026. Zwischen den jüngsten Veröffentlichungen beider Sprachen liegt damit fast ein Monat, und die Zählung ist unterschiedlich: Python steht bei Patch 83, TypeScript bei Patch 30. Wer beide Sprachen im selben Produkt einsetzt, bekommt also nicht automatisch denselben Funktionsstand. Die README beschreibt das Projekt als Toolkit für intelligente, autonome Agenten und Multi-Agent-Systeme und verlinkt getrennte Starter-Templates: beeai-framework-py-starter für Python, beeai-framework-ts-starter für TypeScript. Das ist kein Detail am Rand, sondern die zentrale Strukturentscheidung. Ein Team, das eine Python-Pipeline und ein TypeScript-Frontend parallel entwickelt, muss zwei Upgradepfade pflegen und zwei Changelogs lesen. Die gemeinsame Dokumentation unter framework.beeai.dev/introduction/welcome täuscht darüber hinweg, dass der Code darunter getrennt ist.

Der Requirement Agent als Antwort auf unzuverlässige LLM-Ausgaben

Das auffälligste Feature ist der Requirement Agent, in der README als experimentell geführt und über framework.beeai.dev/experimental/requirement-agent dokumentiert. Die Beschreibung im Feature-Table lautet: vorhersagbares, kontrolliertes Verhalten über verschiedene LLMs hinweg, indem Regeln gesetzt werden, die der Agent befolgen muss. Das zielt auf ein konkretes Problem: Derselbe Prompt liefert bei GPT, Claude und einem offenen Modell unterschiedliche Entscheidungen, und in einer Produktionskette ist das schwer zu testen. Statt den Prompt zu optimieren, deklariert man Bedingungen, an die sich der Agent halten soll. Die README bleibt hier knapp. Sie nennt weder die Syntax der Regeln noch, wie Verstöße behandelt werden, ob der Lauf abgebrochen wird, ob ein Retry erfolgt oder ob die Regel nur als Hinweis in den Kontext geht. Wer den Requirement Agent produktiv einsetzen will, muss die experimentelle Dokumentationsseite lesen, bevor er Architekturentscheidungen darauf stützt. Der Begriff experimentell im Änderungsprotokoll vom 3. Juni 2025 ist dabei ernst zu nehmen.

Backend, Tools und Protokolle: die Bausteine im Überblick

Vier Module strukturieren das Framework. Das Backend-Modul, im Februar 2025 für TypeScript eingeführt, vereinheitlicht den Zugang zu KI-Diensten wie Chat und Embedding, laut README mit Unterstützung für mehrere Anbieter. Das Tools-Modul erweitert Agenten um Werkzeuge, darunter eine MCP-Tool-Anbindung. Das Agents-Modul liefert die Agenten selbst. Das Workflows-Modul, im Januar 2025 für TypeScript eingeführt, dient dem Bau von Multi-Agent-Systemen. Dazu kommen Protokollintegrationen: ACP und MCP kamen im Mai 2025 für Python hinzu. ACP ist inzwischen unter dem Dach der Linux Foundation Teil von A2A geworden, wie eine Notiz vom 25. August 2025 festhält. Für bestehende Integrationen bedeutet das eine Migrationsfrage, deren Umfang die README nicht beziffert. Der Verweis auf die Diskussion im Repository ist der einzige Anhaltspunkt, den das Material liefert.

Installation und erste Schritte

Die README verweist für den Einstieg auf den Abschnitt Installation im Repository und auf den Getting-Started-Guide. Konkrete Befehle nennt der vorliegende Auszug nicht. Das ist eine Lücke, die man beim Lesen einplanen sollte: Wer wissen will, ob die Bibliothek über pip oder uv installiert wird, welcher Paketname gilt und welche Umgebungsvariablen für die Anbieter im Backend-Modul nötig sind, findet das nicht im README-Text, sondern nur in der verlinkten Dokumentation oder in den Starter-Templates. Die Starter-Repositories beeai-framework-py-starter und beeai-framework-ts-starter sind dafür der praktischere Einstieg, weil sie ein lauffähiges Grundgerüst mitbringen. Ein Punkt lässt sich aus dem Repository-Aufbau dennoch ableiten: Die Beispiele liegen sprachgetrennt unter python/ und typescript/, und die Workflow-Beispiele sind unterschiedlich alt. Das Beispiel competitive-analysis im TypeScript-Verzeichnis stammt aus dem Januar 2025, das Beispiel multiAgents.ts aus dem Dezember 2024. Wer sich an Beispielen orientiert, arbeitet teilweise mit Code, der älter ist als die aktuelle Bibliotheksversion.

Wo das Framework an Grenzen stößt

Die wichtigste Einschränkung steht im Änderungsprotokoll selbst: Der Requirement Agent ist experimentell. Das heißt, die Regelsyntax und das Laufzeitverhalten können sich zwischen python_v0.1.83 und einer späteren Version ändern. Ein zweiter Punkt betrifft die Protokolle. ACP wurde in A2A überführt, und die README verweist lediglich auf eine Diskussion. Ob bestehende ACP-Integrationen weiter funktionieren, ob es einen Kompatibilitätsmodus gibt und bis wann, geht aus dem Material nicht hervor. Drittens die Sprachkluft: Wer eine Funktion zuerst in TypeScript sieht, etwa den Backend-Modul-Zusatz vom Februar 2025 oder die DeepSeek-R1-Unterstützung vom Januar 2025, kann nicht davon ausgehen, dass sie in Python zeitgleich verfügbar ist. Umgekehrt kamen ACP und MCP zuerst für Python. Das Framework ist daher die falsche Wahl, wenn ein Team eine sprachübergreifend identische API mit garantiertem Funktionsgleichstand braucht. Ebenso ungeeignet ist es für sehr einfache Einzelaufrufe, bei denen ein direkter SDK-Aufruf weniger Schichten bedeutet.

Abgrenzung zu LangChain und CrewAI

Der Unterschied liegt nicht im Funktionsumfang, sondern im Steuerungsmodell. LangChain und CrewAI bauen Agentenverhalten überwiegend aus Prompts, Rollenbeschreibungen und Ketten von Aufrufen zusammen. BeeAI setzt mit dem Requirement Agent einen anderen Akzent: Regeln, die der Agent einhalten muss, statt Formulierungen, die er interpretieren soll. Das ist ein Trade-off. Regelbasierte Steuerung lässt sich leichter testen und über Modellwechsel hinweg stabiler halten, nimmt dem Agenten aber Flexibilität in Fällen, die der Regelautor nicht vorhergesehen hat. Der zweite Unterschied ist die Sprachstrategie. LangChain hat eine Python- und eine JavaScript-Version mit eigener Release-Kadenz, CrewAI ist stark auf Python ausgerichtet. BeeAI verfolgt beide Sprachen ausdrücklich parallel, was für gemischte Stacks attraktiv ist, aber die oben beschriebene Versionskluft erzeugt. Wer bereits tief in LangChain steckt, findet hier keinen Grund zum Wechsel, solange die Regelsteuerung nicht das eigentliche Problem ist.

Wartung, Lizenz und Upgrade-Kosten

Das Repository ist nicht archiviert, der letzte Push datiert auf den 8. September 2026, also kurz nach der jüngsten Python-Veröffentlichung. Das Muster deutet auf aktive Pflege hin, ohne dass sich daraus etwas über Reaktionszeiten auf Fehlerberichte ableiten lässt. Die Upgrade-Kosten hängen an den Patch-Nummern. Python bei 0.1.83 bedeutet viele kleine Veröffentlichungen. Solche Serien enthalten erfahrungsgemäß sowohl Fehlerkorrekturen als auch Verhaltensänderungen, und die README verweist für Details auf die Releases-Seite. Wer die Bibliothek einsetzt, sollte den Changelog pro Upgrade lesen, nicht nur die Hauptversionsnummer prüfen. Die Lizenz ist Apache-2.0, eine permissive Lizenz mit einer ausdrücklichen Patentgewährung und Pflichten bei Änderungen an Dateien mit Lizenzhinweisen. Das Framework steht zudem unter dem Dach der LF AI & Data, was die Governance-Frage klärt. Rechtlich verbindliche Aussagen zur Eignung für einen konkreten Fall ersetzt das nicht.

Redaktionelles Fazit

Einsteigen sollten Teams, die Agenten mit expliziten Regeln bauen und bereit sind, die Python- und die TypeScript-Bibliothek als zwei getrennte Projekte mit eigenen Versionsständen zu behandeln. Wer eine einzelne, API-stabile Abstraktion über beide Sprachen erwartet, ist hier falsch. Vor dem ersten Commit lohnt der Blick in das Verzeichnis python/ oder typescript/ des jeweiligen Starters, weil die Versionsnummern auseinanderlaufen: python_v0.1.83 und typescript_v0.1.30 liegen rund einen Monat auseinander.

Offizielle Quellen

1. i-am-bee/beeai-framework on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases