Der Agentenkurs · Produktion
Vom Prototyp zur Produktion
Lernziele
- Du benennst vier Bereiche, in denen eine Demo im Betrieb bricht, und eine Gegenmaßnahme für jeden.
- Du trennst die Logik eines Agenten von seinen Auslösern und setzt ein Gateway vor jeden Modellaufruf.
- Du beschreibst den Weg einer Änderung über CI und Staging bis zum schrittweisen Rollout.
Jedes bisherige Modul endet mit etwas, das auf deinem Rechner funktioniert. In diesem Modul hängen andere davon ab: Menschen im Team, andere Systeme oder ein Zeitplan, der um drei Uhr nachts startet. Googles Whitepaper Prototype to Production (Nov. 2025) beginnt mit dem Satz „Building an agent is easy. Trusting it is hard.“ Einen AgentEin System, in dem ein Sprachmodell seinen nächsten Schritt selbst wählt: Es ruft Werkzeuge auf, wertet das Ergebnis aus und macht weiter, bis das Ziel erreicht ist.Im Glossar zu bauen ist leicht, ihm zu vertrauen ist schwer.
Das Autorenteam beobachtet nach eigener Aussage bei Kunden, dass rund 80 % des Aufwands auf Infrastruktur, Sicherheit und Validierung entfallen. Die Intelligenz des Agenten selbst macht den kleineren Teil der Arbeit aus.
Was bricht, wenn die Demo auf Betrieb trifft
Eine Demo läuft, während du zusiehst, mit Eingaben, die du ausgewählt hast, und mit deinen eigenen Zugangsdaten. Im Betrieb fallen alle drei Annehmlichkeiten gleichzeitig weg. Was dann bricht, lässt sich vorhersagen:
- Zuverlässigkeit. Anbieter laufen in Timeouts, drosseln Anfragen und liefern gelegentlich Unbrauchbares. Ohne Wiederholungen mit wachsendem Abstand (Backoff) und ohne idempotente Tool · engl. toolEin Werkzeug, das das Modell aufrufen kann: eine API, eine Datenbankabfrage, ein Shell-Befehl, eine Suche. Über Tools wirkt das Modell auf die Welt.Im Glossar ruiniert ein einziger wackeliger Aufruf den ganzen Lauf. Ein idempotentes Tool darfst du gefahrlos zweimal aufrufen. Wiederholst du ein Tool ohne diese Eigenschaft, geht die E-Mail zweimal raus.
- Kosten. Ein Loop · engl. agent loopDie Schleife eines Agenten: denken, handeln, beobachten, wiederholen. Zwischen den Durchläufen wird der Kontext des Modells jedes Mal neu gebaut.Im Glossar, der 40 Cent kostet, solange du danebensitzt, kostet ohne Aufsicht, so viel er will. Unbegrenzte Läufe brauchen vor allem anderen eine Obergrenze für Runden und für Dollar, wie in der Lektion Loop oder Workflow.
- Eingaben. Echter Verkehr enthält kaputte Dateien, feindseligen Text und Randfälle, die deine drei Test-Prompts nie abgedeckt haben.
- Änderungen. In der Demo steht der Prompt · engl. promptDer Text, den du einem Sprachmodell bei einem Aufruf schickst. In einem Agenten setzt er sich aus Systemprompt, Tool-Definitionen, Verlauf und aktueller Anfrage zusammen.Im Glossar dort, wo du ihn zuletzt eingefügt hast. Im Betrieb ist eine unversionierte Änderung am Prompt ein DeploymentDer Betrieb eines Systems: Hosting, Logging, Monitoring. Der Teil, der aus einer Demo einen Dienst macht.Im Glossar, das niemand prüfen kann.
Demo
- Wer startet: du, während du zusiehst
- Eingaben: von dir ausgewählt
- Zugangsdaten: deine eigenen
- Prompt: dort, wo du ihn zuletzt eingefügt hast
Betrieb
- Wer startet: ein Zeitplan, ein Ereignis oder ein anderes System
- Eingaben: echter Verkehr mit kaputten Dateien und feindseligem Text
- Zugangsdaten: eine eigene Identität mit minimalen Rechten
- Prompt: versioniert und vor jedem Release von Evals geprüft
Das Whitepaper fasst den Wechsel unter einer eigenen Disziplin zusammen und nennt sie AgentOpsDie Betriebsdisziplin für Agenten, wie sie Googles Whitepaper „Prototype to Production“ beschreibt: Evaluationen entscheiden über jedes Release, alles Verhaltensrelevante ist versioniert, und Logs, Traces und Metriken zeigen den Betrieb.Im Glossar. Drei Dinge gehören dazu. Automatische Evaluationen entscheiden über jedes Release. Alles, was das Verhalten prägt, ist versioniert. Logs, Traces und Metriken zeigen, was im Betrieb passiert. Stichproben von Hand, schnelle Anpassungen und das Gefühl „lief doch“ tragen ab hier nicht mehr.
Drei Auslöser und ein Agent
Agenten im Betrieb starten auf drei Wegen: nach einem Zeitplan (die nächtliche Zusammenfassung), durch ein Ereignis (eine Datei kommt an, ein Webhook feuert) oder über eine API (ein Mensch oder ein anderes System fragt jetzt gerade). Palantir beschreibt in der Architektur seiner Plattform AIP genau diese drei Formen: Automatisierungen nach Zeitplan, ereignisgesteuerte Automatisierungen nahezu in Echtzeit und Automatisierungen, die mit API-Aufrufen verzahnt sind. Alle drei greifen auf dieselbe Grundlage aus Daten, Logik und Aktionen zu.
Daraus folgt eine Regel für den Entwurf: Trenne die Logik des Agenten von seinem Auslöser. Du schreibst eine Agentendefinition und davor drei schmale Adapter. Sind die Version für den Zeitplan und die Version für die API zwei Codebasen, muss jede Korrektur zweimal landen. Früher oder später laufen die beiden Versionen auseinander.
Ein Gateway vor jedem Modellaufruf
Nach unserer Einschätzung ist das wirksamste Stück Infrastruktur ein GatewayEin zentraler Durchgang, durch den jeder Modellaufruf läuft. Dort werden sensible Felder maskiert, Antworten gecacht, fehlgeschlagene Aufrufe wiederholt und Tokens und Kosten pro Aufruf gezählt.Im Glossar: ein einziger Durchgang, durch den jeder Modellaufruf läuft, ohne Ausnahme. Es erledigt vier Aufgaben:
- Maskieren. Sensible Felder werden entfernt oder pseudonymisiert, bevor sie dein Netz verlassen.
- Cachen. Für identische Aufrufe und wiederholte Präfixe liefert das Gateway Ergebnisse aus dem Zwischenspeicher.
- Wiederholen und ausweichen. Backoff, der Wechsel zu einem anderen Anbieter und ein Notschalter liegen an einer einzigen Stelle.
- Tokens zählen. Jeder Aufruf trägt die Angabe, wer ihn ausgelöst hat und was er gekostet hat.
Größere Plattformen zeigen dasselbe Muster. Palantir führt den Zugriff auf Sprachmodelle in AIP über eine eigene, von Palantir verwaltete Infrastruktur. Laut Palantir behalten die Modellanbieter dabei keine übertragenen Daten, und die Beobachtung der Plattform reicht bis zum Token-Verbrauch. Für die Form brauchst du keine solche Plattform. Ein Proxy mit rund 200 Zeilen Code bringt dich nach unserer Einschätzung schon weit.
Welche Aufgabe des Gateways greift?
Ordne jede Situation der Aufgabe des Gateways zu, die sie abfängt.
Noch offen (6)
- Eine Kundenanfrage enthält eine IBAN, die nicht beim Modellanbieter landen soll.
- Der Anbieter antwortet mit einem Rate-Limit-Fehler.
- Die Finanzabteilung will wissen, welcher Auslöser im März die meisten Tokens verbraucht hat.
- Derselbe Klassifikationsaufruf mit identischer Eingabe kommt hundertmal am Tag.
- Ein Anbieter fällt eine Stunde lang aus.
- Ein Lauf gerät außer Kontrolle, und du willst alle Modellaufrufe sofort stoppen.
Maskieren (0)
Cachen (0)
Wiederholen und ausweichen (0)
Tokens zählen (0)
Das ganze Bild sieht so aus:
Schritt 1 von 4
Drei Auslöser
Ein Zeitplan, ein Ereignis oder ein API-Aufruf startet den Lauf. Jeder Auslöser ist nur ein schmaler Adapter.
Der Weg aus dem Whitepaper
Im Whitepaper ist der Weg in die Produktion ein Lebenszyklus mit drei Phasen.
- Prüfung vor dem Merge (CI). Jeder Pull Request startet die Eval-Suite. Verschlechtert eine Änderung das Verhalten in wichtigen Szenarien, fällt das auf, bevor sie im Hauptzweig landet.
- Staging (CD). Nach dem Merge läuft der Agent in einer Staging-Umgebung, einem möglichst getreuen Abbild der Produktion. Dort laufen Lasttests, Integrationstests gegen externe Dienste und Tests durch Menschen aus dem eigenen Haus.
- Freigabe für die Produktion. Dieser Schritt läuft laut Whitepaper fast nie vollautomatisch. Meist gibt eine verantwortliche Person aus dem Produktteam die Freigabe. Danach geht genau das Artefakt in Produktion, das im Staging geprüft wurde.
Ausgerollt wird schrittweise. Das Whitepaper nennt vier Muster, darunter Canary und Blue-Green. Ein Canary-Release startet mit 1 % der Nutzerinnen und Nutzer, und das Team beobachtet dabei Prompt-Injections und ungewöhnliche Tool-Nutzung. Danach wird es schrittweise ausgeweitet oder sofort zurückgenommen. Bei Blue-Green laufen zwei gleiche Produktionsumgebungen. Der Verkehr wechselt auf einen Schlag zur neuen und bei Problemen genauso schnell zurück. Beides setzt voraus, dass jeder Bestandteil versioniert ist: Code, Prompts, Modell-Endpunkte, Tool-Schemas, Speicherstrukturen und sogar die Eval-Datensätze.
Eine fehlgeschlagene Evaluation blockiert das Deployment automatisch. Damit werden die zwei Arten von Checks aus Modul 5 zur Schranke vor dem Release. Der Kreis schließt sich über die Produktions-TraceDie vollständige Aufzeichnung eines Agentenlaufs: Modellrunden, Tool-Aufrufe mit ihren Argumenten, Tool-Ergebnisse und Wiederholungen. Verhaltenschecks lesen den Trace.Im Glossar: Sie liefern neue Fälle für die Eval-Suite, die das nächste Release strenger prüft. Das Whitepaper zeigt das an einem Agenten im Handel. Laut den Logs bekommen 15 % der Nutzerinnen und Nutzer bei der Frage nach ähnlichen Produkten einen Fehler. Aus den Logs entsteht ein neuer Testfall, die Korrektur besteht die erweiterte Suite und geht per Canary live, im Beispiel in unter 48 Stunden.
All das ist gewöhnliche Softwaredisziplin, angewendet auf eine Komponente, die probabilistisch arbeitet. Die nächste Lektion behandelt den laufenden Betrieb: beobachten, bezahlen und absichern.
Merksätze
- Laut Googles Whitepaper fließen rund 80 % des Aufwands in Infrastruktur, Sicherheit und Validierung.
- Im Betrieb brechen Zuverlässigkeit, Kosten, Eingaben und Änderungen, und für jeden Bereich gibt es eine bekannte Gegenmaßnahme.
- Eine Agentendefinition steht hinter drei schmalen Adaptern für Zeitplan, Ereignis und API.
- Ein Gateway vor jedem Modellaufruf maskiert, cacht, wiederholt und zählt an einer einzigen Stelle.
- Jede Änderung läuft über CI, Staging und eine Freigabe und geht schrittweise live, Evals blockieren schlechte Versionen.
Prüf dich selbst
Denkfrage
Dein Agent läuft als nächtlicher Job und soll zusätzlich per API erreichbar sein. Eine Kollegin kopiert dafür das Skript in einen neuen Dienst. Was schlägst du vor?
Du ziehst die Logik des Agenten in eine gemeinsame Definition und baust zwei schmale Adapter davor, einen für den Zeitplan und einen für die API. Mit zwei Kopien muss jede Korrektur zweimal landen, und früher oder später verhalten sich die beiden Versionen verschieden.
Denkfrage
Dein Agent wiederholt fehlgeschlagene Tool-Aufrufe automatisch. Eines der Tools verschickt Rechnungen. Worauf achtest du?
Das Tool muss idempotent sein, ein zweiter Aufruf mit derselben Anfrage darf keine zweite Rechnung erzeugen. Eine verbreitete Lösung ist eine feste Kennung pro Rechnung, die das Tool beim zweiten Aufruf wiedererkennt. Erst dann ist die automatische Wiederholung sicher.
Prüf dich selbst
Quellen
- Prototype to Production
„Building an agent is easy. Trusting it is hard.“, rund 80 % Aufwand für Infrastruktur, Sicherheit und Validierung, AgentOps, CI, Staging und Freigabe, Canary und Blue-Green, Beispiel mit 48 Stunden.
- AIP architecture
Automatisierungen nach Zeitplan, nach Ereignis und über APIs, Zugriff auf Sprachmodelle über von Palantir verwaltete Infrastruktur, Beobachtung bis zum Token-Verbrauch.