Jido 2.0 – Elixir-basiertes Agenten-Framework vorgestellt

 (jido.run)
7 Punkte von GN⁺ 2026-03-07 | 1 Kommentare | Auf WhatsApp teilen
  • Rein funktionale Agentenarchitektur: Zustand und Verhalten werden als Daten definiert, während Nebenwirkungen in imperative Direktiven (directives) ausgelagert werden, was Tests und Debugging vereinfacht
  • Mit kompakter API und BEAM-zentriertem Design sowie getrennten Modulen wie jido_action und jido_signal bietet es ein standardisiertes Action- und Signal-System
  • Die höhere Ebene Jido AI unterstützt 6 Inferenzstrategien wie ReAct und Chain-of-Thought und ermöglicht durch ReqLLM-basierte LLM-Integration die Nutzung von 11 Anbietern und 665 Modellen
  • Jido wird nun zu einer Agenten-Ökosystem-Plattform ausgebaut und unterstützt durch die Integration mit dem Ash Framework (ash_jido) AI-aufrufbare CRUD-Werkzeuge

Überblick über Jido 2.0

  • Jido 2.0 ist ein Elixir-basiertes Agenten-Framework, das nach 18 Monaten Entwicklung und Neugestaltung fertiggestellt wurde
    • Ursprünglich startete es 2024 als Bot-Plattform namens BotHive, bevor die BEAM-Runtime als Grundlage für das Agentensystem übernommen wurde
    • Um die Grenzen von TypeScript- oder Python-basierten Frameworks zu überwinden, nutzt es die Nebenläufigkeit und Stabilität von BEAM

Die Veränderungen von 1.0 zu 2.0

  • Jido 1.0 litt unter zu viel Abstraktion und war dadurch schwerer nutzbar; in 2.0 wurde das durch eine vereinfachte API und eine BEAM-zentrierte Struktur verbessert
    • Auf Basis von Nutzerfeedback wurde unnötige Komplexität entfernt und die Reibung bei grundlegenden Aufgaben minimiert
    • Damit wird dem Wunsch entsprochen: „Ich will Agenten bauen und nicht mit dem Framework kämpfen.“

Ein leistungsfähiger und robuster Agentenkern

  • Das Herzstück von Jido 2.0 ist eine rein funktionale Agentenarchitektur
    • Agenten werden als einfache Structs mit Zustand (state), Aktionen (actions) und Werkzeugen (tools) definiert
    • Alle Abläufe werden über die Funktion cmd/2 verarbeitet, die abhängig von der eingegebenen Aktion einen aktualisierten Agenten und eine Liste von Direktiven zurückgibt
    • Nebenwirkungen werden als Direktiven dargestellt und von der Runtime ausgeführt, was Tests und Debugging erleichtert
  • Jido.AgentServer kapselt Agenten als überwachte GenServer und unterstützt Signal-Routing sowie Parent-Child-Agenten-Hierarchien
  • Strategien (strategy) dienen als Erweiterungspunkte; standardmäßig werden Direct (sequenzielle Ausführung) und FSM (Zustandsmaschine) mitgeliefert
    • Auch AI-Strategien wie ReAct und Chain-of-Thought arbeiten mit derselben Schnittstelle

Trennung von Action- und Signal-Modulen

  • jido_action: ein universeller Action-Vertrag, der sämtliche Agentenfunktionen definiert
    • Enthält Schema-Validierung zur Compile-Zeit, Lifecycle-Hooks und automatische Umwandlung in das ReqLLM-Tool-Format
    • Bietet mehr als 25 vorgefertigte Werkzeuge sowie einen DAG-basierten Workflow-Planer
  • jido_signal: ein Messaging-System auf Basis von CloudEvents v1.0.2
    • Bietet ein standardisiertes Signalformat, einen Trie-basierten Router, einen Pub/Sub-Bus und 9 Dispatch-Adapter
    • Dadurch ist die Integration mit verschiedensten Systemen ohne nicht standardisierte Protokolle möglich

Die Integrationsschicht Jido AI

  • jido_ai ist eine Integrationsschicht, die LLM-Aufrufe in strukturierte Agentenintelligenz umwandelt
    • Enthält 6 Inferenzstrategien wie ReAct, Chain-of-Thought, Tree-of-Thoughts, Graph-of-Thoughts, TRM und Adaptive
    • Behält denselben cmd/2-Vertrag und dasselbe Direktivsystem bei und integriert die AI-Schicht als Erweiterung statt als getrennte Welt
  • Es basiert auf ReqLLM und unterstützt 11 Anbieter sowie mehr als 665 Modelle
    • Streaming-orientiertes Design, Multi-Provider-Architektur und aktive Beiträge aus der Community

Ein wachsendes Ökosystem

  • Jido entwickelt sich über ein reines Framework hinaus zu einem Agenten-Ökosystem
    • Die Community baut auf BEAM unter anderem Coding-Assistenten, Workflow-Orchestratoren, Research-Agenten und Systeme zur Betriebsunterstützung
    • Es entstehen verschiedene Pakete für Browser-Automatisierung, Speichersysteme, Evaluierungs-Harnesses und MCP-Integration
  • Integration mit dem Ash Framework (ash_jido)
    • Wenn Ash-Ressourcen ein jido-DSL-Block hinzugefügt wird, werden CRUD-Aktionen in AI-aufrufbare Werkzeuge umgewandelt
    • Berechtigungspolicies, Datenebene und Typsicherheit bleiben erhalten
    • Auch ash_ai wird auf ReqLLM migriert, wodurch die Konvergenz beider Ökosysteme voranschreitet

Community und Dank

  • Jido 2.0 wurde auf dem Ökosystem der Elixir-Community aufgebaut
    • Es profitiert von den Beiträgen zentraler Bibliotheken wie Phoenix, LiveView, Ash, Req, Telemetry und NimbleOptions

Erste Schritte

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-07
Hacker-News-Kommentare

  • Ich habe Jido zwar noch nie tatsächlich verwendet, schaue aber etwa einmal im Monat danach.
    Ich denke, dass BEAM perfekt zu einem Agenten-Framework passt, aber das Ökosystem ist noch begrenzt, daher bin ich nicht tiefer eingestiegen.
    Ich freue mich auf Version 2.0. Übrigens scheint es in einigen Codebeispielen ein Problem mit Entity Escaping zu geben.

    • Danke! Ich behebe das gerade.

  • Mir gefällt der schon zu Beginn des Artikels betonte Ansatz rund um Daten und pure Funktionen sehr.
    Man liest oft, dass das Ausführungsmodell von BEAM gut zu KI passt, aber in der Praxis wird die Robustheit in Situationen wie Knotenausfällen oder Rolling Deployments oft übersehen.
    Es gibt auch das Missverständnis, Elixir biete Location Transparency, aber das stimmt so nicht. Wenn ein Knoten ausfällt, enden auch die Prozesse darin.
    Wenn man bei jedem API-Aufruf einen klaren und reinen Agentenzustand beibehält, kann man solche Probleme lösen. Man speichert den Zustand in Mnesia oder Redis und setzt ihn auf einem anderen Knoten fort. Am Ende ist Checkpointing der Schlüssel.

    • Meiner Meinung nach ist das wichtigste Prinzip von Jido, einen strukturell korrekten Agenten auch ohne LLM zu bauen, bevor man überhaupt ein LLM verwendet.
      Deshalb hat der Jido-Kern überhaupt keine LLM-Unterstützung.
      Es gibt mehr als 40 Jahre Agentenforschung, und mit dem Aufkommen der LLMs scheint das alles vergessen worden zu sein. Deshalb habe ich diese Geschichte noch einmal studiert und versucht, sie in Jido einfließen zu lassen.
      Natürlich mag ich LLMs, aber das ist die Aufgabe des Jido-AI-Pakets.

  • Perfektes Timing. Ich habe mein eigenes Agenten-Framework gebaut, indem ich GenServer und Oban kombiniert habe, und das war wirklich schmerzhaft.
    Dieses Projekt scheint den Entwicklungsschmerz deutlich zu verringern. Vielen Dank.

    • ❤️

  • Ich frage mich, ob das vielleicht OpenAI Symphony ähnelt.
    Ich verfolge eher Elixir als KI, daher ist es erfrischend zu sehen, dass Elixir und BEAM für solche Orchestrierungs-Workloads eingesetzt werden.

    • Es freut mich zu sehen, dass OpenAI Elixir nutzt. Symphony ist ein Beispiel dafür, Dinge direkt umzusetzen, die Jido leisten kann.

  • Die Website ist wegen eines Traffic-Ansturms schwer erreichbar. Deshalb teile ich den archive.org-Backup-Link.

    • Das wird wohl für die nächsten zwei Wochen meine persönliche Schande bleiben … ein gutes Problem zwar, aber ich war wirklich schlecht vorbereitet.
    • Ich weiß nicht, ob es damit zusammenhängt, aber die Seite öffnet sich zunächst normal und wird dann nach ein paar Sekunden mit einem 404 neu geladen. Ich habe am Ende aufgegeben, sie zu lesen.

  • Danke fürs Teilen! Ich werde es mir auf jeden Fall ansehen.
    Ich habe kürzlich mit einem LLM ein A2A-Paket gebaut, eine ähnliche Abstraktion wie GenServer.
    Es gab bereits andere A2A-Implementierungen, aber mein Paket hat eine andere Semantik, deshalb habe ich es trotzdem veröffentlicht.
    Wer Interesse hat, kann es hier ansehen.

    • Cool! Ich habe sofort einen Star vergeben.

  • Ich beobachte dieses Projekt seit einigen Monaten, und Elixir/BEAM ist eine perfekte Plattform für die Ausführung von Agenten.
    BEAM ist wirklich leichtgewichtig und effizient, daher könnte man theoretisch Tausende von Agenten auf einem einzigen Server betreiben.
    Ich bin gespannt, was Menschen bauen werden, die das verstanden haben.

    • Der Jido-Kern kann sogar auf einem Raspberry Pi laufen.
      Es gab sogar Versuche, BEAM auf Bare Metal (Embedded) zu deployen und dort Agenten auszuführen.
      Die Zukunft dürfte wirklich spannend werden.

  • Ich würde gern einen Screenshot des Prozessbaums sehen, während die Agenten in observer aktiv sind.
    Zur Einordnung: observer ist ein Tool zur Visualisierung der Erlang-Prozesse innerhalb der BEAM-VM.
    Ein Beispiel-Screenshot ist in der Fly.io-Dokumentation zu sehen.

    • Bald werde ich ein Dashboard namens jido_studio veröffentlichen. Es visualisiert die Prozessstruktur.
      Einen Teaser-Screenshot gibt es hier.
      Agenten, die mit AgentRuntime umhüllt sind, laufen normalerweise als einzelner GenServer-Prozess, aber wenn eine größere Topologie nötig ist, gibt es Ausnahmen.

  • Perfektes Timing. Ich habe auch selbst ein Erlang-Agenten-Framework gebaut, aber das hier ist deutlich besser.

  • Ich frage mich, wie die Sicherheit gewährleistet wird. Ohne Container-Isolation ist es schwer, das Ausleaken von Production Secrets zu verhindern.

    • Mit Signals und Plugins lassen sich Daten zwischen Agenten verschlüsseln.
      Ich habe tatsächlich schon Jido-Beispiele gesehen, die genau so umgesetzt wurden.
      Das hängt allerdings vom jeweiligen Use Case ab, und Sicherheit ist ein viel breiteres Thema als nur „Agenten im Container“.
      Ziel von Jido ist nicht, Sicherheit direkt zu lösen, sondern Werkzeuge bereitzustellen, mit denen Nutzer sie auf die für sie passende Weise lösen können.