uAgents: Python-Agenten mit Almanac-Registrierung

Welches Problem uAgents löst und für wen

Ein Agent, der nur auf einem Entwicklerrechner läuft, braucht keine Adresse. Sobald er aber von anderen Agenten gefunden und angesprochen werden soll, entsteht eine Identitätsfrage: Wer ist dieser Agent, welche Adresse hat er, und wie stellt man sicher, dass Nachrichten nicht von einem Dritten stammen? uAgents beantwortet das nach eigener Darstellung mit einem Registrierungsschritt. Beim Start tritt jeder Agent automatisch dem Netzwerk bei, indem er sich im Almanac registriert, einem Smart Contract auf der Fetch.ai-Blockchain. Das ist die zentrale Designentscheidung des Projekts, nicht die Agentenlogik selbst. Die eigentliche Logik bleibt ein Python-Objekt mit Dekoratoren, und dieser Teil ist bewusst klein gehalten. Zielgruppe sind damit nicht Data-Science-Teams, die eine Pipeline aus LLM-Aufrufen zusammenstecken wollen, sondern Entwickler, die Agenten als adressierbare Teilnehmer eines Netzwerks betreiben. Die Themenliste des Repositories (agents, ai-agents, llm, multi-agent-systems) deutet zwar auf den breiten KI-Agenten-Markt, die README selbst argumentiert aber über Netzwerk, Identität und Kryptografie, nicht über Modellgüte oder Prompt-Verwaltung.

Dekoratoren, Adressen und der Registrierungsschritt

Ein Agent entsteht in der README mit zwei Zeilen: aus uagents wird Agent und Context importiert, dann wird alice = Agent(name="alice") angelegt. Aufgaben hängen an Dekoratoren. Das Beispiel zeigt @alice.on_interval(period=2.0) über einer async-Funktion, die den Agentennamen über ctx.logger.info ausgibt. Der Ablauf ist damit ereignisgetrieben: Der Agent läuft in einer Schleife, und der Dekorator bestimmt, wann die Funktion ausgeführt wird. Der zweite Mechanismus betrifft die Identität. Ohne seed wird der private Schlüssel lokal neben dem Namen in private_keys.json abgelegt. Wird der Agent ohne Namen erzeugt, also Agent(), erhält er bei jedem Lauf eine neue Adresse. Mit einem festen seed, im Beispiel aus einer Umgebungsvariable, bleibt die Adresse stabil. Diese drei Varianten sind keine Details am Rand: Sie entscheiden, ob ein Agent über Neustarts hinweg erreichbar bleibt oder ob er bei jedem Prozessstart als neuer Teilnehmer auftritt. Die Dokumentation verweist für Adressen, Speicher und Kommunikation auf eigene Kapitel, die im README nur verlinkt sind; die genaue Kodierung der Adressen und das Nachrichtenformat lassen sich aus dem vorliegenden Material nicht ableiten.

Installation und erster Lauf

Die Installation erfolgt über pip install uagents, unterstützt werden laut README Python 3.10 bis 3.13. Der vollständige Einstieg sieht so aus: Agent und Context importieren, eine Instanz mit Namen und seed anlegen, eine Funktion mit @alice.on_interval(period=2.0) dekorieren, und im __main__-Block alice.run() aufrufen. Gestartet wird das Ganze mit python agent.py, die Ausgabe erscheint im Terminal. Für feste Adressen empfiehlt die README, den Seed aus einer Umgebungsvariable zu lesen, im Beispiel os.getenv("ALICE_SEED_PHRASE"). Das ist der Punkt, an dem Deployment-Konfiguration beginnt: Der Seed ist das Geheimnis, aus dem die Agentenidentität abgeleitet wird. Wer ihn im Code hinterlegt, wie es das Kurzbeispiel tut, hat ihn im Repository. Der Hinweis auf private_keys.json macht die Alternative sichtbar, nämlich die lokale Schlüsseldatei, die dann ebenfalls geschützt werden muss. Das Repository ist in zwei Teile gegliedert: den python-Ordner mit der eigentlichen Bibliothek und den Unterordner uagents-core, der laut README Kern-Definitionen und Funktionen bereitstellt, um Agenten-Software in das Fetch.ai-Ökosystem und den Agentenmarktplatz zu integrieren.

Die Kehrseite der automatischen Registrierung

Der Satz "On startup, each agent automatically joins the fast-growing network" beschreibt eine Kopplung, die man bewusst eingehen muss. Ein Agent, der beim Start einen Smart Contract auf einer öffentlichen Blockchain anspricht, hat eine externe Abhängigkeit in seinem Startpfad. Für Anwendungen, die nur intern kommunizieren, ist das ein Fremdkörper: Man bezahlt Registrierungsaufwand und Netzwerklatenz für eine Auffindbarkeit, die niemand nutzt. Dazu kommt die Versionierung. Die jüngsten Releases zeigen zwei getrennte Versionslinien, v0.25.5 für das Hauptpaket und core@0.4.9 für uagents-core. Wer beide Komponenten einsetzt, muss die zueinander passenden Stände selbst verfolgen. Ein weiterer Vorbehalt steht direkt im Repository: Der Disclaimer erklärt das Projekt für "provided as-is without any warranty" und nennt ausdrücklich unerwartetes Verhalten und Datenverlust als mögliche Risiken. Bei einem System, das Schlüssel verwaltet und Transaktionen im weiteren Sinne berührt, ist das kein Formelsatz. Die README liefert außerdem keine Aussage zu Betriebsgrenzen, etwa wie viele Nachrichten ein einzelner Agent verarbeiten kann oder was bei Ausfall der Registrierung passiert. Wer diese Zahlen braucht, findet sie im vorliegenden Material nicht.

Abgrenzung zu LangGraph und CrewAI

Die naheliegenden Alternativen für Python-Agenten sind LangGraph und CrewAI, und der Unterschied liegt nicht in der Bequemlichkeit, sondern im Adressmodell. LangGraph modelliert einen Agenten als Graph aus Knoten und Kanten und führt ihn innerhalb des eigenen Prozesses aus; Zustand und Übergänge sind das zentrale Abstraktionsmittel. CrewAI beschreibt Rollen und Aufgaben und lässt mehrere Agenten innerhalb einer Crew zusammenarbeiten, ebenfalls ohne Netzwerkidentität nach außen. uAgents setzt woanders an: Der Agent ist primär ein Teilnehmer mit Adresse, der über das Almanac auffindbar wird und dessen Nachrichten und Wallet laut README kryptografisch gesichert sind. Ein Graph oder eine Crew ist damit kein Ersatz für uAgents, und umgekehrt liefert uAgents keine Graph-Engine und keine Rollenverwaltung. Wer Agenten über Organisationsgrenzen hinweg ansprechen will, braucht das Adressmodell; wer innerhalb eines Prozesses Zustände orchestriert, braucht es nicht. Eine Kombination ist denkbar, aber das vorliegende Material beschreibt keine Integration mit LangGraph oder CrewAI, und die README nennt als Beispielintegration nur einen ASI:One-kompatiblen Agenten.

Lizenz, Wartung und Upgrade-Aufwand

Die Lizenz ist Apache-2.0, eine permissive Lizenz mit einer ausdrücklichen Patentgewährung. Für den üblichen Fall, die Bibliothek in ein eigenes Produkt einzubinden, ergeben sich daraus keine Copyleft-Pflichten; wer das Projekt selbst verändert und weitergibt, muss die Lizenzbedingungen und die Hinweise auf Änderungen einhalten. Das ist keine Rechtsberatung, sondern die Einordnung des Lizenzidentifiers aus dem Repository. Zur Wartung lässt sich aus dem Material ableiten: Der letzte Push liegt bei 2026-09-07, die Releases v0.25.5 vom 2026-08-20 und v0.25.4 vom 2026-08-07 folgen in kurzem Abstand, dazu core@0.4.9 vom 2026-08-06. Das Muster deutet auf eine aktive, aber schnelle Release-Kadenz im 0.x-Bereich hin. Genau das ist der Kostentreiber: In einer Vor-1.0-Linie sind Breaking Changes zu erwarten, und die Aufteilung in uagents und uagents-core bedeutet, dass ein Upgrade zwei Versionsnummern betrifft. Wer die Bibliothek produktiv einsetzt, sollte die Versionen pinnen und vor jedem Sprung die Release Notes lesen, statt automatisch zu aktualisieren. Die README selbst nennt keine Migrationshinweise und keine Versionskompatibilitätsmatrix.

Speicher, Broadcast und die dünne Dokumentationslage

Die README verlinkt Konzepte wie Storage, Synchronous Communication und Agent Broadcast, erklärt sie aber nicht. Das ist eine bewusste Arbeitsteilung, denn die Details liegen in der offiziellen Dokumentation. Für eine Adoption bedeutet es, dass die Entscheidung nicht allein anhand des Repositories fallen kann: Wer wissen will, wie der Speicher eines Agenten persistiert, wie synchroner Nachrichtenaustausch abläuft und wie Broadcast adressiert wird, muss die verlinkten Kapitel lesen. Ein weiterer Punkt ist die Trennung zwischen der Bibliothek und dem Ökosystem. Der Ordner uagents-core existiert laut README, um Software zu bauen, die mit dem Fetch.ai-Ökosystem und dem Agentenmarktplatz interagiert. Wer nur die Agentenlaufzeit aus dem Hauptpaket nutzt, zieht diese Abhängigkeit möglicherweise gar nicht ein. Diese Unterscheidung ist praktisch relevant, weil sie bestimmt, wie tief man sich mit der Fetch.ai-Seite beschäftigen muss. Beispielcode für verschiedene Agententypen liegt laut README im separaten Repository uAgent-Examples, das als offizieller Ort für interne und Community-Anwendungen bezeichnet wird.

Wann uAgents die falsche Wahl ist

Es gibt einen klaren Fall, in dem man uAgents nicht nehmen sollte: ein einzelner Agent, der lokal ein LLM aufruft, Werkzeuge ausführt und sein Ergebnis an einen Aufrufer zurückgibt. Hier bringt das Framework nichts, was nicht auch ein einfaches Python-Skript leistet, während es die Registrierung beim Start und die Schlüsselverwaltung als zusätzliche Betriebsfläche hinzufügt. Dasselbe gilt für Anwendungen, die keine stabile Agentenadresse über Neustarts hinweg benötigen. Wer den Agenten ohne Namen anlegt, bekommt bei jedem Lauf eine neue Adresse, und wer den Seed im Code hinterlegt, verteilt sein Geheimnis mit dem Repository. Beides sind Konfigurationsfehler, die das Framework nicht verhindert. Umgekehrt ist die Wahl naheliegend, wenn Agenten über einen Marktplatz gefunden oder über Organisationsgrenzen hinweg angesprochen werden sollen. Die Prüffragen vor der Adoption sind konkret: Passt die Zielumgebung in den Bereich Python 3.10 bis 3.13? Sind uagents und uagents-core auf kompatible Versionen festgelegt? Wo liegt der Seed im Deployment, und ist private_keys.json außerhalb des Images? Und erfordert der Anwendungsfall wirklich eine öffentliche Registrierung im Almanac?

Redaktionelles Fazit

Sinnvoll ist uAgents für Teams, die Agenten mit kryptografisch verankerter Identität und Auffindbarkeit im Fetch.ai-Ökosystem betreiben wollen, etwa für marktplatzbasierte Dienste. Wer ausschließlich lokale LLM-Pipelines orchestriert, sollte bei LangGraph oder CrewAI bleiben; die Almanac-Registrierung beim Start und die Abhängigkeit von der Fetch.ai-Kette bringen hier nur Overhead. Vor dem ersten Produktiveinsatz ist zu prüfen, ob die anvisierte Python-Version im Bereich 3.10 bis 3.13 liegt, ob die Versionen von uagents und uagents-core zueinander passen, wie die private_keys.json im Deployment geschützt wird und ob der eigene Anwendungsfall tatsächlich eine öffentliche Agentenadresse erfordert.

Offizielle Quellen

1. fetchai/uAgents on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases