Langroid: Multi-Agent-Programmierung ohne Langchain

Welches Problem Langroid löst und für wen es gedacht ist

Ein einzelner LLM-Aufruf beantwortet eine Frage. Sobald mehrere Schritte nötig sind, mehrere Werkzeuge ins Spiel kommen oder ein Dokument durchsucht werden muss, reicht das nicht mehr. Dann braucht man Zustand, Rollen und eine Regel, wer wann das Wort hat. Genau hier setzt Langroid an: Das README beschreibt das Framework als Python-Bibliothek, in der man Agenten einrichtet, ihnen optional einen LLM, einen Vektorstore und Werkzeuge mitgibt, ihnen Aufgaben zuweist und sie das Problem durch Nachrichtenaustausch lösen lässt. Die Zielgruppe sind Entwickler, die solche Abläufe selbst im Code kontrollieren wollen, statt eine Plattform mit grafischer Oberfläche zu benutzen. Das Projekt stammt laut README von Forschern der CMU und der UW-Madison. Es richtet sich an Python-Entwickler, nicht an Fachanwender ohne Programmiererfahrung.

Agenten als Aktoren: der Nachrichtenaustausch als Kern

Das README nennt als Vorbild ausdrücklich das Aktormodell, betont aber, dass man darüber nichts wissen muss. Die Bausteine sind Agent, Task und Nachricht. Ein Agent ist ein Objekt mit eigener Konfiguration, ein Task beschreibt, was zu tun ist, und die Zusammenarbeit entsteht dadurch, dass Agenten einander Nachrichten schicken. Ein Werkzeugaufruf wird laut README als ToolMessage abgebildet. Diese Darstellung ist der Grund, warum sich MCP-Server anbinden lassen: Der mitgelieferte Adapter übersetzt die Werkzeuge des Servers in ToolMessage-Instanzen, sodass jeder Agent darauf zugreifen kann. Bemerkenswert ist, was fehlt. Langroid benutzt laut README weder Langchain noch ein anderes LLM-Framework. Es gibt also keine Kette aus vorgefertigten Komponenten, sondern eine kleine Menge eigener Abstraktionen, die man selbst verdrahtet. Wer gewohnt ist, Abläufe aus fertigen Bausteinen zusammenzustecken, muss hier mehr selbst schreiben.

Installation und die erste Konfiguration

Das Paket liegt auf PyPI, der übliche Weg führt über pip install langroid. Die Dokumentation verweist zusätzlich auf ein Colab-Notebook und ein separates Repository langroid-examples mit weiteren Skripten. Der Einstieg im README sieht so aus: Zuerst wird eine Konfiguration vom Typ lm.OpenAIGPTConfig angelegt, in der chat_model gesetzt wird. Der Kommentar im Beispiel nennt lm.OpenAIChatModel.GPT4o, alternativ eine Zeichenkette wie "ollama/mistral". Aus dieser Konfiguration entsteht mit lm.OpenAIGPT ein Modellobjekt, das man direkt mit mdl.chat ansprechen kann. Für den Agenten wird lr.ChatAgentConfig mit dem Feld llm befüllt, daraus entsteht lr.ChatAgent. Aufrufe laufen dann über agent.llm_response. Zwei Dinge sind an diesem Ausschnitt wichtig. Das Modell wird über eine OpenAI-kompatible Schnittstelle angesprochen, weshalb laut README praktisch jedes Modell funktioniert, auch lokal über Ollama. Und die Konfiguration ist ein Datenobjekt, das man weiterreichen kann, statt verstreuter Parameter im Code.

Wo Langroid an Grenzen stößt

Der Nachrichtenaustausch zwischen Agenten ist mächtig, aber er ist kein Ersatz für eine deterministische Ablaufsteuerung. Wer eine feste Reihenfolge von Schritten braucht, bei der jeder Schritt garantiert ausgeführt wird, baut das besser als gewöhnliche Python-Funktionen und setzt das LLM nur an den Stellen ein, an denen wirklich Sprache verarbeitet werden muss. Ein zweiter Punkt betrifft die Modelle. Das README nennt als Beispiel für lokale Nutzung Mistral-7b-instruct-v0.2 und verweist auf ein Skript, das strukturierte Informationen ausschließlich mit einem lokalen Modell extrahiert. Kleine Modelle halten sich aber nicht zuverlässig an Formatvorgaben, und das Framework kann das nicht kompensieren. Drittens die Versionslage: Zwischen 0.67.5 am 31. August und 0.67.7 am 2. September 2026 liegen drei Veröffentlichungen in drei Tagen. Diese Kadenz spricht für Aktivität, bedeutet aber auch, dass man die Version pinnen sollte. Ob und wie das Projekt Breaking Changes dokumentiert, lässt sich aus dem vorliegenden Material nicht beurteilen.

CrewAI, Autogen und LangChain als Alternativen

Das README zitiert einen Anwender, dessen Firma nach eigenen Angaben CrewAI, Autogen, LangChain und Langflow geprüft und sich dann für eine interne Anpassung von Langroids Orchestrierung entschieden hat. Solche Zitate sind kein Benchmark, und die Zahlen darin lassen sich nicht nachprüfen. Interessant ist der genannte Grund: Einrichtung und Flexibilität. Der Unterschied liegt im Umfang. LangChain ist ein breites Ökosystem aus Integrationen und vorgefertigten Ketten, in dem man für viele Dienste fertige Anbindungen findet. Langroid geht den umgekehrten Weg und beschränkt sich auf Agent, Task und Nachricht. CrewAI stellt dagegen Rollen und Teams stärker in den Vordergrund, während Autogen die Konversation zwischen Agenten als zentrales Muster behandelt. Wer viele fremde Dienste anbinden muss, ist mit einem breiteren Ökosystem schneller. Wer die Kontrolle über den Ablauf behalten will, kommt mit weniger Schichten weiter.

Wie viel Pflege das Projekt verlangt

Die Lizenz ist MIT, was die Nutzung in kommerziellen Produkten erlaubt. Wer das Projekt weiterverbreitet oder verändert, muss den Lizenztext beibehalten. Das ist keine Rechtsberatung, im Zweifel gehört die Lizenzfrage zu einer juristischen Prüfung. Der Pflegeaufwand hängt an der Versionskadenz. Drei Veröffentlichungen in drei Tagen bedeuten, dass man nicht jede Version mitnehmen muss. Sinnvoll ist es, die Version in der eigenen Abhängigkeitsdatei festzuschreiben und Aktualisierungen bewusst zu ziehen, nachdem die eigenen Tests durchgelaufen sind. Das Repository bringt laut den Badges im README eine Pytest-Pipeline und eine Coverage-Messung mit, dazu Multi-Architektur-Docker-Images. Ein Teil der Arbeit wird also vom Projekt selbst getragen. Was bleibt, ist die Prüfung der eigenen Abläufe, weil sich das Verhalten von Modellen ändert, unabhängig von der Framework-Version.

Für wen sich der Einstieg lohnt

Langroid passt zu Teams, die in Python arbeiten und mehrere Agenten mit unterschiedlichen Rollen und Werkzeugen kombinieren wollen, ohne eine große Framework-Abhängigkeit einzugehen. Der Verzicht auf Langchain ist dabei kein Detail, sondern eine Architekturentscheidung: Man bekommt weniger fertige Bausteine und dafür weniger Schichten zwischen dem eigenen Code und dem Modell. Für Anwender, die eine grafische Oberfläche erwarten oder Abläufe ohne Programmierung zusammenklicken wollen, ist das Projekt die falsche Wahl. Ebenso für Vorhaben, in denen jeder Schritt deterministisch garantiert sein muss. Der nächste konkrete Schritt ist ein Blick in das Notebook Langroid_quick_start.ipynb und in das Repository langroid-examples, um die Beispiele gegen das eigene Modell laufen zu lassen, bevor man sich auf die Abstraktionen festlegt.

Redaktionelles Fazit

Wer mehrere LLM-Agenten mit klarer Rollenverteilung in Python bauen will und dabei auf Langchain verzichten möchte, findet in Langroid ein kompaktes, MIT-lizenziertes Framework. Wer eine fertige Plattform mit grafischer Oberfläche oder eine breite Integrationsbibliothek sucht, ist hier falsch. Vor dem ersten produktiven Einsatz sollte man die Beispiele im Repository gegen das eigene Modell laufen lassen, die Abhängigkeiten im Lockfile fixieren und die Versionsnummer pinnen, weil zwischen 0.67.5 und 0.67.7 nur wenige Tage liegen.

Offizielle Quellen

1. langroid/langroid on GitHub
2. License: MIT
3. Project website
4. README
5. Releases