openai agents ai-economics llm observability

Wie die Agents API von OpenAI die Wirtschaftlichkeit der KI-Arbeit verändert

Der Agent führt Modelliterationen, Toolaufrufe, Sandbox-Tests, Wiederholungsversuche sowie menschliche Überprüfungen durch, wodurch die Token-Zählung nicht mehr die Kosten angibt. Messen Sie stattdessen die angenommenen Aufgaben.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 23. Okt. 20269 Min. Lesezeit2004 Wörter

Quellen: OpenAI’s Agents API Changes the Economics of AI Work

Die Agents API von OpenAI ist dafür konzipiert, Cloud-Agenten über längere Sitzungen laufen zu lassen und verfügt über Werkzeuge, Sandboxes, Dateien, eine Kontextverwaltung sowie Subagenten, die parallel arbeiten. Ein Agent kann ein Problem untersuchen, Code ausführen, Aufgaben an andere weitergeben, Zwischenergebnisse speichern und so lange fortfahren, bis die Aufgabe abgeschlossen ist.

Das verändert nicht nur die Art und Weise, wie Entwickler Agenten erstellen, sondern auch, wie ein Unternehmen die Kosten dafür ermitteln sollte.

Ein einziger Anfrage kann nun eine Kette von Modellaufrufen, Werkzeugaufrufen, Sandbox-Operationen, Wiederholungsversuchen, gespeicherten Ergebnissen sowie menschlichen Freigaben auslösen. Tokens erscheinen weiterhin auf der Rechnung, sagen aber nicht mehr aus, was die eigentlichen Kosten der Arbeit sind. Die zu verfolgende Einheit ist die abgeschlossene Aufgabe: korrekt, wiederherstellbar, prüfbar und im Wert dessen, was zur Erstellung aufgewendet wurde.

Eine Anfrage ist nicht mehr eine Arbeitseinheit

Ein gewöhnlicher Modellaufruf weist eine klare Abgrenzung auf: Die Anwendung sendet Eingaben, das Modell gibt Ausgaben zurück, und die Anwendung geht mit ihrer Arbeit weiter.

Die Agents API ist für eine andere Art der Ausführung konzipiert. Der Agent erhält ein Ziel und entscheidet selbst, wie er es verfolgen soll. Nehmen wir an, man bittet einen Agenten, einen Anstieg der 5xx-Fehler zu untersuchen:

Erfahren Sie, warum service-api in den letzten 30 Minuten einen ungewöhnlichen Anstieg der Fehler aufweist, und empfehlen Sie eine sichere Abhilfe.

Ein herkömmlicher Assistent würde beschreiben, wie ein Ingenieur vorgehen könnte. Ein in die richtigen Systeme eingebundener Agent kann sofort damit beginnen. Er überprüft kürzliche Bereitstellungen, durchsucht Anwendungsprotokolle, vergleicht Abhängigkeitsversionen, betrachtet Infrastrukturmetriken, delegiert separate Analysen, führt Diagnosecodes aus, speichert Beweise und wartet auf Freigabe, bevor er etwas ändert.

Der Benutzer sieht eine Anfrage. Das System hat einen gesamten Workflow abgewickelt.

OpenAI’s praktischer Leitfaden zur Erstellung von Agenten bezeichnet dies als „Ausführung“: eine Schleife, die so lange weiterläuft, bis der Agent die Aufgabe erledigt hat, eine endgültige Ausgabe erzeugt hat, auf einen Fehler stößt oder eine konfigurierte Grenze erreicht hat. Die Kosten sammeln sich innerhalb dieser Schleife an.

Die Laufzeit hat eine versteckte Rechnung

Token sind Teil der Rechnung. Sie sind lediglich der Teil, der am leichtesten sichtbar ist.

Zurück zum Produktionsvorfall: Zuerst holt der Agent die aktuellen Fehlerraten aus einem Überwachungstool, liest anschließend die Bereitstellungshistorie und durchsucht die Protokolle. Jeder dieser Aufrufe hat einen Preis, eine Verzögerung, eine Reihe von Berechtigungen sowie seine eigene Art, fehlerhaft zu werden.

Dann liefert das Protokollierungstool 500 Einträge. Das klingt nützlich – bis man sieht, was danach passiert. Die Einträge müssen verschoben, verarbeitet und in den Kontext des Modells eingefügt werden. Die meisten sind irrelevant, und das Modell verbringt Zeit damit, „Rauschen“ zu lesen, bevor es die fünf Ereignisse findet, die den Vorfall erklären.

Daher ist die Tool-Entwicklung auch eine Kostenplanung. Ein Suchtool, das eine kurze, strukturierte Zusammenfassung liefert, kann günstiger und zuverlässiger sein als eines, das jeden passenden Eintrag anzeigt. Die Antwort der API besteht aus Tool-Suche in Kombination mit programmatischem Aufruf des Tools – wodurch die Tool-Definitionen nur dann sichtbar werden, wenn sie benötigt werden, und die Ergebnisse können gefiltert oder kombiniert werden, bevor sie das Modell erreichen.

Die gleiche Logik gilt auch für die Ausführung in einer Sandbox. Ein Diagnoseskript verbraucht CPU-Ressourcen, Speicher, Speicherplatz, Zeit für die Installation von Paketen und möglicherweise Netzwerkzugang. Wenn es einen Bericht oder eine Sammlung von Beweismitteln erzeugt, müssen diese Artefakte gespeichert, indiziert, überprüft oder aufbewahrt werden.

Lange Laufzeiten der Agenten erzeugen außerdem mehr als nur Text. Bei der Untersuchung eines Vorfalls können die Beweismittel hinter einer Diagnose wichtiger sein als die schriftliche Zusammenfassung. Bei der Programmierung ist der Patch ein Bestandteil der Ergebnisse, während Testergebnisse und eine Abhängigkeitsanalyse genauso wertvoll sein können.

Ein kleines Beispiel aus dem Agents SDK zeigt, wo die Ausführungsgrenze liegt:

from agents import Agent, Runner, function_tool
@function_tool
def get_error_rate(service: str, minutes: int = 30) -> str:
    """Return the recent error rate for a service."""
    return f"{service}: 8.4% errors over {minutes} minutes"
investigator = Agent(
    name="Incident investigator",
    instructions=(
        "Investigate the incident, use evidence, and recommend "
        "the safest next action. Do not change production state."
    ),
    tools=[get_error_rate],
)
result = Runner.run_sync(
    investigator,
    "Investigate the elevated 5xx rate in service-api."
)

Die Funktion ist winzig. Die wirtschaftlichen Aspekte hingegen nicht. Alles hängt vom Agenten ab: ob er aufgerufen wird, ein zweites Mal aufgerufen wird, wie sein Ergebnis ausgelesen wird und ob eine weitere Tool-Nutzung oder die Zustimmung eines Menschen erforderlich ist.

Zuverlässigkeit, Kontrolle und Akzeptanz definieren den Erfolg

Das SDK stellt die Komponenten für den Laufzeitbetrieb hinter diesem Prozess bereit: Agenten, Ausführungsmechanismen, Tools, Übergabeprozesse, Sitzungen, Sicherheitsregeln und Überwachungsfunktionen. Sie sind wichtig, weil reale Arbeitsabläufe selten auf Anhieb erfolgreich sind.

Die Protokollabfrage könnte ablaufen, weshalb der Agent es erneut versucht. Die zweite Abfrage funktioniert, liefert aber unvollständige Daten. Der Agent formuliert die Abfrage neu, holt ein größeres Datensatz an und bittet einen spezialisierten Agenten, die Bereitstellungshistorie zu prüfen. Schließlich ist die Untersuchung erfolgreich.

Für den Benutzer hat der Agent die Aufgabe abgeschlossen. Aus wirtschaftlicher Sicht umfasste die Aufgabe jedoch auch fehlgeschlagene Versuche, zusätzliche Modelliterationen, mehr Toolaufrufe sowie mehr verstrichene Zeit.

Wiederholte Versuche sind nicht automatisch verschwendet. Ein Versuch, der nach einem vorübergehenden Fehler wieder zum Erfolg führt, kann genau das sein, was einen Agenten zuverlässig macht. Das Problem entsteht, wenn diese Wiederholungsversuche in eine einzige Gesamterfolgszahl zusammengefasst werden.

Parallel arbeitende Agenten tauschen Zeit gegen Kosten

Die API kann komplexe Aufgaben auf Subagenten aufteilen, die nebeneinander laufen. Bei der Untersuchung eines Incidents erhält ein Spezialist beispielsweise die Bereitstellungshistorie, ein anderer die Anwendungsfehler und ein dritter die Abhängigkeitsänderungen, während ein Koordinator ihre Erkenntnisse zusammenführt.

Die reine Laufzeit kann sinken, da alles gleichzeitig abgewickelt wird. Die Gesamtkosten können jedoch steigen, da man nun für mehrere separate Modellkontexte, mehrere Tool-Aufrufketten, die Koordination, einen Syntheseschritt und möglicherweise sogar doppelte Bearbeitung desselben Stoffes bezahlen muss.

Deshalb wirken Mehr-Agentensysteme wie verteilte Systeme mit Sprachmodellen im Kreislauf. Der Koordinator fungiert als Scheduler, die Spezialisten sind Arbeiter, externe Tools sind Dienste, und Dateien sowie Datenbanken bilden den gemeinsamen Zustand. Die bekannten Probleme treten auf: teilweiser Ausfall, Wiederholungsversuche, inkonsistenter Zustand, wiederholte Arbeit, Konkurrenzbeschränkungen sowie unklare Kostenzuordnungen. Mehr Agenten bedeuten nicht automatisch besseres Denken. Parallelität muss durch die Struktur der Aufgabe sowie den Wert der Zeit gerechtfertigt werden.

Akzeptanz ist die Ziellinie

Die Generierung kann lange vor Abschluss der eigentlichen Arbeit enden. Im Fall eines Support-Anliegens könnte die Akzeptanz bedeuten, dass das Problem des Kunden ohne unnötige Eskalation gelöst wurde. Bei einer Programmieraufgabe könnte sie bedeuten, dass die Tests bestanden sind, die Überprüfungsstandards erfüllt wurden und die Änderung eingefügt wurde. Im Incident-Response-Kontext könnte sie bedeuten, dass eine Diagnose durch Beweise gestützt wurde und zu einer sicheren Abmilderung führte. Die daraus resultierende Kennzahl ist:

cost per accepted task =
    total execution cost / tasks accepted without rework

Falls ein Agent innerhalb von zehn Sekunden antwortet und eine Person anschließend zehn Minuten damit verbringt, das Problem zu beheben, war die zehnsekündige Antwort nicht das günstige Ergebnis. Es war lediglich der günstige Versuch.

Dass eine Person das Ergebnis überprüft, bedeutet nicht, dass die Automatisierung fehlgeschlagen ist. Bei arbeitsintensiven Aufgaben kann gerade die Genehmigung durch einen Menschen dazu führen, dass die Automatisierung überhaupt akzeptabel wird. Man sollte das geringste mögliche menschliche Eingreifen anstreben, das dennoch eine echte menschliche Kontrolle bewahrt.

Das SDK bietet Eingabesicherungen, Ausgabesicherungen sowie Toolsicherungen, und seine Dokumentation trennt die Überprüfungen auf Agentenebene von denen auf Tool-Ebene: Bei Konfigurationen mit beauftragten Spezialisten können Überprüfungen für einzelne Funktions-Tools sowie MCP-Operationen erforderlich sein. Solche Sicherungen erfordern Aufwand und manchmal zusätzliche Modellaufrufe. Zudem können sie weitaus größere Kosten durch falsche Aktionen, Datenoffenlegung, Verstöße gegen Richtlinien oder regulatorische Probleme verhindern. Die Ausgabe gilt erst nach Qualitätskontrollen sowie unter Berücksichtigung des richtigen Grades an menschlicher Kontrolle als abgeschlossene Aufgabe.

Von Spuren zu Geschäftswert

Jedes neue Tool erweitert die Möglichkeiten eines Agents. Gleichzeitig erhöhen sich auch die Berechtigungen des Systems, die Latenz, die Fehlermöglichkeiten sowie die Anforderungen an die Verwaltung.

Die API unterstützt benutzerdefinierte Funktionen, eingebaute Tools sowie MCP-Server. MCP standardisiert die Verbindung von KI-Anwendungen mit externen Tools, Ressourcen und Anfragen. Dadurch wird die Integration erleichtert, doch ein entferntes Tool wird dadurch nicht automatisch zuverlässig. Die MCP-Spezifikation warnt davor, Toolbeschreibungen und Anmerkungen von unzuverlässigen Servern automatisch zu vertrauen, und empfiehlt sichtbare Aufrufe der Tools sowie menschliche Genehmigung für Aktionen. Fernsteuerung bringt zusätzliche Herausforderungen mit sich, wie die Überprüfung des Token-Zugriffsrechts, die sichere Speicherung von Tokens, PKCE sowie der Schutz vor confused-deputy-Angriffen. Jede neue Funktion erzeugt neue Grenzen hinsichtlich Autorisierung, Prüfung und Verwaltung.

Spuren sind Buchhaltungsdaten

Die endgültige Antwort verrät kaum etwas darüber, wie sie zustande gekommen ist. Man kann nicht erkennen, welche Werkzeuge berücksichtigt wurden, wie viele ausgeführt wurden, ob ein Unteragent versagte oder was dazu führte, dass eine Person einbezogen wurde.

Das SDK liefert Protokolle, die Generationen, Werkzeugaufrufe, Übertragungen, Schutzmechanismen sowie benutzerdefinierte Ereignisse umfassen. Protokollierung wird in der Regel als Hilfsmittel zur Fehlersuche eingeführt, dient aber auch als Buchhaltungssystem. Ein Protokoll kann zeigen, dass ein Werkzeug den größten Teil der Verzögerung verursacht, dass ein Workflow immer wieder dieselbe Suche wiederholt oder dass eine bestimmte Modellwahl bei weniger Wiederholungen eine höhere Akzeptanz bringt. Ohne Protokolle optimieren Teams Durchschnittswerte. Mit ihnen können sie einzelne Phasen des Workflows optimieren.

Die Leistungsübersicht sollte Ausführungsdaten mit Ergebnisdaten verknüpfen: den Kosten für jede abgeschlossene Aufgabe zusammen mit der Anzahl der Modellaufrufe und Toolaufrufe, der Zeit im Sandbox-Umfeld, der Häufigkeit von Wiederholungsversuchen und deren Erfolg, sowie den Umbaukosten, den Minuten der Prüfer, den Eskalationen und dem erbrachten Wert. Das genaue Dashboard hängt vom Workflow ab. Ein Support-Team könnte an Fällen interessiert sein, die ohne Eskalation abgeschlossen wurden, ein Plattform-Team an gemilderten Vorfällen, ein Produktteam an geschütztem Umsatz oder eingespartem Personalzeit. Was sich ändert, ist das, womit man teilt.

Die strategische Entscheidung

Organisationen sollten nicht damit beginnen, darüber nachzudenken, wie man einen Agenten pro Anruf günstiger macht. Zuerst muss die schwierigere Frage gestellt werden:

Kann dieser Agent diese Art von Arbeit zuverlässig genug bewältigen, sodass die Gesamtkosten unter denen des aktuellen Prozesses liegen?

Dafür benötigt man eine ehrliche Grundlage für den aktuellen Prozess, die die Mitarbeiterzeit, das Warten in Warteschlangen, wiederholte Übergaben, die Infrastruktur, Fehler und deren Nachbearbeitung, verpasste Chancen sowie die Anstrengungen zur Einhaltung von Vorgaben umfasst. Ein Agent, der 2 Dollar pro bearbeiteter Aufgabe kostet, kann eine hervorragende Investition sein, wenn der bestehende Prozess 20 Dollar kostet. Ein Agent, der 0,10 Dollar pro Versuch kostet, kann hingegen eine schlechte Investition sein, wenn nur die Hälfte seiner Ergebnisse angenommen wird und jeder Fehler von Menschen korrigiert werden muss.

Ein vernünftiger Optimierungsplan beginnt mit dem einfachsten System, das die Aufgabe erledigen kann. Verwenden Sie kleinere Modelle für die Routenplanung, Filterung oder einfache Validierung und wechseln Sie zu leistungsstärkeren Modellen, wenn ein tieferes Denken erforderlich ist. Stellen Sie sicher, dass die Tools kompakte, strukturierte Ergebnisse liefern. Parallelisieren Sie nur unabhängige Aufgaben. Überprüfen Sie die Folgehandlungen. Bewahren Sie ausreichende Belege auf, um Überprüfungen und Wiederherstellungen zu ermöglichen.

Das SDK lohnt sich, wenn die Laufzeit selbst Umläufe, Tools, Sitzungen, Übertragungen, Schutzmechanismen oder die Koordination zwischen Agenten verwalten muss. Die Responses API bleibt sinnvoll, wenn ein Team die Kontrolle über den gesamten Ablauf sowie die Zustandsverwaltung selbst in die Hand nehmen möchte. Diese Wahl ist architektonisch bedingt – und auch finanziell relevant.

Messen Sie die Arbeit, nicht die Worte

Die Agents API erleichtert es, Agenten zu entwickeln, die in verschiedenen Tools, Umgebungen, Sitzungen und Unteragenten arbeiten können, und das SDK bietet Anwendungsebene-Primitiven, um sie zu koordinieren, mit Schutzmechanismen zu schützen und durch Spuren zu überprüfen. Gemeinsam weisen sie auf eine andere Denkweise bezüglich der Wirtschaftlichkeit von KI hin.

Die eingehende Anfrage ist lediglich der Eingangspunkt, nicht die Recheneinheit. Die Recheneinheit ist die abgeschlossene Aufgabe, die als korrekt anerkannt werden kann, im Falle eines Fehlers wiederhergestellt werden kann, nachträglich überprüft werden kann und deren Kosten gerechtfertigt sind. Eine Preiskalkulation pro Token bleibt weiterhin als einzelne Posten nützlich. Alles Weitere – Tools, Rechenleistung, Speicher, Wiederholungsversuche, Latenz, Sicherheit sowie menschliche Aufmerksamkeit – wird auf einer anderen Stelle der Rechnung ausgewiesen.

Die besten Agentensysteme werden nicht die sein, die die wenigsten Tokens erzeugen. Es werden vielmehr die sein, die die wertvollsten Arbeiten zu einem sinnvollen Gesamtkostenrahmen abschließen.