Dapr Agents Trial
Überblick
Dapr Agents kombinieren Dapr Building Blocks (State, Pub/Sub, Bindings, Workflows) mit Agent-Patterns für Microservice-Estates. Das Modell passt zu Kubernetes-Teams mit bestehendem Dapr-Betrieb (Dapr AI). Das Python-Framework hat auf der KubeCon Europe im März 2026 den Status v1.0 General Availability erreicht (CNCF-Ankündigung).
Trial, wenn Agents bestehende Microservices über governete Dapr-Komponenten statt Ad-hoc-HTTP aus Prompt-Loops aufrufen müssen.
Adoptionssignale
- v1.0 wurde am 23. März 2026 als allgemein verfügbar angekündigt, nach einjähriger Zusammenarbeit von NVIDIA, der Dapr-Community und Endanwendern; zentrale Merkmale sind Durable Workflows, State über mehr als 30 Datenbanken und SPIFFE-basierte Identität (CNCF-Ankündigung).
- Die zugrunde liegende Dapr-Runtime ist seit dem 30. Oktober 2024 ein graduiertes CNCF-Projekt, womit die Agent-Schicht auf etablierten Governance- und Security-Audit-Prozessen aufsetzt (CNCF-Projektseite Dapr).
- ZEISS Vision Care hat auf der KubeCon Europe 2026 gezeigt, wie das Unternehmen mit Dapr Agents optische Parameter aus unstrukturierten Dokumenten extrahiert (CNCF-Ankündigung, Aufzeichnung der Keynote).
- Das Projekt liefert nach GA regelmäßig aus: v1.0.3 brachte Human-in-the-Loop und einen Anthropic-Client, v1.0.4 MCP-Server-Auto-Discovery über die Dapr-Metadata-API, v1.0.6 (28. September 2026) Streaming-Agents und einen LiteLLM-Provider (Release Notes v1.0.6).
- Die Verbreitung ist noch gering: rund 750 GitHub-Sterne (Dapr Agents auf GitHub) und etwa 18.000 PyPI-Downloads in den 30 Tagen bis zum 30. September 2026 (PyPI Stats).
Risiken
- Infrastruktur als Voraussetzung. Agents laufen über einen Dapr-Sidecar, und Durable Execution benötigt eine State-Store-Komponente, die als Actor State Store konfiguriert ist (Dapr Agents Getting Started); ohne bestehende Dapr-Plattform bringt das Framework eine verteilte Runtime gleich mit.
- API-Änderungen nach GA. Die Agent-Klasse wurde mit 1.0.0 als deprecated markiert und im Patch-Release 1.0.1 entfernt (Release Notes v1.0.1); Versionen sollten gepinnt und Release Notes vor jedem Upgrade gelesen werden.
- Replay-Semantik von Workflows. Da Agents auf Workflows basieren, wird Workflow-Code bei der Wiederherstellung erneut abgespielt und muss deterministisch sein (Dapr workflow concepts); Seiteneffekte außerhalb von Activities können doppelt ausgeführt werden oder Replays abbrechen.
- Schmales Ökosystem. Bei kleiner Nutzerbasis kommen Antworten überwiegend von Maintainern und aus der Dokumentation; Integrationen mit Evaluations- oder Tracing-Werkzeugen müssen oft selbst gebaut werden.
- Nur Python. Dapr Agents ist ein Python-Framework (CNCF-Ankündigung); polyglotte Teams brauchen für die Agent-Logik eine Python-Service-Grenze, auch wenn der übrige Dapr-Bestand in Go, Java oder .NET läuft.
Vorteile & Nachteile
Vorteile
- Jeder DurableAgent läuft auf Dapr Workflows: LLM-Aufrufe und Tool-Ausführungen werden gecheckpointet und nach Abstürzen oder Neustarts fortgesetzt, statt den Lauf zu verlieren; Version 1.0 ist seit März 2026 allgemein verfügbar.
- Agents nutzen dieselben Dapr Building Blocks (State Stores, Pub/Sub, Service Invocation, SPIFFE-basierte Identität), die Plattform-Teams bereits betreiben und governen, statt einer separaten Agent-Runtime.
- Entwickelt im CNCF-graduierten Dapr-Projekt unter Apache-2.0, mit aktiver Release-Linie, die seit GA Human-in-the-Loop-Freigaben, MCP-Server-Auto-Discovery, Anthropic- und LiteLLM-Provider sowie Streaming ergänzt hat.
Nachteile
- Voraussetzung sind die Dapr-Runtime mit Sidecar und State-Store-Komponenten, darunter ein Actor-fähiger Store für Durable Execution, was für Teams ohne bestehenden Dapr-Betrieb auf Kubernetes erheblichen Mehraufwand bedeutet.
- Die Community ist im Vergleich zu verbreiteten Agent-Frameworks klein (rund 750 GitHub-Sterne und etwa 18.000 PyPI-Downloads pro Monat im September 2026), entsprechend selten sind Beispiele, Antworten und Drittanbieter-Integrationen.
- Die API bewegt sich auch nach GA: Die ursprüngliche Agent-Klasse wurde im Patch-Release 1.0.1 zugunsten von DurableAgent entfernt, frühere Orchestrator-Klassen bereits mit 1.0.0.
Empfehlung
Dapr Agents eignet sich für einen Trial, wenn Dapr bereits Teil der Plattform ist und Agents auf bestehende Microservices, Queues und State Stores unter denselben Regeln für Component Scoping, mTLS und Observability zugreifen sollen. Am besten passen langlaufende, fehleranfällige Abläufe wie Dokumentenextraktion oder mehrstufige Back-Office-Prozesse, weil das Workflow-Checkpointing handgeschriebene Retry- und Resume-Logik überflüssig macht.
Teams ohne Dapr sollten es nicht allein für Agents einführen; eine bereits betriebene Durable-Execution-Engine wie Temporal oder ein leichteres Framework ist meist günstiger. Vor einem Pilot sollten Component Scopes und Secret Stores pro Agent festgelegt, ein produktionstauglicher Workflow-State-Store gewählt, die Paketversion gepinnt und LLM-Aufrufe über ein Gateway mit Budgets pro Team geführt werden.
Quellen
- Dapr AI docs
- Dapr Agents docs
- Why Dapr Agents
- Dapr Agents Getting Started
- Dapr Agents auf GitHub
- Dapr workflow features and concepts
- Dapr Agents v1.0.1 Release Notes
- Dapr Agents v1.0.6 Release Notes
- CNCF-Ankündigung: Dapr Agents v1.0 General Availability
- CNCF-Projektseite Dapr
- Keynote: Orchestrating Document Data Extraction with Dapr Agents (KubeCon EU 2026)
- PyPI Stats: dapr-agents
- Dapr GitHub
Verwandte Einträge
Beratung
Vom Radar zur Umsetzung
Du hast Technologien bewertet — wir helfen dir, sie sicher und messbar in produktive Systeme zu bringen.

