Apache Burr: Zuverlässige KI-Agenten und Anwendungen entwickeln

• Apache Burr ist ein Framework, mit dem sich entscheidungsbasierte KI-Anwendungen in Python entwickeln lassen – von einfachen Chatbots bis hin zu komplexen Multi-Agenten-Systemen
• Anwendungen werden als Menge von Aktionen und Übergängen definiert und ohne DSL oder YAML nur mit Python-Funktionen und Decorators geschrieben
• Die Burr UI bietet Monitoring, Debugging und Nachverfolgung für jeden Ausführungsschritt, sodass sich Zustandsänderungen in Echtzeit prüfen lassen
• Zustände können auf Datenträgern, in Datenbanken oder in benutzerdefinierten Backends gespeichert werden; außerdem lässt sich die Ausführung an Unterbrechungspunkten fortsetzen, mit Unterstützung für menschliche Eingaben und parallele Ausführung
• Die Integration mit bestehenden Tools wie OpenAI, Anthropic, LangChain, FastAPI und PostgreSQL ist möglich, ohne Lock-in-Effekt oder Wrapper

---

Zuverlässige KI-Agenten und Anwendungen entwickeln

• Apache Burr ist ein Apache Incubating Project, das die Entwicklung von Anwendungen mit Entscheidungslogik vereinfacht
• Der Anwendungsbereich reicht von einfachen Chatbots bis zu komplexen Multi-Agenten-Systemen
• Die Implementierung erfolgt in reinem Python und folgt dem Prinzip „no magic“
• Als öffentliche Kennzahlen werden 1.641 GitHub Stars, 379k+ PyPI-Downloads und 457+ Discord-Mitglieder angezeigt

Einfache und leistungsfähige Python-API

• Burr bietet eine kombinierbare Schnittstelle, mit der sich alles von Chatbots bis zu Multi-Agenten-Systemen aufbauen lässt
• Im Beispielcode wird mit burr.core sowie action, State und ApplicationBuilder eine chat-Aktion definiert
• @action(reads=["messages"], writes=["messages"]) legt fest, welche Zustände gelesen und geschrieben werden
• ApplicationBuilder() konfiguriert Aktionen, Übergänge, den Initialzustand und den lokalen Tracker und erstellt anschließend die Anwendung
• Im Ausführungsbeispiel wird der LLM-Client in der Form app.run(halt_after=["chat"], inputs={"llm_client": client}) als Eingabe übergeben

Erforderliche Bausteine für den Aufbau von KI-Anwendungen

• Simple Python API definiert Anwendungen als Menge aus Aktionen und Übergängen und verwendet dazu ausschließlich Python-Funktionen und Decorators, ohne DSL oder YAML
• Built-in Observability ermöglicht mit der Burr UI das Echtzeit-Monitoring, Debugging und Nachverfolgen aller Anwendungsschritte
• Persistence & State Management speichert Zustände automatisch auf Datenträgern, in Datenbanken oder in benutzerdefinierten Backends und ermöglicht das Fortsetzen ab Unterbrechungspunkten
• Human-in-the-Loop kann die Ausführung an jedem Schritt anhalten und auf menschliche Eingaben warten, was sich für Freigabe-Workflows und interaktive Agenten eignet
• Branching & Parallelism unterstützt parallele Aktionsausführung, fan out / fan in, den Aufbau komplexer DAGs und die Kombination von Unteranwendungen
• Testing & Replay erhöht das Vertrauen in KI-Systeme durch das Wiedergeben früherer Ausführungen, Unit-Tests einzelner Aktionen und die Verifikation von Zustandsübergängen

Integration in bestehende Stacks

• Burr integriert sich in bereits verwendete Tools und Frameworks und erfordert weder Lock-in-Effekt noch Wrapper
• Als LLM-Integrationen werden OpenAI, Anthropic und Instructor genannt
• Als Framework-Integrationen werden LangChain, Hamilton und Haystack genannt
• Als UI- und Serving-Integrationen werden Streamlit und FastAPI genannt
• Als Integrationen für Validierung und Datenspeicher werden Pydantic und PostgreSQL genannt
• Die vollständige Integrationsliste ist in der Dokumentation zu finden

Nutzungserfahrungen von Entwicklern und Teams

• Peanut Robotics berichtet, nach der Bewertung mehrerer LLM-Frameworks sei das State Management von Burr eine starke Lösung für die Bereitstellung von Robotern auf Basis KI-gestützter Entscheidungslogik gewesen
• Watto.ai berichtet, dass sich modulare KI-Anwendungen leicht erstellen lassen und die UI das Debugging vereinfacht
• Paxton AI hebt hervor, dass Burr nicht nur wegen KI auf seltsame oder schwer verständliche Konzepte setzt
• Provectus berichtet, dass Burrs State Management hilfreich für das Erstellen von State-Snapshots, Debugging, Replay und den Aufbau von Evaluierungsfällen ist
• CognitiveGraphs berichtet, dass Burr im Vergleich zu verschiedenen agentischen LLM-Plattformen wie LangChain, CrewAi, AutoGen und Agency Swarm ein robusteres Framework für das Design komplexer Abläufe bietet
• TaskHuman berichtet, nach dem Wechsel von LangChain zu Burr innerhalb weniger Stunden gestartet zu sein und die gesamte Codebasis auf Burr umgestellt zu haben

Community und Projektstatus

• Die Community dient als Raum, um Hilfe zu bekommen, Projekte zu teilen und zur Zukunft von Burr beizutragen
• Beteiligungsmöglichkeiten gibt es über Discord, GitHub und Twitter / X
• Projektressourcen verlinken auf Dokumentation, Beispiele, YouTube, Roadmap und Changelog
• Apache Burr ist ein Projekt in der Inkubationsphase bei der Apache Software Foundation und wird vom Apache Incubator unterstützt
• Der Inkubationsstatus spiegelt nicht zwangsläufig den Reifegrad oder die Stabilität des Codes wider, zeigt jedoch an, dass noch keine vollständige Zustimmung der ASF vorliegt

[GN⁺]

Hacker-News-Kommentare

• Bei Agent-Frameworks halte ich mein Urteil noch zurück, und ihr Nutzen hängt stark von der Art des Agenten ab. Es ist zum Beispiel etwas anderes, ob man innerhalb von 3 Sekunden eine ausreichend gute Antwort liefern muss oder ob ein einzelnes Problem 3 Stunden lang bearbeitet werden soll.
  Letztlich lassen sich Agenten auf Kontextaufbau, LLM-Aufrufe, das Ausführen angeforderter Tool-Aufrufe, das Parsen der finalen Modellausgabe und die Rückgabe ans Frontend herunterbrechen. Es gibt Erweiterungen wie Memory oder asynchrone Tool-Aufrufe, aber aus Sicht klassischer Softwareentwicklung ist das nicht so komplex.
  Alle wollen ihr eigenes Agent-Framework bauen, aber wenn man einen konkreten Agenten bauen muss, ist 1:1-Code, der genau auf diesen Agenten zugeschnitten ist, meiner Meinung nach deutlich einfacher und besser wartbar. Die Abstraktionen von Frameworks verdecken oft die Kernlogik und stehen eher im Weg; am Ende muss man sich nach den vom Framework gewählten Abstraktionen richten, was vom eigentlichen Ziel abweichen kann.

  • Der Kern agentischer Systeme besteht meiner Meinung nach nicht darin, Agenten zu verwenden, sondern sie nur dann einzusetzen, wenn sie wirklich nötig sind. Ein funktionierendes System braucht Pipelines/Rezepte, um mehrstufige Abläufe auszudrücken, ein Betriebssystem, das Modell- und Human-in-the-Loop-Schritte über mehrere Agenten-Worker-Pools hinweg zuverlässig ausführt, sowie Verwaltung, Deployment, Sicherheit und Berechtigungen für umfangreiche Skills, bei denen möglichst viel per Code erledigt wird, und ein Kontextmanagement, das den richtigen Kontext in die richtige Session bringt.
    Dazu kommen Projektmanagement für Tickets, Abhängigkeiten, Fortschritt und das Neustarten festgefahrener Tickets, das Speichern von Gesprächsverläufen sowie Funktionen für Memory, Träumen und kumulatives Lernen, Observability für Kosten und Nutzung, Prompt-Evaluierung und automatische Anpassung, der Wechsel zwischen Modellanbietern und das Pinning von Modellversionen sowie Sandboxes, in denen echte Sessions laufen können.
    Das muss man nicht alles von einem Anbieter beziehen, aber in den meisten Fällen sollte man sich nicht an einen einzelnen Modellanbieter binden und den eigenen Kontext sowie kumulatives Lernen selbst besitzen.
  • Das schwerwiegendste Problem bei den meisten Agent-Frameworks ist, dass sie die Kernlogik verdecken. Man sollte klar sehen können, was tatsächlich an das Sprachmodell gesendet wird und was zurückkommt.
    Alles in agentischen Anwendungen wird letztlich als Tokensequenz oder Anbieteraufruf umgesetzt, daher sollte das auf fast jeder Ebene der Anwendung deutlich sichtbar sein.
  • Ähnliche Gedanken hatte ich auch bei Dutzenden Frontend-Frameworks. Sie laden einem gewaltige Abstraktion und Komplexität auf, für einen möglichen Nutzen in der Zukunft, der wahrscheinlich nie eintritt.
    Trotzdem brauchen Leute etwas zu tun oder interessante Spielzeuge, und „die nächste Person“ ist den meisten offenbar nicht besonders wichtig, also scheint es akzeptabel, ihr die Ergebnisse bezahlter Spielzeit aufzubürden.
  • Dem Ansatz, 1:1-Code für einen bestimmten Agenten zu schreiben, stimme ich bis zu einem gewissen Grad zu. Wenn man aber bei einem neuen Agenten neue Techniken oder Ansätze entwickelt, stellt sich aus Wartungssicht die Frage, wie und ob man ältere Agenten aktualisieren will.
    Apache Burr unterstützt oder wird wohl ein steckbares Vektor-RAG-System unterstützen, aber ich brauche eher einen Ansatz, bei dem Dokumente dem Kontext hinzugefügt und als Teil des aktualisierten Systemprompts erhalten bleiben, mit sehr spezifischer Feinabstimmung in diesem Prozess. Das ist eine maßgeschneiderte Nutzung des bestehenden RAG-Konzepts und passt nicht gut zu einem bestimmten Framework.
    Für meinen Anwendungsfall ist eine maßgeschneiderte Implementierung richtig, aber die Engineering-Entscheidungen zur Aktualisierung älterer Agenten bleiben bestehen.
  • Der Vorteil von Frameworks liegt nicht unbedingt darin, dass das Schreiben des eigentlichen Agenten einfacher wird, sondern eher bei Tools und Observability. LangChain kann man in vieler Hinsicht kritisieren, aber genau das hat es sehr früh sehr deutlich gezeigt.
    Einen Chatbot von Grund auf selbst zu bauen kann einfach oder sogar einfacher sein, aber sobald man Observability oder Tracing hinzufügen muss, sieht die Sache anders aus. Wenn man mit nur einer zusätzlichen Umgebungsvariable sämtliches Tracing in der UI nahezu ohne weiteren Aufwand durchsehen kann, ist eine Eigenlösung schwer konkurrenzfähig.

• Ich frage mich, ob diese Seite mit https://vorpus.github.io/performativeUI/ erstellt wurde.
  Sie erfüllt so ziemlich jedes denkbare Klischee einer KI-generierten Landingpage. Oder ist das absichtlich als Satire gemeint?

• Ich nutze dieses Framework gern in privaten und beruflichen Projekten. Es war gut, einen zuverlässigen zustandsbehafteten Workflow für KI-Modelle und kostenlose Observability zu bekommen.
  Ich habe ein Tool daran gekoppelt, das die Burr-Zustandsmaschine über MCP mountet und dem Agenten Leitplanken gibt; selbst wenn die Zustandsmaschine noch so komplex wird, sind die MCP-Tools auf die Navigation innerhalb der Zustandsmaschine beschränkt: https://github.com/msradam/theodosia
  Im Moment arbeite ich daran, Skills in Zustandsmaschinen umzuwandeln. Viele populäre Skills sind bereits als Abfolge von Schritten geschrieben, denen KI-Modelle folgen sollen, und ich denke, dass man sie mit Burrs expliziten Funktionen robuster machen kann.

• Ich frage mich, wie das im Vergleich zu https://strandsagents.com/ abschneidet. Ich interessiere mich für Tools in diesem Bereich und bin noch nicht an ein bestimmtes gebunden, aber Bedrock + Serverless on Agent Core fühlt sich wie der „einfache geführte Weg“ an. Plattformbindung gefällt mir allerdings nicht.

  • Mich würden Erfahrungen anderer interessieren. Ich nutze diesen Stack gerade und frage mich weiterhin, ob Strands zusammen mit Agent Core irgendeine besondere Geheimzutat bietet.
    Bisher fühlt es sich nicht so an, und manchmal wirkt es sogar, als würden die beiden miteinander kollidieren.

• Hier sieht man das Builder-Pattern und Decorators. Python hat zwar auch Decorators, aber ich finde, sie eignen sich am besten als „Filter“, die auf Funktionen oder Methoden angewendet werden. Also etwa: Diese Funktion cachen, die Ausgabe dieser Funktion immer serialisieren oder diese Funktion als Tool für eine agentenartige Laufzeit vorbereiten
  Für Registrierung oder Ablaufsteuerung sind sie meiner Meinung nach nicht gedacht. Man kann anderer Meinung sein, aber irgendwer muss es sagen. FastAPI hat die moderne Verwendung von Decorators viel zu sehr in die falsche Richtung gezogen
  Das Builder-Pattern ist in Rust eher eine Konvention, die daraus entstanden ist, dass es dort keine benannten Keyword-Argumente gibt, und Python-Funktionen legen ohnehin schon einen benannten Vertrag offen. Es gibt fast nie einen guten Grund, Konfigurationsparameter der Reihe nach über verkettete Methodenaufrufe zu übergeben
  Wenn man einen Zustand hinzufügen muss, der im Konstruktor oder in einer Factory noch nicht existiert, dann ist das keine Anwendung des Builder-Patterns, sondern Registrierung. Ein Ort, an dem man das Builder-Pattern gerade noch gelten lassen kann, sind Query-Builder. Dort baut man wiederholt Konzepte auf, und die Metadaten-Slots in Form von Methodennamen und Keyword-Argumenten sind tatsächlich nützlich. Methoden zu verwenden, die statt Keyword-Argumenten einen einzelnen Parameter entgegennehmen, halte ich für falsch

  • Hier hängt der Decorator konkret Metadaten an eine Funktion an und macht sie zu einer wiederverwendbaren Komponente, während der Builder den Workflow erstellt. In Hamilton ist die Struktur vollständig deklarativ, daher wird alles über Decorators abgewickelt, aber Wiederverwendbarkeit ist eigentlich eine separate Frage
  • Das Builder-Pattern wird nicht nur in Rust verwendet, aber ich stimme zu, dass es in Python hässlich wirkt

• Das wirkt wie eine ziemlich naive Vorstellung davon, was ein zuverlässiger AI-Agent ist
  Zuverlässigkeit bedeutet, „kann er die übertragene Aufgabe zu Ende bringen“, und hat mit einer Zustandsmaschine an sich nichts zu tun

• Von Burr habe ich zum ersten Mal gehört, und ich frage mich, warum es bei Apache inkubiert wurde

  • Es gibt keinen Grund, warum das nicht hätte passieren sollen. Die ASF hat eine lange Geschichte darin, neue freie Open-Source-Projekte zu inkubieren
    Einige werden erfolgreich abgeschlossen und werden zu Namen, die jeder kennt, andere scheitern und landen im Attic. Die ASF bietet organisatorische Unterstützung und fördert im Allgemeinen gute Communities
  • Weil ich es eingereicht habe. Es war ein langsamer Prozess, weil ich das Apache-Verfahren erst lernen und parallel noch andere Dinge machen musste, aber inzwischen hat das Ganze etwas Momentum bekommen, und wir beginnen mit regelmäßigeren Releases

• Die Seite sieht aus wie Wegwerf-Müll, der mit Claude Code gebaut wurde, und sie versucht nicht einmal, ohne JavaScript zu funktionieren. Wenigstens gibt es Markenkonsistenz

• Ich konnte keine explizite Begründung für den Namen finden, aber für Interessierte gibt es hier ein Hamilton-Beispiel: https://github.com/apache/burr/tree/main/examples/multi-agen...

  • Burr ist nach Aaron Burr benannt, einem Gründervater der USA, dem 3. Vizepräsidenten und dem Mörder sowie Erzfeind von Alexander Hamilton
    Die Verbindung zu Hamilton besteht darin, dass es sich um die zweite Open-Source-Bibliothek handelt, die DAGWorks nach der Hamilton-Bibliothek veröffentlicht hat. Der Name spielt mit der Vorstellung, wie es gewesen wäre, wenn Burr und Hamilton zusammengefunden und ihre Unterschiede überwunden hätten, um eine bessere Föderation zu schaffen
    Ursprünglich wurde Burr als Mechanismus gebaut, um Zustände zwischen Hamilton-DAG-Ausführungen zu handhaben. DAGs haben schließlich keine Zyklen. Später wurde klar, dass sich das viel breiter anwenden lässt, und dann wurde es entsprechend breiter veröffentlicht
    https://pypi.org/project/burr/

• Ich frage mich, ob jemand ein empfehlenswertes Orchestrierungs-Tool oder eine Plattform für Coding-Agenten kennt. Ich möchte codex- oder claude-Agenten auf mehreren Maschinen ausführen, verwalten und überwachen
  Wenn möglich, wäre Self-Hosting oder Open Source gut. Ich weiß, dass Claude Code intern schon viel davon mitbringt, aber das ist Claude-spezifisch

  • Laut Dokumentation gibt es in Burr ein Agent-Cookbook, mit dem man so etwas aufsetzen kann, und es kann auch Workflows über mehrere Maschinen hinweg verarbeiten. Vielleicht ist es genau das, wonach du suchst
    Ich bin nicht sicher, wie gut es sich mit Skills und Ähnlichem integrieren lässt, aber auf den ersten Blick scheint es zu funktionieren
    https://burr.apache.org/docs/examples/agents/