all-agentic-architectures: 35 Agentenmuster hinter einer einheitlichen run-Schnittstelle

Das Problem: 35 Muster, 35 verschiedene APIs

Wer Agentenmuster aus der Literatur vergleichen will, stolpert zuerst ueber die Verpackung. Reflexion, LATS, Tree of Thoughts, GraphRAG und MemGPT stammen aus unterschiedlichen Arbeiten, und jede Referenzimplementierung bringt eigene Klassennamen, eigene Rueckgabetypen und eigene Annahmen darueber mit, wie ein Modellaufruf auszusehen hat. Ein Vergleich kostet deshalb mehr Zeit fuer Adapter als fuer die eigentliche Frage. Genau hier setzt das Repository an: Laut README kapselt es jedes Muster als Architecture-Klasse mit demselben .run(task)-Aufruf und demselben ArchitectureResult als Rueckgabe. Im Quickstart steht ein Beispiel mit Reflection, max_iterations=2 und target_score=8, bei dem anschliessend result.output und result.metadata["final_score"] gelesen werden. Die Zielgruppe sind damit weniger Endanwender als Ingenieure und Forschende, die mehrere Muster gegeneinander testen oder ein Muster aus einem Notebook in eigenen Code ueberfuehren wollen. Die Themenliste des Repositories (agentic-ai, langchain, langgraph, langsmith) deutet darauf hin, dass LangGraph als Laufzeitumgebung vorausgesetzt wird.

Der deterministic picker als eigentliche These des Repositories

Das README benennt eine technische Disziplin, die es als zentrale Entscheidung des Projekts beschreibt: den deterministic-picker-Pattern. Die Formulierung lautet, jede LLM-as-Scorer-Oberflaeche solle das Modell dazu bringen, sich auf kategoriale Merkmale festzulegen (Booleans, Enums), waehrend Python das entscheidende Signal zusammensetzt. Das ist eine Reaktion auf ein bekanntes Verhalten von Sprachmodellen: Wenn man sie um eine Zahl auf einer kontinuierlichen Skala bittet, driften die Werte in einen engen Bereich, und die Rangfolge zwischen zwei Kandidaten wird unbrauchbar. Der Ausweg besteht darin, die Bewertung in diskrete Fragen zu zerlegen und die Aggregation aus dem Modell herauszunehmen. Nach Angaben des README wird dieses Muster in 13 der 35 Architekturen angewendet, waehrend 9 weitere laut Projektbeschreibung architektonisch immun dagegen seien. Diese Aufteilung ist der interessanteste Teil des Repositories, weil sie eine Designentscheidung sichtbar macht, die in vielen Agenten-Frameworks implizit bleibt. Ob die verbleibenden 13 Architekturen das Problem anders loesen oder es schlicht nicht adressieren, laesst sich aus dem vorliegenden Material nicht ableiten.

Architekturfamilien und der Weg durch die 35 Muster

Das README gruppiert die Muster in Familien, die jeweils eine eigene Frage beantworten. Reasoning & Reflection enthaelt Reflection, Reflexion, Chain-of-Verification, Self-Discover und Constitutional AI, also Schleifen, die eine Antwort durch Selbstkritik verbessern. Sampling & Search umfasst Self-Consistency, Tree of Thoughts, LATS, Mental Loop und Ensemble, also Verfahren, die viele Pfade erzeugen oder einen Baum mit Belohnungen wachsen lassen. Retrieval (RAG) deckt mit Agentic RAG, Corrective RAG, Self-RAG, Adaptive RAG und GraphRAG fuenf Retrieval-Formen ab. Memory enthaelt Episodic + Semantic Memory, Graph Memory, MemGPT, Voyager und Agent Workflow Memory, also Speicherformen, die ueber einzelne Aufrufe hinaus bestehen. Tools & Actions reicht laut README von einem einzelnen Suchwerkzeug bis zu einem echten Chromium-Browser, mit Tool Use, ReAct, Planning, PEV, SWE-Agent und Computer Use. Diese Gruppierung ist nuetzlicher als eine alphabetische Liste, weil sie die Auswahl an der Aufgabe ausrichtet statt am Namen des Verfahrens. Die Notebooks sind durchnummeriert und im README direkt verlinkt, etwa notebooks/22_lats.ipynb oder notebooks/27_graph_rag.ipynb.

Installation und die tatsaechlichen Konfigurationsschluessel

Der Einstieg ist ein pip-Aufruf mit Extras: pip install "agentic-architectures[nebius,faiss,tavily]". Die Extras sind nicht kosmetisch. faiss wird fuer Vektorindizes gebraucht, tavily liefert die Suchwerkzeuge, nebius ist einer der neun unterstuetzten Provider. Wer Retrieval- oder Tool-Architekturen ausprobieren will, muss diese Extras also mitinstallieren, sonst fehlen Laufzeitabhaengigkeiten. Fuer einen Klon aus dem Repository zeigt das README den vollstaendigen Weg: git clone, dann python -m venv .venv, Aktivierung je nach Plattform, danach pip install -e ".[dev,test,docs,nebius,faiss,tavily,networkx]" und cp .env.example .env, in das die API-Schluessel eingetragen werden (im README genannt: NEBIUS_API_KEY). Der Testlauf ist pytest -q, laut README laufen 283 Tests in etwa 30 Sekunden durch. Das ist eine konkrete Zahl aus dem Projekt, kein Benchmark-Ergebnis, und sie bezieht sich auf die Tests, nicht auf Modellqualitaet. Die neun genannten Provider sind Nebius, OpenAI, Anthropic, Groq, Ollama, Together, Fireworks, Mistral und Google; der Zugriff laeuft ueber get_llm().

Notebooks als Beleg, nicht als Demo

Das README beschreibt die Notebooks mit einer Formulierung, die Aufmerksamkeit verdient: Die Theorie sei gegen den aufgezeichneten Lauf geschrieben, nicht gegen synthetische Beispiele. Dazu passt die Angabe 0 MOCKED RUNS in der Kennzahlen-Tabelle. Wenn das zutrifft, unterscheidet es das Repository von der ueblichen Praxis, bei der Beispielausgaben von Hand geglaettet werden. Der praktische Nutzen liegt darin, dass man vor der Adoption sehen kann, welche Ausgaben ein Muster mit einem realen Modell tatsaechlich produziert, inklusive der Stellen, an denen es unschoen wird. Zwei Einschraenkungen bleiben. Erstens sind aufgezeichnete Laeufe Momentaufnahmen: Sie belegen Verhalten, nicht Reproduzierbarkeit, denn Modellversionen und Sampling-Parameter aendern sich. Zweitens haengt der Aussagewert davon ab, welcher Provider und welches Modell im jeweiligen Notebook verwendet wurde; das README nennt die Providerliste, ordnet sie aber nicht den einzelnen Notebooks zu. Wer ein Muster ernsthaft evaluieren will, muss den Lauf mit dem eigenen Modell wiederholen, und genau dafuer ist die einheitliche run-Schnittstelle nuetzlich.

Der 17-Task-Benchmark und die Grenze seiner Aussagekraft

Das Repository betreibt laut Beschreibung ein Leaderboard, das jede Architektur gegen jede relevante Aufgabe antreten laesst, ueber 17 Benchmark-Aufgaben. Der Wert liegt nicht in einer Rangliste, sondern in der Frage, die sie beantwortet: Welches Muster passt zu welcher Aufgabensorte? Ein Vergleich ueber alle 35 Muster hinweg ist nur moeglich, weil der ArchitectureResult-Typ und der run-Aufruf konstant bleiben. Genau hier liegt aber auch die Grenze. Ein Benchmark mit 17 Aufgaben kann pro Aufgabensorte nur wenige Faelle abdecken, und die Ergebnisse gelten fuer die Konfiguration, mit der sie erhoben wurden. Das README macht keine Angaben, die im vorliegenden Material bestaetigen wuerden, mit welchem Modell, bei welcher Temperatur oder zu welchem Zeitpunkt die Zahlen entstanden sind. Wer das Leaderboard als Auswahlgrundlage nimmt, sollte es als Hinweis behandeln, nicht als Messung. Der eigentliche Nutzen des Aufbaus ist methodisch: Er zeigt, wie man Muster unter gleichen Bedingungen vergleicht, und diese Methodik laesst sich mit eigenen Aufgaben und eigenem Modell wiederholen.

Wann das Paket das falsche Werkzeug ist

Die Normierung auf einen gemeinsamen Vertrag ist eine Staerke fuer Vergleiche und eine Schwaeche fuer Produktion. Wer einen einzelnen Agenten mit eng zugeschnittenen Kontrollfluessen, eigenen Retry-Regeln und eigener Persistenz baut, arbeitet gegen die Abstraktion statt mit ihr. Hinzu kommen die Abhaengigkeiten: Das Paket setzt laut README auf LangGraph-Zustandsmaschinen auf, und die Notebooks brauchen je nach Muster zusaetzliche Extras wie faiss, tavily oder networkx. Ein Projekt, das diese Abhaengigkeiten aus Groessen- oder Sicherheitsgruenden nicht aufnehmen will, muss den Code der jeweiligen Architektur herausloesen, und dann ist der Nutzen des Pakets auf das Verstaendnis der Vorlage reduziert. Ein weiterer Punkt betrifft die Kosten: Reflexions- und Suchmuster erzeugen mehrere Modellaufrufe pro Aufgabe. Das README nennt max_iterations und target_score als Parameter, was zeigt, dass die Schleife konfigurierbar ist, aber die Standardwerte sind keine kostenoptimierten Werte. Fuer latenzkritische Pfade sind Muster wie LATS oder Tree of Thoughts allein wegen der Anzahl der Modellaufrufe schwer zu rechtfertigen.

Alternative: direkt auf LangGraph bauen

Die naheliegende Alternative ist, auf der Ebene darunter zu bleiben und die Muster selbst als LangGraph-Graphen zu implementieren. Der Unterschied liegt nicht in den Moeglichkeiten, sondern im Abstraktionsgrad. LangGraph gibt Knoten, Kanten und Zustand vor und ueberlaesst dem Entwickler die Struktur. all-agentic-architectures liefert die Struktur fertig und verlangt dafuer die Anpassung an seinen Vertrag: eine Klasse pro Muster, ein run-Aufruf, ein ArchitectureResult. Wer den deterministic picker als Idee uebernehmen und auf die eigene Bewertungslogik zuschneiden will, ist mit einem eigenen Graphen besser bedient, weil die Aggregationsregel dann im eigenen Code liegt statt in der Bibliothek. Umgekehrt ist der Eigenbau teuer, sobald man mehrere Muster vergleichen will: Jede Variante braucht dann ihre eigene Verdrahtung, und der Vergleich wird wieder durch Adapter verzerrt. Die Wahl ist damit eine Frage des Zeithorizonts. Fuer eine einmalige, tiefe Integration spricht der eigene Graph. Fuer die Frage, welches Muster ueberhaupt in Frage kommt, spricht die Bibliothek.

Wartung, Versionen und die MIT-Lizenz

Das Repository ist nicht archiviert, der letzte Push liegt laut Metadaten im Juni 2026, die letzte Version v0.3.0 stammt vom Mai 2026. Das sind Anhaltspunkte fuer Aktivitaet, keine Zusage. Wichtiger fuer die Planung ist die Kopplung an LangGraph und an neun Provider-SDKs: Aenderungen an einem dieser SDKs koennen eine neue Version des Pakets erzwingen, und wer die Extras einzeln pinnt, muss diese Updates selbst nachziehen. Die Lizenz ist MIT, also permissiv. Sie erlaubt kommerzielle Nutzung, Weitergabe und Aenderung, verlangt aber, dass der Urheberrechtshinweis und der Lizenztext in Kopien oder wesentlichen Teilen der Software erhalten bleiben. Wer Code aus den Notebooks in ein eigenes Produkt uebernimmt, sollte pruefen, ob dabei groessere Teile kopiert werden und ob der Hinweis dann mitgefuehrt werden muss. Das ist keine Rechtsberatung, sondern ein Hinweis auf die Stelle, an der man sie einholen sollte. Zu beachten ist auch, dass die Notebooks selbst nicht unter der MIT-Lizenz des Pakets stehen muessen, wenn sie separat lizenziert sind; das vorliegende Material sagt dazu nichts.

Redaktionelles Fazit

Wer mehrere Agentenmuster vergleichen will, ohne fuer jedes eine eigene Bibliothek zu lernen, findet hier eine einheitliche run-Schnittstelle und ausgefuehrte Notebooks als Belegmaterial. Wer einen einzelnen, tief integrierten Agenten fuer eine konkrete Produktionsanwendung baut, ist mit einem direkt auf LangGraph aufsetzenden Projekt oft naeher an den eigenen Anforderungen, weil hier jede Architektur bewusst auf denselben Vertrag normiert wird. Vor dem Adoptieren zuerst klaeren: welche Provider-Extras die eigene Umgebung braucht, ob die Benchmark-Zahlen mit dem eigenen Modell reproduzierbar sind, und ob die permissive MIT-Lizenz zu den eigenen Weitergabepflichten passt.

Offizielle Quellen

1. FareedKhan-dev/all-agentic-architectures on GitHub
2. License: MIT
3. Project website
4. README
5. Releases