Die meisten KI-Agenten-Projekte scheitern nicht, weil der Prototyp schlecht war. Sie scheitern, weil das Team ein Framework gewählt hat, das in einem Jupyter-Notebook problemlos funktionierte — und dessen Schwächen erst drei Monate nach Beginn des Produktions-Builds zutage traten, wenn der Wechsel teuer und der Lieferdruck noch höher ist.
LangGraph, CrewAI, AutoGen (jetzt im Wartungsmodus — Microsoft verweist neue Projekte an das Microsoft Agent Framework), Mastra, VoltAgent, Smolagents — jedes hat eine nachvollziehbare Geschichte, eine wachsende Community und überzeugende Demos. Das Problem: Demos sind nicht die richtige Bewertungseinheit. Die richtige Einheit lautet: Hält das Framework unter echter Last stand, mit echten Fehlszenarien, innerhalb einer Organisation, die auditieren, steuern und warten muss?
Nachfolgend finden Sie die acht Kriterien, die wir in jedem Kundenprojekt anwenden, bevor wir uns auf ein Framework festlegen. Arbeiten Sie sie durch, und Sie können die meisten schwachen Kandidaten an einem Nachmittag ausschließen.
Warum Framework-Produktionstauglichkeit eine eigene Disziplin ist
Ein Sprachmodell, das eine Funktion aufruft, ist kein Agent. Ein Agent ist ein automatisiertes System, das Zustände erfasst, Aktionen wählt, Werkzeuge aufruft und iteriert — manchmal minutenlang, manchmal über mehrere Schritte, manchmal mit Geld oder Daten auf dem Spiel. Die Lücke zwischen „funktioniert in der Demo” und „sicher für den unbeaufsichtigten Betrieb im großen Maßstab” ist größer, als die meisten Teams erwarten.
Produktionstauglichkeit umfasst Aspekte, die Tutorials überspringen: Was passiert, wenn ein LLM-Aufruf mitten im Loop abbricht? Wer prüft die Entscheidungen des Agenten? Wo lebt der Gesprächszustand, wenn der Container crasht? Das sind keine Randszenarien — das sind die normalen Betriebsbedingungen jedes Systems, das in nennenswertem Umfang läuft.
Die Acht-Kriterien-Checkliste
1. Observability: Können Sie sehen, was der Agent tatsächlich getan hat?
Das ist der erste Prüfpunkt — und der am häufigsten vernachlässigte.
Ein Produktionsagent braucht strukturierte, exportierbare Traces: Aufzeichnungen auf Schritt-Ebene, die zeigen, welches Werkzeug mit welchen Argumenten aufgerufen wurde, was der LLM zurückgegeben hat, wie lange jeder Schritt gedauert hat und wo der Loop verzweigt hat. Ohne das wird die Fehleranalyse zur Archäologie.
Zu klärende Fragen:
- Emittiert das Framework nativ OpenTelemetry-kompatible Traces, oder müssen Sie diese nachträglich einbauen?
- Können Sie einen bestimmten Lauf für die Post-mortem-Analyse abspielen?
- Werden Token-Zählungen und Latenz auf Schritt-Ebene erfasst?
Frameworks, die Logging als Nachgedanken behandeln, zwingen Sie, alles selbst zu instrumentieren — das kostet bei jedem ernsthaften Deployment in der Regel einen ganzen Sprint.
2. Fehlerbehandlung: Was bricht kontrolliert, was explodiert
LLM-Aufrufe schlagen fehl. APIs geben Rate-Limit-Fehler zurück. Werkzeuge werfen Exceptions. Die Frage ist nicht ob Fehler auftreten, sondern ob das Framework eine durchdachte Antwort darauf hat.
Achten Sie auf:
- Retry-Policies mit konfigurierbarem Backoff, die zwischen wiederholbaren und terminalen Fehlern unterscheiden
- Partial-Run-Recovery — kann ein unterbrochener Workflow ab dem letzten gültigen Zustand fortgesetzt werden, oder startet er von vorne?
- Tool-Fehler-Propagation — bekommt der Agent ein nützliches Signal, oder verfällt er still in einen schlechten Zustand?
Ein Framework ohne Retry-Logik und ohne State-Checkpointing wird um 2 Uhr nachts Produktionsvorfälle verursachen.
3. Zustands- und Speicherpersistenz: Wer besitzt den Kontext?
Kurze Demo-Agenten sind zustandslos. Echte Agenten nicht.
Für alles, was sich über mehrere Gesprächsrunden, Benutzersitzungen oder lang laufende Aufgaben erstreckt, müssen Sie genau verstehen, wo der Agentenzustand lebt:
- Im In-Process-Speicher (weg beim Neustart), in einer Datenbank oder in einem externen Store?
- Wer verwaltet Schema-Migrationen, wenn sich die Zustandsform des Agenten ändert?
- Kann der Zustand manuell inspiziert und korrigiert werden, wenn ein Agent feststeckt?
Manche Frameworks verwenden standardmäßig In-Memory-Zustand ohne Persistenzschicht. Für Prototypen ist das in Ordnung. Für einen kundenorientierten Agenten, der Support-Tickets oder Verkaufsanfragen bearbeitet, bedeutet das Kontextverlust bei jedem Deploy — oder das Bauen einer Persistenzschicht von Grund auf.
Ergänzend dazu: Bei Multi-Agenten-Architekturen wird die Koordination gemeinsamer Zustände zu einem eigenen Problem. Prüfen Sie, ob das Framework dafür ein dokumentiertes Muster hat oder es vollständig Ihnen überlässt. Siehe AI Agent Orchestration: Agenten als System zum Laufen bringen für eine vertiefte Behandlung.
4. Evaluierungswerkzeuge: Woher wissen Sie, dass es besser wird?
Das ist das Kriterium, das Teams, die zuverlässige Agenten liefern, von solchen trennt, die „manuell überwachen.”
Produktionsagenten brauchen Regressionstests — die Fähigkeit, eine definierte Suite von Eingaben auszuführen und sicherzustellen, dass die Ausgaben eine Qualitätsschwelle erfüllen. Das nennt sich Evals, und es ist nicht trivial, das von Grund auf zu bauen.
Fragen Sie:
- Liefert das Framework Eval-Werkzeuge, oder setzt es voraus, dass Sie ein externes Tool integrieren?
- Können Sie Evals lokal vor einem Deploy ausführen?
- Gibt es ein Dataset-Format, um gute/schlechte Beispiele aus der Produktion zu erfassen und in Tests zurückzuführen?
Ohne Eval-Infrastruktur wird jedes Framework-Update oder jede Prompt-Änderung zum Glücksspiel. Siehe KI-Agenten testen: Wie Evals Automatisierung zuverlässig halten für eine vertiefte Behandlung.
5. Sicherheitslage: Tool-Ausführung und Prompt Injection
Agenten führen Code aus, rufen APIs auf und schreiben in Datenbanken. Die Angriffsfläche unterscheidet sich grundlegend von der eines Chatbots.
Kritisch zu prüfen:
- Tool-Berechtigungen — können Sie einschränken, welche Werkzeuge ein Agent je nach Kontext oder Rolle aufrufen darf? Oder hat jedes Werkzeug dieselbe Zugriffsebene?
- Eingabe-Sanitisierung — gibt es einen Schutz gegen Prompt-Injection-Angriffe, bei denen feindliche Inhalte in einem abgerufenen Dokument das Agentenverhalten kapern?
- Secrets-Management — werden API-Schlüssel und Anmeldedaten auf Framework-Ebene verwaltet, oder regelt das jeder Entwickler ad hoc?
Ein Framework ohne Konzept für werkzeugspezifische Berechtigungen ist für keinen Workflow geeignet, in dem ein Agent Kundendaten oder externe Systeme mit Schreibzugriff berührt.
6. Governance-Hooks: Mensch im Loop, wenn es darauf ankommt
Nicht jede Entscheidung sollte autonom getroffen werden. Ihr Governance-Team — und letztlich die Aufsichtsbehörden — werden dokumentierte Punkte einfordern, an denen ein Mensch eingreifen oder prüfen könnte.
Achten Sie auf:
- Interrupt-/Pause-Mechanismen — kann der Agent eine Entscheidung einem menschlichen Operator vorlegen, bevor er eine Aktion oberhalb eines definierten Risikoschwellenwerts ausführt?
- Genehmigungsworkflows — gibt es ein eingebautes Muster für die menschliche Freigabe bei bestimmten Werkzeugaufrufen (z. B. E-Mail senden, Erstattung ausstellen)?
- Audit-Log — gibt es eine unveränderliche Aufzeichnung dessen, was der Agent entschieden hat und warum, in einer für Compliance-Reviews ausreichenden Granularität?
Governance ist zunehmend eine vertragliche Anforderung für Enterprise-Kunden und eine konkrete regulatorische Verpflichtung unter dem EU AI Act, der seit August 2024 in Kraft ist und dessen mehrere Tranchen bereits verbindlich sind. Siehe KI-Agenten Governance: Ein praxisorientiertes Playbook für KMU für das übergeordnete Governance-Bild.
7. Community-Gesundheit und Wartungstrajektorie
Open-Source-Frameworks sind nur so dauerhaft wie die Communities hinter ihnen. Bevor Sie sich festlegen, prüfen Sie:
- Commit-Frequenz — wird das Repo aktiv gepflegt oder verliert es an Dynamik?
- Issue-Response-Zeit — wie lange dauert es, bis ein Maintainer einen Bug-Report bestätigt?
- Breaking-Change-Policy — dokumentiert das Projekt API-Stabilität und Migrationspfade?
- Sponsor-Abhängigkeit — handelt es sich um ein Einzelunternehmen-Projekt, bei dem ein strategischer Kurswechsel den Support beendet?
Ein Framework, das vor sechs Monaten auf GitHub im Trend lag und jetzt sinkende Beitragsgeschwindigkeit aufweist, ist ein Risiko, das eingepreist werden sollte, bevor Sie Monate an Entwicklungszeit investieren.
8. Exit-Kosten: Wie würde eine Migration aussehen?
Das ist die Frage, die bei der Auswahl kaum jemand stellt und die achtzehn Monate später alle stellen.
Wenn Sie dieses Framework verlassen müssen — weil es nicht mehr gepflegt wird, weil Ihre Anforderungen darüber hinausgewachsen sind oder weil eine bessere Option entstanden ist — was kostet das?
Bedenken Sie:
- Wie viel Ihrer Geschäftslogik steckt in Framework-spezifischen Konstrukten statt in portablem Python/TypeScript?
- Sind Ihre Werkzeugdefinitionen außerhalb des Frameworks wiederverwendbar?
- Liegt Ihr Agenten-Zustandsschema in einem Format vor, das Sie kontrollieren, oder ist es für das Framework undurchsichtig?
Frameworks mit hoher Abstraktion und undurchsichtigen Interna tendieren zu hohen Exit-Kosten. Das ist nicht automatisch disqualifizierend, sollte aber eingepreist werden. Siehe KI-Agenten Platform Lock-in: Die Risiken, die niemand einpreist für eine detaillierte Behandlung.
Wie Sie ein Framework schnell bewerten
Wenden Sie jedes Kriterium auf einer Drei-Punkte-Skala an:
| Punkte | Bedeutung |
|---|---|
| 2 | Nativ, dokumentiert, funktioniert sofort |
| 1 | Möglich mit Integration oder eigenem Code |
| 0 | Fehlt — Sie bauen es selbst |
Ein Gesamtwert unter 10 von 16 ist ein Warnsignal. Unter 8 ist ein klares Nein für alles Kundenorientierte oder Compliance-sensible. Die spezifischen Nullen zählen mehr als die Gesamtsumme — eine Null bei der Sicherheitslage ist ein Blocker, unabhängig vom Gesamtergebnis.
Wie eine Framework-Vetting-Session konkret aussieht
Wenden Sie die acht Kriterien auf Ihre Shortlist in einer strukturierten Session an. Zwei Frameworks werden schnell eliminiert, weil ihnen Interrupt-/Genehmigungsmechanismen fehlen. Eines schneidet bei der Governance gut ab, hat aber eine dünne Wartungshistorie — es wird als Abhängigkeitsrisiko markiert. Der verbleibende Kandidat erreicht 13/16 mit einem klaren Migrationspfad. Das ist das Framework, auf dem Sie aufbauen.
Die Kriterien sind dieselben, unabhängig davon, welche Frameworks auf Ihrer Shortlist landen. Für einen breiteren Kontext darüber, was typischerweise die Auswahl besteht, siehe Open-Source KI-Agenten Framework wählen: Die CTO-Shortlist und CrewAI vs. LangGraph: Das richtige Agenten-Framework wählen.
Wann externe Perspektiven sinnvoll sind
Wenn Ihr Team dabei ist, Budget für ein Agenten-Framework ohne strukturierte Evaluierung einzusetzen, ist das der Moment mit dem höchsten Hebel, jemanden hinzuzuziehen, der das bereits getan hat. Die Framework-Wahl beeinflusst Ihre Sicherheitslage, Compliance-Dokumentation, den operativen Aufwand und die zukünftigen Migrationskosten — nicht nur Ihre Sprint-Geschwindigkeit.
Bei Orange ITS läuft diese Evaluierung als Teil jedes KI-Agenten-Entwicklungs-Engagements. Wir haben Frameworks gesehen, die in Demos hervorragend aussehen und unter realer Last zusammenbrechen, und Frameworks, die anfangs grob sind, aber im großen Maßstab dauerhaft funktionieren. Dieses Mustererkennen ist das, was ein guter Evaluierungspartner mitbringt.
Bereit, Ihre Framework-Shortlist unter Druck zu testen, bevor der Build beginnt? Buchen Sie ein 30-minütiges Gespräch mit Orange ITS — wir bewerten Ihre Kandidaten anhand dieser Kriterien und sagen Ihnen ehrlich, auf welchen wir aufbauen würden.