AgentField: Agents wie Microservices betreiben
Build, run and scale AI agents like API and microservices
Auf einen Blick
- Was ist das?
- AgentField ist eine Go-Control-Plane, die Python-, Go- oder TypeScript-Funktionen als REST-Endpunkte veröffentlicht und Fan-out, Queues und Retries übernimmt. Wer viele Agenten in einem Workflow koordinieren will, findet hier ein tragfähiges Modell; wer einen einzelnen Chat-Bot baut, zahlt für Infrastruktur, die er nicht braucht.
- Für wen ist es gedacht?
- Wer einen einzelnen Agenten mit einer Handvoll Tools betreibt, sollte bei einem Framework bleiben, das im Prozess läuft. AgentField lohnt sich, wenn ein Request auf viele Agenten verzweigt und die Kontrolle über Queues, Retries und Traces wichtiger ist als die kürzeste Latenz.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem AgentField löst und für wen
Ein Agent, der eine Anfrage in Unterfragen zerlegt und parallel beantwortet, ist schnell geschrieben. Die Mühe beginnt danach: Welcher Zweig ist ausgefallen? Wie oft wird wiederholt? Wo landet der Trace, wenn ein Durchlauf aus tausend Aufrufen besteht? AgentField setzt genau dort an. Das README beschreibt das Projekt als Control Plane, die Agenten-Logik aus Python, Go oder TypeScript in Produktionsinfrastruktur überführt: Routing, Koordination, Speicher, asynchrone Ausführung und Beobachtbarkeit. Jede registrierte Funktion wird zu einem REST-Endpunkt. Die Zielgruppe sind Teams, die bereits mehrere Agenten betreiben und deren Aufrufe über Frontends, Backends, Cron-Jobs oder andere Agenten verteilen wollen, ohne für jede Verzweigung eigene Broker-, Retry- und Tracing-Logik zu schreiben. Für Prototypen mit einem einzigen Agenten ist der Ansatz zu schwer.
Vom Dekorator zum REST-Endpunkt
Das Mechanismus lässt sich am Python-Beispiel aus dem README ablesen. Ein Agent wird mit node_id, version und ai_config instanziiert. Funktionen werden mit @app.reasoner(tags=[...]) ausgezeichnet. Der Aufruf app.run() veröffentlicht laut Kommentar im Beispiel genau einen Endpunkt: POST /api/v1/execute/researcher.research. Der Pfad kombiniert node_id und Funktionsnamen, was bedeutet, dass die Adressierung eines Agenten an seine Registrierung gebunden ist. Innerhalb der Funktion ruft app.call(f"{app.node_id}.research", ...) denselben Agenten erneut auf, diesmal über die Control Plane. Die Verzweigung läuft über asyncio.gather, die Tiefe wird über einen Parameter depth begrenzt, im Beispiel bei drei. Diese Begrenzung ist kein Detail, sondern die einzige im Material sichtbare Schutzmaßnahme gegen unkontrolliertes Wachstum des Aufrufbaums. Die Control Plane übernimmt laut README Fan-out, Queues und Retries für jeden Zweig. Wie die Queue konkret aussieht, welche Zustellgarantie gilt und wo der Trace gespeichert wird, geht aus dem vorliegenden Material nicht hervor.
Installation und der Dienst im Hintergrund
Der Einstieg erfolgt über ein Shell-Skript: curl -fsSL https://agentfield.ai/install.sh | bash. Der Installer legt neben af auch die Coding-Harness aforge unter ~/.agentfield/bin ab; mit --no-aforge lässt sich dieser Teil überspringen. Auf macOS registriert der Installer die Control Plane zusätzlich bei launchd, sodass sie beim Login startet, und setzt ein Menüleisten-Icon. Zwei Details sind für den Betrieb relevant. Erstens: ein normales kill wirkt laut README wie ein Absturz, der Dienst startet neu; sauber beenden lässt er sich mit af service stop oder über das Menüleisten-Icon. Zweitens: af service status zeigt Gesundheitszustand und laufende Arbeit an. Wer das nicht will, installiert mit --no-tray. Für den eigentlichen Entwicklungsfluss gibt es den Befehl /agentfield, dem eine Beschreibung folgt, etwa ein Claims-Prozessor mit Risk-Scoring, Mustererkennung und menschlicher Freigabe bei unsicherer Entscheidung. Das Ergebnis ist laut README ein Docker-Compose-Stack mit Agent, Control Plane und einem REST-Endpunkt zum Ausprobieren. Der genaue Inhalt dieses Stacks ist im Material nicht aufgeführt.
Drei SDKs, eine Control Plane
AgentField positioniert sich nicht als Python-Framework, sondern als sprachübergreifende Schicht. Das README verweist auf SDKs für Python, Go und TypeScript sowie auf eine REST-API als direkten Zugang. Die Control Plane selbst ist in Go geschrieben, was für einen Dienst, der Verbindungen und Nebenläufigkeit verwaltet, eine naheliegende Wahl ist. Für Teams bedeutet das: Die Agenten-Logik kann dort bleiben, wo sie bereits liegt, und muss nicht in eine neue Sprache portiert werden. Der Preis dafür ist ein zusätzlicher Netzwerksprung. Jeder app.call läuft über die Control Plane statt direkt im Prozess. Bei einem Workflow, der ohnehin über hunderte Agenten verteilt ist, fällt das kaum ins Gewicht. Bei einem einzelnen Agenten, der drei Tool-Aufrufe hintereinander ausführt, ist es reiner Overhead.
Versionsnummern und Rollout-Muster
Das Agent-Konstrukt nimmt eine version entgegen, im README-Beispiel "1.0.0", mit dem Kommentar, dass dies Canary-Deployments, A/B-Tests und Blue-Green-Rollouts ermöglicht. Das ist eine bewusste Design-Entscheidung: Versionierung wird nicht dem Deployment-Tool überlassen, sondern ist Teil der Agenten-Identität. Wer zwei Versionen parallel laufen lässt, adressiert sie unterschiedlich. Allerdings lässt das Material offen, wie die Control Plane eingehende Anfragen auf Versionen verteilt, ob es Gewichtungen gibt und wie ein Rollback aussieht. Diese Lücke ist relevant, weil der Nutzen des Feldes ohne dokumentierte Routing-Regeln nicht bewertbar ist. Der Leser sollte die Versions-Semantik in der Dokumentation prüfen, bevor er sie in einen Release-Prozess einbaut.
Release-Kadenz und Wartungskosten
Die letzten veröffentlichten Versionen tragen Bezeichnungen wie v0.1.138-rc.16, v0.1.138-rc.15 und v0.1.138-rc.14, alle vom September 2026. Drei Release Candidates innerhalb weniger Stunden deuten auf eine hohe Iterationsgeschwindigkeit hin. Für Betreiber heißt das: Die Major-Version ist noch 0, die API kann sich zwischen Minor-Versionen ändern, und wer auf eine RC-Version setzt, sollte mit häufigen Updates rechnen. Das ist kein Qualitätsurteil, sondern eine Planungsgröße. Ein Upgrade-Pfad, Migrationshinweise oder eine Stabilitätszusage für die 0.x-Linie sind im vorliegenden Material nicht dokumentiert. Die Lizenz ist Apache-2.0, was kommerzielle Nutzung und Modifikation erlaubt und eine Weitergabe des Lizenztextes verlangt. Wer den Code verändert und als Dienst betreibt, sollte die Patentklausel und die Bedingungen für Namensnutzung selbst im Lizenztext nachlesen; eine rechtliche Einordnung kann dieser Artikel nicht leisten.
Wo AgentField das falsche Werkzeug ist
Der Installer auf macOS registriert die Control Plane bei launchd und startet sie nach einem kill neu. Das ist für lokale Entwicklung bequem, kann aber im Betrieb überraschen, wenn jemand einen Prozess beenden will und ihn kurz darauf wieder vorfindet. Wer AgentField in Kubernetes betreibt, muss dieses Verhalten selbst nachbilden. Ein zweiter Punkt betrifft die Kosten: Jede Verzweigung wird über die Control Plane geleitet und dort in eine Queue gestellt. Bei einem Workflow mit tausend Zweigen ist das gewünscht. Bei einem einzelnen Agenten, der eine Anfrage an ein Modell weiterreicht, entsteht Latenz ohne Gegenwert. Und schließlich: Das README verspricht, dass jede Funktion zu einem REST-Endpunkt wird. Das bedeutet, dass die Fehlerbehandlung auf HTTP-Ebene stattfindet. Wer gewohnt ist, Exceptions im selben Prozess zu behandeln, muss sich auf Netzwerkfehler, Timeouts und Teilausfälle einstellen. Wie die Control Plane einen fehlgeschlagenen Zweig nach einem Retry behandelt, ob der gesamte Fan-out abgebrochen wird oder nur der Zweig, steht nicht im Material.
Abgrenzung zu LangGraph und ähnlichen Frameworks
Der naheliegende Vergleich ist ein Graph-Framework wie LangGraph. Dort beschreibt man den Ablauf als Knoten und Kanten, oft in einem YAML- oder Builder-Ansatz, und führt ihn im selben Prozess aus. AgentField geht den umgekehrten Weg: keine Graph-Definition, sondern gewöhnliche Funktionen mit Dekoratoren, dafür ein externer Dienst, der die Verzweigung verwaltet. Der Unterschied zeigt sich im Fehlerfall. Ein Graph-Framework kann einen fehlgeschlagenen Knoten im Speicher des laufenden Prozesses wiederholen; AgentField schiebt ihn zurück in die Queue der Control Plane, die laut README Retries und Tracing übernimmt. Der zweite Unterschied ist die Sprache. Ein Graph-Framework bindet die Orchestrierung an eine Sprache; AgentField adressiert Agenten über REST, sodass ein Go-Agent einen Python-Agenten aufrufen kann. Wer bereits in einem Graph-Framework produktiv ist und keine sprachübergreifende Verzweigung braucht, hat wenig Grund zu wechseln.
Redaktionelles Fazit
Wer einen einzelnen Agenten mit einer Handvoll Tools betreibt, sollte bei einem Framework bleiben, das im Prozess läuft. AgentField lohnt sich, wenn ein Request auf viele Agenten verzweigt und die Kontrolle über Queues, Retries und Traces wichtiger ist als die kürzeste Latenz. Vor dem ersten Deployment im eigenen Cluster ist zu prüfen, ob die Control Plane den eigenen Ausfallmodus toleriert: startet sie auf macOS per launchd automatisch neu, muss im Kubernetes-Betrieb ein entsprechendes Restart-Verhalten selbst konfiguriert werden.
Community-Notizen