Wenn der Agent nachts allein arbeitet
Seit ein paar Monaten läuft bei mir ein Agent rund um die Uhr. Kein Daemon, den ich selbst gebaut habe, sondern ein LLM, das per Cronjob regelmäßig Aufgaben abarbeitet: morgens ein Briefing zusammenfassen, YouTrack-Issues aufbereiten, abends einen Sicherheitscheck fahren. Der Agent ist mein Assistent – und anfangs habe ich den Fehler gemacht, ihn wie einen Cronjob zu behandeln, der einfach läuft.
Ein Agent ist kein Cronjob
Ein klassischer Cronjob hat zwei Zustände: gelaufen oder nicht gelaufen. Der Exit-Code sagt dir, ob es geklappt hat. Ein LLM-Agent hat einen dritten, heimtückischeren Zustand: Er ist gelaufen, hat eine Antwort produziert, und die Antwort ist trotzdem falsch – nur sieht sie auf den ersten Blick richtig aus.
Der erste Fall, der mich wachgerüttelt hat, war ein Report, der jeden Morgen fehlte. Kein Fehler im Log, kein kaputter Cron – der Job lief durch und lieferte schlicht nichts Brauchbares. Der Fehler lag nicht im Code, sondern im Verhalten: eine Rate-Limit-Meldung, die der Agent einfach hinnahm, statt es noch einmal zu versuchen.
Da habe ich die erste Regel formuliert: Ein Agent braucht andere Fehlerbehandlung als ein Skript. Ein Skript darf bei einem Fehler abbrechen. Ein Agent muss unterscheiden, ob ein Fehler sich von selbst erledigt – oder ob er ohne mein Zutun nie wieder verschwindet.
Zwei Arten von Fehlern
Diese Unterscheidung ist der Kern. Ich teile Fehler in zwei Klassen:
- Selbstheilend. Rate-Limits, kurze Timeouts, ein Dienst, der gerade nicht erreichbar ist. Hier ist die richtige Reaktion: still wiederholen. Ein paar Minuten warten, nochmal probieren. Das braucht mich nicht.
- Manuell. Abgelaufene Tokens, kaputte Authentifizierung, eine API, die ihre Struktur geändert hat. Hier hilft kein Retry. Wenn ich das still umgehe, fällt der Fehler dauerhaft unter den Tisch – der Job „läuft", liefert aber seit Wochen nichts.
Der Unterschied klingt banal, aber er ist es nicht. Ein Agent, der jeden Fehler laut meldet, nervt dich mit Rate-Limits, bis du ihn ignorierst. Ein Agent, der jeden Fehler still schluckt, verreckt lautlos, und du merkst es erst, wenn du das Ergebnis brauchst.
Für mich heißt das konkret: Selbstheilende Fehler werden automatisch wiederholt, ohne mich. Manuelle Fehler landen bei mir – als Meldung, nicht als stille Lücke.
Erst messen, dann optimieren
Der zweite Fehler war typisch für mich: Ich habe zu viele Jobs zu oft laufen lassen, bevor ich wusste, was sie kosten.
Ein LLM-Agent verbraucht Tokens. Jeder Durchlauf kostet – und bei einem Agent, der alle fünfzehn Minuten etwas prüft, summiert sich das schneller, als man denkt. Als ich anfing, den Verbrauch zu tracken, sah ich auf einen Blick, dass ein einziger Job fast die Hälfte aller Tokens fraß. Nicht weil er kompliziert war, sondern weil er schlicht zu oft lief.
Die Lösung war keine technische, sondern eine taktische: den Rhythmus hinterfragen. Braucht dieser Job wirklich alle fünfzehn Minuten einen Durchlauf, oder reicht eine Stunde? In den meisten Fällen reichte weniger. Der Verbrauch sank, ohne dass mir etwas gefehlt hat.
Das ist dieselbe Lektion wie beim Monitoring und beim Backup: erst messen, dann optimieren. Du kannst nicht optimieren, was du nicht siehst. Bei mir läuft das über ein paar kleine Skripte, die den Token-Verbrauch pro Job festhalten – nichts Aufwendiges, aber genug, um zu wissen, wer der größte Verbraucher ist.
Die Regeln, die ich eingeführt habe
Inzwischen hat sich ein kleiner Regelkatalog eingeschliffen. Nichts Spektakuläres, aber er verhindert die meisten Störungen, bevor sie passieren:
- Jeder Job meldet sich. Ob Erfolg oder Fehler – das Ergebnis landet in einem Kanal, den ich tatsächlich lese. Ein Job, der schweigt, ist ein Job, dem ich nicht vertraue.
- Erfolg muss sich beweisen. „Gelaufen" heißt noch nicht „erledigt". Wichtige Jobs prüfen ihr eigenes Ergebnis – existiert der Report wirklich, steht der Eintrag wirklich im Zielsystem?
- Wiederholungen sind endlich. Ein Retry, der unbegrenzt läuft, ist kein Retry, sondern ein verdeckter Fehler. Nach einer Handvoll Versuchen gibt es eine Meldung statt eines stillen Abbruchs.
- Selten ist besser als häufig. Bevor ich einen Job häufiger laufen lasse, frage ich, ob der Mehrwert die Kosten rechtfertigt. Meistens tut er das nicht.
Der letzte Punkt ist der wichtigste. Es ist verlockend, alles ständig zu prüfen – aber ein Agent, der dich jede Stunde mit Belanglosigkeiten zuspammt, wird genauso ignoriert wie einer, der schweigt.
Was ich daraus mitnehme
Ein autonomer Agent ist kein Werkzeug, das man einrichtet und vergisst. Er ist ein Mitarbeiter, den man führen muss – mit klaren Regeln, was er selbst entscheiden darf und was er melden muss. Der Unterschied zwischen einem nützlichen Agenten und einem, der still vor sich hin arbeitet und falsch liegt, ist nicht die Modellqualität. Es ist die Aufsicht.
Und die Kernaussage ist dieselbe wie immer: Der beste Agent ist nicht der mit den meisten Features, sondern der, den du tatsächlich im Blick behältst. Ein Agent, den du nicht beobachtest, ist schlimmer als keiner – weil er dir das Gefühl gibt, es laufe etwas, während es in Wahrheit nur so tut.