AWS bewertet KI-Agenten über Frameworks hinweg – OpenTelemetry verbindet sie

AWS erläuterte am 26. August 2026, wie Amazon Bedrock AgentCore Evaluations Agenten aus unterschiedlichen Frameworks mit denselben Evaluatoren bewertet. Der technische AWS-Beitrag nennt LangGraph, LlamaIndex, OpenAI Agents SDK, Google ADK, Claude Agent SDK und Strands Agents sowie einen generischen Pfad für kompatibel instrumentierte Frameworks.

Die am 26. August beschriebene Architektur verschiebt die Integrationsgrenze vom Framework auf die Telemetrie: AgentCore vereinheitlicht unterstützte Traces, nicht die internen Zustandsmodelle der Agenten. Eine am Folgetag veröffentlichte unabhängige technische Einordnung bestätigt die sechs genannten Frameworks und den Telemetrievertrag; ihre darüber hinausgehenden Architektur- und Kostenannahmen sind jedoch nicht durch AWS belegt.

Die Erweiterung war bereits für Juli dokumentiert

Der 26. August ist das Veröffentlichungsdatum der ausführlichen technischen Erklärung, nicht eindeutig das Freigabedatum der Funktion. Die AWS-Release-Notes für Juli 2026 führen die erweiterte Framework-Unterstützung bereits in diesem Monat auf: OpenAI Agents, LlamaIndex, Google ADK und Claude Agent SDK kamen dort zu Strands Agents und LangGraph hinzu.

Der Dienst selbst war zu diesem Zeitpunkt keine neue Vorschau. AgentCore Evaluations war laut denselben Release-Notes bereits seit März 2026 allgemein verfügbar. Neu beziehungsweise neu dokumentiert war die breitere Abdeckung samt generischem Integrationspfad über die OpenTelemetry-GenAI- oder OpenInference-Konventionen.

Welche Frameworks und Instrumentierungen zusammenpassen

Die Kompatibilität hängt von einer konkreten Kombination aus Framework, Python-Instrumentierungsbibliothek und erkanntem scope.name ab. Der Name des Frameworks allein reicht nicht aus.

• Strands Agents: verwendet die integrierte Telemetrie des Strands Agents SDK.
• LangGraph: wird über die LangChain-Instrumentierung für OpenTelemetry oder OpenInference erfasst.
• OpenAI Agents SDK: besitzt unterstützte Instrumentierungspfade für OpenTelemetry und OpenInference.
• LlamaIndex: kann ebenfalls über Bibliotheken für beide Konventionen angebunden werden.
• Google ADK: ist über seine OpenInference-Instrumentierung aufgeführt.
• Claude Agent SDK: wird über die zugehörige OpenInference-Instrumentierung angebunden.

Für nicht ausdrücklich genannte Frameworks existieren zwei generische Pfade. AgentCore liest Instrumentierungen mit einem Scope unter opentelemetry.instrumentation.* nach den OpenTelemetry-GenAI-Konventionen und solche unter openinference.instrumentation.* nach der OpenInference-Konvention. Infrastruktur-Spans, die zwar ähnlich benannt sind, aber keine Agentenoperation darstellen, werden dabei nicht automatisch zu auswertbaren Agententraces.

Vollständige Traces sind die eigentliche Mindestanforderung

Für die Rekonstruktion eines vollständigen Gesprächsschritts benötigt der Dienst drei funktionale Rollen: einen übergeordneten Agentenaufruf mit Eingabe und endgültiger Antwort, die einzelnen Modellaufrufe sowie die Werkzeugaufrufe mit Name, Parametern und Ergebnis. Retrieval-, Reranking-, Guardrail- oder Memory-Spans können Kontext liefern, ersetzen diese Rollen aber nicht.

AgentCore gruppiert zusammengehörige Abläufe über session.id; innerhalb einer Sitzung entspricht ein Trace grundsätzlich einem Nutzerschritt. Der Instrumentierungs-Scope bestimmt, nach welchem Schema der Dienst Operationen klassifiziert und Nachrichten- oder Werkzeugdaten ausliest. Ein eigener Scope außerhalb der unterstützten Präfixe wird nicht allein deshalb erkannt, weil seine Attribute ähnlich aufgebaut sind.

Auch die Nachrichteninhalte müssen die ausgewählte CloudWatch-Datenquelle erreichen. Bei der vereinheitlichten Observability-Konfiguration liegen Spans und Inhalte in der agentenspezifischen Log-Gruppe. In älteren Konfigurationen können Spans dagegen in aws/spans und die korrelierten Ereignisse mit Ein- und Ausgaben in einer separaten Agenten-Log-Gruppe liegen. Eine Datenquelle, die nur die Spans enthält, kann Operationen klassifizieren, aber keine inhaltsbezogene Antwortqualität bewerten.

Weitere Lücken entstehen vor dem Dienst: Deaktiviertes internes Tracing im OpenAI Agents SDK unterbindet die benötigten Spans. Bei LlamaIndex muss die Agentenstruktur einen übergeordneten Agenten-Span erzeugen. In kurzlebigen Runtime-Aufrufen müssen außerdem sowohl der Trace- als auch der Log-Puffer exportiert werden; fehlt einer davon, bleiben Sitzungen oder Nachrichteninhalte unvollständig.

On-Demand prüft ausgewählte Läufe, Online beobachtet Produktion

On-Demand-Evaluierung verarbeitet gezielt ausgewählte Spans, Traces oder Sitzungen. Weil Teams die Aufrufe kontrollieren, können sie Referenzantworten, erwartete Werkzeugfolgen und Verhaltensaussagen mitgeben. Das macht den Modus für Regressionstests und CI/CD geeignet, ohne ihn auf diese Anwendungsfälle zu beschränken.

Online-Evaluierung überwacht dagegen neu eintreffende Produktionssitzungen aus einer konfigurierten CloudWatch-Datenquelle. Die Konfiguration legt unter anderem Datenquellen, Evaluatoren und Stichprobenparameter fest. Für ungeplanten Produktionsverkehr fehlen normalerweise vorab definierte Referenzantworten; eigene Evaluatoren, deren Anweisung solche Ground-Truth-Felder voraussetzt, sind deshalb nur für kontrollierte Auswertungen geeignet.

Beide Modi verwenden dieselbe vereinheitlichte Trace-Verarbeitung. Das bedeutet jedoch nicht, dass ihre Scores ohne Weiteres austauschbar sind: Ein festes Testset und eine Stichprobe realer Nutzerinteraktionen können sich bei Eingaben, Schwierigkeit und verfügbarer Referenz unterscheiden. Vergleichbar werden Ergebnisse erst unter konsistenten Kriterien und einer ähnlich vollständigen Telemetrie.

Einheitliche Evaluatoren beseitigen nicht die Bewertungsgrenzen

AgentCore bietet integrierte und eigene Evaluatoren auf Sitzungs-, Trace- oder Werkzeugebene. Sprachmodellbasierte Evaluatoren arbeiten als LLM-as-a-Judge und können etwa Zielerreichung, Korrektheit oder Hilfreichsein anhand ihrer Anweisungen beurteilen. Eigene codebasierte Evaluatoren eignen sich dagegen für deterministische Regeln.

Ein frameworkübergreifend berechneter Wert ist deshalb kein objektiver Benchmark des Frameworks. Er bewertet den beobachteten Agentenlauf unter einer bestimmten Rubrik und mit dem verfügbaren Kontext. Unterschiede können aus dem Agentenverhalten stammen, aber ebenso aus fehlenden Werkzeug-Spans, abweichenden Testeingaben oder unvollständigen Nachrichteninhalten.

Fest steht damit die breitere Unterstützung der sechs genannten Frameworks und kompatibler OpenTelemetry- beziehungsweise OpenInference-Instrumentierung. Ob eine konkrete Installation belastbare Ergebnisse liefert, entscheidet sich weiterhin an Scope, Sitzungszuordnung, Span-Rollen, Nachrichteninhalt und zuverlässigem Export. OpenTelemetry verbindet die Frameworks für die Auswertung – es garantiert nicht automatisch vollständige oder gleichwertige Messdaten.